Thời gian khởi động ứng dụng

Người dùng mong muốn ứng dụng sẽ phản hồi nhanh và tải nhanh. Một ứng dụng có thời gian khởi động chậm không đáp ứng được kỳ vọng này và có thể gây thất vọng cho người dùng. Tình trạng này có thể khiến người dùng đánh giá không tốt ứng dụng của bạn trên Cửa hàng Play, hoặc thậm chí là bỏ qua hoàn toàn ứng dụng của bạn.

Trang này cung cấp thông tin giúp tối ưu hoá thời gian khởi chạy ứng dụng, bao gồm nội dung tổng quan về các yếu tố bên trong trong quy trình khởi chạy, cách phân tích hiệu suất khởi động và một số vấn đề thường gặp về thời gian khởi động cùng các mẹo về cách giải quyết các vấn đề đó.

Hiểu rõ các trạng thái khởi động ứng dụng

Hoạt động khởi chạy ứng dụng có thể diễn ra ở một trong 3 trạng thái: khởi động nguội, khởi động ấm hoặc khởi động nóng. Mỗi trạng thái ảnh hưởng đến khoảng thời gian mà ứng dụng của bạn hiển thị cho người dùng. Khi khởi động nguội, ứng dụng của bạn sẽ khởi động lại từ đầu. Ở các trạng thái khác, hệ thống cần đưa ứng dụng đang chạy từ nền lên nền trước.

Bạn nên tối ưu hoá dựa trên giả định khởi động nguội. Việc này cũng có thể cải thiện hiệu suất của chế độ khởi động ấm và nóng.

Để tối ưu hoá việc khởi động nhanh ứng dụng, bạn nên nắm được những gì đang diễn ra ở cấp hệ thống và cấp ứng dụng, cũng như cách chúng tương tác ở mỗi trạng thái.

Hai chỉ số quan trọng để xác định thời gian khởi động ứng dụng là thời gian để hiển thị khung hình đầu tiên (TTID)thời gian để hiển thị đầy đủ (TTFD). TTID là thời gian cần thiết để hiển thị khung hình đầu tiên và TTFD là thời gian để ứng dụng có khả năng tương tác hoàn chỉnh. Cả 2 chỉ số này đều quan trọng như nhau, vì TTID cho người dùng biết rằng ứng dụng đang tải và TTFD cho biết thời điểm ứng dụng thực sự có thể dùng được. Nếu một trong hai chỉ số này quá lớn, thì người dùng có thể thoát khỏi ứng dụng của bạn trước khi ứng dụng tải hoàn toàn.

Để xem các giá trị chính xác của TTFD, hãy báo hiệu khi ứng dụng đạt đến trạng thái hiển thị đầy đủ để giúp đảm bảo đo lường thời gian chính xác. Để tìm hiểu cách làm việc này, hãy xem bài viết Cải thiện độ chính xác của thời gian khởi động.

Khởi động nguội

Khởi động nguội là việc mở ứng dụng từ đầu. Điều này có nghĩa là quy trình của hệ thống sẽ chỉ tạo ra quy trình của ứng dụng cho khi quá trình khởi động nguội bắt đầu. Khởi động nguội xảy ra trong một số trường hợp, chẳng hạn như ứng dụng của bạn khởi chạy lần đầu kể từ khi thiết bị khởi động, hoặc kể từ khi hệ thống buộc dừng ứng dụng.

Hình thức khởi động này đưa ra thách thức lớn nhất về việc giảm thiểu thời gian khởi động, vì hệ thống và ứng dụng phải làm nhiều việc hơn so với các trạng thái chạy khác.

Khi bắt đầu khởi động nguội, hệ thống có 3 nhiệm vụ sau đây:

  1. Tải và khởi chạy ứng dụng.
  2. Hiển thị cửa sổ khởi động trống cho ứng dụng ngay sau khi khởi chạy.
  3. Tạo quy trình ứng dụng.

