Uygulama başlatma süresi

Kullanıcılar, uygulamaların hızlı yüklenmesini ve yanıt vermesini bekler. Başlangıç süresi yavaş olan bir uygulama bu beklentiyi karşılamaz ve kullanıcıları hayal kırıklığına uğratabilir. Bu tür kötü deneyimler, kullanıcının Play Store'da uygulamanıza düşük puan vermesine veya uygulamanızı tamamen bırakmasına neden olabilir.

Bu sayfada, uygulamanızın başlatma süresini optimize etmenize yardımcı olacak bilgiler verilmektedir. Bu bilgiler arasında başlatma sürecinin iç işleyişine dair genel bakış, başlatma performansının nasıl profillendirileceği ve başlatma süresiyle ilgili bazı yaygın sorunların nasıl ele alınacağına dair ipuçları yer alır.

Farklı uygulama başlatma durumlarını anlama

Uygulama başlatma işlemi üç durumdan birinde gerçekleşebilir: baştan başlatma, hazır durumda başlatma veya çalışır durumda başlatma. Her durum, uygulamanızın kullanıcıya görünür hale gelmesinin ne kadar süreceğini etkiler. Sıfırdan başlatmada uygulamanız sıfırdan başlar. Diğer durumlarda, sistemin çalışan uygulamayı arka plandan ön plana getirmesi gerekir.

Her zaman baştan başlatma varsayımına göre optimizasyon yapmanızı öneririz. Bu işlem, sıcak ve hızlı başlatma performansını da artırabilir.

Uygulamanızı hızlı başlatma için optimize etmek istiyorsanız sistem ve uygulama düzeyinde neler olduğunu ve bu durumların her birinde nasıl etkileşimde bulunduklarını anlamanız faydalı olur.

Uygulama başlatma işlemini belirlemek için iki önemli metrik vardır: İlk ekran görüntülenene kadar geçen süre (TTID) ve tam ekran görüntülenene kadar geçen süre (TTFD). TTID, ilk karenin gösterilmesi için gereken süreyi, TTFD ise uygulamanın tamamen etkileşimli hale gelmesi için gereken süreyi ifade eder. TTID, kullanıcıya uygulamanın yüklendiğini bildirdiği için, TTFD ise uygulamanın gerçekten kullanılabilir olduğu zamanı gösterdiği için her ikisi de eşit derecede önemlidir. Bu sürelerden biri çok uzunsa kullanıcı, uygulamanız tam olarak yüklenmeden çıkabilir.

Baştan başlatma

Sıfırdan başlatma, uygulama işleminin çalışmadığı durumlarda uygulamanın sıfırdan başlamasını ifade eder. Bu, başlangıca kadar sistemin sürecinin uygulamanın sürecini oluşturduğu anlamına gelir. Sıfırdan başlatmalar, cihaz başlatıldığından veya sistem uygulamayı sonlandırdığından beri uygulamanızın ilk kez başlatılması gibi durumlarda gerçekleşir.

Bu durumda sistemin ve uygulamanın iş yükü diğer başlatma durumlarına göre daha fazla olduğundan, başlatma süresini en aza indirmenin en zor olduğu başlangıç türü sıfırdan başlatmadır.

Baştan başlatmanın başında sistemin üç görevi vardır:

1. Uygulamayı yükleyip başlatın.
2. Uygulama başlatıldıktan hemen sonra boş bir başlangıç penceresi gösterilir.
3. Uygulama sürecini oluşturun.

Sistem uygulama sürecini oluşturur oluşturmaz, sonraki aşamalardan uygulama süreci sorumludur:

1. Uygulama nesnesini oluşturun.
2. Ana iş parçacığını başlatın.
3. Ana etkinliği oluşturun.
4. Kullanıcı arayüzünü başlatın.
5. Kullanıcı arayüzünü ekranda çizin.

Uygulama işlemi ilk çizimi tamamladığında sistem işlemi, görüntülenen arka plan penceresini ana etkinlikle değiştirir. Bu noktada kullanıcı uygulamayı kullanmaya başlayabilir.

Compose'daki düzen aşamaları hakkında daha fazla bilgi için Jetpack Compose aşamaları başlıklı makaleyi inceleyin.

