Tổng quan về cách đo lường hiệu suất của ứng dụng

Tài liệu này giúp bạn xác định và khắc phục các vấn đề chính về hiệu suất của ứng dụng.

Các vấn đề chính về hiệu suất

Có nhiều vấn đề có thể góp phần gây ra hiệu suất kém trong một ứng dụng. Tuy nhiên, bạn nên lưu ý một số vấn đề thường gặp sau đây trong ứng dụng của mình:

Độ trễ khi khởi động

Độ trễ khi khởi động là khoảng thời gian cần thiết kể từ khi người dùng nhấn vào biểu tượng ứng dụng, thông báo hoặc điểm vào khác đến khi dữ liệu của người dùng hiện trên màn hình.

Hãy cố gắng đạt được các mục tiêu khởi động sau trong ứng dụng của bạn:

  • Khởi động nguội trong vòng chưa đầy 500 mili giây. Quá trình khởi động nguội xảy ra khi ứng dụng đang khởi chạy không có trong bộ nhớ của hệ thống. Hiện tượng này xảy ra khi đây là lần đầu tiên ứng dụng chạy kể từ khi khởi động lại hoặc kể từ khi người dùng/hệ thống buộc dừng quy trình của ứng dụng.

    Ngược lại, quá trình khởi động ấm xảy ra khi ứng dụng đã chạy trong nền. Quá trình khởi động nguội yêu cầu hệ thống phải xử lý nhiều việc nhất, vì hệ thống phải tải mọi thứ từ bộ nhớ và khởi động ứng dụng. Hãy cố gắng làm cho thời gian khởi động nguội chỉ mất tối đa 500 mili giây.

  • Các độ trễ P95 và P99 rất gần với độ trễ trung bình. Khi mất quá nhiều thời gian để khởi động, ứng dụng sẽ mang lại trải nghiệm khó chịu cho người dùng. Hoạt động giao tiếp liên quy trình (IPC) và I/O không cần thiết trong quá trình quan trọng khi khởi động ứng dụng có thể gặp phải tình trạng cạnh tranh khoá và dẫn đến sự không nhất quán.

Giật trong khi cuộn

Giật là thuật ngữ mô tả tình trạng hình ảnh bị giật khi hệ thống không thể xây dựng và cung cấp các khung hình kịp thời để vẽ chúng lên màn hình ở tần số 60 Hz trở lên. Hiện tượng giật thể hiện rõ nhất lúc cuộn, khi luồng ảnh động không chạy trơn tru mà lại có tình trạng giật. Hiện tượng giật xuất hiện khi chuyển động tạm dừng trong một hoặc nhiều khung hình, vì ứng dụng mất nhiều thời gian hơn để hiển thị nội dung so với thời lượng của một khung hình trên hệ thống.

Ứng dụng phải nhắm đến tốc độ làm mới 90 Hz. Tốc độ kết xuất thông thường là 60 Hz, nhưng nhiều thiết bị mới hoạt động ở chế độ 90 Hz trong các hoạt động tương tác của người dùng, chẳng hạn như cuộn. Một số thiết bị hỗ trợ tốc độ thậm chí còn cao hơn, lên tới 120 Hz.

Để xem tốc độ làm mới mà một thiết bị đang sử dụng tại một thời điểm nhất định, hãy bật lớp phủ bằng cách sử dụng Tuỳ chọn cho nhà phát triển > Hiện tốc độ làm mới trong phần Gỡ lỗi.

Quá trình chuyển đổi không suôn sẻ

Vấn đề này rất dễ thấy trong các hoạt động tương tác như chuyển đổi giữa các thẻ hoặc tải một hoạt động mới. Các loại chuyển đổi này phải mượt mà và không có độ trễ hoặc hình ảnh nhấp nháy.

Sử dụng pin không hiệu quả

Tất nhiên làm việc sẽ tốn pin, nhưng thực hiện những tác vụ không cần thiết lại cũng làm giảm thời lượng pin.