Ngay khi hệ thống tạo quy trình ứng dụng, quy trình này sẽ chịu trách nhiệm về các giai đoạn tiếp theo:

  1. Tạo đối tượng ứng dụng.
  2. Chạy luồng chính.
  3. Tạo hoạt động chính.
  4. Tăng cường khung hiển thị.
  5. Sắp xếp bố cục màn hình.
  6. Thực hiện thao tác vẽ ban đầu.

Khi quy trình ứng dụng hoàn tất lần vẽ đầu tiên, quy trình hệ thống sẽ thay đổi cửa sổ nền đang hiển thị và thay thế bằng hoạt động chính. Tại thời điểm này, người dùng có thể bắt đầu sử dụng ứng dụng.

Hình 1 cho thấy cách hệ thống và các quy trình ứng dụng chuyển đổi công việc luân phiên với nhau.

Hình 1. Hình ảnh minh hoạ các phần quan trọng của quá trình khởi chạy ứng dụng nguội.

Các vấn đề về hiệu suất có thể phát sinh trong quá trình tạo ứng dụng và tạo hoạt động.

Tạo ứng dụng

Khi ứng dụng của bạn chạy, cửa sổ khởi động trống vẫn sẽ hiển thị trên màn hình cho đến khi hệ thống hoàn tất thao tác vẽ ứng dụng lần đầu. Khi đó, quy trình hệ thống sẽ hoán đổi cửa sổ khởi động cho ứng dụng của bạn, cho phép người dùng tương tác với ứng dụng.

Nếu bạn đã ghi đè Application.onCreate() trong ứng dụng của riêng mình, hệ thống sẽ gọi phương thức onCreate() trên đối tượng ứng dụng. Sau đó, ứng dụng sẽ tạo luồng chính (còn gọi là luồng giao diện người dùng) và thực hiện thao tác bằng cách tạo hoạt động chính.

Từ đó, các quy trình ở cấp hệ thống và cấp ứng dụng sẽ tiếp tục theo các giai đoạn trong vòng đời của ứng dụng.

Tạo hoạt động

Sau khi ứng dụng tạo ra hoạt động, hoạt động đó sẽ thực hiện các hoạt động sau:

  1. Khởi chạy các giá trị.
  2. Gọi hàm khởi tạo.
  3. Gọi phương thức gọi lại, chẳng hạn như Activity.onCreate(), phù hợp với trạng thái vòng đời hiện tại của hoạt động.

Thường thì phương thức onCreate() có tác động lớn nhất đến thời gian tải, vì phương thức này thực hiện công việc với chi phí cao nhất, bao gồm tải và tăng cường khung hiển thị cũng như khởi tạo các đối tượng cần thiết cho hoạt động để chạy.

Khởi động ấm

Một quy trình khởi động ấm bao gồm một tập con các thao tác diễn ra trong quá trình khởi động nguội. Đồng thời, điều đó cho thấy mức hao tổn cao hơn so với quy trình khởi động nóng. Có nhiều trạng thái tiềm năng có thể được coi là khởi động ấm, chẳng hạn như sau:

  • Người dùng quay lại ứng dụng của bạn, sau đó chạy lại ứng dụng. Quá trình này có thể tiếp tục chạy nhưng ứng dụng phải tạo lại hoạt động từ đầu thông qua lệnh gọi đến onCreate().

  • Hệ thống sẽ loại bỏ ứng dụng của bạn khỏi bộ nhớ, sau đó người dùng khởi chạy lại ứng dụng. Quy trình và hoạt động cần được khởi động lại, nhưng tác vụ có thể hưởng lợi đôi chút từ gói trạng thái của thực thể đã lưu được truyền vào onCreate().

Khởi động nóng

Khởi động nóng ứng dụng có mức hao tổn thấp hơn so với khởi động nguội. Khi khởi động nóng, hệ thống sẽ đưa hoạt động của bạn lên nền trước. Nếu tất cả hoạt động của ứng dụng vẫn nằm trong bộ nhớ, thì ứng dụng có thể tránh lặp lại thao tác khởi tạo đối tượng, tăng cường bố cục và kết xuất.

