Những lầm tưởng phổ biến nhất về tối ưu hóa Android được gỡ bỏ

ứng dụng trên Cửa hàng Play, nhưng các tập lệnh tối ưu hóa được phát hành trên các diễn đàn Android thường có chủ đích tốt, điều đó xảy ra là nhà phát triển có thể bị thông báo sai hoặc chỉ đơn giản là thử nghiệm với các chỉnh sửa tối ưu hóa khác nhau. Thật không may, một loại hiệu ứng quả cầu tuyết có xu hướng xảy ra, đặc biệt là trong các tập lệnh tối ưu hóa 'tất cả trong một'. Một số ít các chỉnh sửa có thể thực sự làm được cái gì đó , trong khi một loạt các chỉnh sửa khác trong một tập lệnh có thể hoàn toàn không làm gì cả - nhưng những tập lệnh này được truyền tụng như là những viên đạn ma thuật, mà không có bất kỳ cuộc điều tra thực tế nào về cái gì hoạt động và cái gì không.



Do đó, rất nhiều tập lệnh tối ưu hóa tất cả trong một đang sử dụng các phương pháp giống nhau, một số trong số đó đã hoàn toàn lỗi thời hoặc có hại về lâu dài. Tóm lại, phần lớn các tập lệnh tối ưu hóa “tất cả trong một” không là gì ngoài các điều chỉnh được đề xuất kết hợp với nhau, không có ý tưởng rõ ràng về cách thức hoặc lý do tại sao những tối ưu hóa này “hoạt động - người dùng sau đó flash các tập lệnh và tuyên bố hiệu suất của họ đột nhiên nhanh hơn ( trong khi trên thực tế, rất có thể hành động khởi động lại thiết bị của họ rất đơn giản đã làm tăng hiệu suất , vì mọi thứ trong RAM của thiết bị được dọn sạch) .

Trong bài viết dành riêng cho Ứng dụng này, chúng tôi sẽ nêu bật một số đề xuất phổ biến nhất cho “ tối ưu hóa ” Hiệu suất của Android và liệu chúng chỉ là một huyền thoại hay một tinh chỉnh hợp pháp cho hiệu suất thiết bị.



Hoán đổi

Đứng đầu danh sách hoang đường là hoán đổi Android - điều này khá vô lý khi được coi là một sự tối ưu hóa Android. Mục đích chính của Swaps là tạo và kết nối tệp hoán trang, điều này sẽ giải phóng không gian lưu trữ trong bộ nhớ. Điều này nghe có vẻ hợp lý trên giấy , nhưng nó thực sự áp dụng cho một người phục vụ , hầu như không có tương tác.



Khi bạn sử dụng tính năng hoán đổi của điện thoại Android thường xuyên, điều này sẽ dẫn đến độ trễ nghiêm trọng do mọi thứ trượt qua bộ nhớ cache. Hãy tưởng tượng, chẳng hạn, nếu một ứng dụng cố gắng hiển thị một đồ họa, được lưu trữ trong bộ trao đổi, bây giờ phải tải lại đĩa sau khi giải phóng dung lượng bằng cách đặt hoán đổi dữ liệu với một ứng dụng khác. Nó thực sự lộn xộn.



Một số người đam mê tối ưu hóa có thể nói rằng hoán đổi không mang lại vấn đề gì, nhưng hoán đổi không làm tăng hiệu suất - đó là cơ chế Android được tích hợp sẵn lowmemorykiller , điều này sẽ thường xuyên tiêu diệt các quy trình có mức độ ưu tiên cao, cồng kềnh không được sử dụng. LMK được thiết kế đặc biệt để xử lý các điều kiện bộ nhớ thấp, được gọi từ kswapd xử lý và thường giết các quy trình không gian của người dùng. Điều này khác với OOMkiller (kẻ giết người mất trí nhớ), nhưng đó hoàn toàn là một chủ đề khác.

