对无线电商动态化方案的思考（三）

[Jinjiang]

之前两篇我们分别谈到了对无线电商动态化的理解，以及我们自己的技术方案：Weex，今天我们分享一些其中的技术细节

data-binding

首先要介绍一下我们是怎么做到数据绑定的，首先，我们对上层撰写的代码遵循了传统的 mustache 书写习惯。即：

<template>
  <text style="color: {{mainColor}}">{{title}}</text>
</template>
<script>
  module.exports = {
    mainColor: '#FF9900',
    title: 'Hello Weex!'
  }
</script>

我们的 transformer 对这样的语法的解析思路非常简单直接，即：

• 不含 mustache 语法的值，直接做为最终返回值
• 含 mustache 语法的值 (如 {{xxx}})，转换为：function () {return xxx}

所以上面的模板最终会被转换成：

{
  type: 'text',
  style: {
    color: function () {
      return this.mainColor
    }
  },
  content: function () {
    return this.title
  }
}

在客户端的 JavaScript 引擎中，我们会进行这样的判断：

// parent, key, value, updater, data
if (typeof value === 'function') {
  updater = value
  parent._bindKey(data, null, key, updater)
}
else {
  data[key] = value
}

只要是函数类型，就进行数据绑定，否则一次性赋值，简单易懂易用。

这样在相应的数据发生改写的时候，界面结构和样式会通过 _bindKey 和 updater 自动触发更新。