Tuy nhiên, nếu một số bộ nhớ bị xoá hoàn toàn để đáp ứng các sự kiện cắt bỏ bộ nhớ, chẳng hạn như onTrimMemory(), thì các đối tượng đó cần được tạo lại để phản hồi sự kiện khởi động nóng.

Quá trình khởi động nóng sẽ hiển thị cùng hành vi trên màn hình như quá trình khởi động nguội. Quy trình hệ thống này sẽ hiển thị một màn hình trống cho đến khi ứng dụng hiển thị xong hoạt động.

Hình 2. Một sơ đồ cho thấy nhiều trạng thái khởi động và các quy trình tương ứng, trong đó mỗi trạng thái bắt đầu từ thời điểm khung hình đầu tiên được vẽ.

Cách xác định quá trình khởi động ứng dụng trong Perfetto

Để gỡ lỗi các vấn đề về việc khởi động ứng dụng, bạn nên xác định chính xác những gì được đưa vào giai đoạn khởi động ứng dụng. Để xác định toàn bộ giai đoạn khởi động ứng dụng trong Perfetto, hãy làm theo các bước sau:

  1. Trong Perfetto, hãy tìm hàng có chỉ số phát sinh từ Android App Startups (Khởi động ứng dụng Android). Nếu bạn không thấy hàng này, hãy thử ghi lại dấu vết bằng ứng dụng theo dõi hệ thống trên thiết bị.

    Hình 3. Lát cắt chỉ số phát sinh từ Android App Startups (Khởi động ứng dụng Android) trong Perfetto.
  2. Nhấp vào lát cắt được liên kết rồi nhấn m để chọn lát cắt đó. Các dấu ngoặc sẽ xuất hiện xung quanh lát cắt và biểu thị thời lượng cần thiết. Thời lượng đó cũng xuất hiện trong thẻ Current selection (Lựa chọn hiện tại).

  3. Ghim hàng Android App Startups (Khởi động ứng dụng Android) bằng cách nhấp vào biểu tượng ghim. Bạn có thể thấy biểu tượng này khi giữ con trỏ trên hàng đó.

  4. Di chuyển xuống hàng có ứng dụng liên quan rồi nhấp vào ô đầu tiên để mở rộng hàng đó.

  5. Phóng to vào luồng chính (thường ở trên cùng), bằng cách nhấn w (nhấn s, a, d để thu nhỏ, di chuyển sang trái và di chuyển sang phải).

    Hình 4. Lát chỉ số phát sinh từ Android App Startups (Khởi động ứng dụng Android) bên cạnh luồng chính của ứng dụng.
  6. Lát cắt chỉ số phát sinh giúp bạn dễ dàng biết được chính xác dữ liệu nào được đưa vào quá trình khởi động ứng dụng để có thể tiếp tục gỡ lỗi một cách cụ thể hơn.

Sử dụng các chỉ số để phát hiện và chẩn đoán vấn đề

Để chẩn đoán chính xác hiệu suất của thời gian khởi động, bạn có thể theo dõi các chỉ số cho biết thời gian cần để ứng dụng của bạn khởi động. Android sẽ cung cấp một số phương tiện để thông báo cho bạn biết ứng dụng của mình có vấn đề, đồng thời giúp bạn chẩn đoán vấn đề đó. Android vitals có thể cảnh báo cho bạn về một vấn đề đang xảy ra, và các công cụ chẩn đoán có thể giúp bạn chẩn đoán vấn đề đó.

Lợi ích của việc sử dụng các chỉ số khởi động

Android sử dụng các chỉ số thời gian để hiển thị khung hình đầu tiên (TTID)thời gian để hiển thị đầy đủ (TTFD) để tối ưu hoá việc khởi động ấm và khởi động nguội cho ứng dụng. Android Runtime (ART) sử dụng dữ liệu từ các chỉ số này để biên dịch trước
mã một cách hiệu quả nhằm tối ưu hoá các kiểu khởi động sau này.

