Android Performansını Optimize Etme. Android kodunu yazarken, bizim… | tarafından Sonika Srivastava | Tem, 2022

Android Performansını Optimize Etme.  Android kodunu yazarken, bizim… |  tarafından Sonika Srivastava |  Tem, 2022

Android kodunu yazarken odak noktamız esas olarak UI, olay işleme, arka plan görevi ve arka uç entegrasyonudur. Uygulamanın performansını pek düşünmüyoruz ve genellikle bunu hafife alıyoruz.

Burada, uygulamamızın performansını büyük ölçüde etkileyen bazı önemli hususları inceleyeceğiz ve ayrıca geliştiricilerin performansı iyileştirmek için atabilecekleri adımları anlayacağız.

oluşturma

Normalde, sistem her 16 ms’de bir aktiviteyi yeniden çizmeye çalışacaktır. Bu bizi nasıl etkiler?

  • Telefonun donanımı, ekranın kendini güncelleyebileceği hızı belirler. Çoğu cihaz yaklaşık 60Hz’de yenilenir, yani 1000ms/60Hz~16.66 ms
  • Bu nedenle, sistemin tüm çizim mantığını yürütmek için yaklaşık 16ms’si vardır. 16ms aralığı kaçırılırsa, karelerin düşmesine neden olur. Bu, animasyonlarda düzgünlüğü engeller. Bu tür birden çok örnek, önemsiz ve gecikmeli bir deneyime yol açar.
  • Bu nedenle, süslü animasyonların ve geçişlerin tüm Android cihazlarda çok iyi çalışmayabileceğini aklımızda tutmalıyız.

Android işleme hattı 2 alt sisteme ayrılmıştır: GPU ve CPU.

XML’leri ekrana dönüştürme işlemine denir. rasterleştirme.

  • Özel bir görünüm yapmış olanlar, bir görünüm oluşturma adımlarından haberdar olabilirler (aşağıda gösterildiği gibi)
  • Rasterleştirme çok zaman alan bir işlemdir ve GPU, bu işlemi daha hızlı hale getirmek için oluşturulmuştur. Bu nedenle, bu adımları mümkün olduğunca en aza indirmeye çalışmalıyız.
  • Nesneleri değiştirmeye devam edersek, örneğin arka plan rengini, metnini, boyutunu vb. değiştirmeye devam edersek, yukarıdaki işlem her seferinde yeniden yürütülecektir.
  • UI giderek daha karmaşık hale geldikçe, oluşturma işlemi giderek daha fazla zaman alır.
  • GPU tarafında, en önemli sorun “fazla çizim” yani GPU döngülerini pikselleri çizmek ve renklendirmek için boşa harcamak ve sonunda gizleniyor.
  • Overdraw, ekrandaki bir pikselin tek bir karede kaç kez yeniden çizildiğini açıklamak için kullanılan bir terimdir. Bir grup yığılmış UI kartı başlayın, yalnızca en üstteki kart görünür, ancak tüm kartlar çekilir.
  • Geliştiriciler, UI kodunu yazarken aşağıdakileri akılda tutabilir.

i)Son sahnenin parçası olmayan bir şey çizdiğimiz her seferinde GPU döngülerini boşa harcıyoruz.

ii) Yığılmış veya katmanlı kullanıcı arayüzünden kaçının.

iii) Cihazda overdraw’ı görmek için : Developer mode’a gidin ve “Show GPU Overdraw” seçeneğini açın. Android, overdraw seviyesini göstermek için renk şemasını kullanır. Fazla çekmeyi azaltmak için kırmızı alanları arayın. Gereksiz arka plan renklerini ortadan kaldırın. Ve gizlenecek alanları arayın.

