Ngân sách bộ nhớ hệ thống

Trong Android 17 trở lên, nền tảng này quản lý bộ nhớ của quy trình hệ thống bằng hai cơ chế cgroup v2 bổ sung của Linux, hoạt động cùng với Trình giới hạn bộ nhớ chung của ứng dụng:

• Ngưỡng bảo vệ trình nền hệ thống (SystemMemoryBudgetManager có memory.min): Các lượt đặt trước memory.min cgroup v2 tự điều chỉnh (được đặt thành 90% tập hợp hoạt động thường trú đã ổn định của mỗi trình nền và được giới hạn trên toàn hệ thống ở mức 10% tổng RAM vật lý) bảo vệ các trình nền tương tác quan trọng và quy trình shell (system_server, surfaceflinger, HAL đồ hoạ composer, audioserver, cameraserver, netd, SystemUI và Trình chạy chính) khi có áp lực về bộ nhớ, thay thế việc ghim tệp tĩnh PinnerService mlock.
• Giới hạn bộ nhớ của ứng dụng hệ thống (<memory-budget> có memory.high): Giới hạn mềm memory.high của cgroup phiên bản 2 được điều chỉnh theo khối lượng công việc (thường là 30 MB đến 190 MB) được khai báo trong tệp kê khai cho các ứng dụng hệ thống cố định và chạy trong nền (Bluetooth, Nfc, CalendarProvider, Traceur, MediaProvider, :PhotoPicker, NetworkStack, AppSearch và TeleService) chủ động thu hồi bộ nhớ đệm trang tệp không hoạt động và vùng nhớ khối xếp ẩn danh sau khi tăng đột biến trước khi xảy ra áp lực bộ nhớ toàn cục.

Bảng sau đây so sánh hai cơ chế:

Để biết thêm thông tin về cú pháp <memory-budget>, thuộc tính XML, API thời gian chạy và lưu giữ hồ sơ bộ nhớ hệ điều hành, hãy xem bài viết Đặt ngân sách bộ nhớ ứng dụng và Tìm hiểu và khắc phục sự cố về bộ nhớ Android.

Bảo vệ các trình nền tương tác quan trọng bằng SystemMemoryBudgetManager

SystemMemoryBudgetManager giữ cho các quy trình nằm trực tiếp trên đường dẫn tương tác của người dùng nằm trong RAM vật lý khi bộ nhớ bị áp lực. Thay vì ghim danh sách tĩnh gồm các tệp APK, ODEX và VDEX vào bộ nhớ bằng mlock (như PinnerService thực hiện cho config_defaultPinnerServiceFiles và config_pinnerHomePinBytes), SystemMemoryBudgetManager chỉ định các mức tối thiểu memory.min của cgroup v2 động cho các quy trình sau:

• Phân đoạn hệ thống cốt lõi (/sys/fs/cgroup/system): system_server, surfaceflinger, HAL đồ hoạ composer, audioserver, cameraserver và netd, cùng với mọi trình nền hệ thống gốc hoặc trình nền của nhà cung cấp dành riêng cho kiểu dáng được liệt kê trong config_systemMemoryBudgetAdditionalSystemProcesses (ví dụ: android.hardware.perceptionhost và auracamerahal trên thiết bị XR).
• Phần ứng dụng tương tác (/sys/fs/cgroup/apps): Quy trình chính của gói SystemUI đã định cấu hình (config_systemUi) và quy trình chính của người dùng hiện tại giữ vai trò Trang chủ.

Việc bảo vệ người giữ vai trò Home cùng với config_systemUi đảm bảo phạm vi bao phủ trên tất cả kiểu dáng. Trên các kiểu dáng mà config_systemUi là một gói tương thích gọn nhẹ (chẳng hạn như Wear OS, nơi mặt đồng hồ, thông báo và thẻ thông tin chạy trong ứng dụng Home), shell dành cho người dùng vẫn nhận được sự bảo vệ đầy đủ của tập hợp đang hoạt động. Nếu ý định Home phân giải thành gói config_systemUi, thì quy trình sẽ được bảo vệ một lần. Chỉ quy trình chính của mỗi gói (processName == packageName) mới nhận được mức bảo vệ tối thiểu, vì vậy, các quy trình phụ trợ (chẳng hạn như :screenshot) không tiêu tốn ngân sách bảo vệ.

Chính sách tự điều chỉnh và uỷ quyền cgroup ba cấp

Vì tập hợp hoạt động của một trình nền tương tác thay đổi rất nhiều tuỳ theo kiểu dáng và dung lượng RAM (ví dụ: SystemUI sử dụng khoảng 45 MB trên đồng hồ thông minh, 60 MB trên điện thoại 6 GB và 180 MB trên điện thoại 16 GB), nên bảng tìm kiếm tĩnh cho mỗi thiết bị sẽ không ổn định. Thay vào đó, SystemMemoryBudgetManager lấy trực tiếp các giá trị tối thiểu từ dấu vết thường trú của từng quy trình bằng cách sử dụng 3 hằng số:

Trong bộ điều khiển bộ nhớ cgroup v2 của Linux (mm/memcontrol.c:effective_protection), mức bảo vệ memory.min hiệu quả của một cgroup lá được giới hạn bởi memory.min được định cấu hình trên cgroup mẹ và cgroup tổ tiên của nó. Việc chỉ đặt memory.min trên thư mục pid_<pid> lá trong khi uid_<uid>/memory.min là 0 sẽ không mang lại hiệu quả bảo vệ. Ngược lại, việc đặt memory.min cố định chỉ trên lát cắt trên cùng /sys/fs/cgroup/system sẽ phân phối biện pháp bảo vệ chưa được xác nhận quyền sở hữu trên tất cả UID và quy trình con theo tỷ lệ (memory_recursiveprot), cho phép các quy trình chẩn đoán hoặc quy trình phụ chia sẻ uid_1000 (android.uid.system) để loại bỏ biện pháp bảo vệ khỏi surfaceflinger và audioserver.

Để cung cấp khả năng tách biệt chính xác cho từng trình nền, SystemMemoryBudgetManager sẽ ghi bảo vệ trên cả ba cấp của hệ phân cấp cgroup v2 trong mỗi lần làm mới, như minh hoạ trong hình 1:

1. Nút quy trình lá (pid_<pid>/memory.min): Đặt thành mức tối thiểu của tập hợp đang hoạt động 90% (đã điều chỉnh theo tỷ lệ) của quy trình.
2. Nút UID (uid_<uid>/memory.min): Đặt thành tổng chính xác của các tầng lá được quản lý pid_*, vì vậy, các quy trình không được quản lý chia sẻ UID đó (chẳng hạn như các trình nền AID_SYSTEM hoặc gói sharedUserId="android.uid.system" khác) có memory.min = 0 và không thể yêu cầu bảo vệ.
3. Lát cắt cấp cao nhất (/sys/fs/cgroup/system/memory.min và /sys/fs/cgroup/apps/memory.min): Đặt thành tổng chính xác của các phần tử con uid_*. Mọi giá trị memory.low cũ trên các nút được quản lý đều được xoá thành 0 và mọi thư mục uid_* được quản lý trong lần làm mới trước đó (chẳng hạn như Trình chạy màn hình chính trước đó sau khi người dùng chuyển đổi trình chạy) đều được đặt lại thành 0.

Hình 1. Uỷ quyền mức bảo vệ ba cấp trên các lát cắt cgroup.

Lý do memory.min được dùng thay vì memory.low trên nhân MGLRU

Trong LRU đa thế hệ (MGLRU, công cụ lấy lại trang mặc định trên Android 6.6 và các nhân mới hơn), memory.low và memory.min hoạt động khác nhau trong mm/vmscan.c:shrink_one:

• memory.low (trì hoãn một lần): Một cgroup có mức sử dụng dưới memory.low được xoay vòng đến cuối LRU memcg (MEMCG_LRU_TAIL) và bị bỏ qua trong một lần thu hồi. Trong lần tiếp theo khi áp lực bộ nhớ kéo dài, hạt nhân sẽ thu hồi toàn bộ cgroup và ghi lại một sự kiện MEMCG_LOW. Trong các bài kiểm thử áp lực trên thiết bị thực với một ứng dụng tiêu tốn bộ nhớ ẩn danh tăng lên đến 85% RAM thực, memory.low cho phép SystemUI trên đồng hồ thông minh thu gọn từ ~45 MB xuống còn ~5 đến 10 MB và audioserver trên thiết bị gập 16 GB giảm từ 15 MB xuống còn 2 MB so với mức tối thiểu ~14 MB.
• memory.min (ngưỡng bảo vệ cứng): Một cgroup có mức sử dụng dưới memory.min sẽ bị bỏ qua trong quá trình thu hồi chung. Như trong hình 2, trong cùng một khối lượng công việc áp lực RAM 85%, memory.min chỉ loại bỏ 10% phần đuôi ít hoạt động nhất của mỗi trình nền và giữ SystemUI, surfaceflinger và audioserver ở mức tối thiểu 90% mà không có lỗi lặp lại ẩn danh và không tăng số lần chấm dứt quy trình lmkd.

memory.min cung cấp một mức đặt trước vật lý cứng khớp với mức bảo vệ của tính năng ghim PinnerService mlock mà nó thay thế, với ưu điểm là LRU nhân (thay vì danh sách tệp tĩnh) sẽ chọn mã nóng, vùng nhớ khối xếp và trang đồ hoạ nào sẽ được lưu trú.

Hình 2. Duy trì tập hợp hoạt động của trình nền khi áp lực bộ nhớ tăng lên.

Làm nóng trước khi khởi động và thu hồi bộ nhớ đệm tệp chưa được ánh xạ sau khi khởi động

Việc thay thế PinnerService vĩnh viễn mlock của config_defaultPinnerServiceFiles đòi hỏi phải điều phối hai hành vi trong thời gian khởi động:

• Làm nóng trước khi khởi động trong nền một lần (PinnerService): Việc bỏ qua PinnerService mlock mà không làm nóng bộ nhớ đệm trang sẽ chuyển khoảng 95 MB dữ liệu đọc ổ đĩa APK, ODEX và VDEX của SystemUI sang đường dẫn khởi động đồng bộ khi SystemUI khởi động (OnBootPhase_550), khiến thời gian hoàn tất khởi động tăng thêm từ 300 đến 450 mili giây. Việc gọi madvise(MADV_WILLNEED) là chưa đủ vì force_page_cache_ra trong hạt nhân sẽ kẹp một lệnh gọi MADV_WILLNEED vào một cửa sổ đọc trước (thường là 128 KB đến 2 MB). Thay vào đó, khi SystemMemoryBudgetManager.shouldSkipDefaultSystemPinning đang hoạt động, PinnerService sẽ liên kết từng tệp trong config_defaultPinnerServiceFiles trên một luồng trong nền trong onStart, đồng bộ hoá tệp vào bộ nhớ đệm trang bằng Os.mlock và gọi ngay Os.munlock, munmap và close. Cách này giúp duy trì thời gian khởi động nhanh trong khi không để lại byte nào bị khoá vĩnh viễn, nhờ đó, các trang khởi động nguội có thể bị loại bỏ sau này.
• Loại trừ và thu hồi bộ nhớ đệm quét gói khởi động system_server: Trong quá trình khởi động, PackageManagerService sẽ quét các tệp APK đã cài đặt, để lại 1,5 đến 2,5 GB bộ nhớ đệm trang tệp chưa được liên kết nguội được tính vào cgroup system_server. Nếu được đưa vào phép tính memory.min của system_server, thì bộ nhớ đệm khởi động nguội đó sẽ lấp đầy giới hạn RAM chung 10% và giảm tỷ lệ tương ứng với mức bảo vệ tối thiểu của surfaceflinger, SystemUI và audioserver. Để ngăn tình trạng thiếu hụt giới hạn, SystemMemoryBudgetManager đọc memory.stat cho system_server, tính toán bộ nhớ đệm tệp chưa được liên kết dưới dạng max(0, file - shmem - file_mapped) và trừ bộ nhớ đệm chưa được liên kết đó khỏi memory.current trước khi tính toán mức sàn 90%, như minh hoạ trong hình 3. Ngoài ra, 10 giây sau PHASE_BOOT_COMPLETED, trình quản lý sẽ thực hiện một lần ghi <unmapped_file> swappiness=0 vào nút memory.reclaim của system_server trên Linux 6.2 và các nhân mới hơn để chủ động loại bỏ bộ nhớ đệm quét gói không hoạt động mà không cần hoán đổi vùng nhớ khối xếp ẩn danh hoặc loại bỏ DEX và trang mã được liên kết. Trên các hạt nhân cũ (chẳng hạn như android14-6.1) từ chối swappiness=0 bằng EINVAL, trình quản lý sẽ bỏ qua thao tác ghi memory.reclaim thay vì quay lại thao tác ghi thu hồi không đủ điều kiện để hoán đổi vùng nhớ khối xếp ẩn danh trong quá trình khởi động.

Hình 3. Hội tụ tầng bảo vệ và thu hồi bộ nhớ đệm sau khi khởi động.

Yêu cầu về hạt nhân và lớp phủ cấu hình thiết bị

SystemMemoryBudgetManager dựa vào mem_cgroup_calculate_protection trong nhân Linux để truyền memory.min qua các nhóm điều khiển lồng nhau. Nhân Android chung android15-6.6 và android16-6.12 có hỗ trợ đầy đủ tính năng bảo vệ lồng nhau của MGLRU ngay từ đầu. Các thiết bị chạy android14-6.1 đã bật MGLRU cần có 3 bản backport ngược dòng trong mm/vmscan.c và mm/memcontrol.c để các lát cắt trung gian trống và cgroup UID truyền biện pháp bảo vệ đến các cgroup quy trình lá:

• 30d77b7eef01 (mm/mglru: fix ineffective protection calculation)
• 8aa420617918 (mm/mglru: respect min_ttl_ms with memcgs)
• adb8213014b2 (mm: memcg: fix stale protection of reclaim target memcg)

OEM có thể tuỳ chỉnh hoặc tắt SystemMemoryBudgetManager bằng cách sử dụng các lớp phủ tài nguyên khung sau:

• config_systemMemoryBudgetLowKb (số nguyên, KB): 0 (mặc định) giới hạn tổng của tất cả các tầng memory.min ở mức 10% tổng dung lượng RAM thực. Giá trị dương đặt giới hạn rõ ràng theo KB và giá trị âm tắt SystemMemoryBudgetManager trên thiết bị (giữ lại tính năng ghim mlock tĩnh PinnerService cũ).
• config_systemMemoryBudgetHighKb (số nguyên, KB): 0 (mặc định) giữ nguyên /sys/fs/cgroup/system/memory.high ở mức max. Giá trị dương đặt mức trần cho phần trên cùng memory.high (phải lớn hơn hoặc bằng mức sàn).