Khởi động nhanh hơn giúp người dùng tương tác nhiều hơn với ứng dụng của bạn, giảm bớt các trường hợp thoát sớm, khởi động lại phiên bản hoặc chuyển sang một ứng dụng khác.

Android vitals

Android vitals có thể giúp cải thiện hiệu suất của ứng dụng bằng cách thông báo cho bạn trên Play Console, khi thời gian khởi động ứng dụng của bạn quá lớn.

Android vitals xem xét các thời gian khởi động sau đây là quá mức đối với ứng dụng của bạn:

  • Khởi động nguội mất 5 giây trở lên.
  • Khởi động ấm mất từ 2 giây trở lên.
  • Khởi động nóng mất 1,5 giây trở lên.

Android vitals sử dụng chỉ số thời gian để hiển thị khung hình đầu tiên (TTID). Để biết thông tin về cách Google Play thu thập dữ liệu Android vitals, vui lòng xem tài liệu Play Console.

Thời gian để hiển thị khung hình đầu tiên

Chỉ số thời gian để hiển thị khung hình đầu tiên (TTID) cho biết thời lượng cần thiết để một ứng dụng tạo ra khung đầu tiên, bao gồm cả khởi chạy quy trình khi khởi động nguội, tạo hoạt động khi khởi động nguội hoặc khởi động ấm, và hiển thị khung hình đầu tiên.

Cách truy xuất TTID

Logcat bao gồm một dòng đầu ra chứa giá trị có tên là Displayed. Giá trị này biểu thị khoảng thời gian đã trôi qua giữa thời điểm chạy quy trình và hoàn tất việc vẽ hoạt động tương ứng trên màn hình. Thời gian đã trôi qua bao gồm chuỗi sự kiện sau đây:

  • Chạy quy trình này.
  • Khởi tạo đối tượng.
  • Tạo và khởi tạo hoạt động.
  • Tăng cường bố cục.
  • Vẽ ứng dụng lần đầu.

Dòng nhật ký được báo cáo sẽ giống như ví dụ sau:

ActivityManager: Displayed com.android.myexample/.StartupTiming: +3s534ms

Nếu bạn đang theo dõi đầu ra logcat từ dòng lệnh hoặc trong thiết bị đầu cuối, thì việc tìm thời gian đã trôi qua rất đơn giản. Để tìm thời gian đã trôi qua trong Android Studio, hãy tắt các bộ lọc trong khung hiển thị logcat. Bạn cần tắt bộ lọc cho máy chủ hệ thống chứ không phải chính ứng dụng phân phát nhật ký này.

Sau khi thiết lập chế độ cài đặt thích hợp, bạn có thể tìm kiếm đúng cụm từ để xem thời gian. Hình 3 cho thấy cách tắt các bộ lọc bằng cách chọn "No filter" (Không dùng bộ lọc) trong trình đơn thả xuống "bộ lọc" và trong dòng đầu ra thứ hai từ dưới lên (một ví dụ về đầu ra logcat của thời gian Displayed).

Hình 5. Tắt các bộ lọc và tìm giá trị Displayed trong logcat.

Chỉ số Displayed trong dữ liệu đầu ra logcat không nhất thiết ghi lại khoảng thời gian cho đến khi tất cả tài nguyên được tải và hiển thị. Chỉ số này sẽ loại bỏ các tài nguyên không được tham chiếu trong tệp bố cục hoặc ứng dụng tạo ra trong quá trình khởi tạo đối tượng. Chỉ số đó cũng loại trừ các tài nguyên này vì việc tải chúng là một quy trình cùng dòng, đồng thời không chặn khung hình đầu tiên của ứng dụng.

Đôi khi, dòng Displayed trong đầu ra logcat chứa một trường bổ sung dành cho tổng thời gian. Ví dụ:

ActivityManager: Displayed com.android.myexample/.StartupTiming: +3s534ms (total +1m22s643ms)

