En Yaygın Android Optimizasyonu Mitleri Debunked

Android performansını arttırmaya ve genel optimizasyon ipuçlarına adanmış birçok öğretim kılavuzu var. Bazıları meşru, bazıları ise yalnızca teoriye ya da Android sistemindeki eski operasyonel yöntemlere dayanıyor ya da sadece saçma sapan. Bu, takas önerilerini, build.prop'a eklenen değerleri ve Linux çekirdeğindeki değişken değişiklikleri içerir.

Dışarıda bile bir sürü “optimizasyon senaryosu” var, hepsi bir arada parlatılabilir. Fermuarlar performansı, batarya ömrünü ve diğer şeyleri önemli ölçüde artırmayı vaat ediyor. Bunlardan bazıları gerçekten işe yarayabilir, ancak çoğunluğu sadece cihazınız üzerinde olumsuz bir etkiye sahip olan, yalnızca bir plasebo etkisi veya daha da kötüsüdür.

Bu, insanların kasıtlı olarak kötü senaryolar yayınladıkları anlamına gelmez - Google Play Store'da sahte ödemeli uygulamalar olduğu kesindir, ancak Android forumlarında yayınlanan optimizasyon komut dosyaları genellikle iyi niyetlidir, geliştiricinin yanlış bilgilendirilmiş olması gerekir. veya sadece çeşitli optimizasyon ayarlarıyla deneme yapmak. Maalesef, özellikle “hepsi bir arada” optimizasyon komut dosyalarında bir tür kartopu efekti oluşma eğilimindedir. Küçük bir avuç tweaks aslında bir şey yapabilir, bir senaryoda başka bir tweaks kesinlikle hiçbir şey yapmaz - ama bu senaryolar neyin işe yarayıp neyin işe yarayıp yaramadığına dair gerçek bir soruşturma olmadan sihirli mermi olarak geçer. .