Uygulama ve ana makine etkinliği oluşturulurken performans sorunları ortaya çıkabilir.

Uygulama oluşturma

Uygulamanız başlatıldığında, sistem uygulamayı ilk kez çizme işlemini tamamlayana kadar boş başlangıç penceresi ekranda kalır. Bu noktada, sistem süreci uygulamanızın başlangıç penceresini değiştirerek kullanıcının uygulamayla etkileşimde bulunmasına olanak tanır.

Kendi uygulamanızda Application.onCreate işlevini geçersiz kılarsanız sistem, uygulama nesnenizde onCreate yöntemini çağırır. Ardından uygulama, kullanıcı arayüzü iş parçacığı olarak da bilinen ana iş parçacığını oluşturur ve uygulamanızın ana etkinliğini oluşturma görevini bu iş parçacığına verir.

Bu noktadan itibaren sistem ve uygulama düzeyindeki işlemler, uygulama yaşam döngüsü aşamalarına uygun şekilde ilerler.

Etkinlik oluşturma

Uygulama işlemi etkinliğinizi oluşturduktan sonra etkinlik aşağıdaki işlemleri gerçekleştirir:

1. Değerleri başlatır.
2. Yapıcıları çağırır.
3. Etkinliğin mevcut yaşam döngüsü durumuna uygun olarak Activity.onCreate gibi geri çağırma yöntemini çağırır.

Genellikle onCreate yöntemi, yükleme süresi üzerinde en büyük etkiye sahiptir. Jetpack Compose uygulamasında onCreate yönteminin ek yükü genellikle ilk beste işleminden kaynaklanır. Bu durum, uygulamanız setContent işlevini çağırdığında ve üst düzey composable'larınızı çağırdığında gerçekleşir. Derin veya karmaşık bir kullanıcı arayüzü hiyerarşisi ya da ana iş parçacığında yoğun hesaplamalar yapan composable'lar bu kompozisyon süresini artırabilir.

Hazır durumda başlatma

Hazır durumda başlatma, baştan başlatma sırasında gerçekleşen işlemlerin bir alt kümesini kapsar. Aynı zamanda, çalışır durumda başlatmaya kıyasla daha fazla ek yük oluşturur. Aşağıdakiler gibi birçok olası durum, sıcak başlangıç olarak değerlendirilebilir:

• Kullanıcı uygulamanızdan çıkar ancak uygulamayı yeniden başlatır. İşlem çalışmaya devam edebilir ancak uygulamanın, onCreate çağrısı kullanarak etkinliği sıfırdan oluşturması gerekir.

• Sistem, uygulamanızı bellekten çıkarır ve kullanıcı uygulamayı yeniden başlatır. İşlemin ve etkinliğin yeniden başlatılması gerekir ancak görev, onCreate içine iletilen kaydedilmiş örnek durumu paketinden bir miktar faydalanabilir.

Çalışır durumda başlatma

Uygulamanızın çalışır durumda başlatılması, baştan başlatılmasına kıyasla daha az ek yük oluşturur. Çalışır durumda başlatma işleminde sistem, uygulamanızın ana makine etkinliğini ön plana getirir. Uygulamanızın kullanıcı arayüzünün tamamı bellekte kalmaya devam ediyorsa uygulama, nesne başlatma, kullanıcı arayüzü başlatma ve oluşturma işlemlerini tekrarlamaktan kaçınabilir.

Ancak onTrimMemory gibi bellek kırpma etkinliklerine yanıt olarak bazı bellek temizlenirse bu nesnelerin çalışır durumda başlatma etkinliğine yanıt olarak yeniden oluşturulması gerekir.

Çalışır durumda başlatma, baştan başlatma senaryosunda olduğu gibi ekranda aynı davranışı gösterir. Sistem işlemi, uygulama etkinliği oluşturmayı tamamlayana kadar boş bir ekran gösterir.

Şekil 1. Çeşitli başlatma durumlarını ve ilgili süreçlerini gösteren bir diyagram. Her durum, çizilen ilk kareyle başlar.

Perfetto'da uygulama başlatmayı belirleme

