Đánh giá hiệu suất

Sử dụng Simpleperf để đánh giá hiệu suất của thiết bị. Simpleperf là công cụ lập hồ sơ gốc cho cả hai ứ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 của ứng dụng và hoạt động của luồng theo thời gian thực.

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

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

URL đầu tiên dễ nhận thấy hơn lựa chọn thứ hai. Người dùng thường nhận thấy hiện tượng giật nhưng họ không thể cho biết thời gian khởi động ứng dụng là 500 mili giây so với 600 mili giây trừ phi họ xem hai thiết bị cạnh nhau. Độ trễ khi chạm sẽ xuất hiện ngay lập tức đáng chú ý và góp phần đáng kể vào cảm nhận về một thiết bị.

Do đó, trong một thiết bị nhanh, quy trình giao diện người dùng là điều quan trọng nhất trong hệ thống khác với những gì cần thiết để giữ cho quy trình giao diện người dùng hoạt động. Chiến dịch này có nghĩa là quy trình giao diện người dùng phải giành quyền ưu tiên bất kỳ công việc nào khác không cần thiết cho giao diện người dùng linh hoạt. Để duy trì giao diện người dùng linh hoạt, đồng bộ hoá trong nền, gửi thông báo, và tác vụ tương tự đều phải được trì hoãn nếu có thể chạy tác vụ giao diện người dùng. Đó là được chấp nhận để đánh đổi hiệu suất của các hoạt động 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 linh hoạt.

Dung lượng so với dao động

Khi xem xét hiệu suất của thiết bị, dung lượngsự biến động 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. Đó 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ỳ số liệu nào tương tự. Khi kiểm tra hiệu suất của toàn bộ hệ thống, nên việc trừu tượng hoá từng thành phần riêng lẻ có thể sẽ hữu ích và giả định một chỉ số duy nhất quyết định hiệu suất (đặc biệt là khi điều chỉnh thiết bị mới vì khối lượng công việc chạy trên thiết bị đó có thể đã được khắc phục).

Công suất của hệ thống thay đổi tuỳ theo tài nguyên điện toán trực tuyến. Việc thay đổi tần số của CPU/GPU là phương tiện chính để thay đổi dung lượng, nhưng có chẳng hạn như thay đổi số lượng lõi CPU trên mạng. Theo đó, công suất của hệ thống tương ứng với điện năng tiêu thụ; đang thay đổi dung lượng 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 được xác định quá nhiều bởi đang chạy. Do đó, nền tảng này có thể không điều chỉnh được dung lượng cần thiết cho một khối lượng công việc nhất định và phương tiện để làm như vậy được giới hạn ở các 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 hệ điều hành).

Dao động

Mặc dù dễ thấy mức dung lượng cần thiết đối với một khối lượng công việc, nhưng hiện tượng dao động là một khái niệm mơ hồ. Giới thiệu sơ lược về sự biến động như một trở ngại cho quá trình phát triển nhanh hệ thống, tham chiếu đến THEO TRƯỜNG HỢP THIẾU HIỆU SUẤT CỦA MÁY TÍNH BẢNG: ĐẠT ĐƯỢC HIỆU SUẤT TỐI ƯU HOÁ TRÊN 8.192 BỘ ĐIỀU KHIỂN CỦA ASCl Q. (Đây là cuộc điều tra về lý do khiến ASCI Siêu máy tính Q không đạt được hiệu suất như mong đợi và thật tuyệt vời giới thiệu về cách tối ưu hoá các hệ thống lớn.)

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

Các nguồn dao động gặp phải trong quá trình triển khai Android thực tế bao gồm:

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

Khoảng thời gian cần thiết cho một khoảng thời gian dao động nhất định có thể hoặc không thể giảm khi dung lượng tăng. Ví dụ: nếu người lái xe rời khỏi điểm gián đoạn bị vô hiệu hoá trong khi chờ đọc từ trên xe buýt i2c, thao tác này sẽ bất kể CPU ở tốc độ 384 MHz hay 2 GHz. Tăng dung lượng không phải là giải pháp khả thi để cải thiện hiệu suất khi dao động liên quan. Kết quả là những bộ xử lý nhanh hơn thường sẽ không cải thiện được hiệu suất cao trong các trường hợp ràng buộc về hiện tượng dao động.

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

Mức sử dụng bộ nhớ

Theo truyền thống, mức tiêu thụ bộ nhớ thường gây ra hiệu suất kém. Trong khi mức tiêu thụ không phải là vấn đề về hiệu suất, nó có thể gây ra hiện tượng dao động qua mức hao tổn bộ nhớ thấp, dịch vụ khởi động lại và tình trạng đơ máy bộ nhớ đệm của trang. Giảm việc tiêu thụ bộ nhớ có thể tránh được nguyên nhân trực tiếp làm giảm hiệu suất, nhưng cũng có thể là những cải tiến khác có mục tiêu cụ thể nhằm tránh những nguyên nhân đó (ví dụ: ghim khung này để khung đó không bị phân trang khi đượ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 kém hiệu quả 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 người dùng kém hiệu suất không phải là một chiến lược hợp lý. Bởi vì hiệu suất kém thường không dễ dàng tái tạo (chẳng hạn như hiện tượng dao động) hoặc gặp vấn đề về ứng dụng nhiều biến số trong toàn bộ hệ thống ngăn cản chiến lược này có hiệu quả. Như dẫn đến một kết quả là rất dễ xác định sai nguyên nhân và thực hiện những cải tiến nhỏ trong khi bỏ lỡ các cơ hội mang tính hệ thống để khắc phục 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 đưa ra một thiết bị:

  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ố trình điều khiển cơ bản cài đặt bộ điều khiển tần suất (nếu bạn thay đổi chế độ cài đặt của bộ điều khiển tần suất, lặp lại tất cả các bước bên dưới).
  2. Đảm bảo 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ị biểu thị thời điểm khung hình được đưa đến màn hình.
  3. Theo dõi toàn bộ quy trình giao diện người dùng (từ việc nhận dữ liệu đầu vào thông qua IRQ) cho đế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 bài kiểm tra bóng trong TouchLatency).
  4. Khắc phục hiện tượng rớt khung hình được phát hiện trong phiên bản gọn nhẹ và nhất quán khối lượng công việc.
  5. Lặp lại các bước từ 3 đến 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 cùng một lúc.
  6. Hãy chuyển sang các nguồn khác mà người dùng có thể thấy được.

