Đá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 của ứng dụng và hoạt động của luồ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à cảm nhận được. Giao diện người dùng (UI) có bị rớt khung hình hoặc kết xuất liên tục ở tốc độ 60 khung hình/giây (FPS) không? Âm thanh có phát mà không bị lỗi hoặc bị giật không? Độ trễ giữa thời điểm người dùng chạm vào màn hình và hiệu ứng xuất hiện trên màn hình là bao lâu?
  • 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).

Chỉ báo đầu tiên dễ nhận thấy hơn chỉ báo 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 mili giây hay 600 mili giây, trừ phi họ đang xem 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ị nhanh, 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ẽ chiếm quyền ưu tiên đối với 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à, quá trình đồng bộ hoá ở chế độ nền, việc 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ó thể chạy công việc 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 hiện tượng giật

Khi xem xét hiệu suất của thiết bị, dung lượng và hiện tượng giật là 2 chỉ số có ý nghĩa.

Dung lượng

Dung lượng là tổng số tài nguyên mà thiết bị sở hữu 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 của toàn bộ 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ì các 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 sẽ thay đổi dựa trên các tài nguyên điện toán trực tuyến. Việc thay đổi tần số CPU/GPU là phương thức chính để thay đổi dung lượng, nhưng cũng có những phương thức khác, chẳng hạn như thay đổi số lượng lõi CPU trực tuyến. Theo đó, dung lượng của một hệ thống tương ứng với mức tiêu thụ điện; việc thay đổi dung lượng luôn dẫn đến sự thay đổi tương tự về mức tiêu thụ điện.

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 này có thể làm rất ít để đ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 để thực hiện việc này chỉ 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).

Hiện tượng giật