Việc phân bổ bộ nhớ (từ việc tạo các đối tượng mới trong mã) có thể là nguyên nhân khiến hệ thống phải thực hiện khối lượng công việc lớn. Bởi vì không chỉ có việc phân bổ yêu cầu chạy Android Runtime (ART), mà việc giải phóng các đối tượng đó sau này (gom rác) cũng đòi hỏi thời gian và công sức. Cả quá trình phân bổ và thu gom đều nhanh và hiệu quả hơn nhiều, đặc biệt là với các đối tượng tạm thời. Mặc dù trước đây phương pháp hay nhất là tránh phân bổ các đối tượng bất cứ khi nào có thể, nhưng bạn nên làm điều phù hợp nhất với ứng dụng và kiến trúc của mình. Dựa trên khả năng của ART, phương pháp hay nhất là tiết kiệm được các mức phân bổ trước nguy cơ mã không thể duy trì.

Tuy nhiên, việc này đòi hỏi nhiều công sức, vì vậy, hãy lưu ý rằng nó có thể ảnh hưởng đến hiệu suất nếu bạn đang phân bổ nhiều đối tượng trong vòng lặp nội bộ.

Xác định vấn đề

Chúng tôi đề xuất quy trình công việc sau đây để xác định và khắc phục các vấn đề về hiệu suất:

  1. Xác định và kiểm tra các hành trình trọng yếu sau đây của người dùng:
    • Các quy trình khởi động phổ biến, bao gồm cả từ trình chạy và thông báo.
    • Màn hình mà người dùng cuộn xem dữ liệu.
    • Chuyển đổi giữa các màn hình.
    • Các quy trình chạy lâu dài, chẳng hạn như điều hướng hoặc phát nhạc.
  2. Kiểm tra xem điều gì đang xảy ra trong các quy trình trước đó bằng các công cụ gỡ lỗi sau:
    • Perfetto: cho phép bạn xem điều gì đang diễn ra trên toàn bộ thiết bị nhờ dữ liệu thời gian chính xác.
    • Trình phân tích bộ nhớ: cho phép bạn xem quá trình phân bổ bộ nhớ đang diễn ra trên vùng nhớ khối xếp.
    • Simpleperf: hiển thị biểu đồ về các lệnh gọi hàm đang sử dụng nhiều CPU nhất trong một khoảng thời gian nhất định. Khi bạn xác định được tác vụ nào đang chạy nhiều thời gian trong Systrace, nhưng không biết lý do tại sao, Simpleperf có thể cung cấp thêm thông tin.

Để hiểu và gỡ lỗi các vấn đề về hiệu suất này, bạn cần phải tự mình gỡ lỗi từng lần chạy kiểm thử. Bạn không thể thay thế các bước trước đó bằng cách phân tích dữ liệu tổng hợp. Tuy nhiên, để hiểu rõ những gì người dùng thực sự nhìn thấy và xác định thời điểm sự hồi quy có thể xảy ra, điều quan trọng là bạn phải thiết lập tính năng thu thập chỉ số trong quy trình kiểm thử tự động và trong trường:

  • Quy trình khởi động
  • Giật
    • Chỉ số trường
      • Các chỉ số khung của Play Console: trong Play Console, bạn không thể thu hẹp các chỉ số cho một hành trình cụ thể của người dùng. Loại chỉ số này chỉ báo cáo tình trạng giật tổng thể trong toàn bộ ứng dụng.
      • Đo lường tuỳ chỉnh bằng FrameMetricsAggregator: bạn có thể sử dụng FrameMetricsAggregator để ghi lại các chỉ số độ giật trong một quy trình công việc cụ thể.
    • Phòng thử nghiệm
      • Cuộn bằng Macrobenchmark.
      • Macrobenchmark thu thập thời gian kết xuất khung hình bằng cách sử dụng các lệnh dumpsys gfxinfo để đóng một hành trình của người dùng. Đây là một cách để tìm hiểu về sự thay đổi độ giật trong một hành trình cụ thể của người dùng. Chỉ số RenderTime (nêu rõ khoảng thời gian cần thiết để vẽ các khung hình) có ý nghĩa quan trọng hơn số lượng khung hình bị giật trong việc xác định sự hồi quy hay cải thiện.

