Đánh giá hiệu suất

Sử dụng Simpleperf để đánh giá hiệu suất của thiết bị. Simpleperf là một công cụ lập hồ sơ gốc cho cả ứng dụng và quy trình gốc trên Android. Sử dụng Trình phân tích CPU để kiểm tra mức sử dụng CPU và hoạt động của luồng trong ứng dụng theo thời gian thực.

Có 2 chỉ báo về hiệu suất mà người dùng có thể thấy:

• Hiệu suất có thể dự đoán và nhận biết được. Giao diện người dùng có bị rớt khung hình hay luôn kết xuất ở tốc độ 60 khung hình/giây không? Âm thanh có phát mà không bị lỗi hoặc tiếng lách tách không? Độ trễ giữa thời điểm người dùng chạm vào màn hình và thời điểm hiệu ứng xuất hiện trên màn hình là bao lâu?
• Khoảng thời gian cần thiết cho các thao tác dài hơn (chẳng hạn như mở ứng dụng).

Lỗi đầu tiên dễ nhận thấy hơn lỗi thứ hai. Người dùng thường nhận thấy hiện tượng giật nhưng họ sẽ không thể phân biệt được thời gian khởi động ứng dụng là 500 ms hay 600 ms, trừ phi họ đang nhìn vào 2 thiết bị cạnh nhau. Độ trễ khi chạm có thể nhận thấy ngay lập tức và đóng góp đáng kể vào cảm nhận về một thiết bị.

Do đó, trong một thiết bị có tốc độ cao, quy trình giao diện người dùng là yếu tố quan trọng nhất trong hệ thống, ngoài những yếu tố cần thiết để duy trì chức năng của quy trình giao diện người dùng. Điều này có nghĩa là quy trình giao diện người dùng sẽ ưu tiên mọi công việc khác không cần thiết cho giao diện người dùng mượt mà. Để duy trì giao diện người dùng mượt mà, bạn phải trì hoãn tất cả các hoạt động đồng bộ hoá trong nền, gửi thông báo và các hoạt động tương tự nếu có thể chạy hoạt động giao diện người dùng. Bạn có thể chấp nhận đánh đổi hiệu suất của các thao tác dài hơn (thời gian chạy HDR+, khởi động ứng dụng, v.v.) để duy trì giao diện người dùng mượt mà.

Dung lượng so với độ trễ

Khi xem xét hiệu suất của thiết bị, dung lượng và độ trễ là hai chỉ số có ý nghĩa.

Dung lượng

Dung lượng là tổng lượng tài nguyên mà thiết bị có trong một khoảng thời gian nhất định. Đây có thể là tài nguyên CPU, tài nguyên GPU, tài nguyên I/O, tài nguyên mạng, băng thông bộ nhớ hoặc bất kỳ chỉ số tương tự nào. Khi kiểm tra hiệu suất toàn hệ thống, bạn có thể trừu tượng hoá các thành phần riêng lẻ và giả định một chỉ số duy nhất xác định hiệu suất (đặc biệt là khi điều chỉnh một thiết bị mới vì khối lượng công việc chạy trên thiết bị đó có khả năng cố định).

Công suất của một hệ thống sẽ thay đổi tuỳ thuộc vào tài nguyên điện toán trực tuyến. Thay đổi tần số CPU/GPU là phương thức chính để thay đổi công suất, nhưng có những phương thức khác, chẳng hạn như thay đổi số lượng lõi CPU đang hoạt động. Theo đó, công suất của một hệ thống tương ứng với mức tiêu thụ điện năng; việc thay đổi công suất luôn dẫn đến sự thay đổi tương tự về mức tiêu thụ điện năng.

Dung lượng cần thiết tại một thời điểm nhất định chủ yếu được xác định bởi ứng dụng đang chạy. Do đó, nền tảng này không thể điều chỉnh nhiều dung lượng cần thiết cho một khối lượng công việc nhất định và các phương tiện để làm như vậy chỉ giới hạn ở những cải tiến về thời gian chạy (khung Android, ART, Bionic, trình biên dịch/trình điều khiển GPU, nhân).

Dao động

Mặc dù bạn có thể dễ dàng nhận thấy dung lượng cần thiết cho một khối lượng công việc, nhưng độ trễ biến thiên là một khái niệm khó nắm bắt hơn. Để có một phần giới thiệu hay về độ trễ là một trở ngại đối với các hệ thống nhanh, bạn nên đọc bài viết có tiêu đề The Case of the Missing Supercomputer Performance: Achieving Optimal Performance on the 8,192 processors of ASCI Q (Trường hợp hiệu suất siêu máy tính bị thiếu: Đạt được hiệu suất tối ưu trên 8.192 bộ xử lý của ASCI Q). (Đây là một nghiên cứu về lý do siêu máy tính ASCI Q không đạt được hiệu suất như mong đợi và là một phần giới thiệu tuyệt vời về cách tối ưu hoá các hệ thống lớn.)

