Review Cho biết các instance của ứng dụng này là những process riêng biệt hay thuộc một process
Mẹo về Cho biết những instance của ứng dụng này là những process riêng biệt hay thuộc một process Mới Nhất
Lê Minh Sơn đang tìm kiếm từ khóa Cho biết những instance của ứng dụng này là những process riêng biệt hay thuộc một process được Update vào lúc : 2022-07-23 03:26:02 . Với phương châm chia sẻ Mẹo về trong nội dung bài viết một cách Chi Tiết Mới Nhất. Nếu sau khi tham khảo nội dung bài viết vẫn ko hiểu thì hoàn toàn có thể lại Comment ở cuối bài để Admin lý giải và hướng dẫn lại nha.
Trình phân tích bộ nhớ (Memory Profiler) là một thành phần trong Trình phân tích tài nguyên Android (Android Profiler) giúp bạn xác định những tình trạng rò rỉ và nhồi nhét bộ nhớ hoàn toàn có thể khiến ứng dụng của bạn bị gián đoạn, bị treo và thậm chí gặp sự cố. Tính năng này cho bạn thấy biểu đồ theo thời gian thực về việc mức sử dụng bộ nhớ của ứng dụng đồng thời được cho phép bạn ghi lại tệp báo lỗi, thu thập rác và theo dõi cơ cấu tổ chức phân bổ bộ nhớ.
Nội dung chính- Tại sao bạn nên phân tích bộ nhớ ứng dụngTổng quan về Trình phân tích bộ nhớCách tính bộ nhớXem cơ cấu tổ chức phân bổ bộ nhớCải thiện hiệu suất của ứng dụng trong khi phân tíchXem những lượt tham chiếu đến JNI toàn cụcTrình phân tích bộ nhớ cho mã gốcGhi tệp báo lỗiLưu tệp báo lỗi dưới dạng tệp HPROFNhập tệp báo lỗiPhát hiện rò rỉ trong Trình phân tích bộ nhớKỹ thuật phân tích bộ nhớVideo liên quan
Để mở Trình phân tích bộ nhớ, hãy tuân theo tiến trình sau:
Nhấp vào View (Xem) > Tool Windows (Cửa sổ công cụ) > Profiler (Trình phân tích tài nguyên) (bạn cũng hoàn toàn có thể nhấp vào Profile (Phân tích tài nguyên) trong thanh công cụ). Chọn thiết bị và quy trình ứng dụng mà bạn muốn phân tích trong thanh công cụ Android Profiler (Trình phân tích tài nguyên Android). Nếu bạn đã link thiết bị qua USB nhưng không thấy thiết bị đó trong list, hãy đảm bảo bạn đã bật tính năng gỡ lỗi qua USB. Nhấp vào vị trí bất kỳ trong tiến trình MEMORY (BỘ NHỚ) để mở Memory Profiler (Trình phân tích bộ nhớ).Ngoài ra, bạn hoàn toàn có thể kiểm tra bộ nhớ của ứng dụng qua dòng lệnh bằng dumpsys cũng như xem những sự kiện GC trong logcat.
Tại sao bạn nên phân tích bộ nhớ ứng dụng
Android đáp ứng một môi trường tự nhiên thiên nhiên bộ nhớ được quản lý – khi nhận thấy ứng dụng của bạn không hề sử dụng một số trong những đối tượng, trình thu gom rác (garbage collector) sẽ giải phóng bộ nhớ không dùng đến trở về vùng nhớ khối xếp. Tuy Android liên tục tăng cấp cải tiến cách tìm bộ nhớ không dùng đến, nhưng đến thuở nào điểm nào đó trên mọi phiên bản Android, khối mạng lưới hệ thống sẽ phải tạm dừng mã của bạn trong giây lát. Trong hầu hết trường hợp, bạn sẽ không sở hữu và nhận thấy việc tạm dừng. Tuy nhiên, nếu ứng dụng của bạn phân bổ bộ nhớ nhanh hơn tốc độ khối mạng lưới hệ thống thu thập bộ nhớ, thì ứng dụng của bạn hoàn toàn có thể bị gián đoạn trong khi trình thu gom giải phóng đủ bộ nhớ để đáp ứng mức phân bổ. Tình trạng trễ này hoàn toàn có thể khiến ứng dụng của bạn bỏ qua khung hình cũng như làm chậm khung hình.
Ngay cả khi ứng dụng của bạn không biến thành đình trệ, nếu bị rò rỉ bộ nhớ, thì ứng dụng vẫn hoàn toàn có thể giữ lại bộ nhớ đó trong cả những lúc đang ở chính sách nền. Tình trạng này hoàn toàn có thể làm giảm hiệu suất của cục nhớ còn sót lại trong khối mạng lưới hệ thống do những sự kiện buộc thu thập rác không thiết yếu. Cuối cùng, khối mạng lưới hệ thống buộc phải đóng quy trình ứng dụng để lấy lại bộ nhớ. Sau đó, khi người tiêu dùng trở lại ứng dụng của bạn, ứng dụng phải khởi động lại hoàn toàn.
Để ngăn ngừa những sự cố như vậy, bạn nên sử dụng Trình phân tích bộ nhớ để làm những việc sau:
- Tìm bộ sưu tập phân bổ bộ nhớ không mong ước trong tiến trình hoàn toàn có thể gây ra vấn đề về hiệu suất.
Kết xuất tài liệu của vùng nhớ khối xếp Java để xem những đối tượng nào đang dùng hết bộ nhớ tại thuở nào điểm nào đó. Nhiều tệp báo lỗi trong một khoảng chừng thời gian dài hoàn toàn có thể giúp xác định tình trạng rò rỉ bộ nhớ.
Ghi lại quá trình phân bổ bộ nhớ trong khi người tiêu dùng tương tác theo cách thông thường và theo cách cực đoan để xác định đúng chuẩn nơi mã của bạn đang phân bổ quá nhiều đối tượng trong thuở nào gian ngắn hoặc phân bổ những đối tượng đã bị rò rỉ.
Để biết thông tin về những phương pháp lập trình hoàn toàn có thể làm giảm mức sử dụng bộ nhớ của ứng dụng, hãy tham khảo nội dung Quản lý bộ nhớ của ứng dụng.
Tổng quan về Trình phân tích bộ nhớ
Trong lần đầu mở Trình phân tích bộ nhớ, bạn sẽ thấy tiến trình rõ ràng về mức sử dụng bộ nhớ của ứng dụng cũng như thấy những công cụ để buộc thu gom rác, ghi lại tệp báo lỗi và ghi lại quá trình phân bổ bộ nhớ.
Như thể hiện trong hình 1, chính sách xem mặc định của Trình phân tích bộ nhớ có những mục sau:
Một nút để buộc thực hiện một sự kiện thu gom rác.Một nút để Ghi lại một tệp báo lỗi.
Lưu ý: Nút để ghi lại quá trình phân bổ bộ nhớ chỉ xuất hiện ở bên phải nút tệp báo lỗi khi link với một thiết bị chạy Android 7.1 (API cấp 25) trở xuống.
Một trình đơn thả xuống để chỉ định tần suất trình phân tích tài nguyên ghi lại quá trình phân bổ bộ nhớ. Bạn hoàn toàn có thể chọn tuỳ chọn thích hợp để cải tổ hiệu suất ứng dụng trong khi phân tích. Các nút để phóng to/thu nhỏ tiến trình. Một nút để chuyển tới tài liệu bộ nhớ thực tế. Tiến trình sự kiện đã cho tất cả chúng ta biết trạng thái hoạt động và sinh hoạt giải trí, sự kiện nhập của người tiêu dùng và sự kiện xoay màn hình hiển thị. Tiến trình sử dụng bộ nhớ gồm có:- Một biểu đồ xếp chồng về lượng bộ nhớ mà mỗi khuôn khổ bộ nhớ đang sử dụng, biểu thị bằng trục y ở bên trái và khoá màu ở trên cùng. Một đường đứt nét thể hiện số lượng đối tượng được phân bổ, biểu thị theo trục y ở bên phải. Một hình tượng cho từng sự kiện thu gom rác.
Tuy nhiên, nếu bạn đang sử dụng một thiết bị chạy Android 7.1 trở xuống, thì theo mặc định không phải tài liệu phân tích nào thì cũng xuất hiện. Nếu thấy thông báo cho biết thêm thêm "Advanced profiling is unavailable for the selected process" ("Không thể phân tích nâng cao cho quy trình đã chọn"), bạn cần bật tính năng phân tích nâng cao để xem được những thông tin sau:
- Tiến trình sự kiện
Số lượng đối tượng được phân bổ
Sự kiện thu gom rác
Trên Android 8.0 trở lên, tính năng phân tích nâng cao sẽ luôn bật cho những ứng dụng hoàn toàn có thể gỡ lỗi.
Cách tính bộ nhớ
Các số lượng bạn thấy ở đầu Trình phân tích bộ nhớ (hình 2) được nhờ vào tất cả những trang bộ nhớ riêng tư mà ứng dụng của bạn đã cam kết, theo khối mạng lưới hệ thống Android. Số liệu này sẽ không gồm có những trang được chia sẻ với khối mạng lưới hệ thống hoặc những ứng dụng khác.
Có những khuôn khổ sau trong phần mức sử dụng bộ nhớ:
- Java: Mức sử dụng bộ nhớ của những đối tượng được phân bổ qua mã Java hoặc Kotlin.
Native (Mã gốc): Mức sử dụng bộ nhớ của những đối tượng được phân bổ qua mã C hoặc C++.
Ngay cả lúc không dùng C++ trong ứng dụng, ở đây bạn vẫn hoàn toàn có thể thấy bộ nhớ mà mã gốc dùng (native memory) do khung Android sử dụng loại bộ nhớ này để thay mặt bạn xử lý nhiều thao tác, ví dụ như khi xử lý thành phần hình ảnh hoặc những thành phần đồ hoạ khác (tuy nhiên bạn viết mã bằng Java hoặc Kotlin).
Graphics (Đồ hoạ): Mức sử dụng bộ nhớ cho những hàng đợi bộ đệm đồ hoạ để hiện pixel lên màn hình hiển thị, gồm có cả mặt phẳng GL, kết cấu GL, v.v. (Xin lưu ý rằng đây là bộ nhớ dùng chung với CPU, không phải bộ nhớ GPU chuyên được dùng.)
Stack (Ngăn xếp): Mức sử dụng bộ nhớ của tất cả ngăn xếp gốc và ngăn xếp Java trong ứng dụng của bạn. Số liệu này thường liên quan đến số lượng luồng mà ứng dụng của bạn đang chạy.
Code (Mã gốc): Mức sử dụng bộ nhớ của ứng dụng cho mã gốc và tài nguyên, ví dụ như mã byte dex, mã dex được tối ưu hoá hoặc biên dịch, thư viện .so và phông chữ.
Others (Khác): Mức sử dụng bộ nhớ của ứng dụng mà khối mạng lưới hệ thống không chắc cách phân loại.
Allocated (Đã phân bổ): Số lượng đối tượng Java/Kotlin mà ứng dụng của bạn đã phân bổ. Số liệu này sẽ không tính những đối tượng được phân bổ trong C hoặc C++.
Khi link với một thiết bị chạy Android 7.1 trở xuống, số liệu phân bổ này chỉ khởi đầu tại thời điểm Trình phân tích bộ nhớ link với ứng dụng đang chạy của bạn. Vì vậy, mọi đối tượng được phân bổ trước khi bạn khởi đầu phân tích sẽ không được tính đến. Tuy nhiên, Android 8.0 trở lên có một công cụ phân tích trên thiết bị giúp theo dõi mọi mức phân bổ. Vì vậy, số liệu này luôn thể hiện tổng số đối tượng Java còn tồn đọng trong ứng dụng của bạn trên thiết bị Android 8.0 trở lên.
Khi so sánh với mức sử dụng bộ nhớ qua công cụ Android Monitor (Trình theo dõi Android) trước đó, Trình phân tích bộ nhớ mới sẽ ghi lại bộ nhớ của bạn theo cách khác, vì vậy, trông có vẻ như như mức sử dụng bộ nhớ hiện tại của bạn cao hơn. Trình phân tích bộ nhớ theo dõi một số trong những khuôn khổ tương hỗ update giúp tăng tổng số, nhưng nếu bạn chỉ quan tâm đến bộ nhớ khối xếp Java thì số liệu "Java" sẽ tương đương với giá trị thể hiện trong công cụ trước đây. Mặc dù số liệu Java hoàn toàn có thể không khớp đúng chuẩn với những gì bạn thấy trong Android Monitor (Trình theo dõi Android), nhưng số liệu mới có tính đến tất cả những trang bộ nhớ thực đã được phân bổ cho vùng nhớ khối xếp Java của ứng dụng Tính từ lúc lúc được phát triển nhánh qua Zygote. Vì vậy, số liệu này thể hiện đúng chuẩn mức độ ứng dụng sử dụng bộ nhớ thực.
Lưu ý: Khi sử dụng thiết bị chạy Android 8.0 (API cấp 26) trở lên, Trình phân tích bộ nhớ đôi khi đã và đang cho tất cả chúng ta biết nhầm mức sử dụng bộ nhớ trong ứng dụng (phần thực ra thuộc về công cụ phân tích tài nguyên). Tối đa là 10 MB bộ nhớ được thêm vào cho khoảng chừng 100 nghìn đối tượng Java. Trong một phiên bản IDE sau này, những số này sẽ được lọc ra khỏi tài liệu của bạn.Xem cơ cấu tổ chức phân bổ bộ nhớ
Cơ cấu phân bổ bộ nhớ cho bạn biết tình trạng phân bổ từng đối tượng Java và tham chiếu JNI trong bộ nhớ. Cụ thể, Trình phân tích bộ nhớ hoàn toàn có thể cho bạn thấy những thông tin sau về tình trạng phân bổ đối tượng:
- Loại đối tượng được phân bổ và mức sử dụng của những đối tượng đó.
Dấu vết ngăn xếp của mỗi mức phân bổ, gồm có cả luồng chứa tương ứng.
Khi những đối tượng được giải phóng khỏi bộ nhớ (chỉ khi sử dụng thiết bị chạy Android 8.0 trở lên).
Để ghi lại mức phân bổ cho Java và Kotlin, hãy lựa chọn Record Java / Kotlin allocations (Ghi lại mức phân bổ cho Java/Kotlin), sau đó chọn Record (Ghi). Nếu thiết bị đang chạy Android 8 trở lên, thì giao diện người tiêu dùng của Trình phân tích bộ nhớ sẽ chuyển sang một màn hình hiển thị riêng hiển thị quá trình ghi đang ra mắt. Bạn hoàn toàn có thể tương tác với tiến trình thu nhỏ ở phía trên bản ghi (ví dụ: để thay đổi phạm vi lựa chọn). Để hoàn tất quá trình ghi, hãy lựa chọn hình tượng Stop (Dừng)
.Trên Android 7.1 trở xuống, trình phân tích bộ nhớ sử dụng tính năng ghi quá trình phân bổ cũ, đã cho tất cả chúng ta biết quá trình ghi trên tiến trình cho tới lúc bạn nhấp vào Stop (Dừng).
Sau khi bạn chọn một vùng trên tiến trình (hoặc khi bạn hoàn tất một phiên ghi cho thiết bị chạy Android 7.1 trở xuống), list đối tượng được phân bổ sẽ xuất hiện, được phân nhóm theo tên lớp và sắp xếp theo số lượng vùng nhớ khối xếp.
Lưu ý: Trên Android 7.1 trở xuống, bạn hoàn toàn có thể ghi lại tối đa 65535 lượt phân bổ. Nếu phiên ghi của bạn vượt quá số lượng giới hạn này, thì chỉ 65535 lượt phân bổ mới gần đây nhất mới được lưu vào bản ghi. (Không có số lượng giới hạn thực tế trên Android 8.0 trở lên.)Để kiểm tra bản ghi mức phân bổ, hãy tuân theo tiến trình sau:
Duyệt xem list để tìm những đối tượng có số lượng vùng nhớ khối xếp lớn không bình thường và hoàn toàn có thể bị rò rỉ. Để tìm những lớp đã xác định, hãy nhấp vào tiêu đề cột Class Name (Tên lớp) để sắp xếp theo thứ tự bảng vần âm. Sau đó, hãy nhấp vào một tên lớp. Ngăn Instance View (Chế độ xem thực thể) xuất hiện ở bên phải đã cho tất cả chúng ta biết từng thực thể của lớp đó, như thể hiện trong hình 3.- Ngoài ra, bạn hoàn toàn có thể tìm nhanh những đối tượng bằng phương pháp nhấp vào hình tượng Filter (Bộ lọc) hoặc bằng phương pháp nhấn Control+F (Command+F trên Mac) rồi nhập tên lớp hoặc gói trong trường tìm kiếm. Bạn cũng hoàn toàn có thể tìm kiếm theo tên phương thức nếu chọn Arrange by callstack (Sắp xếp theo ngăn xếp lệnh gọi) trong trình đơn thả xuống. Nếu bạn muốn sử dụng biểu thức chính quy, hãy đánh dấu hộp cạnh bên Regex (Biểu thức chính quy). Đánh dấu vào hộp cạnh bên Match case (Khớp chữ hoa chữ thường) nếu cụm từ tìm kiếm của bạn có phân biệt chữ hoa chữ thường.
Bạn hoàn toàn có thể sử dụng hai trình đơn phía trên list đối tượng được phân bổ để chọn vùng nhớ khối xếp cần kiểm tra cũng như cách sắp xếp tài liệu.
Trong trình đơn bên trái, hãy lựa chọn vùng nhớ khối xếp cần kiểm tra:
- default heap (vùng nhớ khối xếp mặc định): Khi khối mạng lưới hệ thống không riêng gì có định vùng nhớ khối xếp nào.
image heap (vùng nhớ khối xếp hình ảnh): Hình ảnh khởi động của khối mạng lưới hệ thống, chứa những lớp được tải trước trong thời gian khởi động. Mức phân bổ tại đây được đảm bảo sẽ không bao giờ di tán hoặc biến mất.
zygote heap (bộ nhớ khối xếp zygote): Vùng nhớ khối xếp dạng ngầm sao chép (copy-on-write) nơi quy trình ứng dụng được phát triển nhánh qua khối mạng lưới hệ thống Android.
app heap (vùng nhớ khối xếp ứng dụng): Vùng nhớ khối xếp chính nơi ứng dụng của bạn phân bổ bộ nhớ.
JNI heap (vùng nhớ khối xếp JNI): Vùng nhớ khối xếp cho biết thêm thêm nơi phân bổ và giải phóng lượt tham chiếu Giao diện gốc Java (JNI).
Trong trình đơn bên phải, hãy lựa chọn cách sắp xếp những lượt phân bổ:
- Arrange by class (Sắp xếp theo lớp): Nhóm tất cả lượt phân bổ nhờ vào tên lớp. Đây là tuỳ chọn mặc định
Arrange by package (Sắp xếp theo gói): Nhóm tất cả lượt phân bổ nhờ vào tên gói.
Arrange by callstack (Sắp xếp theo ngăn xếp lệnh gọi): Nhóm tất cả lượt phân bổ vào ngăn xếp lệnh gọi tương ứng.
Cải thiện hiệu suất của ứng dụng trong khi phân tích
Để cải tổ hiệu suất của ứng dụng trong quá trình phân tích, trình phân tích bộ nhớ sẽ lấy mẫu những lượt phân bổ bộ nhớ theo định kỳ theo mặc định. Khi thử nghiệm trên thiết bị chạy API cấp 26 trở lên, bạn hoàn toàn có thể thay đổi hành vi này bằng phương pháp sử dụng trình đơn thả xuống Allocation Tracking (Theo dõi quá trình phân bổ). Hiện có những tuỳ chọn sau:
- Full (Đầy đủ): Ghi lại toàn bộ mức phân bổ bộ nhớ cho đối tượng. Đây là hành vi mặc định trong Android Studio 3.2 trở xuống. Nếu có một ứng dụng phân bổ rất nhiều đối tượng, hoàn toàn có thể bạn sẽ quan sát thấy tình trạng ứng dụng bị đình trệ trong quá trình phân tích.
Sample (Lấy mẫu): Lấy mẫu mức phân bổ đối tượng trong bộ nhớ theo chu kỳ luân hồi. Đây là tuỳ chọn mặc định và có ít tác động hơn đến hiệu suất của ứng dụng trong quá trình phân tích. Đối với ứng dụng phân bổ nhiều đối tượng trong một khoảng chừng thời gian ngắn, hoàn toàn có thể bạn vẫn thấy tình trạng ứng dụng bị đình trệ.
Off (Tắt): Ngừng theo dõi quá trình phân bổ bộ nhớ của ứng dụng.
Xem những lượt tham chiếu đến JNI toàn cục
Giao diện gốc Java (Java Native Interface – JNI) là một khung được cho phép mã Java và mã gốc gọi lẫn nhau.
Các lượt tham chiếu JNI được mã gốc quản lý theo cách thủ công. Vì vậy, hoàn toàn có thể có tình trạng những đối tượng Java do mã gốc sử dụng được duy trì hoạt động và sinh hoạt giải trí trong thời gian dài. Có thể không truy cập được một số trong những đối tượng trên vùng nhớ khối xếp Java nếu lượt tham chiếu JNI bị vô hiệu nhưng trước đó chưa thể hiện rõ thao tác xoá. Ngoài ra, hoàn toàn có thể bạn đã sử dụng hết hạn mức tham chiếu JNI toàn cục.
Để khắc phục những vấn đề như vậy, hãy sử dụng chính sách xem JNI heap (vùng nhớ khối xếp JNI) trong Trình phân tích bộ nhớ để duyệt xem tất cả những lượt tham chiếu JNI cục bộ rồi lọc chúng theo loại Java và ngăn xếp lệnh gọi gốc. Với thông tin này, bạn hoàn toàn có thể xem thời điểm cũng như nơi tạo và xoá tham chiếu JNI toàn cục.
Khi ứng dụng của bạn đang chạy, hãy lựa chọn một phần tiến trình mà bạn muốn kiểm tra rồi chọn JNI heap (vùng nhớ khối xếp JNI) trong trình đơn thả xuống phía trên list lớp. Sau đó, bạn hoàn toàn có thể kiểm tra những đối tượng trong vùng nhớ khối xếp như thông thường rồi nhấp đúp vào những đối tượng trong thẻ Allocation Call Stack (Ngăn xếp lệnh gọi phân bổ) để xem nơi những lượt tham chiếu JNI được phân bổ và giải phóng trong mã của bạn, minh hoạ trong hình 4.
Để kiểm tra mức phân bổ bộ nhớ cho mã JNI của ứng dụng, bạn phải triển khai ứng dụng của tớ trên một thiết bị chạy Android 8.0 trở lên.
Để biết thêm thông tin về JNI, hãy xem nội dung những mẹo về JNI.
Trình phân tích bộ nhớ cho mã gốc
Trong Trình phân tích bộ nhớ của Android Studio có một Trình phân tích bộ nhớ cho mã gốc (Native Memory Profiler) cho những ứng dụng được triển khai trên thiết bị thực tế chạy Android 10. Các thiết bị Android 11 hiện được tương hỗ trong bản thử nghiệm Android Studio 4.2.
Trình phân tích bộ nhớ gốc theo dõi quá trình phân bổ/giải phóng những đối tượng trong mã gốc theo một khoảng chừng thời gian rõ ràng rồi đưa ra những thông tin sau:
- Allocations (Phân bổ): Số lượng đối tượng được phân bổ qua malloc() hoặc toán tử new trong khoảng chừng thời gian đã chọn.
Deallocations (Giải phóng): Số lượng đối tượng được giải phóng qua không lấy phí() hoặc toán tử delete trong khoảng chừng thời gian đã chọn.
Allocations Size (Kích thước phân bổ): Kích thước tổng hợp tính bằng byte của mọi lượt phân bổ trong khoảng chừng thời gian đã chọn.
Deallocations Size (Kích thước giải phóng): Kích thước tổng hợp tính bằng byte của mọi mức bộ nhớ đã được giải phóng trong khoảng chừng thời gian đã chọn.
Total Count (Tổng số): Giá trị trong cột Allocations (Phân bổ) trừ đi giá trị trong cột Deallocations (Giải phóng).
Remaining Size: (Kích thước còn sót lại) Giá trị trong cột Allocations Size (Kích thước phân bổ) trừ đi giá trị trong cột Deallocations Size (Kích thước giải phóng).
Để ghi lại những lượt phân bổ mã gốc trên thiết bị chạy Android 10 trở lên, hãy lựa chọn Record native allocations (Ghi mức phân bổ cho mã gốc), sau đó chọn Record (Ghi). Quá trình ghi sẽ tiếp tục cho tới lúc bạn nhấp vào Stop (Dừng)
, sau đó giao diện người tiêu dùng Trình phân tích bộ nhớ sẽ quy đổi sang một màn hình hiển thị riêng đã cho tất cả chúng ta biết bản ghi mã gốc.Trên Android 9 trở xuống, bạn không sử dụng được tuỳ chọn Record native allocations (Ghi mức phân bổ cho mã gốc).
Theo mặc định, Trình phân tích bộ nhớ cho mã gốc sử dụng kích thước mẫu là 32 byte: mọi khi phân bổ được 32 byte bộ nhớ, khối mạng lưới hệ thống thực hiện một lần chụp tổng quan nhanh bộ nhớ. Kích thước mẫu nhỏ hơn giúp việc chụp thông tin tổng quan nhanh xảy ra thường xuyên hơn, mang lại nhiều tài liệu đúng chuẩn hơn về mức sử dụng bộ nhớ. Kích thước mẫu to hơn khiến giảm độ đúng chuẩn của tài liệu, nhưng sẽ tốn ít tài nguyên hơn trên khối mạng lưới hệ thống và cải tổ hiệu suất trong quá trình ghi.
Để thay đổi kích thước mẫu của Trình phân tích bộ nhớ cho mã gốc:
Chọn Run (Chạy) > Edit Configuration (Chỉnh sửa thông số kỹ thuật). Chọn mô-đun ứng dụng của bạn trong ngăn bên trái. Nhấp vào thẻ Profiling (Phân tích), rồi nhập kích thước mẫu trong trường có gắn nhãn Native memory sampling interval (bytes) (Chu kỳ lấy mẫu bộ nhớ mã gốc (byte)). Xây dựng rồi chạy lại ứng dụng của bạn. Lưu ý: Dữ liệu bộ nhớ do Trình phân tích bộ nhớ cho mã gốc đáp ứng khác với tài liệu của trình phân tích bộ nhớ cho vùng nhớ khối xếp Java. Thay vì phân tích cho những đối tượng trên vùng nhớ khối xếp Java, Trình phân tích tài nguyên bộ nhớ cho mã gốc chỉ theo dõi những lượt phân bổ được thực hiện thông qua trình mô phỏng C/C++, gồm có cả những đối tượng JNI gốc.Trình phân tích tài nguyên bộ nhớ cho mã gốc được xây dựng trên heapprofd trong ngăn xếp Perfetto của công cụ phân tích hiệu suất. Để biết thêm thông tin về bên trong Trình phân tích bộ nhớ cho mã gốc, hãy xem tài liệu về heapprofd.
Lưu ý: Kể từ bản phát hành 4.1 đầu tiên của Android Studio, Trình phân tích bộ nhớ cho mã gốc sẽ bị tắt trong quá trình khởi động ứng dụng. Tuỳ chọn này sẽ được bật trong một bản phát hành sắp tới.Để khắc phục vấn đề này, bạn hoàn toàn có thể sử dụng trình phân tích dòng lệnh độc lập Perfetto để ghi lại tài liệu phân tích trong quá trình khởi động.
Ghi tệp báo lỗi
Tệp báo lỗi cho biết thêm thêm những đối tượng trong ứng dụng của bạn đang sử dụng bộ nhớ tại thời điểm bạn thu thập tài liệu cho tệp báo lỗi. Đặc biệt là sau một phiên đăng nhập mở rộng của người tiêu dùng, tệp báo lỗi hoàn toàn có thể giúp xác định tình trạng rò rỉ bộ nhớ bằng phương pháp đã cho tất cả chúng ta biết những đối tượng vẫn còn trong bộ nhớ mà đáng nhẽ tránh việc ở đó nữa.
Sau khi ghi tệp báo lỗi, bạn hoàn toàn có thể xem những thông tin sau:
- Loại đối tượng mà ứng dụng của bạn đã phân bổ cũng như số lượng mỗi loại.
Dung lượng bộ nhớ mà mỗi đối tượng đang sử dụng.
Nơi giữ những lượt tham chiếu đến từng đối tượng trong mã của bạn.
Ngăn xếp lệnh gọi cho nơi đối tượng được phân bổ. (Hiện nay, tệp báo lỗi chỉ ghi ngăn xếp lệnh gọi trên Android 7.1 trở xuống khi bạn ghi tệp báo lỗi trong khi ghi quá trình phân bổ.)
Để ghi tệp báo lỗi, hãy nhấp vào Capture heap dump (Ghi tệp báo lỗi), sau đó chọn Record (Ghi). Trong khi kết xuất vùng nhớ khối xếp, mức sử dụng bộ nhớ Java hoàn toàn có thể tạm thời tăng lên. Hiện tượng này là thông thường vì tệp báo lỗi và ứng dụng của bạn ra mắt trong cùng một quy trình với ứng dụng, đồng thời nên phải có một lượng bộ nhớ để thu thập tài liệu.
Sau khi trình phân tích tài nguyên hoàn tất việc ghi tệp báo lỗi, giao diện người tiêu dùng của Trình phân tích bộ nhớ sẽ quy đổi sang một màn hình hiển thị riêng biệt đã cho tất cả chúng ta biết tệp báo lỗi.
Nếu cần thông tin đúng chuẩn hơn về thời điểm tạo tệp kết xuất, bạn hoàn toàn có thể tạo tệp báo lỗi tại điểm tới hạn trong mã ứng dụng bằng phương pháp gọi dumpHprofData().
Trong list lớp bạn hoàn toàn có thể xem những thông tin sau:
- Allocations (Phân bổ): Số lượt phân bổ trong vùng nhớ khối xếp.
Native Size (Kích thước gốc): Tổng dung tích bộ nhớ gốc mà loại đối tượng này sử dụng (tính bằng byte). Cột này chỉ xuất hiện trên Android 7.0 trở lên.
Bạn sẽ thấy bộ nhớ ở đây cho một số trong những đối tượng được phân bổ trong Java vì Android sử dụng bộ nhớ gốc cho một số trong những lớp khung (ví dụ như Bitmap).
Shallow Size (Kích thước đối tượng): Tổng dung tích bộ nhớ Java mà loại đối tượng này sử dụng (tính bằng byte).
Retained Size (Kích thước giữ lại): Tổng dung tích bộ nhớ được giữ lại do tất cả những thực thể của lớp này (tính bằng byte).
Bạn hoàn toàn có thể sử dụng hai trình đơn phía trên list đối tượng được phân bổ để chọn tệp báo lỗi cần kiểm tra cũng như cách sắp xếp tài liệu.
Trong trình đơn bên trái, hãy lựa chọn vùng nhớ khối xếp cần kiểm tra:
- default heap (vùng nhớ khối xếp mặc định): Khi khối mạng lưới hệ thống không riêng gì có định vùng nhớ khối xếp nào.
app heap (vùng nhớ khối xếp ứng dụng): Vùng nhớ khối xếp chính nơi ứng dụng của bạn phân bổ bộ nhớ.
image heap (vùng nhớ khối xếp hình ảnh): Hình ảnh khởi động của khối mạng lưới hệ thống, chứa những lớp được tải trước trong thời gian khởi động. Mức phân bổ tại đây được đảm bảo sẽ không bao giờ di tán hoặc biến mất.
zygote heap (bộ nhớ khối xếp zygote): Vùng nhớ khối xếp dạng ngầm sao chép (copy-on-write) nơi quy trình ứng dụng được phát triển nhánh qua khối mạng lưới hệ thống Android.
Trong trình đơn bên phải, hãy lựa chọn cách sắp xếp những lượt phân bổ:
- Arrange by class (Sắp xếp theo lớp): Nhóm tất cả lượt phân bổ nhờ vào tên lớp. Đây là tuỳ chọn mặc định
Arrange by package (Sắp xếp theo gói): Nhóm tất cả lượt phân bổ nhờ vào tên gói.
Arrange by callstack (Sắp xếp theo ngăn xếp lệnh gọi): Nhóm tất cả lượt phân bổ vào ngăn xếp lệnh gọi tương ứng. Tuỳ chọn này chỉ hoạt động và sinh hoạt giải trí nếu bạn ghi tệp báo lỗi trong khi ghi quá trình phân bổ. Mặc dù vậy, hoàn toàn có thể có một số trong những đối tượng trong vùng nhớ khối xếp đã được phân bổ trước khi bạn khởi đầu ghi, vì vậy những lượt phân bổ này sẽ xuất hiện trước (liệt kê đơn giản theo tên lớp).
Danh sách này được sắp xếp theo cột Retained Size (Kích thước giữ lại) theo mặc định. Để sắp xếp theo những giá trị trong một cột khác, hãy nhấp vào tiêu đề của cột đó.
Nhấp vào tên lớp để mở hiên chạy cửa số Instance View (Chế độ xem thực thể) ở bên phải (như minh hoạ trong hình 6). Mỗi thực thể được liệt kê lại sở hữu những thông tin sau đây:
- Depth (Chiều sâu): Số bước nhảy ngắn nhất từ gốc GC bất kỳ đến thực thể đã chọn.
Native Size (Kích thước gốc): Kích thước của thực thể này trong bộ nhớ gốc.
Cột này chỉ xuất hiện trên Android 7.0 trở lên.
Shallow Size (Kích thước của đối tượng): Kích thước của thực thể này trong bộ nhớ Java.
Retained Size (Kích thước giữ lại): Kích thước của cục nhớ mà thực thể này chiếm ưu thế (theo sơ đồ ưu thế (dominator tree)).
Để kiểm tra vùng nhớ khối xếp, hãy tuân theo tiến trình sau:
Duyệt xem list để tìm những đối tượng có số lượng vùng nhớ khối xếp lớn không bình thường và hoàn toàn có thể bị rò rỉ. Để tìm những lớp đã xác định, hãy nhấp vào tiêu đề cột Class Name (Tên lớp) để sắp xếp theo thứ tự bảng vần âm. Sau đó, hãy nhấp vào một tên lớp. Ngăn Instance View (Chế độ xem thực thể) xuất hiện ở bên phải đã cho tất cả chúng ta biết từng thực thể của lớp đó, như thể hiện trong hình 6.- Ngoài ra, bạn hoàn toàn có thể tìm nhanh những đối tượng bằng phương pháp nhấp vào hình tượng Filter (Bộ lọc) hoặc bằng phương pháp nhấn Control+F (Command+F trên Mac) rồi nhập tên lớp hoặc gói trong trường tìm kiếm. Bạn cũng hoàn toàn có thể tìm kiếm theo tên phương thức nếu chọn Arrange by callstack (Sắp xếp theo ngăn xếp lệnh gọi) trong trình đơn thả xuống. Nếu bạn muốn sử dụng biểu thức chính quy, hãy đánh dấu hộp cạnh bên Regex (Biểu thức chính quy). Đánh dấu vào hộp cạnh bên Match case (Khớp chữ hoa chữ thường) nếu cụm từ tìm kiếm của bạn có phân biệt chữ hoa chữ thường.
Hoặc nhấp vào mũi tên cạnh bên tên thực thể để xem tất cả trường của thực thể, sau đó nhấp vào tên trường để xem tất cả lượt tham chiếu. Nếu bạn muốn xem thông tin rõ ràng về thực thể cho một trường, hãy nhấp chuột phải vào trường đó rồi chọn Go to Instance (Chuyển đến thực thể).
Trong thẻ References (Tham chiếu), nếu bạn xác định được một tệp đối chiếu hoàn toàn có thể bị rò rỉ bộ nhớ, hãy nhấp chuột phải vào tệp đối chiếu đó rồi chọn Go to Instance (Chuyển đến thực thể). Thao tác này sẽ chọn thực thể tương ứng trong tệp báo lỗi, cho bạn thấy tài liệu về thực thể có trong tệp đó.Trong tệp báo lỗi của bạn, hãy tìm lỗi rò rỉ bộ nhớ do nguyên nhân bất kỳ trong số sau:
- Các lượt tham chiếu kéo dãn đến Activity, Context, View, Drawable và những đối tượng khác hoàn toàn có thể duy trì tham chiếu đến vùng chứa Activity hoặc Context.
Các lớp không tĩnh bên trong (ví dụ như Runnable) hoàn toàn có thể duy trì một thực thể Activity.
Bộ nhớ đệm duy trì những đối tượng lâu hơn mức thiết yếu.
Lưu tệp báo lỗi dưới dạng tệp HPROF
Sau khi ghi lại tệp báo lỗi, bạn chỉ hoàn toàn có thể xem tài liệu trong Trình phân tích bộ nhớ trong khi trình phân tích này đang chạy. Khi thoát khỏi phiên phân tích bạn sẽ mất tệp báo lỗi. Vì vậy, nếu bạn muốn lưu tệp để xem xét sau, hãy xuất tệp báo lỗi sang định dạng HPROF. Trong Android Studio phiên bản 3.1 trở xuống, nút Export capture to file (Xuất bản ghi vào tệp)
nằm ở bên trái thanh công cụ phía dưới tiến trình; trong Android Studio 3.2 trở lên, có một nút Export Heap Dump (Xuất tệp báo lỗi) ở bên phải mỗi mục Heap Dump (Tệp báo lỗi) trong ngăn Sessions (Phiên). Trong hộp thoại Export as (Xuất dưới dạng), hãy lưu theo phần mở rộng tên tệp .hprof.Để sử dụng một trình phân tích HPROF khác (ví dụ như jhat, bạn cần quy đổi tệp HPROF từ định dạng Android sang định dạng Java SE HPROF. Bạn hoàn toàn có thể thực hiện việc này bằng công cụ hprof-conv có trong thư mục android_sdk/platform-tools/. Chạy lệnh hprof-conv với hai đối số: tệp HPROF ban đầu và vị trí để viết tệp HPROF đã quy đổi. Ví dụ:
hprof-conv heap-original.hprof heap-converted.hprofNhập tệp báo lỗi
Để nhập tệp HPROF (.hprof), hãy nhấp vào hình tượng Start a new profiling session (Bắt đầu một phiên phân tích mới)
trong ngăn Session (Phiên), chọn Load from file (Tải qua tệp) rồi chọn tệp trên trình duyệt tệp.Bạn cũng hoàn toàn có thể nhập tệp HPROF bằng phương pháp kéo tệp từ trình duyệt tệp vào hiên chạy cửa số trình sửa đổi.
Phát hiện rò rỉ trong Trình phân tích bộ nhớ
Khi phân tích một tệp báo lỗi trong Trình phân tích bộ nhớ, bạn hoàn toàn có thể lọc tài liệu phân tích mà Android Studio nhận định rằng hoàn toàn có thể chỉ báo lỗi rò rỉ bộ nhớ cho những thực thể Activity và Fragment trong ứng dụng của bạn.
Bộ lọc này đã cho tất cả chúng ta biết những loại tài liệu sau đây:
- Các thực thể Activity đã bị huỷ bỏ nhưng vẫn đang được tham chiếu.
Các thực thể Fragment không còn FragmentManager hợp lệ nhưng vẫn
đang được tham chiếu.
Trong một số trong những trường hợp, ví dụ như sau, bộ lọc hoàn toàn có thể tạo ra những kết quả dương tính giả:
- Fragment được tạo nhưng không được sử dụng.
Fragment đang được lưu vào bộ nhớ đệm nhưng không thuộc FragmentTransaction.
Để sử dụng tính năng này, trước tiên, hãy ghi lại tệp báo lỗi hoặc nhập tệp báo lỗi vào Android Studio. Để xem những phân đoạn và hoạt động và sinh hoạt giải trí hoàn toàn có thể bị rò rỉ bộ nhớ, hãy đánh dấu vào hộp Activity/Fragment Leaks (Rò rỉ phân mảnh/hoạt động và sinh hoạt giải trí) trong ngăn tệp báo lỗi của Trình phân tích bộ nhớ, như minh hoạ trong hình 7.
Kỹ thuật phân tích bộ nhớ
Trong khi sử dụng Trình phân tích bộ nhớ, bạn nên tạo áp lực cho mã nguồn ứng dụng và buộc rò rỉ bộ nhớ. Có một phương pháp để tìm ra lỗi rò rỉ bộ nhớ trong ứng dụng là cho ứng dụng chạy một lúc trước khi kiểm tra vùng nhớ khối xếp. Các lỗi rò rỉ hoàn toàn có thể dần lộ ra trên quá trình phân bổ trong vùng nhớ khối xếp. Tuy nhiên, rò rỉ càng ít thì bạn cần chạy ứng dụng càng lâu để thấy được nơi rò rỉ.
Bạn cũng hoàn toàn có thể kích hoạt sự cố rò rỉ bộ nhớ theo một trong những phương pháp sau:
- Liên tục xoay thiết bị từ chính sách dọc sang chính sách ngang rồi ngược lại trong khi ở nhiều trạng thái hoạt động và sinh hoạt giải trí. Việc xoay thiết bị thường hoàn toàn có thể khiến ứng dụng rò rỉ đối tượng Activity, Context hoặc View do khối mạng lưới hệ thống tái tạo Activity và nếu ứng dụng của bạn tham chiếu đến một trong những đối tượng đó ở nơi khác, thì khối mạng lưới hệ thống không thu thập được rác của đối tượng đó.
Chuyển đổi giữa ứng dụng của bạn với một ứng dụng khác khi ở nhiều trạng thái hoạt động và sinh hoạt giải trí (chuyển đến Màn hình chính, sau đó quay lại ứng dụng của bạn).
Mẹo: Bạn cũng hoàn toàn có thể thực hiện tiến trình trên bằng phương pháp sử dụng khung kiểm thử monkeyrunner.
Post a Comment