Vấn đề là, một thiết bị, ví dụ, 1GB RAM không bao giờ có thể đạt được dữ liệu hiệu suất cần thiết trong một cuộc hoán đổi và do đó, hoán đổi là hoàn toàn không cần thiết trong Android. Việc triển khai nó chỉ đơn giản là đầy độ trễ và dẫn đến suy thoái về hiệu suất, thay vì tối ưu hóa nó.

zRAM - Đã lỗi thời và không còn hiệu quả

zRAM là một phương pháp đã được chứng minh và hiệu quả để tối ưu hóa thiết bị, thiết bị cũ hơn - hãy nghĩ rằng các thiết bị dựa trên KitKat chỉ hoạt động trên RAM 512 MB. Thực tế là một số người vẫn bao gồm các chỉnh sửa zRAM trong các tập lệnh tối ưu hóa hoặc đề xuất zRAM như một số loại tinh chỉnh tối ưu hóa hiện đại, là một ví dụ về việc mọi người thường không tuân theo các giao thức hoạt động mới nhất.



zRAM được thiết kế cho các SoC đa lõi tầm ngân sách cấp thấp, chẳng hạn như thiết bị sử dụng chipset MTK và 512 MB RAM. Về cơ bản, điện thoại Trung Quốc rất rẻ. Những gì zRAM về cơ bản là tách hạt nhân thông qua luồng mã hóa.

Khi zRAM được sử dụng trên các thiết bị cũ hơn với lõi đơn , ngay cả khi zRAM được khuyến nghị trên các thiết bị như vậy, số lượng lớn độ trễ có xu hướng tăng lên. Điều này cũng xảy ra với công nghệ KSM ( Hợp nhất nhân cùng trang) kết hợp các trang bộ nhớ giống hệt nhau để giải phóng dung lượng. Trên thực tế, điều này được Google khuyến nghị, nhưng dẫn đến độ trễ lớn hơn trên các thiết bị cũ hơn, vì các bộ đệm lõi hoạt động liên tục đang chạy liên tục từ bộ nhớ để tìm kiếm các trang trùng lặp. Về cơ bản, việc cố gắng chạy tinh chỉnh tối ưu hóa còn làm chậm thiết bị hơn nữa, thật trớ trêu.

Seeder - Đã lỗi thời kể từ Android 3.0

Một trong những mẹo tối ưu hóa được tranh luận nhiều nhất giữa các nhà phát triển Android là tuyết tùng và chúng tôi chắc chắn rằng ai đó có thể cố gắng chứng minh chúng tôi sai về chủ đề này - nhưng trước tiên chúng tôi cần kiểm tra lịch sử của seeder.

Ứng dụng Seeder dành cho Android

Có, có một số lượng lớn các báo cáo tuyên bố hiệu suất Android tốt hơn sau khi cài đặt trên thiết bị Android cũ hơn nhiều . Tuy nhiên, mọi người vì bất cứ lý do gì tin rằng điều này có nghĩa là nó cũng là một cách tối ưu thiết bị Android hiện đại , điều này hoàn toàn vô lý. Thực tế là Seeder vẫn được duy trì và cung cấp như một “ hiện đại ” công cụ giảm độ trễ là một ví dụ về thông tin sai lệch - mặc dù đây không phải là lỗi của nhà phát triển Seeder, vì ngay cả trang Cửa hàng Play của họ cũng lưu ý rằng Seeder kém hiệu quả hơn sau Android 4.0+. Tuy nhiên, vì bất cứ lý do gì, Seeder vẫn xuất hiện trong các cuộc thảo luận về tối ưu hóa cho các hệ thống Android hiện đại.

Những gì Seeder làm về cơ bản cho Android 3.0 là giải quyết một lỗi trong đó thời gian chạy Android sẽ chủ động sử dụng tệp / dev / random / để lấy entropy. / Dev / random / buffer sẽ trở nên không ổn định và hệ thống sẽ bị chặn cho đến khi nó lấp đầy lượng dữ liệu cần thiết - hãy nghĩ những điều nhỏ nhặt như các cảm biến và nút khác nhau trên thiết bị Android.

