Başlatma gecikmesini iyileştirme
Koleksiyonlar ile düzeninizi koruyun
İçeriği tercihlerinize göre kaydedin ve kategorilere ayırın.
Başlatma gecikmesi, günlük etkin kullanıcı sayısını korumak ve ilk etkileşimden itibaren sorunsuz bir kullanıcı deneyimi sağlamak için önemli bir metriktir. Bu durum, özellikle performanstan ödün verilebilen düşük RAM'li ortamlarda geçerlidir.
Ancak uygulama başlatma sürecini iyileştirmeye başlamadan önce, başlangıçtan sorumlu olan temel unsurları anlamak önemlidir.
En iyi uygulamalar
Temel Profil ile Gönderme
Temel Profiller, dahil edilen kod yolları için yorumlamadan ve sadece zamanında (JIT) derleme adımlarını atlayarak kod yürütme hızını ilk lansmandan itibaren yaklaşık% 30 artırır. Android Çalışma Zamanı (ART), uygulamada bir Referans Profil sunarak, dahil edilen kod yollarını Zamana Önde (AOT) derlemesi aracılığıyla optimize edebilir. Böylece, her yeni kullanıcı ve her uygulama güncellemesinde performans iyileştirmeleri sağlar.
Hızlıca başlatmaktan kaçının
Uygulamanızın başlangıç sırasında gerekli olmayabilecek yoğun işleri yapmaktan kaçının.
Uygulamanızın işlem başlatması ile ilgili en olası senaryo, uygulamanın başlatılmasıdır. Ancak WorkManager,
JobScheduler, BroadcastReceiver, bağlı hizmetler ve AndroidX başlangıç kitaplığı da arka planda uygulama işlemleri başlatabilir. Mümkünse Application sınıfınızda gereksiz işleri başlatmaktan kaçının. Pek çok kitaplıkta isteğe bağlı başlatma özelliği sunulur. Böylece sadece gerektiğinde çağırabilirsiniz.
Görevleri kullanıcı arayüzü ileti dizisinden arka plan ileti dizisine taşıyın
Daha uzun süren ve ana iş parçacığını engelleyen görevler varsa bunları bir arka plan iş parçacığına taşıyın veya verimliliği sağlamak için WorkManager'ı kullanın.
Uzun zaman dilimlerini kaplayan veya beklenenden daha fazla zaman alan işlemleri belirleyin. Bu görevleri optimize etmek, başlatma gecikmesini önemli ölçüde iyileştirmeye yardımcı olabilir.
Ciddi disk okuma anlaşmazlığını analiz etme ve düzeltme
StrictMode, kullanıcı arayüzü işlemlerinin alındığı ve animasyonların gerçekleştiği, uygulamanın ana iş parçacığında yanlışlıkla disk veya ağ erişimi kullanılmasını algılamaya yardımcı olabilen bir geliştirici aracıdır. Araç, iyileştirme yapılabilecek bir alan tespit ettiğinde uygulamayı otomatik olarak sonlandırabilir veya daha sonra, daha ayrıntılı inceleme için ihlali günlüğe kaydedebilirsiniz.
Eşzamanlı IPC'lerden kaçının
Uygulamanızın çalışmasındaki uzun duraklamalar genellikle Android'deki işlemler arası iletişim (IPC) mekanizması olan bağlayıcı çağrılarından kaynaklanır. Android'in son sürümlerinde, UI Thread'in çalışmayı durdurmasının en yaygın nedenlerinden biridir. Genellikle çözüm, bağlayıcı çağrıları yapan işlevleri çağırmaktan kaçınmaktır. Kaçınılmazsa değeri önbelleğe almanız veya çalışmayı arka plan iş parçacıklarına taşımanız gerekir. Daha fazla bilgi için İleti dizisi planlama gecikmeleri bölümünü inceleyin.
Bu sayfadaki içerik ve kod örnekleri, İçerik Lisansı sayfasında açıklanan lisanslara tabidir. Java ve OpenJDK, Oracle ve/veya satış ortaklarının tescilli ticari markasıdır.
Son güncelleme tarihi: 2025-07-27 UTC.
[[["Anlaması kolay","easyToUnderstand","thumb-up"],["Sorunumu çözdü","solvedMyProblem","thumb-up"],["Diğer","otherUp","thumb-up"]],[["İhtiyacım olan bilgiler yok","missingTheInformationINeed","thumb-down"],["Çok karmaşık / çok fazla adım var","tooComplicatedTooManySteps","thumb-down"],["Güncel değil","outOfDate","thumb-down"],["Çeviri sorunu","translationIssue","thumb-down"],["Örnek veya kod sorunu","samplesCodeIssue","thumb-down"],["Diğer","otherDown","thumb-down"]],["Son güncelleme tarihi: 2025-07-27 UTC."],[],[],null,["# Improve startup latency\n\nStartup latency is an important metric to retain daily active users and ensure\na seamless user experience from the first interaction. This is especially true\nin low-RAM environments where performance tradeoffs might be considered.\nHowever, before beginning to improve app startup, it's important to understand\nthe underlying aspects that contribute to startup itself.\n\nBest practices\n--------------\n\n### Ship with a Baseline Profile\n\nBaseline Profiles improve code execution speed by around 30% from the first\nlaunch by avoiding interpretation and\n[just-in-time (JIT)](/about/versions/nougat/android-7.0#jit_aot) compilation\nsteps for included code paths. By shipping a Baseline Profile in an app,\n[Android Runtime (ART)](https://source.android.com/docs/core/runtime)\ncan optimize included code paths through Ahead of Time (AOT) compilation,\nproviding performance enhancements for every new user and on every app update.\n\n### Avoid eager initialization\n\nAvoid doing eager work that may not be necessary in your app's startup sequence.\nThe most likely scenario for your app starting a process is through the\nlaunching of the app. However,\n[WorkManager](/reference/androidx/work/WorkManager),\n[JobScheduler](/reference/android/app/job/JobScheduler),\n[BroadcastReceiver](/reference/android/content/BroadcastReceiver), bound\nservices, and the [AndroidX startup library](/topic/libraries/app-startup)\ncan also start app processes in the background. If possible, avoid unnecessarily\ninitializing anything eagerly in your `Application` class. A lot of libraries\noffer on-demand initialization, which lets you invoke them only when necessary.\n\n### Move tasks from UI thread to background thread\n\nIf there are tasks that are taking longer and blocking the main thread, move\nthem to a background thread or use WorkManager to ensure efficiency.\nIdentify operations that occupy large time frames or consume more time\nthan expected. Optimizing these tasks can help drastically improve startup\nlatency.\n\n### Analyze and fix severe disk read contention\n\n[StrictMode](/reference/android/os/StrictMode) is a developer tool that can\nhelp detect the use of accidental disk or network access on the app's main\nthread, where UI operations are received and animations take place. Once the\ntool detects a possible area of improvement, you can automatically terminate\nthe app or log the violation for further inspection at a later time.\n\n### Avoid synchronous IPCs\n\nOften long pauses in your app's execution are caused by binder calls,\nthe inter-process communication (IPC) mechanism on Android. On recent versions\nof Android, it's one of the most common reasons for the UI Thread to stop\nrunning. Generally, the fix is to avoid calling functions that make binder\ncalls; if it's unavoidable, you should cache the value, or move work to\nbackground threads. For more information, see\n[Thread scheduling delays](/topic/performance/vitals/render#thread_scheduling_delays)."]]