Bu nedenle, hepsi bir arada optimizasyon komut dosyalarının çoğu, uzun vadede bazıları tamamen eski veya zararlı olan aynı yöntemleri kullanıyor. Özetle, “hepsi bir arada” optimizasyon komut dosyalarının çoğu, bu optimizasyonların “nasıl çalıştığını - kullanıcılar daha sonra komut dosyalarını nasıl yanıp söndüğünü ve performanslarının aniden daha hızlı olduğunu iddia etmeden hiçbir şekilde net bir şekilde bir araya getirilmeden önerilen ayarlardan başka bir şey değildir. ( Aslında, büyük olasılıkla , cihazın RAM'indeki her şey temizlendiğinden, performans artışına neden olan cihazlarının yeniden başlatılması çok basit bir eylemdi ) .

Bu Appuals'ın özel makalesinde, Android performansını “ optimize etmek” için en yaygın önerilerden bazılarını ve basitçe bir efsane mi yoksa cihaz performansı için meşru bir değişiklik mi olduğunu vurgulayacağız.

takas

Efsane listesinin başında Android takası - Android optimizasyonu olarak düşünüldüğünde oldukça saçma. Takas ana amacı, bellekte boş saklama alanı olacak disk belleği dosyasını oluşturmak ve bağlamaktır. Bu kâğıt üzerinde mantıklı geliyor, ancak neredeyse hiçbir etkileşimi olmayan bir sunucu için gerçekten uygulanabilir.

Android telefonunuzun takasını düzenli olarak kullandığınızda, önbellekten geçen nesnelerden kaynaklanan ciddi gecikmelere yol açacaktır. Örneğin, bir uygulamanın takas içerisinde depolanan bir grafiği görüntülemeye çalıştığını, bunun için takas alanını boşalttıktan sonra tekrar takması gereken başka bir uygulama ile yeniden yüklemesi gerektiğini hayal edin. Gerçekten dağınık.

Bazı optimizasyon meraklıları, takasın hiçbir sorun sunmadığını söyleyebilirler, ancak performans artışı sağlayan takas değildir - bu, kullanılmayan şişirilmiş, yüksek öncelikli işlemleri düzenli olarak öldürecek olan yerleşik Android mekanizması lowmemorykiller'dir . LMK, düşük bellek koşullarını yönetmek için özel olarak tasarlanmıştır, kswapd işleminden başlatılır ve genellikle kullanıcı alanı işlemlerini öldürür. Bu, OOMkiller’dan (bellek dışı katil) farklıdır , ancak bu tamamen farklı bir konudur.

Mesele şu ki, örneğin, 1GB RAM'e sahip bir cihaz, bir takasta gerekli performans verilerine asla erişemez ve bu yüzden Android'te takas kesinlikle gerekli değildir. Uygulaması basit bir gecikmeyle doludur ve onu optimize etmek yerine performansın düşmesine neden olur.

zRAM - Eski ve Artık Verimlilik Yok

zRAM, daha iyi cihazlar için cihaz optimizasyonu için kanıtlanmış ve etkili bir yöntemdir - yalnızca yaklaşık 512 MB RAM'de çalışan KitKat tabanlı cihazları düşünün. Bazı insanların hala zRAM tweaks'ını optimizasyon komut dosyalarına dahil etmesi veya bir tür modern optimizasyon tweak'ı olarak zRAM'ı tavsiye etmesi, genellikle en son operasyonel protokolleri takip etmeyen insanlara bir örnektir.

zRAM, MTK yonga setleri ve 512 MB RAM kullanan cihazlar gibi giriş seviyesi bütçe aralığında çok çekirdekli SoC'ler için tasarlanmıştır. Temelde çok ucuz Çin telefonları. Temel olarak zRAM'ın yaptığı şey, çekirdeği şifreleme akışıyla ayırmaktır.

ZRAM, tek çekirdekli eski cihazlarda kullanıldığında, bu cihazlarda zRAM tavsiye edilse bile, büyük miktarlarda gecikme meydana gelir. Bu aynı teklifte aynı bellek sayfalarını boş alan için birleştiren KSM teknolojisi ( Çekirdek Aynı Sayfa Birleşmesi) ile de olur. Bu aslında Google tarafından önerilmektedir, ancak sürekli aktif çekirdek bölümleri sürekli sayfalar aramak için bellekten sürekli olarak çalıştığı için eski cihazlarda daha büyük gecikmelere yol açmaktadır. Temel olarak, optimizasyon ayarını çalıştırmaya çalışmak, cihazı ironik olarak daha da yavaşlatır.

Tohum Ekme Makinesi - Android 3.0'dan beri eski

Android geliştiricileri arasında en çok tartışılan optimizasyon ipuçlarından biri ekicidir ve birinin bu konuda yanlış olduğunu ispatlamaya çalıştığından eminiz - ancak önce ekim makinesinin tarihini incelememiz gerekiyor.

Android için ekme makinesi uygulaması

Evet, çok daha eski Android cihazlara yüklendikten sonra daha iyi Android performansı bildiren çok sayıda rapor var. Bununla birlikte, insanlar ne sebeple olursa olsun, bunun kesinlikle saçma olan modern Android cihazlar için de uygulanabilir bir optimizasyon olduğu anlamına geliyor. Seeder’in hala “ modern” gecikme azaltma aracı olarak muhafaza edilmesi ve sunulması yanlış bir örnek teşkil ediyor - bu, Seeder'in geliştiricisinin hatası olmasa da, Play Store sayfalarında bile Android 4.0 + 'dan sonra daha az etkin olduğunu gösteriyor. Yine de ne sebeple olursa olsun, Seeder hala modern Android sistemler için optimizasyon tartışmalarında ortaya çıkıyor.

Temel olarak Android 3.0 için Seeder'in yaptığı şey, Android çalışma zamanının entropi elde etmek için / dev / random / dosyasını aktif olarak kullanacağı bir hatayı ele almak. / Dev / random / buffer dengesiz hale gelir ve sistem gerekli miktarda veriyi dolduruncaya kadar engellenir - Android cihazdaki çeşitli sensörler ve düğmeler gibi küçük şeyler düşünün.

Seeder'in yazarı Linux-demon rngd'yi aldı ve Android'in saldırganlığı için derlendi, böylece çok daha hızlı ve daha öngörülebilir / dev / urandom yolundan rastgele verileri aldı ve / dev / random'a izin vermeden dev / random / her saniye olarak birleştirdi. tükenmiş olmak. Bu, entropi eksikliği yaşamayan ve daha yumuşak performans gösteren bir Android sisteminde sonuçlandı.

Google, Android 3.0’dan sonra bu hatayı parçaladı, ancak bazı nedenlerden dolayı, Seeder hala Android performans optimizasyonu için “önerilen tweaks” listelerinde karşımıza çıkıyor. Dahası, Tohum Ekme Uygulaması, aynı rngd veya alternatif kablonun kullanılmasını ya da sadece / dev / urandom ve / dev / random arasındaki bir işaret bağlantısını kullanarak, Tohum işlevselliğini içeren sEFix gibi birkaç analoga sahiptir. Bu, modern Android sistemleri için kesinlikle anlamsızdır.

Bunun anlamsız olmasının nedeni, daha yeni Android sürümlerinin / dev / random / üç ana bileşende - libcrypto, SSL bağlantılarını şifrelemek, SSH anahtarları oluşturmak, vb. Kullanmasıdır. WPA / WPA anahtarları üreten WPA_supplication / hostapd EXT2 / EXT3 / EXT4 dosya sistemleri oluştururken kimlik üretme kitaplıkları.

Bu nedenle, Seeder veya Ekme makinesi temelli geliştirmeler modern Android optimizasyon komut dosyalarına dahil edildiğinde, sonuçta ortaya çıkan şey cihaz performansında bir bozulmadır, çünkü rngd cihazı sürekli uyandırır ve elbette pil tüketimini olumsuz yönde etkileyen CPU frekansında bir artışa neden olur .

odex

Android cihazlarda stok firmware hemen hemen her zaman odex. Bu, Android formatındaki Android uygulamaları için APK formatında bulunan / system / app / ve / system / priv-app / içinde bulunan, .odex uzantılı aynı dosya isimlerinde olduğu anlamına gelir. Odex dosyaları, validator ve optimizer sanal makinesinden zaten geçmiş, daha sonra dexopt aracı gibi bir şey kullanarak ayrı bir dosyaya kaydedilmiş optimize edilmiş bytecode uygulamaları içerir.

Bu nedenle, odex dosyalarının sanal makineyi boşaltması ve odexed uygulamasının başlatılmasını hızlandırması amaçlanmıştır - olumsuz, ODEX dosyaları bellenimde değişiklik yapılmasını önler ve güncellemelerle ilgili sorunlar oluşturur, bu nedenle LineageOS gibi birçok özel ROM'lar dağıtılmadan dağıtılır. ODEX .

ODEX dosyalarını oluşturmak, Odexer Tool'u kullanmak gibi bir çok yolla yapılır - sorun, bunun tamamen bir plasebo etkisi olmasıdır. Modern Android sistemi / system dizininde odex dosyalarını bulamadığında, sistem onları gerçekten yaratacak ve / system / dalvik-cache / dizinine yerleştirecektir. Bu, örneğin yeni bir Android versiyonunu flaşladığınızda ve bir süre “Meşgul, Uygulamaları Optimize Etme” mesajını verdiğinde olan tam olarak budur.

Lowmemorykiller tweaks

Android'de çoklu görevlendirme, uygulamaların arka planda sessizce çalıştığı klasik bir modele dayandığı ve arka plan uygulamalarının sayısıyla ilgili herhangi bir kısıtlama olmadığı ( geliştirici Seçeneklerinde ayarlanmadığı sürece), diğer mobil işletim sistemlerinden farklıdır. genel olarak karşı tavsiye edilir) - ayrıca, düşük hafıza durumlarında sistem arka plan uygulamalarını öldürme hakkını saklı tutmasına rağmen, bir arkaplan uygulamasına geçme işlevselliği durdurulmaz ( daha önce bu hafızada bulunan düşük hafızalı katil ve bellek dışı katil hakkında nerede konuştuğumuza bakın). rehber) .

Düşük hafızalı katil mekanizmasına geri dönmek için, Android sınırlı miktarda bellek ve takas bölümü eksikliği ile çalışmaya devam edebilir. Kullanıcı uygulamaları başlatmaya ve aralarında geçiş yapmaya devam edebilir ve sistem aktif görevler için belleği boşaltmayı denemek ve boşaltmak için kullanılmayan arka plan uygulamalarını sessizce öldürür.

Bu, ilk günlerde Android için oldukça faydalıydı, ancak bir nedenden ötürü, genellikle faydalı olmaktan daha zararlı olan görev öldürücü uygulamalar biçiminde popüler hale geldi. Görev katil uygulamaları, belirli aralıklarla uyanır veya kullanıcı tarafından çalıştırılır ve pozitif olarak görülen büyük miktarlarda RAM'i serbest bırakır gibi görünür - daha serbest RAM daha hızlı bir cihaz demektir, değil mi? Ancak bu tam olarak Android için geçerli değil.

Aslında, büyük miktarda boş RAM'in olması cihazınızın performansına ve batarya ömrüne zarar verebilir. Uygulamalar Android RAM'e kaydedildiğinde, onları çağırmak, başlatmak, vb. İşlemleri yapmak çok daha kolaydır. Android sisteminin uygulamaya geçmek için çok fazla kaynak ayırması gerekmez, çünkü bellekte zaten var.

Bu nedenle, görev katilleri bir zamanlar olduğu kadar popüler değil, ancak Android acemiler hala bir sebepten dolayı onlara güvenmeye meyilliydi ( ne yazık ki) . Ne yazık ki, yeni bir eğilim, düşük hafızaya sahip mekanizma ayarlarının trendi olan görev katillerinin yerini aldı. Bu, örneğin MinFreeManager uygulaması olacaktır ve ana fikir, sistem arka plan uygulamalarını öldürmeye başlamadan önce RAM yükünü artırmaktır.

Örneğin, standart RAM 4 - 8, 12, 24, 32 ve 40 Mb sınırlarında ve 40 MB'lık boş depolama alanı dolduğunda, belleğe yüklenen ancak çalışmayan önbelleğe alınmış uygulamalardan biri Sonlandırılacak.

Bu yüzden, temelde Android her zaman en az 40 MB kullanılabilir belleğe sahip olacak, bu da düşük hafızalı katiller temizleme işlemine başlamadan önce bir uygulamaya daha yetecek kadar yeterli olacaktır - bu, Android'in maksimum kullanılabilir RAM miktarını etkilemeden kullanmak için her zaman elinden gelenin en iyisini yapacağını gösterir. kullanıcı deneyimi.

Ne yazık ki, bazı homebrew meraklılarının tavsiye ettiği şey, örneğin LMK başlamadan önce değerin 100 MB'a yükseltilmesidir. Şimdi kullanıcı RAM'i (100 - 40 = 60) kaybedecek, bu nedenle geri saklamak için bu alanı kullanmak uygulamaları sonlandırmak için, sistem bu hatıra miktarını boşta tutacaktır, bunun için hiçbir amaç yoktur.

LKM ayarı , 512 RAM'e sahip çok daha eski cihazlar için faydalı olabilir, ancak artık bunlara sahip olan var mı? 2GB modern “bütçe aralığı”, 4GB RAM cihazları bile bugünlerde “orta sınıf” olarak görüyor, bu nedenle LMK tweaks gerçekten modası geçmiş ve işe yaramaz.

G / Ç tweaks

Android için birçok optimizasyon komut dosyasında, çoğu zaman G / Ç alt sistemine yönelik tweaks bulacaksınız. Örneğin, ThunderBolt'a bir göz atalım ! Bu satırları içeren komut dosyası:

 yankı 0> $ i / sıra / dönme; yankı 1024> $ i / sıra / nr_requests; 

İlk satır, bir SSD ile ilgili olarak G / Ç zamanlayıcı talimatlarını verir ve ikincisi, kuyruk G / Ç'nin maksimum boyutunu 128'den 1024'e yükseltir - çünkü $ i değişkeni, blok aygıtları ağacının yolunu içerir. / sys ve script bir döngüde çalışır.

Bundan sonra, CFQ zamanlayıcı ile ilgili bir satır bulursunuz:

 echo 1> $ i / sıra / iyiye / geri_seek_penalty; yankı 1> $ i / sıra / iyiye / alçak ses; echo 1> $ i / queue / iosched / slice_idle; 

Bunu diğer planlamacılara ait daha fazla satır izler, ancak sonuçta ilk iki komut anlamsızdır, çünkü:

Modern bir Linux çekirdeği varsayılan olarak ne tür bir depolama ortamı ile çalıştığını anlayabilir.

Uzun bir giriş-çıkış sırası ( 1024 gibi) modern bir Android cihazda işe yaramaz, aslında masaüstünde bile anlamsız - gerçekten ağır hizmet sunucularında öneriliyor. Telefonunuz ağır bir Linux sunucusu değildir.

Bir Android cihaz için, giriş-çıkışta öncelikli olarak hiçbir uygulama yoktur ve mekanik bir sürücü yoktur, bu nedenle en iyi planlayıcı noop / FIFO kuyruğudur, bu nedenle bu “zamanlayıcı” bu tip programlayıcı için özel veya anlamlı bir şey yapmaz. G / Ç alt sistemi. Aslında, bu çok ekranlı liste komutlarının tümü basit bir döngü ile değiştirilir:

 i / sys / block / mmc * 'de; yankı yapmak noop> $ i / sıra / zamanlayıcı yankı 0> $ i / sıra / iostats 

Bu, çok küçük ve neredeyse tamamen ihmal edilebilir olmasına rağmen, performans için olumlu bir etkiye sahip olması gereken G / Ç istatistikleri birikiminden tüm sürücüler için noop zamanlayıcısını etkinleştirir.

Performans senaryolarında sıklıkla bulunan bir başka işe yaramaz I / O ayarlaması, 2 MB'a kadar olan SD kartlar için ileri okuma değerleridir. Okumaya devam eden mekanizma, uygulama bu verilere erişmeden önce, ilk verinin medyadan okunması içindir. Bu nedenle, temel olarak, çekirdek gelecekte hangi verilere ihtiyaç duyulacağını bulmaya çalışacak ve RAM'e önceden yükleyecek, böylece geri dönüş süresini azaltacaktır. Bu kâğıt üzerinde kulağa harika geliyor, ancak ileri okuma algoritması daha sık yanlıştır, bu da yüksek RAM tüketiminden bahsetmek yerine, tamamen gereksiz girdi-çıktı işlemlerine yol açar.

RAID dizilerinde 1-8 MB arasında yüksek okuma değerleri önerilir, ancak Android cihazlar için varsayılan değeri 128 KB değerinde bırakmak en iyisidir.

Sanal Bellek Yönetimi sistemi tweaks

Diğer bir yaygın “optimizasyon” tekniği sanal bellek yönetimi alt sistemini ayarlamaktır. Bu genellikle "kirli" verilerin depolanması için arabellek boyutunu ayarlamak için olan yalnızca iki çekirdek değişkenini (vm.dirty_background_ratio ve vm.dirty_ratio) hedefler. Kirli veriler, genellikle diske yazılan verilerdir, ancak daha çok bellekte ve diske yazılmayı bekleyenler vardır.

Hem Linux dağıtımlarında hem de Androis'in VM yönetim alt sistemine olan tipik ince değerleri şöyle olacaktır:

 vm.dirty_background_ratio = 10 vm.dirty_ratio = 20 

Yani, bunun yapmaya çalıştığı şey, kirli veri arabelleği toplam RAM miktarının% 10'u olduğunda, pdflush akışını uyandırır ve diske veri yazmaya başlar - eğer diskteki veri kaydı işlemi çok yoğun olursa, arabellek büyümeye devam edecek ve mevcut RAM'in% 20'sine ulaştığında, sistem önbellek olmadan - senkronize modda sonraki yazma işlemine geçecektir. Bu, diske uygulamaya yazma işinin , veriler diske yazılana kadar engelleneceği anlamına gelir (AKA 'lag').

Anlamanız gereken şey, arabellek boyutu % 10'a ulaşmasa bile, sistemin 30 saniye sonra otomatik olarak pdflush yapmasıdır. 10/20'luk bir kombinasyon oldukça uygundur, örneğin 1 GB RAM'e sahip bir cihazda bu 100/200 MB RAM'e eşit olacaktır; bu, NAND sistemindeki hızın genellikle hız kaydının altında kaldığı seri çekim kayıtları için fazlasıyla yeterlidir. - uygulamaları yüklerken veya bir bilgisayardan dosya kopyalarken, hafıza veya SD kart.

Bazı nedenlerden dolayı, senaryo yazarları bu değeri saçma oranlara daha da yükseltmeye çalışıyor. Örneğin, Xplix optimizasyon komut dosyasında 50/90 kadar yüksek bir oran bulabiliriz.

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

1 GB belleğe sahip bir cihazda, bu, kirli bir arabellek sınırını 500/900 MB olarak ayarlar; bu, Android bir aygıt için tamamen yararsızdır, çünkü yalnızca diskte sürekli kayıt altında çalışır - yalnızca çok ağır bir şey olur Linux sunucusu

Yıldırım! Script daha makul bir değer kullanır, ancak genel olarak, yine de oldukça anlamsız:

 eğer ["$ mem" -lt 524288]; o zaman sysctl -w vm.dirty_background_ratio = 15; sysctl -w vm.dirty_ratio = 30; elif ["$ mem" -lt 1049776]; sonra sysctl -w vm.dirty_background_ratio = 10; sysctl -w vm.dirty_ratio = 20; başka sysctl -w vm.dirty_background_ratio = 5; sysctl -w vm.dirty_ratio = 10; fi; 

İlk iki komut, 512 MB RAM, ikincisi - 1 GB ve diğerleri - 1 GB'tan daha fazla olan akıllı telefonlarda çalıştırılır. Ancak aslında varsayılan ayarları değiştirmek için tek bir neden var - çok yavaş bir dahili hafızaya veya hafıza kartına sahip bir cihaz. Bu durumda, değişkenlerin değerlerini yaymak, yani şöyle bir şeyi yapmak makul olur:

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

Ardından, bir dalgalanma sistemi işlemleri yazdığında, diske veri kaydetmek zorunda kalmadan, en sonuncusu senkronize moda geçmez, bu da uygulamaların kayıt sırasında gecikmeyi azaltmasına izin verir.

Ek Yararsız Tweaks ve Performans Ayarlamaları

Gerçekten hiçbir şey yapmayan çok daha fazla “optimizasyon” var. Birçoğu, hiçbir şekilde bir etkiye sahip değildir; diğerleri ise, performansı başka yönlerden de düşürürken, performansın bir kısmını iyileştirebilir ( genellikle akü boşalmasına karşı performans düşer) .

Android sistemine ve cihaza bağlı olarak, yararlı olabilecek veya olmayabilecek bazı popüler popüler optimizasyonları burada bulabilirsiniz.

  • Hızlanma - Performansı ve düşük gerilimi artırmak için küçük hızlanma - küçük bir batarya tasarrufu sağlar.
  • Veri Tabanı Optimizasyonu - Teoride bu, cihaz performansında bir iyileşme sağlamalı, ancak şüphelidir.
  • Zipalign - İronik bir şekilde, yerleşik Android SDK özelliklerine rağmen mağaza içerisindeki APK dosyası içerisindeki içerik hizalamalarını bulabileceğiniz birçok yazılım zipalign ile iletilmez.
  • Gereksiz sistem servislerini devre dışı bırakın, kullanılmayan sistemi kaldırın ve nadiren kullanılan üçüncü taraf uygulamaları. Temel olarak, bloatware kaldırma.
  • Belirli bir aygıt için optimizasyonlara sahip özel çekirdek (yine tüm çekirdekler eşit derecede iyi değildir).
  • Zaten G / Ç zamanlayıcı noop açıkladı.
  • Doygunluk algoritması TCP Westwood - Özel ağlarda kullanılabilen, kablosuz ağlar için varsayılan Android Cubic'te daha verimli kullanılır.

İşe yaramaz ayarlar build.prop

XDA Developers forumundan LaraCraft304 bir araştırma yaptı ve etkileyici sayıda /system/build.prop ayarının “uzmanlar” için kullanılması önerilen kaynakların AOSP ve CyanogenMod'da bulunmadığını tespit etti. İşte liste:

 ro.ril.disable.power.collapse ro.mot.eri.losalert.delay Instagram Hesabındaki Resim ve Videoları ro.config.hw_fast_dormancy kernel.checkjni dalvik.vm.verify-bytecode debug.performance.tuning video.accelerate.hw ro.media.dec.jpeg.memcap Instagram Hesabındaki Resim ve Videoları ro.config.nocheckin profiler.force_disable_ulog profiler.force_disable_err_rpt 

Ilginç Haberler