Uygulama başlatma süresi

Kullanıcılar uygulamaların hızlı yüklenmesini ve duyarlı olmasını bekler. Başlangıç zamanı yavaş olan bir uygulama bu beklentiyi karşılamaz ve kullanıcıları hayal kırıklığına uğratabilir. Bu tür kötü bir deneyim, kullanıcının Play Store'da uygulamanıza düşük puan vermesine, hatta uygulamanızı tamamen terk etmesine neden olabilir.

Bu sayfada uygulamanızın lansman zamanını optimize etmenize yardımcı olacak bilgiler sağlanmaktadır. Bu bilgiler arasında lansman sürecinin dahili ayrıntılarına genel bir bakış, başlangıç performansının nasıl profilleneceği ve bazı yaygın başlangıç zamanı sorunları ile bunları ele alma konusunda ipuçları yer almaktadır.

Farklı uygulama başlatma durumlarını anlama

Uygulama şu üç durumdan birinde başlatılabilir: baştan başlatma, hazır durumda başlatma veya çalışır durumda başlatma. Her durum, uygulamanızın kullanıcılara 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 ise 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, hazır durumda ve çalışır durumda başlatmanın performansını da artırabilir.

Uygulamanızı hızlı başlatma için optimize etmek amacıyla sistem ve uygulama düzeylerinde neler olduğunu ve bu durumların her birinde nasıl etkileşimde bulunduklarını anlamak faydalıdır.

Uygulamanın başlatılmasını belirleyen iki önemli metrik, ilk gösterime kadar geçen süre (TTID) ve tamamen çizim süresi (TTFD) şeklindedir. TTID, ilk kareyi görüntülemek için gereken süreyi, TTFD ise uygulamanın tamamen etkileşimli hale gelmesi için gereken süreyi ifade eder. TTID kullanıcının uygulamanın yüklendiğini bilmesini sağladığı ve TTFD, uygulamanın gerçekten kullanılabilir olduğu zamanları sağladığı için her ikisi de eşit derecede önemlidir. Bunlardan biri çok uzunsa kullanıcı, tam olarak yüklenmeden uygulamanızdan çıkabilir.

Soğuk başlatma

Sıfırdan başlatma, bir uygulamanın sıfırdan başlatılmasını ifade eder. Yani bu başlatılana kadar uygulamanın işlemi sistem tarafından oluşturulur. Sıfırdan başlatmalar, uygulamanızın cihaz başlatıldıktan sonra ilk kez başlatılması veya sistem tarafından uygulamanın sonlandırılması gibi durumlarda gerçekleşir.

Bu tür bir başlangıç, başlatma süresini en aza indirme konusunda en büyük zorluğu teşkil eder. Çünkü sistemin ve uygulamanın iş yükü diğer başlatma durumlarına göre daha fazladır.

Soğuk başlatmanın başlangıcında, sistemin aşağıdaki üç görevi vardır:

  1. Uygulamayı yükleyip başlatın.
  2. Lansmandan hemen sonra uygulama için boş bir başlangıç penceresi görüntüleyin.
  3. Uygulama sürecini oluşturun.

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

  1. Uygulama nesnesini oluşturun.
  2. Ana ileti dizisini başlatın.
  3. Ana etkinliği oluşturun.
  4. Görüntüleme sayısını artırma.
  5. Ekranı düzenleyin.
  6. İlk çizimi yapın.

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

Şekil 1'de sistem ve uygulama işlemlerinin birbirleri arasında nasıl çalıştığı gösterilmektedir.

Şekil 1. Başarılı bir uygulama lansmanının önemli bölümlerinin görsel temsili.

Uygulamanın oluşturulması ve oluşturulması sırasında performans sorunları ortaya çıkabilir.

Uygulama oluşturma

Uygulamanız başlatıldığında, sistem uygulamayı ilk kez çizmeyi bitirene kadar ekranda boş başlangıç penceresi kalır. Bu noktada, sistem işlemi uygulamanızın başlangıç penceresini değiştirerek kullanıcının uygulamayla etkileşimde bulunmasına izin verir.

Kendi uygulamanızda Application.onCreate() öğesini geçersiz kılarsanız sistem, uygulama nesnenizde onCreate() yöntemini çağırır. Daha sonra, uygulama kullanıcı arayüzü iş parçacığı olarak da bilinen ana iş parçacığı oluşturur ve ana etkinliğinizi oluşturmakla görevlendirilir.