Tác giả của Seeder lấy Linux-quỷ rngd và được biên dịch cho inastroil của Android để nó lấy dữ liệu ngẫu nhiên từ một con đường nhanh hơn và dễ dự đoán hơn / dev / urandom và hợp nhất chúng thành dev / random / mỗi giây mà không cho phép / dev / random / cạn kiệt. Điều này dẫn đến hệ thống Android không bị thiếu entropy và hoạt động mượt mà hơn nhiều.

Google đã sửa lỗi này sau Android 3.0, nhưng vì một số lý do, Seeder vẫn bật lên 'Các chỉnh sửa được đề xuất' danh sách để tối ưu hóa hiệu suất Android. Hơn nữa, ứng dụng Seeder có một số tương tự như sEFix bao gồm chức năng của Seeder, cho dù sử dụng cùng một rngd hoặc thay thế rèn giũa , hoặc thậm chí chỉ là một liên kết tượng trưng giữa / dev / urandom và / dev / random. Điều này hoàn toàn vô nghĩa đối với các hệ thống Android hiện đại.

Lý do nó vô nghĩa là vì các phiên bản Android mới hơn sử dụng / dev / random / trong ba thành phần chính: libcrypto , để mã hóa các kết nối SSL, tạo khóa SSH, v.v. WPA_supplication / hostapd tạo khóa WEP / WPA và cuối cùng, một số ít thư viện để tạo ID trong việc tạo hệ thống tệp EXT2 / EXT3 / EXT4.

Vì vậy, khi Máy gieo hạt hoặc các cải tiến dựa trên Seeder được bao gồm trong các tập lệnh tối ưu hóa Android hiện đại, những gì cuối cùng xảy ra là suy thoái về hiệu suất thiết bị, bởi vì rngd sẽ liên tục đánh thức thiết bị và gây ra sự gia tăng tần số CPU, tất nhiên, điều này sẽ ảnh hưởng tiêu cực đến việc tiêu thụ pin.

Odex

Phần mềm có sẵn trên các thiết bị Android luôn luôn odex. Điều này có nghĩa là cùng với gói tiêu chuẩn cho ứng dụng Android ở định dạng APK, được tìm thấy trong / system / app / và / system / priv-app /, đều có cùng tên tệp với phần mở rộng .odex. Các tệp odex chứa các ứng dụng mã bytecode được tối ưu hóa đã chuyển qua máy ảo trình xác thực và trình tối ưu hóa, sau đó được ghi lại trong một tệp riêng biệt bằng cách sử dụng một cái gì đó như dexopt dụng cụ.

Vì vậy, các tệp odex có nghĩa là để giảm tải máy ảo và cung cấp tốc độ khởi chạy ứng dụng odex - mặt trái, các tệp ODEX ngăn các sửa đổi đối với phần sụn và tạo ra các vấn đề với các bản cập nhật, vì vậy, vì lý do này mà nhiều ROM tùy chỉnh như LineageOS được phân phối không có ODEX .

Việc tạo tệp ODEX được thực hiện theo một số cách, như sử dụng Công cụ Odexer - vấn đề là nó hoàn toàn là một hiệu ứng giả dược. Khi hệ thống Android hiện đại không tìm thấy tệp odex trong thư mục / system, hệ thống sẽ thực sự tạo chúng và đặt chúng trong thư mục / system / dalvik-cache /. Đây chính xác là những gì đang xảy ra khi bạn cài đặt phiên bản Android mới và nó đưa ra thông báo “Bận, đang tối ưu hóa ứng dụng” một lúc.

Chỉnh sửa Lowmemorykiller

