Mitos Pengoptimuman Android Yang Paling Popular

Terdapat banyak panduan pengajaran di luar sana yang didedikasikan untuk meningkatkan prestasi Android, dan petua pengoptimuman keseluruhan. Sesetengah daripada mereka adalah sah, dan yang lain hanya berasaskan teori, atau kaedah operasi ketinggalan zaman dalam sistem Android, atau hanya tidak masuk akal. Ini termasuk cadangan untuk menukar, nilai tambah untuk build.prop, dan perubahan berubah dalam kernel Linux.

Terdapat juga satu "skrip pengoptimuman" di luar sana, all-in-one .zips yang boleh menjejaskan prestasi yang ketara, hayat bateri, dan lain-lain. Sesetengah tweak sebenarnya boleh berfungsi, tetapi majoriti hanya kesan plasebo, atau lebih teruk, sebenarnya mempunyai kesan negatif pada peranti anda.

Itu bukan untuk mengatakan bahawa orang akan melepaskan skrip jahat dengan sengaja - ada pasti aplikasi berbayar berbayar di Play Store, tetapi skrip pengoptimuman yang dikeluarkan di forum Android pada umumnya berniat baik, hanya berlaku bahawa pemaju mungkin salah, atau hanya bereksperimen dengan pelbagai tweak pengoptimuman. Malangnya, semacam kesan bola salji cenderung berlaku, terutamanya dalam skrip pengoptimuman "semua-dalam-satu". Sebilangan kecil tweak mungkin sebenarnya melakukan sesuatu, sementara satu lagi tweak dalam skrip mungkin sama sekali tidak berbuat apa-apa - tetapi skrip-skrip ini dapat diturunkan sebagai peluru ajaib, tanpa penyiasatan sebenar apa yang berfungsi, dan apa yang tidak .

Oleh itu, banyak skrip pengoptimuman all-in-one menggunakan kaedah yang sama, beberapa di antaranya sudah ketinggalan zaman atau berbahaya dalam jangka masa panjang. Ringkasnya, kebanyakan skrip pengoptimuman "semua-dalam-satu" tidak lain hanyalah menampan-bersama-sama dengan penyesuaian yang disyorkan, tanpa idea jelas tentang bagaimana atau mengapa pengoptimuman ini "berfungsi - pengguna kemudian memaparkan skrip, dan menuntut prestasi mereka tiba-tiba lebih cepat ( pada hakikatnya, kemungkinan besar perbuatan mudah menaikkan semula peranti mereka yang menyebabkan peningkatan prestasi, kerana segala-galanya dalam RAM peranti akan dibersihkan) .

Dalam artikel eksklusif Appuals ini, kami akan menyerlahkan beberapa saranan yang paling biasa untuk " mengoptimumkan" prestasi Android, dan sama ada ia hanya satu mitos, atau tweak yang sah untuk prestasi peranti.

Pertukaran

Di bahagian atas senarai mitos adalah swap Android - yang agak tidak masuk akal dari segi pemikiran sebagai pengoptimuman Android. Swap tujuan utama adalah untuk membuat dan menyambungkan fail paging, yang akan mengosongkan ruang simpanan dalam memori. Ini berbunyi wajar di atas kertas, tetapi ia benar-benar terpakai kepada pelayan, yang hampir tidak mempunyai interaktiviti.

Apabila anda menggunakan swap telefon Android anda secara teratur, ia akan menyebabkan ketegangan teruk yang berpunca daripada perkara yang tergelincir melewati cache. Bayangkan, sebagai contoh, jika aplikasi cuba memaparkan grafik, yang disimpan dalam swap, yang kini perlu memuat semula cakera selepas membebaskan ruang dengan meletakkan pertukaran data dengan aplikasi lain. Ia benar-benar kemas.

Sesetengah peminat pengoptimuman boleh mengatakan bahawa swap tidak menawarkan masalah, tetapi ia tidak menukar menjadikan peningkatan prestasi - ia adalah mekanisme terbina dalam Android lowmemorykiller, yang akan membunuh secara berkala, proses keutamaan tinggi yang tidak digunakan. LMK direka khusus untuk mengendalikan keadaan memori rendah, dipanggil dari proses kswapd, dan secara amnya membunuh proses ruang pengguna. Ini berbeza dengan OOMkiller (pembunuh out-of-memory), tetapi itu adalah topik yang berbeza sama sekali.

Intinya, peranti dengan, sebagai contoh, 1GB RAM tidak boleh mencapai data prestasi yang diperlukan dalam swap, dan swap sememangnya tidak diperlukan dalam Android. Pelaksanaannya hanya penuh dengan ketinggalan dan membawa kepada kemerosotan prestasi, daripada mengoptimalkannya.

