En Yaygın Android Optimizasyon Efsaneleri Çürütüldü

Bu nedenle, birçok hepsi bir arada optimizasyon komut dosyası, bazıları tamamen eski veya uzun vadede zararlı olan aynı yöntemleri kullanıyor. Özetle, 'hepsi bir arada' optimizasyon komut dosyalarının çoğu, bu optimizasyonların nasıl veya neden 'çalıştığına dair net bir fikri olmayan bir araya getirilmiş önerilen ayarlamalardan başka bir şey değildir - daha sonra kullanıcılar komut dosyalarını çalıştırır ve performanslarının aniden daha hızlı olduğunu iddia eder ( aslında, performans artışına neden olan büyük olasılıkla cihazlarını yeniden başlatma işlemiydi. , cihazın RAM'indeki her şey temizlendiğinden) .

Appuals'a özel bu makalede, 'için en yaygın önerilerden bazılarını vurgulayacağız' optimize etme ' Android performansı ve bunların sadece bir efsane mi yoksa cihaz performansı için meşru bir değişiklik mi olduğu.

Takas

Efsane listesinin en üstünde, Android optimizasyonu olarak düşünülmesi açısından oldukça saçma olan Android takası var. Swaps'ın temel amacı, bellekte depolama alanı boşaltacak disk belleği dosyasını oluşturmak ve bağlamaktır. Bu mantıklı geliyor kağıtta , ancak gerçekten bir sunucu , neredeyse hiç etkileşimi olmayan.

Android telefonunuzun değiş tokuşunu düzenli olarak kullandığınızda, önbellekten kayıp olan şeylerden kaynaklanan ciddi gecikmelere neden olur. Örneğin, bir uygulamanın takas işleminde depolanan bir grafiği görüntülemeye çalıştığını ve şimdi başka bir uygulamayla veri değişimi yaparak yer açtıktan sonra diski yeniden yüklemesi gerektiğini düşünün. Gerçekten dağınık.

Bazı optimizasyon meraklıları, takasın herhangi bir sorun yaratmadığını söyleyebilir, ancak bu, performansı artırmak için değiş tokuş değildir - yerleşik Android mekanizmasıdır Düşük bellek öldürücü kullanılmayan şişirilmiş, yüksek öncelikli işlemleri düzenli olarak öldürecektir. LMK, düşük bellek koşullarını işlemek için özel olarak tasarlanmıştır, kswapd süreç ve genellikle kullanıcı alanı işlemlerini öldürür. Bu farklı OOMkiller (yetersiz bellek katili), ama bu tamamen farklı bir konu.

Mesele şu ki, örneğin 1GB RAM'e sahip bir cihaz, bir takasla gerekli performans verilerine asla ulaşamaz ve bu nedenle, Android'de takas kesinlikle gerekli değildir. Uygulanması basitçe gecikmelerle doludur ve bir bozulma performans açısından optimize etmektense.

zRAM - Modası geçmiş ve Artık Verimli Değil

zRAM, cihaz optimizasyonu için kanıtlanmış ve etkili bir yöntemdir. eski cihazlar - Sadece 512 MB RAM ile çalışan KitKat tabanlı cihazları düşünün. Bazı kişilerin optimizasyon komut dosyalarına hala zRAM ayarlamaları eklemesi veya bir tür modern optimizasyon ayarı olarak zRAM'ı önermesi, genellikle en son operasyonel protokolleri takip etmeyen insanlara bir örnektir.

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

ZRAM, daha eski cihazlarda kullanıldığında tek çekirdek zRAM bu tür cihazlarda önerilse bile, büyük miktarlarda gecikmeler ortaya çıkma eğilimindedir. Bu aynı zamanda KSM teknolojisinde de olur ( Çekirdek Aynı Sayfa Birleştirme) Bu, aynı bellek sayfalarını boş alan için bir teklifte birleştirir. Bu aslında Google tarafından tavsiye edilir, ancak eski cihazlarda daha büyük gecikmelere yol açar, çünkü sürekli olarak aktif olan çekirdek tead'ler, yinelenen sayfaları aramak için sürekli olarak bellekten çalışır. Temel olarak, optimizasyon ayarını çalıştırmaya çalışmak, ironik bir şekilde cihazı daha da yavaşlatır.

