都已经禁止调用私有API了，你还不重视Android P怎么行

Posted 2021-04-27 京东技术

来这里找志同道合的小伙伴！

作 者 简 介

张志强，京东商城资深android系统架构师，现任职于CMO体系商城前台产品研发部，Android组件化技术负责人，致力于京东商城Android系统构架和优化，带领团队从无到有实现了Aura组件化体系建设。

>>>>

1、导读

Android P来了，插件化将何去何从？Android作为操作系统涉及的面比较广，不可能在所有的方面都能走在大家的需求之前，尤其是这几年，App越来越大，而相应的Android官方给出的方案一直不太符合中国的国情，先是65536问题，再是多团队协同开发，再到App如何瘦身，这些问题一直困扰着中国的开发者。国内的开发者们在经过了无数高手的实践之后，在2016、2017年插件化技术越来越成熟，发展到了顶峰，井喷了许多高质量的插件化框架，以应对大型App的开发。

2018年，Google官方也终于祭出了大杀器 -- 禁止调用私有API，并推出官方的动态化框架Android App Bundles。随着Android P的发布，使用插件化的你们做好应对方案了吗？

今年Google放出了Android P的开发者预览版的同时加入了限制App调用非SDK接口的计划，它这是释放了一个将会治理目前各种篡改Android系统乱象的信号，随着这项计划的推进，将会涉及到国内的很多App，尤其是使用加固和插件化技术的App。作为App的开发者，早一步重视这个事情，则将会早一步受益，基于这个前提，京东已经开始着手进行此方面的研究和推进工作了。

Android P是google在2018年推出的Android新版本，将于第三季度发出正式版本，在这之前会有五个预览版本。3月份放出第一个预览版本的时候，宣布了禁止应用调用系统非SDK接口的消息；5月初，Google IO开发者大会上，推出了Android的官方动态化框架Android app bundles。下面篇幅中我将会对这两个方面进行一个全面解读，并对可以采取的一些应对方案进行分析和阐述。

>>>>

2、Android P的禁令解读

访问非SDK接口的后果

在Android官网上面列出了几种通过反射调用访问非SDK接口的方式和引发的后果，从表格中我们看到后果主要有两个分别是抛出异常和返回的结果列表中没有私有API接口。

实施计划

但是，Google并没有一刀切的直接执行禁令，而是分步骤的进行，给了开发者一个缓冲期去修改自己的App。采用的办法是维护三个名单，分别是浅灰名单，深灰名单，黑名单。

• 浅灰名单中的接口还可以继续在Android P中使用，但是在未来的版本中就有可能会移到黑名单中，也可能会开发新的public API来供开发者光明正大的使用。

• 深灰名单中的接口，在Android P的后续预览版中将不可访问，所以如果有使用深灰名单中的接口，必须马上进行整改。

• 黑名单中的接口就不允许调用了，如果调用直接就是抛异常等行为。

注意：这个禁令是在Android P上起作用，而且针对应用的target SDK是否是28会有不同的表现；Google Play要求从2018年8月份开始应用的最低版本为Target SDK 26，明年可能将会要求最低的Target SDK为28，所以开发者一定要重视。

>>>>

3、Android App bundles

Android官方动态化框架Android App Bundles，简称AAB，是今年５月初在Google IO开发者大会上首次亮相，这是官方支持的动态化框架，值得开发者尽快学习和使用。

通过一张动图来感性的认识一下AAB，左图是legacy APK，右图是动态分发apk，可以看到左图是把所有的代码和资源统统塞到了用户的App中，所以导致App体积变大，而右图只把适合用户手机分辨率和语言等按维度划分的相关部分动态下发到用户手机上，这样能够极大的减小APK的大小。

Android App bundles的内部结构

• AAB拆分后主要分为三种类型的APK，它们分别是Base APK, configuration APKs，Dynamic feature APKs；

• Base APK是首次安装的APK，它提供了应用的基本功能，并且包含其它Splite Apks可以访问的代码和资源；

• Configuration Apks包含了特定的屏幕密度，cpu架构和语言资源等，有两种类型的configuration apk，一种是 Base Configuration Apks，一种是Feature Configuration Apks，当用户下载Base APK或者Dynamic feature Apk的时候，只需要下载其对应的特定资源；

• Dynamic feature Apks是首次安装的时候不需要的代码和资源，是由开发者自行定义和开发出来的，在代码中使用Play Core Library动态下载和安装。

AAB的整体流程

• 首先，开发者研发自己的APP，并把它编译打包成AAB格式，然后上传到Google Play服务器上；

• 服务器会把客户的AAB文件拆分成三种类型的APK，并存储在Google Play的服务器中；

• 当用户使用时，会从市场上首次安装Base apk，然后按需下载 Dynmaic Apk，对于以上两种APK，均有配套对应的feature configuration APK进行下载。

Android App Bundles 总结

• 优点

  官方推出的，背景强大

  通过了两种方式减小了APK的体积，一是去除了与用户机型不匹配的代码和资源，二是动态下发首次不需要安装的部分

• 限制

  目前只能通过Google Play发布

  处于测试阶段，用户需要申请加入Google的Dynamic feature beta program计划才能使用

  最低支持的版本是Android 5.0

  只是单纯的减小了包体积，不能通过动态下发来修复Bug和增加之前未预算的新功能，也不能增加Base Apk的manifest中没有的四大组件

• 使用成本

  需要开发者的IDE升级到Android Studio 3.2

  需要集成Play Core Library来支持dynamic feature的下载和安装

  可以加入SplitCompat库以支持6.0以下的手机来热更新D ynamic feature apk

  所有的模块必须位于同一个工程

  如果之前的Library想改改造成Dynamic Feature Module必须手动改造

>>>>

4、插件化的路在何方