zRAM - Ketinggalan zaman dan Tiada Lagi Cekap

zRAM adalah kaedah yang terbukti dan berkesan untuk pengoptimuman peranti, untuk peranti yang lebih lama - fikirkan peranti berasaskan KitKat yang beroperasi pada hanya kira-kira 512 MB RAM. Hakikat bahawa sesetengah orang masih termasuk tweak zRAM dalam skrip pengoptimuman, atau mengesyorkan zRAM sebagai semacam tweak pengoptimuman moden, adalah contoh orang umumnya tidak mengikuti protokol operasi terkini.

zRAM bertujuan untuk SoCs multi-core bajet peringkat masuk, seperti peranti menggunakan chipset MTK dan RAM 512 MB. Telefon Cina yang sangat murah, pada asasnya. Apa yang zRAM pada dasarnya adalah memisahkan kernel melalui aliran penyulitan.

Apabila zRAM digunakan pada peranti lama dengan teras tunggal, walaupun zRAM disyorkan pada peranti sedemikian, kuantiti yang banyak tidak dapat dicas. Ini juga berlaku dengan teknologi KSM ( Kernel Same Page Merging) yang menggabungkan laman memori yang sama dalam usaha untuk membebaskan ruang. Ini sebenarnya disyorkan oleh Google, tetapi membawa kepada kejatuhan yang lebih besar pada peranti yang lebih tua, kerana teras teras yang sentiasa aktif berjalan secara berterusan dari ingatan untuk mencari halaman pendua. Pada dasarnya, cuba menjalankan tweak pengoptimuman melambatkan peranti lebih jauh, ironinya.

Seeder - Outdated Sejak Android 3.0

Salah satu petua pengoptimuman yang paling diperdebatkan di kalangan Android devs adalah pemula, dan kami pasti seseorang boleh cuba membuktikan kami salah dalam topik ini - tetapi pertama-tama kami perlu memeriksa sejarah penanam.

Ya, terdapat sejumlah besar laporan yang mengisytiharkan prestasi Android yang lebih baik selepas pemasangan pada peranti Android yang lebih tua . Walau bagaimanapun, orang atas sebab apa pun percaya ini bermakna ia juga merupakan pengoptimalan yang boleh digunakan untuk peranti Android moden, yang benar-benar tidak masuk akal. Hakikat bahawa Seeder masih dikekalkan dan ditawarkan sebagai alat pengurangan lag "moden" adalah contoh maklumat yang salah - walaupun ini bukanlah kesalahan pemaju Seeder, kerana halaman Play Store mereka juga mencatat bahwa Seeder kurang berkesan setelah Android 4.0+. Namun untuk apa sebabnya, Seeder masih muncul dalam perbincangan pengoptimalan untuk sistem Android moden.

Apa Seeder pada dasarnya tidak untuk Android 3.0 adalah alamat bug di mana Android runtime akan secara aktif menggunakan / dev / random / file untuk memperoleh entropi. / Dev / random / buffer akan menjadi tidak stabil, dan sistem akan disekat sehingga ia mengisi jumlah data yang diperlukan - berfikir perkara-perkara kecil seperti pelbagai sensor dan butang pada peranti Android.

Penulis Seeder mengambil ringgit -syaitan Linux, dan disusun untuk inastroil Android supaya ia mengambil data rawak dari laluan / dev / urandom yang lebih cepat dan lebih diramal, dan menggabungkannya ke dev / random / setiap saat, tanpa membenarkan / dev / random / menjadi lelah. Ini mengakibatkan sistem Android yang tidak mengalami kekurangan entropi, dan dilakukan dengan lebih lancar.

Google menghancurkan bug ini selepas Android 3.0, namun untuk sebab tertentu, Seeder masih muncul pada senarai "tweak yang disyorkan" untuk pengoptimuman prestasi Android. Selain itu, aplikasi Seeder mempunyai beberapa analog seperti sEFix yang merangkumi fungsi Seeder, sama ada menggunakan rngd yang sama atau alternatif yang dicetuskan, atau hanya symlink antara / dev / urandom dan / dev / rawak. Ini sama sekali tidak berguna untuk sistem Android moden.

Sebabnya tidak berguna adalah kerana versi Android yang lebih baru menggunakan / dev / random / dalam tiga komponen utama - libcrypto, untuk penyulitan sambungan SSL, menghasilkan kunci SSH, dan lain-lain WPA_supplication / hostapd yang menghasilkan kunci WEP / WPA, perpustakaan untuk menghasilkan ID dalam membuat sistem fail EXT2 / EXT3 / EXT4.