Ekme Makinesi - Android 3.0'dan Beri Güncel Değil

Android geliştiricileri arasında en çok tartışılan optimizasyon ipuçlarından biri sedir ve birilerinin bizi bu konuda yanlış kanıtlamaya çalışabileceğinden eminiz - ama önce ekme makinesinin tarihini incelemeliyiz.

Android için ekme makinesi uygulaması

Evet, kurulumdan sonra daha iyi Android performansını bildiren çok sayıda rapor var. çok daha eski Android cihazlar . Ancak, her ne sebeple olursa olsun insanlar bunun, bunun aynı zamanda, modern Android cihazlar ki bu kesinlikle saçma. Seeder'ın hala ' modern' Gecikme azaltma aracı yanlış bilgilendirmeye bir örnektir - ancak bu, Seeder’ın geliştiricisinin hatası değildir, çünkü Play Store sayfaları bile Seeder'ın Android 4.0+ sonrasında daha az etkili olduğunu belirtmektedir. Yine de herhangi bir nedenle, Seeder, modern Android sistemleri için optimizasyon tartışmalarında hala ortaya çıkıyor.

Seeder'ın temelde Android 3.0 için yaptığı şey, Android çalışma zamanının entropi elde etmek için / dev / random / dosyasını aktif olarak kullandığı bir hatayı ele almaktır. / Dev / random / buffer kararsız hale gelir ve gerekli miktarda veriyi doldurana kadar sistem engellenir - Android cihazındaki çeşitli sensörler ve düğmeler gibi küçük şeyler düşünün.

Seeder’ın yazarı Linux şeytanı aldı rngd ve Android’in inastroil'i için derlendi, böylece çok daha hızlı ve daha öngörülebilir / dev / urandom yolundan rastgele veriler aldı ve bunları / dev / random / tükenmesine izin vermeden her saniye dev / random / olarak birleştirdi. Bu, entropi eksikliği yaşamayan ve çok daha sorunsuz performans gösteren bir Android sistemi ile sonuçlandı.

Google bu hatayı Android 3.0'dan sonra parçaladı, ancak bazı nedenlerden dolayı, Seeder hala açılıyor 'Önerilen ince ayarlar' Android performans optimizasyonu için listeler. Ayrıca, Seeder uygulamasının sEFix gibi, ister aynısını kullanıyor olsun, Seeder'ın işlevselliğini içeren birkaç analogu vardır. rngd veya alternatif başlamış veya hatta / dev / urandom ve / dev / random arasında bir sembolik bağ. Bu, modern Android sistemleri için kesinlikle anlamsız.

Bunun anlamsız olmasının nedeni, yeni Android sürümlerinin üç ana bileşende / dev / random / kullanmasıdır - libcrypto , SSL bağlantılarının şifrelenmesi, SSH anahtarlarının oluşturulması vb. için WEP / WPA anahtarlarını oluşturan WPA_supplication / hostapd ve son olarak, EXT2 / EXT3 / EXT4 dosya sistemleri oluşturmada kimlik oluşturmak için bir avuç kitaplık.

Öyleyse ne zaman Ekme makinesi veya Seeder tabanlı geliştirmeler, modern Android optimizasyon komut dosyalarına dahil edilmiştir; sonuçta, bozulma cihaz performansında, çünkü rngd cihazı sürekli olarak uyandıracak ve CPU frekansında bir artışa neden olacak, bu da elbette pil tüketimini olumsuz yönde etkiliyor.

Odex

Android cihazlardaki stok üretici yazılımı hemen hemen her zaman Odex. Bu, / system / app / ve / system / priv-app / içinde bulunan APK formatındaki Android uygulamaları için standart paketin yanında .odex uzantısıyla aynı dosya adlarına sahip olduğu anlamına gelir. Odex dosyaları, daha önce doğrulayıcı ve optimize edici sanal makineden geçmiş, ardından aşağıdaki gibi bir şey kullanarak ayrı bir dosyaya kaydedilmiş optimize edilmiş bayt kodu uygulamalarını içerir. Dexopt aracı.