Đường liên kết ứng dụng là các đường liên kết sâu dựa trên URL của trang web đã được xác minh thuộc trang web của bạn. Sau đây là những lý do có thể khiến quá trình xác minh Đường liên kết ứng dụng không thành công.

  • Phạm vi bộ lọc ý định: chỉ thêm autoVerify vào bộ lọc ý định cho các URL mà ứng dụng của bạn có thể phản hồi.
  • Chuyển đổi giao thức chưa được xác minh: các lệnh chuyển hướng phía máy chủ và miền con chưa được xác minh được xem là rủi ro bảo mật và không xác minh được. Chúng khiến mọi đường liên kết autoVerify bị lỗi. Ví dụ: việc chuyển hướng các đường liên kết từ HTTP sang HTTPS, chẳng hạn như example.com sang www.example.com mà không xác minh các đường liên kết HTTPS có thể khiến xác minh không thành công. Hãy nhớ xác minh Đường liên kết ứng dụng bằng cách thêm bộ lọc ý định.
  • Đường liên kết không thể xác minh: việc thêm đường liên kết không thể xác minh cho mục đích thử nghiệm có thể khiến hệ thống không xác minh Đường liên kết ứng dụng cho ứng dụng của bạn.
  • Máy chủ không đáng tin cậy: đảm bảo máy chủ có thể kết nối với các ứng dụng khách của bạn.

Thiết lập ứng dụng để phân tích hiệu suất

Bạn cần phải thiết lập đúng cách để có được các điểm chuẩn chính xác, có thể lặp lại và hữu ích từ một ứng dụng. Hãy kiểm thử trên một hệ thống gần với bản phát hành công khai nhất có thể, đồng thời loại bỏ các nguồn gây nhiễu. Trong các phần sau, bạn có thể thực hiện một số bước cụ thể tuỳ theo APK và hệ thống để chuẩn bị thiết lập việc kiểm thử, trong đó một số bước có thể thay đổi tuỳ từng trường hợp sử dụng.

Các điểm theo dõi

Các ứng dụng có thể đo lường mã của chúng bằng các sự kiện theo dõi tuỳ chỉnh.

Mặc dù đang thu thập dấu vết, nhưng tính năng theo dõi có mức hao tổn nhỏ (khoảng 5μ mỗi phần), vì vậy, đừng sử dụng tính năng này cho mọi phương thức. Việc theo dõi các phần công việc lớn hơn 0,1 mili giây có thể cung cấp thông tin chi tiết đáng kể về các điểm tắc nghẽn.

Những điểm cần lưu ý về APK

Các biến thể gỡ lỗi có thể hữu ích cho việc khắc phục sự cố và thay thế các biểu tượng mẫu ngăn xếp. Tuy nhiên, các biến thể đó có ảnh hưởng nghiêm trọng đến hiệu suất. Các thiết bị chạy Android 10 (API cấp 29) trở lên có thể sử dụng profileable android:shell="true" trong tệp kê khai để cho phép lập hồ sơ trong các bản phát hành.

Sử dụng cấu hình rút gọn mã ở cấp phát hành công khai. Tuỳ thuộc vào tài nguyên mà ứng dụng của bạn dùng, việc này có thể có tác động đáng kể đến hiệu suất. Một số cấu hình ProGuard xoá các điểm theo dõi, vì vậy, hãy cân nhắc xoá các quy tắc đó cho cấu hình mà bạn đang chạy chương trình kiểm thử.

Biên dịch

Biên dịch ứng dụng của bạn trên thiết bị sang một trạng thái đã biết, thường là speed hoặc speed-profile. Hoạt động đúng thời điểm (JIT) ở chế độ nền có thể gây ra mức hao tổn hiệu suất đáng kể. Bạn sẽ thường xuyên đạt đến mức này nếu đang cài đặt lại APK giữa các lần chạy kiểm thử. Sau đây là lệnh để thực hiện việc này:

adb shell cmd package compile -m speed -f com.google.packagename