Jadi apabila penambahan Seeder atau Seeder dimasukkan dalam skrip pengoptimuman Android moden, apa yang akan berlaku adalah kemerosotan dalam prestasi peranti, kerana rngd akan sentiasa membangkitkan peranti dan menyebabkan peningkatan kekerapan CPU, yang tentu saja memberi kesan negatif kepada penggunaan bateri .

Odex

Firmware saham pada peranti Android cukup banyak selalu odex. Ini bermakna bahawa di samping pakej standard untuk aplikasi Android dalam format APK, terdapat dalam / sistem / aplikasi / dan / sistem / aplikasi priv /, adalah nama fail yang sama dengan sambungan kododex. Fail odex mengandungi aplikasi bytecode yang dioptimumkan yang telah melalui mesin pengesah dan pengoptimasi mesin maya, kemudian direkodkan dalam fail berasingan menggunakan sesuatu seperti alat dexopt .

Oleh itu, fail odex bertujuan untuk mengasingkan mesin maya dan menawarkan peluncuran aplikasi runcing - pada bahagian bawah, fail ODEX menghalang pengubahsuaian pada firmware, dan membuat masalah dengan kemas kini, oleh sebab itu banyak ROM tersuai seperti LineageOS diedarkan tanpa ODEX .

Menjana fail ODEX dilakukan dalam beberapa cara, seperti menggunakan Alat Odexer - masalahnya ialah kesan plasebo semata-mata. Apabila sistem Android moden tidak menemui fail odex dalam direktori / sistem, sistem sebenarnya akan membuatnya dan meletakkannya dalam direktori / system / dalvik-cache /. Inilah yang berlaku ketika, sebagai contoh, anda menghidupkan versi Android baru dan memberikan mesej "Sibuk, Mengoptimalkan Aplikasi" untuk seketika.

Tweak lowmemorykiller

Multitasking di Android berbeza dengan sistem pengendalian mudah alih lain dalam erti kata bahawa berdasarkan model klasik di mana aplikasi bekerja secara senyap di latar belakang, dan tidak ada sekatan ke atas bilangan aplikasi latar belakang ( melainkan jika satu ditetapkan dalam Pilihan Pembangun, tetapi ini adalah biasanya disyorkan) - tambahan pula, fungsi peralihan kepada pelaksanaan latar belakang tidak dihentikan, walaupun sistem berhak untuk membunuh aplikasi latar belakang dalam situasi memori yang rendah ( lihat di mana kita bercakap tentang pemadam pengemis rendah dan pembunuh memori luar sebelum ini panduan) .

Untuk kembali ke mekanisme pengemasan rendah, Android boleh terus beroperasi dengan jumlah memori yang terhad dan kekurangan swap-partition. Pengguna boleh terus melancarkan aplikasi dan beralih di antara mereka, dan sistem akan secara senyap-senyap membunuh aplikasi latar belakang yang tidak digunakan untuk mencuba dan membebaskan memori untuk tugas aktif.

Ini sangat berguna untuk Android pada hari-hari awal, walaupun untuk beberapa sebabnya menjadi popular dalam bentuk aplikasi pembunuh tugas, yang pada umumnya lebih berbahaya daripada berfaedah. Aplikasi pembunuh tugas sama ada bangun pada jarak yang ditetapkan, atau dijalankan oleh pengguna, dan muncul untuk membebaskan sejumlah besar RAM, yang dilihat sebagai positif - RAM lebih bebas bermakna peranti lebih cepat, bukan? Walau bagaimanapun, ini tidak tepat dengan Android.

Malah, mempunyai sejumlah besar RAM percuma sebenarnya boleh memudaratkan prestasi peranti anda dan hayat bateri. Apabila apl disimpan dalam RAM Android, lebih mudah untuk memanggilnya, melancarkannya, dan sebagainya. Sistem Android tidak perlu menumpukan banyak sumber untuk beralih ke aplikasi, kerana sudah ada di dalam memori.

Oleh kerana itu, pembunuh tugas tidak begitu popular seperti yang mereka pernah lakukan, walaupun orang Android masih cenderung bergantung kepada mereka atas sebab tertentu ( kekurangan maklumat, sayangnya) . Sayangnya, trend baru telah menggantikan pembunuh tugas, trend aliran mekanisme penggerak rendah . Ini akan menjadi contoh aplikasi MinFreeManager, dan idea utama adalah untuk meningkatkan overhead RAM 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 dimuatkan ke memori tetapi tidak berjalan akan ditamatkan.