Trong trường hợp này, phép đo lần đầu chỉ dành cho hoạt động được vẽ lần đầu. Hoạt động đo lường thời gian total bắt đầu khi quá trình ứng dụng bắt đầu, và có thể bao gồm một hoạt động khác được bắt đầu trước tiên nhưng không hiển thị bất kỳ thông tin nào đối với màn hình. Chế độ đo lường thời gian total chỉ hiển thị khi có sự khác biệt giữa một hoạt động và tổng thời gian khởi động.

Bạn cũng có thể đo lường TTID bằng cách chạy ứng dụng thông qua lệnh ADB Shell Activity Manager. Ví dụ:

adb [-d|-e|-s <serialNumber>] shell am start -S -W
com.example.app/.MainActivity
-c android.intent.category.LAUNCHER
-a android.intent.action.MAIN

Chỉ số Displayed xuất hiện trong đầu ra logcat như trước đây. Cửa sổ dòng lệnh hiển thị như sau:

Starting: Intent
Activity: com.example.app/.MainActivity
ThisTime: 2044
TotalTime: 2044
WaitTime: 2054
Complete

Các đối số -c-a là không bắt buộc và cho phép bạn chỉ định <category> lẫn <action>.

Thời gian để hiển thị đầy đủ

Chỉ số Thời gian để hiển thị đầy đủ (TTFD) đo thời gian mà ứng dụng thực hiện để tạo ra khung hình đầu tiên với nội dung đầy đủ, bao gồm cả nội dung được tải không đồng bộ sau khung hình đầu tiên. Thông thường, đây là nội dung danh sách chính được tải từ mạng theo báo cáo của ứng dụng.

Cách truy xuất TTFD

Bạn có thể sử dụng phương thức reportFullyDrawn() để đo lường thời gian giữa thời điểm chạy ứng dụng và thời điểm hiển thị toàn bộ tài nguyên cũng như hệ phân cấp khung hiển thị. Điều này có thể hữu ích trong trường hợp ứng dụng tải từng phần. Trong khi tải từng phần, một ứng dụng không chặn quá trình vẽ cửa sổ ban đầu mà sẽ tải không đồng bộ các tài nguyên và cập nhật hệ phân cấp khung hiển thị.

Nếu màn hình ban đầu của một ứng dụng không bao gồm tất cả tài nguyên vì đang tải từng phần, bạn có thể coi việc tải và hiển thị hoàn chỉnh tất cả tài nguyên và khung hiển thị là một chỉ số riêng. Ví dụ: giao diện người dùng của bạn có thể đã tải đầy đủ bằng một số văn bản được vẽ, nhưng chưa hiển thị hình ảnh mà ứng dụng phải tìm nạp từ mạng.

Cải thiện độ chính xác về thời gian khởi động giải thích cách sử dụng FullyDrawnReporter để trì hoãn gọireportFullyDrawn cho đến khi ứng dụng của bạn có tính tương tác với người dùng.

Khi bạn sử dụng API này, giá trị mà logcat hiển thị là thời gian trôi qua từ lúc tạo đối tượng ứng dụng đến thời điểm reportFullyDrawn() được gọi. Dưới đây là ví dụ về kết quả logcat:

system_process I/ActivityManager: Fully drawn {package}/.MainActivity: +1s54ms

Kết quả logcat đôi khi bao gồm thời gian total, như thảo luận trong mục Thời gian để hiển thị khung hình đầu tiên.

Nếu biết thời gian hiển thị chậm hơn mong muốn, bạn có thể cố gắng xác định điểm tắc nghẽn trong quá trình khởi động.

Xác định điểm tắc nghẽn

Để tìm điểm tắc nghẽn, bạn có thể sử dụng Trình phân tích CPU của Android Studio. Để biết thêm thông tin, hãy xem bài viết Kiểm tra hoạt động của CPU bằng Trình phân tích CPU.

