移动端类原生开发

刺骨的言语ヽ痛彻心扉 2021-12-22 13:04 388阅读 0赞

*  Hybrid方案：以WebView为容器，以HTML5为基石，通过定义native特性的扩展来支持的动态化产品研发，比如手机淘宝内部的名为WindVane的容器，这类方案通常具有非常高的动态性，但存在的问题和动态性本身一样明显，那就是性能和展现效果上的不足，而且想把其优势在工程中充分发挥出来，对开发者在前端知识和经验上的积累也有较高的要求，篇幅有限不做过多的展开。
 *  结构化native view方案：以native view为容器进行 native 级别的渲染，并定义一套描述视图结构的数据格式 (如 XML 或 JSON 等) ，然后通过动态改变或请求新的这样的数据信息达到动态化的界面效果，比如阿里巴巴集团内出现 (过) 的 WeApp、鸟巢、Dynative、PageKit 等，这类方案依赖一个结构化的界面描述，并重点保障纯展现输出维度的动态性，各有千秋，但有一些共性的不足之处，比如对其它维度的动态性处理，比如逻辑的动态性，加载策略的动态性等。
 *  React Native方案：大家习惯简称其为RN，以native为渲染引擎，通过脚本引擎支持界面Virtual DOM的转换和逻辑控制，来实现界面的动态性。RN 前半年在阿里很多团队都得到了实践，包括我所在的无线事业部，但效果并不令人满意，首先是RN量级非常重，在请求、加载、渲染、交互、稳定性等层面都不够理想，而整个技术方案在社区的迭代和演进过程也一直充满着不确定性，这给团队产品级别的运用和后期跟进带来了很大的困惑。

实际上，我们觉得 RN 更像是一个全新的移动开发框架，而不是为了增强现有移动应用的动态性而生。大家希望通过 RN 解决动态性问题，是因为它在客户端引入了 JavaScript 引擎而已。

**关于移动端动态化方案的再思考：Weex**

综上所述，我们能够看到很多中动态性问题的解法，但也都各有所限。团队经过不断的观察和讨论，决定拿出一套更好的更针对移动端动态性问题的技术方案——这就是今天的 Weex！

**Weex的设计理念和思考过程**

Weex 在我们看来已经具有非常多的特点，比如：

*  致力于移动端，充分调度 native 的能力
 *  充分解决或回避性能瓶颈
 *  灵活扩展，多端统一，优雅“降级”到 HTML5
 *  保持较低的开发成本和学习成本
 *  快速迭代，轻量实时发布
 *  融入现有的 native 技术体系
 *  工程化管理和监控等
 *  ……

但是 Weex 其实最核心的诉求就是解决移动端动态性问题，它有自己非常鲜明的 **三大特点** **：**

*  轻量：体积小巧，语法简单，方便接入和上手
 *  可扩展：业务方可去中心化横向定制组件和功能模块
 *  高性能：高速加载、高速渲染、体验流畅

Weex 为移动端动态性问题而生，这些优势都是天然的，追求极致的。团队基于这三方面设计并实现了整套技术方案。

团队在 Weex 的设计和实践中，还有一个很深刻的感悟，就是：找到性能与动态性之间的平衡点。

放眼这么多动态性技术方案，有这么几个必经之路：

*  动态内容的开发/配置
 *  动态内容的云端部署
 *  客户端请求动态内容
 *  客户端把动态内容现成最终的效果

如果我们不只是处理纯展现性质的动态性内容，那么要再加上一个必经环节

*  动态内容的开发/配置
 *  动态内容的云端部署
 *  客户端请求动态内容
 *  客户端把动态内容和逻辑解析成视图
 *  客户端把视图展现成最终的效果并处理用户交互

这里面哪些环节值得扩展、哪些环节需要更多的动态性、哪些环节是性能的瓶颈，是整个解法的关键。通过思考和讨论，我们不难发现：