Oleh itu pada dasarnya, Android akan sentiasa mempunyai sekurang-kurangnya 40 MB ingatan yang tersedia, yang cukup untuk menampung satu lagi aplikasi sebelum proses pembersihan semula bermula proses pembersihan - yang bermaksud Android akan sentiasa melakukan yang terbaik untuk menggunakan jumlah maksimum RAM yang tersedia tanpa mengganggu pengalaman pengguna.

Malangnya, apa yang digalakkan oleh peminat homebrew adalah bahawa nilai akan dinaikkan kepada, misalnya, 100 MB sebelum LMK akan masuk. Sekarang pengguna akan kehilangan RAM (100 - 40 = 60), jadi bukannya menggunakan ruang ini untuk menyimpan back- aplikasi akhir, sistem ini akan menyimpan jumlah memori ini secara percuma, dengan sememangnya tiada tujuan untuknya.

Penalaan LKM boleh berguna untuk peranti yang lebih lama dengan 512 RAM, tetapi siapa yang memiliki mereka lagi? 2GB adalah "anggaran belanjawan" yang moden, walaupun peranti RAM 4GB dilihat sebagai "jarak tengah" pada hari ini, jadi tweak LMK benar-benar ketinggalan zaman dan tidak berguna.

I / O tweak

Dalam banyak skrip pengoptimuman untuk Android, anda akan sering mencari tweak yang menangani subsistem I / O. Sebagai contoh, sila lihat pada ThunderBolt! Skrip, yang mengandungi baris ini:

 echo 0> $ i / giliran / putaran; echo 1024> $ i / queue / nr_requests; 

Baris pertama akan memberikan arahan penjadual I / O dalam menangani SSD, dan kedua meningkatkan saiz maksimum I / O gilir dari 128 hingga 1024 - kerana pembolehubah $ i mengandungi jalan ke pokok peranti blok / sys, dan skrip berjalan dalam gelung.

Berikutan itu, anda mencari garis yang berkaitan dengan penjadual CFQ:

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

Ini diikuti oleh lebih banyak baris yang dimiliki oleh perancang lain, tetapi akhirnya, dua perintah pertama adalah sia-sia kerana:

Kernel Linux moden dapat memahami jenis media penyimpanan yang ia gunakan secara lalai.

Giliran input-output yang lama ( seperti 1024) tidak berguna pada peranti Android moden, sebenarnya tidak bermakna walaupun di desktop - yang benar-benar 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 tiada pemandu mekanikal, jadi perancang terbaik adalah noop / FIFO-baris, jadi jenis penjadwal " tweak" ini tidak melakukan sesuatu yang istimewa atau bermakna I / O subsistem. Malah, semua arahan senarai multi-skrin lebih baik digantikan dengan kitaran mudah:

 untuk i dalam / sys / block / mmc *; do echo noop> $ i / queue / scheduler echo 0> $ i / queue / iostats done 

Ini akan membolehkan penjadual noop untuk semua pemacu dari pengumpulan statistik I / O, yang sepatutnya mempunyai kesan positif terhadap prestasi, walaupun sangat kecil dan hampir tidak dapat diabaikan.

Satu lagi I / O tweak yang tidak berguna yang sering dijumpai dalam skrip prestasi adalah peningkatan nilai baca untuk kad SD sehingga 2MB. Mekanisme baca hadapan adalah untuk membaca data awal dari media, sebelum aplikasi meminta akses kepada data tersebut. Jadi pada asasnya, kernel akan cuba untuk mencari tahu apa data yang diperlukan pada masa akan datang, dan pra-beban ke dalam RAM, yang sepatutnya mengurangkan masa pulangan. Ini berbunyi hebat di atas kertas, tetapi algoritma baca lebih awal lebih sering salah, yang menyebabkan operasi input-output yang tidak perlu, tidak lagi penggunaan RAM yang tinggi.

Nilai baca-maju yang tinggi antara 1 - 8 MB disyorkan dalam array RAID, tetapi untuk peranti Android, yang terbaik hanya untuk meninggalkan nilai lalai 128 KB.

Tweak sistem Pengurusan Maya Memori

Satu lagi teknik "pengoptimuman" yang biasa adalah mensimulasikan subsistem pengurusan memori maya. Ini biasanya mensasarkan hanya dua pemboleh ubah kernel, vm.dirty_background_ratio dan vm.dirty_ratio, yang adalah untuk menyesuaikan saiz penampan untuk menyimpan data "kotor". Data kotor biasanya data yang telah ditulis ke cakera, tetapi masih terdapat memori dan menunggu untuk ditulis ke cakera.

