【移动应用开发技术】小程序运行机制的示例分析

【移动应用开发技术】小程序运行机制的示例分析

在下给大家分享一下小程序运行机制的示例分析，相信大部分人都还不怎么了解，因此分享这篇文章给大家参考一下，希望大家阅读完这篇文章后大有收获，下面让我们一起去了解一下吧！ 写作背景接触小程序有一段时间了，总得来说小程序开发门槛比较低，但其中基本的运行机制和原理还是要懂的。“比如我在面试的时候问到一个关于小程序的问题，问小程序有window对象吗？他说有吧”，但其实是没有的。感觉他并没有了解小程序底层的一些东西，归根结底来说应该只能算会使用这个工具，但并不明白其中的道理。小程序与普通网页开发是有很大差别的，这就要从它的技术架构底层去剖析了。还有比如习惯Vue，react开发的开发者会吐槽小程序新建页面的繁琐，page必须由多个文件组成、组件化支持不完善、每次更改data里的数据都得setData、没有像Vue方便的watch监听、不能操作Dom，对于复杂性场景不太好，之前不支持npm，不支持sass，less预编译处理语言。“有的人说小程序就像被阉割的Vue”，哈哈当然了，他们从设计的出发点就不同，咱也得理解小程序设计的初衷，通过它的使用场景，它为什么采用这种技术架构，这种技术架构有什么好处，相信在你了解完这些之后，就会理解了。下面我会从以下几个角度去分析小程序的运行机制和它的整体技术架构。了解小程序的由来在小程序没有出来之前，最初微信WebView逐渐成为移动web重要入口，微信发布了一整套网页开发工具包，称之为JS-SDK，给所有的Web开发者打开了一扇全新的窗户，让所有开发者都可以使用到微信的原生能力，去完成一些之前做不到或者难以做到的事情。但JS-SDK的模式并没有解决使用移动网页遇到的体验不良的问题，比如受限于设备性能和网络速度，会出现白屏的可能。因此又设计了一个增强版JS-SDK，也就是“微信Web资源离线存储”，但在复杂的页面上依然会出现白屏的问题，原因表现在页面切换的生硬和点击的迟滞感。这个时候需要一个JS-SDK所处理不了的，使用户体验更好的一个系统，小程序应运而生。快速的加载更强大的能力原生的体验易用且安全的微信数据开放高效和简单的开发小程序与普通网页开发的区别小程序的开发同普通的网页开发相比有很大的相似性，小程序的主要开发语言也是JavaScript，但是二者还是有些差别的。普通网页开发可以使用各种浏览器提供的DOMAPI，进行DOM操作，小程序的逻辑层和渲染层是分开的，逻辑层运行在JSCore中，并没有一个完整浏览器对象，因而缺少相关的DOMAPI和BOMAPI。普通网页开发渲染线程和脚本线程是互斥的，这也是为什么长时间的脚本运行可能会导致页面失去响应，而在小程序中，二者是分开的，分别运行在不同的线程中。网页开发者在开发网页的时候，只需要使用到浏览器，并且搭配上一些辅助工具或者编辑器即可。小程序的开发则有所不同，需要经过申请小程序帐号、安装小程序开发者工具、配置项目等等过程方可完成。小程序的执行环境小程序架构一、技术选型一般来说，渲染界面的技术有三种：用纯客户端原生技术来渲染用纯Web技术来渲染用客户端原生技术与Web技术结合的混合技术（简称Hybrid技术）来渲染通过以下几个方面分析，小程序采用哪种技术方案开发门槛：Web门槛低，Native也有像RN这样的框架支持体验：Native体验比Web要好太多，Hybrid在一定程度上比Web接近原生体验版本更新：Web支持在线更新，Native则需要打包到微信一起审核发布管控和安全：Web可跳转或是改变页面内容，存在一些不可控因素和安全风险由于小程序的宿主环境是微信，如果用纯客户端原生技术来编写小程序，那么小程序代码每次都需要与微信代码一起发版，这种方式肯定是不行的。所以需要像web技术那样，有一份随时可更新的资源包放在云端，通过下载到本地，动态执行后即可渲染出界面。如果用纯web技术来渲染小程序，在一些复杂的交互上可能会面临一些性能问题，这是因为在web技术中，UI渲染跟JavaScript的脚本执行都在一个单线程中执行，这就容易导致一些逻辑任务抢占UI渲染的资源。所以最终采用了两者结合起来的Hybrid技术来渲染小程序，可以用一种近似web的方式来开发，并且可以实现在线更新代码，同时引入组件也有以下好处：扩展Web的能力。比如像输入框组件（input,textarea）有更好地控制键盘的能力体验更好，同时也减轻WebView的渲染工作绕过setData、数据通信和重渲染流程，使渲染性能更好用客户端原生渲染内置一些复杂组件，可以提供更好的性能二、双线程模型小程序的渲染层和逻辑层分别由2个线程管理：视图层的界面使用了WebView进行渲染，逻辑层采用JsCore线程运行JS脚本。那么为什么要这样设计呢，前面也提到了管控和安全，为了解决这些问题，我们需要阻止开发者使用一些，例如浏览器的window对象，跳转页面、操作DOM、动态执行脚本的开放性接口。我们可以使用客户端系统的JavaScript引擎，iOS下的JavaScriptCore框架，安卓下腾讯x5内核提供的JsCore环境。这个沙箱环境只提供纯JavaScript的解释执行环境，没有任何浏览器相关接口。这就是小程序双线程模型的由来：逻辑层：创建一个单独的线程去执行JavaScript，在这里执行的都是有关小程序业务逻辑的代码，负责逻辑处理、数据请求、接口调用等视图层：界面渲染相关的任务全都在WebView线程里执行，通过逻辑层代码去控制渲染哪些界面。一个小程序存在多个界面，所以视图层存在多个WebView线程JSBridge起到架起上层开发与Native（系统层）的桥梁，使得小程序可通过API使用原生的功能，且部分组件为原生组件实现，从而有良好体验三、双线程通信把开发者的JS逻辑代码放到单独的线程去运行，但在Webview线程里，开发者就没法直接操作DOM。那要怎么去实现动态更改界面呢？如上图所示，逻辑层和试图层的通信会由Native（微信客户端）做中转，逻辑层发送网络请求也经由Native转发。这也就是说，我们可以把DOM的更新通过简单的数据通信来实现。VirtualDOM相信大家都已有了解，大概是这么个过程：用JS对象模拟DOM树->比较两棵虚拟DOM树的差异->把差异应用到真正的DOM树上。如图所示：在渲染层把WXML转化成对应的JS对象。在逻辑层发生数据变更的时候，通过宿主环境提供的setData方法把数据从逻辑层传递到Native，再转发到渲染层。经过对比前后差异，把差异应用在原来的DOM树上，更新界面。我们通过把WXML转化为数据，通过Native进行转发，来实现逻辑层和渲染层的交互和通信。而这样一个完整的框架，离不开小程序的基础库。四、小程序的基础库小程序的基础库可以被注入到视图层和逻辑层运行，主要用于以下几个方面：在视图层，提供各类组件来组建界面的元素在逻辑层，提供各类API来处理各种逻辑处理数据绑定、组件系统、事件系统、通信系统等一系列框架逻辑由于小程序的渲染层和逻辑层是两个线程管理，两个线程各自注入了基础库。小程序的基础库不会被打包在某个小程序的代码包里边，它会被提前内置在微信客户端。这样可以：降低业务小程序的代码包大小可以单独修复基础库中的Bug，无需修改到业务小程序的代码包五、Exparser框架Exparser是微信小程序的组件组织框架，内置在小程序基础库中，为小程序的各种组件提供基础的支持。小程序内的所有组件，包括内置组件和自定义组件，都由Exparser组织管理。Exparser的主要特点包括以下几点：基于ShadowDOM模型：模型上与WebComponents的ShadowDOM高度相似，但不依赖浏览器的原生支持，也没有其他依赖库；实现时，还针对性地增加了其他API以支持小程序组件编程。可在纯JS环境中运行：这意味着逻辑层也具有一定的组件树组织能力。高效轻量：性能表现好，在组件实例极多的环境下表现尤其优异，同时代码尺寸也较小。小程序中，所有节点树相关的操作都依赖于Exparser，包括WXML到页面最终节点树的构建、createSelectorQuery调用和自定义组件特性等。内置组件基于Exparser框架，小程序内置了一套组件，提供了视图容器类、表单类、导航类、媒体类、开放类等几十种组件。有了这么丰富的组件，再配合WXSS，可以搭建出任何效果的界面。在功能层面上，也满足绝大部分需求。六、运行机制小程序启动会有两种情况，一种是「冷启动」，一种是「热启动」。假如用户已经打开过某小程序，然后在一定时间内再次打开该小程序，此时无需重新启动，只需将后台状态的小程序切换到前台，这个过程就是热启动；冷启动指的是用户首次打开或小程序被微信主动销毁后再次打开的情况，此时小程序需要重新加载启动。小程序没有重启的概念当小程序进入后台，客户端会维持一段时间的运行状态，超过一定时间后（目前是5分钟）会被微信主动销毁当短时间内（5s）连续收到两次以上收到系统内存告警，会进行小程序的销毁七、更新机制小程序冷启动时如果发现有新版本，将会异步下载新版本的代码包，并同时用客户端本地的包进行启动，即新版本的小程序需要等下一次冷启动才会应用上。如果需要马上应用最新版本，可以使用wx.getUpdateManagerAPI进行处理。八、性能优化主要的优化策略可以归纳为三点：精简代码，降低WXML结构和JS代码的复杂性；合理使用setData调用，减少setData次数和数据量；必要时使用分包优化。1、setData工作原理小程序的视图层目前使用WebView作为渲染载体，而逻辑层是由独立的JavascriptCore作为运行环境。在架构上，WebView和JavascriptCore都是独立的模块，并不具备数据直接共享的通道。当前，视图层和逻辑层的数据传输，实际上通过两边提供的evaluateJavascript所实现。即用户传输的数据，需要将其转换为字符串形式传递，同时把转换后的数据内容拼接成一份JS脚本，再通过执行JS脚本的形式传递到两边独立环境。而evaluateJavascript的执行会受很多方面的影响，数据到达视图层并不是实时的。2、常见的setData操作错误频繁的去setData在我们分析过的一些案例里，部分小程序会非常频繁（毫秒级）的去setData，其导致了两个后果：Android下用户在滑动时会感觉到卡顿，操作反馈延迟严重，因为JS线程一直在编译执行渲染，未能及时将用户操作事件传递到逻辑层，逻辑层亦无法及时将操作处理结果及时传递到视图层；渲染有出现延时，由于WebView的JS线程一直处于忙碌状态，逻辑层到页面层的通信耗