关于如何在 JavaScript 上实现数据监听，也算是一个很重要的细节，不过市面上已经有大把优秀的实现案例了，我们也没有在这个环节上做特别的事情，所以不做赘述。(p.s. 在 Weex 的 JS Framework 中，我们复用了 Vue.js 的数据监听 (observer/*.js) 和依赖收集 (watcher.js) 的代码实现，在此特别要感谢一下！)

transformer

在 transformer 中，我们主要的工作就是对 HTML、CSS、JavaScript 代码进行解析和重组。这里我们用到了三个非常重要的库：

• HTML 解析工具：htmlparser
• CSS 解析工具：cssom
• JavaScript 解析工具：uglify-js

用 htmlparser 可以把 HTML 转换成 JSON

var fragment
var handler = new htmlparser.DefaultHandler(function (err, data){
  fragment = data
})
var parser = new htmlparser.Parser(handler)
parser.parseComplete(content)
...

用 cssom 可以把 CSS 转换成对象供二次处理

var css = cssom.parse(content)
var rules = css.cssRules

rules.forEach(function (rule) {
  rule.selectorText
  rule.style
  ...
})

用 uglify-js 可以把 JavaScript 代码进行细节解析处理

// 遍历语法树
new uglifyjs.TreeWalker(function(node, descend) {...})
...
// 格式化代码
uglifyjs.parse(code)
...

而且因为有了 transformer，我们可以把传统 mvvm 需要在客户端甚至 DOM 上完成的模板解析、数据绑定语法解析等工作提前处理完毕。所以免去了客户端运行时现解析模板源文件的负担。更酷的是，因为模板解析是不依赖真实 DOM 的，所以我们可以大大方方的把语法设计成 <img src="{{xxx}}"> 而不必担心任何副作用。而高级的表达式、过滤器等数据绑定语法也都可以在 transformer 这一层提前处理好，这样在撰写体验持续增强的情况下，运行时并不会产生额外的负担——这都要归功于我们引入了这一层 transformer

debugger tools

我们为 native 界面调试设计了贴心的远程调试工具，主要解决三个痛点问题：

1. 调试 JavaScript 代码，任意设置断点 debug
2. 运行命令行代码 (Console) 对程序做实时的判断
3. 渲染结构的树形审查

解决问题的办法是：

图：远程调试工具工作原理

1. 客户端设置一个开关，可以把 JS Bridge 对接到一个远程的 websocket 服务器，而不是对接到本地的 JavaScript 引擎
2. 本地准备一个网页，其中运行了完整的 JavaScript 引擎的代码，并且也可以链接到一个远程的 websocket 服务器，这样客户端的 native 层和本地网页里的 JavaScript 引擎就串联起来了
3. 原本通过 JS Bridge 的双向通信内容可以被 websocket 连接记录下来
4. JavaScript 引擎里的所有代码都可以通过本地浏览器的开发者工具进行 debug 和 console 控制
5. 开发一个简易的 Chrome Devtools Extension，可以得到 Weex 实例的界面结构，并以目录树的方式呈现出来。

这样，一个客户端开关，一个 websocket 服务器，一个本地的 JavaScript 引擎页面，一个开发者工具扩展，我们就实现了 Weex 的远程调试。

图：开发者工具的审查元素功能扩展

unit test 和 ci 实践

Weex 的 JavaScript 引擎作为一个相对底层的项目，品控需要做到非常严格和极致，否则一个小小的失误在客户端长期运行之后都有可能带来灾难性的后果。

本次 Weex 的开发当中，我们认真实践了基于 mocha、chai 和 sinon 的单元测试，每个源代码的文件夹都放了一个名叫 __test__ 的文件夹，里面放了这个目录下所有同名的 JavaScript 文件，每个文件的内容都是当前文件夹内对应文件的测试用例。

图：所有的源文件都在同级目录下有一个 __test__ 文件夹放相应的测试代码

在项目中后期，我们还引入了集团内部的一个 ci 系统，每次开发新功能，先开一个分支，然后写测试用例，最后进行代码实现知道跑通所有的 test case，搞定之后发起 merge request，ci 系统会自动在线上运行所有的回归测试，再次验证其正确性和各项指标。

图：项目分支管理

图：CI 实践

其实有关项目品控的话题还有很多，我们也在逐渐实践当中。

isomorphic (同构)

我们已经在内部版本实现了简单的服务端渲染，有了这个东西会怎样呢？

一旦我们可以在服务端直接渲染出界面的 JSON 结构，客户端就可以绕过 JavaScript 解析过程，直接根据 JSON 结构把界面渲染出来。与其对应的逻辑控制稍后也会初始化好，并和界面效果最终保持同步，但在整个过程中，首屏加载的时间会进一步缩短。而且，更令人兴奋的是，如果当前界面刚好没有交互逻辑，甚至后期的 JavaScript 也不需要参与了，这是一条更短的链路！

反哺 HTML5

通过对 Weex 技术方案的探索，我们把组件化开发、transformer 机制、同构等理念反哺到 HTML5 开发，会有什么样的惊喜呢？

那就是一个极简的针对无线前端的 HTML5 MVVM 库：我暂时取名叫做 v.js

v.js 的名字来自著名的 MVVM 库 Vue.js，我希望这个库更适合移动端，目前它可以具备所有 MVVM 的核心功能，通过 transformer 提前解析模板，运行时更快速，体积是 Vue.js 的 1/3，而且支持服务端的同构。这些都是基于移动端现状的二次改进，目前还在细节构思和研发当中。希望不久的将来可以跟大家见面。

<template>
  <div>
    <img src="http://www.taobao.com/favicon.ico" width="32" height="32" onclick="foo"></img>
    <span style="color: red;">Hello{{name}}!</span>
  </div>
</template>

<style>
  .title {color: red;}
</style>

<script>
  module.exports = {
    data: {
      title: 'World'
    },
    methods: {
      foo: function (e) {
        this.title = 'V'
      }
    }
  }
</script>

基于 v.js 的源文件

v.js 的展示效果

{
  "ref":"0","type":"root","attr":{},"style":{},
  "children":[
    {"ref":"1","type":"div","attr":{},"style":{},"component":"...",
      "children":[
        {"ref":"2","type":"image","attr":{"height":"32","width":"32","src":"http://www.baidu.com/favicon.ico"},"style":{},"event":["click"]},
        {"ref":"3","type":"span","attr":{"value":"HelloWorld!"},"style":{"color":"red"}}
      ]
    }
  ]}

同构的 JSON 数据，方便 native 快速渲染

<root ref="0">
  <div ref="1">
    <image ref="2" height="32" width="32" src="http://www.baidu.com/favicon.ico" onclick="$fire"></image>
    <span ref="3" value="HelloWorld!" style="color: red"></span>
  </div>
</root>

同构的 HTML 代码，方便浏览器快速渲染

篇幅有限，写了三篇还是觉得不够，期待和大家更多的交流。我晚上再针对大家频繁问及或感兴趣的问题做一个整理。欢迎继续阅读大家近期针对 Weex 的常见问题汇总整理

阿里无线前端团队更多精彩的内容还在后面排队，我这边对无线电商动态化方案的思考就先写到这里了：）

[jincdream]

我们已经在内部版本实现了简单的服务端渲染，有了这个东西会怎样呢？
一旦我们可以在服务端直接渲染出界面的 JSON 结构，客户端就可以绕过 JavaScript 解析过程，直接根据 JSON 结构把界面渲染出来。与其对应的逻辑控制稍后也会初始化好，并和界面效果最终保持同步，但在整个过程中，首屏加载的时间会进一步缩短。而且，更令人兴奋的是，如果当前界面刚好没有交互逻辑，甚至后期的 JavaScript 也不需要参与了，这是一条更短的链路！

跟我自己原本想做的东西基本一致-->通过JSON生成页面。只不过weex 在生成JSON之前加多了个transformer，其实不止是 webcomponents ，换成其他也是可以进行转换，因为思路已经在那里了。而这个核心的思想一样可以用来构建pc页面，相当于打造了一个积木系统去快速搭建专题页面了。

只不过目前我们大多数页面仔还是面多浏览器比较多而非native，weex可能会引起前端开发者对native的青睐，也可能未必。~

在移动端浏览器上的表现能否更上一层楼？这让人很期待。
很好，很强大。~

[wssgcg1213]

nice

[huizhiliu]

效率好高 先占坑 等下来读

[yelingfeng]

持续关注

[rockcoder23]

终于知道@Jinjiang (@勾股) 为啥之前一直在研究webcomponent & vue.js了~ 👍

[myheartwillgoon]

Model -- (js)transformer--- H5 view
|                                                |
(native)transfromer                   |
|                                  interactive (interface)
native view ----------------

Model (component way)
transformer ( v.js or native)

[creeperyang]

transformer很好，解决了一些痛点。站在了vue.js, react.js的肩膀上，不过还是挺好的。

[Gaohaoyang]

这些思路真是值得学习！太棒了。

[zeyongTsai]

这篇看不懂的干货多起来了……期待。

[longmore]

强大

[Jinjiang]

大家近期针对 Weex 的常见问题汇总整理

设计初衷

我们希望移动客户端可以具备动态发布的能力同时不失良好的性能和体验

这里面有三个关键要素，同时也是 Weex 的侧重点：

1. 轻量：首先每次远程请求的数据量级太重就无法愉快的通过网络实时同步或更新了，还有就是客户端的包也是比较小巧的，可以较低侵入性的接入不同的业务
2. 跨端统一：每次发布只需要一份源代码，多端差异会尽可能抹平或收敛在不影响数据和描述的范围内
3. 横向可扩展：我们希望客户端提供的能力不仅限于团队自己产生的基础组件和 API，大家可以对原生组件或业务功能做针对性的定制和抽象，同时高扩展性也可以帮助 Weex 核心保持在一个小巧的体量

我们并不是一个人在战斗，市面上已经有很多非常优秀的技术可供参考和使用，Weex 希望集优秀技术之大成，快速落地，解决业务上“最后一公里”的问题。

另外除了介绍设计初衷，也想强调一下 Weex 不是什么：

• 不是一个 HTML5 库或开发框架
• 不是一套全新的技术
• 不是为了解决纯 native 开发的体验问题
• 不是一个以自身为中心的移动应用开发框架

一套代码同时运行 3 端？

是的，这是基于动态性业务需要的考虑，也是工作效率最大化的必然产物

如何做到“热更新”的？

也就是我们所说的“实时/动态部署”：通过 JS 进行描述和控制，把传输体积做到最小，把运算量降到最小，加上配套发布机制

感觉就像 React + MVVM 合体

Weex 是结合了 React Native 和 Vue？

这用的应该就是 Vue.js 吧？

这几个问题统一解答一下。

很多同学也开玩笑说这就是个“vue-native”，对此我没什么可否认的。团队在前期考虑移动端动态性解决方案的时候，包括整个实施过程中，对我们影响最深远的应该就是 React Native 和 Vue.js 了。我们也不介意晒一下这套技术方案背后的“幕后英雄”们：

• Vue.js：我们从 Vue.js 借鉴了 MVVM 的独特优势，并复用了 Vue.js 中数据监听和依赖收集部分的代码
• React Native：我们从 React Native 中获得了 Virtual DOM 和在客户端引入 JavaScript Engine 的灵感，完善我们的动态化逻辑处理和 JS Bridge 接口设计，同时复用了 csslayout 这个 native 布局计算的库，它把标准化的 flexbox 布局引入了 native 的世界
• mustache：我们数据绑定语法设计的灵感来源
• webcomponents 系列规范：我们通过对 webcomponents 长期的学习和探讨，摸索出了自定义组件封装和 template/style/script 三部分描述组件的最佳实践 (其实 vue-loader 也是这个思路)
• 还有一些手机淘宝常年的底层技术积累，如集团 Hybrid API 统一设计规范、底层的图片库、网络库等，都能够让我们能够快速实现自己的想法，快速在业务中完美落地，快速产生它的价值！

终于知道 @Jinjiang 为啥之前一直在研究 webcomponents & vue.js 了

呵呵是的，我在准备这套技术方案早期几乎见人就问 MVVM 和 React [偷笑]

可以透露一些心路历程

今年早些时候在 ShenJS 的时候，我自己也有幸和 Vue.js 的作者尤小右当面探讨过这些问题。我记得直接问了他是否对“Vue Native”这样的东西感兴趣，小右说自己的精力会先集中在 Vue 1.0 上，但随后小右提到一个观点：

实际上 Virtual DOM 可以理解为就是一个 AST，如果依赖收集能够和 AST 再结合起来，应该会不错

同时也在之后的一次技术交流的场合跟贺老聊到这件事：

• 如果能够把传统 MVVM 的模板解析过程提前或不经过 DOM，性能表现应该会更好
• 今天我们周围大量的移动端界面并没有复杂的数据结构和交互逻辑，如果能够把 MVVM 和 Virtual DOM 结合起来，应该也是一个不错的思路

还有一次和达峰聊到 React，我们都看过源码，有一个相同的感受，就是 React 的量级还是有点重，有点“过度实现” (记得原词是 over-implement，R 粉请原谅我这样讲)，尤其放到移动端。所以不论是 React.js 还是通过 React Native，我们想达到动态化的目的，都不一定是最好的选择

这些经历都给了我很多信息和思考

再后来，集团很多兄弟团队都在做着各式各样的 React Native 的尝试，看得到大家各自的突破和成绩，也不时看到一些瓶颈和无奈，尤其是体积、性能和可控度上。我不由得思考这样一个问题，就是 React Native 对于“动态化”这件事来说是否是最合适的基础？我们是否可以取其精华，汇集各路优秀的观点和理念，做出一个更合适的“最后一公里”技术方案？

再综合之前的一些想法和周围朋友的鼓励，最后如大家看到的，我在团队提出并实践了现在的这套 Weex 技术方案，并且有机会通过双十一主会场这样的业务得到了检验。

Weex 和 React、Vue 相比优缺点希望讲解下

上面一个问题的答复中其实提到了不少，我不太善于也不热衷评价别人，但 Weex 是一个特点鲜明目的很明确的技术方案，而且会继续在这条路上不断走下去，同时 React 和 Vue 也都非常赞！

似乎对 SEO 不太友好

目前 HTML5 的版本确实都是通过 JavaScript 生成界面的，从 SEO 的角度看是非常不理想的，不过有 2 件事：

1. 从目前手机淘宝所处的业务形态和环境来看，SEO 并不是一个关键的问题
2. 后期我们可以通过“同构”的技术手段实现服务器端预渲染，并生成 HTML 代码，这是可以做到对 SEO 友好的

研发过程中踩过那些坑？

还蛮多的，说几个刻骨铭心的

1. 安卓下没有系统自带的 JavaScript 引擎直接可用，我们单独引入了一个叫 duktape 的引擎，但是后来发现效率太低了 (完整渲染主会场需要好几秒钟)，后来果断又连夜加班换了 v8
2. 即便换了 v8 引擎，在手淘大团队“1s法则”的原则下，中低端安卓机的性能依然是很大的问题。native 尝试了多种接受 Virtual DOM 加载的策略，最后在 iOS 下选用了总耗时最短的一次性接受所有 Virtual DOM 的策略，而 Android 选用了按“楼层”分段加载 Virtual DOM 的策略，这样的话 Android 的总加载时间其实变得更长了，但是首屏渲染速度大大提高
3. JS Framework 的代码为了配合各端的性能调试，引入了一些 FLAG 机制，即客户端运行 JS Framework 的时候，不同的平台会设置不同的 FLAG 参数，JS Framework 在多端还能够保持同一份代码，但是执行不同的加载策略 (其实整个系统优化过程中我提供了不止这两种 FLAG)
4. 在 csslayout 布局实现中，文本和图片的尺寸和浏览器中的 CSS 不一样：是需要明确指定宽高的，而不会自动撑开。我们对文本实现了“自动撑开”
5. 在 HTML5 版本中，为了应对懒加载等策略，我们设计了一个叫做 onappear 和 ondisappear 的非标准事件，当元素被滚动到可视区域时，appear 事件会被触发，而滚动出可视区域时，则会触发 disappear，然后图片可以选择在 appear 的时机完成首次加载，商品分类的横向导航条的“自动定位”功能也是借助每个商品楼层的 appear 和 disappear 事件实现的
6. 切记 JavaScript Core 默认是没有 setTimeout 的，当然这个很好再实现
7. 在没有远程调试工具的情况下 native 的实现和适配工作异常痛苦——一提到这个就觉得团队的 native 同学很了不起！索性我们现在有工具了
8. 移动端 native 界面的资源复用是一个非常重要而且棘手的问题，它直接决定了应用的内存、帧率和稳定性
9. 浏览器里多写几个甚至几十个 <div> 没什么大不了的，但是在移动端结点数是一个很关键的要素，所以不能滥写容器，能省则省

另外也顺便抛一些尚未解决的问题，非常希望得到大家的指点和建议！

• 因为移动设备的资源非常有限，所以就算同时打开多个 Weex 实例，也只能公用一个 JavaScript 实例，如何有效的让多个实例在 JavaScript 引擎中共存是个关键的问题
• 如何优雅的设计动画和表单的语法并合理的实现，是否照搬 HTML Form 和 CSS Transition/Transform/Animation 是最好的选择？
• 如何合理设计上层的 IDE 或可视化工具/编辑器
• 如何同一个 URL 或二维码，客户端请求到的是 JS Bundle，而浏览器打开的是一个 HTML5 页面

是否会开源？

我们非常希望乐于开源，和更多人一起分享和共建 (我们已经在刚结束的旧金山 QCon 上宣布了未来开源的打算)，现在我们的 native 底层还依赖着很多集团私有的架构和服务，比如基于阿里的图片 CDN 做了加载策略的深度优化，基于阿里的底层网络库做了数据请求的深度优化等等。所以这会有个过程 (如果你迫不及待想体验……机会也是有的，你懂的)

最后还是再次感谢大家的关注，大家提出来的问题我会继续和大家一起探讨

[chen--johnny]

这个大前端的实现思路不得不让人佩服

[GavinHans]

好激动的样子

[OllivanderMe]

等开源再说

[luqin]

淘宝又造了个轮子，希望开源库能走出国门，与国际接轨。

[lynzz]

期待开源

[RubyLouvre]

阿里之前搞了这么多MVVM框架，终于搞出一个像样的出来了

[hero76]

针对业务场景，将合适的技术整合在一起，形成解决方案，就是创新了，也多亏了有这样的团队支撑

[whq731]

后端渲染服务应该是用phantomJS做的吧

[magicapple]

能谈一下研发的各个时间节点么：）

[li6185377]

赶紧刘明

[okoala]

前排啃瓜子~

[acmeid]

star再看~~

[andyforever]

跟目前我们项目开发方式某些地方很相近，组件化的方式，提一个小小的建议，在定义组件绑定数据的时候，

<script>
  module.exports = {
    data: {
      title: 'World'
    },
    methods: {
      foo: function (e) {
        this.title = 'V'
      }
    }
  }
</script>

除data、methods属性外，加一个options属性，可能对后期组件的应用场景带来更多的可能。目前我们组件绑定数据是这样的：

<script>
  module.exports = {
    opts:{
        editable:true
    },
    data: {
      title: 'World'
    },
    actions: {
      foo: function (e) {
        this.title = 'V'
      }
    }
  }
</script>

[xiaoniao]

大公司自己研究，小公司使用开源就好了，这是要累死程序员的节奏啊。有好多不懂的东西要学习:)

[stephenzhao]

请问如何解决多人协作时 css的命名冲突

<template>
  <div>
    <img src="http://www.taobao.com/favicon.ico" width="32" height="32" onclick="foo"></img>
    <span style="color: red;">Hello{{name}}!</span>
  </div>
</template>

<style>
  .title {color: red;}
</style>

[skyline0705]

@stephenzhao 可以看一下vue loader，在编译组件的时候会给相应的dom加上随机属性，并且将所有css选择器也加上了同样的随机属性，以此来解决scope css的问题

[happypeter]

React 组件内部采用 js 本身替代了 mustache 这样的“小语言”，有了更大的灵活性。换句话说就是抛弃了 template 这个概念。这个我觉得挺好的。

[dolmens]

因为移动设备的资源非常有限，所以就算同时打开多个 Weex 实例，也只能公用一个 JavaScript 实例，如何有效的让多个实例在 JavaScript 引擎中共存是个关键的问题

不知道我理解的问题对不对，和你们团队的同学沟通过，在引擎加载js的时候，强制把这个js包含在一个function里面，至少可以杜绝各个js之间的变量冲突。当然，你还需要屏蔽window等全局变量。

[Jinjiang]

@dolmens 是的，原理是如此，但是怎么通过工具或实现从理论上杜绝问题还是要有些工程手段，最近有些眉目了，正在做尝试

[dolmens]

没有看太明白，有个问题确认下，最终在native端执行的时候，是只有一个js引擎呢，还是也有xml和css的引擎？RN是只有js。

[buildAll]

你们这么牛，马云知道吗？

[yutingzhao1991]

其实大家都知道JS HTML CSS的这种前端开发模式在现在各种框架的支持下是最高效的，但是因为web页面在移动端的性能问题所以才搞这种写法是web的方式，但是运行是native的。不过我想知道为什么web也没这种dom树渲染的方式性能会差会卡呢？如果这个问题解决了是不是这些什么个xxx-native好像都没什么意义了呢？

[0326]

66666！总之WEEX是吸收了RN和vue.js的一些设计思想并且更加适合手淘和猫客内的前端开发，集团内部赶紧推广起来：）

[niluanxy]

@Jinjiang 那明白了，其实就是相当于做了一个虚拟机一样，选择H5最主要的元素，以及兼容上Flex布局的语法，这样来达到对应到原生组件的效果，了然了，确实目前来说这种方式最实际，也最容易应用起来。

[Jinjiang]

@dolmens 全部会转换成 JS 或 JSON，客户端只有 JS Engine，不需要做 HTML 和 CSS 的解析

[Jinjiang]

@yutingzhao1991 好问题，我个人的看法是 webkit 的优化侧重点主要还是沿袭了 PC 端的一些典型场景，也许未来会发生一些改变，但是这个节奏比想象中慢得多，而且 iOS 下只有他自家的 webkit 可以使用，我们无法控制这件事情

[yutingzhao1991]

@Jinjiang 是啊，记得12年的时候html5火得一塌糊涂，最后呢？发现还是要走native。有时候还是要务实啊，当年的html5就是太执着于web技术了，但是最终的决定权还是在用户还是在整个生态环境。目前感觉这个方向是靠谱的，web的开发模式+各个端各自的组件view。�也许某一天ios和andriod官方都借鉴并支持目前web前端的这种更有效的开发模式了。 JS >= ObjectC + Java + ...... :D

[rocman]

弱弱地问，weex 应该怎么发音？

[whq731]

@rocman we 克斯

[Hi-Rube]

问一下 加入 v8 后对客户端的体积有什么影响

如何同一个 URL 或二维码，客户端请求到的是 JS Bundle，而浏览器打开的是一个 HTML5 页面 // 判断来路和根据特定规则进行跳转不行么？

[AliThink]

感谢分享，对于服务器js更新后该如何下发到客户端，并对比出需要更新的部分进行局部刷新这块比较感兴趣，这里weex是如何做的呢？借鉴了virtual dom吗？

[qqqzhch]

我没理解错的这个transformer
1 如果运行在uc这样的浏览器里面 相当于是服务器端渲染
2 如果运行在手机淘宝里面的web view 是app原生渲染
是这样吗？

[Jinjiang]

@qqqzhch transformer 会把 template, style, script 都转换成一段段 json 或 js，这样客户端只运行 js，不必同时解析 html/css 这些语法，你这里提的服务端渲染，出来的应该是个完整的 virtual dom 了，但是这里的 js 还会继续进行数据监听和绑定，然后才是生成最终的 virtual dom 再发送给 native 端渲染

[miniflier]

"一旦我们可以在服务端直接渲染出界面的 JSON 结构，客户端就可以绕过 JavaScript 解析过程，直接根据 JSON 结构把界面渲染出来。与其对应的逻辑控制稍后也会初始化好，并和界面效果最终保持同步，但在整个过程中，首屏加载的时间会进一步缩短。而且，更令人兴奋的是，如果当前界面刚好没有交互逻辑，甚至后期的 JavaScript 也不需要参与了，这是一条更短的链路！"

这个地方请教一下，客户端什么情况下会拿到JSON，什么情况下拿到JS呢？
对于有动态业务逻辑的需求，肯定是需要用JS。但是仅仅是动态UI，是不是只用JSON就能解决问题？

[Jinjiang]

@miniflier 等于先把初始化的virtual dom先生成优先加载并渲染，然后再把动态逻辑“补”上去，具体实现是有一些窍门的，已经不是什么行业秘密了

[jellychen]

我觉得weex的项目的确是一个KPI的项目！

从双十一来看只是非常简单的页面再用，说实在的只是对电商的一些些（很少的页面有作用），其次由于事件跨线程的延迟 会导致事件处理的操作延迟到界面渲染上面去，这增加了 从事件发出到UI响应的时间。是一种巨大的性能的倒退的做法!!! 其实JavaScript的性能不是很高，采用大量的js的代码运行维持Native的界面运行，对内存和CPU都是浪费！

其次week一起来就拉起 排版线程(注意是排版线程)和JSCore的线程，无端端就增加了好几个线程(由于JSCore自己还会起线程)，这不得不说是一个性能的倒退和浪费。其次很多事件不支持，手势不支持(由于手势是持续的事件反馈，跨线程走message队列显然做不到及时响应)。在IOS下这种性能还说的过去，在安卓上面这种东西不得不说有点垃圾！！非常典型的不计较开销的做法！

最后总结下 为了实现一些些 很少的界面的动态化+配合web前端的开发胃口(其实为了页面动态化，完全可以利用java+网络+lua实现这个东西，而且性能更好)。简单的上线双十一的很简单的页面是不具备说服力的(当然忽悠上层不懂技术老板是可行的，(一下子跨三端，一次编写导出运行 多么诱人！！))。

所以说我个人认为这是一个KPI项目！

@@@在说说RN，这是一个很坑的项目。native代码风格和规范来说说是facebook发布的 吓一跳(对比Google的Chorme的代码)，原来美国佬也有这么随便写程序的！我以为只有我天朝才有！RN的话和Weex同理。从问题的出发点就是错的！Web前端的确很多人在用innerHtml的方式在更新dom，所以需要virtualDom 需要diff 这个无可厚非，思想还是挺牛的不得不承认。但是问题出现在ios和android前端并不存在这个问题~ 你简单的把web前端的问题假设成移动设备native前端的问题，然后给出同样的解决方式是不是太过于坑了！

@@@有很多种可以做到移动端native的及时性上线变动（非app版本替换）的方法。兼容三端确实不简单，但是RN不是一种好的解决方案，如果非要说RN是一种好的解决方案，只能说他对web前端的意义还是有的。

国内现在一阵大风说RN这个好 那个好！是不是真的符合大家的场景，还是一味的跟风做KPI项目！

[jellychen]

鄙人 去年一直在用 淘宝的app 在魅族的魅蓝手机上面！ 2G内存！ 淘宝的APP 那是卡的感动人。IOS倒是还可以！寄希望于IOS可以早日吃点安卓的市场，说不定就可以从机器的角度规避RN此类框架的性能问题

[jellychen]

5年前就听说 性能不是问题，机器愈来愈好，到今天这个CPU过剩时代，我们还是搞出了性能问题，在厉害的硬件也抵不住操蛋的程序！

[jellychen]

还有多个weex实例公用一个jscore的话，那么一直不释放这个jscore的确性能有加强。但是谁能保证前端代码没有内存泄露，如果泄露了那就呵呵了！ 这个也是一个坑！

[RubyLouvre]

其实阿里他们就是炒红了vue.js，来带动炒作他们的weex!

[data-farmer]

只能说真的写的好多

[mejustme]

读读，视野打开更多。

[0326]

最后在 iOS 下选用了总耗时最短的一次性接受所有 Virtual DOM 的策略，而 Android 选用了按“楼层”分段加载 Virtual DOM 的策略，这样的话 Android 的总加载时间其实变得更长了，但是首屏渲染速度大大提高.

我说怎么安卓的加载时间就是比iOS的长，还以为是苹果机高端些，原来是加载策略的问题~
另外很好奇这个按“楼层”分段加载Virtual DOM是如何实现的？

[jp1017]

😄 👍

[wendaoji]

@jellychen 我昨天为了买个东西（在6s上），先用浏览器访问淘宝，然后动不动就提示错误，没招了，只能安装淘宝客户端，看了一眼，190多m，不知道是不是用weex做的，没有感觉到什么好的体验。（我们在用vuejs）

[ideal]

请问最后的例子里，为什么不是：

<span style="color: red;">Hello{{title}}!</span>

?