Những việc đơn giản khác mà bạn có thể thực hiện sớm trong quá trình hiển thị thiết bị bao gồm:

  • Đảm bảo nhân của bạn có lý_do_bị_chặn bản vá điểm theo dõi. Điểm theo dõi này được bật bằng danh mục dấu vết sched trong systrace và cung cấp chức năng chịu trách nhiệm cho chế độ ngủ khi luồng chuyển sang chế độ ngủ không gián đoạn. Có vai trò quan trọng trong quá trình phân tích hiệu suất vì giấc ngủ không gián đoạn là chỉ báo rất phổ biến của hiện tượng dao động.
  • Đảm bảo bạn có đủ dữ liệu theo dõi cho GPU và quy trình hiển thị. Bật SOC gần đây của họ, đ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"
    

    Những sự kiện này sẽ vẫn được bật khi bạn chạy systrace để bạn có thể thấy thêm thông tin trong dấu vết về quy trình hiển thị (PROFILES) trong mdss_fb0. Trên SOC Qualcomm, bạn sẽ không thấy bất kỳ thông tin nào thông tin về GPU trong chế độ xem systrace chuẩn, nhưng kết quả là xuất hiện trong chính dấu vết (để biết chi tiết, hãy xem Tìm hiểu 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 mà cho biết một khung hình đã được gửi tới màn hình. Từ đó, bạn có thể xác định xem bạn đã đạt đến thời gian kết xuất khung hình thành công hay chưa; nếu sự kiện Xn xảy ra trong chưa đầy 16,7 mili giây sau sự kiện Xn-1 (giả sử màn hình 60 Hz), thì bạn biết 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 của bạn để có được quảng cáo. Gỡ lỗi dao động rất khó nếu không có tín hiệu chính xác 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 trong việc đảm bảo chức năng cơ bản của thiết bị đang tồn tại. Tuy nhiên, việc coi điểm chuẩn là proxy cho thiết bị được cảm nhận hiệu suất không hữu ích.

Dựa trên trải nghiệm với SOC, sự khác biệt về điểm chuẩn tổng hợp hiệu suất 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 biết (số khung hình bị rớt, khung hình tại phân vị thứ 99 thời gian, v.v.). Điểm chuẩn tổng hợp là các điểm chuẩn chỉ về dung lượng; tác động của dao động hiệu suất đo lường được của các điểm chuẩn này chỉ bằng cách đánh cắp thời gian từ hàng loạt hoạt động của điểm chuẩn. Do đó, điểm chuẩn tổng hợp chủ yếu không liên quan đến hiệu suất mà người dùng nhận thấy.

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

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

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

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

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

Sử dụng TouchLatency

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

Bài kiểm tra bóng bật lên rất đơn giản như bạn vẫn tưởng: Một quả bóng nảy mãi mãi xung quanh màn hình, bất kể hoạt động đầu vào của người dùng. Thông thường, cho đến bài kiểm thử khó nhất để chạy một cách hoàn hảo, nhưng nó càng gần chạy mà không bị rớt khung hình, thiết bị của bạn sẽ càng tốt hơn. Chiến lược phát hành đĩa đơn kiểm thử bóng nảy rất khó vì đây là một bài kiểm thử bình thường nhưng hoàn toàn nhất quán khối lượng công việc chạy ở xung nhịp rất thấp (giả sử thiết bị có tần số thống đốc; nếu thiết bị đang chạy với xung nhịp cố định, hãy giảm xung nhịp cho CPU/GPU gần mức tối thiểu trong lần chạy kiểm tra bóng nảy trong lần đầu tiên). Khi hệ thống ngừng hoạt động và xung nhịp gần đạt đến trạng thái rảnh, CPU/GPU cần có thời gian trên mỗi khung hình sẽ tăng lên. Bạn có thể quan sát quả bóng và thấy vật bị giật, khi đó bạn bạn cũng có thể xem 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 dao động dễ dàng hơn nhiều so với hầu hết khối lượng công việc mà người dùng có thể nhìn thấy bằng cách theo dõi đang chạy trên hệ thống trong mỗi khung hình bị bỏ lỡ thay vì trên giao diện người dùng quy trình. Các xung nhịp thấp hơn khuếch đại ảnh hưởng của hiện tượng dao động bằng cách làm cho nó nhiều khả năng là sự biến động cũng khiến khung hình bị rớt. Do đó, Chạm Độ trễ càng gần với 60FPS thì khả năng hệ thống của bạn càng thấp những hành vi gây ra tình trạng giật ngẫu nhiên, khó tái hiện của chúng tôi.

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

  • Không phải tất cả các dao động đều là tốc độ xung nhịp bất biến; nhiều nguồn chỉ tiêu thụ CPU bất cứ lúc nào.
  • Thống đốc cần đưa ra thời gian kết xuất khung hình trung bình sát với thời hạn giảm xung nhịp nên thời gian dành để chạy công việc không phải giao diện người dùng có thể đẩy công việc đó vượt quá mức thả một khung hình.