Uygulama başlatma sorunlarını ayıklamak için uygulama başlatma aşamasında tam olarak nelerin yer aldığını belirlemek faydalıdır. Perfetto'da uygulamanın başlatılmasının tamamını belirlemek için şu adımları uygulayın:

1. Perfetto'da, Android Uygulama Başlangıçları türetilmiş metriğini içeren satırı bulun. Bu seçeneği görmüyorsanız Cihaz üzerinde sistem izleme uygulamasını kullanarak izleme yakalamayı deneyin.

   

   Şekil 2. Perfetto'daki Android Uygulama Başlangıçları türetilmiş metrik dilimi.

2. İlişkili dilimi tıklayın ve dilimi seçmek için m tuşuna basın. Dilimin etrafında köşeli parantezler görünür ve bu parantezler, dilimin ne kadar sürdüğünü gösterir. Süre, Geçerli seçim sekmesinde de gösterilir.

3. İşaretçiyi satırın üzerinde tuttuğunuzda görünen sabitleme simgesini tıklayarak Android Uygulama Başlangıçları satırını sabitleyin.

4. Söz konusu uygulamanın bulunduğu satıra gidin ve satırı genişletmek için ilk hücreyi tıklayın.

5. Genellikle en üstte bulunan ana ileti dizisini w tuşuna basarak yakınlaştırın (Uzaklaştırmak, sola ve sağa gitmek için sırasıyla s, a, d tuşlarına basın).

   

   Şekil 3. Android Uygulama Başlangıçları, uygulamanın ana iş parçacığının yanında türetilmiş metrik dilimi.

6. Türetilmiş metrikler dilimi, uygulama başlatma işlemine tam olarak neyin dahil edildiğini görmeyi kolaylaştırır. Böylece hata ayıklama işlemine daha ayrıntılı bir şekilde devam edebilirsiniz.

Bir Jetpack Compose uygulamasını analiz ederken kullanıcı arayüzünüzün performansıyla ilgili ayrıntılı bilgileri görmek için Composition tracing'i kullanabilirsiniz. Ana ileti dizisindeki Choreographer#doFrame ile başlayan izleme bölümlerine özellikle dikkat edin. Compose:recompose, Compose:layout ve Compose:draw gibi dilimleri bulun. Bu metrikler, uygulamanızın belirli bileşenleri oluşturmak, ölçmek, yerleştirmek ve çizmek için ne kadar zaman harcadığını gösterir.

Başlatma işlemlerini incelemek ve iyileştirmek için metrikleri kullanma

Başlatma süresi performansını doğru şekilde teşhis etmek için uygulamanızın başlatılmasının ne kadar sürdüğünü gösteren metrikleri izleyebilirsiniz. Android, uygulamanızda sorun olduğunu göstermek ve sorunu teşhis etmenize yardımcı olmak için çeşitli yöntemler sunar. Android vitals, bir sorun oluştuğunda sizi uyarabilir. Teşhis araçları ise sorunu teşhis etmenize yardımcı olabilir.

Başlangıç metriklerini kullanmanın avantajları

Android, soğuk ve sıcak uygulama başlatma işlemlerini optimize etmek için ilk ekran görüntülenene kadar geçen süre (TTID) ve tam ekran görüntülenene kadar geçen süre (TTFD) metriklerini kullanır. Android Çalışma Zamanı (ART), gelecekteki başlatma işlemlerinin optimizasyonu için kodu verimli bir şekilde önceden derlemek üzere bu metriklerdeki verileri kullanır.

Daha hızlı başlatma, uygulamanızla daha uzun süreli kullanıcı etkileşimine yol açar. Bu da erken çıkma, örneği yeniden başlatma veya farklı bir uygulamaya gitme durumlarını azaltır.

Android vitals

Android vitals, uygulamanızın başlatma süreleri çok uzun olduğunda Play Console'da sizi uyararak uygulamanızın performansını artırmanıza yardımcı olabilir.

Android vitals, uygulamanızın aşağıdaki başlangıç sürelerini aşırı olarak değerlendirir:

• Yeni başlatma 5 saniye veya daha uzun sürüyor.
• Hazırda başlatma 2 saniye veya daha uzun sürüyor.
• Hot startup 1,5 saniye veya daha uzun sürüyor.

Android vitals, ilk ekran görüntülenene kadar geçen süre (TTID) metriğini kullanır. Google Play'in Android vitals verilerini nasıl topladığı hakkında bilgi edinmek için Play Console belgelerine bakın.

İlk gösterime kadar geçen süre

İlk gösterime kadar geçen süre (TTID), uygulamanın kullanıcı arayüzünün ilk karesini göstermek için gereken süredir. Bu metrik, uygulamanın ilk kareyi oluşturması için geçen süreyi ölçer. Bu süreye, baştan başlatma : sıfırdan başlatma sırasında sürecin ilk kullanıma hazırlanması, baştan başlatma : sıfırdan başlatma veya hazır durumda başlatma sırasında etkinliğin oluşturulması ve ilk karenin görüntülenmesi dahildir. Uygulamanızın TTID'sini düşük tutmak, kullanıcıların uygulamanızın hızlı bir şekilde başlatıldığını görmelerini sağlayarak kullanıcı deneyimini iyileştirir. TTID, Android Framework tarafından her uygulama için otomatik olarak bildirilir. Uygulama başlatma için optimizasyon yaparken TTFD'ye kadar bilgi almak için reportFullyDrawn'yi uygulamanızı öneririz.

TTID, aşağıdaki etkinlik dizisini içeren toplam geçen süreyi temsil eden bir zaman değeri olarak ölçülür:

• İşlemi başlatma
• Nesneler başlatılıyor.
• Ana makine etkinliğini oluşturma ve başlatma.
• Kullanıcı arayüzü başlatılıyor.
• Uygulamanın ilk kez çizilmesi.

TTID'yi alma

TTID'yi bulmak için Logcat komut satırı aracında Displayed adlı bir değer içeren çıkış satırını arayın. Bu değer, TTID'dir ve aşağıdaki örneğe benzer bir görünüme sahiptir. Bu örnekte TTID, 3s534ms'dir:

ActivityManager: Displayed com.android.myexample/.StartupTiming: +3s534ms

Android Studio'da TTID'yi bulmak için açılır filtre menüsünden Logcat görünümünüzdeki filtreleri devre dışı bırakın ve ardından Şekil 4'te gösterildiği gibi Displayed zamanını bulun. Bu günlük, uygulamanın kendisi değil sistem sunucusu tarafından sunulduğu için filtrelerin devre dışı bırakılması gerekir.

Şekil 4. Devre dışı bırakılan filtreler ve Logcat'teki Displayed değeri.

Logcat çıkışındaki Displayed metriği, tüm kaynaklar yüklenip görüntülenene kadar geçen süreyi mutlaka yakalamaz. İlk kompozisyonda referans verilmeyen kaynakları (ör. eşzamansız olarak yüklenen veriler veya resimler) ya da uygulamanın nesne başlatma kapsamında oluşturduğu kaynakları dışarıda bırakır. Bu kaynaklar, yüklenmeleri satır içi bir işlem olduğu ve uygulamanın ilk gösterimini engellemediği için hariç tutulur. Kaynaklar hakkında daha fazla bilgi için Compose'daki kaynaklar başlıklı makaleyi inceleyin.

Bazen Logcat çıktısındaki Displayed satırı, aşağıdaki örnekte olduğu gibi toplam süre için ek bir alan içerir:

ActivityManager: Displayed com.android.myexample/.StartupTiming: +3s534ms (total +1m22s643ms)

Bu durumda, ilk kez ölçüm yalnızca ilk çizilen etkinlik için yapılır (genellikle toplantıyı düzenleyenin etkinliği). total zaman ölçümü, uygulama süreci başladığında başlar ve önce başlatılan ancak ekranda hiçbir şey göstermeyen başka bir etkinliği içerebilir. total zaman ölçümü yalnızca tek etkinlik ile toplam başlatma süreleri arasında fark olduğunda gösterilir.

Android Studio'da Logcat'i kullanmanızı öneririz. Ancak Android Studio kullanmıyorsanız uygulamanızı adb shell activity manager komutu ile çalıştırarak da TTID'yi ölçebilirsiniz. Örneğin:

adb [-d|-e|-s <serialNumber>] shell am start -S -W
com.example.app/.MainActivity
-c android.intent.category.LAUNCHER
-a android.intent.action.MAIN

Displayed metriği, Logcat çıkışında eskisi gibi görünür. Terminal pencerenizde aşağıdakiler gösterilir:

Starting: Intent
Activity: com.example.app/.MainActivity
ThisTime: 2044
TotalTime: 2044
WaitTime: 2054
Complete

-c ve -a bağımsız değişkenleri isteğe bağlıdır ve <category> ile <action> değerlerini belirtmenize olanak tanır.

Tam gösterime kalan süre

Tam görüntüleme süresi (TTFD), bir uygulamanın kullanıcı için etkileşimli hale gelmesi için gereken süredir. Uygulamanın kullanıcı arayüzünün ilk karesinin ve ilk kare görüntülendikten sonra eşzamansız olarak yüklenen içeriğin gösterilmesi için geçen süre olarak bildirilir. Genellikle bu, uygulamanın bildirdiği şekilde ağdan veya diskten yüklenen birincil içeriktir. Diğer bir deyişle, TTFD, TTID'nin yanı sıra uygulamanın kullanılabilir hale gelmesi için geçen süreyi de içerir. Uygulamanızın TTFD'sini düşük tutmak, kullanıcıların uygulamanızla hızlı bir şekilde etkileşim kurmasına olanak tanıyarak kullanıcı deneyimini iyileştirir.

Sistem, ana makine penceresi ilk çerçevesini oluşturduğunda TTID'yi belirleyebilse de TTFD'yi otomatik olarak belirleyemez. Uygulamalar genellikle birincil içeriklerini eşzamansız olarak yüklediğinden sistem, uygulamanın kullanıcı tarafından ne zaman tam olarak kullanılabileceğini bilemez. TTFD'yi belirlemek için uygulama, tamamen çizilmiş duruma ulaştığında sisteme sinyal vermelidir.

TTFD'yi alma

TTFD'yi bulmak için ComponentActivity öğesinin reportFullyDrawn yöntemini çağırarak tamamen çizilmiş durumu belirtin. reportFullyDrawn yöntemi, uygulamanın tamamen çizildiği ve kullanılabilir durumda olduğu zamanı bildirir. TTFD, sistemin uygulama başlatma amaçlı isteği aldığı andan reportFullyDrawn çağrılana kadar geçen süredir. reportFullyDrawn işlevini çağırmazsanız TTFD değeri raporlanmaz.

TTFD'yi ölçmek için kullanıcı arayüzünü ve tüm verileri tamamen çizdikten sonra reportFullyDrawn işlevini çağırın. Sistem tarafından ölçülen ilk etkinliğin penceresi ilk kez çizilip görüntülenmeden önce reportFullyDrawn işlevini çağırmayın. Aksi takdirde sistem, sistem tarafından ölçülen süreyi bildirir. Diğer bir deyişle, sistem TTID'yi algılamadan önce reportFullyDrawn çağrısı yaparsanız sistem hem TTID'yi hem de TTFD'yi aynı değer olarak bildirir ve bu değer TTID değeridir.

reportFullyDrawn kullandığınızda Logcat, aşağıdaki örneğe benzer bir çıkış gösterir. Bu örnekte TTFD 1 sn 54 ms'dir:

system_process I/ActivityManager: Fully drawn {package}/.MainActivity: +1s54ms

Logcat çıkışı bazen İlk görüntüleme süresi bölümünde açıklandığı gibi total süresini içerir.

Görüntüleme süreleriniz istediğinizden daha yavaşsa başlatma sürecindeki darboğazları belirlemeyi deneyebilirsiniz.

Tamamen çizilmiş durumun elde edildiğini bildiğiniz temel durumlarda, tamamen çizilmiş durumu belirtmek için reportFullyDrawn kullanabilirsiniz. Ancak arka plan iş parçacıklarının, tamamen çizilmiş durum elde edilmeden önce arka plan çalışmasını tamamlaması gereken durumlarda daha doğru bir TTFD ölçümü için reportFullyDrawn değerini geciktirmeniz gerekir. reportFullyDrawn nasıl erteleneceğini öğrenmek için aşağıdaki bölüme bakın.

