微信小程序技术演进内部开放微信原生能力使用预览图片
发表时间：2023-10-20 18:31:58
文章来源：炫佑科技
浏览次数：220
菏泽炫佑科技 菏泽炫佑小程序开发 菏泽炫佑app制作 炫佑科技
微信小程序技术演进内部开放微信原生能力使用预览图片
作者：腾讯IEG前端开发工程师。
微信小程序，简称小程序，英文mini。 是一款无需下载安装即可在微信中使用的应用程序。 用户可以扫描小程序码或搜索小程序打开。 它触手可及，可以立即使用。 无需担心安装太多应用程序。
小程序技术进化，内部开放微信原生能力
使用预览图像
此类API*初是为腾讯内部的一些业务使用提供的。 许多外部开发发现后纷纷效仿并使用，逐渐成为微信Web开发事实上的标准。
JS-SDK发布
2015年初，微信发布了一整套网页开发工具包，名为JS-SDK，开放了拍照、录音、语音识别、二维码、地图、支付、分享、优惠券等几十个API，让所有开发都可以使用微信的原生能力。
使用JS-SDK调用图片预览组件
JS-SDK解决了手机网页使用微信能力不足的问题。 通过暴露微信的接口，Web开发可以拥有更多的能力。 然而，除了更多的能力之外，JS-SDK模式并没有解决移动网页的使用问题。 遇到体验不佳的问题。
JS-SDK的缺点
当用户访问网页时，在浏览器开始显示之前会有一个白屏过程。 在移动端，受限于设备性能和网络速度，白屏会更加明显。 除了白屏之外，影响Web体验的问题就是操作反馈缺失，主要体现在两个方面：页面切换的僵硬和点击的滞后。
加载白屏，切换不流畅
另外，一些开发会利用JS-SDK制作假红包、假官方活动等，并利用JS-SDK的分享能力变相解离、分享到各个群组或朋友圈。 由于JS-SDK是根据域名来授予api权限的，所以运营商屏蔽某个域名后，会立即使用其他域名继续。 不好，你应该知道，注册一个新域名的成本是非常低的。
那么小程序是如何设计来改善JS-SDK的体验和控制缺陷的呢？
小程序双线程架构
在具体实现上小程序采用了类似网页的离线包的形式。 开发类似于web，门槛更低，开发效率更高。 离线下载和页面预渲染功能增强用户体验，提高加载速度，解决JS-SDK加载白屏问题1。 小程序提供了云端更新离线包的功能，并且可以动态更新页面，比App的更新发布更加灵活。 另外，小程序在离线包的基础上优化了切换动画，减少了切换页面带来的卡顿，缓解了切换不流畅的问题2。
小程序Web离线打包模式
小程序*大的架构特点是采用双线程开发模式，将JS逻辑和UI渲染隔离。 小程序的渲染层和逻辑层分别由两个线程管理：渲染层的界面渲染，逻辑层使用线程运行JS脚本。
逻辑层：创建单独的线程来执行。 在这个环境下，所有与小程序业务逻辑相关的代码都会被执行；
渲染层：所有与界面渲染相关的任务都在线程中执行，逻辑层代码用于控制渲染哪些界面。 一个小程序有多个接口，因此渲染层有多个线程；
通信：这两个线程之间的通信会通过微信客户端（以下也指微信客户端）进行中继，逻辑层发送的网络请求也会被转发。 小程序的通信模型如下图所示。
小程序双线程架构
JS逻辑层运行在并没有完整的浏览器对象。 因此，它缺少相关的DOM API和BOM API，无法操作页面元素。 这样可以达到控制的目的，但是也限制了开发的权限：
开发不得跳转至其他在线网页。 开发不允许直接访问DOM。 不允许开发随意使用一些未知的、有潜在危险的API。
这种逻辑层和UI层的隔离，再加上小程序的审核和上报机制，使得微信能够加强对小程序的管控，解决问题3。但这也使得开发无法灵活渲染页面。
小程序页面渲染
上面说了，逻辑层无法操作DOM变化，那么小程序是如何渲染页面的呢？ 小程序基于数据驱动的架构模型和Dom的概念（由React引入，一种真实DOM的JS描述方法）。 业务方只需要更改数据即可引起界面变化。 渲染层为WXML提供数据绑定语法，逻辑层提供其他API。 当开发需要进行界面变更时，只需要将变更的数据通过逻辑层中的执行传递给渲染层，小程序就会执行诸如Dom Diff（一种比较DOM结构并*小化变更的算法）等过程，*后在Dom树上更新正确的结果。
小程序DOM渲染
完整的通信流程大致如下：
逻辑层调用宿主环境的方法。 逻辑层将要传输的数据转换为字符串，拼接成具体的JS脚本，*后将数据传输到渲染层。 渲染层收到后，JS线程会编译脚本，获取需要更新的数据，进入渲染队列，在线程空闲时等待页面渲染。 当线程开始渲染时，需要更新的数据会合并到视图层保留的原始数据中，新的数据会应用到WXML片段中，得到一棵新的虚拟节点树。 新的虚拟节点树与当前节点树进行 diff 比较后，差异更新到 UI 视图中。 同时新的节点树替代旧的节点树进行下次重新渲染。小程序方案与React对比
那么小程序和现有的混合开发技术类型有哪些异同呢？ 尤其是和React的区别，为什么小程序技术架构不使用React？
混合开发技术类型
现有的混合开发类型根据UI渲染的分类主要有两类：
基于UI的基本解决方案。 市场上主流的如微信JS-SDK，通过完成H5与. 基于UI的解决方案，如React-、Weex等。在赋予H5原生API能力的基础上，将JS进一步解析为虚拟DOM并传递给它，并使用原生渲染。
小程序也属于类型1。这次我们主要使用类型2中的React来进行对比分析。
React技术架构框架
React 框架分为三个主要层：
JS层：这一层提供了各种组件供开发使用以及一些工具库（事件分发等）。 C层：主要处理java/OC与JS之间的通信（）和执行（JS脚本引擎）。 层（C/Java层）：主要包括UI渲染器、网络通信等工具库。 根据不同的操作系统有不同的实现。 界面渲染
React 基于 React 框架（Dom）进行 UI 渲染。 具体流程大致如下：
首先，JS层使用JSX编写的DOM来构建该层，将其转换为真正的DOM并插入到原生App页面中。 当有变化时，通过 diff 算法生成差异对象，*后该层将差异对象应用到原生 App 的页面元素上。
React是基于实现js和java/oc的交互。 具体流程大致如下：
将JSX代码解析为读取JS文件的代码小程序微信支付开发，并使用JS脚本引擎执行并返回一个数组。 该数组会描述OC/Java对象、对象属性以及需要执行的方法，以便对象可以设置属性。 并调用该方法。
建筑学
React优缺点优点：原生渲染，性能更好，用户体验更好； React生态较好微信小程序技术演进内部开放微信原生能力使用预览图片，对前端开发友好； 跨平台技术开发，成本和难度低于原生； 热更新，可以方便迭代。 缺点：支持的样式是CSS的子集，无法满足Web开发日益增长的需求； 现有能力下还存在一些不稳定问题，比如性能、Bug等； 所有渲染工作都交给客户端原生渲染。 会有更接近原生的体验，但其实一些简单的界面元素完全可以使用Web技术来渲染； React之前爆发了一个开源协议问题（BSD，一般内容是开发使用基于BSD协议的开源项目，如果以后因为专利问题发生纠纷，我们将有权阻止您使用）使用开源项目），将来也会有隐患。小程序不选择React的原因
小程序开发告知的原因如下：
React 仅支持 CSS 的一个子集。 作为一个开放的生态系统，开发需要了解哪些 CSS 属性可以使用，哪些不能使用。 这样的开发体验很差； （对应上面的缺点1）React本身存在一些问题，而这些依赖关系RN的修复也变得过于依赖客户端版本来解决开发这边的bug，修复周期过长。 （对应上面的缺点2）React前段时间也出现了一个开源协议问题，同样存在隐患。 （对应上面的缺点4）小程序和React有着相同的技术优势：接近原生体验，跨平台开发使用Web相关技术框架来编写业务代码，React就是React框架，小程序就是小程序开发实现了跨语言通信方案，完成（Java/-c/...）端与（小程序中的渲染层和逻辑层）之间的通信。 小程序和React的区别
小程序使用浏览器内核来渲染界面（少量原生组件由客户端渲染）。 界面以成熟的Web技术渲染为主，辅以大量接口提供丰富的客户端原生能力，而React就是客户端原生渲染。 。 理论上来说，React 的性能比 React 更好，但是类似 Web 的小程序开发对于开发来说上手相对简单，就像是开发效率和性能的双刃剑。
开发小程序需要注意的事项
基于以上架构分析，我们在开发过程中需要注意以下几点：
避免使用操作 DOM 的 npm 包。 由于逻辑层和渲染层是隔离的，逻辑层无法操作DOM/BOM API，因此需要使用DOM/BOM API的相关npm包和库不可用。 避免频繁通话。 由于其中的数据不仅需要经过层传递到渲染层，还要通过DOM diff算法等渲染到*终页面，因此需要尽量减少其使用，以避免出现性能问题。 避免传递大量新数据。 数据的传输会经过跨线程传输和脚本编译的过程。 当数据量过大时，会增加脚本编译的执行时间，占用JS线程，从而影响*终的渲染性能。
参考文档
小程序简介 | 微信开文档小程序简介 | 微信开文档React - 与小程序底层框架对比-云社区-腾讯云微信小程序原理分析及多端小程序架构原理（应该是全网*全的）| 玄币ejue个人博客小程序架构设计（一） | 微信开放社区小程序架构设计（二）| 微信开放社区福利时间
抽取5位好友赠送《小程序开发原理与实践》。 腾讯一线专家教你如何开发小程序，满满实用资讯！ 点击这里：参与福利！