Đa nhiệm trong Android khác với các hệ điều hành di động khác ở chỗ dựa trên mô hình cổ điển, nơi các ứng dụng hoạt động nhẹ nhàng trong nền và không có giới hạn về số lượng ứng dụng nền ( trừ khi một cái được đặt trong Tùy chọn nhà phát triển, nhưng điều này thường được khuyến nghị chống lại) - hơn nữa, chức năng chuyển đổi sang thực thi nền không bị dừng, mặc dù hệ thống có quyền loại bỏ các ứng dụng nền trong tình huống bộ nhớ thấp ( xem nơi chúng ta đã nói về lowmemorykiller và kẻ giết người mất trí nhớ trước đó trong hướng dẫn này) .

Để quay lại lowmemorykiller Android có thể tiếp tục hoạt động với một lượng bộ nhớ hạn chế và thiếu phân vùng hoán đổi. Người dùng có thể tiếp tục khởi chạy các ứng dụng và chuyển đổi giữa chúng, đồng thời hệ thống sẽ âm thầm loại bỏ các ứng dụng nền không được sử dụng để thử và giải phóng bộ nhớ cho các tác vụ đang hoạt động.

Điều này rất hữu ích cho Android trong những ngày đầu tiên, mặc dù vì một số lý do mà nó trở nên phổ biến dưới dạng các ứng dụng sát thủ tác vụ, thường có hại nhiều hơn có lợi. Các ứng dụng sát thủ công việc hoặc khởi động theo khoảng thời gian đã định hoặc do người dùng chạy và dường như giải phóng một lượng lớn RAM, điều này được coi là tích cực - RAM trống nhiều hơn có nghĩa là thiết bị nhanh hơn, phải không? Tuy nhiên, điều này không hoàn toàn đúng với Android.

Trên thực tế, việc có một lượng lớn RAM trống thực sự có thể gây hại cho hiệu suất và tuổi thọ pin của thiết bị. Khi các ứng dụng được lưu trữ trong RAM của Android, việc gọi chúng lên, khởi chạy, v.v. Hệ thống Android không cần phải dành nhiều tài nguyên để chuyển sang ứng dụng, vì nó đã có sẵn trong bộ nhớ.

Do đó, các trình diệt tác vụ không thực sự phổ biến như trước đây, mặc dù những người mới sử dụng Android vẫn có xu hướng dựa vào chúng vì một số lý do ( thiếu thông tin, thật đáng buồn) . Thật không may, một xu hướng mới đã thay thế những kẻ giết nhiệm vụ, xu hướng lowmemorykiller điều chỉnh cơ chế. Đây sẽ là ví dụ MinFreeManager và ý tưởng chính là tăng dung lượng RAM trước khi hệ thống bắt đầu giết các ứng dụng nền.

Vì vậy, ví dụ: RAM tiêu chuẩn hoạt động ở biên giới - 4, 8, 12, 24, 32 và 40 Mb và khi không gian lưu trữ còn trống 40 MB được lấp đầy, một trong những ứng dụng đã lưu trong bộ nhớ cache sẽ được tải vào bộ nhớ nhưng không chạy Sẽ bị chấm dứt.

Vì vậy, về cơ bản, Android sẽ luôn có ít nhất 40 MB bộ nhớ khả dụng, đủ để chứa thêm một ứng dụng trước đó lowmemorykiller bắt đầu quá trình dọn dẹp - có nghĩa là Android sẽ luôn cố gắng hết sức để sử dụng tối đa dung lượng RAM khả dụng mà không ảnh hưởng đến trải nghiệm người dùng.

Đáng buồn thay, điều mà một số người đam mê homebrew bắt đầu khuyến nghị là giá trị phải được nâng lên, chẳng hạn như 100 MB trước khi LMK bắt đầu hoạt động. Bây giờ người dùng sẽ thực sự thua RAM (100 - 40 = 60), vì vậy thay vì sử dụng không gian này để lưu trữ các ứng dụng back-end, hệ thống sẽ giữ lại lượng bộ nhớ này miễn phí , hoàn toàn không có mục đích cho nó.

