Containerization Architecture in Mobile Applications

技术方案

面临这些痛点和挑战，我们想到了一些解决方案，首先介绍一下技术选型的思考。一是我们要做一个架构，需要知道架构的能力边界在哪里，要解决怎样的困难和实现怎样的目标。这里列出了现在成熟的客户端APP的技术体系。从服务端来看，主要包括几个能力，最底端的是中间件的能力抽象，上面是业务微服务的能力抽象，再上面是面向端的能力抽象，比如我们通常会做一层BFF来面向端的接口封装，一层CDN来面向端的数据高效访问的能力抽象。从客户端来看，现在成熟的APP基本都有一套自己的组件化框架，做一些通用能力的沉淀，我们想要设计和实现的容器框架就是在组件化框架的上面，它的主要目的是承载各个核心页面的展现和相关的业务逻辑，这是整个容器的能力边界的大致界定。

技术选型的两点思考

我们希望这个容器首先是标准化的，通过标准化的手段来尽量抹平业务的复杂性带来的问题。二是隔离的虚拟化技术，尽可能提高自身运行的稳定性。这是容器的两个特点，也是我们选定了在这个范围做容器封装的技术。

动态模块的实现和优化

上图是容器渲染层动态模块的渲染过程。首先还是获取配置，也是刚才整个页面配置里单一模块的配置信息。这个信息里的主要格式有两部分，一是节点信息，决定了这一个渲染素里面每个节点的元素类型，它可能是一个空的容器、一个文本，也可能是一个图片。二是布局信息，我们用Flexbox的语法来描述所有节点之间相互的关系。我们把配置信息解析出来生成了配置树，就是把配置文件变成数据模型。接着是动态绑定，最后会生成一个渲染树。在这个过程中会遇到一些性能问题，如中低端的安卓机，渲染性能较iOS机型会出现明显下降。

容器逻辑层

这张图是容器逻辑层的模型图，可以从几个维度理解容器逻辑层的运作方式。第一是初始化，容器在启动时进行初始化，整个模块首先要进行自注册，我们在适当时会获取相应的配置数据，接下来会走前面介绍的流程，根据模块的ID做模块的初创建，根据算法来判断是不是要上首屏，然后进行模块上屏。

容器协议层

第三层是容器协议层，我们设计这一层的意义是想让模块开发更加标准化，无论是平台方还是业务方，能降低业务开发的复杂度。我们主要抽象了四层容器协议层，首先容器的布局协议和数据协议相对比较好理解，布局协议解决了布局的一些信息，如模块单元的大小、位置。容器的数据协议就是容器配置数据的填充，如单元格数量和内容；生命周期协议，包括创建、加载、显示、消失和销毁。生命周期协议有很多应用的场景，比如性能监控和曝光计算。事件协议，事件总线的运行是依托事件协议的，比如像模块事件、定时器事件。

研发流程的改进

新的系统对研发、测试、运维的工作方式都会带来很多的变化，很多环节上进行了生产提效。绿色标注的是移动端常规的发版流程，我们看到涉及到的节点和团队都非常多，跨团队的合作会遇到很多问题，发版速度并没有想象那么快。在新的系统下，我们通过在线系统做的变更，这个环节的节点就会少很多，而且更新效率会快很多。