Bu nedenle, odex dosyalarının sanal makineyi boşaltması ve odexed uygulamasının hızlandırılmış bir şekilde başlatılmasını sağlaması amaçlanmıştır - olumsuz tarafı, ODEX dosyaları bellenimde yapılan değişiklikleri önler ve güncellemelerde sorun yaratır, bu nedenle bu nedenle LineageOS gibi birçok özel ROM dağıtılır ODEX olmadan .

ODEX dosyalarının oluşturulması, Odexer Aracı gibi çeşitli şekillerde yapılır - sorun, tamamen bir plasebo etkisidir. Modern Android sistemi odex dosyalarını / system dizininde bulamadığında, sistem onları gerçekten yaratacak ve / system / dalvik-cache / dizinine yerleştirecektir. Örneğin, yeni bir Android sürümünü yanıp söndüğünüzde ve bir süre 'Meşgul, Uygulamaları Optimize Ediyor' mesajını verdiğinizde olan tam olarak budur.

Düşük bellek öldürücü tweaks

Android'de çoklu görev, uygulamaların arka planda sessizce çalıştığı klasik bir modeli temel alması ve arka plan uygulamalarının sayısında herhangi bir kısıtlama olmaması açısından diğer mobil işletim sistemlerinden farklıdır ( Geliştirici Seçenekleri'nde bir tane ayarlanmadıkça, ancak bu genellikle tavsiye edilmez) - ayrıca, sistem düşük bellek durumlarında arka plan uygulamalarını kapatma hakkını saklı tutsa da, arka planda yürütmeye geçiş işlevselliği durdurulmaz ( Bu kılavuzda daha önce düşük bellek öldürücü ve yetersiz bellek katili hakkında nerede konuştuğumuzu görün) .

Geri dönmek için Düşük bellek öldürücü mekanizma, 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, etkin görevler için belleği 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 yararlıydı, ancak bazı nedenlerden dolayı, genellikle yararlı olmaktan çok zararlı olan görev öldürücü uygulamalar biçiminde popüler hale geldi. Görev sonlandırıcı uygulamalar ya belirli aralıklarla uyanır ya da kullanıcı tarafından çalıştırılır ve büyük miktarda RAM boşaltmış gibi görünür, bu olumlu bir durumdur - daha fazla boş RAM, daha hızlı bir cihaz anlamına gelir, değil mi? Ancak bu tam olarak Android için geçerli değildir.

Aslında, büyük miktarda boş RAM'e sahip olmak, cihazınızın performansına ve pil ömrüne aslında zarar verebilir. Uygulamalar Android’in RAM'inde depolandığında, onları çağırmak, başlatmak vb. Çok daha kolaydır. Android sisteminin uygulamaya geçmek için fazla kaynak ayırmasına gerek yoktur, çünkü zaten bellekte bulunmaktadır.

Bu nedenle, görev sonlandırıcılar eskisi kadar popüler değiller, ancak Android acemileri hala bazı nedenlerden dolayı onlara güvenme eğilimindeler ( ne yazık ki bilgi eksikliği) . Ne yazık ki, yeni bir eğilim görev katillerinin yerini aldı. Düşük bellek öldürücü mekanizma ayarları. Bu, örneğin MinFreeManager uygulaması ve ana fikir, sistem arka plan uygulamalarını öldürmeye başlamadan önce RAM ek yükünü artırmaktır.

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

Yani temel olarak, Android her zaman en az 40 MB kullanılabilir belleğe sahip olacaktır, bu da daha önce bir uygulamayı daha barındırmak için yeterlidir. Düşük bellek öldürücü temizleme işlemine başlar - bu, Android'in kullanıcı deneyimine müdahale etmeden maksimum miktarda RAM kullanmak için her zaman elinden gelenin en iyisini yapacağı anlamına gelir.

