Uygulama başlatma, uygulamanızın kullanıcılar üzerindeki ilk izlenimini temsil eder. Kullanıcılar beklemekten hoşlanmaz, bu yüzden uygulamanızın hızlı başladığından emin olmanız gerekir. Gerçek hayattaki bir uygulama geliştirme ekibinin, uygulama başlatmayla ilgili sorunları nasıl bulup teşhis ettiğini size göstermek için aşağıda Gmail Wear OS ekibinin yaptıklarını paylaşıyoruz.
Gmail Wear OS ekibi, ekibinin uygulama performansı ölçütlerini karşılamak için özellikle uygulama başlatma ve çalışma zamanı oluşturma performansına odaklanarak bir optimizasyon çalışması gerçekleştirdi. Ancak hedeflemek için belirli eşikleriniz olmasa bile biraz zaman ayırarak uygulama başlatmayı neredeyse her zaman iyileştirebilirsiniz.
Bir iz yakalayın ve uygulama başlangıcına bakın
Analize başlamak için Perfetto veya Android Studio'da daha yakın inceleme için uygulama başlatmayı içeren bir iz yakalayın. Bu örnek olay incelemesinde, uygulamanızın ötesinde cihaz sisteminde neler olduğuyla ilgili bilgi verdiği için Perfetto kullanılmaktadır. İzi Perfetto'ya yüklediğinizde şu şekilde görünür:
Odak noktası uygulama başlatmayı iyileştirmek olduğundan, Android Uygulama Başlatmaları özel metriğinin bulunduğu satırı bulun. Fareyle satırın üzerine geldiğinizde görünen raptiye simgesini 
tıklayarak bu özel metriği görünümünüzün üst kısmına sabitlemeniz faydalı olacaktır. Android Uygulama Başlatmaları satırında gördüğünüz çubuk veya dilim, uygulama girişiminin kapladığı, ilk uygulama çerçevesi ekrana çizilene kadar geçen zaman aralığını gösterir. Bu nedenle, sorun veya performans sorunlarını burada kontrol etmeniz gerekir.
reportFullyDrawn() kullanıyor olsanız bile, Android Uygulama Başlatmaları metriğinin ilk gösterime kadar geçen süreyi temsil ettiğini unutmayın. Tam gösterime kadar geçen süreyi öğrenmek için Perfetto arama kutusuna reportFullyDrawn() ifadesini girin.
Ana ileti dizisini kontrol etme
İlk olarak, ana iş parçacığında neler olup bittiğini inceleyin. Ana iş parçacığı çok önemlidir, çünkü genellikle kullanıcı arayüzü oluşturma işleminin tamamı burada gerçekleşir. Engellendiğinde çizim yapılamaz ve uygulamanız donmuş görünür. Bu nedenle, ana iş parçacığında uzun süre çalışan herhangi bir işlem olmadığından emin olmak istersiniz.
Ana iş parçacığını bulmak için uygulamanızın paket adını içeren satırı bulup genişletin. Paketle aynı ada sahip iki satır (genellikle bölümdeki ilk iki satır) ana iş parçacığını temsil eder. İki ana iş parçacığı satırından ilki CPU durumunu, ikinci satır ise iz noktalarını temsil eder. Android App Startups metriğinin altındaki iki ana iş parçacığı satırını sabitleyin.
Çalıştırılabilir durumda ve CPU anlaşmazlığında harcanan süre
Uygulama başlatılırken CPU etkinliğinin toplu bir görünümünü almak için imlecinizi ana iş parçacığının üzerine sürükleyerek uygulama başlatma zaman aralığını yakalayın. Görüntülenen İleti Dizisi Durumları paneli, seçtiğiniz zaman aralığı içinde her bir CPU durumunda harcanan toplam süreyi gösterir.
Runnable eyaletinde harcanan zamana bakın. Bir iş parçacığı Runnable durumundayken iş parçacığı çalışmak için uygundur ancak herhangi bir çalışma planlanmaz. Bu durum, cihazın çok fazla yük altında olduğunu ve yüksek öncelikli görevleri planlayamadığını gösterebilir. En üstte, kullanıcı tarafından görülebilen uygulama, programlamada en yüksek önceliğe sahiptir. Bu yüzden boşta olan bir ana iş parçacığı genellikle uygulamanızdaki animasyon oluşturma gibi yoğun işlemlerin CPU süresi için ana iş parçacığıyla rekabet ettiğini gösterir.
Runnable ile Running arası durumlarda göreli süreyi değerlendirin.Running durumunda Runnable durumunda zamanın zamana oranı ne kadar yüksek olursa CPU anlaşmazlığının gerçekleşme olasılığı da o kadar yüksek olur. Performans sorunlarını bu şekilde incelerken ilk olarak en uzun süren kareye odaklanın ve daha küçük karelere doğru çalışın.
Runnable durumunda harcanan süreyi analiz ederken cihaz donanımını dikkate alın.
Gösterilen uygulama iki CPU'lu giyilebilir bir cihazda çalıştığından, Runnable durumunda daha uzun süre harcanması ve daha fazla CPU'ya sahip bir cihaza kıyasla diğer işlemlerle daha fazla CPU anlaşmazlığı yaşanması beklentisidir. Runnable durumunda normal bir telefon uygulaması için beklenenden daha fazla zaman harcansa da bu durum, giyilebilir cihazlar bağlamında anlaşılabilir.
OpenDexFilesFromOat* oyununda harcanan süre
Şimdi OpenDexFilesFromOat* konumunda harcanan süreyi kontrol edin. Bu süre, izde bindApplication dilimiyle aynı anda gerçekleşir. Bu dilim, uygulamanın DEX dosyalarının okunması için geçen süreyi temsil eder.
Engellenen bağlayıcı işlemleri
Ardından, bağlayıcı işlemlerini kontrol edin. Bağlayıcı işlemleri, istemci ile sunucu arasındaki çağrıları temsil eder: Bu durumda, uygulama (istemci) Android sistemini (sunucu) binder transaction ile çağırır ve sunucu bir binder
reply ile yanıt verir. CPU anlaşmazlığı riskini artırdığından uygulamanın başlatma sırasında gereksiz bağlayıcı işlemler yapmadığından emin olun. Mümkünse, bağlayıcı çağrılarını içeren işleri uygulama başlatma döneminden sonra erteleyin. Bağlayıcı işlemleri yapmanız gerekiyorsa bu işlemlerin, cihazınızın Vsync yenileme hızından daha uzun sürmediğinden emin olun.
Genellikle ActivityThreadMain dilimiyle aynı anda gerçekleşen ilk bağlayıcı işlemi bu durumda oldukça uzun görünür. Neler olup bittiği konusunda daha fazla bilgi edinmek için şu adımları uygulayın:
- İlişkili bağlayıcı yanıtını görmek ve bağlayıcı işlemine nasıl öncelik verildiği hakkında daha fazla bilgi edinmek için ilgili bağlayıcı işlem dilimini tıklayın.
Bağlayıcı yanıtını görmek için Geçerli Seçim paneline gidin ve Sonraki ileti dizileri bölümünün altında bağlayıcı yanıtı'nı tıklayın. İş Parçacığı alanı, bağlayıcı yanıtının manuel olarak gitmek istediğinizde burada gerçekleştiği iş parçacığını da bildirir. Bu iş parçacığı farklı bir işlemde gerçekleşir. Bağlayıcı işlemi ve yanıtı bağlayan bir satır görünür.
Şekil 5. Uygulama başlatılırken gerçekleşen bağlayıcı işlemlerini tanımlayın ve bunları erteleyip erteleyemeyeceğinizi değerlendirin. Sistem sunucusunun bu bağlayıcı işlemini nasıl işlediğini görmek için Cpu 0 ve Cpu 1 iş parçacıklarını ekranınızın üst kısmına sabitleyin.
Bağlayıcı yanıtı iş parçacığı adını içeren dilimleri (bu örnekte "Binder:687_11 [2542]") bularak bağlayıcı yanıtını işleyen sistem işlemlerini bulun. Bağlayıcı işlemi hakkında daha fazla bilgi almak için ilgili sistem işlemlerini tıklayın.
CPU 0'da gerçekleşen bağlayıcı işlemiyle ilişkili şu sistem sürecine göz atın:
Runnable (Preempted) durumunda. Bu durum, işlemin gecikeceğini gösterir.Bitiş Durumu Runnable (Preempted) yazar. Bu, CPU başka bir şey yaptığı için işlemin geciktiği anlamına gelir. Neyin geçici olarak engellendiğini öğrenmek için Ftrace Etkinlikleri satırlarını genişletin. Kullanılabilir hale gelen Yüz Etkinlikleri sekmesinde gezinin ve "Binder:687_11 [2542]" bağlayıcı iş parçacığıyla ilgili etkinlikleri arayın. Sistem işleminin geçici olarak kesildiği zamanda, "decon" bağımsız değişkenini içeren iki sistem sunucusu etkinliği gerçekleşmiştir. Bu, bunların görüntüleme denetleyicisiyle ilişkili olduğu anlamına gelir. Bu kulağa makul geliyor çünkü ekran denetleyicisi,
kareleri ekrana yerleştiriyor. Bu önemli bir görevdir! Etkinlikleri olduğu gibi bırakabilirsiniz.
JIT etkinliği
Just-in-time derleme (JIT) etkinliğini incelemek için uygulamanıza ait işlemleri genişletin, iki "Jit iş parçacığı havuzu" satırını bulun ve bunları görünümünüzün üst kısmına sabitleyin. Bu uygulama, uygulama başlatılırken Temel Profiller'den yararlandığından ilk Choreographer.doFrame çağrısının sonunda anlaşılan ilk kare çizilene kadar çok az JIT etkinliği gerçekleşir. Ancak yavaş başlatma nedenine (JIT compiling void) dikkat edin. Bu durum, Application creation etiketli izleme noktası sırasında gerçekleşen sistem etkinliğinin çok sayıda arka plan JIT etkinliğine neden olduğunu gösterir. Bu sorunu çözmek için profil koleksiyonunu uygulamanın kullanıma hazır olduğu bir noktaya genişleterek ilk kare Temel Profil'e çekildikten kısa bir süre sonra gerçekleşen etkinlikleri ekleyin. Çoğu durumda, Temel Profil koleksiyonunuzun sonuna, belirli bir kullanıcı arayüzü widget'ının ekranınızda görünmesini bekleyen ve ekranın tamamen dolu olduğunu belirten bir Makrobenchmark testinin sonuna bir satır ekleyerek bunu yapabilirsiniz.
Sonuçlar
Gmail Wear OS ekibi bu analizin sonucunda şu iyileştirmeler yaptı:
- Uygulama başlatılırken CPU etkinliğine bakarken anlaşmazlık fark ettiklerinden, uygulamanın tek bir statik resimle yüklendiğini belirtmek için kullanılan döner animasyonu değiştirdiler. Ayrıca, uygulamanın yüklenmekte olduğunu belirtmek için kullanılan ikinci ekran durumu olan parlama durumunu ertelemek ve CPU kaynaklarını serbest bırakmak için başlangıç ekranını uzattılar. Bu da uygulama başlatma gecikmesini %50 azalttı.
OpenDexFilesFromOat*ve JIT etkinliğinde harcanan zamana bakıp R8'e Temel Profillerin yeniden yazılmasını sağladılar. Bu sayede uygulama başlatma gecikmesini %20 azalttı.
Aşağıda ekipten uygulama performansının verimli bir şekilde nasıl analiz edileceğine ilişkin bazı ipuçları verilmiştir:
- İzleri ve sonuçları otomatik olarak toplayabilen, devam eden bir işlem oluşturun. Karşılaştırma kullanarak uygulamanız için otomatik izlemeyi ayarlamayı düşünebilirsiniz.
- Bir şeyleri iyileştireceğini düşündüğünüz değişiklikler için A/B testini kullanın ve iyileştirmiyorsa reddedin. Makrobenchmark kitaplığını kullanarak farklı senaryolarda performansı ölçebilirsiniz.
Daha fazla bilgi edinmek için aşağıdaki kaynakları inceleyin:
- Performans: Systrace ile örnekleme profili oluşturma işlemini kullanma - MAD Becerileri
- Performans: Profiler izlerini yakalama - MAD Becerileri