• config_systemMemoryBudgetAdditionalSystemProcesses (string-array): Liệt kê tên của các trình nền hệ thống hoặc nhà cung cấp gốc có độ trễ nghiêm trọng khác trong /sys/fs/cgroup/system (khớp với /proc/<pid>/comm hoặc tên cơ sở của argv[0] trong /proc/<pid>/cmdline cho UID của hệ thống và nhà cung cấp trong 10000) để bảo vệ bằng 90% memory.min cùng với 6 trình nền hệ thống mặc định. Sử dụng lớp phủ này thay vì đặt memory.min trong init.rc vì SystemMemoryBudgetManager tính toán lại uid_<uid>/memory.min dưới dạng tổng của các quy trình lá được quản lý và xoá các nút uid_* không được quản lý trong mỗi lần làm mới. Ví dụ: một thiết bị XR có thể bảo vệ trình nền HAL của camera và tính năng theo dõi không gian bằng lớp phủ sau:

  <string-array translatable="false" name="config_systemMemoryBudgetAdditionalSystemProcesses">
      <item>android.hardware.perceptionhost</item>
      <item>auracamerahal</item>
  </string-array>
  

• config_systemUi (chuỗi): Tên gói của ứng dụng SystemUI trên nền tảng, được phân giải bằng MATCH_SYSTEM_ONLY.

Để kiểm tra các tầng SystemMemoryBudgetManager đang hoạt động và các nút cgroup trên một thiết bị, hãy chạy:

# Inspect policy state, resolved PIDs, and applied floors in dumpsys meminfo
adb shell dumpsys meminfo | sed -n '/System Memory Budgets/,$p'
# Inspect raw cgroup v2 memory.min nodes across the system and apps slices
adb shell head -n 1 \
  /sys/fs/cgroup/system/memory.min \
  /sys/fs/cgroup/system/uid_*/memory.min \
  /sys/fs/cgroup/system/uid_*/pid_*/memory.min \
  /sys/fs/cgroup/apps/memory.min \
  /sys/fs/cgroup/apps/uid_*/memory.min \
  /sys/fs/cgroup/apps/uid_*/pid_*/memory.min

Giới hạn các ứng dụng hệ thống chạy ngầm và liên tục bằng ngân sách bộ nhớ

Mặc dù SystemMemoryBudgetManager bảo vệ trình nền tương tác khỏi việc thu hồi bằng cách sử dụng các tầng memory.min, nhưng nhiều ứng dụng hệ thống và dịch vụ nền tảng đặc quyền khác chạy trong nền trong thời gian dài dưới dạng quy trình PERSISTENT, dịch vụ nền trước liên kết hoặc trình cung cấp nội dung thường xuyên được truy vấn. Nếu không có giới hạn bộ nhớ rõ ràng, các quy trình này sẽ không bị ràng buộc cho đến khi đạt đến giới hạn Trình giới hạn bộ nhớ nhiều gigabyte (chẳng hạn như 4 GB đến 10 GB cho ứng dụng hiển thị và 2 GB đến 5 GB cho ứng dụng chạy trong nền) hoặc áp lực bộ nhớ chung kích hoạt hoạt động kswapd và trình tắt ứng dụng khi bộ nhớ thấp (lmkd) trên toàn hệ thống.

Nếu không bị ràng buộc, các quy trình hệ thống trong nền thường tích luỹ một lượng lớn bộ nhớ nguội không thuộc tập hợp hoạt động của chúng:

• Bộ nhớ đệm trang tệp không giới hạn: Các dịch vụ lập chỉ mục nội dung nghe nhìn, tìm kiếm cơ sở dữ liệu hoặc đồng bộ hoá lịch và bảng nhà cung cấp (chẳng hạn như AppSearch, MediaProvider và CalendarProvider) ánh xạ hoặc truyền trực tuyến qua các tệp lớn trên ổ đĩa. Nếu không có giới hạn memory.high của nhóm điều khiển, thì các trang sạch được hỗ trợ bằng tệp từ các lượt đọc một lần sẽ vẫn được tính vào nhóm điều khiển của quy trình vô thời hạn, tiêu tốn hàng trăm megabyte RAM vật lý.
• Giữ lại vùng nhớ khối xếp ẩn danh sau khi tăng đột biến: Các dịch vụ gặp phải tình trạng tăng đột biến tạm thời, chẳng hạn như Bluetooth tăng đột biến về âm thanh và khám phá BLE, NetworkStack xác thực TLS của trang xác thực hoặc trình trợ giúp giao diện người dùng chuyển sang chế độ nền, có thể giữ lại các trang vùng nhớ khối xếp ẩn danh không hoạt động trong thời gian dài sau khi quá trình tăng đột biến hoàn tất.

Việc áp dụng các nội dung khai báo <memory-budget> đã hiệu chỉnh (giới hạn mềm memory.high, thường là 30 MB đến 190 MB) cho các ứng dụng hệ thống mang lại hai lợi ích chính:

• Thu hồi trang cục bộ, chủ động: Khi một quy trình hệ thống vượt quá ngân sách memory.high đã định cấu hình, nhân Linux sẽ hướng việc thu hồi trang cụ thể đến cgroup đó, loại bỏ các trang được hỗ trợ tệp lạnh trước và nén các trang ẩn danh không hoạt động vào ZRAM mà không cần chờ áp lực bộ nhớ thiết bị chung.
• Tăng dung lượng RAM cho các ứng dụng trên nền trước và nhóm ứng dụng được lưu vào bộ nhớ đệm: Việc giới hạn bộ nhớ đệm tệp nguội trên các dịch vụ hệ thống luôn bật sẽ giải phóng hàng chục đến hàng trăm megabyte RAM vật lý trên thiết bị, giảm hiện tượng giật giao diện người dùng, giảm áp lực khi khởi động camera và duy trì nhiều ứng dụng của người dùng hơn ở trạng thái lưu vào bộ nhớ đệm.