*  动态内容的开发/配置需要快速实现
 *  云端部署需要尽量去中心化，横向可扩展
 *  客户端请求需要尽量小的传输数据，需要尽量快的加载过程
 *  客户端内容解析需要动态性
 *  客户端交互响应需要动态性，需要尽量去中心化，横向可扩展
 *  客户端界面渲染需要高性能，需要尽量去中心化，横向可扩展

所以我们的解决方案中有几个关键决策：

*  在内容开发/配置和云端部署之间需要有 transformer 的转换和处理能力，平衡开发体验和客户端请求的数据量
 *  客户端需要有 JavaScript 引擎，处理动态逻辑，提供动态加载策略，同时需要将复杂的端上的解析工作尽量提前
 *  动态内容的描述需要有结构、样式、数据、行为的分离，保障复杂的内容可分解
 *  客户端界面渲染需要 native 的渲染能力，保障性能
 *  Native 渲染和 JavaScript 引擎之间的边界放在了 Virtual DOM，两者通过约定 Virtual DOM 来进行通信，而不是 template + data 或是别的边界，确保渲染性能和灵活度的平衡
 *  动态内容发布、客户端接入、组件、JS API 全部需要横向扩展性，保障 Weex 的核心足够轻，足够专注，同时竟可以支持更多的业务场景

**Weex的核心工作链细节**

Weex 核心设计理念是三端一体化的动态化解决方案，云端同学实现实时发布和动态部署、模版预解析处理，前端同学在 JS Framework 实现动态内容解析并处理成 Virtual DOM，客户端同学提供渲染实现和 native 特性的支持，接下来业务同学根据 DSL 实现动态内容的开发或配置即可。

Weex 在 DSL 设计上大量借鉴了 Web 标准的规范，并且通过主流且成熟的 MVVM 模式书写 template、style、script，我们在学习成本、开发习惯方面为业务同学考虑了很多，这样的话业务同学可以很快的学习和上手，并且保证代码的规范性和可读性 (这里要特别鸣谢一下 Vue.js 及其作者尤雨溪，我们在上层 DSL 的设计和 JS Framework 的实现上都做了深度的使用和借鉴，也在和作者的交流过程中受益匪浅)。

其次为了提升性能，减少客户端的性能损耗，Weex 在服务器端实现了 DSL Transformer 的工作，可以在模版发布的同时，将 XML + CSS + JavaScript 代码转换为可以小数据量执行效率高的 JS Bundle，并同步存储至云端：如 Web Server、CDN 等。

再次为了保证业务逻辑的动态性，Weex 在客户端的 JavaScript 引擎中预运行起了一套 JS Framework，来负责解析整个 JS Bundle，而 native 端则只负责 Virtual DOM 的解析和布局、UI 渲染的实现、以及基础网络通讯、文件读写以及手势处理等基础 API 的实现。

还有为了有效的提升工作效率，Weex 的 JS Bundle 可以实现三端跨平台渲染展示，业务同学可以通过开发一份 Weex JS Bundle，来实现 iOS/Android/HTML5 三端的正常展示。

所有的 native 组件和 JS API 全部都是模块化的，业务同学可以通过注册新的模块和方法达到去中心化的能力扩展。

关于 Weex 的性能优化还有以下几个细节：

1.  JS Framework 通过对数据的依赖收集，实现响应式的视图层，再加上一层 diff 算法的优化，可以有效的过滤冗余的操作和复杂的计算。
2.  Native 端对通信，Virtual DOM 解析以及布局实现等进行异步线程的处理，防止 UI 线程的阻塞。
3.  对 UI 组件节点实现了复用处理，并对图片资源进行监控和回收，有效的减少内存的占用。
4.  对于实时性要求较高的处理，Weex 允许第三方实现 native 的定制需求来保证体验的流畅性。

图：Weex 关键性能测试和同类方案对比

> 注：数据取自实验室测试结果，测试界面为 60 个左右“坑位”的商品列表，测试机型为：

> - iOS：iPhone5 - iOS 9.1

> - Android：三星SM-N9006 - Android 5.0

转载于:https://www.cnblogs.com/lydialee/p/5418567.html