>>>>

4.1 实现插件化的黑科技

插件化的流派比较多，但不管是哪种流派，它们一般都用到了一些黑科技，主要有三种：

• 第一，Hook App运行的关键点，以达到动态检测是否调用了插件中的代码和资源，比如Hook Instrumentation等

• 第二，动态的加载插件中的类，这里分为单Class Loader和多Class Loader技术，这两种技术都用到了反射技术，以达到替换系统的ClassLoader或者是增加自己的Class Path的目的

• 第三，动态的加载插件中的资源，一般会反射调用AssetManager.addAssetPaths这个方法。下面这张图是通过官方的扫描脚本扫描出来的手机京东的插件化框架Aura使用非sdk接口的结果，从中可以看出使用了浅灰名单中的两个方法 

>>>>

4.2 路在何方

当初为什么要研发和使用插件化技术，现在我们的真实需要是什么？

研发和使用插件化技术的原因

• 绕过65536问题，快速启动

• 模块解耦

• 多个团队并行开发

• 加快编译速度

• 动态部署

现在的真实需求

• 去黑科技

• 平稳过渡

• 边界隔离

• 并行开发

• 独立调试

• 快速编译

• 动态部署

探索道路

• Follow官方的方案

• 组件化方案

• 大前端：RN，Weex，快应用等

方案对比

 

这几个方案各有优缺点，其中AAB方案还不太成熟，前端和AAB的迁移成本都比较高，组件化的方案也需要研发一个适合自己公司的框架。

适配步骤

• 第一，增加组件化功能

• 第二，组件化和插件化相结合，具有两者的优点

• 第三，从长期来看，可以向AAB和前端方向靠拢

• 第四，持续改进和优化，以保持自身的活力

>>>>

5、手机京东的架构升级和重构

制定重构目标

• 第一要务就是去除插件化去除黑科技

• 第二要务是从现有的方案平稳过渡到新方案

• 第三，我们在重构的过程中顺便把京东之前的一个毒瘤去除掉，也就是体积庞大并且中心化的基础类库JdLib去中心化

• 第四，插件和组件可随时互相转换

升级手机京东的架构

目前京东的插件化框架使用的是手机京东开放平台Android端解决方案Aura框架，我们将现在的的插件化框架Aura升级到插件化和组件化相结合的AuraPlus框架，它具有灵活互转，无缝调用，优势互补等优点。

从图中，我们看到，一切皆组件，最下层是基础组件，再往上层是业务组件和业务插件，业务组件是直接依赖基础组件的，它们中间不再存在JDLIB这个中心化的基础类库了。再上层是通过业务模块任意组合成的京东的应用。

>>>>

6、解密关键技术点

>>>>

6.1 一个核心，四大技术

• 我们是围绕＂高内聚，低耦合＂这个核心思想来进行的重构和升级的。
  

• 以Project和Module为边界进行组件间物理隔离

• 然后，使用了一个巧妙和灵活的组件间通讯的方式，在自由和隔绝之间寻找到了一个最佳平衡点

• 处理组件间的依赖关系

• 其它的关键技术点

>>>>

6.2 架构的项目结构

• 我们采用的是一主工程多子工程的开发模型，一切皆组件，组件是采用的小团队独立开发的模式

• 我们这个模型与网上流行的一般的Library和Application承着编译类型的不同而转换的方式是不同的，我们这种方式需要在每个组件内实现一个独立的Application壳工程

• 这样带来的好处是避免了很多Library和Application互相转换带来的坑，比如ButterKnife中的R和R2问题。

>>>>

6.3 组件间的通讯

• 组件最终的编译结果生成了两个产物，一个是Api.jar，一个是Full.aar

• 当组件需要依赖其它组件时，只需要provided其它组件的Api.jar，而在宿主工程编译整体APK时，再 Compile Full.aar

• 这种巧妙的方式，能够在自由和隔离之间找到一个最佳平衡点

>>>>

6.4 组件依赖

• 我们看一下这个图，组件Ａ依赖组件Ｂ,Ｃ，Ｄ，组件Ｂ依赖组件E

• 那么能不能通过依赖传递让组个Ａ再依赖组件Ｅ呢，答案是不能，我们制定了一个规则，如果组件Ａ想依赖组件Ｂ，则必须明确写出

• 这样做的好处是简化了组件之间的依赖关系，使它们基于接口的依赖更加明确和清晰化

>>>>

6.5 组件提效武林秘籍

• 前边我们重构的的结构图中介绍到，我们去除了JDLIB这个庞大而臃肿的基础类库，业务组件和业务插件是直接依赖基础组件的

• 但是常用的基础组件有好多个，如果每个业务组件都写一遍的话，则会比较麻烦和重复，这对于追求完（tou）美（lan）的程序员来说是不可接受的

• 所以我们使用Gradle插件做了一个薄而灵活的SDK层，这样，业务组件和业务插件只需要一行代码即可引入多个常用的基础组件，起到了原先JDLIB的功能，但又不致于耦合和臃肿

>>>>

6.6 其它秘籍

• 预防资源ID冲突，可以加上resourcePrefix前缀；

• 为了方便管理第三方库，做了一个统一管理第三方库的组件ThirdBundle；

• 因为组件对外暴露的API是jar，不能有资源，所以还专门实现了一个BaseResBundle来存放公共资源。

>>>>

7、背景介绍

手机京东开放平台：基于手机京东数年移动研发技术实践积累，为企业移动应用研发提供一站式技术解决方案，帮助企业快速构建高可用移动应用。

Aura：是手机京东开放平台 Android 端解决方案，提供了适合大型企业开发的模块化，插件化框架和平台，可有效提高企业的开发效率。

---------------------END---------------------

下面的内容同样精彩

点击图片即可阅读