Google cam kết thúc đẩy công bằng chủng tộc cho Cộng đồng người da đen. Xem cách thực hiện.

Trang này được dịch bởi Cloud Translation API.

Đá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ụ tạo hồ sơ gốc cho cả ứng dụng và quy trình gốc trên Android. Sử dụng CPU Profiler để kiểm tra việ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 về hiệu suất mà người dùng có thể nhìn thấy:

Hiệu suất có thể đoán trướ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 ở 60FPS không? Âm thanh có phát mà không có hiện vật hoặc tiếng kêu không? Khoảng thời gian chờ giữa 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 cho các hoạt động lâu hơn (chẳng hạn như mở ứng dụng).

Đầu tiên là đáng chú ý hơn thứ hai. Người dùng thường nhận thấy jank nhưng họ sẽ không thể biết thời gian khởi động ứng dụng 500ms so với 600ms trừ khi họ đang nhìn hai thiết bị cạnh nhau. Độ trễ của 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 của thiết bị.

Kết quả là, trong một thiết bị nhanh, đường ống 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 để giữ cho đường ống giao diện người dùng hoạt động. Điều này có nghĩa là đường ống giao diện người dùng sẽ chặn trước 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ộ 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.

Dung lượng so với jitter

Khi xem xét hiệu suất của thiết bị, dung lượng và jitter là hai thước đo 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 nào tương tự. Khi kiểm tra hiệu suất toàn hệ thống, có thể hữu ích khi tóm tắt 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 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).

Năng lực của một hệ thống khác nhau dựa trên các 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 dung lượng, nhưng có những cách khác như thay đổi số lượng lõi CPU trực tuyến. Theo đó, công suất của hệ thống tương ứng với công suất tiêu thụ; thay đổi công suất luôn dẫn đến một sự thay đổi tương tự trong công suất tiêu thụ.

Dung lượng cần thiết tại một thời điểm nhất định được xác định áp đảo 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 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 điều đó bị giới hạn ở các cải tiến thời gian chạy (Android framework, ART, Bionic, trình biên dịch / trình điều khiển GPU, nhân).

Bồn chồn

Trong khi khả năng cần thiết cho một khối lượng công việc là dễ dàng nhận thấy, jitter là một khái niệm khó hiểu hơn. Để được giới thiệu tốt về jitter như một trở ngại đối với các hệ thống nhanh, hãy tham khảo TRƯỜNG HỢP HIỆU SUẤT CỦA MÁY SIÊU MỎNG: ĐẠT ĐƯỢC HIỆU SUẤT TỐI ƯU TRÊN 8.192 BỘ XỬ LÝ CỦA ASCl Q. (Đây là một cuộc điều tra về 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à một bài giới thiệu tuyệt vời để 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ì mà báo ASCI Q gọi là nhiễu . Jitter là hành vi hệ thống ngẫu nhiên ngăn không cho chạy công việc có thể cảm nhận được. Nó thường là công việc phải được chạy, nhưng nó có thể không có yêu cầu nghiêm ngặt về thời gian khiến nó chạy vào bất kỳ thời điểm cụ thể nào. Bởi vì nó là ngẫu nhiê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 rất khó để chứng minh rằng một nguồn jitter đã biết là nguyên nhân của một vấn đề hiệu suất cụ thể. Các công cụ thường được sử dụng nhất để chẩn đoán nguyên nhân gây ra hiện tượng chập chờn (chẳng hạn như truy tìm hoặc ghi nhật ký) có thể giới thiệu hiện tượng chập chờn của riêng chúng.

Nguồn jitter có kinh nghiệm trong việc triển khai Android trong thế giới thực bao gồm:

Trình lập lịch trình chậm trễ
Trình xử lý ngắt
Mã trình điều khiển chạy quá lâu với quyền ưu tiên hoặc ngắt bị tắt
Softtirqs hoạt động lâu dài
Khóa tranh chấp (ứng dụng, khuôn khổ, trình điều khiển hạt nhân, khóa chất kết dính, khóa mmap)
Tranh chấp về bộ mô tả tệp trong đó luồng có mức độ ưu tiên thấp giữ khóa 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 của giao diện người dùng trong hàng đợi công việc mà nó có thể bị trì hoãn
Quá trình chuyển đổi nhàn rỗi của CPU
Ghi nhật ký
I / O chậm trễ
Tạo quy trình không cần thiết (ví dụ: chương trình phát sóng CONNECTIVITY_CHANGE)
Trục bộ nhớ cache của 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 rung nhất định có thể giảm hoặc không thể giảm khi dung lượng tăng lên. Ví dụ: nếu trình điều khiển để ngắt ngắt trong khi chờ đọc từ một bus i2c, thì nó sẽ mất một khoảng thời gian cố định bất kể CPU đang ở 384MHz hay 2GHz. 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 có jitter. Do đó, các bộ vi xử lý nhanh hơn thường sẽ không cải thiện 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ư dung lượng, jitter gần như hoàn toàn nằm trong miền của nhà cung cấp hệ thống.

Tiêu thụ bộ nhớ

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

Khởi động hệ thống lên 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).
Đảm bảo hạt nhân hỗ trợ điểm theo sched_blocked_reason cũng như các điểm theo dõi khác trong đường dẫn hiển thị biểu thị thời điểm khung được phân phối đến màn hình.
Ghi dấu vết dài của toàn bộ đường ống 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 kiểm tra bóng trong TouchLatency) .
Khắc phục lỗi khung hình được phát hiện trong khối lượng công việc nhẹ và nhất quán.
Lặp lại các bước 3-4 cho đến khi bạn có thể chạy với số khung hình không bị giảm trong hơn 20 giây cùng một lúc.
Chuyển sang các nguồn jank mà người dùng có thể nhìn thấy khác.