Bu noktadan itibaren, sistem ve uygulama düzeyindeki işlemler uygulama yaşam döngüsü aşamalarına uygun olarak 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. Çağrı kurucuları.
  3. Etkinliğin mevcut yaşam döngüsü durumuna uygun olan Activity.onCreate() gibi geri çağırma yöntemini çağırır.

Genellikle onCreate() yöntemi, en yüksek ek yüke sahip olan işi gerçekleştirdiğinden, yükleme süresi üzerinde en büyük etkiye sahiptir. Görünümleri yükleme, şişirme ve etkinliğin çalışması için gereken nesneleri başlatma.

Hazır durumda başlatma

Hazır durumda başlatma, sıfırdan başlatma sırasında gerçekleştirilen işlemlerin bir alt kümesini kapsar. Aynı zamanda, çalışır durumda başlatmadan daha fazla genel gider anlamına gelir. Aşağıdakiler gibi hazır durumda başlatma olarak değerlendirilebilecek birçok potansiyel durum vardır:

  • Kullanıcı uygulamanızdan geri çı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 yeniden oluşturması gerekir.

  • Sistem uygulamanızı bellekten çıkarır, ardından kullanıcı yeniden başlatır. İşlemin ve etkinliğin yeniden başlatılması gerekir ancak görev, onCreate() aracına iletilen kayıtlı örnek durumu paketinden bir şekilde yararlanabilir.

Çalışır durumda başlatma

Uygulamanızın çalışır durumda başlatılması, baştan başlatmaya göre daha az ek yüke sahiptir. Çalışırken sistem, etkinliğinizi ön plana çıkarır. Uygulamanızın tüm etkinlikleri hâlâ bellekte bulunuyorsa uygulama tekrarlayan nesne başlatma, düzen değiştirme ve oluşturma işlemlerini tekrarlamaktan kaçınabilir.

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

Çalışır durumda başlatma, ekranda soğuk başlatma senaryosuyla aynı davranışı gösterir. Sistem işlemi, uygulama, etkinliği oluşturmayı bitirene kadar boş bir ekran görüntüler.

Şekil 2. Çeşitli başlatma durumlarını ve bunlarla ilgili süreçleri gösteren, her bir durumun çizilen ilk kareden itibaren gösterildiği bir şema.

Perfetto'da uygulama girişimi nasıl anlaşılır?

Uygulama başlatma sorunlarını ayıklamak için, uygulama başlatma aşamasına tam olarak nelerin dahil olduğunu belirlemek faydalı olacaktır. Perfetto'da uygulama başlatma aşamasının tamamını tanımlamak için aşağıdaki adımları izleyin:

  1. Perfetto'da, Android Uygulama Başlatmaları'ndan türetilen metriğin bulunduğu satırı bulun. Bu seçeneği görmüyorsanız cihaz üzerinde sistem izleme uygulamasını kullanarak iz yakalamayı deneyin.

    Şekil 3.Android App Startups, Perfetto'dan 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 işlemin ne kadar sürdüğünü belirtir. Süre, Geçerli seçim sekmesinde de gösterilir.

  3. İşaretçiyi satırın üzerine getirdiğinizde görünen raptiye simgesini tıklayarak Android App Startups 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. w tuşuna basarak ana iş parçacığını, genellikle üstte olacak şekilde yakınlaştırın (uzaklaştırmak için s, a, d tuşlarına basın, sola taşımak ve sırasıyla sağa taşımak için) basın.

    Şekil 4.Android Uygulama Startup'ları metriği, uygulamanın ana iş parçacığının yanında türetilmiş bir metrik dilimidir.
  6. Türetilen metrikler dilimi, uygulama başlatma işlemine tam olarak nelerin dahil edildiğini görmeyi kolaylaştırır. Böylece hata ayıklama işlemine daha ayrıntılı şekilde devam edebilirsiniz.

Girişimleri 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şlamasının ne kadar sürdüğünü gösteren metrikleri izleyebilirsiniz. Android, uygulamanızda bir sorun olduğunu göstermek için çeşitli yollar sunar ve sorunu teşhis etmenize yardımcı olur. Android vitals bir sorun oluştuğunda sizi uyarabilir ve teşhis araçları sorunu teşhis etmenize yardımcı olabilir.

