Mitos Optimasi Android Paling Umum Terbongkar

Ada banyak panduan instruksional di luar sana yang didedikasikan untuk meningkatkan kinerja Android, dan tips pengoptimalan keseluruhan. Beberapa di antaranya sah, dan yang lain hanya berdasarkan teori, atau metode operasional yang ketinggalan zaman dalam sistem Android, atau hanya omong kosong belaka. Ini termasuk rekomendasi untuk bertukar, nilai tambah ke build.prop, dan perubahan variabel di kernel Linux.

Bahkan ada satu ton "skrip pengoptimalan" di luar sana, all-in-one flashable. Zip yang menjanjikan peningkatan kinerja, daya tahan baterai, dan hal-hal lainnya secara signifikan. Beberapa tweak sebenarnya dapat bekerja, tetapi mayoritas hanyalah efek plasebo, atau lebih buruk, sebenarnya memiliki dampak negatif pada perangkat Anda.

Itu bukan untuk mengatakan bahwa orang-orang melepaskan skrip jahat dengan sengaja - pasti ada aplikasi berbayar palsu di Play Store, tetapi skrip optimisasi yang dirilis di forum Android pada umumnya bermaksud baik, kebetulan bahwa pengembang mungkin salah informasi, atau hanya bereksperimen dengan berbagai penyesuaian optimasi. Sayangnya, semacam efek bola salju cenderung terjadi, terutama di skrip optimisasi "all-in-one". Segelintir kecil tweak sebenarnya bisa melakukan sesuatu, sementara set tweak lain dalam naskah mungkin sama sekali tidak melakukan apa pun - namun skrip ini diturunkan sebagai peluru ajaib, tanpa penyelidikan nyata apa yang berhasil, dan apa yang tidak .

Dengan demikian, banyak skrip optimasi all-in-one menggunakan metode yang sama, beberapa di antaranya benar-benar usang atau berbahaya dalam jangka panjang. Singkatnya, sebagian besar skrip pengoptimalan “semua-dalam-satu” tidak lain adalah penyetelan rekomendasi yang ditampar bersama, tanpa gagasan yang jelas tentang bagaimana atau mengapa optimasi ini “bekerja - pengguna kemudian mem-flash skrip, dan mengklaim kinerja mereka tiba-tiba lebih cepat ( padahal, kemungkinan besar tindakan sederhana me-reboot perangkat mereka yang menyebabkan peningkatan kinerja, karena semua yang ada di RAM perangkat dibersihkan) .

Dalam artikel eksklusif Appuals ini, kami akan menyoroti beberapa rekomendasi paling umum untuk " mengoptimalkan" kinerja Android, dan apakah itu hanya mitos, atau tweak yang sah untuk kinerja perangkat.

Menukar

Di bagian atas daftar mitos adalah swap Android - yang cukup absurd dalam hal dianggap sebagai optimasi Android. Bertukar tujuan utama adalah untuk membuat dan menghubungkan file paging, yang akan membebaskan ruang penyimpanan dalam memori. Ini terdengar masuk akal di atas kertas, tetapi benar-benar berlaku untuk server, yang hampir tidak memiliki interaktivitas.

Ketika Anda menggunakan swap ponsel Android Anda secara teratur, itu akan menyebabkan kelambatan parah yang berasal dari hal-hal yang melewati cache. Bayangkan, misalnya, jika suatu aplikasi mencoba untuk menampilkan grafik, yang disimpan dalam swap, yang sekarang harus memuat ulang disk setelah mengosongkan ruang dengan menempatkan pertukaran data dengan aplikasi lain. Benar-benar berantakan.

Beberapa penggemar optimisasi dapat mengatakan bahwa swap tidak menawarkan masalah, tetapi swap tidak membuat peningkatan kinerja - ini adalah mekanisme rendah-memori Android mekanisme rendah, yang akan secara teratur membunuh proses kembung, prioritas tinggi yang tidak digunakan. LMK dirancang khusus untuk menangani kondisi memori rendah, dipanggil dari proses kswapd, dan umumnya membunuh proses ruang pengguna. Ini berbeda dari OOMkiller (out-of-memory killer), tapi itu topik yang berbeda sama sekali.