Başlatma zamanlaması doğruluğunu artırma

Uygulamanızda geç yükleme yapılıyorsa ve ilk görüntülemede tüm kaynaklar (ör. uygulamanız ağdan resim getiriyorsa) yer almıyorsa liste doldurmayı karşılaştırma zamanlamanıza dahil edebilmek için uygulamanız kullanılabilir hale gelene kadar reportFullyDrawn çağrısını ertelemek isteyebilirsiniz.

Örneğin, kullanıcı arayüzünde LazyColumn veya LazyRow gibi dinamik bir liste varsa bu liste, ilk çizildikten ve dolayısıyla kullanıcı arayüzü tamamen çizilmiş olarak işaretlendikten sonra tamamlanan bir arka plan göreviyle doldurulabilir. Bu gibi durumlarda liste doldurma, karşılaştırmaya dahil edilmez.

Liste doldurma işlemini karşılaştırma zamanlamanıza dahil etmek için fullyDrawnReporter kullanarak FullyDrawnReporter alın ve uygulama kodunuza bir muhabir ekleyin. Arka plan görevi listeyi doldurmayı bitirdikten sonra muhabiri serbest bırakın.

FullyDrawnReporter, eklenen tüm raporlar serbest bırakılana kadar reportFullyDrawn yöntemini çağırmaz. Bir muhabir ekleyip arka plan işlemi tamamlanana kadar yayınlamayarak, başlangıç zamanlaması verilerinin liste doldurma süresini içermesini sağlarsınız. Bu işlem, uygulamanın kullanıcı açısından davranışını değiştirmez. reportFullyDrawn, sıradan bağımsız olarak tüm görevler tamamlanana kadar çağrılmaz.

Uygulamanızda Jetpack Compose kullanılıyorsa tamamen çizilmiş durumu belirtmek için aşağıdaki API'leri kullanabilirsiniz:

• ReportDrawn: Composable'ınızın hemen etkileşime hazır olduğunu gösterir.
• ReportDrawnWhen: Composable'ınızın etkileşime hazır olduğunu belirtmek için list.count > 0 gibi bir yüklem alır.
• ReportDrawnAfter: Tamamlandığında composable'ınızın etkileşime hazır olduğunu belirten bir askıya alma yöntemi kullanır.

Aşağıdaki örnekte, her biri kendi raporlayıcısını kaydederek birden fazla arka plan görevini eşzamanlı olarak nasıl çalıştırabileceğiniz gösterilmektedir:

class MainActivity : ComponentActivity() {

    sealed interface ActivityState {
        data object LOADING : ActivityState
        data object LOADED : ActivityState
    }

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        setContent {
            var activityState by remember {
                mutableStateOf(ActivityState.LOADING as ActivityState)
            }
            fullyDrawnReporter.addOnReportDrawnListener {
                activityState = ActivityState.LOADED
            }
            ReportFullyDrawnTheme {
                when(activityState) {
                    is ActivityState.LOADING -> {
                        // Display the loading UI.
                    }
                    is ActivityState.LOADED -> {
                        // Display the full UI.
                    }
                }
            }
            SideEffect {
                fullyDrawnReporter.addReporter()
                lifecycleScope.launch(Dispatchers.IO) {
                    // Perform the background operation.
                    fullyDrawnReporter.removeReporter()
                }
                fullyDrawnReporter.addReporter()
                lifecycleScope.launch(Dispatchers.IO) {
                    // Perform the background operation.
                    fullyDrawnReporter.removeReporter()
                }
            }
        }
    }
}

Darboğazları belirleme

Darboğazları aramak için Android Studio CPU Profiler'ı kullanabilirsiniz. Daha fazla bilgi için CPU Profiler ile CPU etkinliğini inceleme başlıklı makaleyi inceleyin.