Başlangıç metriklerini kullanmanın avantajları

Android, baştan başlayan ve hazır durumda uygulama başlatma işlemlerini optimize etmek için ilk görüntüleme süresi (TTID) ve tam görüntüleme süresi (TTFD) metriklerini kullanır. Android Runtime (ART), bu metriklerden elde edilen verileri kullanarak gelecekteki startup'ların optimizasyonu için kodları önceden derlemektedir.

Daha hızlı başlatmalar, uygulamanızla daha uzun süreli kullanıcı etkileşimi sağlar. Böylece erken çıkış, örneği yeniden başlatma veya farklı bir uygulamaya gitme durumları azalır.

Android vitals

Android vitals, uygulamanızın başlatma süresi çok fazla olduğunda Play Console'da sizi uyararak uygulamanızın performansının iyileştirilmesine yardımcı olabilir.

Android vitals, uygulamanız için aşağıdaki başlatma sürelerini çok uzun olarak kabul eder:

  • Sıfır başlatma işlemi 5 saniye veya daha uzun sürer.
  • Sıcak başlatma, 2 saniye veya daha uzun sürer.
  • Hızlı başlatma 1,5 saniye veya daha uzun sürer.

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 daha fazla bilgi için Play Console dokümanlarına bakın.

İlk ekran görüntülenene kadar geçen süre

İlk ekran görüntülenene kadar geçen süre (TTID), uygulamanın kullanıcı arayüzünün ilk karesinin görüntülenmesi için geçen süredir. Bu metrik, baştan başlatma, soğuk veya hazır durumda başlatma sırasında etkinlik oluşturma ve ilk kareyi görüntüleme de dahil olmak üzere bir uygulamanın ilk karesini oluşturma süresini ölçer. Uygulamanızın TTID değerini düşük tutmak, kullanıcıların uygulamanızın hızlı bir şekilde açıldığını görmesini sağlayarak kullanıcı deneyimini iyileştirmeye yardımcı olur. TTID, Android Çerçevesi tarafından her uygulama için otomatik olarak raporlanır. Uygulama başlatma işlemi için optimizasyon yaparken TTFD'ye kadar bilgi almak için reportFullyDrawn kullanmanızı öneririz.

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

  • İşlem başlatılıyor.
  • Nesneler başlatılıyor.
  • Etkinliği oluşturma ve başlatma.
  • Düzen şişiriliyor.
  • Uygulamayı ilk kez çizme.

TTID 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 TTID'nin 3s534 ms olduğu aşağıdaki örneğe benzer:

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

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

Şekil 5. 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 yakalamayabilir. Düzen dosyasında başvuruda bulunmayan veya nesne başlatma kapsamında uygulamanın oluşturduğu kaynakları dışarıda bırakır. Bu kaynakların yüklenmesi satır içi bir işlem olduğundan ve uygulamanın ilk görüntüsünü engellemediğinden hariç tutar.

Bazen Logcat çıkışındaki Displayed satırı, toplam süre için ek bir alan içerir. Örnek:

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

Bu durumda, ilk ölçüm yalnızca ilk çizilen etkinlik içindir. total süresi ölçümü, uygulama işlemi başlatıldığında başlar ve önce başlatılan ancak ekranda hiçbir şey görüntülenmeyen başka bir etkinliği içerebilir. total süresi ölçümü yalnızca tek etkinlik ile toplam başlatma süreleri arasında fark olduğunda gösterilir.

Logcat'i Android Studio'da kullanmanızı öneririz ancak Android Studio'yu kullanmıyorsanız adb kabuk etkinlik yöneticisi komutuyla uygulamanızı çalıştırarak TTID'yi de ölçebilirsiniz. Aşağıda bununla ilgili bir örnek verilmiştir:

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 daha önce olduğu gibi görünür. Terminal pencereniz aşağıdakileri görüntüler:

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. Bu süre, uygulamanın kullanıcı arayüzünün ilk karesini ve ilk kare gösterildikten sonra eşzamansız olarak yüklenen içeriği görüntülemek için geçen süre olarak raporlanır. Genellikle bu, uygulamanın bildirdiği şekilde ağdan veya diskten yüklenen birincil içeriktir. Diğer bir deyişle, TTFD hem TTID'yi hem de uygulamanın kullanılabilir hale gelmesi için gereken süreyi içerir. Uygulamanızın TTFD'sini düşük tutmak, kullanıcıların uygulamanızla hızlı bir şekilde etkileşim kurmasını sağlayarak kullanıcı deneyimini iyileştirmeye yardımcı olur.

