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ü deneyimler, kullanıcının Play Store'da uygulamanıza düşük puan vermesine, hatta uygulamanızı tamamen bırakmasına neden olabilir.
Bu sayfada, uygulamanızın başlatma süresini optimize etmenize yardımcı olacak bilgiler yer alır. Bu bilgiler arasında, başlatma sürecinin dahili bileşenlerine genel bakış, başlatma performansının nasıl profilleneceği ve bazı yaygın başlangıç zamanı sorunları ile bunların nasıl çözüleceğine 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. Baştan başlatmada uygulamanız sıfırdan başlar. Diğer durumlarda sistemin, çalışan uygulamayı arka plandan ön plana getirmesi gerekir.
Her zaman soğuk başlatma varsayımına göre optimizasyon yapmanızı öneririz. Bu sayede, sıcak ve ılık başlatma performansını da artırabilirsiniz.
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şim kurduklarını anlamak faydalı olur.
Uygulama başlatma süresini belirlemek için iki önemli metrik vardır: ilk ekrana görüntülenene kadar geçen süre (TTID) ve tam ekrana görüntülenene kadar geçen süre (TTFD). TTID, ilk kareyi görüntülemek için gereken süredir. TTFD ise uygulamanın tamamen etkileşimli hale gelmesi için gereken süredir. Her ikisi de eşit derecede önemlidir. TTID, kullanıcıya uygulamanın yüklendiğini bildirir. TTFD ise uygulamanın gerçekten kullanılabilir olduğu zamandır. Bunlardan biri çok uzun sürerse kullanıcı, uygulamanız tam olarak yüklenmeden önce uygulamanızdan çıkabilir.
Sıfırdan başlatma
Baştan başlatma, bir uygulamanın sıfırdan başlatılmasıdır. Yani bu başlangıca kadar sistemin işlemi, uygulamanın işlemini oluşturur. Baştan başlatmalar, cihazın açılmasından veya sistemin uygulamayı sonlandırmasından sonra uygulamanızın ilk kez başlatılması gibi durumlarda gerçekleşir.
Bu tür bir başlatma, başlatma süresini en aza indirme konusunda en büyük zorluğu sunar. Çünkü sistem ve uygulamanın diğer başlatma durumlarına göre daha fazla iş yapması gerekir.
Baştan başlatma işleminin başında sistemin aşağıdaki üç görevi vardır:
- Uygulamayı yükleyip başlatın.
- Uygulama başlatıldıktan hemen sonra boş bir başlangıç penceresi gösterilmesi
- Uygulama sürecini oluşturun.
Sistem, uygulama sürecini oluşturur oluşturmaz uygulama süreci sonraki aşamalardan sorumludur:
- Uygulama nesnesini oluşturun.
- Ana iş parçacığını başlatın.
- Ana etkinliği oluşturun.
- Kullanıcı arayüzünü başlatın.
- Kullanıcı arayüzünü ekrana ç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.
Performans sorunları, uygulamanın ve ana makine etkinliğinin oluşturulması sırasında ortaya çıkabilir.
Uygulama oluşturma
Uygulamanız başlatıldığında, sistem uygulamanın ilk kez çizimini tamamlayana kadar boş başlangıç penceresi ekranda kalır. Bu noktada sistem işlemi, başlangıç penceresini uygulamanızla değiştirerek kullanıcının uygulamayla etkileşime geçmesine olanak tanır.
Kendi uygulamanızda Application.onCreate yöntemini 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şturmakla görevlendirir.
Bu noktadan sonra sistem ve uygulama düzeyindeki işlemler, uygulama yaşam döngüsü aşamalarına göre ilerler.
Etkinlik oluşturma
Uygulama işlemi etkinliğinizi oluşturduktan sonra etkinlik aşağıdaki işlemleri gerçekleştirir:
- Değerleri başlatır.
- Yapıcıları çağırır.
- Etkinliğin mevcut yaşam döngüsü durumuna uygun olan
Activity.onCreategibi 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 oluşturmadan kaynaklanır. Bu durum, uygulamanız setContent yöntemini çağırıp ü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 ağır hesaplamalar yapan composable'lar bu oluşturma süresini artırabilir.
Hazır durumda başlatma
Hazır durumda başlatma, soğuk 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. Sıcak başlatma olarak kabul edilebilecek birçok olası durum vardır. Örneğin:
Kullanıcı uygulamanızdan çıkıp uygulamayı yeniden başlatır. İşlem çalışmaya devam edebilir ancak uygulamanın,
onCreateçağrısını kullanarak etkinliği sıfırdan yeniden 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,
onCreateyöntemine iletilen kaydedilmiş örnek durumu paketinden bir miktar yararlanabilir.
Sıcak başlatma
Uygulamanızın çalışır durumda başlatılması, baştan başlatmaya kıyasla daha az ek yük oluşturur. Sıcak başlatmada sistem, uygulamanızın ana makine etkinliğini ön plana getirir. Uygulamanızın kullanıcı arayüzünün tamamı hâlâ bellekteyse uygulama; nesne başlatma, kullanıcı arayüzü başlatma ve oluşturma işlemlerini tekrarlamaktan kaçınabilir.
Ancak bellek kırpma etkinliklerine (ör. onTrimMemory) yanıt olarak bir miktar bellek temizlenirse bu nesnelerin sıcak başlatma etkinliğine yanıt olarak yeniden oluşturulması gerekir.
Çalışır durumda başlatma, baştan başlatma senaryosuyla aynı ekran davranışını gösterir. Sistem işlemi, uygulama etkinliği oluşturmayı tamamlayana kadar boş bir ekran gösterir.
Perfetto'da uygulama başlatmayı tanımlama
Uygulama başlatma sorunlarını gidermek için uygulama başlatma aşamasına tam olarak nelerin dahil olduğunu belirlemek faydalıdır. Perfetto'da uygulama başlatma aşamasının tamamını belirlemek için aşağıdaki adımları uygulayın:
Perfetto'da, Android Uygulama Başlatmaları türetilmiş metriğini içeren satırı bulun. Bunu görmüyorsanız cihaz üzerinde sistem izleme uygulamasını kullanarak iz yakalamayı deneyin.
Şekil 2. Perfetto'da Android Uygulama Başlatma İşlemleri türetilmiş metrik dilimi. İlişkili dilimi tıklayın ve dilimi seçmek için m tuşuna basın. Dilimin etrafında parantezler görünür ve dilimin ne kadar sürdüğünü gösterir. Süre, Geçerli seçim sekmesinde de gösterilir.
İşaretçiyi satırın üzerine getirdiğinizde görünen sabitleme simgesini tıklayarak Android Uygulaması Girişimleri satırını sabitleyin.
Söz konusu uygulamanın bulunduğu satıra gidin ve satırı genişletmek için ilk hücreyi tıklayın.
w tuşuna basarak genellikle en üstte bulunan ana ileti dizisini yakınlaştırın (uzaklaştırmak, sola gitmek ve sağa gitmek için sırasıyla s, a, d tuşlarına basın).
Şekil 3. Uygulamanın ana iş parçacığının yanında Android Uygulama Başlatma türetilmiş metrik dilimi. Türetilmiş metrikler dilimi, uygulama başlatma işlemine tam olarak nelerin dahil edildiğini görmeyi kolaylaştırır. Böylece daha ayrıntılı bir şekilde hata ayıklamaya devam edebilirsiniz.
Jetpack Compose uygulamasını analiz ederken kullanıcı arayüzünüzün performansıyla ilgili ayrıntılı bilgileri görmek için oluşturma izleme özelliğini kullanabilirsiniz.
Ana ileti dizisinde Choreographer#doFrame ile başlayan iz bölümlerine özellikle dikkat edin. Compose:recompose, Compose:layout ve Compose:draw gibi dilimlere bakın. 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 sürelerini 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 takip edebilirsiniz. Android, uygulamanızda sorun olduğunu göstermek ve sorunu teşhis etmenize yardımcı olmak için çeşitli yöntemler sunar.
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şlemlerini optimize etmek amacıyla kodu verimli bir şekilde önceden derlemek için bu metriklerdeki verileri kullanır.
Daha hızlı başlatma, uygulamanızla daha uzun süreli kullanıcı etkileşimi sağlar. Bu da erken çıkış, örneği yeniden başlatma veya farklı bir uygulamaya geçme durumlarını azaltır.
İlk ekrana görüntülenene kadar geçen süre
İlk görüntüleme süresi (TTID), uygulamanın kullanıcı arayüzünün ilk karesinin gösterilmesi için gereken süredir. Bu metrik, uygulamanın ilk karesini oluşturması için geçen süreyi ölçer. Bu süreye soğuk başlatma sırasında işlem başlatma, soğuk veya sıcak başlatma sırasında etkinlik oluşturma ve ilk kareyi görüntüleme 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örmesini sağlayarak kullanıcı deneyimini iyileştirmeye yardımcı olur. TTID, Android Framework tarafından her uygulama için otomatik olarak raporlanır. Uygulama başlatma için optimizasyon yaparken TTFD'ye kadar bilgi almak için reportFullyDrawn uygulamanızı öneririz.
TTID, aşağıdaki olay dizisini içeren toplam geçen süreyi temsil eden bir zaman değeri olarak ölçülür:
- Süreci başlatma
- Nesneler başlatılıyor.
- Ana makine etkinliği oluşturuluyor ve başlatılıyor.
- Kullanıcı arayüzü başlatılıyor.
- Uygulama ilk kez çiziliyor.
TTID'yi alma
TTID'yi bulmak için Logcat komut satırı aracında Displayed adlı değeri içeren bir çıkış satırı arayın. Bu değer TTID'dir ve aşağıdaki örneğe benzer. Bu örnekte TTID 3 sn 534 ms'dir:
ActivityManager: Displayed com.android.myexample/.StartupTiming: +3s534ms
Android Studio'da TTID'yi bulmak için Logcat görünümünüzdeki filtreleri açılır filtre menüsünden devre dışı bırakın ve ardından Şekil 4'te gösterildiği gibi Displayed süresini bulun.
Bu günlüğü uygulamanın kendisi değil, sistem sunucusu yayınladığı için filtrelerin devre dışı bırakılması gerekir.
Displayed değeri devre dışı bırakıldı.Logcat çıkışındaki Displayed metriği, tüm kaynaklar yüklenip görüntülenene kadar geçen süreyi her zaman yakalamaz. İlk oluşturmada 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ı hariç tutar. Bu kaynakların yüklenmesi satır içi bir işlem olduğundan ve uygulamanın ilk görüntülenmesini engellemediğinden bu kaynaklar hariç tutulur.
Kaynaklar hakkında daha fazla bilgi için Compose'daki kaynaklar bölümüne bakın.
Bazen Logcat çıkışındaki Displayed satırı, toplam süre için ek bir alan içerir. Örneğin:
ActivityManager: Displayed com.android.myexample/.StartupTiming: +3s534ms (total +1m22s643ms)
Bu durumda, ilk kez ölçüm yalnızca ilk çizilen etkinlik (genellikle ana etkinlik) için yapılır. total zaman ölçümü, uygulama işleminin başlangıcı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 kabuk etkinlik yöneticisi komutuyla ç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 daha önce olduğu 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örüntüleme süresi
Tam görüntüleme süresi (TTFD), bir uygulamanın kullanıcı için etkileşimli hale gelmesi için geçen süredir. Uygulamanın kullanıcı arayüzünün ilk karesinin ve ilk kare gösterildikten sonra eşzamansız olarak yüklenen içeriğin gösterilmesi için geçen süre olarak raporlanır. Genellikle bu, uygulama tarafından bildirildiği üzere 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 gereken süreyi de içerir. Uygulamanızın TTFD değerini 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, ana makine penceresi ilk karesini oluşturduğunda TTID'yi belirleyebilir ancak TTFD'yi otomatik olarak belirleyemez. Uygulamalar genellikle birincil içeriklerini eşzamansız olarak yüklediğinden, sistem uygulamanın kullanıcı için ne zaman tam olarak kullanılabilir olduğunu bilemez. TTFD'yi belirlemek için uygulamanın, tamamen çizilmiş duruma ulaştığında sisteme sinyal göndermesi gerekir.
TTFD'yi alma
TTFD'yi bulmak için ComponentActivity sınıfının reportFullyDrawn yöntemini çağırarak tamamen çizilmiş durumu bildirin. reportFullyDrawn yöntemi, uygulamanın tamamen çizildiği ve kullanılabilir durumda olduğu zamanı bildirir. TTFD, sistemin uygulama başlatma intent'ini aldığı andan reportFullyDrawn çağrılana kadar geçen süredir. reportFullyDrawn yöntemini ç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 yöntemini çağırın. İlk etkinliğin penceresi ilk kez çizilip sistem tarafından ölçüldüğü şekilde gösterilmeden önce reportFullyDrawn yöntemini çağırmayın. Aksi takdirde sistem, sistem tarafından ölçülen süreyi bildirir. Başka bir deyişle, sistem TTID'yi algılamadan önce reportFullyDrawn yöntemini çağırırsanız sistem hem TTID hem de TTFD'yi aynı değer olarak bildirir ve bu değer TTID değeridir.
reportFullyDrawn kullandığınızda Logcat, aşağıdaki örnekte olduğu gibi TTFD'nin 1 sn 54 ms olduğu bir çıkış gösterir:
system_process I/ActivityManager: Fully drawn {package}/.MainActivity: +1s54ms
Logcat çıkışı bazen İlk görüntüleme süresi bölümünde ele alınan total süresini içerir.
Görüntüleme süreleriniz istediğinizden daha yavaşsa başlatma sürecindeki sorunları belirlemeye çalışabilirsiniz.
Tam çizilmiş durumun elde edildiğini bildiğiniz temel durumlarda tam çizilmiş durumu belirtmek için reportFullyDrawn kullanabilirsiniz. Ancak arka plan iş parçacıklarının, tam çizim durumuna ulaşılmadan önce arka plan çalışmasını tamamlaması gereken durumlarda daha doğru bir TTFD ölçümü için reportFullyDrawn yöntemini geciktirmeniz gerekir. reportFullyDrawn'i nasıl erteleyeceğinizi öğrenmek için aşağıdaki bölüme bakın.
Başlatma zamanlamasının doğruluğunu artırma
Uygulamanız geç yükleme yapıyorsa ve ilk ekranda tüm kaynaklar yer almıyorsa (ör. uygulamanız ağdan resim getiriyorsa) liste doldurma işlemini karşılaştırma zamanlamanıza dahil edebilmek için uygulamanız kullanılabilir hale gelene kadar reportFullyDrawn çağrısını geciktirebilirsiniz.
Örneğin, kullanıcı arayüzünde LazyColumn veya LazyRow gibi dinamik bir liste varsa bu liste, liste ilk kez çizildikten ve dolayısıyla kullanıcı arayüzü tamamen çizildi olarak işaretlendikten sonra tamamlanan bir arka plan görevi tarafından 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 değerini alın ve uygulama kodunuza bir raporlayıcı ekleyin. Arka plan görevi listeyi doldurmayı tamamladıktan sonra raporlayıcıyı serbest bırakın.
FullyDrawnReporter, eklenen tüm raporlayıcılar serbest bırakılana kadar reportFullyDrawn yöntemini çağırmaz. Bir raporlayıcı ekleyip arka plan işlemi tamamlanana kadar yayınlamayarak, uygulamanın kullanıcıya yönelik davranışını değiştirmeden başlangıç zamanlaması verilerinin liste doldurma süresini içermesini sağlarsınız. reportFullyDrawn, sıradan bağımsız olarak tüm görevler tamamlanana kadar çağrılmaz.
Uygulamanız Jetpack Compose kullanıyorsa tamamen çizilmiş durumu belirtmek için aşağıdaki API'leri kullanabilirsiniz:
ReportDrawn: Oluşturulabilir öğenizin etkileşime hemen hazır olduğunu gösterir.ReportDrawnWhen: composable öğenizin ne zaman etkileşime hazır olduğunu belirtmek içinlist.count > 0gibi 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ı kaydeden birden fazla arka plan görevini aynı anda 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 aracılığıyla olası darboğazlar hakkında bilgi edinebilirsiniz. Satır içi izleme hakkında bilgi edinmek için Trace işlevleriyle ilgili belgelere ve sistem izlemeye genel bakış bölümüne 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ı ve ekranların yüklenmesiyle ilgilidir.
Uygulama başlatma işlemi çok uzun sürüyor.
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şlatma işlemleri tamamen gereksiz olabilir. Örneğin, uygulama aslında bir amaca yanıt olarak başlatıldığında ana etkinliğin durum bilgilerini başlatmak gibi. Uygulama, intent ile daha önce başlatılan durum verilerinin yalnızca bir alt kümesini kullanır.
Uygulama başlatma sırasındaki 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 ve başlatma işlemini daha da engelleyen disk G/Ç işlemleri yer alır. Çöp toplama, özellikle Dalvik çalışma zamanında dikkate alınması gereken bir konudur. Android Çalışma Zamanı (ART), çöp toplama işlemini 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ırdığınızda callApplicationOnCreate yönteminin sonunda com.example.customApplication.onCreate yönteminizi çağırdığını görürsünüz. Araç, bu yöntemlerin yürütülmesinin uzun sürdüğünü gösteriyorsa daha ayrıntılı inceleme yaparak hangi işlemlerin gerçekleştiğini kontrol edin.
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
onCreateişlevi. - Uygulamanızın başlattığı tüm global tekil nesneler.
- Darboğaz sırasında gerçekleşebilecek disk G/Ç, serileştirme veya sıkı döngüler.
Sorunun çözümleri
Sorun ister gereksiz başlatmalardan ister disk G/Ç'den kaynaklansın, çözüm geç başlatmadır. Başka bir deyişle, yalnızca hemen ihtiyaç duyulan nesneleri ilk kullanıma hazırlayın. Global statik nesneler oluşturmak yerine, uygulamanın nesneleri yalnızca ilk kez ihtiyaç duyduğunda başlattığı bir singleton 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 kullanabilirsiniz.
Uygulamanız, başlangıçta uygulama bileşenlerini başlatmak için içerik sağlayıcıları kullanıyorsa bunun yerine App Startup kitaplığını kullanabilirsiniz.
Yoğun etkinlik başlatma
Etkinlik oluşturma genellikle çok fazla ek yük gerektiren bir iştir. Genellikle, performans iyileştirmeleri elde etmek için bu çalışmayı optimize etme 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.
- Oluşturulabilir öğelerde yoğun başlatma.
- Diskte veya ağ G/Ç'sinde ekran çizimini engelleme.
- Bitmap'leri yükleme ve kodlarını çözme
VectorDrawablenesne rasterleştiriliyor.- Uygulamanın ana makine 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 işlemler yapıldığını görmek için daha ayrıntılı 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
onCreateişlevi. - Başlattığı tüm genel tekil nesneler.
- Darboğaz sırasında gerçekleşebilecek disk G/Ç, serileştirme veya sıkı döngüler.
Sorunun çözümleri
Birçok potansiyel darboğaz vardır ancak yaygın olarak karşılaşılan iki sorun ve çözümleri şunlardır:
- Kullanıcı arayüzü hiyerarşiniz ne kadar büyükse uygulamanın hiyerarşiyi 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şturma işlemlerinden kaçının.
- Kritik olmayan kullanıcı arayüzü bileşenlerinin oluşturulmasını erteleyin.
- Tüm kaynak başlatma işlemlerinizin ana iş parçacığında olması da başlatma işlemini yavaşlatabilir. Bu sorunu şu şekilde çözebilirsiniz:
- Uygulamanın farklı bir iş parçacığında geç başlatma gerçekleştirebilmesi için tüm kaynak başlatma işlemlerini 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 (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 fazladan süre eklendiğini görebilirsiniz:
- Başlatma sırasında sistem tarafından çizilen ilk boş ekranı kapatmak için
windowDisablePreviewtema özelliğini kullanma. - Özel bir
Activitykullanma.
Android 12'den itibaren SplashScreen API'sine geçiş yapılması gerekir.
Bu API, daha hızlı bir başlangıç süresi sağlar ve başlangıç ekranınızı aşağıdaki şekillerde ayarlamanıza olanak tanır:
- Başlangıç ekranının görünümünü değiştirmek için tema ayarlayın.
- Başlangıç ekranının ne kadar süreyle gösterileceğini
windowSplashScreenAnimationDurationile kontrol edin. - Başlangıç ekranı animasyonunu özelleştirin ve başlangıç ekranını kapatma animasyonunu düzgün bir şekilde işleyin.
Ayrıca uyumluluk kitaplığı, geriye dönük uyumluluğu etkinleştirmek 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 amacıyla SplashScreen API'yi destekler.
Ayrıntılar için Başlangıç ekranı geçiş rehberine bakın.
Sizin için önerilenler
- Not: JavaScript devre dışı bırakıldığında bağlantı metni gösterilir.
- Yavaş oluşturma
- Macrobenchmark metriklerini yakalama
- Temel profil oluşturma{:#creating-profile-rules}