Bạn cũng có thể nắm được thông tin chi tiết về điểm tắc nghẽn tiềm ẩn qua các phương thức onCreate() của ứng dụng và hoạt động của bạn. Để tìm hiểu về tính năng theo dõi cùng dòng, vui lòng xem tài liệu về hàm Tracethông tin tổng quan về tính năng theo dõi hệ thống.

Giải quyết các vấn đề thường gặp

Phần này thảo luận một số vấn đề thường gặp ảnh hưởng đến hiệu suất khởi động của ứng dụng. Các vấn đề này chủ yếu ảnh hưởng đến việc khởi chạy các đối tượng ứng dụng và hoạt động, cũng như hoạt động tải màn hình.

Khởi động ứng dụng nặng

Hiệu suất khởi chạy có thể bị ảnh hưởng khi mã của bạn ghi đè đối tượng Application, và thực thi logic phức tạp hoặc phức tạp khi khởi tạo đối tượng đó. Ứng dụng của bạn có thể lãng phí thời gian trong quá trình khởi động nếu các lớp con của Application thực hiện việc khởi chạy chưa cần thiết.

Một số hoạt động khởi tạo có thể hoàn toàn không cần thiết, chẳng hạn như khi khởi tạo thông tin trạng thái cho hoạt động chính khi thực ra ứng dụng khởi động để phản hồi một ý định. Với ý định, ứng dụng chỉ sử dụng một số dữ liệu trạng thái đã khởi tạo trước đó.

Những thách thức khác trong quá trình khởi chạy ứng dụng bao gồm các sự kiện thu thập rác có tác động lớn hoặc nhiều sự kiện, hoặc hoạt động I/O ổ đĩa diễn ra đồng thời với việc khởi chạy, chặn thêm quá trình khởi chạy. Việc thu gom rác được đặc biệt quan tâm trong thời gian chạy Dalvik; Android Runtime (ART) thực hiện đồng thời thu thập rác, giảm thiểu tác động của hoạt động đó.

Chẩn đoán sự cố

Bạn có thể sử dụng tính năng theo dõi phương thức hoặc theo dõi cùng dòng để chẩn đoán vấn đề.

Tìm dấu vết phương thức

Việc chạy Trình phân tích CPU cho biết phương thức callApplicationOnCreate() sẽ gọi phương thức com.example.customApplication.onCreate của bạn. Nếu công cụ cho thấy các phương thức này mất nhiều thời gian để hoàn thành việc thực thi, bạn nên khám phá thêm để xem phương thức nào đang diễn ra ở đó.

Theo dõi cùng dòng

Sử dụng tính năng theo dõi cùng dòng điều tra các nguyên nhân có khả năng xảy ra, bao gồm:

  • Hàm onCreate() ban đầu của ứng dụng.
  • Mọi đối tượng singleton toàn cầu mà ứng dụng của bạn khởi tạo.
  • Bất kỳ ổ đĩa I/O, quá trình tái thiết hoặc lặp lại nào có thể xảy ra trong nút thắt cổ chai.

Giải pháp cho vấn đề

Cho dù vấn đề nằm ở việc khởi tạo không cần thiết hay với I/O ổ đĩa, giải pháp là khởi tạo lazy. Nói cách khác, chỉ khởi tạo các đối tượng cần thiết ngay lập tức. Thay vì tạo đối tượng tĩnh toàn cầu, hãy chuyển sang mẫu singleton mà ứng dụng chỉ khởi tạo các đối tượng vào lần đầu tiên bạn cần các đối tượng đó.

Ngoài ra, hãy cân nhắc sử dụng một khung chèn phụ thuộc như Hilt để tạo đối tượng và phần phụ thuộc khi chúng được chèn lần đầu tiên.

Nếu ứng dụng của bạn sử dụng nhà cung cấp nội dung để khởi chạy các thành phần ứng dụng khi khởi động, hãy cân nhắc sử dụng thư viện Khởi động ứng dụng.

Khởi chạy hoạt động nặng