Sistem TTID'yi, Choreographer etkinliğin onDraw() yöntemini çağırdığında ve bunu ilk kez çağırdığında belirler. Ancak, her uygulama farklı davrandığından sistem TTFD'yi ne zaman belirleyeceğini bilemez. TTFD'yi belirlemek için uygulamanın, tamamen çizilmiş durumuna ulaştığında sisteme sinyal vermesi gerekir.

TTFD Al

TTFD'yi bulmak için ComponentActivity öğesinin reportFullyDrawn() yöntemini çağırarak tamamen çizilmiş durumu bildirin. reportFullyDrawn yöntemi, uygulama tamamen çizildiğinde ve kullanılabilir bir durumda olduğunda bunu bildirir. TTFD, sistemin uygulama başlatma niyetini alması ile reportFullyDrawn() çağrılması arasında geçen süredir. reportFullyDrawn() numaralı telefonu aramazsanız TTFD değeri raporlanmaz.

TTFD'yi ölçmek için kullanıcı arayüzünü ve tüm verileri tamamen çizdikten sonra reportFullyDrawn() yöntemini çağırın. İlk etkinlik penceresi ilk çizilmeden ve sistem tarafından ölçülen şekilde görüntülenmeden önce reportFullyDrawn() çağrısı yapmayın. Bu durumda sistem, sistemin ölçülen süresini bildirir. Diğer bir deyişle, sistem TTID'yi algılamadan önce reportFullyDrawn() yöntemini çağırırsanız sistem hem TTID'yi hem de TTFD'yi aynı değer olarak raporlar ve bu değer, TTID değeridir.

reportFullyDrawn() kullanıldığında Logcat, TTFD'nin 1s54 ms olduğu aşağıdaki örneğe benzer bir çıkış görüntüler:

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

Logcat çıkışı, bazen İlk gösterime kadar geçen süre konusunda açıklandığı gibi bir total süresi içerir.

Görüntüleme süreleriniz istediğinizden daha yavaşsa başlatma işlemindeki darboğazları tespit etmeyi deneyebilirsiniz.

Tam çizilmiş durumun elde edildiğini bildiğiniz temel durumlarda tam çizim durumunu bildirmek için reportFullyDrawn() kullanabilirsiniz. Bununla birlikte, arka plan iş parçacıklarının tam olarak çizilen duruma ulaşmadan önce arka plan çalışmasını tamamlaması gerektiği durumlarda, daha doğru bir TTFD ölçümü için reportFullyDrawn() işlemini geciktirmeniz gerekir. reportFullyDrawn() öğesini nasıl geciktireceğinizi öğrenmek için aşağıdaki bölümü inceleyin.

Başlatma zamanlaması doğruluğunu iyileştirin

Uygulamanız geç yükleme yapıyorsa ve ilk ekran, uygulamanızın ağdan resim getirmesi gibi tüm kaynakları içermiyorsa, liste nüfusunu karşılaştırma zamanlamanızın bir parçası olarak dahil edebilmek için reportFullyDrawn çağrısını uygulamanız kullanılabilir hale gelene kadar ertelemek isteyebilirsiniz.

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

Liste nüfusunu karşılaştırma zamanlamanıza dahil etmek için getFullyDrawnReporter() kullanarak FullyDrawnReporter alın ve uygulama kodunuza bir raporlayıcı ekleyin. Arka plan görevi listenin doldurulması tamamlandıktan sonra muhabiri serbest bırakın.

