Overview
2018年初，我开始接手店长社区相关工作，负责进行整条业务线的业务支撑与研发工作， 除了面对新团队磨合与异地沟通等相关问题， 强运营性质的产品需求接踵而至。 在项目推进过程中我们发现， 团队同学们经常会因为一些紧急需求手忙脚乱， 开发资源时而捉襟见肘。
除了进行项目管理的建设工作之外， 我们也在技术层面寻求移动端动态化和跨平台开发的解决方案， 从而保证提升开发人效的同时能够快速响应业务需求。
基于上述业务需求的背景， 我和动态化项目组的小伙伴们选择了Weex作为公司业务动态化方案的框架基础，并围绕它的SDK进行基础设施的建设工作。
本文对团队在完成Weex基础建设工作进行了简单梳理和概述，具体问题和解决方案将逐步补充和索引。
Introduction
Weex 是Alibaba开源的一款基于web技术的移动端应用开发的框架，具有跨平台，动态化，和高性能的特点，能够帮助开发人员使用同一套代码来构建 Android、iOS 和 Web 应用，关于weexSDK的更多介绍和动态请移步Weex官网。
提到Weex，熟悉移动端跨平台技术的同学肯定会想到Facebook出品的 React Native。
相比而言 Weex 比RN更适合页面粒度的混合开发，同时也需要公司团队进行大量的基础设施建设的完善和补充； 而RN更适合小型公司去完成App粒度的开发与业务试错。
事实上，团队一直保持着对移动端动态化跨平台技术保持着探索，无论是早年的Hybrid技术，以及Facebook的React Native，
甚至在微信小程序问世之初，我们也在自己APP中研发过自己的小程序框架Hera
基于先前开发工作的沉淀与公司现有技术栈的考虑，我们还是选择了Weex来进行现有业务的开发，从而帮助我们能够更加快速地响应产品和运营的需求，达到提高开发人效的同时又保证产品性能和交互体验的目的。
在调研和实践过程中我们发现， 尽管Weex官方提供了开发友好的工程脚手架和应用示例，但仍然远远无法满足我们在业务开发过程中的种种需求。
因为当我们站在产品业务侧考虑问题时，一方面要灵活应变的各类业务场景，另一方面更要保证业务本身的稳定，安全和高可用。
与此同时，为了便于技术方案的推广和落地，达到提升人效的目的，还需要尽可能地考虑提升开发者友好度，实现与现有业务和公司平台的无缝对接。
为此，我们围绕官方提供的SDK进行了一系列深度优化和建设，打造了适用于公司业务开发的Weex生态系统，不仅涵盖了Weex 项目的快速搭建，开发，测试，部署的方方面面，同时也和公司现有系统和策略完成了对接和打通，为整个业务开发和发布流程提供了一站式的解决方案。
如上图所示，初期的基础设施建设工作主要包括以下三个部分。
I. 宿主容器建设
围绕着Weex SDK， 我们在宿主App打造了用于承载Weex页面运行的容器。 在客户端与Weex混合开发过程中， 宿主容器在负责页面栈以及路由跳转管理的同时， 还封装了常用的API接口和UI组件。
通过对App底层的网络，日志等模块的封装和扩展， Module向Weex提供了App原生的能力和必要的业务数据信息。
站在工程人效的角度来看，移动端的跨平台的开发框架提供了代码多端运行的能力，从而降低了业务开发和维护的成本。 为了进一步提升人效，还需要我们为不同的业务方（不同BU）提供通用的业务组件或者API。
从图中可以看到， 为了保证业务在跨平台方面具有良好的可用性，无论是封装了底层API的Module， 还是为业务提供界面展示功能的Component, 都分为App端和Web端两类， 并进行对应的实现。
除了基础的API和组件， 我个人不太建议在App端开发大量业务相关的Module和Component, 这不仅会让业务的跨平台能力变弱，同样也会让业务依赖于客户端的发版， 不够灵活。
相反， 我们可以在Web端扩展和建设Weex业务通用的组件库， 一方面可以大大提升业务开发的效率， 同时也统一了UI风格和标准。
II. 工程化建设
前面也提到，Weex官方提供了工程脚手架Weex-toolkit和应用示例，但仍然远远无法满足我们在业务开发过程中的种种需求，同时也无法对接公司现有前端发布系统和解决方案。
关于Weex-toolkit构建脚本的源码分析：
为了解决工程构建相关问题，提高业务开发效率，我们需要根据公司前端开发流程和规范， 进行Weex工程化相关的建设工作。
避免重复造轮子，我们利用公司的脚手架工具（开源版BIO），开发了Weex工程的脚手架。
在开发友好方面，脚手架为工程提供了统一的项目骨架， 不仅可以帮助开发同学零成本完成Weex工程环境的搭建，还提供了不同开发环境下的页面调试功能。
在工程构建方面，脚手架在项目创建时一键初始化了整个工程的构建配置， 不仅降低了新手上手的难度，也大幅度减少了整个工程配置的成本。
通过统一的工程构建配置和约定， 脚手架也完成了与公司Web发布平台的构建任务和发布流程的对接，支持业务代码在平台完成各环境下的云端构建和发布任务。
由于脚手架本身肩负着与公司系统和流程衔接的职责， 代码中可能涉及一些比较敏感的内容不宜开源出来， 后续我针对工程构建过程中的一些问题和解决方案进行总结和补充。
另外，伴随着公司全栈化建设的推进，使用weex来进行业务开发的同学可能来自不同的团队，相关知识基础以及对weex开发的理解和认知也各有不同。良好的文档有助于不同团队大幅度降低工作接入和沟通的成本。
为此，们也为Weex打造了相对比较友好的文档系统，并对相关文档进行了整理，不仅介绍了如何快速上手业务开发，提供了详细的API使用文档和示例，同时也将我们日常所遇到的问题和相关解决方案逐步积累沉淀下来。
这部分工作好比粘合剂或者胶水，将各部分工作都结合起来，并且与已有系统进行对接和适配。
III. 业务动态化
站在业务的角度来讲，强大的动态化能力可以让业务功能不依赖于APP发版，对于缩短业务迭代周期有着决定性意义。
除了保证业务友好之外（灵活应对各类业务场景和需求），我们在技术层面还要考虑到以下问题：
- 页面的性能：如何降低页面（特别是关键路径上）的首屏时间
- 业务稳定：当业务出现问题，如何进行降级（降级策略和粒度），保证业务可用性；
- 业务安全：如何对客户端资源进行校验，防止资源文件被人为篡改和损坏；
这部分工作主要包括两部分内容：
1.业务投放
通常情况下，前端Web页面发布完成后Webview通过加载URL访问页面资源即可。
Weex页面资源发布后，虽然也可以通过URL的方式直接访问和加载，但我们通常会有针对不同App，系统或App版本等维度的投放需。
除此之外，部分业务还需要有相应的主动降级策略，因此需要针对业务页面有相应的管理和投放策略， 相应的页面和数据都通过AppConfig投放给指定的终端。
初期的时候，我们专门开发了一个配置后台进行页面配置和框架流程上的试错， 随后我们将这部分工作集成到了公司前端的发布系统中， 与整个公司流程进行了打通。
2.资源缓存
对于Weex业务的动态化而言，保证业务资源的及时更新和提高页面渲染的速度，不仅是业务页面触达用户的最后一公里路程，也是提高产品体验和页面性能最重要的一环。 为了提高页面打开和渲染速度，保证用户良好页面体验，需要在客户端设计并实现了「Weex页面资源缓存策略与加载方案」。
