组件化技术细节
前面讲的是容器层面的比较概要的东西，下面我们会讲一些具体的细节。
关于Bundle的生命周期会提供细粒度的节点，比如下面是一个Bundle从加载到运行的周期：
startInstall：开始加载。这个时候框架会做一些拷贝文件、释放lib、加载Bundle的事情;
Installed：加载完毕。这时框架会注入资源路径，创建class loader;
resolved：解析完毕，框架会检查组件配置是否合法，是否能被解析;
active：运行组件，即开始运行组件Bundle;
started：运行成功。
组件化涉及到的第一个问题是Manifest处理，一个是因为来源很多，有宿主Manifest、Aar Manifest以及组件Manifest，另外不同组件的Manifest经常发生变化，要求我们灵活地去处理。这里的做法是在工程期将所有的Manifest进行Merge操作，这里需要注意的是Bundle的依赖单独Merge，因为这里涉及到依赖仲裁的问题。最后解析各个Bundle的Merge Manifest，得到整包的BundleInfoList，就是上面我们提到的Bundle信息清单。
第二个是类加载，这里利用Delegate ClassLoader来动态加载组件的类。Delegate ClassLoader先查找宿主Bundle的PathClassLoader，然后根据前面的BundleList找到对应的BundleClassLoader.
第三个是资源，我们会用自己的DelegeteResources替换掉系统的resource，Bundle的资源会逐个在安装的时候添加到AssertPath，由于添加Bundle的顺序非固定，不分区会导致资源查找错乱。
另外，Dalvik和ART上的资源查找过程顺序是不一样的，加上小米等系统会重写自己的resources，所以我们会适配不同的机型，往后追加AssetsPath或者往前追加，系统AssetManager是个单例，默认往后追加，如果往前追加，则需要重新创建AssetsManager对象，同样主dex动态部署的时候要达到替换原有resource的目的，必须保证插入顺序与查找顺序一致。
还有需要注意的是，每次更新resourceTable的时候，必须保证apkresource，runtime的系统resource，例如webview，bundle resource都已经添加成功，而且唯一，顺序正确。
不同Bundle的资源可能发生命名冲突，我们是用了一种相对来说简单的方法，将各自的Bundle分配成不同的ID，保证所有的业务资源不会产生冲突，尽量将问题放到工程期解决。在很多代码里，通过反射来调用整个资源，在5.0以上的系统是没有问题的，它只找第一个，对业务代码而言，原来是怎么写的，今天还是怎么去写。
关于组件化性能这一部分，我们引入了按需加载，因为手淘APK有70多个Bundle，每个用户真正用的时候只需要5或10个，所以不需要加载所有的Bundle。Bundle之间进行隔离，通过Android四大原生组件进行交互，这样Bundle之间可以比较好的解耦。我们所有调用的入口都是基于BundleInfolist去做的，根据这个清单信息，得到组件所在Bundle，如果需要加载，我们就进行install、dexopt等操作。
另外，对于解决组件依赖问题，定义了两种新的组件格式Awb(业务Bundle)和solib(so库)，前者与AAR一致，不过不添加本地lib，在构建的时候做依赖仲裁区分，后者是Native so库的依赖。Awb其实就是AAR，只是后缀修改了，如果你的包放在宿主Bundle就用AAR，如果是组件Bundle就用Awb。
对于业务Bundle的依赖，我们在构建期会将宿主Bundle和业务Bundle及其依赖分别打包，然后按照最短路径、第一声明原则进行树状仲裁，得到每个Bundle需要的依赖，在打包的时候会将依赖库放到各自的Bundle里去。
最后是APK构建，我们对它做了比较大的调整。上面的图中，其实左边这一部分是一个标准的APK的构建过程，包括处理，编译，到签名的过程。我们这个不同的地方是多了Awb需要特殊处理，其中Awb的资源根据宿主的resource.ap_和包内资源构建，R文件由Bundle R资源和宿主R资源合并而来，然后我们对Aapt进行了修改，对每个awb分配不同的packageId，然后进行统一混淆，生产各个AWB的Dex，打包为APK，签名之后复制到libs，改名为so文件，然后合并到taobao APK. 这就是我们组件化的整个过程。