Tối ưu hoá việc sử dụng bộ nhớ

Việc tối ưu hoá bộ nhớ là yếu tố quan trọng để đảm bảo hiệu suất mượt mà, ngăn ứng dụng gặp sự cố và duy trì tính ổn định của hệ thống cũng như trạng thái hoạt động của nền tảng. Mặc dù bạn nên theo dõi và tối ưu hoá mức sử dụng bộ nhớ trong mọi ứng dụng, nhưng các ứng dụng nội dung dành cho thiết bị TV có những thách thức cụ thể khác với các ứng dụng Android thông thường dành cho thiết bị cầm tay.

Mức tiêu thụ bộ nhớ cao có thể dẫn đến các vấn đề về hành vi của ứng dụng và hệ thống, bao gồm:

• Bản thân ứng dụng có thể trở nên chậm hoặc bị trễ, hoặc trong trường hợp xấu nhất, ứng dụng sẽ bị huỷ.
• Các dịch vụ hệ thống mà người dùng có thể thấy (Điều khiển âm lượng, bảng điều khiển Cài đặt hình ảnh, Trợ lý giọng nói, v.v.) trở nên rất chậm hoặc có thể không hoạt động.
• Tiến trình của trình nền low memory killer (LMK) có thể phản ứng với áp lực bộ nhớ cao bằng cách loại bỏ các tiến trình ít cần thiết nhất; sau đó, các thành phần này có thể khởi động lại ngay sau đó, kích hoạt các đợt tăng đột biến của tình trạng tranh chấp tài nguyên hơn nữa, điều này có thể ảnh hưởng trực tiếp đến ứng dụng trên nền trước.
• Quá trình chuyển đổi sang Trình chạy có thể bị trì hoãn đáng kể và khiến ứng dụng trên nền trước có vẻ không phản hồi cho đến khi quá trình chuyển đổi kết thúc.
• Hệ thống có thể bắt đầu sử dụng thu hồi trực tiếp, tạm thời tạm dừng quá trình thực thi luồng trong khi chờ phân bổ bộ nhớ. Điều này có thể xảy ra với bất kỳ luồng nào, chẳng hạn như luồng chính hoặc các luồng liên quan đến bộ mã hoá và giải mã, có khả năng gây ra tình trạng sụt khung hình âm thanh và video, cũng như các sự cố về giao diện người dùng.

Những điều cần lưu ý về bộ nhớ trên thiết bị TV

Các thiết bị TV thường có ít bộ nhớ hơn đáng kể so với điện thoại hoặc máy tính bảng. Ví dụ: một cấu hình mà chúng ta có thể thấy trên TV là RAM 1 GB và độ phân giải video 1080p. Đồng thời, hầu hết các ứng dụng truyền hình đều có các tính năng tương tự nhau; do đó, việc triển khai và những thách thức thường gặp cũng tương tự nhau. Hai trường hợp này gây ra những vấn đề không gặp phải ở các loại thiết bị và ứng dụng khác:

• Các ứng dụng truyền hình đa phương tiện thường bao gồm cả khung hiển thị hình ảnh dạng lưới và hình nền toàn màn hình. Điều này đòi hỏi phải tải nhiều hình ảnh vào bộ nhớ trong một khoảng thời gian ngắn
• Các ứng dụng truyền hình phát các luồng đa phương tiện cần phân bổ một lượng bộ nhớ nhất định để phát video và âm thanh, đồng thời cần có bộ đệm truyền thông đáng kể để đảm bảo quá trình phát diễn ra suôn sẻ.
• Các tính năng bổ sung về nội dung nghe nhìn (tìm kiếm, thay đổi tập, thay đổi bản âm thanh, v.v.) có thể gây thêm áp lực lên bộ nhớ nếu không được triển khai đúng cách.

Tìm hiểu về các thiết bị TV

Hướng dẫn này chủ yếu tập trung vào mức sử dụng bộ nhớ của ứng dụng và các mục tiêu về bộ nhớ cho thiết bị có RAM thấp.

Trên các thiết bị TV, hãy cân nhắc những đặc điểm sau:

• Bộ nhớ thiết bị: Dung lượng Bộ nhớ truy cập ngẫu nhiên (RAM) mà thiết bị đã cài đặt.
• Độ phân giải giao diện người dùng thiết bị: Độ phân giải mà thiết bị dùng để kết xuất giao diện người dùng của hệ điều hành và ứng dụng; độ phân giải này thường thấp hơn độ phân giải video của thiết bị.
• Độ phân giải video: Độ phân giải tối đa mà thiết bị có thể phát video.