Chế độ biên dịch speed sẽ biên dịch ứng dụng hoàn toàn. Chế độ speed-profile biên dịch ứng dụng theo hồ sơ của các đường dẫn mã đã sử dụng được thu thập trong quá trình sử dụng ứng dụng. Có thể bạn sẽ khó thu thập được hồ sơ một cách chính xác và nhất quán. Vì vậy, nếu quyết định sử dụng hồ sơ, hãy xác nhận rằng các hồ sơ đó đang thu thập những dữ liệu bạn muốn. Các hồ sơ này nằm ở vị trí sau:

/data/misc/profiles/ref/[package-name]/primary.prof

Macrobenchmark cho phép bạn trực tiếp chỉ định chế độ biên dịch.

Những điểm cần lưu ý về hệ thống

Để đo lường độ chân thực cao và thấp, hãy điều chỉnh thiết bị của bạn. Chạy quy trình so sánh A/B trên cùng một thiết bị và cùng một phiên bản hệ điều hành. Hiệu suất có thể thay đổi đáng kể, thậm chí ngay trên cùng một loại thiết bị.

Trên các thiết bị đã bị can thiệp hệ thống, hãy cân nhắc sử dụng tập lệnh lockClocks cho Microbenchmark. Ngoài ra, các tập lệnh này thực hiện những việc sau:

  • Đặt CPU ở tần suất cố định.
  • Vô hiệu hoá các lõi nhỏ và định cấu hình GPU.
  • Tắt chế độ điều tiết nhiệt.

Bạn không nên sử dụng tập lệnh lockClocks cho các hoạt động kiểm thử tập trung vào trải nghiệm người dùng, chẳng hạn như khởi chạy ứng dụng, kiểm thử DoU và kiểm thử độ giật. Tuy nhiên, tập lệnh này có thể cần thiết để giảm độ nhiễu trong các hoạt động kiểm thử Microbenchmark.

Nếu có thể, hãy cân nhắc sử dụng một khung thử nghiệm như Macrobenchmark để có thể giảm độ nhiễu trong hoạt động đo lường và ngăn tình trạng đo lường không chính xác.

Khởi động ứng dụng chậm: hoạt động đàn hồi không cần thiết

Một hoạt động đàn hồi có thể kéo dài thời gian khởi động ứng dụng theo cách không cần thiết. Điều quan trọng là bạn phải biết ứng dụng của mình có đang chạy như vậy hay không. Như minh hoạ trong dấu vết mẫu sau, một activityStart đứng ngay trước một activityStart khác mà không có bất kỳ khung nào do hoạt động đầu tiên vẽ.

alt_text Hình 1. Dấu vết cho thấy hoạt động đàn hồi.

Điều này có thể xảy ra cả ở điểm truy cập thông báo và điểm truy cập khởi động ứng dụng thông thường. Bạn thường có thể giải quyết vấn đề này bằng cách tái cấu trúc. Ví dụ: nếu bạn đang sử dụng hoạt động này để thực hiện việc thiết lập trước khi chạy một hoạt động khác, hãy đưa mã này vào một thành phần hoặc thư viện có thể tái sử dụng.

Các trường hợp phân bổ không cần thiết sẽ kích hoạt GC thường xuyên

Bạn có thể thấy hoạt động thu gom rác (GC) diễn ra thường xuyên hơn dự kiến trong Systrace.

Trong ví dụ sau, cứ 10 giây trong một hoạt động kéo dài, sẽ có một chỉ báo xuất hiện cho biết ứng dụng có thể đang phân bổ một cách không cần thiết nhưng nhất quán theo thời gian:

alt_text Hình 2. Dấu vết cho thấy có khoảng cách giữa các sự kiện GC.

Bạn cũng có thể nhận thấy rằng một ngăn xếp lệnh gọi cụ thể đang thực hiện phần lớn quá trình phân bổ khi sử dụng Trình phân tích bộ nhớ. Bạn không cần phải buộc loại bỏ tất cả tuỳ chọn phân bổ, vì điều này có thể khiến mã khó duy trì hơn. Thay vào đó, hãy bắt đầu bằng cách xử lý các điểm phân bổ.

Khung hình bị giật

