第一部分 预备知识
第1章 插件化技术的昨天、今天与明天
这是最好的时代，国内各大应用市场对插件化技术的态度是开放的，因此，国内各大互联网App无一不有自己的插件化框架。有了开放的环境，才会有无数英雄大展身手，在Android插件化的领域中出现百家争鸣、百花齐放的局面。
这是最坏的时代，随着插件化技术在中国的普及，你会发现，去中国的各大互联网公司面试，一般都会聊聊插件化的技术。这就使得开发人员要去了解Android底层的知识，这无形中增加了学习难度。
本章将介绍插件化的概念、历史及应用，为后续学习插件化技术，提供基础。
1.1 插件化技术是什么
一个游戏平台，比如联众，支持上百种游戏，如象棋、桥牌、80分。一个包括所有游戏的游戏平台往往有上百兆的体积，需要下载很卡时间，但是用户往往只玩其中的1～2款游戏。让用户下载并不会去玩的上百款游戏，是不明智的做法。此外，任何一个游戏更新或者新上线一个游戏，都需要重新下载数百兆的安装包，也会让用户抓狂。
所以，游戏平台必然采用插件化技术。
通常的做法是，只让用户下载一个十几兆大小的安装包，其中只包括游戏大厅和一个全民类游戏，如“斗地主”。用户进入游戏大厅，可以看到游戏清单，点击“80分”就下载80分的游戏插件，点击“中国象棋”就下载中国象棋的游戏插件，这称为“按需下载”。这就需要插件化编程，不过这是基于电脑上的游戏平台，是一个个exe可执行文件。
在Android领域，是没有exe这种文件的。所有的文件都会被压缩成一个apk文件，然后下载到本地。Android应用中所谓的安装App的过程，其实就是把apk放到本地的一个目录，然后使用PMS读取其中的权限信息和四大组件信息。所以Android领域的插件化编程，与电脑上的软件的插件化编程是不一样的。
其实，在Android领域，对于游戏而言，用的还真不是插件化技术，而是从服务器动态下发脚本，根据脚本中的信息，修改人物属性，增加道具和地图。
Android插件化技术，主要用在新闻、电商、阅读、出行、视频、音乐等领域，比如说旅游类App，因为涉及下单和支付，所以算是电商的一个分支，旅游类App可以拆分出酒店、机票、火车票等完全独立的插件。
1.2 为什么需要插件化
在那山的这边海的那边有一群程序员，
他们老实又胹腆，
他们聪明又有钱。
他们一天到晚坐在那里熬夜写软件，
饿了就咬一口方便面。
哦苦命的程序员，
哦苦命的程序员，
只要一改需求他们就要重新搞一遍，
但是期限只剩下两天。
这首改编自《蓝精灵》主题曲的《程序员之歌》，道出了中国互联网行业的程序员现状。
就在Android程序员疯狂编写新需求之际，自然会衍生出各种bug，甚至是崩溃。App有bug，会导致用户下不了单，而一旦崩溃，那就连下单页面都进不去，因此我们要在最短时间内修复这些问题，重新发版到Android各大市场已经来不及，每分每秒都在丢失生意，因此，Android插件化的意义就体现出来了，不需要用户重新下载App，分分钟就能享受到插件新的版本。
另一方面，如果要和竞争对手抢占市场，那么谁发布新功能越快越多，对市场对用户的占有率就越高。如果隔三岔五就发布一个新版本到Android各大市场，那么用户会不胜其烦，发版周期固定为半个月，又会导致新功能长期积压，半个月后才能让用户见到，而竞争对手早就让用户在使用同样的新功能了。这时候，如果有插件化技术支持，那么新功能就可以在做完之后立刻让用户看到，这可是让竞争对手闻风丧胆的手段。
1.3 插件化技术的历史
2012年7月27日，是Android插件化技术的第一个里程碑。大众点评的屠毅敏（Github名为mmin18），发布了第一个Android插件化开源项目AndroidDynamicLoader
，大众点评的App就是基于这个框架来实现的。这是基于Fragment来实现的一个插件化框架。通过动态加载插件中的Fragement，来实现页面的切换，而Activity作为Fragement的容器却只有一个。我们也是在这个开源项目中第一次看到了如何通过反射调用AssetManger的addAssetPath方法来处理插件中的资源。
2013年，出现了23Code。23Code提供了一个壳，在这个壳里可以动态下载插件，然后动态运行。我们可以在壳外编写各种各样的控件，在这个框架下运行。这就是Android插件化技术。这个项目的作者和开源地址，我不是很清楚，如果作者恰巧读到我这本书，请联系我，咱们一起喝杯咖啡。
2013年3月27日，第16期阿里技术沙龙，淘宝客户端的伯奎做了一个技术分享，专门讲淘宝的Atlas插件化框架，包括ActivityThread那几个类的Hook、增量更新、降级、兼容等技术。这个视频，只是从宏观来讲插件化，具体怎么实现的并没说，更没有开源项目可以参考。时隔5年再看这个视频，会觉得很简单，但在2013年，这个思想还是很先进的，毕竟那时的我还处在Android入门阶段。
2014年3月30日8点20分，是Android插件化的第二个里程碑。任玉刚开源了一个Android插件化项目dynamic-load-apk，这与后续介绍的很多插件化项目都不太一样，它没有对Android系统的底层方法进行Hook，而是从上层，也就是App应用层解决问题——通过创建一个ProxyActivity类，由它来进行分发，启动相应的插件Activity。因为任玉刚在这个框架中发明了一个that关键字，所以我在本书中把它称为that框架。其实作者不喜欢我给他的最爱起的这个外号，他一直称之为DL。曾经和玉刚在一起吃饭聊天，他感慨当年如何举步维艰地开发这个框架，因为2014年之前没有太多的插件化技术资料可以参考。
that框架一开始只有Activity的插件化实现，后来随着田啸和宋思宇的加入，实现了Service的插件化。2015年4月that框架趋于稳定。那时我在途牛做App技术总监，无意中看到这个框架，毅然决定在途牛的App中引入that框架。具体实施的是汪亮亮和魏正斌，他们当时一个初为人父另一个即将为人父，还是咬牙把这个that框架移植到了途牛App中。that框架经受住了千万级日活App的考验，这是它落地的第一个实际项目。
与此同时，张涛也在研究插件化技术，并于2014年5月发布了他的第一个插件化框架CJFrameForAndroid。它的设计思想和that框架差不多，只是把ProxyActivity和ProxyService称为托管所。此外，CJFrameFor-Android框架还给出了Activity的LaunchMode的解决方案，这是对插件化框架一个很重要的贡献，可以直接移植到that框架中。
2014年11月，houkx在GitHub上发布了插件化项目android-pluginmgr，这个框架最早提出在AndroidManifest文件中注册一个StubActivity来“欺骗AMS”，实际上却打开插件中的ActivityA。但是作者并没有使用对Instrumnetation和ActivityThread的技术进行Hook，而是通过dexmaker.jar这个工具动态生成StubActivity, StubActivity类继承自插件中的ActivityA。现在看来，这种动态生成类的思想并不适用于插件化，但在当时能走到这一步已经很不容易了。
同时，houkx还发现，在插件中申请的权限无法生效，所以要事先在宿主App中申请所有的权限。android-pluginmgr有两个分支——dev分支和master分支。作者的插件化思想位于dev分支。后来高中生Lody参与了这个开源项目，把android-pluginmgr设计为对Instrumnetation的思想进行Hook，体现在master分支上，但这已是2015年11月的事情了。
2014年12月8日有一个好消息，那就是Android Studio1.0版本出现了。Android开发人员开始逐步抛弃Eclipse，而投入Android Studio的怀抱。Android Studio借助于Gradle来编译和打包，这就使插件化框架的设计变得简单了许多，排除了之前Eclipse还要使用Ant来运行Android SDK的各种不便。
时间到了2015年。高中生Lody此刻还是高二学生。他是从初中开始研究Android系统源码的。他的第一个著名的开源项目是TurboDex，能够以迅雷不及掩耳之势加载dex，这在插件化框架中尤其好用，因为首次加载所有的插件需要花很久的时间。
2015年3月底，Lody发布插件化项目Direct-Load-apk。这个框架结合了任玉刚的that框架的静态代理思想和Houkx的pluginmgr框架的“欺骗AMS”的思想，并Hook了Instrumnetation。可惜Lody当时还是个学生，没有花大力气宣传这个框架，以至于没有太多的人知道这个框架的存在。Lody的传奇还没结束，后来他投身于VirtualApp，这是一个App，相当于Android系统之上的虚机，这是一个更深入的技术领域，我们稍后再提及。
2015年5月，limpoxe发布插件化框架Android-Plugin-Framework。
2015年7月，kaedea发布插件化框架android-dynamical-loading。
2015年8月27日，是Android插件化技术的第三个里程碑。张勇的DroidPlugin问世了。张勇当时在360的手机助手团队，DroidPlugin就是手机助手使用的插件化框架。这个框架的神奇在于，能把任意的App都加载到宿主里面去。你可以基于这个框架写一个宿主App，然后就可以把别人写的App都当作插件来加载。
DroidPlugin的功能很强大，但强大的代价就是要Hook很多Android系统的底层代码，而且张勇没有给DroidPlugin项目加任何说明文档，导致这个框架不太容易理解。网上有很多人写文章研究DroidPlugin，但其中写得最好的是田维术。他当时就在360，刚刚毕业转正，写出一系列介绍DroidPlugin思想的文章，包括Binder和AIDL的原理、Hook机制、四大组件的插件化机制等。
2015年是Android插件化蓬勃发展的一年，不光有that框架和DroidPlugin，很多插件化框架也在这个时候诞生。
OpenAtlas这个项目是2015年5月发布在Github上的，后来改名为ACDD。里面提出了通过修改并重新生成aapt命令，使得插件apk的资源id不再是固定的0x7f，可以修改为0x71这样的值。这就解决了把插件资源合并到宿主HostApp资源后资源id冲突的问题。
OpenAtlas也是基于Hook Android底层Instrumentation的execStartActivity方法，来实现Activity的插件化。此外，OpenAltas还Hook了ContextWrapper，在其中重写了getResource等方法，因为Activity是ContextWrapper的“孙子”，所以插件Activity就会继承这些getResource方法，从而取到插件中的资源——这种做法现在已经不用了，我们是通过为插件Activity创建一个基类BasePluginActivity并在其中重写getResource方法来实现插件资源加载的。
携程于2015年10月开源了他们的插件化框架DynamicAPK，这是基于OpenAltas框架基础之上，融入了携程自己特殊的业务逻辑。
2015年12月底，林光亮的Small框架发布，他当时在福建一家二手车交易平台，这个框架是为这个二手车平台的App量身打造的，主要特点如下：
□ Small把插件的ClassLoader对应的dex文件，塞入到宿主HostApp的ClassLoader中，从而HostApp可以加载任意插件的任意类。
□ Small框架通过Hook Instrumentation来启动插件的Activity，这一点和DroidPlugin相同，那么自然也会在AndroidManifest中声明一个StubActivity，来“欺骗AMS”。
□ Small框架对其他三大组件的支持，需要提前在宿主HostApp的AndroidManifest中声明插件的Service、Receiver和ContentProvider。
□ Small对资源的解决方案独树一帜。使用AssetManager的addAssetPath方法，把所有插件的资源都合并到宿主的资源中，这时候就会发生资源id冲突的问题。Small没有采用Atlas修改AAPT的思路，而是在生成插件R.java和resources.arsc这两个文件后，把插件R.java中所有资源的前缀从0x7f改为0x71这样的值，同时也把resources.arsc中出现0x7f的地方也改为0x71。
随着2015年的落幕，插件化技术所涉及的各种技术难点都已经有了一种甚至多种解决方案。在这一年，插件化技术领域呈现了百家争鸣的繁荣态势。这一时期以个人主导发明的插件化框架为主，基本上分为两类——以张勇的DroidPlugin为代表的动态替换方案，以任玉刚的that框架为代表的静态代理方案。
就在2015年，Android热修复技术和React Native开始进入开发者的视线，与Android插件化技术平分秋色。Android插件化技术不再是开发人员唯一的选择。
从2016年起，国内各大互联网公司陆续开源了自己研发的插件化框架。这时候已经没有什么新技术出现了，因为插件化所有的解决方案都已经在2015年由个人开发者给出来了。互联网公司是验证这些插件化技术是否可行的最好的平台，因为他们的App拥有动辄千万用户的日活。
按时间顺序列举插件化框架如下：
2016年8月，掌阅推出Zeus。
2017年3月，阿里推出Atlas。
2017年6月26日，360手机卫士的RePlugin。
2017年6月29日，滴滴推出VisualApk。
仔细读这些框架的源码会发现，互联网公司开源的这些框架更多关注于：
□ 插件的兼容性，包括Android系统的升级对插件化框架的影响，各个手机ROM的不同而对插件化的影响。
□ 插件的稳定性，比如各种奇葩的崩溃。
□ 对插件的管理，包括安装和卸载。
斗转星移，时光荏苒，虽然只有几年时间，但各个插件化框架已经渐趋稳定，现在做插件化技术的开发人员，只需要关注每年Android系统版本的升级对自身框架的影响，以及如果消除这种影响。
随着插件化领域的技术基本成型，我身边很多做插件化的朋友都开始转行，有的人还在Android这个领域，比如张勇基于他的DroidPlugin框架，在做他的创业项目闪电盒子；有的人转入区块链，每天沉浸于用GO语言写智能合约。
谨以此文献给那些在插件化领域中做出过贡献的朋友们，包括开源框架的作者，以及写文章传经布道的作者。我的见识有限，有些人、有些框架、有些文章可能会没有提及，欢迎广大读者多多指正。
1.4 插件化技术的用途到底是什么
我们曾经天真地认为，Android插件化是为了增加新功能，或者增加一个完整的模块。费了不少时间和精力，等项目实施了插件化后，我们才发现，插件化80%的使用场景，是为了修复线上bug。在这一点上，插件化与Tinker、Robust这类热修复工具拥有相同的能力，甚至比热修复工具做得更好。
App每半个月发一次版，新功能上线，一般都会等这个时间点。另一方面，很多公司的Android发版策略是受iPhone新版本影响的，新功能要等两个版本一起面世，那就只有等Apple Store审核通过iPhone的版本，Android才能发版。所以，真的不是那么着急。
在没有插件化的年代，我们做开发都是战战兢兢的，生怕写出什么bug，非常严重的话就要重新发版本。有了插件化框架，开发人员没有了后顾之忧，于是App上线后，每个插件化，每天都会有一到两个新版本发布。Android插件化框架，已经沦落为bug修复的工具。这是我们不愿看到的场景。
其实，插件化框架更适合于游戏领域。比如王者荣耀，经常都会有新皮肤，或者隔几天上线一个新英雄，调整一下英雄的数据，这些都不需要重新发版。
插件化还有一种很好的使用场景，那就是ABTest，只是没有深入人心罢了。当产品经理为两种风格的设计举棋不定时，那么把这两种策略做成两个插件包，让50%的用户下载A策略，另外50%的用户下载B策略，一周后看数据，比如说页面转化率，就知道哪种策略更优了。这就是数据驱动产品。
随着业务线的独立，Android和iOS团队拆分到各自的业务线，有各自的汇报关系，因此有必要把酒店机票火车票这些不同的业务拆分成不同的模块。在Android组件化中，模块之间还是以aar的方式进行依赖的，所以我们可以借助Maven来管理这些aar。
Android的这种组件化模型，仅适用于开发阶段，一旦线上有了bug，或者要发布新功能，那就需要将所有模块重新打包一起发布新版本。
Android组件化再往前走一步，就是插件化。此时，各个业务模块提供的就不再是aar了，而是一个打包好的apk文件，放在宿主App的assets目录下。这样，发版后，某个模块有更新，只需重新打包这个模块的代码，生成增量包，放到服务器上供用户下载就可以了。这才是Android插件化在企业级开发中的价值所在。一般的小公司只做了Android组件化，没有做插件化，所以体会不到这个好处，这是因为插件化开发成本很高，投入产出比很低。
1.5 更好的替代品：React Native
2015年，React Native（RN）横空出世，当时并没有多少人关注它，因为它还很不成熟，甚至连基本的控件都没几个。后来随着RN项目的迭代，功能日趋完善，虽然迄今为止还没有一个1.0的release版本，我们还是欣喜地发现，这个东西就是Android和iOS的插件化啊。
外国人和中国人的思路不一样。就好像国际象棋与中国象棋不一样。当我们投入大量人力去钻研怎么Hook Android系统源码的时候，外国人走的是另一条路，那就是映射，让Android或iOS中的每个控件，在RN中都能找到相对应的控件。RN是基于JavaScript代码来编写的，打包后放到服务器，供Android和iOS的App下载并使用。
RN比Android插件化更好的地方在于它还支持iOS，因此最大程度地实现了跨平台。于是当我们一厢情愿地以为Android插件化多么好用，而对iOS如何发布新功能一筹莫展时，便有了RN这个更好的选择。至于性能，二者差别不大，RN在iOS和Android上都很流畅，这一点不用担心。
对于中小型公司和创业公司而言，缺少人力和财力自己研制一套插件化框架，一般就采用国内比较稳定的、开源的、持续更新的插件化框架。但iOS没有这方面的技术框架，尤其是在jsPatch热修复被AppStore明令禁止了之后，最好的选择就是RN。只要招聘做JavaScript前端的技术人员，就能快速迭代、快速上线了，完全不受发版的限制。我是从研发的岗位走出来，在国内做了两年培训，全国各地走了上百家公司，包括大型国企、二三线互联网公司、传统行业，我发现国内90%的公司都属于这种类型，国内对RN的需求远大于Android插件化。
关于RN的话题，至少要一本书才能说清楚。本书主要介绍Android插件化，这里只指出Android插件化不如RN的地方。
1.6 只有中国这么玩吗
有读者会问，Android插件化在中国如火如荼，为什么在国外却悄无声息？打开硅谷那些独角兽的App，都没有发现插件化的影子。
一方面原因是，国外人都使用Google Play，这个官方市场不允许插件化App的存在，审核会不通过，这就很像Apple Store了。
另一方面原因是，国外没有这样的需求。所以当你发现国外某款App显示数据错误了，或者莫名其妙崩溃了，就算你反馈给他们，得到的也是一副坐看闲云、宠辱不惊的回复——下个版本再修复吧。下个版本什么时候？一个月后。
这就和中国国内的App境遇不同了。在互联网公司，特别是有销售业务的公司，任何数据显示的错误或者崩溃，都会导致订单数量的下降，直接影响的是钱啊。所以，我经常半夜被叫醒去修bug，然后快速出新版本的插件包，避免更多订单的损失。
国内的一二线互联网公司，会花很多钱雇佣一群做插件化框架的人，框架设计完，他们一般会比较闲。在Android每年发布新版本的时候，他们会很忙，去研究新版本改动了哪些Android系统源码，会对自家公司的插件化框架有什么影响。从长期来看，公司花的这些钱是划算的，基本等于没有插件化而损失的订单数量的价值。
而国内的中小型公司以及创业公司，没有额外的财力来做自己的插件化框架，一般就采用国内比较稳定的、开源插件化框架。后来有了RN，就转投RN的怀抱了。
就在中国的各路牛人纷纷推出自家的Android插件化框架之际，国外的技术人员在研究些什么呢？
国外的技术人员比较关注用户体验，所以在国外Material Design大行其道，而在中国，基本是设计师只设计出iOS的样稿，Android保持做的一样就够了。国外的技术人员比较关注函数式编程，追求代码的优雅、实用、健壮、复用，而不像国内的App，为了赶进度超越竞争对手，纯靠人力堆砌代码，甚至带bug上线，以后有时间了再进行重构，而那时当初写代码的人也许已经离职了。
所以，当硅谷那边层出不穷地推出ButterKnife、Dagger、OKHttp、Retrofit、RxJava的时候，国内能拿出来与之媲美的只有各种插件化框架和热修复框架，以及双开技术。
1.7 四大组件都需要插件化技术吗
在Android中，Activity、Service、ContentProvider和BroadcastReceiver并称为四大组件。四大组件都需要插件化吗？这些年，我是一直带着这个问题做插件化技术的。
我所工作过的几家公司都属于OTA（在线旅游）行业。这类App类似于电商，包括完整的一套下单支付流程，用得最多的是Activity，达数百个；Service和Receiver用得很少，屈指可数；ContentProvider根本就没用过。
国内大部分App都是如此。根据技术栈来划分App行业：
□ 游戏类App，有一套自己的在线更新流程，很多用的是Lua之类的脚本。
□ 手机助手、手机卫士，这类App对Service、Receiver、ContentProvider的使用比较多。所以四大组件的插件化都必须实现。
□ 音乐类、视频类、直播类App，除了使用比较多的Activity，对Service和Receiver的依赖很强。
□ 电商类、社交类、新闻类、阅读类App，基本是Activity，其他三大组件使用不是很多，可以只考虑对Activity插件化的支持。
我们应该根据App对四大组件的依赖程度，来选择合适的插件化技术。四大组件全都实现插件化固然是最好的，但是如果App中主要是Activity，那么选择静态代理that框架就够了。
1.8 双开和虚拟机
既然插件化会慢慢被RN所取代，那么插件化的未来是什么？答案是，虚拟机技术。
各位读者应该有过在PC机上安装虚拟机的经历。只要电脑的内存足够大，那么就可以同时打开多个虚拟机，在每个虚拟机上都安装QQ软件，使用不同的账号登录，然后自己跟自己聊天。
在Android系统上，是否也能支持安装一个或多个虚拟机呢？国内已经有人在做了，我所知道的，一个是高中生Lody（当你阅读这本书的时候，他应该已经是大学生了吧），他有一个很著名的开源项目VirtualApp，这个项目现在已经商业化运作了。另一个是DroidPlugin的作者张勇，他现在创业专职做这个，在DroidPlugin的基础上研发了闪电盒子，可以极速加载各种apk。
有了这样一个虚拟机系统，我们就可以在手机上打开两个不同账号的QQ，自己和自己聊天了。
我们称同时打开一个App的多个分身的技术叫“双开”。现在国内有些手机系统已经支持双开技术了，可以在设置中看到这一选项。
关于双开和虚拟机的技术，我们就介绍这么多，毕竟这已经不是本书所涉及的技术范畴了。
1.9 从原生页面到HTML 5的过渡
无线技术越来越成熟，已经从2012年时的初步开荒，发展到现在的蔚为壮观。对于国人来说，我们比较关注的是：热修复、性能、开发效率、App体积、数据驱动产品。这些点目前都已经有了很好的解决方案，也涌现出RxJava、LeakCanary这样优秀的框架。这个话题很大，本文就不展开说了。
由App技术的无比繁荣，回想起我2004年刚工作的时候，IT行业正从CS（Service-Client）转型为BS（Browser-Server）。2004年之前大都是CS这样的软件，比如Windows上安装一个联众的客户端就可以和网友斗地主了，后来互联网的技术成熟起来了，就把原先的系统都搬到网站上，这就是BS。
后来BS做多了，大家觉得BS太“单薄”，很多功能不支持，不如CS，于是就提出SmartClient的概念，也就是智能客户端，Outlook就是一个很好的例子，你可以脱机读和写邮件，没网络也可以，什么时候有网络了，再将写好的邮件发送出去。
再后来Flash火起来了，这个本来是网页制作工具三剑客之一，却阴差阳错地成为了网页富客户端的鼻祖。在此基础上便有了Flex，现在还有些公司在使用。微软这时候提出了Silverlight，是搭载在网页上的。与此同时，JavaScript也在发力，并逐渐取代前者，成为富客户端的最后赢家，那时候《JavaScript设计模式》一书非常畅销。
JavaScript在2004年仅是用来做网页特效的。时至今日，我们发现，JavaScript经历了Ajax、jQuery、ECMAScript从1到6、Webpack打包，以及Angular、React、Vue三大主流框架，已经变得无比强大，被封装成一门“面向对象”的语言了。
前面铺垫了那么多，就是想说明App也在走同样的发展道路，先沉淀几年，把网站的很多技术都搬到App上，也就是目前的发展阶段，差不多该有的也都有了。下一个阶段就是从CS过渡到BS, Hybird技术就类似于BS，但是有很多缺陷，尤其是Web Browser性能很差，然后便出现了React Native, HTML 5很慢，但可以把HTML 5翻译成原生的代码啊。再往前发展是什么样，我不知道，但是这个发展方向是很清晰的。一方面，Android和iOS技术不会消亡；另一方面HTML 5将慢慢成为App开发的主流。
1.10 本章小结
本章回顾了Android插件化技术的发展历史，基本上分为两大流派：静态代理和动态替换，所有的插件化框架都基于此。看完这段历史你会发现，这门技术也不是一蹴而就的，期间也经历了从无到有，以及逐步完善的过程。
插件化技术不仅仅用于修复bug和动态发布新功能，我们在研究插件化技术的过程中，顺带开发出了Android虚拟机和双开技术，这是一个新的技术领域，可以摆脱Android原生系统的束缚，更快地运行App。
本章还谈到了ReactNative，它也能修复bug和动态发布新功能，和Android插件化有异曲同工之妙。具体该采用哪门技术，取决于研发团队以H5为主还是以Android为主，取决于是否要发布到Google Play。