小編給大家分享一下Android LeakCanary檢測內存泄露原理是什么，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！
以LeakCanary2.6源碼分析LeakCanary檢測內存泄露原理，為減少篇幅長度，突出關鍵點，不粘貼大量源碼，閱讀時需搭配源碼食用。
LeakCanary只需引入依賴，不需要初始化代碼，就能執行內存泄漏檢測了，它是通過ContentProvider獲取應用的context。這種獲取context方式在開源第三方庫中十分流行。如下AppWatcherInstaller在LeakCanary的aar包中manifest文件中注冊。
internal sealed class AppWatcherInstaller : ContentProvider() {
override fun onCreate(): Boolean {
val application = context!!.applicationContext as Application
AppWatcher.manualInstall(application)//1
return true
}
...
}（1）處的方法將調用如下方法注冊需要檢測泄露的對象：
fun appDefaultWatchers(
application: Application,
reachabilityWatcher: ReachabilityWatcher = objectWatcher
): List<InstallableWatcher> {
return listOf(
ActivityWatcher(application, reachabilityWatcher),
FragmentAndViewModelWatcher(application, reachabilityWatcher),
RootViewWatcher(reachabilityWatcher),
ServiceWatcher(reachabilityWatcher)
)
}可以看到LeakCanary會把Activity，Fragment，ViewModel，RootView和Service納入檢測，這些對象都是有明確的生命周期，而且占用內存較高，它們的內存泄露是需要我們重點關注的。
（1）處的manualInstall方法將遍歷調用上述Watcher的install方法以適時將這些生命周期對象納入檢測。
ActivityWatcher中install方法通過向application注冊Application.ActivityLifecycleCallbacks接口回調實現對Activity生命周期的檢測。這里有一個很棒的技巧，利用Kotlin委托與Java動態代理，將不需要關注的方法給出默認空實現，（2）（3）處代碼提取出來，可以在平時開發中有需求的地方使用。
//ActivityWatcher
private val lifecycleCallbacks =
object : Application.ActivityLifecycleCallbacks by noOpDelegate() {
override fun onActivityDestroyed(activity: Activity) {
reachabilityWatcher.expectWeaklyReachable(
activity, "${activity::class.java.name} received Activity#onDestroy() callback"
)//4
}
}
internal inline fun <reified T : Any> noOpDelegate(): T {
val javaClass = T::class.java
return Proxy.newProxyInstance(
javaClass.classLoader, arrayOf(javaClass), NO_OP_HANDLER
) as T
}//2
private val NO_OP_HANDLER = InvocationHandler { _, _, _ ->
// no op
}//3（4）調用的objectWatcher.expectWeaklyReachable方法是將對象納入監測的通用方法，如其名稱所示，WeaklyReachable相較的是StronglyReachable，當一個對象不再需要時，我們希望它從WeaklyReachable變為StronglyReachable。
我們可以在不再需要某對象時主動調用該方法，檢測任意對象（除上節的默認對象）的內存泄露：
AppWatcher.objectWatcher.expectWeaklyReachable(obj, "")
onActivityDestroyed回調中就通過該方式將activity納入監測。
通過上述對Activity的納入內存泄露源碼的分析，可以發現其中2個關鍵點，首先需要能獲取應用中所有待檢測對象的引用，其次需要一個待檢測對象生命周期結束的時機。而這兩點通過注冊Application.ActivityLifecycleCallbacks接口能夠同時滿足，可對于其他類對象，就沒有如此便捷的方式了。
下面介紹Fragment，ViewModel，RootView和Service這些類對象是如何納入檢測的。
Fragment為了兼容在Android源碼中幾個不同包名的實現，對它們的檢測也需要分別實現，我們在FragmentAndViewModelWatcher中只關注AndroidXFragmentDestroyWatcher對AndroidX中Fragment的內存泄露檢測即可，其他幾個實現類似。
FragmentAndViewModelWatcher先同樣通過注冊Application.ActivityLifecycleCallbacks回調，適時獲取Activity引用，并在AndroidXFragmentDestroyWatcher獲取Activity的supportFragmentManager，向其注冊FragmentManager.FragmentLifecycleCallbacks。在其中的onFragmentDestroyed與onFragmentViewDestroyed回調中將Fragment和Fragment的View納入內存泄露檢測。
對于ViewModel的檢測，則需要關注ViewModelClearedWatcher，通過用上一步獲取的Activity引用，添加名為ViewModelClearedWatcher的spy ViewModel，來獲得收到onCleared回調的能力，因為對于一個ViewModelStoreOwner（Activity，Fragment）來說，自己的一個ViewModel回調了onCleared，則其他ViewModel的onCleared也應該被調用。這些ViewModel是通過ViewModelStore的mMap屬性反射獲取的。在spy ViewModel的onCleared回調中，納入內存泄露檢測。
對于Android里Window中的RootView，即DecorView，可以通過注冊addOnAttachStateChangeListener在View的onViewDetachedFromWindow時進行檢測。而獲取待檢測對象的引用就不像Activity和Fragment一樣有回調可以依賴了。LeakCanary采取了Hook的方式在install方法對RootView的容器進行替換，具體來說就是通過反射機制將WindowManagerGlobal中的mViews（包含所有Window中的DecorView）的ArrayList容器的實現修改，在其add方法中獲取DecorView的引用，之后設置OnAttachStateChangeListener回調進行檢測。
而Android中Service，無論是獲取引用還是監測時機的確定都沒有系統的回調可以依賴，LeakCanary都是采用Hook的方式達到目的。首先通過反射拿到ActivityThread中的mServices，這是包含app中全部Service的一個Map。在install方法中有兩個Hook點，首先是Android 消息機制的中轉中心，名為H的Handler，系統側對應用側的全部回調都需要經過它的周轉。因為Handler中mCallback執行的優先級大于handleMessage方法，Leakcanary替換H的mCallback實現，當消息為STOP_SERVICE時，便從mServices取出該消息對應的Service作為待檢測Service引用。第二個Hook點為ActivityManagerService，通過動態代理修改它的serviceDoneExecuting方法，在其真正實現前增加內存泄露檢測，其余方法保持不變。
這些類納入檢測納入檢測的時機，可總結為如下表格：
| 如何獲取引用 | 何時納入監測 | |
|---|---|---|
| Activity | ActivityLifecycleCallbacks回調 | onActivityDestroyed |
| Fragment | FragmentLifecycleCallbacks回調 | onFragmentDestroyed |
| Fragment中的View | FragmentLifecycleCallbacks回調 | onFragmentViewDestroyed |
| ViewModel | 反射獲取ViewModelStore的mMap | spy ViewModel的onCleared |
| Window中的DecorView | Hook WindowManagerGlobal中的mViews | onViewDetachedFromWindow |
| Service | Hook H的mCallback實現，當消息為STOP_SERVICE時，從ActivityThread中的mServices獲取 | Hook ActivityManagerService，serviceDoneExecuting中檢測 |
在確定待檢測對象與時機后，查看ObjectWatcher的expectWeaklyReachable方法，可以得知如何實現將泄露對象從待檢測對象（默認即上節我們分析的那些有生命周期的類對象）挑出來的。確定內存泄露對象的原理是我們常用的WeakReference，其雙參數構造函數支持傳入一個ReferenceQueue，當其關聯的對象回收時，會將WeakReference加入ReferenceQueue中。LeakCanary的做法是繼承ReferenceQueue，增加一個值為UUID的屬性key，同時將每個需要監測的對象WeakReference以此UUID作為鍵加入一個map中。這樣，在GC過后，removeWeaklyReachableObjects方法通過遍歷ReferenceQueue，通過key值刪除map中已回收的對象，剩下的對象就基本可以確定發生了內存泄露。
在確定內存泄露的對象后，就需要其他手段來確定泄露對象引用鏈了，這一過程開始于checkRetainedObjects方法，跟蹤調用可以看到啟動了前臺服務HeapAnalyzerService，這在我們使用LeakCanary時可以在通知欄看到。服務中調用了HeapAnalyzer的analyze方法進行堆內存分析，由Shark庫實現該功能，就不再進行追蹤。
以上是“Android LeakCanary檢測內存泄露原理是什么”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