Intinya adalah, perangkat dengan, misalnya, 1GB RAM tidak pernah dapat mencapai data kinerja yang diperlukan dalam swap, dan karenanya swap sama sekali tidak diperlukan di Android. Implementasinya hanya penuh dengan lag dan mengarah pada penurunan kinerja, daripada mengoptimalkannya.

zRAM - Sudah usang dan Tidak Lagi Efisien

zRAM adalah metode yang terbukti dan efektif untuk optimasi perangkat, untuk perangkat yang lebih tua - pikirkan perangkat berbasis KitKat yang beroperasi hanya dengan sekitar 512 MB RAM. Fakta bahwa beberapa orang masih memasukkan tweak zRAM dalam skrip optimisasi, atau merekomendasikan zRAM sebagai semacam tweak optimisasi modern, adalah contoh orang yang umumnya tidak mengikuti protokol operasional terbaru.

zRAM ditujukan untuk SoC multi-core rentang-anggaran tingkat pemula, seperti perangkat yang menggunakan chipset MTK dan RAM 512 MB. Ponsel Cina sangat murah, pada dasarnya. Apa yang dilakukan zRAM pada dasarnya adalah memisahkan kernel melalui aliran enkripsi.

Ketika zRAM digunakan pada perangkat yang lebih tua dengan satu inti, bahkan jika zRAM direkomendasikan pada perangkat tersebut, banyak lag yang cenderung muncul. Ini juga terjadi dengan teknologi KSM ( Kernel Same Page Merging) yang menggabungkan halaman memori yang identik dalam upaya untuk mengosongkan ruang. Ini sebenarnya direkomendasikan oleh Google, tetapi mengarah ke kelambatan yang lebih besar pada perangkat yang lebih tua, karena inti inti yang terus-menerus aktif berjalan terus-menerus dari memori untuk mencari halaman duplikat. Pada dasarnya, mencoba menjalankan optimasi tweak memperlambat perangkat lebih jauh, ironisnya.

Seeder - Usang Sejak Android 3.0

Salah satu kiat pengoptimalan yang paling diperdebatkan di antara pengembang Android adalah seeder, dan kami yakin seseorang dapat mencoba membuktikan kami salah tentang topik ini - tetapi pertama-tama kita perlu memeriksa sejarah seeder.

Aplikasi Seeder untuk Android

Ya, ada sejumlah besar laporan yang menyatakan kinerja Android yang lebih baik setelah instalasi pada perangkat Android yang jauh lebih tua . Namun, orang dengan alasan apa pun percaya ini berarti ini juga merupakan pengoptimalan yang berlaku untuk perangkat Android modern, yang benar-benar tidak masuk akal. Fakta bahwa Seeder masih dipertahankan dan ditawarkan sebagai alat pengurangan lag "modern" adalah contoh informasi yang salah - meskipun ini bukan kesalahan pengembang Seeder, karena bahkan halaman Play Store mereka mencatat bahwa Seeder kurang efektif setelah Android 4.0+. Namun untuk alasan apa pun, Seeder masih muncul dalam diskusi optimasi untuk sistem Android modern.

Apa yang pada dasarnya Seeder lakukan untuk Android 3.0 adalah mengatasi bug di mana Android runtime akan secara aktif menggunakan file / dev / random / untuk mendapatkan entropi. / Dev / random / buffer akan menjadi tidak stabil, dan sistem akan diblokir hingga memenuhi jumlah data yang diperlukan - pikirkan hal-hal kecil seperti berbagai sensor dan tombol pada perangkat Android.

Penulis Seeder mengambil Linux-demon rngd, dan dikompilasi untuk inastroil Android sehingga mengambil data acak dari jalur yang lebih cepat dan lebih dapat diprediksi / dev / urandom, dan menggabungkannya menjadi dev / acak / setiap detik, tanpa mengizinkan / dev / acak Saya menjadi lelah. Ini menghasilkan sistem Android yang tidak mengalami kekurangan entropi, dan tampil lebih lancar.