Định cấu hình ngân sách bộ nhớ của ứng dụng hệ thống

Ứng dụng hệ thống sử dụng cùng một cú pháp tệp kê khai <memory-budget>, phân tầng trạng thái quy trình, điều chỉnh tỷ lệ mật độ hiển thị và quy tắc phân giải mệnh đề khớp cuối cùng như các ứng dụng thông thường. Để xem danh sách đầy đủ các thuộc tính, hãy xem Tài liệu tham khảo về thuộc tính XML.

OEM có thể khai báo các phần tử <memory-budget> ngay bên trong AndroidManifest.xml của ứng dụng hệ thống hoặc hợp nhất các phần tử đó từ một tệp XML riêng biệt bằng cách sử dụng thuộc tính additional_manifests trong Android.bp. Theo quy ước, AOSP lưu trữ ngân sách ứng dụng hệ thống tham chiếu trong các tệp *-budget.xml độc lập (trong frameworks/base/core/memory_budgets/ cho các gói nền tảng cốt lõi hoặc cùng với các mô-đun riêng lẻ như packages/modules/NetworkStack/memory_budgets/, packages/modules/AppSearch/apk/ và packages/services/Telephony/) và đính kèm chúng với additional_manifests:

android_app {
    name: "TeleService",
    manifest: "AndroidManifest.xml",
    additional_manifests: ["Telephony-budget.xml"],
    // ...
}

Phạm vi cấp gói (UID) so với cấp quy trình (PID)

Việc bạn khai báo ngân sách cơ sở ở cấp gói (<application>) hay ngân sách đa quy trình (<processes><process>) sẽ xác định xem hạt nhân có thực thi memory.high ở cấp cgroup UID (/sys/fs/cgroup/uid_<uid>/memory.high) hay ở cấp cgroup theo PID (/sys/fs/cgroup/uid_<uid>/pid_<pid>/memory.high) hay không, như minh hoạ trong hình 4:

• Ngân sách cấp gói (<application>): Sử dụng khi APK chạy một quy trình duy nhất theo UID chuyên dụng của riêng nó (ví dụ: Bluetooth, Nfc, NetworkStack, CalendarProvider, Traceur hoặc AppSearch).
• Ngân sách cấp quy trình (<processes><process>): Sử dụng khi APK chia sẻ android:sharedUserId (chẳng hạn như android.uid.phone có UID 1001 hoặc android.uid.system có UID 1000) với các gói hệ thống khác để các quy trình khác chia sẻ UID đó không bị điều tiết cùng nhau, hoặc khi một APK chạy nhiều quy trình có vai trò bộ nhớ riêng biệt (ví dụ: trình nền MediaProvider trong nền và quy trình con giao diện người dùng :PhotoPicker).

Hình 4. Giới hạn bộ nhớ cấp UID so với cấp PID.

Ví dụ sau đây minh hoạ MediaProvider-budget.xml, trong đó xác định phạm vi ngân sách theo cấp RAM cho quy trình MediaProvider mặc định (<process>) và ngân sách theo tỷ lệ hiển thị cho quy trình giao diện người dùng :PhotoPicker. Mỗi thuộc tính android:maxDeviceRamMb khớp với các thiết bị có tổng RAM vật lý (MemTotal) bằng hoặc thấp hơn ngưỡng MB đã chỉ định (hoặc áp dụng cho bất kỳ dung lượng RAM nào khi bị bỏ qua). Các mệnh đề được sắp xếp từ mặc định không ràng buộc xuống ngưỡng maxDeviceRamMb nhỏ nhất để quy tắc phân giải mệnh đề khớp cuối cùng chọn cấp áp dụng chặt chẽ nhất:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
          package="com.android.providers.media.module">
    <uses-sdk android:targetSdkVersion="10000" />
    <application>
        <processes>
            <process>
                <memory-budget
                    android:maxMb="85" />
                <memory-budget
                    android:maxMb="75"
                    android:maxDeviceRamMb="12288" />
                <memory-budget
                    android:maxMb="60"
                    android:maxDeviceRamMb="8192" />
            </process>
            <process android:process=":PhotoPicker">
                <memory-budget
                    android:maxMb="85"
                    android:additionalBytesPerDisplayPixel="25" />
            </process>
        </processes>
    </application>
</manifest>

Cách hiệu chỉnh ngân sách tham chiếu của AOSP trên thiết bị Google Pixel

Ngân sách bộ nhớ của ứng dụng hệ thống tham chiếu trong AOSP được hiệu chỉnh trên các thiết bị Google Pixel có RAM vật lý từ 6 GB đến 16 GB (bao gồm cả điện thoại, thiết bị gập và máy tính bảng có RAM 6 GB, 8 GB, 12 GB và 16 GB) và độ phân giải màn hình từ ~1, 2 MP (720×1600) đến ~4, 5 MP (2076×2152).