Nilai tweak tipikal di kedua distro Linux dan Androis ke subsistem pengurusan VM akan seperti:

 vm.dirty_background_ratio = 10 vm.dirty_ratio = 20 

Jadi apa yang cuba dilakukan ialah apabila penimbal data kotor adalah 10% dari jumlah RAM, ia membangkitkan aliran pdflush dan mula menulis data ke cakera - jika operasi data rakaman pada cakera akan terlalu sengit, penimbal akan terus berkembang, dan ketika mencapai 20% dari RAM yang tersedia, sistem akan beralih ke operasi menulis berikutnya dalam mod segerak - tanpa pra-penyangga. Ini bermakna kerja menulis ke aplikasi cakera akan disekat, sehingga data ditulis ke cakera (lag 'AKA').

Apa yang anda perlu fahami ialah walaupun saiz penampan tidak mencapai 10%, sistem akan secara automatik menendang dalam pdflush selepas 30 saat. Gabungan 10/20 cukup masuk akal, contohnya pada peranti dengan RAM 1GB ini akan bersamaan dengan 100 / 200MB RAM, yang lebih daripada cukup dari segi rekod pecah di mana kelajuan sering di bawah rekod kelajuan dalam sistem NAND -memory, atau kad SD, seperti ketika memasang aplikasi atau menyalin fail dari komputer.

Atas sebab tertentu, penulis skrip cuba untuk menolak nilai ini lebih tinggi, dengan kadar yang tidak masuk akal. Contohnya, kita dapat mencari skrip pengoptimuman Xplix dengan 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 pada penampan kotor hingga 500/900 MB, yang sama sekali tidak berguna untuk peranti Android, kerana ia hanya akan berfungsi di bawah rakaman berterusan pada cakera - sesuatu yang hanya berlaku pada berat Pelayan Linux.

ThunderBolt! Skrip menggunakan nilai yang lebih munasabah, tetapi keseluruhan, yang 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], maka 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 perintah pertama dijalankan pada telefon pintar dengan RAM 512 MB, yang kedua - dengan 1 GB, dan lain-lain - dengan lebih daripada 1 GB. Tetapi sebenarnya hanya ada satu sebab untuk mengubah tetapan lalai - peranti dengan memori dalaman yang sangat perlahan atau kad memori. Dalam kes ini adalah munasabah untuk menyebarkan nilai pembolehubah, 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, sehingga yang terakhir tidak akan beralih ke mod segerak, yang akan membolehkan aplikasi mengurangkan kelewatan semasa merakam.

Tambahan Tweak Tidak Sesuai dan Tuning Prestasi

Terdapat lebih banyak "pengoptimuman" di luar sana yang benar-benar tidak melakukan apa-apa. Sebahagian besar daripada mereka tidak mempunyai kesan apa pun, sementara yang lain mungkin meningkatkan beberapa aspek prestasi, sementara merendahkan peranti dengan cara lain ( biasanya ia beralih ke prestasi vs saliran bateri) .

Berikut adalah beberapa pengoptimuman popular tambahan yang mungkin atau mungkin tidak berguna, bergantung pada sistem dan peranti Android.

• Pecutan - Pecutan kecil untuk meningkatkan prestasi dan undervolting - menjimatkan sedikit bateri.
• Pengoptimuman Pangkalan Data - Secara teori ini perlu memberi peningkatan dalam prestasi peranti, tetapi yang diragukan.
• Zipalign - Ironinya, walaupun penjajaran kandungan SDK Android terbina dalam dalam fail APK di kedai anda boleh menemui banyak perisian yang tidak dihantar melalui zipalign.
• Lumpuhkan perkhidmatan sistem yang tidak diperlukan, alih keluar sistem yang tidak digunakan dan aplikasi pihak ketiga yang jarang digunakan. Pada asasnya, menyahpasang bloatware.
• Kernel tersuai dengan pengoptimuman untuk peranti tertentu (sekali lagi, tidak semua nukleus sama-sama baik).
• Telah diterangkan I / O scheduler noop.
• Algoritma ketepuan TCP Westwood - Lebih cekap digunakan dalam Android Cubic lalai untuk rangkaian wayarles, tersedia dalam kernel khusus.

Membina tetapan yang tidak berguna

LaraCraft304 dari forum Pemaju XDA telah menjalankan kajian dan mendapati bahawa sejumlah tetapan / system /build.prop yang mengagumkan yang disyorkan untuk menggunakan "pakar" tidak wujud 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_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.mode ro.HOME_APP_ADJ