view 层的 WeixinJSBridge 接收到后台的数据，如果 webviewID 匹配则将 data 与现有页面 data 合并， 然后就是 virtual dom 模块进行 diff 和 apply 操作改变 dom。
小程序模块间消息传递除了界面事件和应用数据还包括触发原生方法、握手以及生命周期等类型， 尽管处理对象和处理方式不同，大体流程跟上面是一样的。
view 模块和 service 模块的 WeixinJSBridge 都使用了 postMessage 接口 (参考MDN 文档) 与后台通信，但是由于该接口无法直接与 nwjs 后台进程通信，所以开发者工具会将 app/dist/contentscript/contentScript.js 文件做为contentScript 注入到 view 模块和 service 模块所在页面，contentScript.js 的代码提供了 message 消息到 chrome.runtime通信接口的转换。
微信开发者工具扩展了 devtools 提供了 AppData 面板，开发者可以修改里面数据然后直接看到 view 界面的变化效果。这里修改数据后 nwjs 会将消息发送给 service 层，之后发生的事就跟上面 4 5 6 步一样：service 传递消息给 nwjs，最后到 view 层。
设计理念分析
小程序这样的分层设计显然是有意为之的，它的中间层完全控制了程序对于界面进行的操作， 同时对于传递的数据和响应时间也做到的监控。一方面程序的行为受到了极大限制， 另一方面微信可以确保他们对于小程序内容和体验有绝对的控制。
我们在小程序的 js 代码里面是不能直接使用浏览器提供的 DOM 和 BOM 接口的，这一方面是因为 js 代码外层使用了局部变量进行屏蔽，另一方面即便我们可以操作 DOM 和 BOM 接口，它们对应的 也是 service 模块页面，并不会对页面产生影响。
这样的结构也说明了小程序的动画和绘图 API 被设计成生成一个最终对象而不是一步一步执行的样子， 原因就是 json 格式的数据传递和解析相比与原生 API 都是损耗不菲的，如果频繁调用很可能损耗 过多性能，进而影响用户体验。
理解了以上机制，再对 view 模块和 service 模块的 WeixinJSBridge 加以改造，我们便不难做到让 小程序跑在自己的环境下，这样就可以做些手机调试以及单页面测试等操作。
