Đánh giá phần thể hiện

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

Có hai chỉ báo hiệu suất mà người dùng có thể nhìn thấy:

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

Điều đầu tiên đáng chú ý hơn điều 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ể biết thời gian khởi động ứng dụng là 500 mili giây hay 600 mili giây trừ khi họ nhìn hai thiết bị cạnh nhau. Độ trễ cảm ứng có thể nhận thấy ngay lập tức và góp phần đáng kể vào cảm nhận về thiết bị.

Kết quả là, 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 ngoài những gì cần thiết để duy trì hoạt độ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 phải ưu tiên bất kỳ công việc nào khác không cần thiết đối với giao diện người dùng linh hoạt. Để duy trì giao diện người dùng linh hoạt, đồng bộ hóa nền, gửi thông báo và các công việc tương tự đều phải bị trì hoãn nếu công việc giao diện người dùng có thể chạy được. Có thể 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.

Công suất và jitter

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

Dung tích

Dung lượng là tổng lượng tài nguyên mà thiết bị sở hữu trong một khoảng thời gian. Đâ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ỳ số liệu tương tự nào. Khi kiểm tra hiệu suất của toàn hệ thống, có thể hữu ích nếu trừu tượng hóa các thành phần riêng lẻ và giả định một số liệu 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ó thể đã được cố định).

Dung lượng của một hệ thống thay đổi tùy theo tài nguyên máy tính trực tuyến. Thay đổi tần số CPU/GPU là phương tiện chính để thay đổi công suất, nhưng cũng có những phương pháp khác như thay đổi số lõi CPU trực tuyến. Theo đó, công suất của một hệ thống tương ứng với điện năng tiêu thụ; 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 được xác định chủ yếu bởi ứng dụng đang chạy. Do đó, nền tảng có thể thực hiện rất ít việc để điều chỉnh công suất 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 điều đó bị 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, kernel).

Giật giật

Mặc dù dễ dàng nhận thấy dung lượng cần thiết cho khối lượng công việc nhưng jitter là một khái niệm mơ hồ hơn. Để có phần giới thiệu hay về jitter như một trở ngại cho các hệ thống nhanh, hãy tham khảo TRƯỜNG HỢP VỀ HIỆU SUẤT SIÊU MÁY TÍNH THIẾU: ĐẠT HIỆU SUẤT TỐI ƯU TRÊN 8.192 BỘ XỬ LÝ CỦA ASCl Q. (Đây là cuộc điều tra lý do tại sao siêu máy tính ASCI Q không đạt được hiệu suất như mong đợi và là sự giới thiệu tuyệt vời về việc tối ưu hóa các hệ thống lớn.)

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

Các nguồn gây giật hình gặp phải khi triển khai Android trong thế giới thực bao gồm:

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

Lượng thời gian cần thiết cho một khoảng thời gian jitter nhất định có thể giảm hoặc không giảm khi công suất tăng. Ví dụ: nếu trình điều khiển tắt các ngắt trong khi chờ đọc từ bus i2c, thì sẽ mất một khoảng thời gian cố định bất kể CPU ở tốc độ 384 MHz hay 2GHz. Tăng công suất 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 jitter. Kết quả là, các bộ xử lý nhanh hơn thường sẽ không cải thiện được hiệu suất trong các tình huống hạn chế về jitter.

Cuối cùng, không giống như năng lực, jitter gần như hoàn toàn nằm trong phạm vi của nhà cung cấp hệ thống.

Tiêu thụ bộ nhớ

Theo truyền thống, việc tiêu thụ bộ nhớ được cho là nguyên nhân dẫn đến 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 nó có thể gây ra hiện tượng giật do chi phí lowmemorykiller, khởi động lại dịch vụ và hỏng bộ nhớ đệm trang. Việc giảm mức tiêu thụ bộ nhớ có thể tránh được những nguyên nhân trực tiếp dẫn đến hiệu suất kém, nhưng cũng có thể có những cải tiến có mục tiêu khác nhằm tránh những nguyên nhân đó (ví dụ: ghim khung để ngăn khung bị phân trang khi nó được phân trang ngay sau đó).

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