Điều này dẫn đến việc phân loại các loại thiết bị và cách chúng nên sử dụng bộ nhớ.

Thông tin tóm tắt về thiết bị TV

Thiết bị TV có RAM thấp

Các thiết bị này đang ở trong tình huống hạn chế về bộ nhớ và sẽ báo cáo ActivityManager.isLowRAMDevice() thành true. Các ứng dụng đang chạy trên thiết bị TV có RAM thấp cần triển khai các biện pháp kiểm soát bộ nhớ bổ sung.

Chúng tôi coi những thiết bị có các đặc điểm sau đây là thuộc danh mục này:

• Thiết bị có RAM 1 GB: RAM 1 GB, độ phân giải giao diện người dùng 720p/HD (1280x720), độ phân giải video 1080p/FullHD (1920x1080)
• Thiết bị có RAM 1,5 GB: RAM 1,5 GB, độ phân giải giao diện người dùng 1080p/FullHD (1920x1080), độ phân giải video 2160p/UltraHD/4K (3840x2160)
• Các trường hợp khác mà OEM xác định cờ ActivityManager.isLowRAMDevice() do các hạn chế bổ sung về bộ nhớ.

Thiết bị TV thông thường

Những thiết bị này không gặp phải tình trạng áp lực bộ nhớ đáng kể như vậy. Chúng tôi coi những thiết bị này có các đặc điểm sau:

• RAM từ 1,5 GB trở lên, giao diện người dùng 720p hoặc 1080p và độ phân giải video 1080p
• RAM từ 2 GB trở lên, giao diện người dùng 1080p và độ phân giải video 1080p hoặc 2160p

Điều này không có nghĩa là các ứng dụng không cần quan tâm đến mức sử dụng bộ nhớ trên những thiết bị này, vì một số hành vi sử dụng bộ nhớ sai cụ thể vẫn có thể làm cạn kiệt bộ nhớ hiện có và hoạt động kém hiệu quả.

Mục tiêu về bộ nhớ trên các thiết bị TV có RAM thấp

Khi đo lường bộ nhớ trên các thiết bị này, bạn rất nên giám sát mọi phần của bộ nhớ bằng trình phân tích bộ nhớ trong Android Studio. Các ứng dụng truyền hình nên lập hồ sơ về mức sử dụng bộ nhớ và cố gắng đưa các danh mục xuống dưới ngưỡng mà chúng tôi xác định trong phần này.

Trong phần Cách tính bộ nhớ, bạn sẽ thấy phần giải thích chi tiết về số liệu bộ nhớ được báo cáo. Để xác định ngưỡng cho các ứng dụng TV, chúng tôi sẽ tập trung vào 3 danh mục bộ nhớ:

• Ẩn danh + Hoán đổi: Bao gồm bộ nhớ phân bổ Java + Gốc + Ngăn xếp trong Android Studio.
• Đồ hoạ: Được báo cáo trực tiếp trên công cụ lập hồ sơ. Thường bao gồm các hoạ tiết đồ hoạ.
• Tệp: Được báo cáo là danh mục "Mã" + "Khác" trong Android Studio.

Với những định nghĩa này, bảng sau đây cho biết giá trị tối đa mà mỗi loại nhóm bộ nhớ nên sử dụng:

Tổng bộ nhớ tối đa (Anon+Swap + Graphics + File) không được vượt quá những giới hạn sau:

• 280 MB tổng mức sử dụng bộ nhớ (Anon+Swap + Graphics + File) cho các thiết bị có RAM thấp 1 GB.

Bạn không nên vượt quá:

• 200 MB mức sử dụng bộ nhớ trên (Anon+Swap + Graphics).

Bộ nhớ tệp

Theo hướng dẫn chung về bộ nhớ được hỗ trợ bằng tệp, hãy lưu ý rằng:

• Nhìn chung, bộ nhớ tệp được hệ thống quản lý bộ nhớ của hệ điều hành xử lý tốt.
• Hiện tại, chúng tôi chưa nhận thấy đây là nguyên nhân chính gây áp lực về bộ nhớ.