FullyDrawnReporter, eklenen tüm bildirenler serbest bırakılıncaya kadar reportFullyDrawn() yöntemini çağırmaz. Arka plan işlemi tamamlanana kadar bir rapor oluşturucu eklediğinizde, zamanlamalar başlangıç zamanlama verilerindeki listeyi doldurmak için gereken süreyi de içerir. Bu, uygulamanın kullanıcı için davranışını değiştirmez ancak zamanlama başlangıç verilerinin, listeyi doldurmak için gereken süreyi içermesini sağlar. Sıradan bağımsız olarak tüm görevler tamamlanana kadar reportFullyDrawn() çağrılmaz.

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

Kotlin

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 {
                lifecycleScope.launch(Dispatchers.IO) {
                    fullyDrawnReporter.addReporter()

                    // Perform the background operation.

                    fullyDrawnReporter.removeReporter()
                }
                lifecycleScope.launch(Dispatchers.IO) {
                    fullyDrawnReporter.addReporter()

                    // Perform the background operation.

                    fullyDrawnReporter.removeReporter()
                }
            }
        }
    }
}

Java

public class MainActivity extends ComponentActivity {
    private FullyDrawnReporter fullyDrawnReporter;

    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        fullyDrawnReporter = getFullyDrawnReporter();
        fullyDrawnReporter.addOnReportDrawnListener(() -> {
            // Trigger the UI update.
            return Unit.INSTANCE;
        });

        new Thread(new Runnable() {
            @Override
            public void run() {
                fullyDrawnReporter.addReporter();

                // Do the background work.

               fullyDrawnReporter.removeReporter();
            }
        }).start();
        new Thread(new Runnable() {
            @Override
            public void run() {
                fullyDrawnReporter.addReporter();

                // Do the background work.

                fullyDrawnReporter.removeReporter();
            }
        }).start();
    }
}

Uygulamanız Jetpack Compose'u kullanıyorsa tam olarak çizilmiş durumu belirtmek için aşağıdaki API'leri kullanabilirsiniz:

  • ReportDrawn: composable'ın etkileşim için hemen hazır olduğunu gösterir.
  • ReportDrawnWhen: composable'ınızın etkileşim için ne zaman 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.
Performans sorunlarını belirleyin

Performans sorunlarını tespit etmek için Android Studio CPU Profiler'ı kullanabilirsiniz. Daha fazla bilgi için CPU Profiler ile CPU etkinliğini inceleme bölümüne bakın.

Ayrıca, uygulamalarınızın ve etkinliklerinizin onCreate() yöntemlerinin içindeki satır içi izlemeyi kullanarak olası performans sorunları hakkında da bilgi edinebilirsiniz. Satır içi izleme hakkında bilgi edinmek için Trace işlevleri belgelerine ve sistem izlemeye genel bakış bölümüne bakın.

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

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

Uygulamaları yoğun şekilde başlatma

Kodunuz Application nesnesini geçersiz kılıp bu nesneyi başlatırken yoğun iş 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ştirirse uygulamanız başlatma sırasında zaman kaybına neden olabilir.

Uygulama bir amaca yanıt olarak başlatıldığında ana etkinliğin durum bilgilerinin ilk kullanıma hazırlanması gibi bazı başlatma işlemleri tamamen gereksiz olabilir. Uygulama, önceden başlatılmış durum verilerinin yalnızca bir alt kümesini belirli bir amaçla kullanır.

Uygulamanın ilk kullanıma hazırlanması sırasında karşılaşılan diğer zorluklar arasında etkili veya çok sayıda atık toplama etkinlikleri ya da başlatma işlemiyle eş zamanlı olarak gerçekleşen çöp G/Ç etkinlikleri sayılabilir. Bu durum başlatma işlemini daha da zorlaştırır. Atık toplama özellikle Dalvik çalışma zamanında önemli bir unsurdur. Android Çalışma Zamanı (ART), atık toplama işlemini eşzamanlı olarak gerçekleştirerek işlemin etkisini en aza indirir.

Sorunu teşhis edin

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

Yöntem izleme

CPU Profiler çalıştırıldığında callApplicationOnCreate() yönteminin sonunda com.example.customApplication.onCreate yönteminizi çağırdığı görülür. Araç bu yöntemlerin yürütülmesinin uzun sürdüğünü gösterirse orada hangi çalışmaların gerçekleştiğini görmek için daha fazla araştırma yapın.

Satır içi izleme

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

  • Uygulamanızın ilk onCreate() işlevi.
  • Uygulamanızın başlatıldığı genel tekil nesneler.
  • Performans sorunu sırasında meydana gelebilecek herhangi bir disk G/Ç, serileştirme işlemi veya sıkı döngüler.