Bắt đầu từ một hệ thống hoạt động kém nhưng cố gắng khắc phục hành vi của hệ thống bằng cách xem xét các trường hợp riêng lẻ về hiệu suất kém mà người dùng có thể nhận thấy 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ễ tái tạo (tức là jitter) hoặc là một vấn đề ứng dụng, nên có quá nhiều biến số trong toàn bộ hệ thống sẽ khiến chiến lược này không hiệu quả. 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 sử dụng một thiết bị mới:

  1. Giúp hệ thống khởi động vào giao diện người dùng với tất cả các trình điều khiển đang chạy và một số cài đặt bộ điều chỉnh tần số cơ bản (nếu bạn thay đổi 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 hạt 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 được phân phối tới màn hình.
  3. Thực hiện các dấu vết dài của toàn bộ quy trình giao diện người dùng (từ nhận đầu vào qua IRQ đến lần quét cuối cùng) trong khi chạy 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 tình trạng rớt 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 giật khác mà người dùng có thể nhìn thấy.

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

  • Đảm bảo hạt nhân của bạn có bản vá tracepoint sched_blocked_reason . Tracepoint này được kích hoạt với danh mục theo dõi được lập lịch trong systrace và cung cấp chức năng chịu trách nhiệm ngủ khi luồng đó chuyển sang chế độ ngủ không bị gián đoạn. Điều này rất quan trọng đối với việc phân tích hiệu suất vì giấc ngủ không bị gián đoạn là một dấu hiệu rất phổ biến của tình trạng bồn chồn.
  • Đảm bảo bạn có đủ khả năng theo dõi cho GPU và quy trình hiển thị. Trên các SOC Qualcomm gần đây, đ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 vẫn được bật khi bạn chạy systrace để bạn có thể xem thông tin bổ sung trong dấu vết về đường dẫn hiển thị (MDSS) trong phần mdss_fb0 . Trên Qualcomm SOC, 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ẽ hiển thị trong chính dấu vết đó (để biết chi tiết, hãy xem 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 khung đã được gửi tới màn hình. Từ đó, bạn có thể xác định xem mình đã đạt được thời gian kết xuất khung hình thành công hay chưa; nếu sự kiện X n xảy ra ít hơn 16,7 mili giây sau sự kiện X n-1 (giả sử màn hình 60Hz), 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 để nhận được chúng. Việc gỡ lỗi jitter là cực kỳ khó khăn nếu không có tín hiệu rõ ràng về việc hoàn thành khung.

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 có chức năng cơ bản của thiết bị. Tuy nhiên, việc coi điểm chuẩn làm đại diện cho hiệu suất thiết bị được cảm nhận 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ể cảm nhận được (số khung hình bị rớt, thời gian khung hình ở phân vị thứ 99, v.v.). Điểm chuẩn tổng hợp là điểm chuẩn chỉ dựa trên năng lực; jitter chỉ tác động đến hiệu suất đo được của các điểm chuẩn này bằng cách lấy đi 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 như một thước đo về hiệu suất mà người dùng nhận thấy.

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

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

Nếu điểm chuẩn biểu thị hiệu suất giao diện người dùng thực tế thì SOC 2 sẽ không sử dụng được. Giả sử tốc độ làm mới 60Hz, SOC 2 sẽ có khung hình 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àn toàn trôi chảy.

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

Các 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 quá nặng nên chúng hiếm khi hữu ích trong việc gỡ lỗi các vấn đề giật lẻ tẻ. Họ có thể cung cấp một số gợi ý về những gì hệ thống đang thực hiện tại một thời điểm nhất định, đặc biệt nếu sự cố xảy ra xung quanh quá trình chuyển đổi ứng dụng (được ghi vào báo cáo lỗi). Báo cáo lỗi cũng có thể chỉ ra khi có sự cố nói chung xảy ra với hệ thống, có thể làm giảm công suất 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 sử dụng cho Pixel và Pixel XL. Nó có sẵn tại frameworks/base/tests/TouchLatency và có hai chế độ: độ trễ cảm ứng và bóng nảy (để chuyển đổi chế độ, hãy nhấp vào nút ở góc trên bên phải).

Thử nghiệm quả bóng nảy chính xác đơn giản như vẻ ngoài của nó: Một quả bóng nảy xung quanh màn hình mãi mãi, bất kể thao tác nhập của người dùng. Cho đến nay, đây cũng thường là bài kiểm tra khó nhất để chạy hoàn hảo, nhưng càng tiến gần đến giai đoạn chạy mà không có bất kỳ khung hình nào bị rớt thì thiết bị của bạn sẽ càng hoạt động tốt hơn. Thử nghiệm bóng nảy rất khó vì đây là khối lượng công việc tầm thường nhưng hoàn toàn nhất quán, chạy ở xung nhịp rất thấp (điều này giả sử thiết bị có bộ điều chỉnh tần số; nếu thay vào đó, thiết bị chạy với xung nhịp cố định, hãy ép xung CPU/GPU xuống gần mức tối thiểu khi thực hiện bài kiểm tra bóng nảy lần đầu tiên). Khi hệ thống ngừng hoạt động và xung nhịp giảm dần về 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 bóng và thấy mọi thứ 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 giật hình dễ dàng hơn nhiều so với hầu hết các 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 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ồ thấp hơn khuếch đại tác động của jitter bằng cách làm cho nhiều khả năng bất kỳ jitter nào cũng gây ra hiện tượng rớt khung hình. Do đó, TouchLatency càng gần 60FPS thì bạn càng ít có khả năng gặp phải các hành vi hệ thống xấu gây ra hiện tượng giật lẻ tẻ, khó tái tạo trong các ứng dụng lớn hơn.

Vì jitter thường (nhưng không phải luôn luôn) bất biến tốc độ xung nhịp, hãy sử dụng thử nghiệm chạy ở xung nhịp rất thấp để chẩn đoán jitter vì những lý do sau:

  • Không phải tất cả jitter đều bất biến với tốc độ đồng hồ; nhiều nguồn chỉ tiêu tốn thời gian của CPU.
  • Người quản lý phải đạt được thời gian khung hình trung bình gần với thời hạn bằng cách giảm thời gian, do đó, thời gian dành cho việc chạy công việc không phải giao diện người dùng có thể khiến nó vượt quá giới hạn và rơi vào tình trạng bỏ khung hình.