Quy trình đồ hoạ tương đối phức tạp và có thể xảy ra một số vấn đề trong việc xác định xem liệu người dùng có thấy khung hình bị bỏ qua hay không. Trong một số trường hợp, nền tảng có thể "giải cứu" khung hình bằng cách sử dụng bộ đệm. Tuy nhiên, bạn có thể bỏ qua hầu hết các vấn đề đó để dễ dàng xác định khung hình có vấn đề từ chính ứng dụng của bạn.

Khi khung hình đang được vẽ và khối lượng công việc đòi hỏi từ ứng dụng không nhiều, điểm truy vết Choreographer.doFrame() xảy ra theo tần suất 16,7 mili giây trên thiết bị 60 khung hình/giây:

alt_text Hình 3. Một dấu vết cho thấy các khung hình nhanh thường xuyên xuất hiện.

Nếu bạn thu nhỏ và điều hướng xem qua dấu vết, đôi khi bạn sẽ thấy một số khung hình mất nhiều thời gian hơn để hoàn thành, nhưng vẫn có thể chấp nhận được vì không quá thời gian 16,7 mili giây đã được phân bổ:

alt_text Hình 4. Dấu vết cho thấy các khung hình nhanh, thường xuyên xảy ra cụm công việc định kỳ.

Khi bạn thấy có sự gián đoạn ở tần suất thông thường này, thì đó là hiện tượng khung hình bị giật như minh hoạ trong Hình 5:

alt_text Hình 5. Dấu vết cho thấy một khung hình bị giật.

Bạn có thể thực hành xác định những khung hình này.

alt_text Hình 6. Một dấu vết cho thấy nhiều khung hình bị giật hơn.

Trong một số trường hợp, bạn cần phóng to một điểm theo dõi để biết thêm thông tin về khung hiển thị nào đang được tăng cường hoặc hoạt động của RecyclerView. Trong các trường hợp khác, bạn có thể cần phải kiểm tra thêm.

Để biết thêm thông tin về cách xác định khung hình bị giật và cách gỡ lỗi, hãy xem phần Kết xuất chậm.

Các lỗi thường gặp về RecyclerView

Việc vô hiệu hoá toàn bộ dữ liệu sao lưu của RecyclerView một cách không cần thiết có thể dẫn đến thời gian kết xuất khung hình dài và hiện tượng giật. Để giảm thiểu số lượng khung hiển thị cần cập nhật, bạn chỉ nên vô hiệu hoá những dữ liệu thay đổi.

Hãy xem phần Trình bày dữ liệu động để biết các cách tránh các lệnh gọi notifyDatasetChanged() tốn kém vì những lệnh này khiến nội dung cập nhật thay vì thay thế hoàn toàn nội dung.

Nếu bạn không hỗ trợ đúng cách cho mọi RecyclerView được lồng, thì việc này có thể khiến RecyclerView nội bộ luôn được tạo lại hoàn toàn. Mọi RecyclerView bên trong được lồng phải có một RecycledViewPool được thiết lập để giúp đảm bảo có thể sử dụng lại các thành phần hiển thị giữa mọi RecyclerView bên trong.

Việc không tìm nạp trước đủ dữ liệu hoặc không tìm nạp trước kịp thời có thể gây khó chịu trong quá trình người dùng truy cập đến cuối danh sách cuộn, vì người dùng phải đợi thêm dữ liệu từ máy chủ. Mặc dù về mặt kỹ thuật thì đây không phải là hiện tượng giật vì không quá thời hạn kết xuất khung hình, nhưng bạn có thể cải thiện đáng kể trải nghiệm người dùng bằng cách sửa đổi thời gian và số lượng tìm nạp trước để người dùng không phải chờ dữ liệu của chúng tôi.

Gỡ lỗi ứng dụng

Sau đây là các phương thức gỡ lỗi về hiệu suất của ứng dụng. Hãy xem video sau đây để biết thông tin tổng quan về tính năng theo dõi hệ thống và cách sử dụng trình phân tích tài nguyên trên Android Studio.

Gỡ lỗi khởi động ứng dụng bằng Systrace

