支付宝客户端架构解析：Android 容器化框架初探

1.3 框架设计原则

为了解决上述模块化的问题，我们要遵循以下原则去设计客户端框架：

• 根据基础技术层级、客户端的业务线等原则，对客户端应用程序进行模块化拆分。
• 每一个模块由独立的小团队或者个人来进行开发、维护、测试、集成。
• 模块与模块之间要做到彻底解耦，模块之间可以通过接口进行依赖。
• 每一个模块可以进行热插拔，单个模块的插拔不影响整体的工程的编译运行。

2. Quinox 简介

Quinox 客户端框架是类 OSGi（ like-as）框架的实现。Quinox 一词来源于著名的 OSGi 框架的实现 Equinox。

基于此框架的客户端 App，都是由一个个的积木搭建而成，这些积木被称之为：Bundle。

3. Bundle 介绍

3.1 什么是 Bundle

Bundle 是 OSGi 规范的模块化基本单位，与 Android 里的 android.os.Bundle 是两个完全不同的概念。 OSGi 里的 Bundle 指的是 Java 应用程序的基本单位，它是一个模块单元（Jar 格式），也是上文 Quinox 简介里提到的积木。 基于 Quinox 容器框架开发的应用程序也是由众多的 Bundle（APK 格式）构成。

本章节将从项目开发的三个不同的时期对 Bundle 的形态进行阐述：

时期	形态
开发期	Bundle 工程
构建期	Bundle 包
集成期	集成客户端的 Bundle 基线

3.2 Bundle 工程

常规的 Android 项目开发，代码工程通常有两种(两级)类型

工程类型	Library	Application
工程输出	Aar	Apk

基于 Quinox 容器框架开发的 Android 项目，代码工程则有三种(三级)类型

工程类型	Library	Bundle（工程包）	Application（测试包/安装包/Final APK）
工程输出	Aar	Apk(.jar)	Apk

关于 Bundle 工程，我们需要了解以下三点：

• Bundle 工程跟常规的 Android Application 工程非常的类似：它内部也会有多个 Library（Android Module）；它的输出形式也是 APK 格式。
• 虽然 Bundle 包文件本质上是 APK 格式，但是该 APK 是无法运行的。同时，Bundle 工程被 deploy 到 mvn 仓库里时，它的后缀名是会改为.jar。
• 基于 Quinox 容器的 Application 工程（可称之为 Portal 工程）则是将众多 Bundle（APK）合并成一个 APK（Final）的过程。这里是合并，而不是编译，所以生成最终 APK 的速度将会非常快，因为编译已经被分布式的进行在各个 Bundle 中了。基于 Quinox 容器开发的客户端程序，需使用 mPaaS 定制的构建工具（即打包插件）。

关于 Bundle 工程的结构图请参考：

3.3 Bundle 包

如上所述，Bundle 工程的输出也是 APK 文件。

在 OSGi 规范中，Bundle 是有很多属性的。Bundle 工程输出的 APK 与常规的 APK 有一个不同点，mPaaS 插件会将 Bundle 的所有属性生成一个特殊的文件放在这个 APK 中，供容器去解读。

除了 APK 文件之外，Bundle 工程的构建结果还包含：

• AndroidMannifest.xml
• Bundle 接口包（可以理解为一个 jar 包，它包含且暴露该 Bundle 提供的接口类）
• mapping.txt

Bundle 包文件，在构建完成之后，通常要 deploy 到本地/远程的 mvn 仓库中，以供其他 Bundle 工程引用，或是被 Portal 工程集成。

3.4 Bundle 基线

前面已经讲述过，构建 Final APK 其实主要就是将很多的 Budnle APK 合并成最终的 APK 的过程，而这些众多的 Bundle APK 们都存放于 mvn 仓库中。

因此我们将这些 Bundle 的 GAV（GroupId，ArtifactId，Vesion）的集合，称之为基线。

当某一个团队/个人开完一个 Bundle 工程的新功能，并经过测试达到可发布状态，就可以更新基线里的版本号。我们将这个过程称之为进基线。我们认为：基线里打出来的 APK 是稳定可运行的；没有稳定 Bundle 工程包不应该进基线。

Bundle 基线机制可以很好的隔离了模块之间的相互影响，保障了不同团队间开发环境的和谐与稳定，达到了我们之前的设计的初衷，因此可以很好的支持多团队并行开发。

3.5 Bundle 包属性及配置办法

关于 Bundle 属性，我们可以参考 OSGi 的 Bundle 属性。Quinox 容器框下定义的 Bundle 属性要简单的多。

下表将列举 Bundle 的所有属性以及配置方法：

