android開發插件

A. 有什麼好用的Android Studio的插件值得推薦

android studio常用插件，可極大簡化開發，增強開發效率。

1、ButterKnife Zelezny

ButterKnife 註解生成器，使用起來非常簡單方便，使用ButterKnife的有福了！

2、SelectorChapek

設計師給我們提供好了各種資源，每個按鈕都要寫一個selector是不是很麻煩？這么這個插件就為解決這個問題而生，你只需要做的是告訴設計師們按照規范命名就好了，其他一鍵搞定。按照不同狀態(normal、pressed)的標准命名後，右鍵文件樹Generate
Android Selectors見inmite/android-selector-chapek · GitHub。

3、GsonFormat

現在大多數服務端api都以json數據格式返回，而客戶端需要根據api介面生成相應的實體類，這個插件把這個過程自動化了，趕緊使用起來吧。

4、Android Parcelable Code Generator

Android中的序列化有兩種方式，分別是實現Serializable介面和Parcelable介面，但在Android中是推薦使用Parcelable，只不過我們這種方式要比Serializable方式要繁瑣，那麼有了這個插件一切就ok了。

5、LeakCanary

B. Android 插件化

原理：實現原理上都選擇盡量少的hook，通過在manifest上預埋一些組件實現四大組件的插件化。其中Small更形成了一個跨平台、組件化的框架。

VirtulApp：
能夠完全模擬app的運行環境，能夠實現免安裝應用和雙開技術。
Atlas：
阿里出品，號稱是一個容器化框架，結合了組件化和熱更新技術。

Android中有兩種類載入器，DexClassLoader和PathClassLoader，它們都繼承於BaseDexClassLoader。

兩者的區別：DexClassLoader多了一個optimizedDirectory的路徑參數，這個目錄必須是內部存儲路徑，用於緩存系統創建的Dex文件。

所以我們可以使用DexClassLoader去載入外部Apk中的類。

ClassLoader調用loadClass方法載入類採用了雙親委託機制來避免重復載入類。
首先，ClassLoader會查看自身已經載入的類中是否已經存在此類，如不存在，然後，則會使用父類來載入此類，如不能成功載入，則會使用自身重載於BaseDexClassLoader的findClass()方法來載入此類。

DexClass的DexPathList在DexClass的構造器中生成，findClass()方法則是從DexPathList下面找出對應的DexFile，循環DexElements，通過dexElement.dexFile取出對應的DexFile，再通過DexFile.loadClassBinaryName()載入對應的類。

作用：使用插件DexClassLoader載入出需要的類。

通過每一個插件的DexClassLoader載入出自身所需要的類，當每一個插件需要載入相同的類庫時，可採用該類庫的不同版本來使用。

通過把每一個插件的pathList（DexFile）合並到主app的DexClassLoader上，來使各個插件和主app直接能夠相互調用類和方法，並且各個插件中相同的功能可以抽取出來作為一個Common插件供其它插件使用。

插件調用主工程
在ClassLoader構造時指定主工程的DexClassLoader為父載入器即可直接調用主工程中的類和方法。
主工程調用插件
如果是多DexClassLoader的情況，則需要通過插件的DexClassLoader載入對應的類並反射調用其方法。此種情況，主工程一般會在一個統一的地方對訪問插件中的類和方法做一些訪問許可權的管理及配置。

如果是單DexClassLoader的情況，則可以直接調用插件中的類和方法。但是當多個插件引用的庫的版本不同時，會出現錯誤，因此，建議採用Gradle版本依賴管理統一處理主工程及各個插件的庫依賴。

Android通過Resource來載入資源，只要有插件apk，就可以使用assertManager.addAssertPath（apkPath）的方式來生成assertManager，再使用其new出對應的Resource對象即可。

注意：由於AssertManager並不是Public，所以需要通過反射的方式去調用它。並且由於一些Rom對Resource的處理，所以，需要兼容處理。

有2種處理方式：

產生的原因：由於主工程和各個插件引用的Resource id重復產生的沖突。

解決思路：Android中的資源在系統中是以8位16進制0XPPTTRRRR的方式存在，其中PP即是資源區分的區域（Android系統只用它來區分系統資源和應用資源），只要讓每一個插件的PP段取不同的值即可解決資源id沖突的問題。
具體解決方式：

1.修改aapt源碼，編譯期修改PP段。
2.修改Resource的arsc文件，其中的每一條都包含了資源id和映射路徑。

Activity的處理最為復雜，有兩種處理方式：
1.ProxyActivity的方式。
2.預埋StubActivity，hook系統啟動Activity的過程。

原理：VirtualAPK通過替換了系統的Instrumentation，hook了Activity的啟動和創建，省去了手動管理插件Activity生命周期的繁瑣，讓插件Activity像正常的Activity一樣被系統管理，並且插件Activity在開發時和常規一樣，即能獨立運行又能作為插件被主工程調用。

Android插件化方向主要有2個方向：

Android 插件化