İşlemde CPU’nun rolü:

  • Ekrana bir şey çizebilmek için CPU’nun yüksek seviyeli XML’leri GPU’nun anlayabileceği nesnelere dönüştürmesi gerekir. Bu, bir görüntüleme listesi yardımıyla yapılır.
  • Bir nesneyi yeniden oluşturmamız gerekirse, örneğin bir UI öğesinin konumu değişirse, görünüm geçersiz kılındığından görüntüleme listesini yeniden oluşturmamız ve yeniden yürütmemiz gerekir. Ayrıca, birindeki değişiklik nedeniyle diğer görünümler yeniden konumlandırılırsa görünümünde, her düzenin görüntüleme listesi yeniden oluşturulur ve yeniden yürütülür.
  • Görünümün boyutu değiştiğinde, onMeasure() yöntemi yeniden çağrılır ve tüm görünüm hiyerarşisi yeniden incelenir.
  • Görünüm konumu değiştirilirse, requestLayout() yöntemi tekrar çağrılır.
  • Bu nedenle, görünüm hiyerarşisi çok karmaşıksa, işleme hattının “ölçü” ve “düzen” bölümleri performans sorunlarına neden olabilir.
  • hiyerarşi görüntüleyici tüm düzeni anlamaya ve ezbere dayalı görünümleri ortadan kaldırmaya yardımcı olur ve ayrıca görünüm hiyerarşisini düzleştirmeye yardımcı olabilir.
  • Geliştiriciler olarak, iç içe yerleşimlerin kullanıcı arayüzünün performansını ve yanıt verme hızını etkilediğini aklımızda tutmamız gerekir. örneğin, iç içe doğrusal düzen yerine kısıtlama düzenini ve göreli düzeni kullanın.

Hafıza

Bellek optimizasyonunu anlamak için, temellerini anlamamız gerekir. Çöp toplama.

  • Java ile birlikte gelse de Çöp toplayıcı ve bellek yönetimi geliştiricinin birincil endişesi değildir, bellek sızıntıları nedeniyle hala performans sorunları olabilir.
  • Basitçe söylemek gerekirse çöp toplayıcı 2 adımda çalışır: İşaretle ve Süpür erişilemeyen nesneleri bulun ve onlardan kaynakları geri alın. Ancak hangi nesnelere erişilmediğini, çöp toplayıcının ne zaman çalıştırılacağını anlamak ve parçalanmış bellekten kaçınmak çok zor, bu da onu çok karmaşık hale getiriyor.
  • Android çalışma zamanındaki bellek yığını, ayırma türüne ve sistemin gelecekteki GC olayları için nesneleri en iyi nasıl düzenleyebileceğine bağlı olarak farklı alanlara bölünür. Yeni bir nesne tahsis edilirken bu özellikler dikkate alınır ve en uygun yığın alanı seçilir.
  • Her alanın belirli bir boyutu vardır. Nesneler tahsis edildiğinde, sistem birleştirilmiş boyutların kaydını tutar. Alan büyüdükçe, sistem yer açmak için bir GC yürütür.
  • GC davranışı Android çalışma zamanına bağlıdır. Dalvik’te GC işlemleri, mevcut yürütme sürecini tamamlanana kadar durdurabilir. GC daha fazla zaman alırsa veya GC çok sık çağrılırsa bu, süreci yavaşlatabilir. Örneğin, GC daha uzun sürerse, çekme işleminin 16ms’lik kareyi kaçırmasına neden olabilir ve bu da jank’a neden olur.
  • Yeni ART GC veya nesil GC daha optimize edilmiştir ve mevcut işleme süreciyle paralel olarak çalışır.
  • GC sırasında ne kadar çok zaman harcanırsa, işleme veya bilgi işlem gibi diğer görevler için daha az zaman ayrılır.
  • GC tarafından kullanılmayan ve hala serbest bırakılmayan nesneler bellek sızıntılarına neden olur.

hafıza monitörü uygulamanın zaman içinde belleği nasıl kullandığını gösterebilir.

Bellek sızıntıları nelerdir?

  • Her yığın segmentinin bir bellek sınırı vardır. Limit neredeyse tükendiğinde, bir GC tetiklenir. Çok sık GC olayları performansı engelleyebilir.
  • Bellek sızıntıları çok sık GC’lere yol açar. Sızan nesneler artık ihtiyaç duyulmayan ancak çöp toplayıcı bunlara artık erişilmediğini fark edemeyen nesnelerdir. Böylece yığındaki kullanılabilir alan küçülür ve küçülür. Bu, alan boşaltmak için daha fazla GC’nin daha sık yürütüleceği bir senaryoya yol açar.
  • Bellek sızıntıları yavaş ve sinsidir. Bir bellek sızıntısı olduğunu anlamamız günlerimizi alabilir.