Quá trình hiệu chỉnh kết hợp hai nguồn dữ liệu bổ sung: dữ liệu đo từ xa của trường cgroup v2 trên toàn bộ nhóm thiết bị và các lần quét memory.high trên thiết bị thực được kiểm soát trong các hành trình quan trọng của người dùng (CUJ).

Phân tích dữ liệu đo từ xa cgroup v2 trên toàn bộ nhóm máy chủ

Ảnh chụp nhanh định kỳ của cgroup phiên bản 2 được thu thập trên toàn bộ nhóm thiết bị và được phân chia theo cấp RAM vật lý (≤8 GB, 12 GB và ≥16 GB) và bộ chứa trạng thái quy trình (foreground, perceptible, background và cached). Có 6 nguyên tắc hướng dẫn việc phân tích thống kê:

• Phân tách memory.current thành tập hợp đang hoạt động so với bộ nhớ đệm tệp có thể thu hồi: Vì memory.high chi phối mức phí cgroup thường trú (memory.current), nên mỗi ảnh chụp nhanh được phân tách bằng memory.stat thành vùng nhớ khối xếp ẩn danh (anon), các trang ẩn danh được hoán đổi (swap) và bộ nhớ đệm trang dựa trên tệp (file), như minh hoạ trong hình 5. Tổng nhu cầu ẩn danh không thể nén (anon + swap tại P99) thiết lập mức tối thiểu của tập hợp đang hoạt động cho ngân sách để quy trình không có nguy cơ làm cạn kiệt ZRAM, trong khi khoảng cách lớn giữa memory.current P99 và anon + swap P99 cho biết bộ nhớ đệm trang tệp mà memory.high có thể thu hồi, miễn là bộ nhớ đệm đó chưa được ánh xạ và không hoạt động.
• Tính đến bộ nhớ mà memory.high không thể lấy lại: Không phải tất cả tệp và bộ nhớ dùng chung đều là bộ nhớ đệm không hoạt động. Các trang bị khoá (unevictable trong memory.stat, chẳng hạn như bộ nhớ dùng chung bị khoá bằng mlock hoặc RAM khách bị khoá của một máy ảo có quy trình lưu trữ được tính vào cgroup của ứng dụng) đặt một mức sàn cứng trong ngân sách và các trang được liên kết (file_mapped) thường là một phần của tập hợp hoạt động đang hoạt động. Kiểm tra unevictable, shmem và file_mapped trước khi coi bộ nhớ tệp là có thể lấy lại. Ví dụ: khoảng 100 MB bộ nhớ AppSearch bị khoá và không thể loại bỏ, vì vậy, ngân sách của bộ nhớ này bao gồm mức tối thiểu đó cộng với tập hợp hoạt động của máy chủ lưu trữ nóng, với khoảng trống để vùng bị khoá tăng lên.
• Lọc bỏ tình trạng pha loãng trạng thái rảnh: Nhà cung cấp nội dung (CalendarProvider) và công cụ cho nhà phát triển theo yêu cầu (Traceur) dành 70% đến 99,9% ảnh chụp nhanh trường ở trạng thái rảnh ở mức ~1 MB đến 3 MB. Việc tính toán phân vị thô trên tất cả ảnh chụp nhanh sẽ làm giảm đáng kể số liệu ước tính P95 và P99. Thay vào đó, phân vị và khoảng tin cậy được tính toán dựa trên ảnh chụp nhanh hoạt động không bị pha loãng (lọc ra ảnh chụp nhanh CACHED và ảnh chụp nhanh cơ sở rảnh).
• Sử dụng khoảng tin cậy theo cụm thiết bị: Vì một thiết bị đóng góp nhiều ảnh chụp nhanh định kỳ theo thời gian, nên việc coi ảnh chụp nhanh là mẫu độc lập sẽ làm giảm độ không chắc chắn của đuôi. Tất cả các giá trị ước tính tập hợp đang hoạt động P95 và P99 đều được đánh giá bằng cách sử dụng khoảng tin cậy 95% được phân cụm theo thiết bị (sử dụng số lượng thiết bị riêng biệt N_dev làm kích thước mẫu hiệu quả).
• Tính đến các mức tăng đột biến tạm thời bằng memory.peak: Việc lấy mẫu định kỳ có thể bỏ lỡ các mức tăng đột biến ngắn hạn, có mức phân bổ cao (chẳng hạn như NetworkStack xác thực TLS của trang xác thực và các lượt thăm dò DNS đồng thời, hoặc Bluetooth khởi chạy A2DP và BLE). Đối với các dịch vụ có mức sử dụng tăng đột biến, ngân sách được điều chỉnh để bao gồm phân vị thứ 90 đến 95 của mức sử dụng cao nhất của nhân memory.peak trong suốt thời gian hoạt động trên các cấp RAM.
• Xác nhận rằng một cấp RAM phản ánh RAM, chứ không phải thế hệ thiết bị: Các thiết bị mới hơn có xu hướng có cả nhiều RAM và nhiều tính năng hơn, vì vậy, một tập hợp đang hoạt động tăng lên theo cấp RAM có thể thực sự tăng lên theo tính năng. Trước khi thêm bậc maxDeviceRamMb, hãy phân chia dữ liệu theo mẫu thiết bị. Ví dụ: com.android.phone đạt cùng một P99 anon + swap (~85 đến 90 MB) trên điện thoại 12 GB và 16 GB cùng thế hệ, trong khi điện thoại gập 12 GB cũ hơn sử dụng 40 MB. Do đó, ngân sách của nó sử dụng một giá trị duy nhất không có cấp RAM, nhờ vậy mà thiết bị có RAM thấp hơn cung cấp các tính năng điện thoại mới hơn sẽ không bị thiếu ngân sách.