Điều chỉnh LKM có thể hữu ích cho các thiết bị cũ hơn nhiều với RAM 512, nhưng ai sở hữu chúng nữa? 2GB là 'phạm vi ngân sách' hiện đại, thậm chí các thiết bị RAM 4GB ngày nay được coi là 'tầm trung', vì vậy các tinh chỉnh LMK thực sự lỗi thời và vô dụng.

Điều chỉnh I / O

Trong rất nhiều tập lệnh tối ưu hóa cho Android, bạn thường sẽ tìm thấy các chỉnh sửa giải quyết hệ thống con I / O. Ví dụ: chúng ta hãy xem ThunderBolt! Tập lệnh, chứa những dòng sau:

echo 0> $ i / queue / quay; echo 1024> $ i / queue / nr_requests;

Dòng đầu tiên sẽ cung cấp hướng dẫn của bộ lập lịch I / O trong việc xử lý ổ SSD và dòng thứ hai tăng kích thước tối đa của I / O hàng đợi từ 128 lên 1024 - vì biến $ i chứa một đường dẫn đến cây khối thiết bị trong / sys và tập lệnh chạy trong một vòng lặp.

Sau đó, bạn tìm thấy một dòng liên quan đến bộ lập lịch CFQ:

echo 1> $ i / queue / iosched / back_seek_penalty; echo 1> $ i / queue / iosched / low_latency; echo 1> $ i / queue / iosched / slice_idle;

Tiếp theo là nhiều dòng hơn thuộc về các nhà lập kế hoạch khác, nhưng cuối cùng, hai lệnh đầu tiên là vô nghĩa vì:

Hạt nhân Linux hiện đại có thể hiểu loại phương tiện lưu trữ mà nó đang làm việc theo mặc định.

Một hàng đợi đầu vào đầu ra dài ( chẳng hạn như 1024) là vô dụng trên thiết bị Android hiện đại, trên thực tế, nó vô nghĩa ngay cả trên máy tính để bàn - nó thực sự chỉ được đề xuất trên máy chủ hạng nặng . Điện thoại của bạn không phải là một máy chủ Linux nặng.

Đối với thiết bị Android, hầu như không có ứng dụng nào được ưu tiên trong đầu vào-đầu ra và không có trình điều khiển cơ học, vì vậy công cụ lập kế hoạch tốt nhất là hàng đợi noop / FIFO, vì vậy loại lập lịch này ' tinh chỉnh ” không làm bất cứ điều gì đặc biệt hoặc có ý nghĩa đối với hệ thống con I / O. Trên thực tế, tất cả các lệnh trong danh sách nhiều màn hình đó tốt hơn nên được thay thế bằng một chu trình đơn giản:

cho tôi trong / sys / block / mmc *; làm echo noop> $ i / queue / Scheduler echo 0> $ i / queue / iostats done

Điều này sẽ kích hoạt bộ lập lịch noop cho tất cả các ổ đĩa từ việc tích lũy số liệu thống kê I / O, điều này sẽ có tác động tích cực đến hiệu suất, mặc dù một số rất nhỏ và gần như hoàn toàn không đáng kể.

Một tinh chỉnh I / O vô dụng khác thường thấy trong các tập lệnh hiệu suất là tăng giá trị đọc trước cho thẻ SD lên đến 2MB. Cơ chế đọc trước dành cho các lần đọc dữ liệu sớm từ phương tiện, trước khi ứng dụng yêu cầu quyền truy cập vào dữ liệu đó. Vì vậy, về cơ bản, hạt nhân sẽ cố gắng tìm ra dữ liệu nào sẽ cần thiết trong tương lai và tải trước nó vào RAM, do đó sẽ giảm thời gian trả về. Điều này nghe có vẻ tuyệt vời trên giấy, nhưng thuật toán đọc trước thường xuyên hơn Sai lầm , dẫn đến các hoạt động hoàn toàn không cần thiết của đầu vào-đầu ra, chưa kể đến việc tiêu thụ RAM cao.

