原理：實現(xiàn)原理上都選擇盡量少的hook，通過在manifest上預埋一些組件實現(xiàn)四大組件的插件化。其中Small更形成了一個跨平臺、組件化的框架。
成都創(chuàng)新互聯(lián)堅持“要么做到，要么別承諾”的工作理念，服務領域包括：成都網(wǎng)站建設、網(wǎng)站建設、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣等服務，滿足客戶于互聯(lián)網(wǎng)時代的盤州網(wǎng)站設計、移動媒體設計的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡建設合作伙伴！
VirtulApp：
能夠完全模擬app的運行環(huán)境，能夠?qū)崿F(xiàn)免安裝應用和雙開技術。
Atlas：
阿里出品，號稱是一個容器化框架，結(jié)合了組件化和熱更新技術。
Android中有兩種類加載器，DexClassLoader和PathClassLoader，它們都繼承于BaseDexClassLoader。
兩者的區(qū)別：DexClassLoader多了一個optimizedDirectory的路徑參數(shù)，這個目錄必須是內(nèi)部存儲路徑，用于緩存系統(tǒng)創(chuàng)建的Dex文件。
所以我們可以使用DexClassLoader去加載外部Apk中的類。
ClassLoader調(diào)用loadClass方法加載類采用了雙親委托機制來避免重復加載類。
首先，ClassLoader會查看自身已經(jīng)加載的類中是否已經(jīng)存在此類，如不存在，然后，則會使用父類來加載此類，如不能成功加載，則會使用自身重載于BaseDexClassLoader的findClass()方法來加載此類。
DexClass的DexPathList在DexClass的構(gòu)造器中生成，findClass()方法則是從DexPathList下面找出對應的DexFile，循環(huán)DexElements，通過dexElement.dexFile取出對應的DexFile，再通過DexFile.loadClassBinaryName()加載對應的類。
作用：使用插件DexClassLoader加載出需要的類。
通過每一個插件的DexClassLoader加載出自身所需要的類，當每一個插件需要加載相同的類庫時，可采用該類庫的不同版本來使用。
通過把每一個插件的pathList（DexFile）合并到主app的DexClassLoader上，來使各個插件和主app直接能夠相互調(diào)用類和方法，并且各個插件中相同的功能可以抽取出來作為一個Common插件供其它插件使用。
插件調(diào)用主工程
在ClassLoader構(gòu)造時指定主工程的DexClassLoader為父加載器即可直接調(diào)用主工程中的類和方法。
主工程調(diào)用插件
如果是多DexClassLoader的情況，則需要通過插件的DexClassLoader加載對應的類并反射調(diào)用其方法。此種情況，主工程一般會在一個統(tǒng)一的地方對訪問插件中的類和方法做一些訪問權(quán)限的管理及配置。
如果是單DexClassLoader的情況，則可以直接調(diào)用插件中的類和方法。但是當多個插件引用的庫的版本不同時，會出現(xiàn)錯誤，因此，建議采用Gradle版本依賴管理統(tǒng)一處理主工程及各個插件的庫依賴。
Android通過Resource來加載資源，只要有插件apk，就可以使用assertManager.addAssertPath（apkPath）的方式來生成assertManager，再使用其new出對應的Resource對象即可。
注意：由于AssertManager并不是Public，所以需要通過反射的方式去調(diào)用它。并且由于一些Rom對Resource的處理，所以，需要兼容處理。
有2種處理方式：
產(chǎn)生的原因：由于主工程和各個插件引用的Resource id重復產(chǎn)生的沖突。
解決思路：Android中的資源在系統(tǒng)中是以8位16進制0XPPTTRRRR的方式存在，其中PP即是資源區(qū)分的區(qū)域（Android系統(tǒng)只用它來區(qū)分系統(tǒng)資源和應用資源），只要讓每一個插件的PP段取不同的值即可解決資源id沖突的問題。
具體解決方式：
1.修改aapt源碼，編譯期修改PP段。
2.修改Resource的arsc文件，其中的每一條都包含了資源id和映射路徑。
Activity的處理最為復雜，有兩種處理方式：
1.ProxyActivity的方式。
2.預埋StubActivity，hook系統(tǒng)啟動Activity的過程。
原理：VirtualAPK通過替換了系統(tǒng)的Instrumentation，hook了Activity的啟動和創(chuàng)建，省去了手動管理插件Activity生命周期的繁瑣，讓插件Activity像正常的Activity一樣被系統(tǒng)管理，并且插件Activity在開發(fā)時和常規(guī)一樣，即能獨立運行又能作為插件被主工程調(diào)用。
Android插件化方向主要有2個方向：
Android 插件化
《Android插件化開發(fā)指南》百度網(wǎng)盤pdf最新全集下載:
鏈接:
?pwd=qn54 提取碼: qn54
簡介：本書不僅詳細介紹Android插件化技術如何實現(xiàn)，而且包含大量Android系統(tǒng)的底層知識，有助于App開發(fā)人員深入理解Android系統(tǒng)，從而寫出更健壯的代碼。 ?
使用Android Studio開發(fā)Gradle插件的步驟：
1 創(chuàng)建Gradle Module
AndroidStudio中是沒有新建類似Gradle Plugin這樣的選項的，那我們?nèi)绾卧贏ndroidStudio中編寫Gradle插件，并打包出來呢？
(1) 首先，你得新建一個Android Project
(2) 然后再新建一個Module，這個Module用于開發(fā)Gradle插件，同樣，Module里面沒有gradle plugin給你選，但是我們只是需要一個“容器”來容納我們寫的插件，因此，你可以隨便選擇一個Module類型（如PhoneTablet Module或Android Librarty）,因為接下來一步我們是將里面的大部分內(nèi)容刪除，所以選擇哪個類型的Module不重要。
(3) 將Module里面的內(nèi)容刪除，只保留build.gradle文件和src/main目錄。
由于gradle是基于groovy，因此，我們開發(fā)的gradle插件相當于一個groovy項目。所以需要在main目錄下新建groovy目錄
(4) groovy又是基于Java，因此，接下來創(chuàng)建groovy的過程跟創(chuàng)建java很類似。在groovy新建包名，如：com.hc.plugin，然后在該包下新建groovy文件，通過new-file-MyPlugin.groovy來新建名為MyPlugin的groovy文件。
(5) 為了讓我們的groovy類申明為gradle的插件，新建的groovy需要實現(xiàn)org.gradle.api.Plugin接口。如下所示：
package com.hc.plugin
import org.gradle.api.Plugin
import org.gradle.api.Project
public class MyPlugin implements Pluginproject {/project
void apply(Project project) {
System.out.println("========================");
System.out.println("hello gradle plugin!");
System.out.println("========================");
}
}
因為我本人對groovy也不是特別熟悉，所以我盡可能的用Java語言，使用System.out.println而不是用groovy的pintln ""，我們的代碼里面啥也沒做，就打印信息。
(6) 現(xiàn)在，我們已經(jīng)定義好了自己的gradle插件類，接下來就是告訴gradle，哪一個是我們自定義的插件類，因此，需要在main目錄下新建resources目錄，然后在resources目錄里面再新建META-INF目錄，再在META-INF里面新建gradle-plugins目錄。最后在gradle-plugins目錄里面新建properties文件，注意這個文件的命名，你可以隨意取名，但是后面使用這個插件的時候，會用到這個名字。比如，你取名為com.hc.gradle.properties，而在其他build.gradle文件中使用自定義的插件時候則需寫成：
apply plugin: 'com.hc.gradle'
然后在com.hc.gradle.properties文件里面指明你自定義的類
implementation-class=com.hc.plugin.MyPlugin
現(xiàn)在，你的目錄應該如下：
(7) 因為我們要用到groovy以及后面打包要用到maven,所以在我們自定義的Module下的build.gradle需要添加如下代碼：
apply plugin: 'groovy'
apply plugin: 'maven'
dependencies {
compile gradleApi()
compile localGroovy()
}
repositories {
mavenCentral()
}
2 打包到本地Maven
前面我們已經(jīng)自定義好了插件，接下來就是要打包到Maven庫里面去了，你可以選擇打包到本地，或者是遠程服務器中。在我們自定義Module目錄下的build.gradle添加如下代碼：
group='com.hc.plugin'
version='1.0.0'
uploadArchives {
repositories {
mavenDeployer {
repository(url: uri('D:/repos'))
}
}
}
其中，group和version后面會用到，我們后面再講。雖然我們已經(jīng)定義好了打包地址以及打包相關配置，但是還需要我們讓這個打包task執(zhí)行。點擊AndroidStudio右側(cè)的gradle工具，如下圖所示：
可以看到有uploadArchives這個Task,雙擊uploadArchives就會執(zhí)行打包上傳啦！執(zhí)行完成后，去我們的Maven本地倉庫查看一下：
其中，com/hc/plugin這幾層目錄是由我們的group指定，myplugin是模塊的名稱，1.0.0是版本號（version指定）。
步驟1：注冊ApkPlug官網(wǎng)賬號：
打開Apkplug官網(wǎng)后，點擊右上角的“注冊”，在跳轉(zhuǎn)頁面填入相關信息，注冊界面如下：
確認后注冊成功，使用你的賬號登錄網(wǎng)站。你就可以用Apkplug開發(fā)應用了
END
步驟2：開發(fā)插件
Apkplug中的插件也是一個完整的apk,它與普通應用的區(qū)別有以下3點：
1， 插件assets目錄下有一個plugin.xml文檔,通過它可判斷一個工程是主應用還是插件。
2， 插件有一個入口類BundleActivator
3， 插件會外部引用一個osgi.jar文件
開發(fā)插件的步驟有如下4步：
1，引入osgi.jar庫文件
Apkplug中插件需要導入的庫文件只有一個osgi.jar。
導入osgi.jar庫文件需要注意一下
osgi.jar文件只能引用不能編譯到apk文件中,否則會出現(xiàn)類沖突的情況
異常代碼：had used a different Lorg/osgi/framework/BundleActivator; during pre-verification。
osgi.jar包導入方法：
這文件在Apkplug SDK中可以找到。
2，編寫插件入口類BundleActivator
插件啟動時首先調(diào)用BundleActivator,其功能類似android中的application類。
public class SimpleBundle implements BundleActivator
{
private BundleContext mcontext = null;
public void start(BundleContext context) throws Exception
{
System.err.println("你好我是插件,我將為你展示啟動acitivty我已經(jīng)啟動了 我的BundleId為："+context.getBundle().getBundleId());
}
public void stop(BundleContext context)
{
System.err.println("你好我是插件,我被停止了 我的BundleId為："+context.getBundle().getBundleId());
}
}
3，編寫plugin.xml配置文件
plugin.xml
是一個配置表,它跟AndroidManifest.xml作用類似。 plugin.xml文檔放置在assets中即可 重要屬性說明：
Bundle-Name 插件名稱 Bundle-SymbolicName 插件包名
-與應用packagename可一一對應 Bundle-Version 插件版本 -1.0.0
Bundle-Activator 插件入口 -與Appliction 類似
Bundle-Activity 插件界面 -多個Activity可用 , 分割
Bundle-Service 插件Service -多個Service可用 , 分割
(v2.0.0新增) Bundle-Receiver 插件廣播 -多個廣播類可用 , 分割
(v2.0.0新增)
4， 編譯生成插件apk文件
插件工程中添加的文件目錄結(jié)構(gòu)如下：
最后編譯運行插件工程,生成的apk文件即為插件文件
END
步驟3：開發(fā)主應用
Apkplug 主應用開發(fā)分兩步集成：
1. 獲取主應用授權(quán)AppAuth。
登錄賬號進入Apkplug后臺后，切換到“應用授權(quán)頁面”，按要求填寫好應用信息，然后確定，你就擁有了一個等待開發(fā)的應用授權(quán)AppAuth。應用授權(quán)界面如下：
進入“授權(quán)列表”頁面,點擊“查看詳情”鏈接,進入“應用詳情界面”，就可以看到已申請的AppAuth，點擊其后面的“復制”，即可直接復制AppAuth，如下圖所示
2. 對接Apkplug SDK 導入相關庫文件。
①配置應用權(quán)限
主應用需要幾個基礎的權(quán)限配置，請將以下的幾個權(quán)限加入到主應用的AndroidManifest.xml中。
!-- 插件平臺需要的權(quán)限! --
uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/uses-permission
uses-permission android:name="android.permission.MOUNT_UNMOUNT_FILESYSTEMS"/
uses-permission android:name="android.permission.INTERNET"/
uses-permission android:name="android.permission.READ_PHONE_STATE"
/uses-permission
另外將一下加入到application/application節(jié)點中
!-- 插件平臺需要的配置! --
activity
android:name="org.apkplug.app.apkplugActivity"
android:theme="@style/android:Theme.Light"
android:configChanges="orientation|keyboardHidden"
/
最后將我們從Apkplug管理后臺申請到的AppAuth加入到配置文件中。
meta-data android:name="apkplug-auth" android:value="xxxxxxxx" /meta-data
注：由于3.2.2節(jié)中我們直接復制了AppAuth，此處直接粘貼到AndroidManifest文檔中。
如下圖：
②導入SDK庫文件
主應用需要導入兩個文件,將其放入libs目錄中即可。
1， libndkfoo.so
2， Bundle2.0.0.jar
如下圖：
這兩個庫文件在Apkplug SDK中可以找到。
然后：
主應用啟動Apkplug最簡只需要一段代碼即可,建議在Application中啟動框架。
FrameworkInstance frame=FrameworkFactory.getInstance().start(ListBundleActivator,Context);
將上一步驟開發(fā)好的插件apk，放置在主應用工程里的assets路徑下。
如下圖：
END
步驟4：啟動主應用
最后啟動主應用即可。簡單的插件化apk的方法就講完了，有興趣的關注我，下次講云端托管插件實現(xiàn)應用內(nèi)更新。
首先由于我自己也是個新手，也是在學習各種框架然后給公司項目選定相應自動化框架，研究移動自動化測試框架也就近段時間而已，所以我只能從我自己今天為止的認知角度給各個框架抒發(fā)我自己的拙見，你看是否能從中接納一二吧（對于我自己的話還需要再花一段時間去學習各個框架才能確定哪個/些是適合我們項目的了,也許到時我會寫個正式的總結(jié))。
根據(jù)你的要求，應該不會考慮MonkeyRunner和Robotium，但我還是想跟你說下其實Robotium還是挺不錯的，如果你沒有考慮跨進程調(diào)用其他APP的話。至于MonkeyRunner我就不大推薦了，你可以看下我對金陽光老師的一個評論的回復《MonkenRunner通過HierarchyViewer定位控件的方法和建議》（文章最后我干脆也貼出來了）。至于Robotium，你對比下本人博客里面各個框架編寫的Note的測試示例就可以看出來Robotium相對其他框架會簡介很多，況且發(fā)展的比UIAutomator和Appium長久很多，所以也應該會更成熟，和Eclipse集成調(diào)試起來也很方便。比起后兩者如果有不足的話我覺得就以下幾點吧：
1. 所有的操作抽象到一個Solo類里面，缺乏面向?qū)ο蟮木幊趟枷耄袝r會讓人不適應。如果你熟悉C語言等面向過程的語言思想的話應該沒有問題。
2. 獲取控件的方法比較缺乏，大概就幾種：通過Text，ID， ClassName，Index。沒有后兩者的多種多樣
3. 跨進程：因為底層使用Instrument框架，測試包和被測應用包打包在一起作為一個進程運行而線程間通過instrumentaiton進行通信，導致了逃不出這個進程設沙箱（sandbox)
4. 做不了模擬鍵盤的測試（但同時這個也是Robotium非常巨大的優(yōu)點，因為不像后兩者那樣需要調(diào)用鍵盤導致輸入的各種各樣的問題），因為Robotium輸入讀出其實是直接對控件的text屬性進行操作沒有通過鍵盤驅(qū)動的，你如果做過UI編程應該就明白我的意思了，因為記住你的測試代碼和目標應用是打包在同一個進程中的，同一個進程中想訪問另外一個線程的某個變量，運用相應的IPC（Interprocess Communication)機制當然是沒有問題的了。
然后到了你問的主題UIAutomator和Appium的對比，我個人是這樣看的：
1. UIAutomator是親爹（google）生的，所以可以保證后續(xù)的開發(fā)維護力量，除非google倒閉（這里我有點不懂的是為什么google對Monkeyrunner的態(tài)度這么讓人摸不著頭腦，具體請看以上我說的對MonkeyRunner的評論）
2. Appium雖然不是親爹生的，但是干爹實力雄厚把它武裝的無所不能（android，ios，firefox，browser通殺），單單以android來說，底層用得還是UIAutomator，所以只要它能及時跟上UIAutomator的更新，功能上面我不是很擔心。
3. 但是也這是Appium的這種架構(gòu)：UIautomator/seledroid-Appium Server-Selenium/AppiumDriver-Test Case （《Appium架構(gòu)框架圖整理》）,導致框架有點復雜，當問題出現(xiàn)的時候調(diào)試起來比較難以定位，不知道哪個模塊出錯了。但是說道調(diào)試，總比UIAutomator好，起碼Appium可以直接集成到eclipse上面進行debug，UiAutomator卻每次都要push到目標機器然后再去執(zhí)行，怎么調(diào)試呢？到現(xiàn)在為止我知道的只能原始的print了。
4. 向下兼容問題：Appium可以通過底層UIAutomator/Selendroid（不記得是不是這名字了）通殺；UIAutomator只能在API Level
17（包含）以上使用
5.語言支持：appium基本通殺，UIAutomator用java足矣
6.跨平臺：如你所說的只是android兩者都沒有問題，如果往后需要擴展到ios，那么建議appium
7.bug數(shù)量：UIAutomator有的問題Appium都會有，UIAutomator沒有的問題Appium也有可能有^_^（不過我還是很看好Appium的）
8. 輸入問題，都有bug，具體請查看我相應blog，特別是中文輸入，這就是為什么我剛才特意提出Robotum的原因之一
9. WebView支持：UIAutomator據(jù)說今年年初已經(jīng)開始支持，個人沒有這方面要求所以沒研究；Appium的框架用的Selenium本身就是PC上最流行的開源Web測試框架，所以必然支持了。注意這你你要有點android編程知識了，WebView指的不僅是WebView控件還包含如用sencha+phonegap把webview封裝成一個跨平臺app的情況了，具體如果不清楚請google。
其他區(qū)別我現(xiàn)在就沒有想到了，希望能幫助到你，從我自己的角度來看，我覺得UIAutomator繼續(xù)往前發(fā)展是必然的了，但是它不可能最終支持ios。至于Appium我同樣有很大的信心它會繼續(xù)往好的方向發(fā)展，且考慮到它的跨平臺支持，基于node.js（現(xiàn)在非常流行哦），兼容性等，我如果是你的話我會考慮用Appium的（拋開Robotium不說，如果你又要考慮的話就需要你根據(jù)我之前說的再總結(jié)下了^_^）。
我覺得這個可以類比之前的微軟和Borland的關系，API是Windows，但是IDE是Borland的，各專所長了?？上Вɑ蛘邞c幸）后來微軟發(fā)力一下把Borland打得滿地找牙一蹶不振，不過這是題外話了，略過......
對了，我有可能會對這封郵件整理下發(fā)到博客了，也希望其他網(wǎng)友能評點一二給你出主意。今晚本來想看下easy_monkey的知識了，給你寫這個email變成臨時性總結(jié)了。^_^
給金陽光老師評論的回復如下（關于MonkeyRunner的個人觀點）
-----------------------------------------------------------------------------------------------------------------
回復haorenmin2008：首先膜拜下，金老師大駕光臨蓬蓽生輝??！
對于后者，確實如此，UIAutomator需要API Level17（包含）以上。
對于前者，因為還沒有MonkeyRunner的項目經(jīng)驗，所以是否很強大我就不敢妄加評論了，但是在我近來的tryout過程中，鄙人有以下的一些不成熟的認知：
1. 感覺功能不是很穩(wěn)定，之前嘗試一個MonkeyDevice的getProperty方法，竟然有時成功有時失敗。
2. 性能不好，特別是當我們要用到hierarchyviewer的功能的時候很明顯。
3. 只能用MonkeyImage的sameAs做截屏的對比，雖然加上hierarchyviewer后可以用它的getText，但還是很有限。
4. 控件定位方面主要是坐標點和HierarchyViewer提供的根據(jù)ID。前這兒在UI布局稍微有調(diào)整位置的話就需要跟著變動，沒有像其他控件類框架那樣做高層抽象除非換控件不然都不需要怎么變動；后者的話很多控件是沒有id或者是有多個控件id相同的。
5. 可調(diào)試性也不強（起碼我摸索了這幾天沒有發(fā)現(xiàn)一個很好的調(diào)試方法，比如IDE Ecilpse等的集成調(diào)試方法）
6. HierarchyViewer的穩(wěn)定性也讓我擔憂，碰到過幾次取控件信息的時候報exception的。
7. 資料稀缺，不僅百度，google也一樣
8. Google支持讓人覺得摸不著頭腦，sdk給出的API和官方提供的API竟然不一致，以MonkeyDevice為例子，而sdk多出來的API竟然還不能用，google出來的信息不超過10個page，還要很多都是重復的石沉大海的網(wǎng)友報的問題。
9. 再一個的我真心搞不懂為什么本身java寫的庫非要搞個jython來調(diào)用，首先我不說性能損耗（這點肯定是有的，native庫當然用native語言調(diào)用效率最好嘛），我想在eclipse上對以下的"device."做自動補全是做不到的“device = MonkeyRunner.waitForConnection()\n device.",而只有直接調(diào)用個構(gòu)造函數(shù)實例化的device = MonkeyDevice（xxx）才能做到，這個我不相信是我配置的問題，換了個jython標準編譯器以調(diào)用標準庫問題同樣存在。
簡答的說插件是給android studio這個開發(fā)IDE用的，依賴庫是給你的項目用的。下面詳細解釋下。
插件：(Plug-in,又稱addin、add-in、addon或add-on,又譯外掛)是一種遵循一定規(guī)范的應用程序接口編寫出來的程序。其只能運行在程序規(guī)定的系統(tǒng)平臺下（可能同時支持多個平臺），而不能脫離指定的平臺單獨運行。android studio中插件就是其平臺下幫助開發(fā)的小程序，比如：
ButterKnife Zelezny：ButterKnife 注解生成器，使用起來非常簡單方便。
SelectorChapek：設計師給我們提供好了各種資源，每個按鈕都要寫一個selector是不是很麻煩？這么這個插件就為解決這個問題而生，你只需要做的是告訴設計師們按照規(guī)范命名就好了，其他一鍵搞定。
GsonFormat：現(xiàn)在大多數(shù)服務端api都以json數(shù)據(jù)格式返回，而客戶端需要根據(jù)api接口生成相應的實體類，這個插件把這個過程自動化了。
Android Parcelable Code Generator：Android中的序列化有兩種方式，分別是實現(xiàn)Serializable接口和Parcelable接口，但在Android中是推薦使用Parcelable，只不過我們這種方式要比Serializable方式要繁瑣，那么有了這個插件一切就ok了。
依賴庫：從編程的角度出發(fā)，庫是指封裝了各種功能的函數(shù)，用戶在編寫新程序時，無需再重新開發(fā)相關的功能。android studio的依賴庫就是你在做android功能時用到的功能函數(shù)庫。如下圖片：
重慶分公司
重慶分公司
