【插件&热修系列】前世此生

引言

上一个阶段，咱们学习了gradle的基础系列知识，同时用了两个实战例子 来巩固所学的知识点；（PS：回顾戳这里>>）

前面的准备，更多的是为后面咱们实战android的插件或者热修作基础储备， 由于在插件/热修项目中，须要经过gradle的基础来进行编程，如：经过gradle实现插件生成等；

接下来，咱们将开始逐步进入插件/热修的领域，在这个阶段中咱们定义为“插件&热修系列”， 这个也是重要的基础之一，由于这里涉及比较多的安卓应用知识，底层知识等；

在咱们学习完“插件&热修系列”后，再结合上一个阶段学习的gradle技术知识，插件/热修等就能在项目中轻车熟路了

概要

本章咱们将了解插件&热修的前世此生，说白了就是历史发展过程，哈哈

第1个里程碑

AndroidDynamicLoader

（1）诞生背景，2012年7月27日大众点评的屠毅敏（Github名为mmin18），发布了第一个Android插件化开源项目 AndroidDynamicLoader

（2）机制，基于Fragment来实现的一个插件化框架，动态加载插件中的Fragement，来实现页面的切换

（3）插件中的资源，经过反射调用AssetManger的 addAssetPath 方法

（4）Github地址，github.com/mmin18/Andr… PS：这个是基于Ant的构建，由于12年的时候AS尚未出来，用的是eclipse

23Code

（1）诞生背景，2013年出现了23Code

（2）机制，23Code提供了一个壳，在这个壳里能够动态下载插件，而后动态运行；

（3）其余，23Code是一个自定义UI控件集合应用，直接下载一个自定义控件的demo，而且运行起来；项目的做者和开源地址目前没有找到，找到的朋友辛苦分享下～

Atlas

（1）诞生背景，2013年3月27日淘宝的Atlas插件化框架面世

（2）机制，经过反射和轻量的hook方案来实现模块的组件化，从而减小适配成本；同时将大量的工做放到了编译期，提升稳定性；如：ActivityThread那几个类的Hook、增量更新、降级、兼容等技术

（3）解决的痛点：

a) 容器化思路，解决大规模团队协做问题;，好比：业务开发，实现每一个业务在开发阶段独立编译、独立调试、独立运行，最后再以一个组件的形式集成到客户端中，每一个业务之间并行开发互不影响

b) 实现并行开发、快速迭代和动态部署，适用于 Android 4.x 以上系统版本的大小型 App 开发。

c) 线上修复，具有客户端动态发版和快速修复的能力

（4）github，github.com/alibaba/atl…

（5）官方教程，edu.aliyun.com/course/68/l…

第2个里程碑

dynamic-load-apk

（1）诞生背景，2014年3月30日，任玉刚的Android插件化项目dynamic-load-apk诞生， 一开始只有Activity的插件化实现，后来随着田啸和宋思宇的加入，实现了Service的插件化

（2）机制，从App应用层解决问题，经过建立一个ProxyActivity类由它来进行分发，启动相应的插件Activity；这种方案统称“静态代理方案”

（3）实战性，经受住了千万级日活App的考验（如：途牛App）

（4）Github：github.com/singwhatiwa…

CJFrameForAndroid

（1）诞生背景，2014年5月张涛的CJFrameForAndroid诞生

（2）机制，和《dynamic-load-apk》方案相似，都是采用的静态代理方案，同时还支持了下Activity的LaunchMode的解决方案

（3）注意，此框架再也不更新

（4）做者，blog.kymjs.com/

（5）博客，www.daimajiaoliu.com/daima/4717e…

android-pluginmgr

（1）诞生背景，2014年11月houkx发布了插件化项目android-pluginmgr

（2）机制，最先提出在AndroidManifest文件中注册一个StubActivity来“欺骗AMS”，实际上却打开插件中的ActivityA，可是有个短板，就是不太适用于插件化，以学习思想为主，哈哈～

（3）Github：github.com/houkx/andro…

（4）特殊的意义，从上面的《dynamic-load-apk》思惟，到这里的欺骗AMS思惟，到后面的hook直接欺骗AMS，实际上是一个思想的过分

（5）实战的案例，用在游戏行业的SDK中，具体见：segmentfault.com/a/119000001… ，神奇的这个实战思想和咱们如今用的思想相似，或许这个就是思想的碰撞吧

TurboDex

（1）诞生背景，高中生Lody发布框架TurboDex

（2）机制，结合了“静态代理思想” 和 pluginmgr框架的“欺骗AMS”的思想实现

（3）特色，快速加载dex方面作的比较好

（4）Github：github.com/asLody/Turb…

Android-Plugin-Framework

（1）诞生背景，2015年5月limpoxe发布插件化框架 Android-Plugin-Framework

（2）机制，按需hook，即须要用到哪些系统特性和api，就对哪些特性和api提供支持

（3）特色，免安装运行插件APK ，支持独立插件和非独立插件

（4）Github：github.com/limpoxe/And…

第3个里程碑

DroidPlugin

（1）诞生背景，2015年8月27日，张勇的DroidPlugin发布（360团队）

（2）机制，Hook不少Android系统的底层代码

（3）特色，能把任意的App都加载到宿主里面去；能够基于这个框架写一个宿主App，而后就能够把别人写的App都看成插件来加载；

（4）优势：

（a）宿主和插件彻底隔离，插件不依赖宿主，能够独立安装运行

