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

·  阅读 657
【插件&热修系列】前世今生

引言

上一个阶段,我们学习了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)数据对比:

1.png

(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)其他,如:多模块插件开发/加快编译速度等技术提效

结尾

哈哈,该篇就写到这里(一起体系化学习,一起成长)

分类:
Android
标签:
收藏成功!
已添加到「」, 点击更改