android插件式
⑴ android插件化原理要多久
插件化技术发展到现在其实已经很成熟了，但是相应的问题，如果没有真正地去实践过，根本不了解其中有多少问题，会牵涉到多少技术细节，多少被外人膜拜的外表光鲜的技术大牛都被‘插件化’这三个字折磨地死去活来，这对于 Android 整个生态的损害也让人无法忽视。
我们首先要想一下，我们做插件化的目的是什么？
为了满足产品随时上线的需求？
为了修复因为我们对自己要求不严格而写出来的 bug ？
为了向人炫耀自己的技术实力？
很抱歉，如果是为了这些目的，那就真的太对不起自己是‘开发者’这个如此高逼格的身份了。
做插件化真正的目的：是为了去适应并行开发，是为了解耦各个模块，是为了避免模块之间的交叉依赖，是为了加快编译速度，从而提高并行开发效率。
明确了这些，我们再来看插件化的结果，每个模块都支持独立运行测试，分为稳定的 release 版本和不稳定的 snapshot 版本，每个模块都高度解耦，没有交叉依赖，不会出现一个模块依赖了另一个模块，其中一个人改了这个模块的代码，对另一个模块造成影响。
按照这个思路，我们再来看看一些其他的细节：
在 Android 里有一个比较爽的一点是，作为 library 的时候，aar 里的引用依赖，在宿主 Application 里也有同样的引用依赖，并不会打包两份到宿主 Application 里；
模块之间的跳转，除了使用别名的方式，我能想到的还有另外一种方式，同样是通过 gradle 脚本，将跳转用到的类打成一个 jar ，作为一个 API 服务提供给其他模块作为编译期依赖（provided）引入；
各个 library 在 debug 的时候作为 apk ，要独立打包运行测试，这时就需要有一个启动 Activity ，而 library 是不需要的，我的想法是放置两个 AndroidManifest.xml ，使用 sourceSets 分别在 debug 和 release 的时候加载不同的 AndroidManifest.xml 。
⑵ 什么是Android插件开发
插件化开发和组件化开发略有不用，插件化开发时将整个app拆分成很多模块，这些模块包括一个宿主和多个插件，每个模块都是一个apk（组件化的每个模块是个lib），最终打包的时候将宿主apk和插件apk分开或者联合打包。
开源的插件化框架
Qihoo360/DroidPlugin
CtripMobile/DynamicAPK
mmin18/AndroidDynamicLoader
singwhatiwanna/dynamic-load-apk
houkx/android-pluginmgr
bunnyblue/ACDD
wequick/Small
……
目前开源的这几个框架有宿主和插件分离的也有融合在一起的，每个框架的详细介绍和demo在github里都可以查看到。插件化demo运行起来比较简单，但是真正将它用到实际项目中还是要考虑很多小细节的，目前我也正处于研究阶段。
⑶ 怎么将 Android 程序做成插件化的形式
有个框架叫apkplug
就是apk插件式的开发框架
其实原理都一样,因为android不支持动态的增加jar
因此插件需要做成一个单独的apk,框架APK去查找系统中的其它插件
然后结合一起调用即可
⑷ 如何编写自己的android插件
目前plugin-x中定义了4个协议：ProtocolAds, ProtocolAnalytics, ProtocolIAP, ProtocolSocial。编写自己的插件，不需要写任何的c++/jni代码或者javascript绑定代码。我们已经在plugin-x的核心层实现了这些，开发者所要做的就是：
新建一个android工程。
使用java实现我们定义的接口。
plugin的文件夹结构
请确保你的plugin文件夹结构类似下图：
build.xml : publish.sh脚本使用它，可以从其他插件工程拷贝过来，注意要修改工程名。
ForManifest.xml : gameDevGuide.sh使用它. 如果你的插件在AndroidManifest.xml开启了一些额外的权限，需要把他们添加到这个文件中。
sdk : 把第三方SDK的jar包放在这里。
src : 把你的插件实现代码放在这里。
编写java类实现至少一个接口
这个类应该有一个带有Context参数的构造函数，例如：
package org.cocos2dx.plugin;
public class AnalyticsFlurry implements InterfaceAnalytics {
...
public AnalyticsFlurry(Context context) {
mContext = context;
}
}
你可以覆盖接口中的方法，或者定义自己的方法，例如：
@Override
public String getSDKVersion() {
return "3.2.1";
}
protected void setUserId(String userId) {
LogD("setUserId invoked!");
final String curUser = userId;
PluginWrapper.runOnMainThread(new Runnable() {
@Override
public void run() {
try {
FlurryAgent.setUserId(curUser);
} catch(Exception e){
LogE("Exception in setUserId", e);
}
}
});
}
目前plugin-x只支持传递int, float, boolean, String, JSONObject类型的参数，返回值类型只可以是int, float, boolean, String。
⑸ Android上有哪些好用的插件
好用的Android Studio的插件：
支持直接在AS面板中进行ADB操作，
Uninstall App
Kill App
Start App
Restart App
Clear App Data
Clear App Data and Restart
⑹ Android的apkplug插件开发具体怎么编译生成插件 apk 文件
步骤1：注册ApkPlug官网账号：
打开Apkplug官网后，点击右上角的“注册”，在跳转页面填入相关信息，注册界面如下：
确认后注册成功，使用你的账号登录网站。你就可以用Apkplug开发应用了
END
步骤2：开发插件
Apkplug中的插件也是一个完整的apk,它与普通应用的区别有以下3点：
1， 插件assets目录下有一个plugin.xml文档,通过它可判断一个工程是主应用还是插件。
2， 插件有一个入口类BundleActivator
3， 插件会外部引用一个osgi.jar文件
开发插件的步骤有如下4步：
1，引入osgi.jar库文件
Apkplug中插件需要导入的库文件只有一个osgi.jar。
导入osgi.jar库文件需要注意一下
osgi.jar文件只能引用不能编译到apk文件中,否则会出现类冲突的情况
异常代码：had used a different Lorg/osgi/framework/BundleActivator; ring pre-verification。
osgi.jar包导入方法：
这文件在Apkplug SDK中可以找到。
2，编写插件入口类BundleActivator
插件启动时首先调用BundleActivator,其功能类似android中的application类。
public class SimpleBundle implements BundleActivator
{
private BundleContext mcontext = null;
public void start(BundleContext context) throws Exception
{
System.err.println("你好我是插件,我将为你展示启动acitivty我已经启动了 我的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文件
插件工程中添加的文件目录结构如下：
最后编译运行插件工程,生成的apk文件即为插件文件
END
步骤3：开发主应用
Apkplug 主应用开发分两步集成：
1. 获取主应用授权AppAuth。
登录账号进入Apkplug后台后，切换到“应用授权页面”，按要求填写好应用信息，然后确定，你就拥有了一个等待开发的应用授权AppAuth。应用授权界面如下：
进入“授权列表”页面,点击“查看详情”链接,进入“应用详情界面”，就可以看到已申请的AppAuth，点击其后面的“复制”，即可直接复制AppAuth，如下图所示
2. 对接Apkplug SDK 导入相关库文件。
①配置应用权限
主应用需要几个基础的权限配置，请将以下的几个权限加入到主应用的AndroidManifest.xml中。
<!-- 插件平台需要的权限! -->
<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>节点中
<!-- 插件平台需要的配置! -->
<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节中我们直接复制了AppAuth，此处直接粘贴到AndroidManifest文档中。
如下图：
②导入SDK库文件
主应用需要导入两个文件,将其放入libs目录中即可。
1， libndkfoo.so
2， Bundle2.0.0.jar
如下图：
这两个库文件在Apkplug SDK中可以找到。
然后：
主应用启动Apkplug最简只需要一段代码即可,建议在Application中启动框架。
FrameworkInstance frame=FrameworkFactory.getInstance().start(List<BundleActivator>,Context);
将上一步骤开发好的插件apk，放置在主应用工程里的assets路径下。
如下图：
END
步骤4：启动主应用
最后启动主应用即可。简单的插件化apk的方法就讲完了，有兴趣的关注我，下次讲云端托管插件实现应用内更新。
⑺ android 插件化和热修复做什么用的
针对Android平台，Dexposed支持函数级别的在线热更新，例如对已经发布在应用市场上的宿主APK，当我们从crash统计平台上发现某个函数调用有bug，导致经常性crash，这时，可以在本地开发一个补丁APK，并发布到服务器中，宿主APK下载这个补丁APK并集成后，就可以很容易修复这个crash。
Dexposed是基于久负盛名的开源Xposed框架实现的一个Android平台上功能强大的无侵入式运行时AOP框架。
Dexposed的AOP实现是完全非侵入式的，没有使用任何注解处理器，编织器或者字节码重写器。集成Dexposed框架很简单，只需要在应用初始化阶段加载一个很小的JNI库就可以，这个加载操作已经封装在DexposedBridge函数库里面的canDexposed函数中，源码如下所示：
/**
* Check device if can run dexposed, and load libs auto.
*/
public synchronized static boolean canDexposed(Context context) {
if (!DeviceCheck.isDeviceSupport(context)) {
return false;
}
//load xposed lib for hook.
return loadDexposedLib(context);
}
private static boolean loadDexposedLib(Context context) {
// load xposed lib for hook.
try {
if (android.os.Build.VERSION.SDK_INT > 19){
System.loadLibrary("dexposed_l");
} else if (android.os.Build.VERSION.SDK_INT == 10
|| android.os.Build.VERSION.SDK_INT == 9 ||
android.os.Build.VERSION.SDK_INT > 14){
System.loadLibrary("dexposed");
}
return true;
} catch (Throwable e) {
return false;
}
}
Dexposed实现的hooking，不仅可以hook应用中的自定义函数，也可以hook应用中调用的Android框架的函数。Android开发者将从这一点得到很多好处，因为我们严重依赖于Android SDK的版本碎片化。
⑻ Android Studio有哪些非常好用的插件
Android Studio软件免费下载
链接:https://pan..com/s/10uOaT5HNyfW9Agfntb9_Lw
Android Studio 是谷歌推出的一个Android集成开发工具，基于IntelliJ IDEA. 类似EclipseADT，Android Studio 提供了集成的 Android 开发工具用于开发和调试。
⑼ 为什么我说Android插件化从入门到放弃
首先就是去写代码。有一个做Android的哥们升级为架构师，需要了解iOS这门技术，来问我怎么能迅速精通iOS，我就告诉他，别玩虚的，脚踏实地跟着iOS开发团队做几个需求，半年之后再来谈这个话题。Android和iOS的很多现金思想可以相互借鉴，我建议做一门技术的同学，也适当学习另一门技术。
咬着牙看开源项目。比如说JSPatch，怎么看？我有个建议，你看JSPatch的版本提交历史，从第一次提交看起，这时候的功能应该是最简单的，也是最容易看懂的，然后看历史每次提交都修改了哪些东西，你能搞清楚作者的思路是什么。
Android插件化虽然有被React Native取代的势头，但还是要搞清楚插件化所涉及的各种思想和技术。我这一年来的心得是，这是提高自身内功的极好办法。尤其是涉及到Android系统底层的各种Hook。
写技术博客吧。每天看文章只能是看过，一个月后能沉淀下来的没有多少，好记性不如烂笔头。一开始你可以转载或罗列精品文章的链接，慢慢的开始分享自己的心得，翻译些技术文章，技术水平提高是一个循序渐进的过程。
⑽ android插件化框架哪个好
首先由于我自己也是个新手，也是在学习各种框架然后给公司项目选定相应自动化框架，研究移动自动化测试框架也就近段时间而已，所以我只能从我自己今天为止的认知角度给各个框架抒发我自己的拙见，你看是否能从中接纳一二吧（对于我自己的话还需要再花一段时间去学习各个框架才能确定哪个/些是适合我们项目的了,也许到时我会写个正式的总结)。
根据你的要求，应该不会考虑MonkeyRunner和Robotium，但我还是想跟你说下其实Robotium还是挺不错的，如果你没有考虑跨进程调用其他APP的话。至于MonkeyRunner我就不大推荐了，你可以看下我对金阳光老师的一个评论的回复《MonkenRunner通过HierarchyViewer定位控件的方法和建议》（文章最后我干脆也贴出来了）。至于Robotium，你对比下本人博客里面各个框架编写的Note的测试示例就可以看出来Robotium相对其他框架会简介很多，况且发展的比UIAutomator和Appium长久很多，所以也应该会更成熟，和Eclipse集成调试起来也很方便。比起后两者如果有不足的话我觉得就以下几点吧：
1. 所有的操作抽象到一个Solo类里面，缺乏面向对象的编程思想，有时会让人不适应。如果你熟悉C语言等面向过程的语言思想的话应该没有问题。
2. 获取控件的方法比较缺乏，大概就几种：通过Text，ID， ClassName，Index。没有后两者的多种多样
3. 跨进程：因为底层使用Instrument框架，测试包和被测应用包打包在一起作为一个进程运行而线程间通过instrumentaiton进行通信，导致了逃不出这个进程设沙箱（sandbox)
4. 做不了模拟键盘的测试（但同时这个也是Robotium非常巨大的优点，因为不像后两者那样需要调用键盘导致输入的各种各样的问题），因为Robotium输入读出其实是直接对控件的text属性进行操作没有通过键盘驱动的，你如果做过UI编程应该就明白我的意思了，因为记住你的测试代码和目标应用是打包在同一个进程中的，同一个进程中想访问另外一个线程的某个变量，运用相应的IPC（Interprocess Communication)机制当然是没有问题的了。
然后到了你问的主题UIAutomator和Appium的对比，我个人是这样看的：
1. UIAutomator是亲爹（google）生的，所以可以保证后续的开发维护力量，除非google倒闭（这里我有点不懂的是为什么google对Monkeyrunner的态度这么让人摸不着头脑，具体请看以上我说的对MonkeyRunner的评论）
2. Appium虽然不是亲爹生的，但是干爹实力雄厚把它武装的无所不能（android，ios，firefox，browser通杀），单单以android来说，底层用得还是UIAutomator，所以只要它能及时跟上UIAutomator的更新，功能上面我不是很担心。
3. 但是也这是Appium的这种架构：UIautomator/seledroid<->Appium Server<->Selenium/AppiumDriver<->Test Case （《Appium架构框架图整理》http://blog.csdn.net/zhutian/article/details/39453505）,导致框架有点复杂，当问题出现的时候调试起来比较难以定位，不知道哪个模块出错了。但是说道调试，总比UIAutomator好，起码Appium可以直接集成到eclipse上面进行debug，UiAutomator却每次都要push到目标机器然后再去执行，怎么调试呢？到现在为止我知道的只能原始的print了。
4. 向下兼容问题：Appium可以通过底层UIAutomator/Selendroid（不记得是不是这名字了）通杀；UIAutomator只能在API Level
17（包含）以上使用
5.语言支持：appium基本通杀，UIAutomator用java足矣
6.跨平台：如你所说的只是android两者都没有问题，如果往后需要扩展到ios，那么建议appium
7.bug数量：UIAutomator有的问题Appium都会有，UIAutomator没有的问题Appium也有可能有^_^（不过我还是很看好Appium的）
8. 输入问题，都有bug，具体请查看我相应blog，特别是中文输入，这就是为什么我刚才特意提出Robotum的原因之一
9. WebView支持：UIAutomator据说今年年初已经开始支持，个人没有这方面要求所以没研究；Appium的框架用的Selenium本身就是PC上最流行的开源Web测试框架，所以必然支持了。注意这你你要有点android编程知识了，WebView指的不仅是WebView控件还包含如用sencha+phonegap把webview封装成一个跨平台app的情况了，具体如果不清楚请google。
其他区别我现在就没有想到了，希望能帮助到你，从我自己的角度来看，我觉得UIAutomator继续往前发展是必然的了，但是它不可能最终支持ios。至于Appium我同样有很大的信心它会继续往好的方向发展，且考虑到它的跨平台支持，基于node.js（现在非常流行哦），兼容性等，我如果是你的话我会考虑用Appium的（抛开Robotium不说，如果你又要考虑的话就需要你根据我之前说的再总结下了^_^）。
我觉得这个可以类比之前的微软和Borland的关系，API是Windows，但是IDE是Borland的，各专所长了。可惜（或者庆幸）后来微软发力一下把Borland打得满地找牙一蹶不振，不过这是题外话了，略过......
对了，我有可能会对这封邮件整理下发到博客了，也希望其他网友能评点一二给你出主意。今晚本来想看下easy_monkey的知识了，给你写这个email变成临时性总结了。^_^
给金阳光老师评论的回复如下（关于MonkeyRunner的个人观点）
-----------------------------------------------------------------------------------------------------------------
回复haorenmin2008：首先膜拜下，金老师大驾光临蓬荜生辉啊！
对于后者，确实如此，UIAutomator需要API Level17（包含）以上。
对于前者，因为还没有MonkeyRunner的项目经验，所以是否很强大我就不敢妄加评论了，但是在我近来的tryout过程中，鄙人有以下的一些不成熟的认知：
1. 感觉功能不是很稳定，之前尝试一个MonkeyDevice的getProperty方法，竟然有时成功有时失败。
2. 性能不好，特别是当我们要用到hierarchyviewer的功能的时候很明显。
3. 只能用MonkeyImage的sameAs做截屏的对比，虽然加上hierarchyviewer后可以用它的getText，但还是很有限。
4. 控件定位方面主要是坐标点和HierarchyViewer提供的根据ID。前这儿在UI布局稍微有调整位置的话就需要跟着变动，没有像其他控件类框架那样做高层抽象除非换控件不然都不需要怎么变动；后者的话很多控件是没有id或者是有多个控件id相同的。
5. 可调试性也不强（起码我摸索了这几天没有发现一个很好的调试方法，比如IDE Ecilpse等的集成调试方法）
6. HierarchyViewer的稳定性也让我担忧，碰到过几次取控件信息的时候报exception的。
7. 资料稀缺，不仅网络，google也一样
8. Google支持让人觉得摸不着头脑，sdk给出的API和官方提供的API竟然不一致，以MonkeyDevice为例子，而sdk多出来的API竟然还不能用，google出来的信息不超过10个page，还要很多都是重复的石沉大海的网友报的问题。
9. 再一个的我真心搞不懂为什么本身java写的库非要搞个jython来调用，首先我不说性能损耗（这点肯定是有的，native库当然用native语言调用效率最好嘛），我想在eclipse上对以下的"device."做自动补全是做不到的“device = MonkeyRunner.waitForConnection()\n device.",而只有直接调用个构造函数实例化的device = MonkeyDevice（xxx）才能做到，这个我不相信是我配置的问题，换了个jython标准编译器以调用标准库问题同样存在。