Google menghancurkan bug ini setelah Android 3.0, namun untuk beberapa alasan, Seeder masih muncul di daftar "tweak yang direkomendasikan" untuk optimasi kinerja Android. Selain itu, aplikasi Seeder memiliki beberapa analog seperti sEFix yang mencakup fungsionalitas Seeder, apakah menggunakan rngd yang sama atau alternatif yang ada, atau bahkan hanya hubungan antara / dev / urandom dan / dev / random. Ini sama sekali tidak ada gunanya untuk sistem Android modern.

Alasan tidak ada gunanya adalah karena versi Android yang lebih baru menggunakan / dev / random / dalam tiga komponen utama - libcrypto, untuk enkripsi koneksi SSL, menghasilkan kunci SSH, dll. WPA_supplication / hostapd yang menghasilkan kunci WEP / WPA, dan akhirnya, beberapa perpustakaan untuk menghasilkan ID dalam menciptakan sistem file EXT2 / EXT3 / EXT4.

Jadi ketika peningkatan berbasis Seeder atau Seeder termasuk dalam skrip optimasi Android modern, yang akhirnya terjadi adalah penurunan kinerja perangkat, karena rngd akan terus-menerus membangunkan perangkat dan menyebabkan peningkatan frekuensi CPU, yang tentu saja, berdampak negatif pada konsumsi baterai .

Odex

Firmware stok pada perangkat Android hampir selalu odex. Ini berarti bahwa di samping paket standar untuk aplikasi Android dalam format APK, ditemukan di / system / app / dan / system / priv-app /, memiliki nama file yang sama dengan ekstensi .odex. File odex berisi aplikasi bytecode yang dioptimalkan yang telah melewati mesin virtual validator dan optimizer, kemudian direkam dalam file terpisah menggunakan sesuatu seperti alat dexopt .

Jadi file odex dimaksudkan untuk membongkar mesin virtual dan menawarkan peluncuran aplikasi odex yang dipercepat - pada sisi negatifnya, file ODEX mencegah modifikasi pada firmware, dan membuat masalah dengan pembaruan, jadi untuk alasan ini banyak ROM kustom seperti LineageOS didistribusikan tanpa ODEX .

Membuat file ODEX dilakukan dalam beberapa cara, seperti menggunakan Odexer Tool - masalahnya adalah murni efek plasebo. Ketika sistem Android modern tidak menemukan file odex di direktori / sistem, sistem akan benar-benar membuatnya dan menempatkannya di direktori / system / dalvik-cache /. Ini persis seperti apa yang terjadi ketika, misalnya, Anda mem-flash versi Android baru dan memberikan pesan "Sibuk, Mengoptimalkan Aplikasi" untuk sementara waktu.

Lowmemorykiller tweak

Multitasking di Android berbeda dari sistem operasi seluler lainnya dalam arti bahwa itu didasarkan pada model klasik di mana aplikasi bekerja dengan tenang di latar belakang, dan tidak ada batasan pada jumlah aplikasi latar belakang ( kecuali jika ada yang diatur dalam Opsi Pengembang, tetapi ini adalah umumnya direkomendasikan terhadap) - lebih jauh, fungsi transisi ke eksekusi latar belakang tidak dihentikan, meskipun sistem berhak untuk membunuh aplikasi latar belakang dalam situasi memori rendah ( lihat di mana kita berbicara tentang pembunuh memori rendah dan pembunuh kehabisan memori sebelumnya dalam hal ini panduan) .

Untuk kembali ke mekanisme pembunuhan rendah, Android dapat terus beroperasi dengan jumlah memori terbatas dan kurangnya partisi swap. Pengguna dapat terus meluncurkan aplikasi dan beralih di antara mereka, dan sistem akan secara diam-diam membunuh aplikasi latar belakang yang tidak digunakan untuk mencoba dan membebaskan memori untuk tugas-tugas aktif.

