A. android应用插件式开发
不解释！！！
https://github.com/mmin18/AndroidDynamicLoader
B. Android插件式开发，动态加载apk是怎么实现的呢请大神指教
你说的插件式开发应该是那种用
html5
来开发安卓吧，就是会提供一些常用的模块，比如
下拉刷新，列表，扫描二维码等等，你只需要引入模块就可以使用了，开发相对简单迅速。
你可以看看
apicloud，还可以。
C. 如何使用ApkPlug进行Android平台下模块化开发
步骤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路径下。
http://jingyan..com/article/ca41422fc2ce471eae99ed3d.html
D. 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 。
E. 谷歌官方支持android插件化开发吗
要想从Eclipse迁移到Android Studio，推荐阅读这份迁移指南来理解新的项目结构以及如何通过Gradle构建Android项目。如果满足先决条件，那么可以使用Android Studio导入Eclipse项目，然后执行验证（构建与运行）来确保一切都是正确的。如果有问题，Google建议调整一下Eclipse ADT项目，然后再次导入。
建议那些还想继续使用Eclipse的开发者们看看Andmore项目并参与进去，该项目旨在让Android工具能够继续在Eclipse中发挥作用。Andmore包含了JDT、CDT与ADT，并且支持Maven与Ant，同时还计划对Gradle提供支持，它现在可以与Mylyn、EGit与GitHub集成。
众所周知，Google启动了很多项目，提出了很多大胆的创新，不过很多时候都会轻易扼杀一个事实证明不可行的项目，Reader、Wave、Buzz、Knol、Code、Dart Editor以及Chrome Dev Editor等莫不如此。这与很多软件开发者的做法大相径庭，后者会对那些缺乏动力的项目采取跟进的方式，从而确保项目能够重现生机。虽然Google的这种灵活的做法已经融入到了公司的DNA当中，但很多开发社区对此还是感到非常不舒服。我们看到了很多开发者的评论，他们不愿意参与Google
F. 怎么将 Android 程序做成插件化的形式
有个框架叫apkplug
就是apk插件式的开发框架
其实原理都一样,因为android不支持动态的增加jar
因此插件需要做成一个单独的apk,框架APK去查找系统中的其它插件
然后结合一起调用即可
G. 如何评价360的Android插件化框架RePlugin
APP推广渠道主要付费BD合作两种式: 先说说付费推广吧(IOS&Android) •IOS(appstore&越狱) APPStore刷榜 1.找刷榜技术公司排名刷top榜单(其实作弊式让appstore载APP排名靠前)排名越靠前让越看产品带更自用户刷榜排名越高价格越高双十候总榜TOP501万6千块/前礼拜TOP50价格已经要3万左右/ PS:建议使用刷榜存风险 1、appstore鉴定刷榜收警告信超3产品能架 2、且刷榜市场传闻目前家北京公司刷榜技术十稳定能刷刷 3、刷榜ROI高容易让营销团队其产依赖降低其营销渠道兴趣优化万刷榜 网盟&平台类 1.积墙:盟、力美、米、点入……结算式CPA(激/注册)渠道本身用户价值低用于appstroe冲榜效较明显需求量需要同接进几公司API 2.平台:admob(google)、inmobi……in-APP展示类banner、插屏广告结算式CPC竞价用于推广品宣较合适缺点global公司都提供用户ID准确评估用户本想要监测数据产品嵌入SDK造APP数据公给情况嵌入SDK完全属于盲投优化效理想目前看投放平台公司游戏类居都土豪呀另外些平台海外资源相错滴据说微信类推海外效错哦~ 3.网盟&代理:adsage、亿玛……结算式CPACPC网盟用户量缺点用户质量控(数据能偶掺水情况现-_-#) 4.移DSP:目前知道力美mediav做移DSP刚起步两家公司同自都建议我做没历史数据优化依据少价格高顺说媒体资源般都接入google、inmobi些平台移DSP未比较靠谱投放式清楚静静期待吧~ 应用推荐类 1.APPStore:金山、限免全、搞趣、APP123……结算式CPT由于IOS推广渠道资源限价格直涨金山14合作都需要走度框架即使按照CPA合作电商类价格要12块/激类渠道用户质量错渠道基本掺水数据比较靠谱滴期投放用户产审美疲劳推广效慢慢降些今条百思姐些应用内容植入谈CPS前百思姐见着口袋购物身影 2.越狱类:PP助手、同步推、快用、91......结算式CPT沟通CPA合作几家量错自木推越狱渠道所解少(补课) •Android 网盟&平台 1.积墙:情况android积墙建议做原android像IOS应用商店APPStore展示资源相较需通积墙冲榜(BTW想要拉高某特定市场排名买些载量万能淘宝能找提供服务商家前1万载量要50元性价比高要别市场发现^_^)说要问既android用积墙冲榜干嘛存呀嘿嘿句叫做切存都合理滴~KPI激用户数量且要真用户要买积墙呀物美价廉渠道啊...... 2.网盟&平台:亿玛、安沃、adsage、微创...…按CPA购买跟商定CPA价格(价格越高获取用户数越啦)能定KPI例留存低于**或24购物率低于**等约定用户质量保障IOS平台类网盟inmobi,adwords类公司购买 3.代理公司:微创、adsage、AdTouch些代理公司产品丰富合作式CPC(图片展示类CPA(般应用推荐位置)、代理些应用市场资源比AT跟安卓91、360市场关系比较合作让其代理刊例价格基础打折啥另外推广费用签框架每月都优先选择媒体资源权利哎土豪啊 应用市场 1.主流应用市场些:360、豌豆荚、网络、安卓91、米安智些google-play、N、机锋类市场流量相少些应用市场资源售卖式CPT、CPD(载)CPA等合作发现直接买CPTROI肯定亏,借用安卓市场举例吧计算激用户本需要10块左右于电商说偏高或许说电商说价格高游戏类APP说便宜啊接想说应用市场跟游戏聊CPT滴面游戏应用市场基本要求联运或者CPS做游戏我想肯定懂酸呀再说CPA合作合作般没所谓刊例价格需要跟市场商定价格比5块钱激量般市场剩余流量所每流量少起伏且像91市场要求产品载激转化能低于35%能要求自量需要结算虽条条框框CPA比CPT合算所框框忍吧 2.按竞价CPD合作应用市场:豌豆荚、网络米三市场都CPD投放操作台根据提示步步操作通载起拍价0.5元CPA(激)本概8块左右同APP获取用户本肯定差异CPD合作相较于CPTCPA更灵控平控制本保证ROI,遇节庆典啥调高价格获取较流量想补充说豌豆荚米流量都市场本身流量网络则自网络手机助手网络网盟属于春华条产品线 预装机 1.块我自没尝试般找品牌厂商、运营商、手机销售渠道rom制作自APP内置操作系统根据文件包、产品知名度激数支付同cpa费用做预装机建议:1、找偏游服务商游(厂)装机零售商能重新刷钱白花另外找品牌厂商直接合作第合作谈判艰难第二装机消费者手周期2、要考虑清楚自APP用户使用机型比高尚APP刷500块部手机浪费面向民工游戏要刷三星划 纯花钱渠道主要面说些接着要说通BD合作式获取些性价比较高或免费流量 •换量:APP相互导流量比众点评APP面推荐安居客般情况APP猜喜欢或热门应用推荐Tab位置用跟其APP置换流量(APP够热门些位置广告位售更像墨迹气美图秀秀模式) •联合运营:比聚美跟美相机做晒素颜照即登陆聚美APP领取价值**元面膜盒比美相机提供广告位宣传聚美提供奖品赞助等(纯粹举例雷同纯属巧合)首先要明确双目标各自能提供资源尽量双赢提前联合非性 •针手机应用市场BD合作: 1、每应用市场都首发特权合作APP更新版本早几某应用市场发布市场通免费给1-3首发专区位置配合应用市场做些比给自米商场用户双倍积或参与应用市场运营比十假游市场般做些跟旅行相关APP专题候跟运营员熟悉提前通知比较容易免费些专题(至于跟家打片家各显神通吧) 2、跟应用市场换量所APP应用市场需要增加流量要控制本情况换量各应用市场获取流量普遍途径跟市场换量两种情况首先像豌豆荚接受自APP本身流量说跟豌豆荚换量能自APP面给导流量其像跟米合作比较Open愿意接受非APP本身流量哪怕花钱网盟买用户给要真实行应用市场根据给带用户数量(通激数量)复同等价值广告位比给米导5000用户给banner,价值概1万 用请公表扬疏漏差错请私信批评^_^ 作者:StarWalking 作PM移互联网混沌初期连市场同都迷糊候自始尝试各种推广式扛真枪打实弹推千万级别项目~~~搞留存60项目~~ 面我几重点说项目推广吧: 1.各平台都市场 win7:跃终端都千万没玩必要 ios:市场单itunes越狱ios7向已经足10%现象应该发者市场妥协吧搞付费越越少 ios第三市场我简单推荐几:搞趣限免师91,360金山电池 android:安卓市场相比较元市场政策问题google play没像itunes担起重戏终端市场运营商介入变更加复杂我android市场划: A官市场google play B第三市场机锋安卓安智等 C终端品牌市场智汇云三星市场金立市场等 D room市场Android 4.3Jelly Bean(冻豆)等等 E运营商市场移MM等等 Fwap站PC客户端web站快平台流量站 android要载手机安装所GHIJK类市场省略互联网朋友应该都知道其推广类型 2.特殊市场 我觉钻空民族任何谐环境都打破平衡我推荐两任何平台都适用强市场: A积墙等广告商刷量市场 B肉刷市场 C劣质服务器刷量市场(高危) D真机刷量市场(ios用) E push市场 F恶意软件潜伏安装市场 做互联网做两事抄刷 3.流量共享 貌似每软件都应用推荐合理自资源置换 公司安排实习刷脸必要并且选择渠道精准性 4.线渠道 用户量少情况产品品牌概念未形所线推广都太扯淡形品牌型传播试试看核算CPA陈本 5.社化营销 现兴起种网络SNS推广式比较偏软式植入快速传播文字图片视频各SNS社区传播带高爆发流量能需要产品本身营造题性营销团队执行力我觉亲向放弃吧没啥碰运气 6.SNS享 接入主流社区享功能做自我营销功能我说家熟悉所APP都适合内容型产品或者产内容型产品试试例优伶画报魔漫相机啥理解 7.于团队建议 应该能涵盖移互联网主流推广模式于团队说除才外本能推广建议千万要全平台线团队精力根本负荷特别android平台变现能力强用户基数导致android渠道用户水比较低握产品转换率留存受渠道质量波影响建议先搞iosios推广本效验证产品需求否靠谱您itunes都勃起劝别做 光搞ios没前途像私密相册2013.团队5半做30万iphone用户本1万元推广值研究毕竟竞品比较 吧我觉起析志同道合加我~ 注:android第三渠道我见 android第三渠道我几类 1.论坛早批:机锋网安卓网安智网等 2.PC工具:豌豆荚91助手等 3.市场:应用汇等 4.巨介入:腾讯(等)网络(弱)360(强) 其实android第三放渠道五花八门我自统计共534~项收集够牛B吧呵呵 自:张巧忠
H. 包建强 为什么我说android插件化从入门到放弃
首先就是去写代码。有一个做Android的哥们升级为架构师，需要了解iOS这门技术，来问我怎么能迅速精通iOS，我就告诉他，别玩虚的，脚踏实地跟着iOS开发团队做几个需求，半年之后再来谈这个话题。Android和iOS的很多现金思想可以相互借鉴，我建议做一门技术的同学，也适当学习另一门技术。
咬着牙看开源项目。比如说JSPatch，怎么看？我有个建议，你看JSPatch的版本提交历史，从第一次提交看起，这时候的功能应该是最简单的，也是最容易看懂的，然后看历史每次提交都修改了哪些东西，你能搞清楚作者的思路是什么。
Android插件化虽然有被React Native取代的势头，但还是要搞清楚插件化所涉及的各种思想和技术。我这一年来的心得是，这是提高自身内功的极好办法。尤其是涉及到Android系统底层的各种Hook。
写技术博客吧。每天看文章只能是看过，一个月后能沉淀下来的没有多少，好记性不如烂笔头。一开始你可以转载或罗列精品文章的链接，慢慢的开始分享自己的心得，翻译些技术文章，技术水平提高是一个循序渐进的过程。
I. 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标准编译器以调用标准库问题同样存在。