云栖大会上宣布即将开源的手淘Atlas什么来头？

在刚刚过去的云栖大会上，手淘宣布其移动容器化框架Atlas将于2017年年初开源，对这个框架，在过去团队对外部做过一些分享，外界也一直对其十分关注，到现在它终于即将开源了。

本文将介绍Atlas的设计思路和手淘对容器化、组件化和动态化上的思考，主要内容来自阿里巴巴资深技术专家倪生华（玄黎）在云栖大会上的分享。

Atlas是什么

2013年，手淘航母战略的制定，带来了业务和开发人员的翻倍膨胀。从不到100人猛增四五倍，同时业务数量大增，整个客户端的架构和发版节奏受到极大挑战，Atlas作为之前手淘客户端的基础框架，进行了一次大的重构，形成了今天的Atlas。

Atlas是一个Android客户端容器化框架，主要提供了组件化、动态性、解耦化的支持。支持工程师在工程编码期、Apk运行期以及后续运维修复期的各种问题。

在工程期，实现工程独立开发，调试的功能，工程模块独立。

在运行期，实现完整的组件生命周期的映射，类隔离等机制。

在运维期，提供快速增量的更新修复能力，快速升级。

Atlas是工程期和运行期共同起作用的框架，它的特点是尽量将一些工作放到工程期，这样来保证运行期的简单，稳定。

目前，Atlas在淘系App的应用十分广泛，手淘自身超过60+业务组件、20个协作团队，以及百万行级别代码都在Atlas上运行，其快速迭代能力让应用的发布周期从每月到每周再到随时发布，在过去半年里就发布了446次。

另外Atlas本身非常轻量，只有90多个类，支持大小型App开发，从大型的手淘到相对小型的阿里健康等都是用的这个框架。其稳定性也接受了考验，兼容Android 4.x以上系统版本。整体手淘的Crash率一直维持在万分之五左右，因为容器导致的crash占比小于百分之一。

从这个意义上来说，Atlas首先要解决的问题是大规模团队的协作问题，诉求包括并行开发、快速迭代、工程解耦，然后解决的问题是客户端动态更新的问题。手淘内部思考的解决方案就是组件化。

Atlas组件化实现

组件化，业界称为插件化，不过这里Atlas的组件化和现在的插件化有一些不一样的地方。组件化是需要去知道组件的功能，设计更规范。

手淘APK包目录结构

这是一个手机淘宝的APK包，第一层目录上与标准的APK是完全一样的，在APP会有很多的so文件，如果解开来看的话，它的结构类似于完整的APK，但本身并不能独立运行，它跟很多插件化的差别是在运行期，它是运行在整个容器里的，每一个组件都是独立的Bundle。

bundle

从模块来划分，手淘APK可以分为两层，上层是经过拆分的业务Bundle，扫码、评价、详情，各个业务之间可以进行功能的调用，可以通过路由调度到其他业务方。下层是共享的底层中间件，向业务方开放各种能力，如网络库、图片库等，会在容器里进行统一地把控，这样做的好处是包做到尽可能小，第二是性能佳。

分层

这一块是Atlas的整体设计，分为五层：

第一层我们称之为Hack层，包括OS Hack toolkit & verifier，这里我们对系统能力做一些扩展，然后做一些安全校验。

第二层是Bundle Franework，就是我们的容器基础框架，提供Bundle管理、加载、生命周期、安全等一些最基本的能力。

第三层是运行期管理层，包括清单，我们会把所有的Bundle和它们的能力列在一个清单上，在调用时方便查找；另外是版本管理，会对所有Bundle的版本进行管理；再就是代理，这里就是和业界一些插件化框架机制类似的地方，我们会代理系统的运行环境，让Bundle运行在我们的容器框架上；然后还有调试和监控工具，是为了方便工程期开发调试。

第四层是业务层了，这里我们向业务方暴露了一些接口，如框架生命周期、配置文件、工具库等等。

最上面一层是应用接入层，就是我们的业务代码了。

所以Atlas作为一个框架提供了相对完整的能力，业务层的开发可以在框架生命周期的各个环节做一些自定义的动作，也可以自由的调用系统、框架，乃至其它组件释放的能力。

组件化技术细节

前面讲的是容器层面的比较概要的东西，下面我们会讲一些具体的细节。

关于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都已经添加成功，而且唯一，顺序正确。

（编辑：源码门户网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!