Tuy nhiên, khi xử lý Bộ nhớ tệp nói chung:

• Không đưa các thư viện không dùng đến vào bản dựng và sử dụng các tập hợp con nhỏ của thư viện thay vì các thư viện hoàn chỉnh khi có thể.
• Đừng mở các tệp lớn vào bộ nhớ và giải phóng chúng ngay khi bạn dùng xong.
• Giảm thiểu kích thước mã đã biên dịch cho các lớp Java và Kotlin, hãy xem hướng dẫn Rút gọn, làm rối mã nguồn và tối ưu hoá ứng dụng.

Nội dung đề xuất cụ thể cho TV

Phần này đưa ra các đề xuất cụ thể để tối ưu hoá mức sử dụng bộ nhớ trên các thiết bị TV.

Bộ nhớ đồ hoạ

Sử dụng định dạng và độ phân giải hình ảnh phù hợp.

• Không tải hình ảnh có độ phân giải cao hơn độ phân giải giao diện người dùng của thiết bị. Ví dụ: hình ảnh 1080p phải được giảm kích thước xuống 720p trên thiết bị có giao diện người dùng 720p.
• Sử dụng bitmap dựa trên phần cứng khi có thể.
  • Trên các thư viện như Glide, hãy bật tính năng Downsampler.ALLOW_HARDWARE_CONFIG (theo mặc định, tính năng này bị tắt). Việc bật chế độ này giúp tránh trùng lặp bitmap, nếu không thì bitmap sẽ nằm cả trong bộ nhớ đồ hoạ và bộ nhớ ẩn.
• Tránh hiển thị trung gian và hiển thị lại
  • Bạn có thể xác định những vấn đề này bằng Android GPU Inspector:
  • Hãy xem phần "Kết cấu" để tìm những hình ảnh là các bước hướng tới bản kết xuất cuối cùng thay vì chỉ là các phần tử tạo nên hình ảnh đó. Đây thường được gọi là "bản kết xuất trung gian".
  • Đối với các ứng dụng SDK Android, bạn thường có thể xoá các ứng dụng này bằng cách sử dụng cờ bố cục forceHasOverlappedRendering:false để tắt quá trình kết xuất trung gian cho bố cục này.
  • Hãy xem bài viết Tránh các thành phần hiển thị chồng chéo về các thành phần hiển thị chồng chéo để biết thông tin hữu ích.
• Tránh tải hình ảnh giữ chỗ khi có thể, hãy dùng @android:color/ hoặc @color cho các hoạ tiết giữ chỗ.
• Tránh kết hợp nhiều hình ảnh trên thiết bị khi có thể thực hiện việc kết hợp mà không cần kết nối mạng. Ưu tiên tải hình ảnh độc lập thay vì kết hợp hình ảnh từ hình ảnh đã tải xuống
• Hãy làm theo hướng dẫn Xử lý bitmap để xử lý Bitmap hiệu quả hơn.

Bộ nhớ Anon+Swap

Anon+Swap bao gồm các lượt phân bổ Gốc + Java + Ngăn xếp trong trình phân tích bộ nhớ Android Studio. Sử dụng ActivityManager.isLowMemoryDevice() để kiểm tra xem thiết bị có bị hạn chế về bộ nhớ hay không và thích ứng với tình huống này theo các nguyên tắc sau.