Soruna çözümler

Gereksiz başlatmalardan veya disk G/Ç'sinden kaynaklanan bir sorunun çözümü, geç başlatmadır. Diğer bir deyişle, yalnızca hemen gerekli olan nesneleri başlatın. Genel statik nesneler oluşturmak yerine, uygulamanın nesneleri yalnızca ilk kez ihtiyaç duyduğunda başlattığı bir tekli kalıbına geçin.

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

Uygulamanız, başlangıçta uygulama bileşenlerini ilk kullanıma hazırlamak için içerik sağlayıcıları kullanıyorsa bunun yerine Uygulama Başlangıç kitaplığını kullanmayı düşünün.

Ağır etkinlik başlatma

Etkinlik oluşturmak genellikle çok fazla zahmetli iş gerektirir. Genellikle performans iyileştirmeleri elde etmek için bu çalışmaları optimize etme fırsatları vardır. Bu tür yaygın sorunlardan bazıları şunlardır:

  • Büyük veya karmaşık düzenleri şişirme.
  • Disk veya ağ G/Ç üzerinde ekran çizimi engelleniyor.
  • Bit eşlemleri yükleme ve kodlarını çözme.
  • VectorDrawable nesnelerini pikselleştirme.
  • Etkinliğin diğer alt sistemlerinin başlatılması.

Sorunu teşhis edin

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 kurucularına ve com.example.customApplication.onCreate() yöntemlerine dikkat edin.

Araç bu yöntemlerin uygulanmasının uzun sürdüğünü gösterirse orada hangi çalışmaların gerçekleştiğini görmek için daha fazla araştırma yapın.

Satır içi izleme

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

  • Uygulamanızın ilk onCreate() işlevi.
  • Başlattığı genel tekil nesneler.
  • Performans sorunu sırasında meydana gelebilecek herhangi bir disk G/Ç, serileştirme işlemi veya sıkı döngüler.

Soruna çözümler

Birçok olası performans sorunu vardır, ancak yaygın olarak karşılaşılan iki sorun ve çözümü şunlardır:

  • Görünüm hiyerarşiniz ne kadar genişse uygulamanın bunu genişletmesi için gereken süre de o kadar fazladır. Bu sorunu gidermek için atabileceğiniz iki adım aşağıda verilmiştir:
    • Gereksiz veya iç içe yerleştirilmiş düzenleri azaltarak görünüm hiyerarşinizi düzleştirin.
    • Başlatma sırasında görünür olması gerekmeyen kullanıcı arayüzü bölümlerini şişirmeyin. Bunun yerine, uygulamanın daha uygun bir zamanda oluşturabileceği alt hiyerarşiler için yer tutucu olarak bir ViewStub nesnesi kullanın.
  • Tüm kaynak başlatma işlemlerinizin ana iş parçacığında olması da başlatmayı yavaşlatabilir. Bu sorunu aşağıdaki şekilde çözebilirsiniz:
    • Uygulamanın bu işlemi farklı bir iş parçacığında geç yürütebilmesi için tüm kaynak başlatma işlemlerini taşıyın.
    • Uygulamanın, görünümlerinizi yükleyip göstermesine ve ardından bit eşlemlere ve diğer kaynaklara bağlı görsel özellikleri güncellemesine izin verin.

Özel başlangıç ekranları

Daha önce Android 11 (API düzeyi 30) veya önceki sürümlerde özel başlangıç ekranı uygulamak için 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 kullanma.
  • Özel bir Activity kullanılıyor.

Android 12'den itibaren SplashScreen API'ye geçiş yapmak zorunludur. Bu API daha hızlı bir başlatma süresi sağlar ve başlangıç ekranınızda aşağıdaki şekillerde değişiklik yapmanıza olanak tanır:

Ayrıca uyumlu kitaplığı, geriye dönük uyumluluğu sağlamak ve tüm Android sürümlerinde başlangıç ekranı görünümü için tutarlı bir görünüm ve tarz oluşturmak üzere SplashScreen API'yi geri bağlantılandırır.

Ayrıntılar için Başlangıç ekranı taşıma rehberine bakın.