「容器」这个词，近年来在各种技术文献中被频频提起。但容器二字，细细品味，还有深意。
往浅了说，我们想要包容业务的多样性，支撑起来自各个业务部门形形色色的需求；为更多的业务团队，更多条业务线提供一站式服务。这是一种容，是包容的容。
往深层次说，我们更希望降低业务的适配成本和重复开发的成本，希望在跨平台和高性能之间，达到极致的平衡；我们希望可以抹平设备的差异，操作系统的差异，app端的差异，在整个研发链路上都形成标准，让业务代码write once，run anywhere。这也是一种容，是兼容的容。
所以容是一种追求，一种理想状态，它是一种道。
而器便是达到这种追求和状态的工具或者方式。是我们需要去实实在在建设和践行的东西。
H5是一种器，它有很好的跨平台性，但在性能体验上存在不足；
小程序也是一种器，它在优化了性能体验之上，试图在一个生态体系里建立一套新的标准，尽管建立标准的过程并没有那么容易。
器可以是一项技术，一个解决方案，一整套产研体系，甚至是一种生产劳动的方式。
《易经》中说：形而上者谓之道，形而下者谓之器。这里的器，便是术。
道
容器化的由来要从app架构演进讲起。
技术架构的演进永远是伴随着，产品定位，业务形态的发展，甚至组织架构和团队规模的发展而演进的。这是背后的逻辑。
所以回顾技术架构的演进历史，实际上就是回顾业务的发展史；规划技术架构未来的演进方向，实际上就是预测业务形态未来的方向。
一般来说，一个互联网产品，从业务的蛮荒时代，到一步步发展壮大。在app的架构演进上，大致经历了三个阶段。
工具型：
产品初期，业务形态是单一的。
比如视频类app，播放就是唯一的业务。
所以整个app就是一个具有播放功能的单体应用。围绕着播放功能，我们可能会沉淀一些工具库，比如播放器SDK。同样组织架构也是单一的，端上只有一个技术团队，团队规模也不过几个人。
此时，一个简单的单体应用的app架构，似乎已经可以满足我们的需求。
平台型：
随着业务的发展，产品定位也发生了变化。播放依然是的核心业务，但不再是唯一业务，甚至不再是唯一核心的业务。产品由工具演变成了一个平台，在平台之上长出了许许多多的业务。
播放的业务，点播，直播，长视频，短视频；商业化相关的业务，各种形态的广告，弹窗广告，开屏广告，信息流广告，贴片广告；会员业务，电商业务，社交业务，等等。
与此同时我们的组织架构和团队规模也随之发展。比如播放器内核成立了单独的团队，广告有单独的部门，会员有单独的部门，基础支撑的平台有了单独的部门。团队人数也从几个人发展到了几十人上百人。
按照职能去划分组织架构，实际上就是希望专业的人去做专业的事，希望所有人都能把精力专注在最应该专注的事情上。
而面对这些变化，摆在架构面前的问题就是：团队之间，部门之间怎么分工，怎么协作，怎么更高效更敏捷的完成业务需求。
所以在技术架构上，我们把通用的方法封装起来，形成了服务；把相关的业务聚合起来，形成了模块；把基础的功能抽出来，形成了组件。
我们把依赖梳理清楚，我们解耦合，就是为了团队与团队之间，甚至团队内部不同模块，不同组件之间互相不受干扰，能够独立的，并行的进行开发。
在这一阶段，服务化，模块化，组件化的app架构，帮助我们适应了业务形态的发展，也极大的提高了生产效率。
生态型：
平台型app并不是终态。业务的飞速发展，要求我们站在更高的维度来思考。
我们既要看到BU内部的多条业务线，也要放眼看整个集团。
整个集团的所有业务将会是一个以流量平台为中心的生态矩阵。
在这个生态里，集团内部各个BU，各条业务线的业务。
在这个生态里，还可以存在来集团外部的，我们合作伙伴的业务。
在这样的大背景下，我们面对的问题又多了一条：如何进行跨公司协同，如何让业务在多个app中无缝兼容，如何给外部开发者赋能。
很显然，支撑一个公司的业务，和支撑一个生态的业务，对技术架构的要求肯定是不一样的。适应这种多业务，多端的生态的app架构，关键词是动态化，是标准化，是开放赋能，是可监管。
而容器化正好很好的满足了上述特性，是适应这一阶段生产力和生产关系的最佳实践。
术
容器化
实现容器化的技术选型有很多，Webview，ReactNative，Weex，Flutter，以及小程序。
其中ReactNative和Weex，经过长时间的检验，并没有取得非常好的成绩；
Flutter在成熟度上也还没有达到大规模商用的程度；
所以最适合现阶段的技术选型还是Webview容器，以及以Webview容器为基础的小程序。业内多数公司走的也是这条路。
容器化架构很好的解决了协同的问题，极大的提高了研发效率和业务灵活度，在动态化和性能体验之间似乎找到了一个很好的平衡点。
容器中台
以Webview为基础的容器，可以包括H5容器，轻游戏容器和小程序容器。
为了复用底层基础设施，容器中台的建设也十分必要。
器有优劣，术有高低
天然的Webview主要存在着性能较差，和支持的能力较少两大痛点。
所以也才有了针对这两大痛点的各种技术手段，去提升容器的性能，扩展容器的能力。让这个器更优。
-
我们使用静态资源离线包，容器预加载，提前请求数据等技术，大大减少了webview加载渲染的耗时；
-
使用逻辑层和渲染层分离的双线程模型，进一步提升了webview运行的性能；
-
通过JSBridge，为Webview调用原生方法提供了通道，扩展了Webview的能力；
-
同层渲染技术，甚至让Webview具备了渲染原生视图组件的能力。
这类提升的技术还很多，并且也在不断演进。Webview容器如今已经有了接近原生页面的性能与体验。
结尾
我也会偶尔思考，app架构的终态是什么？或者app架构有没有终态？
答案是未知的。或者我们也可以乐观的预测，是没有终态的，因为业务没有终态。
但我想，在未来可见的，比较长的一段时间里，容器化架构，以及围绕它的一整套产研体系，将会在历史舞台的正中央，扮演举足轻重的角色。
从单体应用到业务生态，业务蓬勃发展，欣欣向荣。而技术的浪潮也与之呼应，滚滚向前，从未停歇。
作为技术人，若能精于术而以道为本，守于道而以术御事，便能朝着正确的方向，做出更有价值，更有生命力的技术。