Ne yazık ki, bazı homebrew meraklılarının önerdiği şey, LMK devreye girmeden önce değerin örneğin 100 MB'a yükseltilmesidir. Şimdi kullanıcı aslında kaybetmek RAM (100 - 40 = 60), bu nedenle bu alanı arka uç uygulamaları depolamak için kullanmak yerine, sistem bu miktarda belleği saklayacaktır. Bedava , kesinlikle hiçbir amacı yok.

LKM ayarı kullanışlı olabilir 512 RAM'e sahip çok daha eski cihazlar için, ancak bunlara artık kim sahip? 2GB modern bir 'bütçe aralığı', 4GB RAM cihazları bile bugünlerde 'orta menzilli' olarak görülüyor, bu nedenle LMK ayarlamaları gerçekten modası geçmiş ve işe yaramaz.

G / Ç ince ayarları

Android için pek çok optimizasyon komut dosyasında genellikle G / Ç alt sistemine hitap eden ince ayarlar bulacaksınız. Örneğin, bir göz atalım. Yıldırım! Bu satırları içeren komut dosyası:

echo 0> $ i / kuyruk / dönüş; echo 1024> $ i / queue / nr_requests;

İlk satır, bir SSD ile ilgili olarak G / Ç zamanlayıcı talimatlarını verir ve ikincisi, sıra G / Ç'nin maksimum boyutunu 128'den 1024'e çıkarır - çünkü $ i değişkeni, içindeki blok aygıtlar ağacına giden bir yol içerir. / sys ve komut dosyası bir döngü içinde çalışır.

Bunu takiben, CFQ zamanlayıcı ile ilgili bir satır bulacaksınız:

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

Bunu, diğer planlayıcı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 girdi-çıktı kuyruğu ( 1024 gibi) modern bir Android cihazda işe yaramaz, aslında masaüstünde bile anlamsız - gerçekten yalnızca ağır hizmet sunucuları . Telefonunuz ağır hizmet tipi bir Linux sunucusu değildir.

Bir Android cihaz için, girdi-çıktıda öncelikli neredeyse hiç uygulama yoktur ve mekanik sürücü yoktur, bu nedenle en iyi planlayıcı noop / FIFO-queue'dur, bu yüzden bu tür bir zamanlayıcı ' çimdik' G / Ç alt sistemi için özel veya anlamlı bir şey yapmıyor. Aslında, tüm bu çok ekranlı liste komutlarının yerini basit bir döngü alması daha iyidir:

i in / sys / block / mmc * için; do echo noop> $ i / queue / scheduler echo 0> $ i / queue / iostats yapıldı

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

Performans betiklerinde sıklıkla bulunan bir başka işe yaramaz G / Ç ayarlaması, 2MB'ye kadar SD kartlar için artırılmış ileri okuma değerleridir. İleriye dönük okuma mekanizması, uygulama bu verilere erişim istemeden önce medyadan verilerin erken okunması içindir. Yani temel olarak, çekirdek gelecekte hangi verilere ihtiyaç duyulacağını anlamaya çalışacak ve bunları RAM'e önceden yükleyerek geri dönüş süresini azaltacaktır. Bu kağıt üzerinde kulağa harika geliyor, ancak önceden okuma algoritması daha sık yanlış yüksek RAM tüketiminden bahsetmeye gerek kalmadan girdi-çıktıda tamamen gereksiz işlemlere yol açar.

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

Sanal Bellek Yönetim sistemi ince ayarları

Diğer bir yaygın 'optimizasyon' tekniği, sanal bellek yönetimi alt sisteminin ayarlanmasıdır. Bu genellikle, 'kirli' verileri depolamak 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 tipik olarak diske yazılan verilerdir, ancak bellekte daha fazlası vardır ve diske yazılmayı beklemektedir.

