Những lầm tưởng tối ưu hóa Android phổ biến nhất đã được trình làng

Có rất nhiều hướng dẫn hướng dẫn dành riêng để tăng hiệu suất Android và các mẹo tối ưu hóa tổng thể. Một số trong số chúng là hợp pháp và những cái khác chỉ dựa trên lý thuyết hoặc các phương thức hoạt động lỗi thời trong hệ thống Android hoặc chỉ là vô nghĩa. Điều này bao gồm các đề xuất để trao đổi, các giá trị được thêm vào build.prop và các thay đổi biến trong nhân Linux.

Thậm chí còn có rất nhiều tập lệnh tối ưu hóa trên mạng. Ngoài ra, các bộ flash có thể flash tất cả trong một hứa hẹn sẽ tăng đáng kể hiệu năng, thời lượng pin và những thứ khác. Một số điều chỉnh thực sự có thể hoạt động, nhưng phần lớn chỉ đơn giản là hiệu ứng giả dược, hoặc tệ hơn, thực sự có tác động tiêu cực đến thiết bị của bạn.

Điều đó không có nghĩa là mọi người cố tình phát hành các tập lệnh bất chính - chắc chắn có các ứng dụng trả phí không có thật trên Play Store, 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ủ ý tốt, điều đó xảy ra khiến nhà phát triển có thể bị thông tin sai, hoặc đơn giản là thử nghiệm với các tinh chỉnh 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 kịch bản tối ưu hóa tất cả trong một của YouTube. Một số ít các tinh chỉnh thực sự có thể làm một cái gì đó, trong khi một bộ chỉnh sửa khác trong một kịch bản hoàn toàn không thể làm gì cả - nhưng các kịch bản này được truyền lại dưới dạng đạn ma thuật, mà không có bất kỳ điều tra thực sự nào về những gì hoạt động, và những 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ùng một phương thức, một số trong đó hoàn toàn lỗi thời hoặc có hại trong thời gian 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 của Cameron không có gì khác ngoài các điều chỉnh được đề xuất cùng nhau, không có ý tưởng rõ ràng về cách thức hoặc lý do tại sao các tối ưu hóa này hoạt động - người dùng sau đó flash các tập lệnh và cho rằng hiệu suất của chúng đột nhiên nhanh hơn ( trong thực tế, rất có thể hành động rất đơn giản là khởi động lại thiết bị của họ đã làm tăng hiệu suất, vì mọi thứ trong RAM của thiết bị đều bị xóa 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 để tối ưu hóa hiệu suất của Android Android và cho dù chúng chỉ là một huyền thoại hay một chỉnh sửa hợp pháp cho hiệu suất thiết bị.

Trao đổi

Đứng đầu danh sách huyền thoại là hoán đổi Android - một điều khá vô lý về mặt được coi là tối ưu hóa Android. Hoán đổi mục đích chính là tạo và kết nối tệp hoán trang, 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ự có thể áp dụng cho một máy chủ, gần như không có tính tương tác.

Khi bạn sử dụng trao đổi điện thoại Android của mình thường xuyên, điều đó sẽ dẫn đến độ trễ nghiêm trọng xuất phát từ những thứ trượt qua bộ đệm. Ví dụ, hãy tưởng tượng, nếu một ứng dụng cố gắng hiển thị đồ họa, được lưu trữ trong trao đổi, giờ đây phải tải lại đĩa sau khi giải phóng không gian bằng cách đặt trao đổi dữ liệu với ứ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 trao đổi không có vấn đề gì, nhưng đó không phải là trao đổi làm tăng hiệu suất - đó là cơ chế Android lowmemorykiller tích hợp, sẽ thường xuyên giết chết các quy trình ưu tiên cao, 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ừ quy trình kswapd và thường giết chế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 hết bộ nhớ), nhưng đó là một chủ đề hoàn toàn khác.

Vấn đề là, một thiết bị có, 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 trao đổi, và vì vậy trao đổi là hoàn toàn không cần thiết trong Android. Việc thực hiện của nó chỉ đơn giản là có độ trễ và dẫn đến suy giảm 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ị, đối với các 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 khoảng 512 MB RAM. Thực tế là một số người vẫn bao gồm các chỉnh sửa zRAM trong các kịch bản tối ưu hóa hoặc đề xuất zRAM như một loại tinh chỉnh tối ưu hóa hiện đại, là một ví dụ về những người thường không tuân theo các giao thức hoạt động mới nhất.