Trang này sử dụng thuật ngữ biến động để mô tả những gì mà bài viết ASCI Q gọi là nhiễu. Độ trễ là hành vi ngẫu nhiên của hệ thống ngăn không cho các hoạt động có thể nhận thấy chạy. Đây thường là tác vụ phải chạy, nhưng có thể không có yêu cầu nghiêm ngặt về thời gian khiến tác vụ chạy vào bất kỳ thời điểm cụ thể nào. Vì là ngẫu nhiên, nên rất khó để bác bỏ sự tồn tại của độ trễ đối với một khối lượng công việc nhất định. Cũng rất khó để chứng minh rằng một nguồn biến động đã biết là nguyên nhân gây ra một vấn đề cụ thể về hiệu suất. Các công cụ thường được dùng nhất để chẩn đoán nguyên nhân gây ra hiện tượng rung (chẳng hạn như theo dõi hoặc ghi nhật ký) có thể gây ra hiện tượng rung riêng.

Các nguồn gây ra hiện tượng giật hình trong quá trình triển khai Android thực tế bao gồm:

• Độ trễ của bộ lập lịch
• Trình xử lý gián đoạn
• Mã trình điều khiển chạy quá lâu khi tính năng ưu tiên hoặc ngắt bị vô hiệu hoá
• Softirq chạy trong thời gian dài
• Tranh chấp khoá (ứng dụng, khung, trình điều khiển nhân, khoá liên kết, khoá mmap)
• Tranh chấp chỉ số mô tả tệp trong đó một luồng có mức độ ưu tiên thấp giữ khoá trên một tệp, ngăn luồng có mức độ ưu tiên cao chạy
• Chạy mã quan trọng đối với giao diện người dùng trong hàng đợi công việc, nơi mã này có thể bị trì hoãn
• Chuyển đổi trạng thái rảnh của CPU
• Ghi nhật ký
• Độ trễ I/O
• Tạo quy trình không cần thiết (ví dụ: thông báo CONNECTIVITY_CHANGE)
• Hiện tượng tràn bộ nhớ đệm trang do không đủ bộ nhớ trống

Thời gian cần thiết cho một khoảng thời gian dao động nhất định có thể giảm hoặc không giảm khi dung lượng tăng. Ví dụ: nếu trình điều khiển để lại các gián đoạn bị vô hiệu hoá trong khi chờ đọc từ một bus i2c, thì sẽ mất một khoảng thời gian cố định bất kể CPU ở 384 MHz hay 2 GHz. Tăng dung lượng không phải là một giải pháp khả thi để cải thiện hiệu suất khi có hiện tượng rung. Do đó, bộ xử lý nhanh hơn thường sẽ không cải thiện hiệu suất trong các trường hợp bị hạn chế về độ trễ.

Cuối cùng, không giống như dung lượng, độ trễ gần như hoàn toàn nằm trong phạm vi của nhà cung cấp hệ thống.

Mức tiêu thụ bộ nhớ

Mức tiêu thụ bộ nhớ thường được cho là nguyên nhân gây ra hiệu suất kém. Mặc dù bản thân mức tiêu thụ không phải là vấn đề về hiệu suất, nhưng mức tiêu thụ có thể gây ra hiện tượng giật hình thông qua chi phí lowmemorykiller, khởi động lại dịch vụ và hiện tượng loại bỏ bộ nhớ đệm trang. Việc giảm mức tiêu thụ bộ nhớ có thể tránh được các nguyên nhân trực tiếp gây ra hiệu suất kém, nhưng cũng có thể có những điểm cải tiến khác nhắm đến việc tránh các nguyên nhân đó (ví dụ: ghim khung để ngăn khung bị phân trang khi khung sẽ được phân trang ngay sau đó).

Phân tích hiệu suất ban đầu của thiết bị

Bắt đầu từ một hệ thống hoạt động nhưng hiệu suất kém và cố gắng khắc phục hành vi của hệ thống bằng cách xem xét từng trường hợp hiệu suất kém mà người dùng nhìn thấy không phải là một chiến lược hợp lý. Vì hiệu suất kém thường không dễ tái tạo (tức là độ trễ) hoặc là vấn đề về ứng dụng, nên có quá nhiều biến số trong toàn bộ hệ thống khiến chiến lược này không hiệu quả. Do đó, bạn rất dễ xác định sai nguyên nhân và chỉ cải thiện một chút trong khi bỏ lỡ các cơ hội mang tính hệ thống để cải thiện hiệu suất trên toàn hệ thống.

Thay vào đó, hãy sử dụng phương pháp chung sau đây khi thiết lập một thiết bị mới:

1. Khởi động hệ thống vào giao diện người dùng với tất cả trình điều khiển đang chạy và một số chế độ cài đặt cơ bản của bộ điều chỉnh tần số (nếu bạn thay đổi chế độ cài đặt bộ điều chỉnh tần số, hãy lặp lại tất cả các bước bên dưới).
2. Đảm bảo rằng nhân hỗ trợ điểm theo dõi sched_blocked_reason cũng như các điểm theo dõi khác trong quy trình hiển thị cho biết thời điểm khung hình được gửi đến màn hình.
3. Lấy các dấu vết dài của toàn bộ quy trình giao diện người dùng (từ khi nhận dữ liệu đầu vào thông qua IRQ đến lần quét cuối cùng) trong khi chạy một khối lượng công việc nhẹ và nhất quán (ví dụ: UiBench hoặc kiểm thử bóng trong TouchLatency).
4. Khắc phục tình trạng giảm khung hình được phát hiện trong khối lượng công việc nhẹ và nhất quán.
5. Lặp lại các bước 3-4 cho đến khi bạn có thể chạy mà không bị rớt khung hình trong hơn 20 giây mỗi lần.
6. Chuyển sang các nguồn khác mà người dùng có thể thấy được hiện tượng giật.

Những việc đơn giản khác mà bạn có thể làm ngay từ đầu trong quá trình khởi động thiết bị bao gồm:

• Đảm bảo rằng nhân của bạn có bản vá điểm theo dõi sched_blocked_reason. Điểm theo dõi này được bật bằng danh mục theo dõi sched trong systrace và cung cấp hàm chịu trách nhiệm cho chế độ ngủ khi luồng đó chuyển sang chế độ ngủ không gián đoạn. Đây là yếu tố quan trọng để phân tích hiệu suất vì thời gian ngủ không bị gián đoạn là một chỉ báo rất phổ biến về độ trễ.
• Đảm bảo bạn có đủ thông tin theo dõi cho GPU và các quy trình hiển thị. Trên các SOC Qualcomm gần đây, các điểm theo dõi được bật bằng cách sử dụng:

adb shell "echo 1 > /d/tracing/events/kgsl/enable"
adb shell "echo 1 > /d/tracing/events/mdss/enable"

Các sự kiện này vẫn được bật khi bạn chạy systrace để có thể xem thêm thông tin trong dấu vết về quy trình hiển thị (MDSS) trong phần mdss_fb0. Trên SOC Qualcomm, bạn sẽ không thấy bất kỳ thông tin bổ sung nào về GPU trong chế độ xem systrace tiêu chuẩn, nhưng kết quả sẽ có trong chính dấu vết (để biết thông tin chi tiết, hãy xem phần Tìm hiểu về systrace).

Điều bạn muốn từ loại theo dõi hiển thị này là một sự kiện duy nhất cho biết trực tiếp rằng một khung hình đã được gửi đến màn hình. Từ đó, bạn có thể xác định xem mình có đạt được thời gian khung hình hay không; nếu sự kiện Xn xảy ra dưới 16,7 ms sau sự kiện Xn-1 (giả sử màn hình 60 Hz), thì bạn biết rằng mình không bị giật. Nếu SOC của bạn không cung cấp các tín hiệu như vậy, hãy làm việc với nhà cung cấp để lấy chúng. Việc gỡ lỗi hiện tượng giật hình là cực kỳ khó khăn nếu không có tín hiệu xác định về việc hoàn thành khung hình.

Sử dụng điểm chuẩn tổng hợp

Điểm chuẩn tổng hợp rất hữu ích để đảm bảo thiết bị có chức năng cơ bản. Tuy nhiên, việc coi điểm chuẩn là một chỉ số đại diện cho hiệu suất thiết bị cảm nhận được là không hữu ích.

Dựa trên kinh nghiệm với SOC, sự khác biệt về hiệu suất điểm chuẩn tổng hợp giữa các SOC không tương quan với sự khác biệt tương tự về hiệu suất giao diện người dùng có thể nhận thấy (số lượng khung hình bị bỏ qua, thời gian khung hình ở phân vị thứ 99, v.v.). Điểm chuẩn tổng hợp chỉ là điểm chuẩn về dung lượng; độ trễ chỉ ảnh hưởng đến hiệu suất đo lường của các điểm chuẩn này bằng cách lấy thời gian từ hoạt động hàng loạt của điểm chuẩn. Do đó, điểm chuẩn tổng hợp hầu như không liên quan đến chỉ số hiệu suất mà người dùng cảm nhận được.

Hãy xem xét 2 SOC chạy Benchmark X, kết xuất 1.000 khung hình giao diện người dùng và báo cáo tổng thời gian kết xuất (điểm số càng thấp càng tốt).