Ini sangat berguna untuk Android di masa-masa awal, meskipun untuk beberapa alasan menjadi populer dalam bentuk aplikasi pembunuh tugas, yang umumnya lebih berbahaya daripada menguntungkan. Aplikasi task-killer entah bangun pada interval yang ditentukan, atau dijalankan oleh pengguna, dan tampaknya membebaskan sejumlah besar RAM, yang dipandang sebagai positif - lebih banyak RAM bebas berarti perangkat yang lebih cepat, kan? Namun, ini tidak persis dengan Android.

Bahkan, memiliki sejumlah besar RAM gratis sebenarnya dapat merusak kinerja perangkat dan daya tahan baterai Anda. Ketika aplikasi disimpan dalam RAM Android, jauh lebih mudah untuk memanggilnya, meluncurkannya, dll. Sistem Android tidak perlu mencurahkan banyak sumber daya untuk beralih ke aplikasi, karena sudah ada dalam memori.

Karena itu, para pembunuh tugas tidak benar-benar sepopuler dulu, meskipun pemula Android masih cenderung mengandalkan mereka untuk beberapa alasan ( kurangnya informasi, sedihnya) . Sayangnya, tren baru telah menggantikan task-killer, tren penyetelan mekanisme pembunuhan rendah . Ini akan menjadi misalnya aplikasi MinFreeManager, dan ide utamanya adalah untuk meningkatkan RAM overhead sebelum sistem mulai membunuh aplikasi latar belakang.

Jadi misalnya, RAM standar beroperasi pada batas - 4, 8, 12, 24, 32, dan 40 Mb, dan ketika ruang penyimpanan gratis 40 MB diisi, salah satu aplikasi dalam cache yang dimuat ke dalam memori tetapi tidak berjalan akan dihentikan.

Jadi pada dasarnya, Android akan selalu memiliki setidaknya 40 MB memori yang tersedia, yang cukup untuk mengakomodasi satu aplikasi lagi sebelum lowmemorykiller memulai proses pembersihannya - yang berarti Android akan selalu melakukan yang terbaik untuk menggunakan jumlah maksimum RAM yang tersedia tanpa mengganggu pengalaman pengguna.

Sayangnya, apa yang disarankan oleh beberapa penggemar homebrew adalah bahwa nilainya dinaikkan menjadi, misalnya, 100 MB sebelum LMK masuk. Sekarang pengguna sebenarnya akan kehilangan RAM (100 - 40 = 60), jadi alih-alih menggunakan ruang ini untuk menyimpan back- aplikasi akhir, sistem akan menjaga jumlah memori ini bebas, dengan sama sekali tidak ada tujuan untuk itu.

Tuning LKM dapat berguna untuk perangkat yang jauh lebih tua dengan RAM 512, tetapi siapa yang memilikinya lagi? 2GB adalah "kisaran anggaran" modern, bahkan perangkat RAM 4GB dipandang sebagai "kelas menengah" hari ini, sehingga tweak LMK benar-benar ketinggalan zaman dan tidak berguna.

I / O tweak

Dalam banyak skrip optimasi untuk Android, Anda akan sering menemukan tweak yang membahas subsistem I / O. Misalnya, mari kita lihat ThunderBolt! Script, yang berisi baris-baris ini:

 gema 0> $ i / antrian / rotasi; echo 1024> $ i / queue / nr_requests; 

Baris pertama akan memberikan instruksi penjadwal I / O dalam berurusan dengan SSD, dan yang kedua meningkatkan ukuran maksimum antrian I / O dari 128 menjadi 1024 - karena variabel $ i berisi jalur ke pohon perangkat blok di / sys, dan skrip berjalan dalam satu lingkaran.

Setelah itu, Anda menemukan baris yang terkait dengan penjadwal CFQ:

 gema 1> $ i / antrian / iosched / back_seek_penalty; gema 1> $ i / antrian / iosched / low_latency; gema 1> $ i / antrian / iosched / slice_idle; 

Ini diikuti oleh lebih banyak baris yang menjadi milik perencana lain, tetapi pada akhirnya, dua perintah pertama tidak ada gunanya karena:

Kernel Linux modern mampu memahami apa jenis media penyimpanan yang bekerja dengannya secara default.

Antrian input-output yang panjang ( seperti 1024) tidak berguna pada perangkat Android modern, pada kenyataannya tidak ada artinya bahkan pada desktop - itu benar-benar hanya direkomendasikan pada server tugas berat . Ponsel Anda bukan server Linux tugas berat.

Untuk perangkat Android, hampir tidak ada aplikasi yang diprioritaskan dalam input-output dan tidak ada driver mekanik, sehingga perencana terbaik adalah antrian noop / FIFO, jadi jenis penjadwal ini " men-tweak" tidak melakukan sesuatu yang khusus atau berarti bagi Subsistem I / O. Faktanya, semua perintah daftar multi-layar lebih baik digantikan oleh siklus sederhana:

 untuk i in / sys / block / mmc *; lakukan echo noop> $ i / queue / scheduler echo 0> $ i / queue / iostats selesai 

Ini akan memungkinkan penjadwal noop untuk semua drive dari akumulasi statistik I / O, yang seharusnya berdampak positif pada kinerja, meskipun sangat kecil dan hampir sepenuhnya dapat diabaikan.

Tweak I / O lain yang tidak berguna yang sering ditemukan dalam skrip kinerja adalah peningkatan nilai baca-depan untuk kartu SD hingga 2MB. Mekanisme baca-depan adalah untuk membaca data awal dari media, sebelum aplikasi meminta akses ke data tersebut. Jadi pada dasarnya, kernel akan mencoba mencari tahu data apa yang akan dibutuhkan di masa depan, dan memasukkannya ke dalam RAM, yang dengan demikian akan mengurangi waktu pengembalian. Ini kedengarannya bagus di atas kertas, tetapi algoritma baca-depan lebih sering salah, yang mengarah pada operasi input-output yang sama sekali tidak perlu, belum lagi konsumsi RAM yang tinggi.

Nilai baca-depan yang tinggi antara 1 - 8 MB direkomendasikan dalam RAID-array, tetapi untuk perangkat Android, yang terbaik adalah meninggalkan nilai default 128 KB.

Sistem Manajemen Memori Virtual berubah

Teknik "optimisasi" umum lainnya adalah menyetel subsistem manajemen memori virtual. Ini biasanya hanya menargetkan dua variabel kernel, vm.dirty_background_ratio dan vm.dirty_ratio, yang untuk menyesuaikan ukuran buffer untuk menyimpan data "kotor". Data kotor biasanya adalah data yang telah ditulis ke disk, tetapi masih ada lebih banyak di memori dan menunggu untuk ditulis ke disk.

Nilai tweak khas di distro Linux dan Androis ke subsistem manajemen VM akan seperti:

 vm.dirty_background_ratio = 10 vm.dirty_ratio = 20 

Jadi yang coba dilakukan adalah ketika buffer data kotor adalah 10% dari total RAM, ia membangkitkan aliran pdflush dan mulai menulis data ke disk - jika operasi perekaman data pada disk akan terlalu intens, buffer akan terus bertambah, dan ketika mencapai 20% dari RAM yang tersedia, sistem akan beralih ke operasi tulis selanjutnya dalam mode sinkron - tanpa pra-buffer. Ini berarti pekerjaan menulis ke aplikasi disk akan diblokir, hingga data ditulis ke disk (AKA 'lag').

Yang harus Anda pahami adalah bahwa meskipun ukuran buffer tidak mencapai 10%, sistem akan secara otomatis menendang pdflush setelah 30 detik. Kombinasi 10/20 cukup masuk akal, misalnya pada perangkat dengan 1GB RAM ini akan sama dengan 100 / 200MB RAM, yang lebih dari cukup dalam hal burst records di mana kecepatan sering di bawah catatan kecepatan dalam sistem NAND memori, atau SD-card, seperti ketika menginstal aplikasi atau menyalin file dari komputer.