zRAM được dành cho các SoC đa lõi cấp ngân sách cấp nhập cảnh, chẳng hạn như các thiết bị sử dụng chipset MTK và 512 MB RAM. Điện thoại Trung Quốc rất rẻ, về cơ bản. Những gì zRAM về cơ bản làm 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ũ có lõi đơn, ngay cả khi zRAM được khuyến nghị trên các thiết bị đó, 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 trang hạt nhân) kết hợp các trang bộ nhớ giống hệt nhau trong một giá thầu để có không gian trống. Điều này trên thực tế đượ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, bởi vì các lõi 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, cố gắng chạy các tinh chỉnh tối ưu hóa làm chậm thiết bị hơn nữa, trớ trêu thay.

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à seeder và chúng tôi chắc chắn 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.

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 các thiết bị Android cũ hơn nhiều . Tuy nhiên, mọi người vì bất kỳ lý do gì tin rằng điều này có nghĩa là nó cũng là một tối ưu hóa áp dụng cho các thiết bị Android hiện đại, điều này hoàn toàn vô lý. Việc Seeder vẫn được duy trì và cung cấp như một công cụ giảm độ trễ hiện đại 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 Play Store của họ cũng lưu ý rằng Seeder kém hiệu quả hơn sau Android 4.0+. Dù vì lý do gì, Seeder vẫn xuất hiện trong các cuộc thảo luận tối ưu hóa cho các hệ thống Android hiện đại.

Những gì Seeder về cơ bản làm 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 / để thu được entropy. / Dev / ngẫu nhiên / bộ đệm sẽ 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ư 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à biên dịch cho inastroil của Android để nó lấy dữ liệu ngẫu nhiên từ con đường / dev / urandom nhanh hơn và dễ đoán hơn, và hợp nhất chúng thành dev / ngẫu nhiên / mỗi giây, mà không cho phép / dev / ngẫu nhiên / trở nên kiệt sức. Điều này dẫn đến một hệ thống Android không bị thiếu entropy và hoạt động mượt mà hơn nhiều.

Google đã khắc phục lỗi này sau Android 3.0, tuy nhiên vì một số lý do, Seeder vẫn bật lên trên các danh sách cải tiến được đề xuất của Wikipedia để tối ưu hóa hiệu suất của Android. Hơn nữa, ứng dụng Seeder có một vài điểm 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 giải pháp thay thế, hoặc thậm chí chỉ là một liên kết tượng trưng giữa / dev / urandom và / dev / ngẫu nhiên. Điều này là hoàn toàn vô nghĩa đối với các hệ thống Android hiện đại.

Lý do là 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 ra các khóa WEP / WPA và cuối cùng là một số thư viện để tạo ID trong việc tạo hệ thống tệp EXT2 / EXT3 / EXT4.

Vì vậy, khi các cải tiến dựa trên Seeder hoặc Seeder được bao gồm trong các tập lệnh tối ưu hóa Android hiện đại, điều cuối cùng xảy ra là sự suy giảm 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, điều này ảnh hưởng tiêu cực đến mức tiêu thụ pin .

Odex

Phần mềm stock trên các thiết bị Android khá nhiều luôn là odex. Điều này có nghĩa là bên cạnh gói tiêu chuẩn cho các ứng dụng Android ở định dạng APK, được tìm thấy trong / system / app / và / system / private-app /, 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ã byte được tối ưu hóa đã được chuyển qua máy ảo trình xác thực và tối ưu hóa, sau đó được ghi lại trong một tệp riêng sử dụng một cái gì đó như công cụ dexopt .

Vì vậy, các tệp odex có nghĩa là giảm tải cho máy ảo và cung cấp khả năng khởi chạy ứng dụng odexed - mặt khác, các tệp ODEX ngăn sửa đổ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, nhiều ROM tùy chỉnh như LineageOS được phân phối mà không có ODEX .

Việc tạo các 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à hiệu ứng giả dược. Khi hệ thống Android hiện đại không tìm thấy các tệp odex trong thư mục / system, hệ thống sẽ thực sự tạo chúng và đặt chúng vào thư mục / system / dalvik-cache /. Đây chính xác là những gì đang xảy ra khi, ví dụ, bạn flash một phiên bản Android mới và nó đưa ra thông báo là Bus Busy, Tối ưu hóa các ứng dụng.

Điều chỉnh Lowmemorykiller

