小程序底层实现原理及一些思考（2） about blog HOT 9 OPEN

文章写的可以，有个点可以讨论下："之所以采用多UI线程的原因是单页应用很难模拟原生应用切换页面的体验"，这个结论有待商榷吧，单页面也可以做出多页面的切换效果，组件缓存后就没得刷新这个说法了；核心原因可能不是这个吧，不知道博主有没有新的见解

组件再怎么缓存也达不到多页切换的流畅度

自定义路由方式，使用absulute 的 div 作为 webview 实现多个页面，缓存dom的方式 缓存每个页面的内容，单页面模拟原生的push 和 pop 动画，以及实现App的回退的中间态滑动动画，可以实现，但是体验相同机器比较 总是逊色于原生交互。最主要的是 安全和管控

from blog.

大佬，请教几个问题哈。

1. 您目前阐述的原理，是不是目前市面上的小程序的底层实现都和你说的类似？包括微信小程序（这个应用最广泛）？
2. 针对具体技术细节，有个地方不是很清晰。比如在微信小程序的某个JS文件修改了一个状态A，那么在存在多个webview线程的情况下，如何定位到某个webview线程的某个组件根据状态A进行重新渲染呢？有一点需要注意：通信模块在通讯时，为了将信号准确地发送到指定位置，需要根据频道号发送，频道号的规范应该设置为[mid]_[pid]_[cid]。是根据这原理吗？
3. 针对微信小程序，逻辑线程如何通知到native，native如果再通知webview线程呢？大佬有时间详细讲一讲吗？或者提供一些文档也可以。目前，没有找到更好的解释。你这两篇文章质量很高，解决了我很多疑惑。感恩！也买了您的Vue.js书籍表达了支持！

from blog.

我很喜欢您的博客，也买过您出的书，如果大佬开启博客的白名单，可以把买过书的人拉进去吗？保证不外传。

from blog.

微信小程序的实现，在逻辑层也维护了一套虚拟dom，比如调用createSelectorQuery获取节点属性的时候，并不会去渲染层获取，逻辑层直接处理，这应该不是最主要的原因，为什么维护一套虚拟dom在逻辑层还在研究中

from blog.

微信小程序 现在应该也是多线程的

from blog.

文章写的可以，有个点可以讨论下："之所以采用多UI线程的原因是单页应用很难模拟原生应用切换页面的体验"，这个结论有待商榷吧，单页面也可以做出多页面的切换效果，组件缓存后就没得刷新这个说法了；核心原因可能不是这个吧，不知道博主有没有新的见解

from blog.

文章写的可以，有个点可以讨论下："之所以采用多UI线程的原因是单页应用很难模拟原生应用切换页面的体验"，这个结论有待商榷吧，单页面也可以做出多页面的切换效果，组件缓存后就没得刷新这个说法了；核心原因可能不是这个吧，不知道博主有没有新的见解

组件再怎么缓存也达不到多页切换的流畅度

from blog.

多UI线程是不是就是每个页面使用单独的webview，感觉这样内存会爆掉。。

from blog.

文章中分享的，逻辑层运行在web worker中，我分析了飞书的方案，他们的逻辑层好像运行在jscore中，这种区别是基于什么考虑？

from blog.