Untuk beberapa alasan, penulis naskah mencoba untuk mendorong nilai ini lebih tinggi lagi, ke tingkat yang tidak masuk akal. Sebagai contoh kita dapat menemukan dalam skrip optimasi Xplix tingkat setinggi 50/90.

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

Pada perangkat dengan memori 1 GB, ini menetapkan batasan pada buffer kotor hingga 500/900 MB, yang sama sekali tidak berguna untuk perangkat Android, karena itu hanya akan bekerja di bawah perekaman konstan pada disk - sesuatu yang hanya terjadi pada hard disk yang berat Server Linux.

Petir! Script menggunakan nilai yang lebih masuk akal, tetapi secara keseluruhan, masih cukup tidak berarti:

 jika ["$ mem" -lt 524288]; maka sysctl -w vm.dirty_background_ratio = 15; sysctl -w vm.dirty_ratio = 30; elif ["$ mem" -lt 1049776]; lalu sysctl -w vm.dirty_background_ratio = 10; sysctl -w vm.dirty_ratio = 20; selain itu sysctl -w vm.dirty_background_ratio = 5; sysctl -w vm.dirty_ratio = 10; fi; 

Dua perintah pertama dijalankan pada smartphone dengan RAM 512 MB, yang kedua - dengan 1 GB, dan lainnya - dengan lebih dari 1 GB. Tetapi pada kenyataannya hanya ada satu alasan untuk mengubah pengaturan default - perangkat dengan memori internal yang sangat lambat atau kartu memori. Dalam hal ini masuk akal untuk menyebarkan nilai-nilai variabel, yaitu membuat sesuatu seperti ini:

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

Kemudian, ketika sistem lonjakan menulis operasi, tanpa harus merekam data pada disk, hingga yang terakhir tidak akan beralih ke mode sinkron, yang akan memungkinkan aplikasi mengurangi jeda saat merekam.

Tweak Tidak Berguna tambahan dan Tuning Kinerja

Ada lebih banyak "optimasi" di luar sana yang benar-benar tidak melakukan apa-apa. Sebagian besar dari mereka tidak memiliki efek apa pun, sementara yang lain dapat meningkatkan beberapa aspek kinerja, sementara menurunkan perangkat dengan cara lain ( biasanya itu bermuara pada kinerja vs menguras baterai) .

Berikut adalah beberapa optimasi populer tambahan yang mungkin bermanfaat atau tidak, tergantung pada sistem dan perangkat Android.

  • Akselerasi - Akselerasi kecil untuk meningkatkan kinerja dan undervolting - menghemat sedikit baterai.
  • Optimalisasi Basis Data - Secara teori ini seharusnya memberikan peningkatan kinerja perangkat, tetapi diragukan.
  • Zipalign - Ironisnya, meskipun Android SDK built-in alignment konten fitur dalam file APK di toko Anda dapat menemukan banyak perangkat lunak tidak ditransmisikan melalui zipalign.
  • Nonaktifkan layanan sistem yang tidak perlu, hapus sistem yang tidak digunakan dan aplikasi pihak ketiga yang jarang digunakan. Pada dasarnya, menghapus instalan bloatware.
  • Kernel kustom dengan optimisasi untuk perangkat tertentu (sekali lagi, tidak semua inti sama baiknya).
  • Sudah dijelaskan no / scheduler scheduler.
  • Algoritma saturasi TCP Westwood - Lebih efisien digunakan dalam Android Cubic default untuk jaringan nirkabel, tersedia di kernel khusus.

Pengaturan tidak berguna build.prop

LaraCraft304 dari forum XDA Developers telah melakukan penelitian dan menemukan bahwa pengaturan /system/build.prop yang mengesankan yang direkomendasikan untuk digunakan "ahli" tidak ada di sumber AOSP dan CyanogenMod. Berikut daftarnya:

 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 bertahan.cust.tel.eons ro.max.fling_velocity ro.min.fling_velocity 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_shist_pengguna_mode_mode_mode_pod_supput_script_script_script_support_products.html debug.performance.tun video.accelerate.hw. 

Artikel Menarik