Titreşim, algılanabilir işin çalışmasını engelleyen rastgele sistem davranışıdır. Bu sayfada titreşimle ilgili istenmeyen sorunların nasıl tanımlanacağı ve çözüleceği açıklanmaktadır.
Uygulama iş parçacığı zamanlayıcı gecikmesi
Zamanlayıcı gecikmesi, titremenin en belirgin belirtisidir: Çalıştırılması gereken bir işlem çalıştırılabilir hale getirilir ancak önemli bir süre boyunca çalışmaz. Gecikmenin önemi bağlama göre değişir. Örneğin:
- Bir uygulamadaki rastgele bir yardımcı iş parçacığı, muhtemelen sorun olmadan birçok milisaniye gecikebilir.
- Bir uygulamanın kullanıcı arayüzü iş parçacığı 1-2 ms'lik titreşimi tolere edebilir.
- SCHED_FIFO olarak çalışan sürücü kthread'leri, çalıştırılmadan önce 500us boyunca çalıştırılabilirlerse sorunlara neden olabilir.
Çalıştırılabilir zamanlar, systrace'te bir iş parçacığının çalışan bölümünden önce gelen mavi çubukla tanımlanabilir. Çalıştırılabilir bir süre, bir iş parçacığına ilişkin sched_wakeup olayı ile iş parçacığı yürütmesinin başlangıcını işaret eden sched_switch olayı arasındaki sürenin uzunluğuna göre de belirlenebilir.
Çok uzun süren konular
Çok uzun süre çalıştırılabilen uygulama kullanıcı arayüzü iş parçacıkları sorunlara neden olabilir. Uzun çalıştırılabilir süreleri olan alt düzey iş parçacıklarının genellikle farklı nedenleri vardır, ancak UI iş parçacığının çalıştırılabilir süresini sıfıra doğru itmeye çalışmak, alt düzey iş parçacıklarının uzun çalıştırılabilir sürelere sahip olmasına neden olan aynı sorunlardan bazılarının düzeltilmesini gerektirebilir. Gecikmeleri azaltmak için:
- İşlemci kümelerini Termal azaltma bölümünde açıklandığı şekilde kullanın.
- CONFIG_HZ değerini artırın.
- Geçmişte arm ve arm64 platformlarında değer 100 olarak ayarlandı. Ancak bu tarihin bir kazasıdır ve etkileşimli cihazlar için kullanılacak iyi bir değer değildir. CONFIG_HZ=100, bir anlık sürenin 10 ms uzunluğunda olduğu anlamına gelir; bu, CPU'lar arasındaki yük dengelemenin gerçekleşmesinin 20 ms (iki anlık) süreceği anlamına gelir. Bu, yüklü bir sistemdeki jank'a önemli ölçüde katkıda bulunabilir.
- Yeni cihazlar (Nexus 5X, Nexus 6P, Pixel ve Pixel XL) CONFIG_HZ=300 ile birlikte gönderilir. Bu, çalıştırılabilir süreleri önemli ölçüde iyileştirirken göz ardı edilebilir bir güç maliyetine sahip olmalıdır. CONFIG_HZ'yi değiştirdikten sonra güç tüketiminde veya performans sorunlarında önemli artışlar görürseniz, sürücülerinizden biri büyük olasılıkla milisaniye yerine ham anlık sürelere dayalı bir zamanlayıcı kullanıyor ve anlık sürelere dönüştürüyordur. Bu genellikle kolay bir düzeltmedir (Nexus 5X ve 6P'de CONFIG_HZ=300'e dönüştürme sırasında kgsl zamanlayıcı sorunlarını düzelten yamaya bakın).
- Son olarak, Nexus/Pixel üzerinde CONFIG_HZ=1000 ile deneyler yaptık ve RCU yükünün azalması nedeniyle fark edilir bir performans ve güç düşüşü sunduğunu gördük.
Yalnızca bu iki değişiklikle, bir cihazın yük altında UI iş parçacığının çalıştırılabilir süresi açısından çok daha iyi görünmesi gerekir.
Sys.use_fifo_ui'yi kullanma
sys.use_fifo_ui özelliğini 1'e ayarlayarak UI iş parçacığının çalıştırılabilir süresini sıfıra getirmeyi deneyebilirsiniz.
Uyarı : Kapasiteye duyarlı bir RT zamanlayıcınız olmadığı sürece bu seçeneği heterojen CPU yapılandırmalarında kullanmayın. Ve şu anda HİÇBİR GÖNDERİM RT PLANLAYICI KAPASİTEYİ BİLİNÇLİ DEĞİLDİR . EAS için bir tane üzerinde çalışıyoruz, ancak henüz mevcut değil. Varsayılan RT zamanlayıcı tamamen RT önceliklerine ve bir CPU'nun zaten eşit veya daha yüksek önceliğe sahip bir RT iş parçacığına sahip olup olmadığına dayanır.
Sonuç olarak, daha yüksek öncelikli bir FIFO k iş parçacığının aynı büyük çekirdekte uyanması durumunda, varsayılan RT zamanlayıcı, nispeten uzun süren UI iş parçacığınızı yüksek frekanslı büyük bir çekirdekten minimum frekanstaki küçük bir çekirdeğe mutlu bir şekilde taşıyacaktır. Bu, önemli performans gerilemelerine neden olacaktır . Bu seçenek henüz teslim edilen bir Android cihazında kullanılmadığından, kullanmak istiyorsanız doğrulamanıza yardımcı olması için Android performans ekibiyle iletişime geçin.
sys.use_fifo_ui etkinleştirildiğinde ActivityManager, en iyi uygulamanın UI iş parçacığını ve RenderThread'i (kullanıcı arayüzü açısından en kritik iki iş parçacığı) izler ve bu iş parçacıklarını SCHED_OTHER yerine SCHED_FIFO yapar. Bu, kullanıcı arayüzü ve RenderThreads'teki titreşimi etkili bir şekilde ortadan kaldırır; Bu seçenek etkinken topladığımız izler, çalıştırılabilir süreleri milisaniye yerine mikrosaniye düzeyinde gösterir.
Ancak RT yük dengeleyici kapasiteye duyarlı olmadığından, uygulamanın başlatılmasından sorumlu kullanıcı arayüzü iş parçacığının 2,1 GHz altın Kryo çekirdeğinden 1,5 GHz gümüş Kryo çekirdeğine taşınması nedeniyle uygulama başlatma performansında %30'luk bir azalma oldu. . Kapasiteye duyarlı bir RT yük dengeleyiciyle, toplu işlemlerde eşdeğer performans ve birçok kullanıcı arayüzü karşılaştırmamızda 95. ve 99. yüzdelik kare sürelerinde %10-15 azalma görüyoruz.
Trafiği kesintiye uğratın
ARM platformları kesintileri yalnızca varsayılan olarak CPU 0'a ilettiğinden, bir IRQ dengeleyicinin (Qualcomm platformlarında irqbalance veya msm_irqbalance) kullanılmasını öneririz.
Pixel geliştirme sırasında, doğrudan CPU 0'ın kesintilerle aşırı yüklenmesine atfedilebilecek sarsıntılar gördük. Örneğin, mdss_fb0 iş parçacığı CPU 0'da programlandıysa, taramadan hemen önce ekran tarafından tetiklenen bir kesinti nedeniyle aniden patlama olasılığı çok daha yüksekti. mdss_fb0 son teslim tarihi çok kısıtlı olan kendi işinin ortasında olacak ve ardından MDSS kesme işleyicisine biraz zaman kaybedecektir. Başlangıçta, mdss_fb0 iş parçacığının CPU benzeşimini, kesinti ile çekişmeyi önlemek için CPU 1-3'e ayarlayarak bunu düzeltmeye çalıştık, ancak daha sonra msm_irqbalance'ı henüz etkinleştirmediğimizi fark ettik. Msm_irqbalance etkinleştirildiğinde, diğer kesintilerden kaynaklanan çekişmenin azalması nedeniyle hem mdss_fb0 hem de MDSS kesintisi aynı CPU'da olsa bile jank gözle görülür şekilde iyileştirildi.
Bu, irq bölümünün yanı sıra schedule bölümüne de bakılarak systrace'de tanımlanabilir. Zamanlama bölümü nelerin planlandığını gösterir, ancak irq bölümündeki çakışan bir bölge, normal olarak zamanlanan süreç yerine o zaman sırasında bir kesintinin çalıştığı anlamına gelir. Bir kesinti sırasında önemli miktarda zaman harcandığını görürseniz seçenekleriniz şunları içerir:
- Kesme işleyicisini daha hızlı hale getirin.
- İlk etapta kesintinin gerçekleşmesini önleyin.
- Kesintinin frekansını, müdahale edebileceği diğer düzenli çalışmalarla (düzenli bir kesinti ise) faz dışı olacak şekilde değiştirin.
- Kesintinin CPU benzeşimini doğrudan ayarlayın ve dengelenmesini önleyin.
- Kesintiyi önlemek için kesintinin müdahale ettiği iş parçacığının CPU benzeşimini ayarlayın.
- Kesintiyi daha az yüklü bir CPU'ya taşımak için kesme dengeleyicisine güvenin.
CPU benzeşiminin ayarlanması genellikle önerilmez ancak belirli durumlarda yararlı olabilir. Genel olarak, en yaygın kesintiler için sistemin durumunu tahmin etmek çok zordur, ancak sistemin normalden daha kısıtlı olduğu (VR gibi) belirli kesintileri tetikleyen çok özel bir koşullar kümesine sahipseniz, açık CPU benzeşimi, iyi bir çözüm olsun.
Uzun yazılımlar
Bir softirq çalışırken, önlemeyi devre dışı bırakır. softirq'ler ayrıca çekirdeğin birçok yerinde tetiklenebilir ve bir kullanıcı işleminin içinde çalıştırılabilir. Yeterli softirq etkinliği varsa, kullanıcı işlemleri softirq'leri çalıştırmayı durdurur ve ksoftirqd, softirq'leri çalıştırmak ve yük dengelemek için uyanır. Genellikle bu iyidir. Ancak çok uzun tek bir yazılım sisteme zarar verebilir.
softirq'ler bir izlemenin irq bölümünde görülebilir, dolayısıyla izleme sırasında sorun yeniden oluşturulabiliyorsa fark edilmeleri kolaydır. Bir softirq bir kullanıcı işlemi içinde çalışabildiğinden, kötü bir softirq, açık bir neden olmaksızın bir kullanıcı işlemi içinde fazladan çalışma zamanı olarak da ortaya çıkabilir. Bunu görürseniz, softirq'lerin suçlu olup olmadığını görmek için irq bölümünü kontrol edin.
Ön ödemeyi veya IRQ'ları çok uzun süre devre dışı bırakan sürücüler
Ön alımın veya kesintilerin çok uzun süre (onlarca milisaniye) devre dışı bırakılması, beklenmedik bir olayla sonuçlanır. Tipik olarak, jank, çalıştırılabilir iş parçacığı diğer iş parçacığından önemli ölçüde daha yüksek önceliğe (veya SCHED_FIFO) sahip olsa bile, bir iş parçacığının çalıştırılabilir hale gelmesi ancak belirli bir CPU üzerinde çalışmaması olarak kendini gösterir.
Bazı yönergeler:
- Çalıştırılabilir iş parçacığı SCHED_FIFO ise ve çalışan iş parçacığı SCHED_OTHER ise, çalışan iş parçacığında önleme veya kesmeler devre dışıdır.
- Çalıştırılabilir iş parçacığı, çalışan iş parçacığından (120) önemli ölçüde daha yüksek önceliğe (100) sahipse, çalıştırılabilir iş parçacığı iki dakika içinde çalışmazsa, çalışan iş parçacığının büyük olasılıkla önleme veya kesintileri devre dışı bırakılır.
- Çalıştırılabilir iş parçacığı ve çalışan iş parçacığı aynı önceliğe sahipse, çalıştırılabilir iş parçacığı 20 ms içinde çalışmazsa, çalışan iş parçacığının büyük olasılıkla önleme veya kesintileri devre dışı bırakılır.
Bir kesme işleyicisini çalıştırmanın diğer kesmelere hizmet vermenizi engellediğini ve bunun da önlemeyi devre dışı bıraktığını unutmayın.
Sorunlu bölgeleri belirlemek için başka bir seçenek de preemptirqsoff izleyicisidir (bkz. Dinamik ftrace kullanma ). Bu izleyici, kesintisiz bir bölgenin (işlev adları gibi) temel nedeni hakkında çok daha iyi bir fikir verebilir, ancak bunu etkinleştirmek için daha fazla invaziv çalışma gerektirir. Performansa daha fazla etkisi olsa da kesinlikle denemeye değer.
Çalışma kuyruklarının yanlış kullanımı
Kesme işleyicilerinin çoğu zaman kesme bağlamının dışında çalışabilecek işler yapması gerekir, bu da işin çekirdekteki farklı iş parçacıklarına dağıtılmasını sağlar. Bir sürücü geliştiricisi, çekirdeğin, çalışma kuyrukları adı verilen, sistem çapında çok kullanışlı bir eşzamansız görev işlevine sahip olduğunu fark edebilir ve bunu kesintiyle ilgili işler için kullanabilir.
Ancak çalışma kuyrukları bu sorun için neredeyse her zaman yanlış cevaptır çünkü bunlar her zaman SCHED_OTHER'dir. Birçok donanım kesintisi performansın kritik yolundadır ve hemen çalıştırılması gerekir. Çalışma kuyruklarının ne zaman çalıştırılacağına dair hiçbir garantisi yoktur. Performansın kritik yolundaki bir çalışma kuyruğunu her gördüğümüzde, cihazdan bağımsız olarak ara sıra bir jank kaynağı oluyor. Amiral gemisi işlemciye sahip Pixel'de, zamanlayıcı davranışına ve sistemde çalışan diğer şeylere bağlı olarak cihazın yük altında olması durumunda tek bir çalışma kuyruğunun 7 ms'ye kadar gecikebileceğini gördük.
Ayrı bir iş parçacığı içinde kesmeye benzer işleri yapması gereken sürücüler, bir çalışma kuyruğu yerine kendi SCHED_FIFO k iş parçacığını oluşturmalıdır. Bunu kthread_work işlevleriyle yapma konusunda yardım için bu yamaya bakın.
Çerçeve kilidi çekişmesi
Çerçeve kilidi çekişmesi, istenmeyen olayların veya diğer performans sorunlarının kaynağı olabilir. Genellikle ActivityManagerService kilidinden kaynaklanır ancak diğer kilitlerde de görülebilir. Örneğin, PowerManagerService kilidi ekranın performansını etkileyebilir. Cihazınızda bunu görüyorsanız iyi bir düzeltme olamaz çünkü bu durum yalnızca çerçevedeki mimari iyileştirmelerle geliştirilebilir. Ancak, system_server'ın içinde çalışan kodu değiştiriyorsanız, kilitleri, özellikle de ActivityManagerService kilidini uzun süre tutmaktan kaçınmak çok önemlidir.
Cilt kilidi çekişmesi
Tarihsel olarak ciltleyicinin tek bir genel kilidi vardı. Bir ciltleme işlemini çalıştıran iş parçacığı kilidi tutarken önceden boşaltılmışsa, orijinal iş parçacığı kilidi serbest bırakana kadar başka hiçbir iş parçacığı bir ciltleme işlemi gerçekleştiremez. Bu kötü; ciltleyici çekişmesi, UI güncellemelerinin ekrana gönderilmesi de dahil olmak üzere sistemdeki her şeyi engelleyebilir (UI iş parçacıkları, ciltleyici aracılığıyla SurfaceFlinger ile iletişim kurar).
Android 6.0, ciltleyici kilidini tutarken önlemeyi devre dışı bırakarak bu davranışı iyileştirmek için çeşitli yamalar içeriyordu. Bu sadece güvenliydi çünkü ciltleyici kilidinin birkaç mikrosaniyelik gerçek çalışma süresi boyunca tutulması gerekiyordu. Bu, tartışmasız durumlarda performansı önemli ölçüde artırdı ve ciltleyici kilidi tutulurken çoğu zamanlayıcı anahtarını önleyerek çekişmeyi önledi. Bununla birlikte, ciltleyici kilidinin tutulduğu tüm çalışma süresi boyunca önleme devre dışı bırakılamaz; bu, orijinal durumla aynı önleme neden olabilecek, uyuyabilen işlevler (copy_from_user gibi) için önlemenin etkinleştirildiği anlamına gelir. Yamaları yukarıya gönderdiğimizde, bunun tarihteki en kötü fikir olduğunu hemen söylediler. (Onlarla aynı fikirdeydik, ancak aynı zamanda yamaların yanmayı önleme konusundaki etkinliği konusunda da tartışamadık.)
Bir süreçte fd çekişmesi
Bu nadir. Jankınız muhtemelen bundan kaynaklanmıyor.
Bununla birlikte, aynı fd'yi yazan bir işlem içinde birden fazla iş parçacığınız varsa, bu fd üzerinde çekişme görmek mümkündür, ancak bunu Pixel getirme sırasında gördüğümüz tek zaman, düşük öncelikli iş parçacıklarının tüm CPU'yu işgal etmeye çalıştığı bir test sırasındaydı. Aynı işlem içinde tek bir yüksek öncelikli iş parçacığının çalıştığı süre. Tüm iş parçacıkları fd izleme işaretçisine yazıyordu ve düşük öncelikli bir iş parçacığı fd kilidini tutuyorsa ve daha sonra engellenirse, yüksek öncelikli iş parçacığı fd izleme işaretçisinde bloke edilebilir. Düşük öncelikli iş parçacıklarından izleme devre dışı bırakıldığında performans sorunu yaşanmadı.
Bunu başka bir durumda yeniden oluşturamadık, ancak izleme sırasında performans sorunlarının olası bir nedeni olarak bunu belirtmekte fayda var.
Gereksiz CPU boşta geçişleri
IPC ile, özellikle de çok işlemli işlem hatlarıyla uğraşırken, aşağıdaki çalışma zamanı davranışında farklılıklar görmek yaygındır:
- Konu A CPU 1'de çalışır.
- A iş parçacığı B iş parçacığını uyandırır.
- B iş parçacığı CPU 2'de çalışmaya başlar.
- A iş parçacığı hemen uyku moduna geçer ve B iş parçacığı mevcut işini bitirdiğinde B iş parçacığı tarafından uyandırılır.
Genel bir ek yük kaynağı 2. ve 3. adımlar arasındadır. CPU 2 boştaysa, B iş parçacığının çalışabilmesi için önce aktif duruma geri getirilmesi gerekir. SOC'ye ve rölanti derinliğine bağlı olarak, B iş parçacığının çalışmaya başlaması onlarca mikrosaniye sürebilir. IPC'nin her iki tarafının gerçek çalışma süresi ek yüke yeterince yakınsa, bu hattın genel performansı CPU boşta geçişleri nedeniyle önemli ölçüde azaltılabilir. Android'in bunu başarabileceği en yaygın yer ciltleme işlemleridir ve ciltleyiciyi kullanan birçok hizmet, yukarıda açıklanan duruma benzemeye başlar.
İlk olarak, çekirdek sürücülerinizdeki wake_up_interruptible_sync() işlevini kullanın ve bunu herhangi bir özel zamanlayıcıdan destekleyin. Bunu bir ipucu olarak değil, bir gereklilik olarak kabul edin. Binder bugün bunu kullanıyor ve gereksiz CPU boşta geçişlerini önleyerek eşzamanlı ciltleme işlemlerine çok yardımcı oluyor.
İkinci olarak, işlemci geçiş sürelerinizin gerçekçi olduğundan ve işlemci yöneticisinin bunları doğru şekilde hesaba kattığından emin olun. SOC'niz en derin boşta kalma durumunuza girip çıkıyorsa, en derin boşta kalma durumuna geçerek güç tasarrufu sağlayamazsınız.
Kerestecilik
Günlüğe kaydetme, CPU döngüleri veya bellek için ücretsiz değildir, bu nedenle günlük arabelleğine spam göndermeyin. Maliyet döngülerinin uygulamanızda (doğrudan) ve günlük arka plan programında günlüğe kaydedilmesi. Cihazınızı göndermeden önce tüm hata ayıklama günlüklerini kaldırın.
G/Ç sorunları
G/Ç işlemleri yaygın titreşim kaynaklarıdır. Bir iş parçacığı bellek eşlemeli bir dosyaya erişirse ve sayfa sayfa önbelleğinde değilse hata verir ve sayfayı diskten okur. Bu, iş parçacığını engeller (genellikle 10+ ms boyunca) ve kullanıcı arayüzü oluşturmanın kritik yolunda meydana gelirse, jank ile sonuçlanabilir. G/Ç işlemlerinin burada tartışılacak çok fazla nedeni vardır, ancak G/Ç davranışını iyileştirmeye çalışırken aşağıdaki konumları kontrol edin:
- Pinner Hizmeti . Android 7.0'a eklenen PinnerService, çerçevenin sayfa önbelleğindeki bazı dosyaları kilitlemesini sağlar. Bu, belleği başka bir işlem tarafından kullanılmak üzere kaldırır, ancak önceden düzenli olarak kullanıldığı bilinen bazı dosyalar varsa, bu dosyaların kilitlenmesi etkili olabilir.
Android 7.0 çalıştıran Pixel ve Nexus 6P cihazlarda dört dosyayı kilitledik:- /system/framework/arm64/boot-framework.oat
- /system/framework/oat/arm64/services.odex
- /system/framework/arm64/boot.oat
- /system/framework/arm64/boot-core-libart.oat
- Şifreleme G/Ç sorunlarının başka bir olası nedeni. Satır içi şifrelemenin, CPU tabanlı şifrelemeyle veya DMA aracılığıyla erişilebilen bir donanım bloğuyla karşılaştırıldığında en iyi performansı sunduğunu görüyoruz. En önemlisi, satır içi şifreleme, özellikle CPU tabanlı şifrelemeyle karşılaştırıldığında, G/Ç ile ilişkili titreşimi azaltır. Sayfa önbelleğine getirme işlemleri genellikle kullanıcı arayüzü oluşturmanın kritik yolunda olduğundan, CPU tabanlı şifreleme, kritik yola ek CPU yükü getirir ve bu da yalnızca G/Ç getirme işleminden daha fazla titreşime neden olur.
DMA tabanlı donanım şifreleme motorları da benzer bir soruna sahiptir, çünkü çekirdek, çalıştırılacak başka kritik işler olsa bile bu işi yönetmek için döngüler harcamak zorundadır. Satır içi şifreleme desteğini içerecek şekilde yeni donanım oluşturan tüm SOC satıcılarına şiddetle tavsiye ederiz.
Agresif küçük görev paketleme
Bazı zamanlayıcılar, daha fazla CPU'yu daha uzun süre boşta tutarak güç tüketimini azaltmaya çalışmak için küçük görevleri tek CPU çekirdeğine paketleme desteği sunar. Bu, verim ve güç tüketimi açısından iyi çalışsa da gecikme açısından felaket olabilir. Kullanıcı arayüzü oluşturmanın kritik yolunda küçük sayılabilecek birkaç kısa süreli iş parçacığı vardır; eğer bu iş parçacıkları yavaş yavaş diğer CPU'lara aktarılırken gecikirse, bu durum jank'a neden olur . Küçük görev paketlemeyi çok ihtiyatlı bir şekilde kullanmanızı öneririz.
Sayfa önbelleğinin bozulması
Yeterli boş hafızası olmayan bir cihaz, yeni bir uygulamayı açmak gibi uzun süren bir işlemi gerçekleştirirken aniden aşırı derecede yavaşlayabilir. Uygulamanın bir izi, G/Ç'de çoğunlukla engellenmese bile, belirli bir çalıştırma sırasında G/Ç'de sürekli olarak engellendiğini ortaya çıkarabilir. Bu genellikle, özellikle daha az belleğe sahip cihazlarda sayfa önbelleğinin bozulduğunun bir işaretidir.
Bunu tanımlamanın bir yolu, pagecache etiketini kullanarak bir systrace almak ve bu izlemeyi system/extras/pagecache/pagecache.py adresindeki komut dosyasına beslemektir. pagecache.py, dosyaları sayfa önbelleğine eşlemeye yönelik bireysel istekleri, dosya başına toplu istatistiklere dönüştürür. Bir dosyanın diskteki toplam boyutundan daha fazla baytın okunduğunu fark ederseniz, kesinlikle sayfa önbellek atma işlemine başlıyorsunuz demektir.
Bunun anlamı, iş yükünüzün gerektirdiği çalışma kümesinin (genellikle tek bir uygulama artı sistem_sunucusu), cihazınızdaki sayfa önbelleğinde bulunan bellek miktarından daha fazla olmasıdır. Sonuç olarak, iş yükünün bir kısmı ihtiyaç duyduğu verileri sayfa önbelleğinde alırken, yakın gelecekte kullanılacak diğer bir kısım tahliye edilecek ve tekrar getirilmesi gerekeceği için, yüklenene kadar sorunun tekrar oluşmasına neden olacaktır. tamamlandı. Cihazda yeterli bellek bulunmadığında performans sorunlarının temel nedeni budur.
Sayfa önbelleğinin bozulmasını düzeltmenin kusursuz bir yolu yoktur, ancak belirli bir cihazda bunu iyileştirmeye çalışmanın birkaç yolu vardır.
- Kalıcı işlemlerde daha az bellek kullanın. Kalıcı işlemler tarafından ne kadar az bellek kullanılırsa, uygulamalar ve sayfa önbelleği için o kadar fazla bellek kullanılabilir.
- İşletim sistemindeki belleği gereksiz yere çıkarmadığınızdan emin olmak için cihazınız için sahip olduğunuz düzenlemeleri denetleyin. Hata ayıklama için kullanılan kesmelerin, çekirdek yapılandırmalarının nakliyesinde yanlışlıkla bırakılarak onlarca megabayt bellek tükettiği durumları gördük. Bu, özellikle daha az belleğe sahip cihazlarda sayfa önbelleğinin atılması ile atılmaması arasındaki farkı yaratabilir.
- System_server'da kritik dosyalarda sayfa önbelleğinin bozulduğunu görüyorsanız, bu dosyaları sabitlemeyi düşünün. Bu, başka yerlerdeki hafıza baskısını artıracaktır, ancak davranışı, çarpmayı önleyecek kadar değiştirebilir.
- Daha fazla hafızayı boş tutmak için lowmemorykiller'ı yeniden ayarlayın. lowmemorykiller'ın eşikleri hem mutlak boş belleğe hem de sayfa önbelleğine dayalıdır; bu nedenle, belirli bir oom_adj düzeyindeki işlemlerin sonlandırıldığı eşiğin artırılması, arka planda uygulama ölümünün artması pahasına daha iyi davranışla sonuçlanabilir.
- ZRAM'ı kullanmayı deneyin. Nadiren kullanılan kirli sayfalara yardımcı olabileceği için Pixel'in 4GB'ı olmasına rağmen Pixel'de ZRAM kullanıyoruz.