Đa nhiệm trong Android khác với các hệ điều hành di động khác theo nghĩa nó dựa trên mô hình cổ điển nơi các ứng dụng hoạt động lặng lẽ ở chế độ nền và không có giới hạn về số lượng ứng dụng nền ( trừ khi được đặt trong Tùy chọn nhà phát triển, nhưng đây là 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 giết các ứng dụng nền trong các tình huống bộ nhớ thấp ( xem chúng ta đã nói về lowmemorykiller và kẻ giết người hết bộ nhớ trước đó trong phần này hướng dẫn) .

Để quay trở lại cơ chế lowmemorykiller, Android có thể tiếp tục hoạt động với số lượng bộ nhớ hạn chế và thiếu phân vùng trao đổ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 và hệ thống sẽ âm thầm giết các ứng dụng nền không 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, mặc dù vì một số lý do, nó trở nên phổ biến dưới dạng các ứng dụng giết người, thường có hại hơn là có lợi. Các ứng dụng diệt nhiệm vụ sẽ thức dậy theo các khoảng thời gian đã đặt hoặc do người dùng chạy và dường như giải phóng một lượng lớn RAM, được coi là tích cực - RAM miễn phí nhiều hơn có nghĩa là một thiết bị nhanh hơn, phải không? Tuy nhiên, đây không phải là trường hợp chính xác với Android.

Trên thực tế, việc có một lượng lớn RAM miễn phí thực sự có thể gây hại cho hiệu suất và thời lượng 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 chúng sẽ dễ dàng hơn nhiều, 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ớ.

Bởi vì điều này, những kẻ giết người nhiệm vụ không thực sự phổ biến như trước đây, mặc dù 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 ( đáng buồn là thiếu thông tin) . Thật không may, một xu hướng mới đã thay thế những kẻ giết người nhiệm vụ, xu hướng điều chỉnh cơ chế lowmemorykiller. Ví dụ, đây sẽ là ứng dụng MinFreeManager và ý tưởng chính là tăng chi phí 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 ở các viền - 4, 8, 12, 24, 32 và 40 Mb và khi không gian lưu trữ miễn phí 40 MB được lấp đầy, một trong những ứng dụng được lưu trong bộ nhớ cache được tải vào bộ nhớ nhưng không chạy Sẽ bị chấm dứt.

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 khi lowmemorykiller bắt đầu quá trình dọn dẹp của mình - điều đó có nghĩa là Android sẽ luôn cố gắng hết sức để sử dụng lượng RAM tối đa có sẵn mà không can thiệp vào Kinh 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ị được nâng lên, ví dụ, 100 MB trước khi LMK khởi động. Bây giờ người dùng sẽ thực sự mất RAM (100 - 40 = 60), vì vậy thay vì sử dụng không gian này để lưu trữ lại- kết thúc các ứng dụng, hệ thống sẽ giữ cho bộ nhớ này miễn phí, hoàn toàn không có mục đích nào 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 512 RAM, nhưng ai sở hữu chúng nữa? 2GB là phạm vi ngân sách hiện đại, trực tiếp, thậm chí các thiết bị RAM 4GB đang được xem là tầm trung của trực tuyến, 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 sẽ thường tìm thấy các tinh chỉnh giải quyết hệ thống con I / O. Ví dụ: hãy xem ThunderBolt! Script chứa các dòng này:

 tiếng vang 0> $ i / hàng đợi / vòng quay; echo 1024> $ i / queue / nr numquests; 

Dòng đầu tiên sẽ đưa ra các hướng dẫn 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 hàng đợi I / O từ 128 lên 1024 - vì biến $ i chứa đường dẫn đến cây của các thiết bị khối trong / sys và tập lệnh chạy trong một vòng lặp.

Theo đó, 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 / lát_idle; 

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

Mộ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.

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 khuyến nghị trên các 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, do đó, trình lập kế hoạch tốt nhất là hàng đợi noop / FIFO, vì vậy loại trình lập lịch biểu này tinh chỉnh điều chỉnh không có gì đặc biệt hoặc có ý nghĩa đối với Hệ thống con I / O. Trong thực tế, tất cả các lệnh danh sách đa màn hình đó được thay thế tốt hơn bằng một chu trình đơn giản:

 cho i trong / sys / khối / mmc *; làm echo noop> $ i / queue / calendaruler echo 0> $ i / queue / iostats xong 

Điều này sẽ cho phép 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 ổ đĩa rất nhỏ và gần như không đáng kể.

Một tinh chỉnh I / O vô dụng khác thường được tìm thấy trong các tập lệnh hiệu suất là các giá trị đọc trước tăng lên cho thẻ SD lên đến 2MB. Cơ chế đọc trước là để đọc dữ liệu sớm từ phương tiện truyền thông, 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 trong tương lai và tải trước vào RAM, do đó sẽ giảm thời gian trả về. Điều này nghe có vẻ hay trên giấy, nhưng thuật toán đọc trước thường sai hơn, dẫn đến các hoạt động đầu vào-đầu ra hoàn toàn không cần thiết, chưa kể đến mức tiêu thụ RAM cao.

Các giá trị đọc trước cao trong khoảng 1 - 8 MB được khuyến nghị trong mảng RAID, nhưng đối với các thiết bị Android, tốt nhất 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 khác 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 nhân, vm.denty_background_ratio và vm.denty_ratio, để điều chỉnh kích thước của bộ đệm để lưu trữ dữ liệu của bẩn bẩn. Dữ liệu bẩn thường là dữ liệu đã được ghi vào đĩa, nhưng vẫn còn nhiều bộ nhớ và đang chờ ghi vào đĩa.

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

 vm.denty_background_ratio = 10 vm.denty_ratio = 20 

Vì vậy, điều này cố gắng làm là khi bộ đệm dữ liệu bẩn chiếm 10% tổng dung lượng RAM, nó sẽ đánh thức luồng pdflush 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á mãnh liệt, bộ đệm sẽ tiếp tục phát triển và khi đạt 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 'lag').