• SOC 1 kết xuất mỗi khung hình của Benchmark X trong 10 mili giây và đạt điểm số 10.000.
• SOC 2 kết xuất 99% số khung hình trong 1 mili giây nhưng 1% số khung hình trong 100 mili giây và đạt điểm số 19.900, một điểm số cao hơn đáng kể.

Nếu điểm chuẩn cho biết hiệu suất thực tế của giao diện người dùng, thì SOC 2 sẽ không dùng được. Giả sử tốc độ làm mới là 60 Hz, SOC 2 sẽ có một khung hình bị giật sau mỗi 1,5 giây hoạt động. Trong khi đó, SOC 1 (SOC chậm hơn theo Benchmark X) sẽ hoạt động hoàn toàn mượt mà.

Sử dụng báo cáo lỗi

Đôi khi, báo cáo lỗi hữu ích cho việc phân tích hiệu suất, nhưng vì có dung lượng quá lớn nên báo cáo lỗi hiếm khi hữu ích cho việc gỡ lỗi các vấn đề về hiện tượng giật hình không thường xuyên. Chúng có thể cung cấp một số gợi ý về những gì hệ thống đang làm tại một thời điểm nhất định, đặc biệt là nếu hiện tượng giật xảy ra trong quá trình chuyển đổi ứng dụng (được ghi lại trong báo cáo lỗi). Báo cáo lỗi cũng có thể cho biết khi hệ thống gặp phải vấn đề nghiêm trọng hơn có thể làm giảm dung lượng hiệu quả của hệ thống (chẳng hạn như điều tiết nhiệt hoặc phân mảnh bộ nhớ).

Sử dụng TouchLatency

Một số ví dụ về hành vi xấu đến từ TouchLatency, đây là khối lượng công việc định kỳ được ưu tiên dùng cho Pixel và Pixel XL. Bạn có thể truy cập vào công cụ này tại frameworks/base/tests/TouchLatency và công cụ này có 2 chế độ: độ trễ khi chạm và quả bóng nảy (để chuyển đổi chế độ, hãy nhấp vào nút ở góc trên cùng bên phải).

Thử nghiệm quả bóng nảy đơn giản đúng như tên gọi: Một quả bóng nảy xung quanh màn hình mãi mãi, bất kể người dùng nhập dữ liệu gì. Đây cũng thường là bài kiểm thử khó nhất để chạy một cách hoàn hảo, nhưng thiết bị của bạn sẽ hoạt động càng tốt nếu bài kiểm thử này chạy mà không bị rớt khung hình. Bài kiểm thử bóng nảy rất khó vì đây là một khối lượng công việc không đáng kể nhưng hoàn toàn nhất quán, chạy ở xung nhịp rất thấp (điều này giả định thiết bị có bộ điều chỉnh tần số; nếu thiết bị đang chạy với xung nhịp cố định, hãy giảm xung nhịp CPU/GPU xuống gần mức tối thiểu khi chạy bài kiểm thử bóng nảy lần đầu tiên). Khi hệ thống tạm dừng và xung nhịp giảm gần đến mức không hoạt động, thời gian CPU/GPU cần thiết cho mỗi khung hình sẽ tăng lên. Bạn có thể xem quả bóng và thấy các đối tượng bị giật, đồng thời bạn cũng có thể thấy các khung hình bị bỏ lỡ trong systrace.

Vì khối lượng công việc rất nhất quán, nên bạn có thể xác định hầu hết các nguồn gây ra hiện tượng giật hình dễ dàng hơn nhiều so với trong hầu hết các khối lượng công việc mà người dùng nhìn thấy bằng cách theo dõi chính xác những gì đang chạy trên hệ thống trong mỗi khung hình bị bỏ lỡ thay vì quy trình giao diện người dùng. Đồng hồ có tốc độ thấp hơn sẽ khuếch đại ảnh hưởng của hiện tượng giật hình bằng cách tăng khả năng khiến mọi hiện tượng giật hình đều gây ra khung hình bị bỏ qua. Do đó, TouchLatency càng gần với 60 FPS thì bạn càng ít gặp phải các hành vi xấu của hệ thống gây ra hiện tượng giật cục không liên tục và khó tái tạo trong các ứng dụng lớn hơn.

Vì độ trễ thường (nhưng không phải lúc nào cũng) không đổi theo tốc độ xung nhịp, hãy sử dụng một bài kiểm thử chạy ở tốc độ xung nhịp rất thấp để chẩn đoán độ trễ vì những lý do sau:

• Không phải độ trễ nào cũng bất biến theo tốc độ xung nhịp; nhiều nguồn chỉ tiêu thụ thời gian CPU.
• Bộ điều khiển nên giảm tốc độ để thời gian trung bình của khung hình gần với thời hạn, vì vậy, thời gian chạy công việc không phải giao diện người dùng có thể đẩy thời gian này vượt quá giới hạn để giảm khung hình.