• Nội dung nghe nhìn:
  • Chỉ định kích thước biến đổi cho các vùng đệm nội dung nghe nhìn tuỳ thuộc vào RAM của thiết bị và độ phân giải phát video. Thời gian này phải tính đến 1 phút phát video:
    1. 40 – 60 MB cho 1 GB / 1080p
    2. 60 – 80 MB cho 1,5 GB / 1080p
    3. 80 – 100 MB cho 1,5 GB / 2160p
    4. 100 – 120 MB cho 2 GB / 2160p
  • Phân bổ bộ nhớ nội dung nghe nhìn miễn phí khi thay đổi một tập để ngăn tổng lượng bộ nhớ ẩn danh tăng lên.
  • Phát hành và dừng ngay các tài nguyên nghe nhìn khi ứng dụng của bạn bị dừng: Sử dụng lệnh gọi lại vòng đời của hoạt động để xử lý tài nguyên âm thanh và video. Nếu bạn không phải là ứng dụng âm thanh, hãy dừng phát khi onStop() xảy ra trên các hoạt động của bạn, lưu tất cả công việc bạn đang thực hiện và đặt tài nguyên để phát hành. Để lên lịch cho công việc mà bạn có thể cần sau này. Xem phần Công việc và chuông báo.
    • Bạn có thể sử dụng các thành phần nhận biết vòng đời như LiveData và LifecycleOwner để giúp bạn xử lý các lệnh gọi vòng đời của activity.
    • Để giúp công việc của bạn nhận biết được Vòng đời, bạn cũng có thể sử dụng coroutine của Kotlin và luồng Kotlin.
  • Chú ý đến bộ nhớ của vùng đệm khi tìm kiếm video: Nhà phát triển thường phân bổ thêm 15 đến 60 giây nội dung trong tương lai khi tìm kiếm để video sẵn sàng cho người dùng, nhưng điều này tạo ra thêm chi phí bộ nhớ. Nói chung, không lấy quá 5 giây bộ nhớ đệm trong tương lai cho đến khi người dùng chọn vị trí mới cho video. Nếu bạn thực sự cần đệm thêm thời gian trong khi tìm kiếm, hãy nhớ:
    • Phân bổ vùng đệm tìm kiếm trước và sử dụng lại vùng đệm đó.
    • Dung lượng bộ nhớ đệm không được lớn hơn 15 – 25 MB (tuỳ thuộc vào bộ nhớ thiết bị).
• Phân bổ:
  • Sử dụng hướng dẫn về bộ nhớ đồ hoạ để đảm bảo bạn không sao chép hình ảnh trong bộ nhớ ẩn danh
    • Hình ảnh thường là thành phần sử dụng bộ nhớ nhiều nhất, vì vậy, việc sao chép hình ảnh có thể gây nhiều áp lực lên thiết bị. Điều này đặc biệt đúng trong quá trình điều hướng nhiều lưới hình ảnh.
  • Giải phóng các mục phân bổ bằng cách thả các giá trị tham chiếu của chúng khi di chuyển màn hình: Đảm bảo không còn giá trị tham chiếu nào đến các đối tượng và bitmap.
• Thư viện:
  • Phân bổ bộ nhớ hồ sơ từ các thư viện khi thêm các thư viện mới, vì các thư viện này cũng có thể tải các thư viện bổ sung, đồng thời cũng có thể phân bổ và tạo Các liên kết.
• Kết nối mạng:
  • Không thực hiện các lệnh gọi mạng chặn trong quá trình khởi động ứng dụng, vì các lệnh gọi này làm chậm thời gian khởi động ứng dụng và tạo thêm chi phí bộ nhớ khi khởi chạy, trong đó bộ nhớ bị hạn chế đặc biệt do tải ứng dụng. Trước tiên, hãy hiện màn hình tải hoặc màn hình khởi động và thực hiện các yêu cầu mạng sau khi giao diện người dùng đã sẵn sàng.

Đường liên kết

Các liên kết tăng thêm mức sử dụng bộ nhớ vì chúng đưa các ứng dụng khác vào bộ nhớ hoặc tăng mức tiêu thụ bộ nhớ của ứng dụng được liên kết (nếu ứng dụng đó đã có trong bộ nhớ) để hỗ trợ lệnh gọi API. Do đó, điều này sẽ giảm bộ nhớ có sẵn cho ứng dụng trên nền trước. Khi liên kết một dịch vụ, hãy lưu ý đến thời điểm và thời gian bạn sử dụng hoạt động liên kết. Hãy nhớ giải phóng mối liên kết ngay khi không cần thiết nữa.

Các liên kết điển hình và các phương pháp hay nhất:

• API Tính toàn vẹn của Play: Dùng để kiểm tra tính toàn vẹn của thiết bị
  • Kiểm tra tính toàn vẹn của thiết bị sau màn hình tải và trước khi phát nội dung nghe nhìn
  • Phát hành các tham chiếu đến PlayIntegrity StandardIntegrityManager trước khi phát nội dung.
• Thư viện Play Billing: Dùng để quản lý gói thuê bao và giao dịch mua bằng Google Play
  • Khởi chạy thư viện sau màn hình tải và xử lý tất cả công việc thanh toán trước khi phát bất kỳ nội dung nghe nhìn nào.
  • Sử dụng BillingClient.endConnection() khi dùng xong thư viện và luôn dùng trước khi phát video hoặc nội dung nghe nhìn.
  • Sử dụng BillingClient.isReady() và BillingClient.getConnectionState() để kiểm tra xem dịch vụ có bị ngắt kết nối hay không trong trường hợp cần thực hiện lại bất kỳ công việc thanh toán nào, sau đó thực hiện lại BillingClient.endConnection() sau khi hoàn tất.
