初始化性能問題
我們都知道Dagger 2是一個優(yōu)化得很好的依賴注入框架。但是即使有這些全部的微優(yōu)化，仍然在依賴注入的時(shí)候存在可能的性能問題 - “笨重”的第三方庫和/或我們那些主線程阻塞的代碼。
依賴注入是在盡可能短的時(shí)間內(nèi)在正確的地方傳遞所請求的依賴的過程 - 這些都是Dagger 2做得很好的。但是DI也會去創(chuàng)建各種依賴。如果我們需要花費(fèi)幾百毫秒創(chuàng)建它們，那么以納秒級的時(shí)間去提供依賴還有什么意義呢？
當(dāng)我們的app創(chuàng)建了一系列繁重的單例并立即由Dagger2提供服務(wù)之后也許可能沒有這么重要。但是在我們創(chuàng)建它們的時(shí)候仍然需要一個時(shí)間成本 - 大多數(shù)情況下決定了app啟動的時(shí)間。
這問題（已經(jīng)給了提示怎么去調(diào)適它）已經(jīng)在我之前的一篇博客中描述地很詳細(xì)了：Dagger 2 - graph creation performance。
在很短的時(shí)間內(nèi)，讓我們想象這么一個場景 - 你的app有一個初始化的界面（SplashScreen），需要在app啟動后立即做一些需要的事情：
初始化所有tracking libs（Goole Analytics, Crashlytics）然后發(fā)送第一份數(shù)據(jù)給它們。
創(chuàng)建用于API和/或數(shù)據(jù)庫通信的整個棧。
我們試圖的交互邏輯（MVP中的Presenters，MVVM中的ViewModels等等）。
即使我們的代碼是優(yōu)化地非常好的，但是仍然有可能有些額外的庫需要幾十或者幾百毫秒的時(shí)間來初始化。在我們啟動界面之前將展示必須初始化和交付的所有請求的依賴（和它們的依賴）。這意味著啟動時(shí)間將會是它們每一個初始化時(shí)間的總和。
由 AndroidDevMetrics 測量的示例堆?？赡苋缦滤荆?/p>