Bạn có thể xem Thời gian khởi động ứng dụng để biết thông tin tổng quan về quy trình khởi động ứng dụng và xem video sau đây để biết thông tin tổng quan về tính năng theo dõi hệ thống.

Bạn có thể phân biệt các loại hình khởi động qua các giai đoạn sau:

  • Khởi động nguội: bắt đầu khi tạo một quy trình mới chưa có trạng thái được lưu.
  • Khởi động ấm: tạo lại hoạt động trong khi sử dụng lại quy trình hoặc tạo lại quy trình với trạng thái đã lưu.
  • Khởi động nóng: khởi động lại hoạt động và bắt đầu khi tăng cường.

Bạn nên thu thập Systrace bằng ứng dụng Theo dõi hệ thống trên thiết bị. Đối với Android 10 trở lên, hãy sử dụng Perfetto. Đối với Android 9 trở xuống, hãy sử dụng Systrace. Bạn cũng nên xem các tệp theo dõi bằng trình xem dấu vết Perfetto dựa trên nền tảng web. Để biết thêm thông tin, hãy xem bài viết Tổng quan về tính năng theo dõi hệ thống.

Một số điều cần lưu ý bao gồm:

  • Giám sát tranh chấp: việc cạnh tranh các tài nguyên được bảo vệ bằng màn hình có thể làm quá trình khởi động ứng dụng bị chậm trễ đáng kể.

  • Giao dịch liên kết đồng bộ: tìm các giao dịch không cần thiết trong đường dẫn quan trọng của ứng dụng. Nếu một giao dịch cần thiết có chi phí cao, hãy cân nhắc làm việc với nhóm nền tảng liên kết để cải thiện.

  • GC đồng thời: đây là trường hợp phổ biến và có tác động tương đối thấp, nhưng nếu bạn thường xuyên gặp phải, hãy cân nhắc xem xét vấn đề này bằng trình phân tích bộ nhớ của Android Studio.

  • I/O: kiểm tra I/O được thực hiện trong quá trình khởi động và tìm các ô dài.

  • Hoạt động quan trọng trên các luồng khác: những luồng này có thể ảnh hưởng đến luồng giao diện người dùng, vì vậy, hãy chú ý đến thao tác ở chế độ nền trong quá trình khởi động.

Từ góc độ của ứng dụng, bạn nên gọi reportFullyDrawn khi quá trình khởi động hoàn tất để cải thiện báo cáo chỉ số khởi động ứng dụng. Hãy xem phần Thời gian hiển thị đầy đủ để biết thêm thông tin về cách sử dụng reportFullyDrawn. Bạn có thể trích xuất thời gian bắt đầu do RFD xác định thông qua bộ xử lý theo dõi Perfetto và phát một sự kiện theo dõi mà người dùng có thể nhìn thấy.

Sử dụng tính năng Theo dõi hệ thống trên thiết bị

Bạn có thể sử dụng ứng dụng cấp hệ thống có tên là Theo dõi hệ thống để ghi lại dấu vết hệ thống trên thiết bị. Ứng dụng này cho phép bạn ghi lại dấu vết từ thiết bị mà không cần cắm thiết bị vào hoặc kết nối thiết bị với adb.

Sử dụng Trình phân tích bộ nhớ trong Android Studio

Bạn có thể sử dụng Trình phân tích bộ nhớ của Android Studio để kiểm tra áp lực bộ nhớ có thể do rò rỉ bộ nhớ hoặc thói quen sử dụng không hợp lệ. Công cụ này cung cấp chế độ xem trực tiếp các quá trình phân bổ đối tượng.

Bạn có thể khắc phục các sự cố về bộ nhớ trong ứng dụng bằng cách theo dõi thông tin trong quá trình sử dụng Trình phân tích bộ nhớ để theo dõi lý do và tần suất xảy ra GC.

