如题，接下里的一段时间里，我会从无线电商动态化的角度谈一谈自己的理解和思考
无线电商动态化
无线
首先要谈的是无线，或者说移动。手机和传统桌面端计算机有着非常大的不同，首先是随时随地，这样它就需要同时也可以拥有更多的传感器，比如镜头、体感、定位、蓝牙、NFC 等等，当然也包括多点触摸屏，人们的操作和交互方式也发生了很大的变化；其次它的屏幕尺寸和电脑完全不同，也由此产生了完全不同的阅读体验和阅读方式；再有就是能耗和稳定性变得非常非常关键，如何流畅的展示复杂界面和大数据，如何有效控制由于资源问题而导致的 crash，如何帮用户省电，如何长时间使用还不会发烫，都变成了很重要的课题。总而言之，一个输入，一个输出，一个性能。
还有一个潜在的问题，就是无线端很多形态大家都还在一起摸索之中，这其中有很高的“试错”成本，我们的产品经理甚至会在项目初期就主动坦承我们需要很多试错，需要快速迭代。所以在无线端探索性质的东西非常多，远远多过桌面端。
电商
电商这个话题其实挺大的，我只说一些从个人技术角度看到的电商：就是 1 什么地方都得能随时改，2 随时改
从电商平台的角度，我们无时无刻需要为用户挑选和推荐更好更适合的选购信息，比如有新品上架了，有商品降价了，有促销活动了……它作为平台一定是自由的，信息是充分流通的，所以也必须是非常灵活实时的。
再有就是电商是和真金白银打交道的，这要求我们对技术方案的稳定性和准确性做非常严格的把控，对项目工程化有极高的要求，项目过程中的半点松懈都有可能对用户产生极大的影响。
动态化
今天的移动端，大家基本都是通过各式各样的 app 来完成自己的事情，而这些 app 都是 native 的，有必要的版本控制和发布节奏。浏览器的位置相对没有那么明显，更多的充当了一个“快速降级”的角色，即如果我们没有安装 X (类) 应用，那么当我需要使用 X 的时候，就用浏览器打开一个 X 的网站。
既然大家的主战场都是 native app 了，那基于上面我们对于无线和电商这两个关键词的分析和理解，如何在充分合理运用设备的输入输出、并且能够快速迭代、实时调整、还能把控性能和各方面风险，就变成了重中之重。
比如每年双十一当天，整个天猫和淘宝的各条产品线都处在高度“敏感”的状态，活动当天出现的任何一个状况都可能产生非常重大的影响，需要我们可以灵活调整；在平时卖家和买家产生的任何信息和数据，都希望可以最通畅的发布出来。尤其是卖家，如何“装修”好自己的店铺，“打扮”好自己的宝贝信息，“张罗”好自家的活动，都需要非常强的动态性做支撑。
移动端的 HTML5
先反观今天的桌面端，浏览器已经是绝对的主角了，我个人身为一个前端工程师算是亲身经历了浏览器从默默无闻到变成桌面端第一使用时长的全过程。而今天的手机则是 native app 的天下。我觉得原因有很多，比如体验、能耗、生态、入口等等，同时也是因为手机上的浏览器需要顺应很多颠覆式的变化并且在多个厂商之间寻求统一。
HTML5 其实在移动端一如既往的保有着它的跨平台和快速实现的优良特点，随着手机操作系统的不断升级，越来越多的 HTML5 新特性有机会在实际产品中运用起来。但也一直有很多局限性。
比如提供的功能有限——这个问题目前很多地方都在通过 Hybrid 方案来解决，把底层的能力或业务上的特殊需求封装成 JavaScript API 暴露给 webview，从而让 Web 页面可以通过 JavaScript 调到这些特性。相信任何团队在这条路上经过一段时间，都已经把问题解决得差不多了。
第二个问题是性能问题，今天在移动端，设备的性能，不论是从 CPU 还是内存还是电池都不能和桌面端同日而语，简单的界面用起来是没感觉的，一旦交互复杂或数据量达到一定程度，webview 的弊端还是比较明显的。而且上述两点都是比较绝对的，而由于性能和能力缺失而引发的上层技术方案的倾斜则会产生更多深远的影响。比如二维码扫描与识别、省市区地理位置选择、包括一些复杂的动画设计，这些问题都不是“前端能不能做”的问题，而是做出来效果好不好的问题，或“卡不卡”的问题。
在桌面端，浏览器之所以能一统江湖，其实不只要归功于 W3C 和 HTML5，我们的浏览器还有一位好朋友：那就是 Adobe Flash Player Plugin，它虽然不是标准的开放的，但是在后期有着惊人的用户，对浏览器的能力做了大范围的扩展，而性能也是 native 级别的，这恰恰解决了我们上面提到的几个问题——后期 Adobe 还提供过 AIR 平台，可以完全甩开 Web 开发桌面应用。而现在的移动端就没有这么好的“福利”了，迟迟没有人站出来充当“移动端的 flash”的角色。
看上去还不错的解决方案
我所在的团队一直在不断思考和探索无线电商动态化这个问题。在这个过程中，我们看到了很多不错的方案，也做了很多自己的尝试
- 传统 Hybrid：基于嵌入 native app 的 webview，通过对 API 的扩展达到解决问题的目的，这个已经流行好一阵子了，无需多提
- 为 Hybrid 引入 native 界面：我个人最早是在去年 QCon 北京听 @王集鹄 大叔的分享，当时只有安卓版本，大概做法是以类似 plugin 的方式把一块 native 界面引入到 webview 当中，这样在整体还是 webview 的情况下，可以局部达到特殊的 native 效果。随后在今年的 Velocity 北京，也看到了一个类似的方案，这次 native 界面是“盖在 webview 上”的，并随着 webview 滚动条做相应滚动，以保持界面的一致效果。
- WeApp：这是我们无线事业部2年前开启的一个项目，设计一套 JSON 格式，可以描述界面的结构和样式，然后各端实现对这套 JSON 格式的解析和渲染。这样我们只要每次请求不一样的 JSON 数据，就可以展示出不一样的界面效果，和之前的 Hybrid 方案不同的是，在 native app 里我们的展示效果是 100% native 的，并且我们还做了 HTML5 版本的“降级”渲染方案，用户在浏览器里同样有机会借助我们的渲染方案把整个界面展示出来。
- React Native：这位老兄毫无疑问是今年全球最火热的移动技术方案之一，界面是 100% 的 native，彻底颠覆了移动应用的技术栈和开发体验。但最重要的是，它在运行时是用 JavaScript 进行控制的。这件事为我们打开了一个巨大的脑洞：一旦我可以在线发布和加载 JavaScript 文件，那也就意味着我具备了动态性的能力！于是乎出现了通过动态发布 React Native 代码达到动态性目的的技术方案。
最终
我们经过一系列的调研、思考和讨论之后，提出了一套完全针对无线电商动态化的技术方案。它同样：
- 致力于移动端
- 能够充分调度 native 的能力
- 能够充分解决和回避性能瓶颈
- 能够灵活扩展
- 能够多端统一
- 能够优雅“降级”到 HTML5
- 能够保持较低的开发成本
- 能够快速迭代
- 能够轻量实时发布
- 能够融入现有的 native 技术体系
- 能够工程化管理和监控
我们觉得它并不是那种第一眼看上去很伟大的东西，但是它能够帮我们解决几乎所有实际业务中遇到的问题，是个非常务实的家伙。
我们甚至觉得这个方案里面没有什么高深的东西，没有颠覆式的新科技，但我们非常针对性的关注细节，并且在实际业务当中产生的效果却是颠覆式的。
更令人振奋的是，这套技术方案在今年的双十一全球狂欢盛典中经受住了考验，我们成功的支持了主会场的前期研发和当天的发布即实时调整。这也让我们更有勇气和信心面对接下来的更多挑战！
我给它起了一个酷酷的新名字：Weex
关于 Weex 我们有太多收获想分享，今天先开个头，谈一谈自己对无线电商动态化的浅见。
下一篇：对无线电商动态化方案的思考（二）