Hem Linux dağıtımlarında hem de Androis'te VM yönetim alt sistemine tipik ince ayar 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, uyanmasıdır. pdflush akış ve diske veri yazmaya başlar - diske veri kaydetme işlemi olacaksa çok yoğun , arabellek büyümeye devam edecek ve kullanılabilir RAM'in% 20'sine ulaştığında, sistem önceden arabellek olmaksızın eşzamanlı modda sonraki yazma işlemine geçecektir. Bu, disk uygulamasına yazma işinin veriler diske yazılıncaya kadar engellendi (AKA 'gecikme').

Anlamanız gereken, arabellek boyutu olsa bile % 10'a ulaşmıyor , sistem otomatik olarak 30 saniye sonra pdflush'ta başlayacaktır. 10/20 kombinasyonu oldukça makuldür, örneğin 1GB RAM'e sahip bir cihazda bu, hızın genellikle NAND sistemindeki hız kaydının altında olduğu patlama kayıtları açısından fazlasıyla yeterli olan 100 / 200MB RAM'e eşit olacaktır. -bellek veya SD kart, örneğin uygulamaları yüklerken veya bir bilgisayardan dosya kopyalarken.

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

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

1 GB belleğe sahip bir cihazda, bu, kirli arabellek sınırını 500/900 MB olarak belirler; bu, bir Android cihaz için tamamen yararsızdır, çünkü yalnızca altında çalışacaktır. diske sürekli kayıt - yalnızca ağır bir Linux sunucusunda gerçekleşen bir şey.

Yıldırım! Komut dosyası daha makul bir değer kullanır, ancak genel olarak hala oldukça anlamsızdır:

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'e sahip akıllı telefonlarda, ikincisi - 1 GB ile ve diğerleri - 1 GB'den fazla olan akıllı telefonlarda çalıştırılır. Ancak aslında varsayılan ayarları değiştirmenin tek bir nedeni vardır - çok yavaş dahili belleğe veya bellek kartına sahip bir cihaz. Bu durumda değişkenlerin değerlerini yaymak, yani şöyle bir şey yapmak mantıklıdır:

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

Daha sonra, bir dalgalanma sistemi diske veri kaydetmek zorunda kalmadan işlemleri yazdığında, sonuncusuna kadar senkron moda geçmeyecek, bu da uygulamaların kayıt sırasında gecikmeyi azaltmasına izin verecektir.

Ek Gereksiz İnce Ayarlar ve Performans Ayarları

Gerçekten hiçbir şey yapmayan çok daha fazla 'optimizasyon' var. Çoğunun hiçbir etkisi yoktur, diğerleri ise gelişebilir biraz performans açısından, cihazı başka şekillerde düşürürken ( genellikle performansa kıyasla pil tüketimini azaltır) .

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

• Hızlanma - Performansı ve düşük voltajı artırmak için küçük hızlanma - biraz pil tasarrufu sağlar.
• Veritabanı Optimizasyonu - Teoride bu meli cihaz performansında bir gelişme sağlar, ancak bu şüphelidir.
• Zipalign - İronik bir şekilde, yerleşik Android SDK özelliğine rağmen, mağazadaki APK dosyası içindeki içerik hizalamasına rağmen, zipalign aracılığıyla çok sayıda yazılımın iletilmediğini görebilirsiniz.
• Gereksiz sistem hizmetlerini devre dışı bırakın, kullanılmayan sistemi ve nadiren kullanılan üçüncü taraf uygulamalarını kaldırın. Temel olarak, bloatware kaldırılıyor.
• Belirli bir cihaz için optimizasyonlara sahip özel çekirdek (yine, tüm çekirdekler eşit derecede iyi değildir).
• Zaten tanımlanmış G / Ç zamanlayıcı noop.
• Doygunluk algoritması TCP Westwood - Kablosuz ağlar için varsayılan Android Cubic'te daha verimli bir şekilde kullanılır, özel çekirdeklerde mevcuttur.

Yararsız ayarlar build.prop

XDA Developers forumundan LaraCraft304 bir çalışma yürüttü ve AOSP ve CyanogenMod kaynağında 'uzmanlar' kullanımı için önerilen etkileyici sayıda /system/build.prop ayarının bulunmadığını buldu. İşte liste:

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-bayt kodu 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_AD ro.HOMEAP