微信小程序，简称mini程序，英文miniprogram。是一款无需下载安装即可在微信中使用的应用。用户可以扫描小程序代码或搜索小程序打开。它触手可及，随时可用。他们无需担心安装太多应用程序。小程序技术演进开放微信原生能力，使用WeixinJSBridge预览图片。像这样的API，本来是给腾讯内部业务使用的。很多外部开发者发现后，一贯使用，逐渐成为微信web开发的事实。标准。JS-SDK发布2015年初，微信发布了一套完整的web开发工具包JS-SDK，开放了拍摄、录音、语音识别、二维码、地图、支付、分享、优惠券等几十个API。.让所有的开发者都能接触到微信的原生能力。使用JS-SDK调用图片预览组件JS-SDK解决了手机网页微信使用能力不足的问题。通过暴露微信的接口，Web开发者可以拥有更多的能力。然而，除了更多的能力之外，JS-SDK模型并没有解决移动端网页使用体验不佳的问题。JS-SDK不足用户访问网页时，在浏览器开始显示之前会有一个白屏过程。在移动端，受限于设备性能和网速，白屏会更加明显。除了白屏，影响网页体验的问题还有操作反馈不足，主要表现在两个方面：页面切换的生硬和点击的迟钝感。loading画面发白，切换不流畅。另外，一些开发者会利用JS-SDK做一些事情，比如假红包、假官方活动等，并利用JS-SDK的分享能力，变相裂变分享到各个群或朋友圈。由于JS-SDK是根据域名来授予API权限的，所以运营商封了一个域名后，马上又换了一个域名继续。不好，知道注册一个新域名的费用很低。那么小程序是如何设计来提升JS-SDK的体验和控制不足的呢？小程序的双线程架构具体是通过类web+离线包的形式实现的。开发类似web，门槛更低，开发效率更高。离线下载和页面预渲染功能提升用户体验，提升加载速度，解决JS-SDK加载白屏问题1.小程序提供云端更新离线包功能，可动态更新页面，比app的更新发布更加灵活。另外，小程序在离线包的基础上优化了切换动画，减少了页面切换带来的卡顿，缓解了切换不流畅的问题2.小程序web+离线包模式小程序在架构上最大的特点是采用了双线程开发模式，将JS逻辑和UI渲染隔离开来。小程序的渲染层和逻辑层分别由两个线程管理：渲染层的界面使用WebView进行渲染，逻辑层使用JsCore线程运行JS脚本。逻辑层：创建一个单独的线程来执行JavaScript。在这个环境中，执行与小程序业务逻辑相关的代码；渲染层：所有与界面渲染相关的任务都在WebView线程中执行，通过接口的逻辑层代码控制渲染。一个小程序中有多个接口，所以渲染层有多个WebView线程；communication：这两个线程之间的通信会通过微信客户端中转（后面也会用Native来指代微信客户端），逻辑层发送网络请求也是通过Native转发的，通信模型小程序的结构如下图所示。小程序双线程架构的JS逻辑层运行在JSCore中，没有完整的浏览器对象。因此，它缺少相关的DOMAPI和BOMAPI，无法对页面元素进行操作。可以达到控制的目的，但是也限制了开发者的权限：不允许开发者跳转到其他在线网页，不允许开发者直接访问DOM，不允许开发者使用一些未知的和可能的随意在window上的危险API，逻辑层和UI层的这种隔离，加上小程序的审核和上报机制，让微信加强了对小程序的管控，解决了问题3。但这也让开发者无从下手灵活地进行页面渲染。小程序页面渲染上面已经说了逻辑层无法操作DOM变化，那么小程序如何渲染页面呢？小程序基于数据驱动的架构模型，基于VirtualDom（React引入，真实DOM的一种JS描述方式）理念，业务方只需改变数据引起界面变化。渲染层为WXML提供数据绑定语法，逻辑层提供setData等API。当开发者需要改变界面时，只需要在逻辑层执行setData，将改变的数据通过Native层传输到渲染层即可，小程序会执行DomDiff（一种比较DOM结构和最小化变化的算法）等过程，最后在Dom树上更新正确的结果。小程序虚拟DOM渲染的完整通信过程大致如下：逻辑层调用宿主环境的setData方法。逻辑层将需要传输的数据转换成字符串，拼接成具体的JS脚本，最后将数据传输到渲染层。渲染层接收到后，WebViewJS线程编译脚本，获取待更新数据并进入渲染队列，空闲时等待WebView线程渲染页面。当WebView线程开始渲染时，会将要更新的数据合并到视图层保留的原始数据中，并将新数据应用到WXML片段中，得到新的虚拟节点树。比较新的虚拟节点树和当前节点树之间的差异后，将差异更新到UI视图。同时，用新的节点树替换旧的节点树，以便下次重新渲染。小程序与ReactNative对比那么小程序与现有的混合开发技术类型有哪些异同呢？尤其是和ReactNative的区别，为什么小程序的技术架构没有采用ReactNative？混合开发技术类型现有的混合开发类型，根据UI渲染的分类，主要有两大类：基于WebViewUI的基本方案。市场上主流的如微信JS-SDK，通过JSBridge完成H5与Native的双向通信，从而赋予H5一定的原生能力。基于NativeUI的解决方案，如React-Native、Weex、Flutter等。在赋予H5原生API能力的基础上，进一步使用JSBridge将JS解析成虚拟DOM传递给Native，使用原生渲染.小程序也属于类型1，这次我们主要使用类型2中的ReactNative作为对比分析。ReactNative技术架构框架ReactNative框架主要分为三层：JS层：该层为开发者提供各种组件和一些工具库（事件分发等）。C++层：主要处理java/OC与JS（JSBridge）的通信，执行JavaScript（JS脚本引擎）。Native层（ObjectC/Java层）：主要包括UI渲染器、网络通信等工具库。根据操作系统的不同，有不同的实现。UI渲染ReactNative基于React框架（VirtualDom）进行UI渲染。具体过程大致如下：首先，JS层通过用JSX编写的VirtualDom构建ComponentNative层，将其转化为真实的DOM，插入到nativeapp的页面中。当有变化时，通过diff算法生成差异对象，最终Native层将差异对象应用到原生App的页面元素中。通信ReactNative基于JSCore实现了js与java/oc的交互。具体过程大致如下：将JSX代码解析成javaScript代码，读取JS文件，使用JS脚本引擎执行，返回一个数组，里面会描述OC/Java对象。描述对象的属性和需要执行的方法，以便对象可以设置属性和调用方法。ReactNativeArchitectureReactNative优缺点优势原生渲染，性能更好，用户体验更好；React生态更好，对前端开发友好；hybrid技术跨平台开发，成本和难度低于原生；热更新，易于迭代。缺点支持的样式是CSS的子集，将不能满足web开发者日益增长的需求；现有能力下还存在一些不稳定的问题，比如性能、bug等；所有的渲染工作都交给客户端进行原生渲染，会有更接近原汁原味的体验，但实际上一些简单的界面元素完全可以使用Web技术进行渲染；ReactNative之前曾曝光过一个开源协议问题（FacebookBSD+Patents，大致内容是使用基于FacebookBSD+Patents的协议如果你是一个开源项目的开发者，如果由于以下原因与Facebook产生纠纷未来专利问题，那么Facebook有权阻止你使用开源项目），这在未来也会有隐患。小程序没有选择ReactNative的原因，根据小程序开发者的说法是：ReactNative只支持CSS的一个子集。作为一个开放的生态系统，有必要告知开发者哪些CSS属性可以使用，哪些不能使用。这样的开发体验差；（对应上面的劣势1）ReactNative自身存在一些问题，依赖RN的修复，同时过于依赖客户端release版本来解决开发者的bug，修复周期过长.（对应上面的劣势2）前段时间ReactNative也出了一个开源协议问题，也是一个隐患。（对应上面的劣势4）小程序和ReactNative的相似点有混合技术的优点：接近原生体验，跨平台开发使用Web相关技术框架编写业务代码，ReactNative是React框架，小程序是小程序开发框架。分别实现跨语言通信解决方案完成Native(Java/Objective-c/...)和JavaScript（小程序中的渲染层和逻辑层）的通信小程序和ReactNative的区别在于小程序使用浏览器内核WebView渲染界面（客户端渲染少量原生组件），界面以成熟的web技术渲染为主，辅以大量界面提供客户端丰富的原生能力，ReactNative是原生的客户端渲染。从理论上讲，ReactNative比WebView有更好的性能，但是小程序类Web开发对于开发来说相对简单，这就像一把开发效率和性能的双刃剑。小程序开发注意事项基于以上架构分析，我们在开发过程中需要注意以下几点：避免使用操作DOM的npm包。由于逻辑层和渲染层隔离，逻辑层无法操作DOM/BOMAPI，所以在与DOM/BOMAPI相关的npm包和库中不可用。避免频繁调用setData。由于setData中的数据不仅需要通过Native层传递给渲染层，还需要通过DOMdiff算法等渲染到最终页面中，因此需要尽量减少setData的使用，避免性能问题。避免setData传递大量新数据。数据传输会经过跨线程传输和脚本编译的过程。当数据量过大时，会增加脚本编译的执行时间，占用WebViewJS线程，从而影响最终的渲染性能。