• GMS FontsProvider
  • Bạn nên sử dụng phông chữ độc lập trên các thiết bị có RAM thấp thay vì sử dụng trình cung cấp phông chữ, vì việc tải phông chữ xuống tốn kém và FontsProvider sẽ liên kết các dịch vụ để thực hiện việc này.
• Thư viện Trợ lý Google: Đôi khi được dùng cho tính năng tìm kiếm và tìm kiếm trong ứng dụng. Nếu có thể, hãy thay thế thư viện này.
  • Đối với các ứng dụng leanback: Sử dụng tính năng chuyển văn bản sang lời nói của Gboard hoặc thư viện androidx.leanback.
    • Tuân thủ Nguyên tắc của Tìm kiếm để triển khai tính năng tìm kiếm.
    • Lưu ý: leanback không được dùng nữa và các ứng dụng nên chuyển sang TV Compose.
  • Đối với các ứng dụng Compose:
    • Sử dụng tính năng chuyển văn bản sang lời nói của Gboard để triển khai tính năng tìm kiếm bằng giọng nói.
  • Triển khai Xem tiếp để giúp người dùng khám phá nội dung nghe nhìn trong ứng dụng của bạn.

Dịch vụ trên nền trước

Dịch vụ trên nền trước là một loại dịch vụ đặc biệt được liên kết với một thông báo. Thông báo này xuất hiện trên khay thông báo của điện thoại và máy tính bảng, nhưng các thiết bị TV không có khay thông báo theo cách tương tự như những thiết bị đó. Ngay cả khi Dịch vụ trên nền trước hữu ích vì có thể tiếp tục chạy trong khi ứng dụng ở chế độ nền, các ứng dụng truyền hình vẫn phải tuân thủ những nguyên tắc sau:

Trong Android TV và Google TV, Dịch vụ trên nền trước chỉ được phép tiếp tục chạy sau khi người dùng rời khỏi ứng dụng:

• Đối với ứng dụng âm thanh: Dịch vụ trên nền trước chỉ được phép tiếp tục chạy sau khi người dùng rời khỏi ứng dụng để tiếp tục phát bản âm thanh. Dịch vụ phải dừng ngay sau khi quá trình phát âm thanh kết thúc.
• Đối với mọi ứng dụng khác: tất cả Dịch vụ trên nền trước phải dừng khi người dùng rời khỏi ứng dụng của bạn, vì không có thông báo nào cho người dùng biết rằng ứng dụng vẫn đang chạy và tiêu thụ tài nguyên.
• Đối với các tác vụ ở chế độ nền, chẳng hạn như cập nhật đề xuất hoặc Video nên xem tiếp theo, hãy dùng WorkManager.

Công việc và chuông báo

WorkManager là API Android hiện đại để lập lịch biểu cho các công việc định kỳ ở chế độ nền. WorkManager sẽ dùng JobScheduler mới khi có (SDK 23 trở lên) và AlarmManager cũ khi không có. Để thực hiện các công việc theo lịch trên TV theo các phương pháp hay nhất, hãy làm theo các đề xuất sau:

• Tránh sử dụng các API AlarmManager trên SDK 23 trở lên, đặc biệt là AlarmManager.set(), AlarmManager.setExact() và các phương thức tương tự, vì chúng không cho phép hệ thống quyết định thời điểm thích hợp để chạy các công việc (ví dụ: khi thiết bị đang ở trạng thái chờ).
• Trên các thiết bị có RAM thấp, hãy tránh chạy các tác vụ trừ phi thực sự cần thiết. Nếu cần, hãy chỉ dùng WorkManager WorkRequest để cập nhật đề xuất sau khi phát và cố gắng thực hiện việc này khi ứng dụng vẫn đang mở.

• Xác định Constraints WorkManager để hệ thống chạy các công việc của bạn khi thời gian thích hợp:

Constraints.Builder()
    .setRequiredNetworkType(NetworkType.CONNECTED)
    .setRequiresStorageNotLow(true)
    .setRequiresDeviceIdle(true)
    .build()

