最底层是支付宝框架的容器层，包括类加载资源加载和安全模块；
第二层是我们抽离出来的组件层，包括网络库，日志库，缓存库，多媒体库，日志等等，简单说这些是一些通用的能力层；
第三层是我们定制的框架层，这是关键部分，是我们得以实现上千人，上千多个工程共同开发一个 App 的基础。
第四层是基于框架封装出来的业务服务层；
第五层便是具体的业务模块，其中每一个模块都是一个或多个具体的工程。为了搭建超级 App 的并行开发模式，我们必须保证模块与模块之间的低耦合，实现插件式灵活的开发，因此整体业务分为了上千多个工程。
上千个工程低耦合逻辑上是没有问题，比如你开发网络库工程，他开发扫一扫工程，我开发动态发布工程，咱们代码可以完全没有耦合性，但又能如何做到相互依赖？
支付宝移动端的技术架构设计灵感便来源于 Java 的 OSGi 模块化思想：内部对每个工程都叫做 bundle 工程，每个 bundle 有相应代码和开发资源。实际上，每个 bundle 工程都是一个 apk 工程，只是比 apk 多了一个 bundle 描述文件。这三个东西非常关键，回到刚才说的工程与工程之间存在依赖，对方要如何引用？
工程之间的依赖关系只有两种：
第一种：代码层面的依赖（即我需要调用对方写的代码）；
第二种：资源层面的依赖（即我需要引用对方定义的资源，比如布局或者样式等）。
从代码转成可运行的程序可以简单分成两个时期：
1.编译期；
2.运行期。
在支付宝的架构里，编译参与的部分是和运行期参与的部分是分离的：编译期使用 bundle 的接口包，运行期使用 bundle 包本身。bundle 的接口包是 bundle 包的一部分，即刚才说的 bundle 的代码部分。bundle 的资源包同时打进接口包，在编译期提供给另一个 bundle 引用。
