Mức sử dụng bộ nhớ (RSS ẩn danh + không gian hoán đổi) là một chỉ số trong Android vitals, phản ánh mức sử dụng bộ nhớ của ứng dụng.
Bộ nhớ ẩn danh là bộ nhớ không được tệp lưu trữ hỗ trợ, chẳng hạn như các hoạt động phân bổ vùng nhớ và bộ nhớ được phân bổ mmap. Thao tác này ghi lại các hoạt động phân bổ bộ nhớ động của ứng dụng, bao gồm cả vùng nhớ khối xếp Java hoặc Kotlin, các hoạt động phân bổ vùng nhớ khối xếp gốc không được quản lý (nơi dữ liệu pixel Bitmap nằm trên Android 8.0 (cấp độ API 26) trở lên) và các ngăn xếp thực thi luồng. Mặc dù hệ điều hành có thể giảm bộ nhớ được sao lưu bằng tệp khi chịu áp lực, nhưng hệ điều hành không thể giảm bộ nhớ ẩn danh.
Kích thước cài đặt thường trú (RSS) là tổng số trang bộ nhớ (cả được chia sẻ và không được chia sẻ) mà một quy trình sử dụng và được lưu giữ trong RAM vật lý. Một trang được coi là "được chia sẻ" nếu có nhiều quy trình truy cập vào trang đó (chẳng hạn như các ứng dụng truy cập vào cùng một thư viện).
Đối với bộ nhớ ẩn danh, hệ thống có thể ghi các trang vào không gian trao đổi (hoặc zRAM trên Android) khi bộ nhớ chịu áp lực. Hệ thống có thể đọc lại các trang này từ bộ nhớ trao đổi nếu cần.
Nhìn chung, mức sử dụng bộ nhớ (RSS ẩn danh + hoán đổi) là thước đo tổng số trang bộ nhớ của ứng dụng không được một tệp trên bộ nhớ hỗ trợ, bao gồm cả mọi bộ nhớ mà hệ thống cũng đang duy trì trong quá trình hoán đổi. Việc theo dõi RSS ẩn danh + trao đổi đảm bảo bạn thấy được mức sử dụng bộ nhớ thực, không thể loại bỏ của ứng dụng.
Nếu mức sử dụng bộ nhớ của ứng dụng cao, hãy điều tra thêm và khắc phục vấn đề theo hướng dẫn trên trang này.
Xác định mức sử dụng bộ nhớ cao
Android vitals
Android vitals chia sẻ mức sử dụng bộ nhớ của ứng dụng theo các trạng thái quy trình sau đây:
- Nền trước: Quy trình của ứng dụng hiển thị. P99 cao ở đây thường ảnh hưởng đến hiệu suất mà người dùng cảm nhận được (hiện tượng giật hoặc sự cố OOM) và chịu ảnh hưởng lớn của các thành phần hoặc hoạt động trên giao diện người dùng chưa bị loại bỏ.
- Dịch vụ trên nền trước: Ứng dụng đang chạy một dịch vụ trên nền trước. Vì các dịch vụ này được thiết kế cho các tác vụ chạy trong thời gian dài, nên chúng là những ứng cử viên hàng đầu cho các rò rỉ vòng đời tích luỹ làm tăng đuôi P99 một cách mạnh mẽ theo thời gian.
- Nền: Ứng dụng đang chạy một dịch vụ nền hoặc gần đây đã chuyển sang nền nhưng chưa được lưu vào bộ nhớ đệm. Đây là nơi các rò rỉ xử lý dưới nền kết hợp.
- Đã lưu vào bộ nhớ đệm: Ứng dụng đang ở trạng thái lưu vào bộ nhớ đệm. Trạng thái này rất nhạy cảm với áp lực bộ nhớ hệ thống, chẳng hạn như LMK. Vì hệ điều hành có thể tuỳ ý loại bỏ trạng thái quy trình này, nên trạng thái này chỉ được cung cấp cho mục đích gỡ lỗi.
Để hiểu cách các trạng thái quy trình này tương quan với lệnh gọi lại onTrimMemory, hãy tham khảo hướng dẫn về giải phóng bộ nhớ để phản hồi sự kiện.
Android vitals cũng phân tích mức sử dụng bộ nhớ của ứng dụng theo các nhóm RAM. Chỉ số mức sử dụng bộ nhớ được hiển thị dưới dạng dòng thời gian của các giá trị phần trăm hằng ngày, cùng với giá trị hằng ngày gần đây nhất cho phân vị thứ 50 và 90.
Sau khi xác định được mức sử dụng bộ nhớ cơ bản, hãy làm theo hướng dẫn để chẩn đoán và cải thiện tình trạng sử dụng bộ nhớ quá mức.
Xác định lỗi rò rỉ bộ nhớ bằng độ lệch đuôi
Để xác định rò rỉ bộ nhớ, hãy tìm sự khác biệt giữa người dùng điển hình (P50) và người dùng cuối (P90) trong Android vitals. Mặc dù tình trạng phình to tài sản nói chung làm tăng bộ nhớ một cách đồng đều trên tất cả các phân vị, nhưng tình trạng rò rỉ bộ nhớ sẽ tăng lên theo thời gian, làm sai lệch đáng kể dữ liệu ở phần cuối.
Bạn nên so sánh các chỉ số P90 và P99 với đường cơ sở P50 theo tên quy trình. Nếu tỷ lệ P90/P50 vượt quá 3,5 lần, thì có thể là do rò rỉ bộ nhớ trong các phiên kéo dài. Đối với một số trường hợp sử dụng nhất định, tỷ lệ tăng không phải lúc nào cũng cho thấy tình trạng rò rỉ, nhưng bạn nên đánh giá quy trình làm việc cụ thể để xác định xem mức sử dụng bộ nhớ tăng có phải là hành vi dự kiến hay không.
Tài nguyên
Chẩn đoán mức sử dụng bộ nhớ quá mức trên thiết bị
Để bắt đầu chẩn đoán nguồn gốc của tình trạng mức sử dụng bộ nhớ quá mức, bạn có thể ghi lại tệp báo lỗi bằng Ghi lại tệp báo lỗi trong phần cài đặt cho nhà phát triển, Android Studio hoặc Perfetto. Bạn nên bắt đầu bằng cách ghi lại một tệp báo lỗi cục bộ sau khi kiểm thử các hành trình chính của người dùng trong ứng dụng.
Bạn nên kiểm thử những hành trình sau đây của người dùng:
- Chế độ xem web và phiên trình duyệt trong ứng dụng
- Cuộn vô hạn với nhiều nội dung nghe nhìn
- Quy trình tạo và chỉnh sửa thành phần
Để điều tra các rò rỉ bộ nhớ tiềm ẩn, trước tiên, hãy xác định các quy trình tiêu thụ nhiều nhất bằng cách sử dụng bảng Tên quy trình trong trang tổng quan về mức sử dụng bộ nhớ của Android vitals. Tiếp theo, hãy chạy hành trình tương ứng của người dùng trên thiết bị và thu thập các kết xuất heap trên nhiều trạng thái quy trình (hiển thị, dịch vụ trên nền trước và được lưu vào bộ nhớ đệm) để xác minh xem ứng dụng có giải phóng bộ nhớ sau khi chuyển sang chế độ nền hay không.
Nếu đang gỡ lỗi các vấn đề về bộ nhớ bằng Android Studio Profiler, bạn cũng có thể sử dụng chế độ tích hợp LeakCanary để đơn giản hoá quy trình phát hiện rò rỉ và phát hiện bitmap trùng lặp nhằm tối ưu hoá việc sử dụng hình ảnh.
Sau khi thu thập tệp báo lỗi, bạn nên sử dụng Perfetto AI Skills (Các kỹ năng AI của Perfetto) để phân tích tệp báo lỗi và xác định các nguồn có thể dẫn đến mức sử dụng bộ nhớ cao.
Sau đây là ví dụ về nội dung mà các kỹ năng AI có thể phản hồi:
I have completed the analysis of memory leaks and bitmap issues for [app] using the provided Perfetto trace.
Summary of Findings
The investigation identified a critical memory pressure issue caused by massive bitmap retention within the app process.
...
Recommendations for [app]
1. [Library] Image Cache Optimization:
* Review the [Library] caching strategy. Ensure that bitmaps
loaded for animations are released or downsampled when the animation is
not in the foreground.
2. Asset Resolution Audit:
* The 14.7 MB average size suggests full-screen or extremely high-density assets. Audit the [library] files in the native_home component to ensure they are not using unnecessarily large source images.
3. View Lifecycle Management:
* Investigate why 21 [LibraryImage] instances are alive simultaneously. Ensure that views in the bottom
tab are properly detached or their animations are cleared when switching between tabs.
4. Fix Surface Leaks:
* Address the Surface.release failures observed in the logs, as these can lead to both memory leaks and
native resource exhaustion.
Tài nguyên bổ sung để diễn giải kết xuất heap
Các tài nguyên sau đây cung cấp thêm thông tin về cách diễn giải kết xuất heap và gỡ lỗi mức sử dụng bộ nhớ:
- Phân tích thủ công: Sử dụng hướng dẫn về Perfetto Heap Dump Explorer để tìm hiểu cách thao tác và diễn giải hình ảnh trực quan của tệp báo lỗi trong giao diện người dùng Perfetto.
- Phân bổ Java/Kotlin: Đọc bài viết Hình dung về kết xuất heap ART đầu tiên để xem hướng dẫn từng bước về cách phân tích kết xuất heap Android Runtime (ART).
- Native allocations (Phân bổ gốc): Tham khảo tài liệu Perfetto Native Profiling (Lập hồ sơ gốc Perfetto) để tìm hiểu cách thu thập và phân tích hồ sơ bộ nhớ gốc (C/C++).
- Kiểm tra bằng giao diện dòng lệnh (CLI): Sử dụng adb dumpsys meminfo để xem thông tin tổng quan nhanh về mức sử dụng bộ nhớ của ứng dụng trên một thiết bị.
- Phân tích dựa trên AI: Tận dụng Các kỹ năng AI của Perfetto để chạy quy trình phân tích dựa trên LLM nhằm giúp phát hiện tình trạng rò rỉ bộ nhớ và việc phân bổ quá mức trong các dấu vết của bạn.
- Phân tích dựa trên SQL: Sử dụng Perfetto SQL và Kỹ năng phân tích dấu vết để chạy các truy vấn có cấu trúc và tập lệnh chuyên biệt nhằm phân tích dữ liệu dấu vết phức tạp.
Cải thiện mức sử dụng bộ nhớ
Hãy tham khảo các phần này để tìm hiểu thêm về cách cải thiện mức sử dụng bộ nhớ của ứng dụng:
- Giảm kích thước mã và tài nguyên của ứng dụng
- Giám sát mức sử dụng bộ nhớ và bộ nhớ hiện có
- Tạo cấu trúc mã tiết kiệm bộ nhớ hơn
Để biết hướng dẫn chi tiết về cách khắc phục các vấn đề về bộ nhớ, hãy tham khảo hướng dẫn Quản lý bộ nhớ của ứng dụng.