Mặc dù bạn có thể dễ dàng thấy dung lượng cần thiết cho một khối lượng công việc, nhưng hiện tượng giật là một khái niệm mơ hồ hơn. Để biết thông tin tổng quan về hiện tượng giật như 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 cuộc điều tra về lý do siêu máy tính ASCI Q không đạt được hiệu suất dự kiến và là 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ữ hiện tượng giật để mô tả những gì bài viết ASCI Q gọi là nhiễu. Hiện tượng giật là hành vi ngẫu nhiên của hệ thống ngăn không cho công việc có thể cảm nhận được chạy. Đây thường là công việc phải chạy, nhưng có thể không có các yêu cầu nghiêm ngặt về thời gian khiến công việc này 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ó để chứng minh sự tồn tại của hiện tượng giật đố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 giật đã 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 giật (chẳng hạn như theo dõi hoặc ghi nhật ký) có thể gây ra hiện tượng giật riêng.

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

  • Độ trễ của trình 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ắt tính năng chiếm quyền ưu tiên hoặc gián đoạn
  • Softirq chạy trong thời gian dài
  • Tranh chấp khoá (ứng dụng, khung, trình điều khiển kernel, khoá trình 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 không cho 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 các hàng đợi công việc nơi mã đó có thể bị trì hoãn
  • Chuyển đổi trạng thái nhàn rỗi của CPU
  • Ghi nhật ký
  • Độ trễ I/O
  • Tạo quy trình không cần thiết (ví dụ: truyền tin CONNECTIVITY_CHANGE)
  • Tình trạng đơ máy do bộ nhớ đệm trang không đủ bộ nhớ trống

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

Cuối cùng, không giống như dung lượng, hiện tượng giật 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 bị đổ lỗi 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ụ này có thể gây ra hiện tượng dao động thông qua chi phí lowmemorykiller, khởi động lại dịch vụ và tình trạng đơ máy 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 cải tiến khác có mục tiêu giúp tránh được 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 có 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 có thể thấy là 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à hiện tượng giật) hoặc là vấn đề về ứng dụng, nên có quá nhiều biến 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à thực hiện các 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 quả trên toàn hệ thống.

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

  1. Khởi động hệ thống đến 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 trình điều khiển tần số (nếu bạn thay đổi chế độ cài đặt của trình điều khiển tần số, hãy lặp lại tất cả các bước bên dưới).
  2. Đảm bảo kernel 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. Theo dõi quy trình giao diện người dùng trong thời gian dài (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 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 20 giây trở lên tại một thời điểm.
  6. Chuyển sang các nguồn gây ra hiện tượng giật khác mà người dùng có thể thấy.

Bạn cũng có thể thực hiện những việc đơn giản khác ngay từ đầu trong quá trình đưa thiết bị vào hoạt động, bao gồm:

  • Đảm bảo kernel 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 việc ngủ khi luồng đó chuyển sang trạng thái ngủ không gián đoạn. Điểm theo dõi này rất quan trọng đối với việc phân tích hiệu suất vì trạng thái ngủ không gián đoạn là một chỉ báo rất phổ biến về hiện tượng giật.
  • Đảm bảo bạn có đủ thông tin theo dõi cho GPU và 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 các 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 một khung hình đã được gửi đến màn hình. Từ đó, bạn có thể xác định xem mình đã đạt được thời gian khung hình hay chưa; nếu sự kiện Xn xảy ra ít hơn 16,7 mili giây 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 để nhận các tín hiệu đó. Việc gỡ lỗi hiện tượng giật 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 hữu ích để đảm bảo chức năng cơ bản của thiết bị hiện có. Tuy nhiên, việc coi điểm chuẩn là đại diện cho hiệu suất cảm nhận được của thiết bị là không hữu ích.

Dựa trên kinh nghiệm với các 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 chỉ là điểm chuẩn về dung lượng; hiện tượng giật 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ừ thao tác hàng loạt của điểm chuẩn. Do đó, điểm số đ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 Điểm chuẩn X kết xuất 1000 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ố thấp hơn thì tốt hơn).

  • SOC 1 kết xuất mỗi khung hình của Điểm chuẩn X trong 10 mili giây và đạt điểm số 10.000.
  • SOC 2 kết xuất 99% khung hình trong 1 mili giây nhưng 1% khung hình trong 100 mili giây và đạt điểm số 19.900, một điểm số tốt 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ì bạn sẽ không thể sử dụng SOC 2. 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 Điểm chuẩn X) sẽ hoàn toàn mượt mà.

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ì báo cáo lỗi rất nặng, nên hiếm khi hữu ích cho việc gỡ lỗi các vấn đề về hiện tượng giật không thường xuyên. Báo cáo lỗi 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 có vấn đề rộng hơn với hệ thống 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ỳ ưu tiên được dùng cho Pixel và Pixel XL. Bạn có thể tìm thấy khối lượng công việc này tại frameworks/base/tests/TouchLatency và có 2 chế độ: độ trễ khi chạm và 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).

Kiểm thử 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ể dữ liệu đầu vào của người dùng. Đây thường cũng là bài kiểm thử khó nhất để chạy hoàn hảo, nhưng càng gần với việc chạy mà không bị rớt khung hình, thì thiết bị của bạn sẽ càng tốt hơn. Kiểm thử bóng nảy 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 ở tốc độ xung nhịp rất thấp (điều này giả định thiết bị có trình điều khiển tần số; nếu thiết bị đang chạy với tốc độ xung nhịp cố định, hãy giảm tốc độ xung nhịp của CPU/GPU xuống gần mức tối thiểu khi chạy kiểm thử bóng nảy lần đầu tiên). Khi hệ thống ngừng hoạt động và tốc độ xung nhịp giảm xuống gần mức nhàn rỗi, 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 hiện tượng giật, đồng thời 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 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 có thể 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. Tốc độ xung nhịp thấp hơn sẽ khuếch đại tác động của hiện tượng giật bằng cách khiến mọi hiện tượng giật đều có khả năng gây ra khung hình bị rớt. Do đó, TouchLatency càng gần với 60 khung hình/giây, thì bạn càng ít có khả năng 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 không thường xuyên và khó tái tạo trong các ứng dụng lớn hơn.

Vì hiện tượng giật 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 hiện tượng giật vì những lý do sau:

  • Không phải hiện tượng giật nào cũng không đổi theo tốc độ xung nhịp; nhiều nguồn chỉ tiêu thụ thời gian CPU.
  • Trình điều khiển sẽ đưa thời gian khung hình trung bình đến gần thời hạn bằng cách giảm tốc độ xung nhịp, 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 để rớt khung hình.