Yığın Görüntüleyici uygulamamız tarafından ne kadar bellek kullanıldığını görmemize yardımcı olabilir. Yığın üzerinde “ne olduğunu” bilebiliriz.

Yaygın bellek sızıntısı senaryoları:

  1. Statik görünüm/bağlam kullanımı : Statik görünümler ve bağlam nesneleri, uygulama öldürülünceye kadar bellekte tutulacak ve bunların kapladığı bellek çöp olarak toplanmayacaktır. Kotlin’de bağlamı statik bir değişken olarak veya eşlik eden bir nesnede kullanmaktan kaçının.
  2. Dinleyicilerin kaydını silmeyi unutmak: Dinleyicilerin kaydını silmezsek, kullanımda olmasa bile işgal edilen bellek çöp toplayıcı tarafından geri alınmayacaktır. Bu sorun, etkinlik yok edildiğinde ve yeni bir tane oluşturulduğunda, örneğin cihaz dönüşünde daha da artar. Her seferinde, asla yayınlanmayan görünüm tarafından yeni bir dinleyici oluşturulur. Böylece hiçbir dinleyici GC tarafından geri alınmaz ve bu bir bellek sızıntısı yarattı.
  3. Statik olmayan iç içe sınıf: Eğer yuvalanmış sınıf statik değilse, örtük olarak dış sınıfa olan referansı tutacaktır ve böylece uygulama canlı olana kadar dış sınıf canlı kalacaktır.
  4. İçeriği üçüncü taraf kitaplığına geçirmes: Üçüncü taraf kitaplıklarını başlatmak için her zaman getApplicationContext() iletin, aksi takdirde etkinlik bağlamı kitaplık tarafından statik bir bağlamda kullanılacak ve uygulama öldürülene kadar etkinlik çöp olarak toplanmayacaktır.
  5. Bit eşlemler: Bitmap’ler uygulama belleğini kolayca tüketebilir. Bu nedenle bitmapleri mümkün olduğunca azaltmalı, yeniden kullanmalı ve geri dönüştürmeliyiz. Bitmap kullanımını optimize etmeye yardımcı olan Glide gibi üçüncü taraf kitaplıkları da kullanabiliriz.

Pil ve ağ

Çok açık olmasa da, kodumuzun bir kısmı daha fazla pil tüketebilir.

  • Ekranı her açtığımızda pil tüketiminde büyük bir artış oluyor; LED’leri açmak, ekranı boyamak, CPU, GPU işlemleri vb. çok fazla güç gerektirir.
  • Uygulama cihazı uyandırdığında çok büyük bir pil tüketimi olur. Ör. Uyanma kilidi, alarm yöneticisi veya iş planlayıcı. Çok az iş yapmak veya hiç iş yapmamak için cihazı uyanık tutmak pil ömrü kaybıdır.
  • Uyandırma kilidinden pilin bitmesini azaltmak için pilin yoğun olduğu işlemleri telefon şarj olurken veya Wifi’ye bağlıyken erteleyin. İş zamanlayıcı API’si, gelecekteki işlemleri planlamak veya gruplamak için doğru seçimdir.
  • Pilin bitmesinin en büyük suçlusu ağdır. Baz istasyonu ile haberleşen ve yüksek hacimlerde veri ileten bir radyo çipi vardır. Mümkünse, hücresel radyonun kullanılmaması için WIFI’a bağlıyken arka plan ağ işlemlerini gerçekleştirin. Ancak, ağ isteklerini toplu işlemek, önbelleğe almak ve ertelemek için kod yazmak gerçekten zor bir iştir. İş Zamanlayıcı API’leri burada da yardımcı olabilir.

Ağ profili oluşturucu bunu görselleştirmek için kullanılabilir:

Uygulamayı geliştirirken bu hususları göz önünde bulundurursak, uygulamamızdaki birçok performans sorununu en baştan önleyebiliriz.

Bir cevap yazın

E-posta hesabınız yayımlanmayacak.