Các giá trị đọc trước cao từ 1 - 8 MB được khuyến nghị trong mảng RAID, nhưng đối với thiết bị Android, tốt nhất bạn chỉ nên để giá trị mặc định là 128 KB.

Tinh chỉnh hệ thống quản lý bộ nhớ ảo

Một kỹ thuật “tối ưu hóa” phổ biến khác là điều chỉnh hệ thống con quản lý bộ nhớ ảo. Điều này thường chỉ nhắm mục tiêu hai biến hạt nhân, vm.dirty_background_ratio và vm.dirty_ratio, để điều chỉnh kích thước của bộ đệm để lưu trữ dữ liệu 'bẩn'. Dơ bẩn dữ liệu thường là dữ liệu đã được ghi vào đĩa, nhưng vẫn còn nhiều dữ liệu trong bộ nhớ và đang chờ được ghi vào đĩa.

Các giá trị tinh chỉnh điển hình trong cả hai bản phân phối Linux và Androis cho hệ thống con quản lý máy ảo sẽ như sau:

vm.dirty_background_ratio = 10 vm.dirty_ratio = 20

Vì vậy, điều này cố gắng làm là khi bộ đệm dữ liệu bẩn là 10% tổng dung lượng RAM, nó sẽ đánh thức pdflush luồng và bắt đầu ghi dữ liệu vào đĩa - nếu hoạt động ghi dữ liệu trên đĩa sẽ quá dữ dội , bộ đệm sẽ tiếp tục phát triển và khi đạt đến 20% RAM khả dụng, hệ thống sẽ chuyển sang hoạt động ghi tiếp theo ở chế độ đồng bộ - không có bộ đệm trước. Điều này có nghĩa là công việc ghi vào ứng dụng đĩa sẽ bị chặn, cho đến khi dữ liệu được ghi vào đĩa (AKA ‘tụt hậu’).

Những gì bạn nên hiểu là ngay cả khi kích thước bộ đệm không đạt 10% , hệ thống sẽ tự động chuyển sang dạng pdflush sau 30 giây. Kết hợp 10/20 là khá hợp lý, ví dụ trên một thiết bị có RAM 1GB, con số này sẽ tương đương với 100 / 200MB RAM, quá đủ nếu xét về các bản ghi liên tục trong đó tốc độ thường thấp hơn kỷ lục tốc độ trong hệ thống NAND -memory hoặc SD-card, chẳng hạn như khi cài đặt ứng dụng hoặc sao chép tệp từ máy tính.

Vì một lý do nào đó, các nhà biên kịch cố gắng đẩy giá trị này lên cao hơn nữa, đến mức phi lý. Ví dụ, chúng ta có thể tìm thấy trong Xplix tập lệnh tối ưu hóa tỷ lệ cao tới 50/90.

sysctl -w vm.dirty_background_ratio = 50 sysctl -w vm.dirty_ratio = 90

Trên thiết bị có bộ nhớ 1 GB, điều này đặt giới hạn bộ đệm bẩn là 500/900 MB, điều này hoàn toàn vô dụng đối với thiết bị Android, vì nó sẽ chỉ hoạt động dưới ghi liên tục trên đĩa - điều chỉ xảy ra trên một máy chủ Linux nặng.

ThunderBolt! Script sử dụng một giá trị hợp lý hơn, nhưng nhìn chung, nó vẫn khá vô nghĩa:

if ['$ mem' -lt 524288]; then sysctl -w vm.dirty_background_ratio = 15; sysctl -w vm.dirty_ratio = 30; elif ['$ mem' -lt 1049776]; then sysctl -w vm.dirty_background_ratio = 10; sysctl -w vm.dirty_ratio = 20; else sysctl -w vm.dirty_background_ratio = 5; sysctl -w vm.dirty_ratio = 10; fi;

