传统模式中，依赖的 SDK 既参与编译，也参与运行。我们定制了编译流程，使得编译与运行的依赖内容分离。
问题来了，如何保证 App 在运行期代码和资源不缺失呢？支付宝有一个容器工程（即 portal 工程），该工程中配置了所有 bundle 包的引用，在 portal 中把所有 bundle 包本身合并，最终形成 apk 包本身。这样 bundle 引用 bundle 的接口包，仅参与编译，最终所有 bundle 在 portal 中汇集，这样编译期没问题，运行期也没问题，从而实现了工程与工程之间依赖的解耦。
完成工程间的解耦，那么如何解决代码之间存在的强依赖关系？
举个简单例子，你引用了某个 Bundle 接口包中类 A 里的方法 m，这个方法 m 因为一些业务原因需要变动，那么你就被迫需要同时改动代码。针对这样的问题，我们通过框架层面提供的微服务来解决，简单来说，即面向接口编程：具体实现与调用的接口分离，因此只要保证接口包不变，具体实现可以由开发者任意调整而不影响使用方。
以上是代码与代码之间的解耦，接下来再看看业务与业务之间的解耦：
假设某个业务首页一开始叫 ActivityA，后来因为业务优化导致这个业务首页的入口被改，那么跳转到业务首页的使用方同样跟进改动。同理，对于 H5 前端来说，在不同..想要跳转到同一个业务，但这两个..跳转的入口是不一样的，前端怎么跳转？支付宝是通过框架层面的微服务和微应用来实现解耦的：
微服务是通过面向接口开发、引用，然后在框架中动态..的方式来实现的接口隔离解耦。
微应用是通过预先定义好一个数字来唯一标识一个业务模块，然后动态..到框架中，具体这个业务模块中有什么，入口叫什么，完全由开发负责人自己决定。