Constraints.Builder()
    .setRequiredNetworkType(NetworkType.CONNECTED)
    .setRequiresStorageNotLow(true)
    .setRequiresDeviceIdle(true)
    .build()

• Nếu bạn phải chạy các công việc thường xuyên (ví dụ: để cập nhật Xem tiếp dựa trên hoạt động xem nội dung của người dùng trong ứng dụng trên một thiết bị khác), hãy giảm mức sử dụng bộ nhớ bằng cách giữ mức tiêu thụ bộ nhớ của công việc dưới 30 MB.

Những lưu ý chung về bộ nhớ

Các nguyên tắc sau đây cung cấp thông tin chung về việc phát triển ứng dụng Android:

• Giảm thiểu việc phân bổ đối tượng, tối ưu hoá việc sử dụng lại đối tượng và huỷ phân bổ mọi đối tượng không dùng đến một cách nhanh chóng.
  • Không giữ thông tin tham chiếu đến các đối tượng, đặc biệt là bitmap.
  • Tránh sử dụng System.gc() và các lệnh gọi bộ nhớ phát hành trực tiếp vì chúng can thiệp vào quy trình xử lý bộ nhớ của hệ thống: Ví dụ: trong các thiết bị sử dụng zRAM, một lệnh gọi bắt buộc đến gc() có thể tạm thời tăng mức sử dụng bộ nhớ do quá trình nén và giải nén bộ nhớ.
  • Sử dụng LazyList như minh hoạ trong trình duyệt danh mục trong Compose hoặc RecyclerView trong bộ công cụ giao diện người dùng Leanback (hiện không được dùng nữa) để sử dụng lại các khung hiển thị và không tạo lại các phần tử danh sách.
  • Lưu vào bộ nhớ đệm cục bộ các phần tử được đọc từ những trình cung cấp nội dung bên ngoài không có khả năng thay đổi và xác định khoảng thời gian cập nhật để ngăn việc phân bổ thêm bộ nhớ ngoài.
• Kiểm tra xem có thể xảy ra tình trạng rò rỉ bộ nhớ hay không.
  • Lưu ý các trường hợp rò rỉ bộ nhớ điển hình, chẳng hạn như các tham chiếu bên trong các luồng ẩn danh, việc phân bổ lại các vùng đệm video không bao giờ được phát hành và các tình huống tương tự khác.
  • Sử dụng tệp báo lỗi để gỡ lỗi rò rỉ bộ nhớ.
• Tạo hồ sơ cơ sở để giảm thiểu lượng quy trình biên dịch tức thì cần thiết khi thực thi ứng dụng của bạn từ trạng thái khởi động nguội.

Tìm hiểu về tính năng thu hồi bộ nhớ trực tiếp

Khi một ứng dụng Android TV yêu cầu bộ nhớ và hệ thống đang chịu áp lực, hạt nhân Linux (nền tảng của Android) có thể phải sử dụng tính năng thu hồi bộ nhớ trực tiếp.

Quy trình này bao gồm tạm dừng hoàn toàn mọi luồng phân bổ để chờ các trang bộ nhớ được giải phóng. Điều này xảy ra khi tính năng giải phóng bộ nhớ ở chế độ nền không thể chủ động duy trì một nhóm bộ nhớ đủ lớn.

Điều này có thể dẫn đến tình trạng tạm dừng hoặc giật đáng chú ý trong trải nghiệm người dùng vì hệ thống tạm dừng phân bổ các luồng cho đến khi có đủ bộ nhớ. Theo nghĩa này, việc phân bổ các luồng không chỉ giới hạn ở các lệnh gọi mã xử lý ứng dụng như malloc(); bộ nhớ cần được phân bổ cho trang trong các trang mã, chẳng hạn.

Tóm tắt về công cụ

• Sử dụng công cụ Trình phân tích bộ nhớ trong Android Studio để kiểm tra mức tiêu thụ bộ nhớ trong quá trình sử dụng.
  • Sử dụng heapdump để kiểm tra việc phân bổ đối tượng và bitmap cụ thể.
  • Sử dụng trình phân tích tài nguyên bộ nhớ gốc để kiểm tra các mức phân bổ không phải Java hoặc Kotlin.
• Sử dụng Android GPU Inspector để kiểm tra việc phân bổ đồ hoạ.