zhaobinglong
commented
4 years ago setData原理
从上面代码以及流程图中可以看出，在一次setData({a: 1})作时，会进行三次 JSON.stringify，二次JSON.parse以及两次window.postMessage操作。并且在第一次window.postMessage时，并不是单单只处理传递的{a:1}，而是处理当前页面的所有 data 数据。因此可想而知每次setData操作的开销是非常大的，只能通过减少数据量，以及减少setData操作来规避。
在一个列表中，有n条数据，采用上拉加载更多的方式，假如这个时候想对其中某一个数据进行点赞操作，还能及时看到点赞的效果 此时，可以采用setData全局刷新，点赞完成之后，重新获取数据，再次进行全局重新渲染，这样做的优点是：方便，快捷！缺点是：用户体验极其不好，当用户刷量100多条数据后，重新渲染量大会出现空白期（没有渲染过来）
如果局部刷新，知道点的是那一条数据, 将点赞的id传过去，查找相对应id的那条数据的下标（index是不会改变的），小程序setData里面的key支持数据路径的写法
补充
小程序的视图层目前使用 WebView 作为渲染载体，而逻辑层是由独立的 JavascriptCore 作为运行环境。在架构上，WebView 和 JavascriptCore 都是独立的模块，并不具备数据直接共享的通道。当前，视图层和逻辑层的数据传输，实际上通过两边提供的 evaluateJavascript 所实现。即用户传输的数据，需要将其转换为字符串形式传递，同时把转换后的数据内容拼接成一份 JS 脚本，再通过执行 JS 脚本的形式传递到两边独立环境。而 evaluateJavascript 的执行会受很多方面的影响，数据到达视图层并不是实时的。
参考
官方介绍：https://developers.weixin.qq.com/miniprogram/dev/framework/performance/tips.html
双线程通信
• 渲染层：渲染层的界面使用了 WebView 进行渲染，一个小程序存在多个界面，所以渲染层存在多个webview线程。 • 逻辑层：逻辑层采用 JsCore 线程运行 JS 脚本，逻辑层发送网络请求也会经由Native转发
小程序的基础库
小程序的基础库是JavaScript编写的，它可以被注入到渲染层和逻辑层运行。主要用于： • 在渲染层，提供各类组件来组件页面的元素 • 在逻辑层，提供各种API来处理各种元素。 • 处理数据绑定、组件系统、事件系统、通信系统等一系列框架逻辑 • 小程序的渲染层和逻辑层是两个线程管理，两个线程各自注入了基础库。 • 小程序的基础库不会打包在小程序的代码中，它会被提前内置在微信客户端 • 降低业务小程序的代码包大小 • 可以单独修复基础库中的Bug，无需修改到业务小程序的代码包 发请求 WeixinJSBridge 真正发送处理数据请求的时这端代码；如果当前环境是 ios, 那么调用 WKWebview 的 window.webkit.messageHandlers.invokeHandler.postMessage。如果所处环境是 android 则调用 WeixinJSCore.invokeHandler(调用的时候，默认会带上当前 webviewID)。
微信小程序的吐槽
• 一开始不支持从 node_modules 中加载模块。背离了潮流 • 开发工具上自带一个代码编辑器，鸡肋的存在 • 定义了一套wxss，支持大部分css，这个就有点玄乎了
架构思考
微信的这种架构，对逻辑和UI进行了完全隔离，小程序逻辑和UI完全运行在2个独立的Webview里面来处理。那么这么做的好处是啥？总感觉更加麻烦了。除了小程序外，还有人采用这种架构设计么？ 在网上搜索了一下，目前使用这种架构的项目还真有一个：去哪儿最新的 YIS 框架 YIS 采取了类似小程序的架构，分为逻辑层和UI层。UI 层运行在 WebView 中，而逻辑层运行在独立的 JS 引擎中。相应地，整个应用的代码，也分为两个大的部分，一部分运行在 WebView 中，一部分运行在JS引擎中。JS引擎计算DOM结构输出给WebView，WebView转发用户的点击事件给JS引擎。 该项目做法和小城十分类似，唯一缺少的就是没有 native 的组件吧。然而官方文档上也没有任何介绍，为什么要这么做，只是说更流畅了。