Hình 5. Tập hợp đang hoạt động so với bộ nhớ đệm tệp có thể lấy lại.

CUJ trên thiết bị thực và quét tỷ lệ hiển thị

Để xác thực ngân sách dựa trên dữ liệu đo từ xa và hiệu chỉnh ngân sách theo tỷ lệ hiển thị (chẳng hạn như :PhotoPicker) và ngân sách nền theo trạng thái cụ thể (chẳng hạn như Traceur), các lần quét memory.high trực tiếp đã được thực hiện trên các thiết bị thực có RAM từ 6 GB đến 16 GB:

• Tìm điểm uốn không có lỗi lặp lại: Trong khi thực hiện các CUJ toàn diện (chẳng hạn như lướt nhanh lưới ảnh, duyệt xem album, vuốt xem trước ảnh và video có độ phân giải cao ở chế độ toàn màn hình, cũng như ghi và lưu dấu vết), memory.high được giảm dần trong khi đo lường bộ đếm cgroup memory.stat (workingset_refault_anon, workingset_refault_file, pgscan và pgsteal) và memory.events (high). Như minh hoạ trong hình 6, ngân sách tối ưu nằm ngay trên điểm uốn không có lỗi lặp lại. Điểm uốn không lỗi tham chiếu lại là ngưỡng mà tại đó hạt nhân lấy lại bộ nhớ đệm tệp một lần không hoạt động (pgsteal > 0) mà không kích hoạt lỗi trang liên tục của tập hợp hoạt động (workingset_refault == 0).
• Xác thực tỷ lệ pixel hiển thị trên các độ phân giải: Thử nghiệm :PhotoPicker trên 4 độ phân giải màn hình vật lý và mô phỏng từ ~1,2 MP (720×1600) đến ~4,5 MP (màn hình bên trong mở ra 2076×2152) xác nhận rằng tập hợp hoạt động bitmap Glide và ViewPager2 đang hoạt động mở rộng tuyến tính theo số lượng pixel hiển thị. Đường cơ sở không hiển thị cũng khác nhau tuỳ theo thiết bị: với số lượng pixel gần như giống nhau, điểm uốn không có lỗi tải lại là khoảng 140 MB trên màn hình ngoài của thiết bị gập 16 GB so với 110 đến 125 MB trên điện thoại 6 GB. Mức cơ sở 85 MB cộng với 25 byte cho mỗi pixel hiển thị (android:maxMb="85" và android:additionalBytesPerDisplayPixel="25") luôn cao hơn mức đo được trên mọi màn hình được thử nghiệm (~110 MB trên HD+, ~145 MB trên FHD+ và ~190 MB trên màn hình gập).
• Xác minh tính năng dọn rác ART ở trạng thái nền: Trong cgroup v2, các trang hình ảnh khung và boot.art do Zygote chia sẻ vẫn được tính vào cgroup của Zygote và được coi là không gian miễn nhiễm trong quá trình dọn rác đồng thời (CMC) của ART. Thử nghiệm chịu tải xác nhận rằng khi một ứng dụng giao diện người dùng hệ thống chuyển sang background, việc thắt chặt memory.high (ví dụ: thành 30 MB trên Traceur) sẽ giới hạn rõ ràng vùng nhớ khối xếp riêng tư và bộ nhớ đệm trang mà không gây ra tình trạng dọn rác quá mức hoặc hoạt động hoán đổi.

Hình 6. Tìm điểm gãy không có lỗi trang lặp lại trong một hành trình quan trọng của người dùng (CUJ).

Tóm tắt ngân sách ứng dụng hệ thống tham chiếu AOSP

Bảng sau đây tóm tắt ngân sách tham chiếu đã hiệu chỉnh trong AOSP trên các cấp RAM và trạng thái quy trình:

Cách nhà sản xuất thiết bị gốc (OEM) có thể hiệu chỉnh lại ngân sách ứng dụng hệ thống cho thiết bị của họ

OEM tuỳ chỉnh ứng dụng hệ thống (ví dụ: thêm hồ sơ Bluetooth của nhà cung cấp, tiện ích điện thoại tuỳ chỉnh hoặc trình lập chỉ mục nội dung nghe nhìn của OEM) hoặc cung cấp thêm dịch vụ hệ thống được cài đặt sẵn có thể hiệu chỉnh lại ngân sách hiện có hoặc tạo tệp *-budget.xml mới cho danh mục phần cứng của họ.

Thu thập hồ sơ bộ nhớ cgroup v2 đang hoạt động