Điều 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 khởi động trong pdflush sau 30 giây. Một sự kết hợp của 10/20 là khá hợp lý, ví dụ trên một thiết bị có 1GB RAM, điều này sẽ tương đương với 100/200 MB RAM, quá đủ về các bản ghi nổ trong đó tốc độ thường thấp hơn tốc độ ghi trong NAND hệ thống -memory hoặc thẻ SD, 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 số lý do, các tác giả kịch bản cố gắng đẩy giá trị này cao hơn nữa, đến mức vô lý. Ví dụ: chúng ta có thể tìm thấy trong tập lệnh tối ưu hóa Xplix với tỷ lệ cao tới 50/90.

 sysctl -w vm.denty_background_ratio = 50 sysctl -w vm.denty_ratio = 90 

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

Sấm sét! 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]; thì sysctl -w vm.denty_background_ratio = 15; sysctl -w vm.denty_ratio = 30; elif ["$ mem" -lt 1049776]; sau đó sysctl -w vm.denty_background_ratio = 10; sysctl -w vm.denty_ratio = 20; other sysctl -w vm.denty_background_ratio = 5; sysctl -w vm.denty_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 để thay đổi cài đặt mặc định - một thiết bị có bộ nhớ trong hoặc thẻ nhớ rất chậm. Trong trường hợp này, việc phân tán các giá trị của các biến là hợp lý, nghĩa là tạo ra một cái gì đó như thế này:

 sysctl -w vm.denty_background_ratio = 10 sysctl -w vm.denty_ratio = 60 

Sau đó, khi một hệ thống đột biến ghi các hoạt động, mà không phải ghi dữ liệu trên đĩa, cho đến lầ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.

Tinh chỉnh bổ sung vô dụng và điều chỉnh hiệu suất

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

Dưới đây là một số tối ưu hóa phổ biến bổ sung có thể có hoặc không hữu ích, 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 tốc - tiết kiệm một ít pin.
• Tối ưu hóa cơ sở dữ liệu - Về lý thuyết, điều này sẽ giúp cải thiện hiệu suất thiết bị, nhưng nó đáng nghi ngờ.
• Zipalign - Trớ trêu thay, mặc dù tính năng căn chỉnh tính năng SDK Android tích hợp trong tệp APK trong cửa hàng, bạn có thể tìm thấy rất nhiều phần mềm không được truyền qua zipalign.
• Vô hiệu hóa các dịch vụ hệ thống không cần thiết, loại bỏ hệ thống không sử dụng và các ứng dụng bên thứ ba ít sử dụng. Về cơ bản, gỡ cài đặt bloatware.
• Hạt nhân tùy chỉnh với 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ả lịch trình I / O noop.
• 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 các mạng không dây, có sẵn trong các hạt nhân tùy chỉnh.

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

LaraCraft304 từ diễn đàn XDA Developers đã 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ủa cài đặt /system/build.prop được khuyến nghị sử dụng cho các chuyên gia, Đâ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 contin.cust.tel.eons ro.max.fling_vel kernel.checkjni dalvik.vm.verify-bytecode debug.performance.tuning video.accelellow.hw ro.media.dec.jpeg.memcap ro.config.nocheckin profiler.force_disable_ulog profiler.force_disable_