名称	说明	配置办法
Bundle-Name	Bundle 的名称，作为 key 值存在。同一个客户端 apk 中，不允许同名的 Bundle 存在	由 mPaaS 插件根据 Bundle 工程的 GAV 的 GroupId、ArtifactId ，以一定的规则生成而来。
Bundle-Version	Bundle 的版本号，各个 Bundle 的接口包必须做到 API 版本向下兼容。	由 mPaaS 插件根据 Bundle 工程的 GAV 中的 Version 生成而来
Init-Level	已废弃	配置为 1 即可
Package-Name	已废弃	配置为 ‘’ 即可
Component-Name	Bundle 中声明的 Android Component。它跟 Export-Pacakges 属性一样，是 Bundle 的入口类。	由 mPaaS 插件根据 AndroidManifest.xml 文件中定义的 Activity，Service，BroadcastReceiver，ContentProvider 等生成
Package-Id	Bundle 工程的资源的 packageid，具体技术细节请参考4.2章节	必须由开发同学在 Bundle 工程中设置属性 packageId，其值的设置区间为【27, 127】，如果没有资源，则设置为 127，如果 Bundle 为 Bundle 依赖关系树上根节点的 Bundle，则设置为27。
Contains-Dex	此 Bundle 中是否包含代码（classes.dex）	由 mPaaS 插件根据 Bundle 文件中是否包含 classes.dex 节点判断得来。备注：静态链接的 Bundle 由于 classes.dex merge 到了主 apk 中，所以该属性会被修正为 false
Contains-Res	此 Bundle 中是否包含资源（resources.arsc）	由 mPaaS 插件根据 Bundle 文件中是否包含 resources.arsc 文件判断得来。
Native-Library	此 Bundle 中是否包含 native so（lib/xxx/libxxx.so）	由 mPaaS 插件根据 Bundle 文件中 native so 文件判断得来。备注：在构建最终 apk 时，Bundle 中所有的 so 文件在构建 Final apk 时，会 merge 到 Final apk 中，所以该属性会被修正为 null
Required-Bundle	此 Bundle 依赖的 Bundle 列表：为 Budnle-Name@Bundle-Version 的格式。	由 mPaaS 插件根据Bundle项目工程依赖其他Bundle接口包，来生成此属性。
Export-Pacakges	Bundle 导出包（请参考 OSGi 的导出包概念）。Quinox 容器将根据导出包，从对应的 Bundle 中加载类。	必须由开发同学在 Bundle 工程中设置属性 exportPackages。例如：某个非静态连接的 Bundle 提供了类: com.alipay.android.phone.framework.api.A作为接口给其他 Bundle 使用，则须将com.alipay.android.phone.framework.api配置为导出包。（反射被使用的类也应纳入导出包）。有多个导出包的用’,'隔开。为了性能考虑，导出包不应设置太多，或者范围太广。

4. 资源管理

4.1 资源管理器

作为 Android 开发人员，我们知道通过 android.content.res.Resources 对象可以获取字符串、布局、图片、动画等资源。

在 Quinox 容器化的框架内，原生的资源管理肯定无法实现多 Bundle 的资源管理，这时候，我们就构建了 Bundle 资源管理器，来专门处理各个 Bundle 的资源的加载、调用等工作，替代了 Android 原生的资源管理逻辑。

但是，由于所有 Bundle 包都是独立编译的，它们中的资源极可能存在着相同的资源 id。因此，当存在相同资源时，就可能存在冲突，那么如何解决资源 id 的冲突呢？

4.2 资源 id

作为 Android 程序员，我们都知道资源 id 是一个 int 值，它包含4个 byte。它是在构建 APK 工程时，由 aapt 工具生成，定义在 R 文件中。

示例代码：

public final class R {
public static final class drawable {
public static int xxx_bg=0x1e020000;
}
public static final class id {
public static int xxx_id=0x1e050001;
}
public static final class layout {
public static int xxx_layout=0x1e030000;
}
public static final class string {
public static int xxx_str=0x1e040001;
}
}

这四个 byte 含义如下：

• 第一个字节为：pacakgeId。
• 第二个字节为：typeId。它表示的是不同的资源类型，如字符串，布局，图片，动画等。
• 第三第四两个字节合起来为：资源名称的 id

如下图所示：

到这里，很多读者应该已经理解到了，Quinox 容器框架关于资源 id 冲突的解决方案是，让 mPaaS 打包插件使用改造过 aapt 工具，对每一个 Bundle 工程都指定不同 packageId，进行分区隔离，从而确保不同的 Bundle 之间资源 id 是不会重复的。这也是为什么 Bundle 工程里需要指定 packageId 的缘故。

5.容器化

关于 Quinox 容器化这里，由于目前为止，Quinox 暂未开源，所以本章节内，我们暂时不涉及到源码分析。

上面我们聊了很多关于 Bundle 的话题，那么整个容器化的核心，也是如何管理各个 Bundle。这时就要引出我们的容器管理器了，容器管理器的主要工作就是协调各个 Bundle，对各种信息进行增删改查。

在应用启动后，我们的容器管理器会读取配置信息，生成各 Bundle 的信息实例。

5.1 容器管理器：增、删

Quinox 容器框架的目标是解决 Android 客户端 App 模块化和动态化这两大核心问题。增、删这两项能力，更多的是用来实现动态化能力的，方便容器对各个 Bundle 进行动态添加、删除。由于本文着重描写模块化的能力，所以这部分，我们后续单开专题来分析容器的动态化能力。

5.2 容器管理器：改

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则近万的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：Android）

学习福利

【Android 详细知识点思维脑图（技能树）】

其实Android开发的知识点就那么多，面试问来问去还是那么点东西。所以面试没有其他的诀窍，只看你对这些知识点准备的充分程度。so，出去面试时先看看自己复习到了哪个阶段就好。

虽然 Android 没有前几年火热了，已经过去了会四大组件就能找到高薪职位的时代了。这只能说明 Android 中级以下的岗位饱和了，现在高级工程师还是比较缺少的，很多高级职位给的薪资真的特别高（钱多也不一定能找到合适的），所以努力让自己成为高级工程师才是最重要的。

这里附上上述的面试题相关的几十套字节跳动，京东，小米，腾讯、头条、阿里、美团等公司19年的面试题。把技术点整理成了视频和PDF（实际上比预期多花了不少精力），包含知识脉络 + 诸多细节。

由于篇幅有限，这里以图片的形式给大家展示一小部分。

网上学习 Android的资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。希望这份系统化的技术体系对大家有一个方向参考。

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！

习 Android的资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。希望这份系统化的技术体系对大家有一个方向参考。

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！