Những điều đơn giản khác bạn có thể làm sớm khi mang thiết bị lên bao gồm:

Đảm bảo hạt 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 kích hoạt với danh mục theo dõi lịch trình trong hệ thống và cung cấp chức năng chịu trách nhiệm về chế độ ngủ khi luồng đó đi vào chế độ ngủ liên tục. Nó rất quan trọng đối với phân tích hiệu suất bởi vì giấc ngủ liên tục là một chỉ báo rất phổ biến của jitter.
Đảm bảo bạn có đủ khả năng theo dõi GPU và đường ống hiển thị. Trên các SOC của 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 kích hoạt khi bạn chạy hệ thống để 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 hệ thống tiêu chuẩn, nhưng kết quả hiển thị trong chính dấu vết (để biết chi tiết, hãy xem Tìm hiểu hệ thống ).

Những gì bạn muốn từ loại theo dõi màn hình này là một sự kiện duy nhất cho biết trực tiếp một khung hình đã được chuyển đến màn hình. Từ đó, bạn có thể xác định xem mình đã đạt được khung thời gian thành công hay chưa; nếu sự kiện X n xảy ra ít hơn 16,7ms sau sự kiện X n-1 (giả sử hiển thị 60Hz), thì bạn biết bạn đã không nhảy. 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. Gỡ lỗi jitter là cực kỳ khó 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 chức năng cơ bản của thiết bị hiện diện. Tuy nhiên, việc coi điểm chuẩn như một đạ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 trải 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ị giảm, thời gian khung hình phần trăm thứ 99, v.v.). Điểm chuẩn tổng hợp là điểm chuẩn chỉ 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 đánh cắp 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 có liên quan như một thước đo về hiệu suất do người dùng cảm nhận.

Hãy xem xét hai SOC đang chạy Điểm chuẩn 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 của Điểm chuẩn X trong 10 mili giây và đạt điểm số 10.000.
SOC 2 hiển thị 99% khung hình trong 1ms nhưng 1% khung hình trong 100ms và đạt 19,900, một điểm số tốt 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ó một khung hình không ổn định sau mỗi 1,5 giây hoạt động. Trong khi đó, SOC 1 (SOC chậm hơn theo Điểm chuẩn X) sẽ hoàn toàn linh hoạt.

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

Báo cáo lỗi đôi khi hữu ích để phân tích hiệu suất, nhưng vì chúng rất nặng, chúng hiếm khi hữu ích để gỡ lỗi các vấn đề liên tục lẻ tẻ. Họ 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 nếu lỗi xung quanh quá trình chuyển đổi ứng dụng (được ghi trong một báo cáo lỗi). Các báo cáo lỗi cũng có thể chỉ ra khi hệ thống có vấn đề ở phạm vi rộ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 chỉnh 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ế độ, nhấp vào nút ở góc trên bên phải).

Kiểm tra bóng nảy hoàn toàn đơn giản như nó xuất hiện: 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 vào. Cho đến nay , đây cũng là bài kiểm tra khó nhất để chạy hoàn hảo, nhưng càng gần thời gian chạy mà không có bất kỳ khung hình nào bị giảm, thiết bị của bạn sẽ càng tốt. Kiểm tra bóng nảy rất khó vì nó là một khối lượng công việc nhỏ nhưng hoàn toàn nhất quán chạy ở mức đồng hồ rất thấp (điều này giả sử thiết bị có bộ điều chỉnh tần số; nếu thiết bị đang chạy với đồng hồ cố định, hãy hạ xung CPU / GPU xuống gần mức tối thiểu khi chạy thử nghiệm bóng nảy lần đầu tiên). Khi hệ thống ngừng hoạt động và đồng hồ giảm xuống gần trạng thái không hoạt động, thời gian CPU / GPU yêu cầu trên mỗi khung hình sẽ tăng lên. Bạn có thể xem quả bóng và thấy mọi thứ lộn xộn, và bạn cũng sẽ có thể xem các khung hình bị bỏ lỡ trong systrace.

Bởi vì khối lượng công việc rất nhất quán, bạn có thể xác định hầu hết các nguồn jitter 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 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ì đường ống giao diện người dùng. Các đồng hồ thấp hơn khuếch đại các hiệu ứng của jitter bằng cách làm cho nhiều khả năng rằng bất kỳ jitter nào cũng gây ra một khung hình bị giảm. Do đó, TouchLatency càng gần 60FPS, bạn càng ít có khả năng xảy ra các hành vi hệ thống xấu gây ra tình trạng giật rời rạc, 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) tốc độ đồng hồ luôn bất biến, hãy sử dụng một bài kiểm tra chạy ở đồng hồ rất thấp để chẩn đoán jitter vì những lý do sau:

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