（b）低入侵设计，插件不须要继承任何类

（c）插件apk和普通apk同样的，因此插件开发没有门槛

（d）集成简单，开发的时候集成简单，只须要三两个步骤便可集成到一个新的项目中

（e）资源彻底隔离，插件之间、与Host之间实现了资源彻底隔离，不会出现资源窜用的状况

（f）API低侵入性：极少的API。HOST程序只是须要一行代码便可集成Droid Plugin

（g）超强隔离：插件之间、插件与Host之间彻底的代码级别的隔离，不能互相调用对方的代码。通信只能使用Android系统级别的通信方法。
复制代码

（5）缺点：

（a）插件启动速度比较慢

（b）缺少对Native层的Hook，对某些带native代码的apk支持很差，可能没法运行

（c）没法在插件中注册一些具备特殊Intent Filter的4大组件

（d）主要问题仍是在机型的适配方面
复制代码

（6）GitHub：github.com/DroidPlugin…

（7）诞生背景连接：www.infoq.cn/article/201…

（8）系列博客源码分析：weishu.me/archives/

OpenAtlas

（1）诞生背景，2015年OpenAtlas项目面世（后来更名为ACDD）；bunnyblue同窗在研究手淘客户端以后, 发现Atlas部分混淆得不完全, 以后在此基础上捣鼓出了OpenAtlas.

（2）机制（同Atlas），经过反射和轻量的hook方案来实现模块的组件化，从而减小适配成本；同时将大量的工做放到了编译期，提升稳定性；如：ActivityThread那几个类的Hook、增量更新、降级、兼容等技术

（3）特色，经过修改并从新生成aapt命令，使得插件apk的资源id再也不是固定的0x7f，能够修改成0x71这样的值；解决了把插件资源合并到宿主HostApp资源后资源id冲突的问题

（4）博客系列分析：blog.imallen.wang/archives/pa…

（5）Github：github.com/HiWong/Open…

DynamicAPK

（1）诞生背景，2015年10月，携程的插件化框架DynamicAPK诞生；基于OpenAltas框架基础之上，融入了携程本身特殊的业务逻辑（为此这个网上还有朋友说携程抄袭的风波😂）

（2）机制和特色，见上面的OpenAltas模块

（3）诞生背景（若是是插件化模式，有以下好处）：

（a）随着业务发展，原有携程无线App开发团队被分为基础框架、酒店、机票、火车票等多个开发团队

（b）合做模式高效：在这种模式下，开发沟通成本大大提升，以前的协做模式难觉得继

（c）编译速度加快，工程被拆分为十来个子工程以后，Android Studio编译流程繁冗的缺点被迅速放大，在Win7机械硬盘开发机上编译时间曾突破1小时，使人发指的龟速编译让开发人员叫苦连天

（d）启动速度加快，Google提供的MultiDex方案，会在主线程中执行全部dex的解压、dexopt、加载操做，这是一个很是漫长的过程，用户会明显的看到长久的黑屏，更容易形成主线程的ANR，致使首次启动初始化失败

（e）产品A/B Testing，独立开发AB版本的模块，而不是将AB版本代码写在同一个模块中。

（f）可选模块按需下载，例如用于调试功能的模块能够在须要时进行下载后进行加载，减小App Size
复制代码

（4）官方博客：mp.weixin.qq.com/s?__biz=MzA…

（5）Github：github.com/CtripMobile…

Small框架

（1）诞生背景，2015年12月底，光亮GG的Small框架发布；

（2）愿景：世界那么大，组件那么小。Small，作最轻巧的跨平台插件化框架

（3）思想：组件化，APP拆分红不一样功能模块，造成独立组件，让宿主调用

（4）使用场景：适用于将一个APK拆分为多个公共库插件、业务模块插件的场景

（5）机制，经过Hook Instrumentation来启动插件的Activity等，相似DroidPlugin

（6）数据对比：

（7）系列源码解析：ivonhoe.github.io/2018/01/18/…

（8）Github：github.com/wequick/Sma…

这些框架的关注点

根据上面的历史，咱们能够看出，开源的这些框架都关注于以下几点：

（1）插件的兼容性，包括Android系统的升级对插件化框架的影响，各个手机ROM的不一样而对插件化的影响。

（2）插件的稳定性，好比各类奇葩的崩溃。

（3）对插件的管理，包括安装和卸载。

插件化技术的经常使用用途

（1）游戏行业，插件化框架更适合于游戏领域。好比王者荣耀，常常都会有新皮肤，或者隔几天上线一个新英雄，调整一下英雄的数据，这些都不须要从新发版。

（2）数据驱动产品，ABTest，。当产品经理为两种风格的设计犹豫不定时，那么把这两种策略作成两个插件包，让50%的用户下载A策略，另外50%的用户下载B策略，一周后看数据

（3）线上问题，不须要用户从新下载App，分分钟就能享受到插件新的版本

（4）抢占市场，谁发布新功能越快越多，对市场对用户的占有率就越高；由于隔三岔五就发布一个新版本到Android各大市场，那么用户会不胜其烦；发版周期固定为半个月，又会致使新功能长期积压，半个月后才能让用户见到，而竞争对手早就让用户在使用一样的新功能了。

（5）其余，如：多模块插件开发/加快编译速度等技术提效

结尾

哈哈，该篇就写到这里（一块儿体系化学习，一块儿成长）