Để phân tích bộ nhớ ứng dụng, hãy thực hiện các bước sau:

  1. Phát hiện vấn đề về bộ nhớ.

    Ghi lại phiên phân tích bộ nhớ trong hành trình của người dùng mà bạn muốn tập trung vào. Tìm số lượng đối tượng ngày càng tăng, như minh hoạ trong hình 7, mà cuối cùng sẽ dẫn đến GC, như trong hình 8.

    alt_text Hình 7. Đang tăng số lượng đối tượng.

    alt_text Hình 8. Thu gom rác.

    Sau khi bạn xác định hành trình của người dùng đang tăng thêm áp lực bộ nhớ, hãy phân tích để tìm nguyên nhân gốc gây ra áp lực bộ nhớ.

  2. Chẩn đoán các điểm nóng về áp lực bộ nhớ.

    Chọn một dải ô trong tiến trình để trực quan hoá cả Allocations (Phân bổ) và Shallow size (Kích thước của đối tượng), như minh hoạ trong hình 9.

    alt_text Hình 9. Giá trị cho Allocations (Phân bổ) và Shallow Kích thước.

    Có nhiều cách để sắp xếp dữ liệu này. Sau đây là một số ví dụ về cách mỗi khung hiển thị có thể giúp bạn phân tích vấn đề.

    • Sắp xếp theo lớp: hữu ích khi bạn muốn tìm các lớp đang tạo đối tượng được lưu vào bộ nhớ đệm hoặc sử dụng lại trong nhóm bộ nhớ.

      Ví dụ: nếu bạn thấy một ứng dụng tạo 2.000 đối tượng của lớp có tên là "Vertex" mỗi giây, thì ứng dụng này sẽ tăng số lượng Allocations (Phân bổ) thêm 2.000 mỗi giây và bạn sẽ thấy điều này khi sắp xếp theo lớp. Nếu bạn muốn sử dụng lại các đối tượng này để tránh tạo ra rác, hãy triển khai một nhóm bộ nhớ.

    • Sắp xếp theo ngăn xếp lệnh gọi: hữu ích khi bạn muốn tìm vị trí có một đường dẫn nóng mà bộ nhớ đang được phân bổ, chẳng hạn như bên trong một vòng lặp hoặc bên trong một hàm cụ thể thực hiện nhiều công việc phân bổ.

    • Shallow Kích thước: chỉ theo dõi bộ nhớ của chính đối tượng. Công cụ này hữu ích cho việc theo dõi các lớp đơn giản chỉ bao gồm phần lớn các giá trị gốc.

    • Giữ lại kích thước: cho biết tổng bộ nhớ do đối tượng và các tệp tham chiếu chỉ được đối tượng tham chiếu. Công cụ này rất hữu ích trong việc theo dõi áp lực bộ nhớ do các đối tượng phức tạp. Để nhận giá trị này, hãy lấy tệp kết xuất bộ nhớ đầy đủ như minh hoạ trong hình 10 và đối với kích thước được giữ lại sẽ được thêm vào dưới dạng cột, như minh hoạ trong hình 11.

      alt_text Hình 10. Tệp kết xuất bộ nhớ đầy.

      Cột Kích thước được giữ lại.
      Hình 11. Cột Kích thước được giữ lại.

  3. Đo lường tác động của tính năng tối ưu hoá.

    Các GC hiển thị rõ ràng hơn và dễ dàng hơn để đo lường tác động của hoạt động tối ưu hoá bộ nhớ. Khi một hoạt động tối ưu hoá làm giảm áp lực bộ nhớ, bạn sẽ thấy ít GC hơn.

    Để đo lường tác động của hoạt động tối ưu hoá, trong tiến trình của trình phân tích tài nguyên, hãy đo lường thời gian giữa các GC. Sau đó, bạn có thể thấy quá trình này mất nhiều thời gian hơn giữa các GC.

    Sau đây là những tác động sau cùng của việc cải thiện bộ nhớ:

    • Tình trạng tắt hết bộ nhớ có thể giảm nếu ứng dụng không liên tục gặp áp lực về bộ nhớ.
    • Việc có ít GC sẽ giúp cải thiện các chỉ số về hiện tượng giật, đặc biệt là trong P99. Nguyên nhân là do GC gây ra tranh chấp về CPU, có thể dẫn đến việc hiển thị các nhiệm vụ bị trì hoãn trong khi GC đang diễn ra.