Android元件化和外掛化
元件化開發就是將一個app分成多個模組，每個模組都是一個元件（Module），開發的過程中我們可以讓這些元件相互依賴或者單獨除錯部分元件等，但是最終釋出的時候是將這些元件合併統一成一個apk
元件化優勢：
稍微改動一個模組的一點程式碼都要編譯整個工程，耗時耗力
公共資源、業務、模組混在一起耦合度太高，不方便測試
如何劃分元件：
1.新建一個lib元件，new Module—>Andorid Library，取名BaseUtilLib，我們將所有的公共的工具類、網路分裝等類放在其中
2.新建一個lib元件，BaseReslLib，我們將所有的公共資源、drawable、String等類放在其中
3.將app按照自己的規則劃分成多個模組，比如按業務按地區等都可以
4.逐一開發某個模組，比如Test模組，新建一個TestApp元件，TestApp元件引用[1][2]步驟的BaseUtilLib和BaseReslLib，在TestApp元件裡新增並引用TestLib元件。在TestLib的activity中寫程式碼寫業務邏輯，TestApp只負責跳轉和測試
5.將工程中的所有類似TestLib元件（不是TestApp元件）引入到工程的app中
外掛化開發和元件化開發略有不用，外掛化開發時將整個app拆分成很多模組，這些模組包括一個宿主和多個外掛，每個模組都是一個apk（元件化的每個模組是個lib），最終打包的時候將宿主apk和外掛apk分開或者聯合打包。外掛化：宿主和外掛分開編譯，併發開發，動態更新外掛，按需下載模組4.LeakCanary原理解析
檢測原理
監聽
在Android中，當一個Activity走完onDestroy生命週期後，說明該頁面已經被銷燬了，應該被系統GC回收。通過Application.registerActivityLifecycleCallbacks()方法註冊Activity生命週期的監聽，每當一個Activity頁面銷燬時候，獲取到這個Activity去檢測這個Activity是否真的被系統GC。
檢測
當獲取了待分析的物件後，需要確定這個物件是否產生了記憶體洩漏。
通過WeakReference + ReferenceQueue來判斷物件是否被系統GC回收，WeakReference 建立時，可以傳入一個 ReferenceQueue 物件。當被 WeakReference 引用的物件的生命週期結束，一旦被 GC 檢查到，GC 將會把該物件新增到 ReferenceQueue 中，待ReferenceQueue處理。當 GC 過後物件一直不被加入 ReferenceQueue，它可能存在記憶體洩漏。
當我們初步確定待分析物件未被GC回收時候，手動觸發GC，二次確認。