Có rất nhiều hướng dẫn chỉ dẫn dành riêng cho việc 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ố đó là hợp pháp, và một số khác chỉ dựa trên lý thuyết hoặc các phương pháp hoạt động lỗi thời trong hệ thống Android, hoặc chỉ là những điều vô nghĩa. Điều này bao gồm các đề xuất để hoán đổi, các giá trị được thêm vào build.prop và các thay đổi có thể thay đổi trong nhân Linux.
Thậm chí còn có rất nhiều “tập lệnh tối ưu hóa”, các tệp .zips có thể nhấp nháy tất cả trong một hứa hẹn sẽ tăng đáng kể hiệu suất, tuổi thọ pin và những thứ khác. Một số trong số các chỉnh sửa 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ó những điều không có thật được trả tiền ứ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 điều 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 lại 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ì khác 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 - sau đó người dùng flash các tập lệnh và tuyên bố rằng hiệu suất của họ đột nhiên nhanh hơn ( trong khi 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 , khi 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 để “ 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 sự tinh chỉnh hợp pháp cho hiệu suất của 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 phương pháp 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ự có thể áp dụng cho một máy chủ , 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, nó sẽ dẫn đến độ trễ nghiêm trọng xuất phát từ việc 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ình ảnh được lưu trữ trong 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 cung cấp vấn đề gì, nhưng hoán đổi không làm tăng hiệu suất - đó là cơ chế Android lowmemorykiller được tích hợp sẵn , điều này sẽ thường xuyên giết chết các quy trình ư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ị có RAM 1GB chẳng hạn không bao giờ có thể đạt được dữ liệu hiệu suất cần thiết trong một lần hoán đổi, và do đó, việc 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ị, cho 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 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ế dành cho các SoC đa lõi tầm ngân sách cấp thấp, chẳng hạn như các 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 làm 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 có 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 ( Kernel Same Page Merging) kết hợp các trang bộ nhớ giống hệt nhau để cố gắng 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à seeder 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.
Có, có một số lượng lớn báo cáo cho biết 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 kỳ 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 hóa có thể áp dụng cho thiết bị Android hiện đại , đó là điều 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.
Về cơ bản những gì Seeder 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 / để 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 trê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 giải pháp thay thế hasged , 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à sự xuống cấp về hiệu suất của thiết bị, 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 bytecode được tối ưu hóa đã được 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 cô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à 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 vào thư mục / system / dalvik-cache /. Đây chính xác là những gì đang xảy ra, chẳng hạn như 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” trong 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 trong đó 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 ứng dụng được đặt trong Tùy chọn nhà phát triển, nhưng điều này thường được khuyến khích 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 lại, mặc dù hệ thống có quyền loại bỏ 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à sát thủ hết bộ nhớ ở phần trước trong hướng dẫn này ở đâu) ) .
Để quay lại lowmemorykiller cơ chế, 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 và hệ thống sẽ tự động tắt 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ủ tác vụ 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 chúng, v.v ... dễ dàng hơn nhiều. 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ó đã ở đó 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 làm quen với Android vẫn có xu hướng dựa vào chúng vì một số lý do ( thật đáng tiếc là thiếu thông tin) . Thật không may, một xu hướng mới đã thay thế các trình diệt tác vụ, xu hướng lowmemorykiller điều chỉnh cơ chế. Đây sẽ là ví dụ MinFreeManager ứng dụng và ý tưởng chính là tăng dung lượng RAM trước khi hệ thống bắt đầu hủy các ứng dụng nền.
Vì vậy, ví dụ:RAM tiêu chuẩn hoạt động ở các đường viền - 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 thực sự sẽ mất 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ữ cho lượng bộ nhớ này trống , hoàn toàn không có mục đích gì.
Đ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 chỉnh sửa của 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 dành 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 xét ThunderBolt! Tập lệnh, chứa những dòng sau:
echo 0> $ i / queue / rotational; echo 1024> $ i / queue / nr_requests;
Dòng đầu tiên sẽ cung cấp các 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ì:
Theo mặc định, 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.
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ó chỉ thực sự được khuyến nghị 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 trình lập kế hoạch tốt nhất là noop / FIFO-queue, 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 *; doecho noop> $ i / queue / Schedrecho 0> $ i / queue / iostatsdone
Đ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 bị 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 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 chỉ nên để giá trị mặc định là 128 KB.
Điều 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". Bẩn thỉu 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 =10vm.dirty_ratio =20
Vì vậy, những gì đ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 dòng chảy 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á cường độ cao , 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’).
Đ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 chuyển sang dạng pdflush sau 30 giây. Sự kết hợp của 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, là quá đủ 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 -bộ nhớ 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 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 có tỷ lệ cao tới 50/90.
sysctl -w vm.dirty_background_ratio =50sysctl -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 trong điều kiện ghi liên tục trên đĩa - điều gì đó chỉ xảy ra trên một máy chủ Linux nặng.
ThunderBolt! Tập lệnh 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]; thensysctl -w vm.dirty_background_ratio =15; sysctl -w vm.dirty_ratio =30; elif ["$ mem" -lt 1049776]; thensysctl -w vm.dirty_background_ratio =10; sysctl -w vm.dirty_ratio =20; elsesysctl -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, việc dàn trải 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.dirty_background_ratio =10sysctl -w vm.dirty_ratio =60
Sau đó, khi 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, cho đế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 và hiệu suất vô ích bổ sung
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 một số khác có thể cải thiện một số khía cạnh hiệu suất, đồng thời làm suy giảm thiết bị theo những cách khác ( thường thì thiết bị giảm hiệu suất so với mức 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 - Tăng 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 hoá Cơ sở dữ liệu - Về lý thuyết, điều này nên cải thiện hiệu suất của thiết bị nhưng điều đó là đáng ngờ.
- Zipalign - Trớ trêu thay, mặc dù tích hợp sẵn tính năng SDK Android 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, xóa 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.
- Hạt 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 của 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 các hạt 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.collapsero.mot.eri.losalert.delayro.config.hw_fast_dormancyro.config.hw_power_savingwindowsmgr.max_events_per_secpersist.cust.tel.eonsro.max.fling_velckro.min.fling_vi.velocity.fling_velckro.min.fling_kênh.fling_velckro. .verify-bytecodedebug.performance.tuningvideo.accelerate.hwro.media.dec.jpeg.memcapro.config.nocheckinprofiler.force_disable_ulogprofiler.force_disable_err_r Chapterist.sys.shutdown.modero.HOME_APP_ADJ