Oleh itu, banyak skrip pengoptimuman all-in-one menggunakan kaedah yang sama, beberapa di antaranya sudah usang atau berbahaya dalam jangka masa panjang. Ringkasnya, sebahagian besar skrip pengoptimuman 'semua-dalam-satu' tidak lain adalah penyesuaian yang disarankan untuk ditampar, tanpa idea yang jelas tentang bagaimana atau mengapa pengoptimuman ini 'berfungsi - pengguna kemudian mem-flash skrip, dan mendakwa prestasinya tiba-tiba lebih cepat ( padahal pada hakikatnya, kemungkinan besar tindakan reboot peranti mereka menyebabkan peningkatan prestasi , kerana semua yang terdapat dalam RAM peranti dibersihkan) .
Dalam artikel eksklusif Appuals ini, kami akan menyoroti beberapa cadangan yang paling umum untuk “ mengoptimumkan ” Prestasi Android, dan apakah itu hanya mitos, atau tweak yang sah untuk prestasi peranti.
Tukar
Di bahagian atas senarai mitos adalah pertukaran Android - yang cukup tidak masuk akal dalam hal dianggap sebagai pengoptimuman Android. Tujuan utama pertukaran adalah membuat dan menyambungkan fail paging, yang akan mengosongkan ruang penyimpanan dalam memori. Ini kedengaran masuk akal atas kertas , tetapi benar-benar berlaku untuk a pelayan , yang hampir tidak mempunyai interaktiviti.
Apabila anda menggunakan pertukaran telefon Android anda secara berkala, ia akan menyebabkan ketinggalan teruk yang disebabkan oleh perkara yang melepasi cache. Bayangkan, misalnya, jika aplikasi mencoba menampilkan grafik, yang disimpan di swap, yang sekarang harus memuat kembali cakera setelah mengosongkan ruang dengan meletakkan pertukaran data dengan aplikasi lain. Ia sangat tidak kemas
Beberapa peminat pengoptimuman dapat mengatakan bahawa pertukaran tidak menawarkan masalah, tetapi bukan pertukaran menjadikan peningkatan prestasi - ini adalah mekanisme Android bawaan lowmemorykiller , yang secara berkala akan membunuh proses kembung, keutamaan tinggi yang tidak digunakan. LMK dirancang khusus untuk menangani keadaan memori rendah, dipanggil dari kswapd proses, dan secara amnya membunuh proses ruang pengguna. Ini berbeza dengan OOMkiller (pembunuh di luar ingatan), tapi itu topik yang berbeza sama sekali.
Intinya adalah, peranti dengan, misalnya, 1 GB RAM tidak pernah dapat mencapai data prestasi yang diperlukan dalam pertukaran, dan jadi pertukaran sama sekali tidak diperlukan di Android. Pelaksanaannya hanya penuh dengan lag dan membawa kepada a kemerosotan dalam prestasi, bukannya mengoptimumkannya.
zRAM - Tertinggal dan Tidak Lagi Cekap
zRAM adalah kaedah yang terbukti dan berkesan untuk pengoptimuman peranti, untuk peranti yang lebih tua - fikirkan peranti berasaskan KitKat yang hanya beroperasi pada sekitar 512 MB RAM. Fakta bahawa beberapa orang masih memasukkan tweak zRAM dalam skrip pengoptimuman, atau mengesyorkan zRAM sebagai semacam tweak pengoptimuman moden, adalah contoh orang pada umumnya tidak mengikuti protokol operasi terkini.
zRAM ditujukan untuk SoC pelbagai teras pelbagai anggaran, seperti peranti yang menggunakan chipset MTK dan RAM 512 MB. Telefon Cina yang sangat murah. Yang pada dasarnya zRAM lakukan adalah memisahkan kernel melalui aliran penyulitan.
Apabila zRAM digunakan pada peranti lama dengan a teras tunggal , walaupun zRAM disyorkan pada peranti sedemikian, ketinggalan dalam jumlah besar cenderung muncul. Ini juga berlaku dengan teknologi KSM ( Penggabungan Halaman Sama Kernel) yang menggabungkan halaman memori yang sama dalam usaha untuk mengosongkan ruang. Ini sebenarnya disarankan oleh Google, tetapi membawa kepada kelewatan yang lebih besar pada peranti yang lebih tua, kerana inti inti yang sentiasa aktif terus berjalan dari memori untuk mencari halaman pendua. Pada asasnya, cuba menjalankan pengoptimuman memperlahankan peranti dengan lebih jauh, ironinya.
Seeder - Usang Sejak Android 3.0
Salah satu petua pengoptimuman yang paling diperdebatkan di kalangan pemaju Android adalah aras , dan kami yakin seseorang boleh mencuba membuktikan kami salah dalam topik ini - tetapi pertama-tama kita perlu meneliti sejarah seeder.
Aplikasi Seeder untuk Android
Ya, terdapat sebilangan besar laporan yang menyatakan prestasi Android yang lebih baik setelah pemasangan dihidupkan peranti Android yang jauh lebih tua . Walau bagaimanapun, orang dengan alasan apa pun percaya ini bermakna ia juga merupakan pengoptimuman yang sesuai untuk peranti Android moden , yang sama sekali tidak masuk akal. Fakta bahawa Seeder masih dipertahankan dan ditawarkan sebagai ' moden' alat pengurangan ketinggian adalah contoh maklumat yang salah - walaupun ini bukan kesalahan pembangun Seeder, malah halaman Play Store mereka menyatakan bahawa Seeder kurang berkesan selepas Android 4.0+. Namun atas alasan apa pun, Seeder masih muncul dalam perbincangan pengoptimuman untuk sistem Android moden.
Apa yang pada dasarnya dilakukan oleh Seeder untuk Android 3.0 adalah mengatasi bug di mana waktu operasi Android akan menggunakan / dev / random / file secara aktif untuk memperoleh entropi. / Dev / random / buffer akan menjadi tidak stabil, dan sistem akan disekat sehingga memenuhi jumlah data yang diperlukan - fikirkan perkara kecil seperti pelbagai sensor dan butang pada peranti Android.
Pengarang Seeder mengambil setan Linux rngd , dan disusun untuk inastroil Android sehingga mengambil data rawak dari jalur / dev / urandom yang jauh lebih cepat dan lebih dapat diramalkan, dan menggabungkannya menjadi dev / random / setiap saat, tanpa membiarkan / dev / random / menjadi habis. Ini menghasilkan sistem Android yang tidak mengalami kekurangan entropi, dan berjalan lebih lancar.
Google memecahkan bug ini setelah Android 3.0, namun untuk sebab tertentu, Seeder masih muncul 'Tweak yang disyorkan' senarai untuk pengoptimuman prestasi Android. Tambahan pula, aplikasi Seeder mempunyai beberapa analog seperti sEFix yang merangkumi fungsi Seeder, sama ada menggunakan yang sama rngd atau alternatifnya dicambuk , atau bahkan hanya symlink antara / dev / urandom dan / dev / random. Ini sama sekali tidak berguna untuk sistem Android moden.
Alasannya tidak berguna adalah kerana versi Android yang lebih baru menggunakan / dev / random / dalam tiga komponen utama - libcrypto , untuk penyulitan sambungan SSL, menghasilkan kunci SSH, dll. WPA_supplication / hostapd yang menghasilkan kunci WEP / WPA, dan akhirnya, sebilangan kecil perpustakaan untuk menghasilkan ID dalam membuat sistem fail EXT2 / EXT3 / EXT4.
Jadi bila Seeder atau Peningkatan berasaskan Seeder disertakan dalam skrip pengoptimuman Android moden, yang akhirnya berlaku adalah kemerosotan dalam prestasi peranti, kerana rngd akan sentiasa menyedarkan peranti dan menyebabkan peningkatan frekuensi CPU, yang tentunya memberi kesan negatif terhadap penggunaan bateri.
Odex
Firmware stok pada peranti Android hampir selalu ada. Ini bermaksud bahawa bersama dengan pakej standard untuk aplikasi Android dalam format APK, yang terdapat di / system / app / dan / system / priv-app /, terdapat nama fail yang sama dengan ekstensi .odex. Fail odex mengandungi aplikasi bytecode yang dioptimumkan yang telah melalui mesin virtual validator dan optimizer, kemudian direkodkan dalam fail berasingan menggunakan sesuatu seperti dexopt alat.
Oleh itu, fail odex bertujuan untuk memuatkan mesin maya dan menawarkan pelancaran aplikasi odexed - pada sisi negatifnya, fail ODEX menghalang pengubahsuaian pada firmware, dan menimbulkan masalah dengan kemas kini, jadi untuk alasan ini banyak ROM tersuai seperti LineageOS diedarkan tanpa ODEX .
Menjana fail ODEX dilakukan dengan beberapa cara, seperti menggunakan Odexer Tool - masalahnya adalah bahawa ia adalah kesan plasebo. Apabila sistem Android moden tidak menemui fail odex di direktori / sistem, sistem akan membuatnya dan meletakkannya di direktori / system / dalvik-cache /. Inilah yang sebenarnya terjadi ketika, misalnya, Anda mem-flash versi Android baru dan memberikan pesan 'Sibuk, Mengoptimumkan Aplikasi' untuk sementara waktu.
Tweak Lowmemorykiller
Multitasking di Android berbeza dengan sistem operasi mudah alih lain dalam arti bahawa berdasarkan model klasik di mana aplikasi berfungsi dengan tenang di latar belakang, dan tidak ada batasan pada jumlah aplikasi latar belakang ( melainkan jika ditetapkan dalam Pilihan Pembangun, tetapi ini biasanya tidak disarankan) - selanjutnya, fungsi peralihan ke pelaksanaan latar belakang tidak dihentikan, walaupun sistem berhak membunuh aplikasi latar belakang dalam situasi memori rendah ( lihat di mana kita bercakap mengenai pembunuh rendah memori dan pembunuh di luar ingatan sebelumnya dalam panduan ini) .
Untuk kembali ke lowmemorykiller mekanisme, Android dapat terus beroperasi dengan jumlah memori yang terhad dan kekurangan partisi pertukaran. Pengguna dapat terus melancarkan aplikasi dan beralih di antara mereka, dan sistem akan mematikan aplikasi latar belakang yang tidak digunakan secara diam-diam untuk mencuba dan mengosongkan memori untuk tugas aktif.
Ini sangat berguna untuk Android pada hari-hari awal, walaupun untuk beberapa alasan ia menjadi popular dalam bentuk aplikasi pembunuh tugas, yang umumnya lebih berbahaya daripada bermanfaat. Aplikasi pembunuh tugas sama ada bangun pada selang waktu yang ditetapkan, atau dijalankan oleh pengguna, dan nampaknya membebaskan sejumlah besar RAM, yang dilihat positif - RAM yang lebih bebas bermaksud peranti yang lebih pantas, bukan? Namun demikian, ini tidak berlaku dengan Android.
Sebenarnya, mempunyai sejumlah besar RAM percuma sebenarnya boleh memudaratkan prestasi dan hayat bateri peranti anda. Apabila aplikasi disimpan dalam RAM Android, lebih mudah untuk memanggilnya, melancarkannya, dll. Sistem Android tidak perlu menumpukan banyak sumber untuk beralih ke aplikasi, kerana sudah ada dalam memori.
Oleh kerana itu, pembunuh tugas tidak begitu popular seperti dulu, walaupun pemula Android masih cenderung bergantung padanya untuk beberapa sebab ( kekurangan maklumat, sayangnya) . Malangnya, trend baru telah menggantikan pembunuh tugas, iaitu trend lowmemorykiller penalaan mekanisme. Ini contohnya MinFreeManager aplikasi, dan idea utamanya adalah untuk meningkatkan RAM overhead sebelum sistem mula membunuh aplikasi latar belakang.
Sebagai contoh, RAM standard beroperasi di sempadan - 4, 8, 12, 24, 32, dan 40 Mb, dan apabila ruang penyimpanan percuma 40 MB diisi, salah satu aplikasi cache yang dimuat ke dalam memori tetapi tidak berjalan akan ditamatkan.
Jadi pada dasarnya, Android akan sentiasa mempunyai sekurang-kurangnya 40 MB memori yang tersedia, yang cukup untuk menampung satu lagi aplikasi sebelumnya lowmemorykiller memulakan proses pembersihannya - yang bermaksud Android akan sentiasa melakukan yang terbaik untuk menggunakan jumlah maksimum RAM yang ada tanpa mengganggu pengalaman pengguna.
Malangnya, apa yang disarankan oleh beberapa peminat homebrew adalah nilai dinaikkan menjadi, misalnya, 100 MB sebelum LMK bermula. Sekarang pengguna akan benar-benar kalah RAM (100 - 40 = 60), jadi daripada menggunakan ruang ini untuk menyimpan aplikasi belakang, sistem akan menyimpan jumlah memori ini percuma , sama sekali tidak mempunyai tujuan untuk itu.
Penalaan LKM boleh berguna untuk peranti yang jauh lebih tua dengan RAM 512, tetapi siapa yang memilikinya lagi? 2GB adalah 'julat anggaran' moden, bahkan peranti RAM 4GB dilihat sebagai 'jajaran tengah' hari ini, jadi tweak LMK benar-benar ketinggalan zaman dan tidak berguna.
Tweak I / O
Dalam banyak skrip pengoptimuman untuk Android, anda akan sering menemui tweak yang menangani subsistem I / O. Sebagai contoh, mari kita lihat di ThunderBolt! Skrip, yang mengandungi baris berikut:
gema 0> $ i / giliran / putaran; echo 1024> $ i / queue / nr_requests;
Baris pertama akan memberi arahan penjadual I / O dalam menangani SSD, dan yang kedua meningkatkan ukuran maksimum I / O barisan dari 128 hingga 1024 - kerana pemboleh ubah $ i mengandungi jalan menuju pokok peranti blok di / sys, dan skrip berjalan dalam satu gelung.
Selepas itu, anda akan menemui garis yang berkaitan dengan penjadual CFQ:
gema 1> $ i / quueue / iosched / back_seek_penalty; gema 1> $ i / quueue / iosched / low_latency; gema 1> $ i / quueue / iosched / slice_idle;
Ini diikuti oleh lebih banyak baris yang termasuk dalam perancang lain, tetapi akhirnya, dua perintah pertama tidak berguna kerana:
Kernel Linux moden dapat memahami jenis media penyimpanan yang digunakannya secara lalai.
Baris input-output yang panjang ( seperti 1024) tidak berguna pada peranti Android moden, sebenarnya tidak berguna walaupun pada desktop - ia hanya disyorkan pada pelayan tugas berat . Telefon anda bukan pelayan Linux tugas berat.
Untuk peranti Android, hampir tidak ada aplikasi yang diprioritaskan dalam input-output dan tidak ada pemacu mekanikal, jadi perancang terbaik adalah noop / FIFO-queue, jadi jenis penjadual ini ' tweak ' tidak melakukan sesuatu yang istimewa atau bermakna bagi subsistem I / O. Sebenarnya, semua arahan senarai pelbagai skrin lebih baik diganti dengan kitaran sederhana:
untuk i in / sys / block / mmc *; lakukan echo noop> $ i / queue / scheduler gema 0> $ i / queue / iostats selesai
Ini akan membolehkan penjadual noop untuk semua pemacu dari pengumpulan statistik I / O, yang semestinya memberi kesan positif pada prestasi, walaupun sangat kecil dan hampir sepenuhnya diabaikan.
Tweak I / O lain yang tidak berguna yang sering dijumpai dalam skrip prestasi adalah peningkatan nilai baca hadapan untuk kad SD hingga 2MB. Mekanisme baca-hadapan adalah untuk pembacaan data awal dari media, sebelum aplikasi meminta akses ke data tersebut. Jadi pada dasarnya, kernel akan berusaha mencari tahu data apa yang akan diperlukan pada masa akan datang, dan memuatkannya ke dalam RAM, yang seharusnya dapat mengurangkan waktu kembali. Kedengarannya hebat di atas kertas, tetapi algoritma membaca lebih kerap salah , yang membawa kepada operasi input-output yang sama sekali tidak perlu, apatah lagi penggunaan RAM yang tinggi.
Nilai baca tinggi antara 1 - 8 MB disyorkan dalam array RAID, tetapi untuk peranti Android, sebaiknya tinggalkan nilai lalai 128 KB.
Tweak sistem Pengurusan Memori Maya
Teknik 'pengoptimuman' lain yang biasa adalah menala subsistem pengurusan memori maya. Ini biasanya menyasarkan hanya dua pemboleh ubah kernel, vm.dirty_background_ratio dan vm.dirty_ratio, yang untuk menyesuaikan ukuran penyangga untuk menyimpan data 'kotor'. Kotor data biasanya adalah data yang telah ditulis ke cakera, tetapi masih banyak lagi yang masih ada dalam memori dan menunggu untuk ditulis ke cakera.
Nilai tweak khas di kedua distro Linux dan Androis ke subsistem pengurusan VM adalah seperti:
vm.dirty_background_ratio = 10 vm.dirty_ratio = 20
Oleh itu, apa yang cuba dilakukan ini ialah apabila penyangga data kotor adalah 10% daripada jumlah RAM, ia akan terbangun pdflush mengalir dan mula menulis data ke disk - jika operasi merakam data pada disk akan terlalu kuat , penyangga akan terus bertambah, dan apabila mencapai 20% RAM yang tersedia, sistem akan beralih ke operasi penulisan berikutnya dalam mod segerak - tanpa pra-penyangga. Ini bermaksud kerja menulis ke aplikasi cakera akan disekat, sehingga data ditulis ke cakera (AKA ‘lag’).
Yang harus anda fahami adalah walaupun ukuran penyangga tidak mencapai 10% , sistem akan secara automatik menggunakan pdflush selepas 30 saat. Kombinasi 10/20 cukup berpatutan, misalnya pada peranti dengan RAM 1GB ini sama dengan RAM 100 / 200MB, yang lebih dari cukup dari segi rekod pecah di mana kelajuan selalunya di bawah rekod kelajuan di sistem NAND -memori, atau kad SD, seperti ketika memasang aplikasi atau menyalin fail dari komputer.
Atas sebab-sebab tertentu, penulis skrip cuba mendorong nilai ini lebih tinggi, ke tahap yang tidak masuk akal. Contohnya kita dapati di Xplix skrip pengoptimuman kadar setinggi 50/90.
sysctl -w vm.dirty_background_ratio = 50 sysctl -w vm.dirty_ratio = 90
Pada peranti dengan memori 1 GB, ini menetapkan had penyangga kotor hingga 500/900 MB, yang sama sekali tidak berguna untuk peranti Android, kerana hanya berfungsi di bawah rakaman berterusan pada cakera - sesuatu yang hanya berlaku pada pelayan Linux yang berat.
ThunderBolt! Skrip menggunakan nilai yang lebih masuk akal, tetapi secara keseluruhan, skripnya masih tidak bermakna:
jika ['$ mem' -lt 524288]; maka sysctl -w vm.dirty_background_ratio = 15; sysctl -w vm.dirty_ratio = 30; elif ['$ mem' -lt 1049776]; kemudian sysctl -w vm.dirty_background_ratio = 10; sysctl -w vm.dirty_ratio = 20; lain sysctl -w vm.dirty_background_ratio = 5; sysctl -w vm.dirty_ratio = 10; fi;
Dua arahan pertama dijalankan pada telefon pintar dengan RAM 512 MB, yang kedua - dengan 1 GB, dan yang lain - dengan lebih dari 1 GB. Tetapi sebenarnya hanya ada satu alasan untuk mengubah tetapan lalai - peranti dengan kad memori atau memori dalaman yang sangat perlahan. Dalam kes ini, adalah wajar untuk menyebarkan nilai pemboleh ubah, iaitu, untuk membuat sesuatu seperti ini:
sysctl -w vm.dirty_background_ratio = 10 sysctl -w vm.dirty_ratio = 60
Kemudian, apabila sistem lonjakan menulis operasi, tanpa perlu merakam data pada cakera, hingga yang terakhir tidak akan beralih ke mod segerak, yang akan membolehkan aplikasi mengurangkan kelambatan semasa merakam.
Tweaks dan Penalaan Prestasi Tambahan Tidak Berguna
Terdapat banyak lagi 'pengoptimuman' di luar sana yang benar-benar tidak melakukan apa-apa. Sebilangan besar dari mereka tidak mempunyai kesan sama sekali, sementara yang lain mungkin bertambah baik beberapa aspek prestasi, sambil merendahkan peranti dengan cara lain ( biasanya turun ke prestasi vs kehabisan bateri) .
Berikut adalah beberapa pengoptimuman popular tambahan yang mungkin berguna atau tidak, bergantung pada sistem dan peranti Android.
- Pecutan - Pecutan kecil untuk meningkatkan prestasi dan undervolting - menjimatkan sedikit bateri.
- Pengoptimuman Pangkalan Data - Secara teori ini semestinya memberikan peningkatan prestasi peranti, tetapi diragukan.
- Zipalign - Ironinya, walaupun terdapat penjajaran kandungan ciri SDK Android yang ada di dalam fail APK di kedai, anda dapati banyak perisian tidak dihantar melalui zipalign.
- Lumpuhkan perkhidmatan sistem yang tidak perlu, hapus sistem yang tidak digunakan dan aplikasi pihak ketiga yang jarang digunakan. Pada dasarnya, menyahpasang bloatware.
- Kernel khusus dengan pengoptimuman untuk peranti tertentu (sekali lagi, tidak semua inti sama baiknya).
- Sudah dijelaskan I / O scheduler noop.
- Algoritma ketepuan TCP Westwood - Lebih cekap digunakan dalam Android Cubic lalai untuk rangkaian tanpa wayar, tersedia dalam kernel tersuai.
Tetapan tidak berguna build.prop
LaraCraft304 dari forum Pengembang XDA telah melakukan kajian dan mendapati bahawa sebilangan besar tetapan / system/build.prop yang disyorkan untuk digunakan sebagai 'pakar' tidak ada dalam sumber AOSP dan CyanogenMod. Inilah senarai:
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 persist.cust.tel.eons ro.max.fling_velocity ro.min.fling_vel. kernel.checkjni dalvik.Teg android Pembangunan 12 minit membaca