Việc tạo hoạt động thường đòi hỏi nhiều công việc với mức hao tổn cao. Thông thường, có nhiều cơ hội để tối ưu hoá công việc này nhằm cải thiện hiệu suất. Sau đây là các vấn đề phổ biến:

  • Chèn bố cục lớn hoặc phức tạp.
  • Chặn vẽ màn hình trên đĩa hoặc I/O mạng.
  • Tải và giải mã bitmap.
  • Đang tạo điểm ảnh cho đối tượng VectorDrawable.
  • Khởi chạy các hệ thống con khác của hoạt động.

Chẩn đoán sự cố

Trong trường hợp này, cả theo dõi phương pháp lẫn theo dõi cùng dòng đều có thể hữu ích.

Tìm dấu vết phương thức

Khi sử dụng Trình phân tích CPU, hãy chú ý đến hàm dựng lớp con Application và phương thức com.example.customApplication.onCreate() của ứng dụng.

Nếu công cụ cho thấy các phương thức này mất nhiều thời gian để hoàn thành việc thực thi, bạn nên khám phá thêm để xem phương thức nào đang diễn ra ở đó.

Theo dõi cùng dòng

Sử dụng tính năng theo dõi cùng dòng điều tra các nguyên nhân có khả năng xảy ra, bao gồm:

  • Hàm onCreate() ban đầu của ứng dụng.
  • Mọi đối tượng singleton toàn cầu mà hàm khởi tạo.
  • Bất kỳ ổ đĩa I/O, quá trình tái thiết hoặc lặp lại nào có thể xảy ra trong nút thắt cổ chai.

Giải pháp cho vấn đề

Có thể có nhiều điểm tắc nghẽn, nhưng vấn đề và các phương án khắc phục thông thường sẽ như sau:

  • Hệ phân cấp khung hiển thị của bạn càng lớn, ứng dụng càng mất nhiều thời gian để tăng cường. Bạn có thể giải quyết vấn đề này qua 2 bước sau:
    • Làm phẳng hệ phân cấp khung hiển thị bằng cách giảm bố cục thừa hoặc lồng nhau.
    • Không tăng cường các phần của giao diện người dùng không cần hiển thị trong quá trình khởi chạy. Thay vào đó, hãy sử dụng đối tượng ViewStub làm phần giữ chỗ cho các hệ phân cấp phụ mà ứng dụng có thể tăng kích thước vào thời điểm thích hợp hơn.
  • Tất cả hoạt động khởi tạo tài nguyên của bạn trên luồng chính cũng có thể làm chậm quá trình khởi động. Bạn có thể giải quyết vấn đề này như sau:
    • Di chuyển tất cả hoạt động khởi tạo tài nguyên để ứng dụng có thể thực hiện từng phần trên một luồng khác.
    • Cho phép ứng dụng tải và hiển thị khung hiển thị của bạn, sau đó cập nhật các thuộc tính hình ảnh phụ thuộc vào bitmap và các tài nguyên khác.

Màn hình chờ tuỳ chỉnh

Bạn có thể thấy thêm thời gian khởi động trong quá trình khởi động, nếu trước đó bạn đã sử dụng một trong các phương thức sau để triển khai màn hình chờ tùy chỉnh trong Android 11 (API cấp 30) trở xuống:

  • Sử dụng thuộc tính giao diện windowDisablePreview để tắt màn hình trống ban đầu do hệ thống vẽ trong khi chạy.
  • Sử dụng Activity chuyên biệt.

Bắt đầu từ Android 12, bạn phải chuyển sang SplashScreen API. API này cho phép thời gian khởi động nhanh hơn và cho phép bạn điều chỉnh màn hình chờ theo các cách sau:

Hơn nữa, thư viện khả năng tương thích điều chỉnh SplashScreen API cho phiên bản cũ để mang đến khả năng tương thích ngược và tạo giao diện nhất quán để hiện màn hình chờ trên tất cả các phiên bản Android.

Xem Hướng dẫn di chuyển màn hình chờ để biết thông tin chi tiết.