Đối với mỗi quy trình hệ thống mục tiêu, hãy đọc các nút bộ nhớ cgroup v2 trong /sys/fs/cgroup/uid_<uid>/pid_<pid>/ trên các khối lượng công việc và cấp RAM tiêu biểu:

• memory.current: Bộ nhớ thường trú hiện tại được tính cho cgroup (không bao gồm các trang được chia sẻ Zygote)
• memory.peak: Mức cao nhất memory.current trong suốt thời gian hoạt động kể từ khi bắt đầu quy trình
• memory.swap.current: Mức sử dụng bộ nhớ hoán đổi nén hiện tại trong ZRAM
• memory.stat: Thông tin chi tiết về anon, file, pgscan, pgsteal, workingset_refault_anon và workingset_refault_file
• memory.events: Số lượng tích luỹ các lỗi vi phạm high (memory.high sự kiện điều tiết và thu hồi)

Khi tổng hợp dữ liệu đo từ xa từ các thiết bị thử nghiệm nội bộ hoặc thiết bị thực tế, hãy tách riêng các trạng thái quy trình đang hoạt động (TOP, FOREGROUND_SERVICE, liên kết đang hoạt động và đồng bộ hoá đang hoạt động) khỏi trạng thái CACHED rảnh hoặc PERSISTENT rảnh để ảnh chụp nhanh trạng thái rảnh không làm sai lệch các phép tính tập hợp hoạt động P95 và P99 theo hướng giảm xuống.

Tách vùng nhớ khối xếp không thể nén khỏi bộ nhớ đệm tệp có thể thu hồi

So sánh phân vị thứ 99 của anon + swap với phân vị thứ 99 của memory.current:

• Dịch vụ do bộ nhớ đệm tệp chi phối (file ≫ anon, chẳng hạn như nhà cung cấp cơ sở dữ liệu, trình lập chỉ mục của Tìm kiếm và trình nền nhật ký): Đặt android:maxMb để cung cấp khoảng trống thoải mái (thường là 1, 5 lần đến 4 lần) so với P99 anon + swap cộng với cửa sổ làm việc cho các trang tệp nóng. Cấu hình này cho phép hạt nhân liên tục loại bỏ các trang tệp chưa được liên kết mà không cần chạm vào vùng nhớ khối xếp ẩn danh. Nếu unevictable hoặc file_mapped lớn (như với bộ nhớ bị khoá hoặc cơ sở dữ liệu được liên kết với bộ nhớ), hãy tính cả mức sử dụng đó vào tập hợp đang hoạt động.
• Dịch vụ có nhiều vùng nhớ khối xếp ẩn danh hoặc dịch vụ đột biến (anon chiếm phần lớn memory.current, chẳng hạn như ngăn xếp mạng hoặc ngăn xếp kết nối): Đặt kích thước android:maxMb để bao gồm P90 đến P95 của memory.peak để các mức tăng đột biến tạm thời không kích hoạt tính năng hoán đổi ZRAM đồng bộ trên các luồng nhạy cảm với độ trễ.
• Quy trình giao diện người dùng cần nhiều màn hình (chẳng hạn như bộ chọn, thư viện hoặc trình trợ giúp giao diện người dùng hệ thống): Đo lường mức sử dụng bộ nhớ cơ sở không phải giao diện người dùng và mức sử dụng bộ nhớ bitmap gia tăng trên mỗi megapixel trên màn hình có độ phân giải thấp nhất và cao nhất, đồng thời thể hiện ngân sách bằng android:maxMb cộng với android:additionalBytesPerDisplayPixel.

Xoá memory.high trên thiết bị thực

Trước khi cam kết ngân sách mới cho bản dựng, hãy sử dụng am memory-limiter manual (hoặc ghi trực tiếp vào nút cgroup memory.high của quy trình trên bản dựng userdebug) để kiểm thử các giới hạn đề xuất trong khi chạy kiểm thử CUJ tự động:

# Override memory.high for a specific PID to 60 MB during a CUJ test
adb shell am memory-limiter manual <PID> 60MB

Theo dõi memory.stat và memory.events trước và sau CUJ:

• Ngân sách quá thấp: workingset_refault_anon hoặc workingset_refault_file tăng đột biến trong CUJ, memory.swap.current tăng liên tục trong quá trình hoạt động ở nền trước, hoặc Độ trễ của khung hình CUJ hoặc Binder bị hồi quy. Tăng ngân sách vượt quá mức mặc định.
• Ngân sách quá cao: memory.events:high vẫn là 0 ngay cả sau khi thực hiện các khối lượng công việc lập chỉ mục hoặc truyền trực tuyến tệp nặng, và file trong memory.stat tăng lên không giới hạn với các trang nguội. Thắt chặt ngân sách cho tập hợp đang hoạt động.
• Ngân sách được điều chỉnh phù hợp: memory.current ở trạng thái ổn định luôn ở mức dưới memory.high trong quá trình hoạt động bình thường. Trong thời gian tệp hoặc bộ nhớ đệm tăng đột biến, pgsteal sẽ lấy lại các trang tệp ít dùng trong khi workingset_refault_anon vẫn gần bằng 0 và độ trễ CUJ không thay đổi.