Hai lệnh đầu tiên được chạy trên điện thoại thông minh có RAM 512 MB, lệnh thứ hai - với 1 GB và các lệnh khác - với hơn 1 GB. Nhưng trên thực tế chỉ có một lý do duy nhất để thay đổi cài đặt mặc định - thiết bị có bộ nhớ trong hoặc thẻ nhớ rất chậm. Trong trường hợp này, điều hợp lý là rải các giá trị của các biến, nghĩa là tạo ra một cái gì đó như sau:

sysctl -w vm.dirty_background_ratio = 10 sysctl -w vm.dirty_ratio = 60

Sau đó, khi một hệ thống tăng cường ghi các hoạt động, mà không cần phải ghi dữ liệu trên đĩa, đến cuối cùng sẽ không chuyển sang chế độ đồng bộ, điều này sẽ cho phép các ứng dụng giảm độ trễ khi ghi.

Các tinh chỉnh bổ sung vô ích và điều chỉnh hiệu suất

Có rất nhiều 'tối ưu hóa' khác thực sự không làm được gì cả. Hầu hết chúng chỉ đơn giản là không có tác dụng gì, trong khi những người khác có thể cải thiện một số khía cạnh hiệu suất, trong khi làm suy giảm thiết bị theo những cách khác ( thường nó sẽ giảm hiệu suất so với tiêu hao pin) .

Dưới đây là một số tối ưu hóa phổ biến bổ sung có thể hữu ích hoặc không, tùy thuộc vào hệ thống và thiết bị Android.

  • Tăng tốc - Gia tốc nhỏ để cải thiện hiệu suất và giảm hiệu suất - tiết kiệm một ít pin.
  • Tối ưu hóa cơ sở dữ liệu - Về lý thuyết thì điều này Nên cải thiện hiệu suất của thiết bị, nhưng nó có thể nghi ngờ.
  • Zipalign - Trớ trêu thay, mặc dù Android SDK được tích hợp sẵn tính năng căn chỉnh nội dung trong tệp APK trong cửa hàng, bạn có thể tìm thấy nhiều phần mềm không được truyền qua zipalign.
  • Tắt các dịch vụ hệ thống không cần thiết, gỡ bỏ hệ thống không sử dụng và các ứng dụng bên thứ ba hiếm khi được sử dụng. Về cơ bản, gỡ cài đặt bloatware.
  • Nhân tùy chỉnh với các tối ưu hóa cho một thiết bị cụ thể (một lần nữa, không phải tất cả các hạt nhân đều tốt như nhau).
  • Đã mô tả noop bộ lập lịch I / O.
  • Thuật toán bão hòa TCP Westwood - Được sử dụng hiệu quả hơn trong Android Cubic mặc định cho mạng không dây, có sẵn trong nhân tùy chỉnh.

Cài đặt vô dụng build.prop

LaraCraft304 từ diễn đàn Nhà phát triển XDA đã tiến hành một nghiên cứu và phát hiện ra rằng một số lượng ấn tượng các cài đặt /system/build.prop được khuyến nghị sử dụng cho các “chuyên gia” không tồn tại trong nguồn AOSP và CyanogenMod. Đây là danh sách:

ro.ril.disable.power.collapse ro.mot.eri.losalert.delay ro.config.hw_fast_dormancy ro.config.hw_power_saving windowsmgr.max_events_per_sec Kiên trì.cust.tel.eons ro.max.fling_velocity ro.min.fling_velocity ro. kernel.checkjni dalvik.vm.verify-bytecode debug.performance.tuning video.accelerate.hw ro.media.dec.jpeg.memcap ro.config.nocheckin profiler.force_disable_ulog profiler.force_disable_err_rpt ersist.sys.shutdown.APP_APP_ADJ.HOME
Thẻ android Phát triển 12 phút đọc