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:
- 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.
- 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ị với 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 bộ nhớ heap.
- Simpleperf: hiển thị biểu đồ về các lệnh gọi hàm đang sử dụng hầu hết CPU trong một khoảng thời gian nhất định. Khi bạn xác định được một vật nào đó quá trình này mất nhiều thời gian trong Systrace, nhưng bạn 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
- Chỉ số trường: Thời gian khởi động Play Console
- Thử nghiệm trong phòng thí nghiệm: kiểm thử khởi động bằng Macrobenchmark
- 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ụngFrameMetricsAggregator
để ghi lại chỉ số độ giật trong một khoảng thời gian quy trình làm việc.
- Kiểm thử trong 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.
- Chỉ số trường
Vấn đề về quy trình xác minh Đường liên kết ứng dụng
Đườ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 về trang web của bạn. Sau đây là các lý do có thể khiến Đường liên kết ứng dụng xác minh 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 ứ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: chuyển hướng phía máy chủ và miền con chưa được xác minh
đều được coi là rủi ro bảo mật và không xác minh được. Chúng gây ra tất cả
autoVerify
đường liên kết không thành công. Ví dụ: chuyển hướng liên kết từ HTTP sang HTTPS, chẳng hạn như example.com đến www.example.com, mà không cần xác minh liên kết HTTPS có thể khiến xác minh không thành công. Đừng quên xác minh Đường liên kết ứng dụng bằng cách thêm ý định bộ lọc. - Đường liên kết không thể xác minh: bạn có thể thêm đường liên kết không thể xác minh cho mục đích thử nghiệm 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,
nhưng chúng có tác động nghiêm trọng đến hiệu suất. 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 để bật tính năng lập hồ sơ trong 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 mà ứng dụng của bạn dùng, thì điều này có thể ảnh hưởng đáng kể đến hiệu suất. Hơi nhiều 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 thử nghiệm.
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ể có đáng kể
mức hao tổn hiệu suất và bạn sẽ đạt đến mức này thường xuyên 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
Điểm chuẩn vi mô. 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, để giảm nhiễu trong kết quả đo 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ẽ.
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:
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:
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ổ:
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:
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.
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. Thay vào đó, để giảm thiểu số lượng
chế độ xem cần cập nhật, chỉ vô hiệu hoá những dữ liệu thay đổi.
Xem phần Trình bày dữ liệu động để biết các cách tránh tốn kém notifyDatasetChanged()
để 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 được lồng,
RecyclerView
bên trong phải được đặt RecycledViewPool
để giúp đảm bảo
thành phần hiển thị có thể được sử dụng lại 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. Xem video sau đây cung cấp thông tin tổng quan về tính năng theo dõi hệ thống và cách sử dụng Android Trình phân tích tài nguyên trong 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 trình bày 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 sẽ 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 phần mở rộng dựa trên web Trình xem dấu vết Perfetto. Để biết thêm thông tin, hãy xem bài viết Tổng quan về hệ thống theo dõi.
Một số điều cần lưu ý bao gồm:
- Giám sát tranh chấp: sự cạnh tranh về tài nguyên được bảo vệ bằng màn hình có thể giới thiệu độ trễ đáng kể khi khởi động ứng dụng.
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 việc hợp tác với nhóm phụ trách nền tảng đã liên kết để cải thiện.
GC đồng thời: đây là tình trạng phổ biến và tác động tương đối thấp, nhưng nếu bạn thường xuyên gặp phải vấn đề này, hãy cân nhắc xem xét vấn đề bằng bộ nhớ Android Studio trình phân tích tài nguyên.
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: có thể ảnh hưởng đến luồng giao diện người dùng, vì vậy, hãy chú ý đến công việc trong nền khi khởi động.
Bạn nên gọi reportFullyDrawn
khi quá trình khởi động hoàn tất từ
quan điểm của ứng dụng để cải thiện báo cáo chỉ số khởi động ứng dụng. Xem Thời gian
để hiển thị toàn bộ để 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 trình xử lý dấu vết Perfetto,
và một sự kiện dấu vết mà người dùng nhìn thấy sẽ được phát.
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 Theo dõi hệ thống để ghi lại hệ thống
theo dõi trên một 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
bạn phải cắm nguồn 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ớ trong Android Studio để kiểm tra áp lực bộ nhớ có thể là do rò rỉ bộ nhớ hoặc thói quen sử dụng không hợp lệ. Nền tảng này mang đến trải nghiệm chế độ xem phân bổ đối tượng.
Bạn có thể khắc phục các vấn đề về bộ nhớ trong ứng dụng bằng cách làm theo thông tin sau đây trên 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:
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ư trong hình 7, cuối cùng dẫn đến GC, như minh hoạ trong Hình 8.
Hình 7. Đang tăng số lượng đối tượng.
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 gây thêm áp lực về bộ nhớ, hãy phân tích để biết nguyên nhân gốc rễ của áp lực bộ nhớ.
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à Kích thước của đối tượng, như minh hoạ trong hình 9.
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ề về cách mỗi chế độ xem 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 tạo các đối tượng được lưu vào bộ nhớ đệm hoặc sử dụng lại từ 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à "Đỉnh" mỗi giây, nó sẽ làm tăng số lượng Allocations (Phân bổ) thêm 2.000 mỗi giây và bạn sẽ thấy biểu tượng 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 rác, hãy triển khai nhóm bộ nhớ.
Arrange by callstack (Sắp xếp theo ngăn xếp lệnh gọi): hữu ích khi bạn muốn tìm nơi có đường dẫn nơi 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 thực hiện rất 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. hữu ích để theo dõi các lớp đơn giản chỉ bao gồm hầu hết các giá trị ban đầu.
Giữ lại kích thước: cho biết tổng dung lượng bộ nhớ do đối tượng và tham chiếu chỉ được đối tượng tham chiếu. Rất hữu ích cho việc theo dõi bộ nhớ áp lực của các vật thể phức tạp. Để nhận giá trị này, hãy dùng một bộ nhớ đầy tệp kết xuất, như minh hoạ trong hình 10 và Giữ lại kích thước được thêm dưới dạng cột, như như minh hoạ trong hình 11.
Hình 10. Tệp kết xuất bộ nhớ đầy.
Hình 11. Cột Kích thước được giữ lại.
Đo lường tác động của tính năng tối ưu hoá.
GC hiển thị rõ ràng hơn và dễ dàng hơn để đo lường tác động của bộ nhớ tối ưu hoá. Khi tối ưu hoá làm giảm áp lực về 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 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 bị áp lực 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.
Đề xuất cho bạn
- Lưu ý: văn bản có đường liên kết sẽ hiện khi JavaScript tắt
- Phân tích và tối ưu hoá quá trình khởi động ứng dụng {:#app-startup-analysis-optimization}
- Khung hình bị treo
- Viết một Macrobenchmark