Ayrıca, uygulamalarınızın ve etkinliklerinizin onCreate yöntemlerindeki satır içi izleme sayesinde olası darboğazlar hakkında bilgi edinebilirsiniz. Satır içi izleme hakkında bilgi edinmek için Trace işlevleriyle ilgili dokümanlara ve sistem izlemeye genel bakış başlıklı makaleye bakın.

Sık karşılaşılan sorunları çözme

Bu bölümde, uygulama başlatma performansını sıklıkla etkileyen çeşitli sorunlar ele alınmaktadır. Bu sorunlar genellikle uygulama ve etkinlik nesnelerinin başlatılmasıyla ve ekranların yüklenmesiyle ilgilidir.

Yoğun uygulama başlatma

Kodunuz Application nesnesini geçersiz kıldığında ve bu nesneyi başlatırken ağır işler veya karmaşık mantık yürüttüğünde başlatma performansı düşebilir. Application alt sınıflarınız henüz yapılması gerekmeyen başlatma işlemleri gerçekleştiriyorsa uygulamanız başlatma sırasında zaman kaybedebilir.

Bazı başlatmalar tamamen gereksiz olabilir. Örneğin, uygulama aslında bir amaç doğrultusunda başlatıldığında ana etkinliğin durum bilgilerinin başlatılması gibi. Uygulama, bir amaçla yalnızca daha önce başlatılmış durum verilerinin bir alt kümesini kullanır.

Uygulama başlatma sırasında karşılaşılan diğer zorluklar arasında, etkili veya çok sayıda olan çöp toplama etkinlikleri ya da başlatma işlemiyle eşzamanlı olarak gerçekleşen disk G/Ç'si yer alır. Bu durum, başlatma sürecini daha da engeller. Çöp toplama özellikle Dalvik çalışma zamanında dikkate alınması gereken bir konudur. Android çalışma zamanı (ART) çöp toplamayı eşzamanlı olarak gerçekleştirerek bu işlemin etkisini en aza indirir.

Sorunu teşhis etme

Sorunu teşhis etmek için yöntem izleme veya satır içi izleme özelliğini kullanabilirsiniz.

Yöntem izleme

CPU Profiler'ı çalıştırmak, callApplicationOnCreate yönteminin sonunda com.example.customApplication.onCreate yönteminizi çağırdığını gösterir. Araç, bu yöntemlerin yürütülmesinin uzun sürdüğünü gösteriyorsa hangi işlemlerin gerçekleştiğini görmek için daha ayrıntılı bir inceleme yapın.

Satır içi izleme

Aşağıdakiler de dahil olmak üzere olası sorun kaynaklarını araştırmak için satır içi izlemeyi kullanın:

• Uygulamanızın ilk onCreate işlevi.
• Uygulamanızın başlattığı tüm genel tekil nesneler.
• Performans sorunu sırasında gerçekleşebilecek tüm disk G/Ç'leri, seri durumdan çıkarma veya sıkı döngüler.

Sorunun çözümleri

Sorun gereksiz başlatmalardan veya disk G/Ç'den kaynaklanıyor olsa da çözüm, geç başlatmadır. Başka bir deyişle, yalnızca hemen ihtiyaç duyulan nesneleri başlatın. Global statik nesneler oluşturmak yerine, uygulamanın nesneleri yalnızca ilk kez ihtiyaç duyduğunda başlatıldığı tekil örnek kalıbına geçin.

Ayrıca, nesneleri ve bağımlılıkları ilk kez yerleştirildiklerinde oluşturan Hilt gibi bir bağımlılık yerleştirme çerçevesi kullanmayı da düşünebilirsiniz.

Uygulamanız, başlatma sırasında uygulama bileşenlerini başlatmak için içerik sağlayıcıları kullanıyorsa bunun yerine App Startup kitaplığını kullanmayı düşünebilirsiniz.

Yoğun aktivite başlatma

Etkinlik oluşturma genellikle çok fazla ek yük gerektiren bir iştir. Genellikle, bu çalışmayı optimize ederek performansı artırma fırsatları vardır. Bu tür yaygın sorunlar şunlardır:

• Büyük veya karmaşık bir kullanıcı arayüzünü başlatma.
• Composable işlevlerde yoğun başlatma.
• Diske veya ağ G/Ç'ye ekran çizimini engelleme.
• Bit eşlemleri yükleme ve kodunu çözme
• VectorDrawable nesneler rasterleştiriliyor.
• Uygulamanın barındırıcı etkinliğinin diğer alt sistemlerinin başlatılması.

Sorunu teşhis etme

Bu durumda da hem yöntem izleme hem de satır içi izleme yararlı olabilir.

Yöntem izleme

CPU Profiler'ı kullanırken uygulamanızın Application alt sınıf oluşturucularına ve com.example.customApplication.onCreate yöntemlerine dikkat edin.

Araç, bu yöntemlerin yürütülmesinin uzun sürdüğünü gösteriyorsa ne tür bir çalışma yapıldığını görmek için daha ayrıntılı bir inceleme yapın.

Satır içi izleme

Aşağıdakiler de dahil olmak üzere olası sorun kaynaklarını araştırmak için satır içi izlemeyi kullanın:

• Uygulamanızın ilk onCreate işlevi.
• Başlattığı tüm genel tekil nesneler.
• Performans sorunu sırasında gerçekleşebilecek tüm disk G/Ç'leri, seri durumdan çıkarma veya sıkı döngüler.

Sorunun çözümleri

Birçok olası darboğaz vardır ancak sık karşılaşılan iki sorun ve çözümleri aşağıda verilmiştir:

• Kullanıcı arayüzü hiyerarşiniz ne kadar büyükse uygulamanın ilk kullanıma hazırlaması o kadar uzun sürer. Bu sorunu ele alırken aşağıdaki adımları göz önünde bulundurun:
  • Gereksiz veya iç içe yerleştirilmiş composable'ları azaltarak kullanıcı arayüzü hiyerarşinizi düzleştirin.
  • Başlatma sırasında gereksiz oluşturma ve yeniden oluşturmadan kaçının.
  • Kritik olmayan kullanıcı arayüzünün oluşturulmasını erteleyin.
• Tüm kaynak başlatma işlemlerinin ana iş parçacığında yapılması da başlatma işlemini yavaşlatabilir. Bu sorunu aşağıdaki şekilde giderebilirsiniz:
  • Tüm kaynak başlatma işlemlerini, uygulamanın farklı bir iş parçacığında geç gerçekleştirebileceği şekilde taşıyın.
  • Kullanıcı arayüzünüzü önce yer tutucu verilerle yükleyip görüntüleyin, ardından bit eşlemlere ve diğer kaynaklara bağlı görsel özellikleri güncelleyin.

Yeniden oluşturma hakkında daha fazla bilgi için Yeniden oluşturma ve Yeniden oluşturma sayılarını alma başlıklı makaleleri inceleyin.

Özel başlangıç ekranları

Android 11'de (API düzeyi 30) veya önceki sürümlerde özel bir başlangıç ekranı uygulamak için daha önce aşağıdaki yöntemlerden birini kullandıysanız başlatma sırasında ek süre eklendiğini görebilirsiniz:

• Başlatma sırasında sistem tarafından çizilen ilk boş ekranı kapatmak için windowDisablePreview tema özelliğini kullanın.
• Özel bir Activity kullanma

Android 12'den itibaren SplashScreen API'ye geçiş yapılması zorunludur. Bu API, başlatma süresini kısaltır ve başlangıç ekranınızı aşağıdaki şekillerde ayarlamanıza olanak tanır:

• Açılış ekranının görünümünü değiştirmek için tema ayarlayın.
• Açılış ekranının ne kadar süreyle gösterileceğini windowSplashScreenAnimationDuration ile kontrol edin.
• Başlangıç ekranı animasyonunu özelleştirin ve başlangıç ekranını kapatma animasyonunu sorunsuz bir şekilde yönetin.

Ayrıca, uyumluluk kitaplığı, geriye dönük uyumluluğu etkinleştirmek ve tüm Android sürümlerinde başlangıç ekranı gösterimi için tutarlı bir görünüm ve tarz oluşturmak üzere SplashScreen API'sini geriye dönük olarak taşır.

Ayrıntılar için Açılış ekranı taşıma kılavuzuna bakın.