分析小程序的实现原理(小程序的工作原理)

摘要

作为一个前端开发者，如果你还停留在应用开发的层面，那你就落伍了。来和我探讨一下小程序框架本身底层实现的一些技术细节。下面我们就从小程序的运行机制来深入了解一下。小程序是一套基于WEB规范的框架，使用HTML、CSS、JS等。微信官方将其命名为WXML、WXSS，但本质上是在整个WEB体系下搭建的。WXml，我个人猜测名字是微信的Xml。归根结底，它是XML的子集。WXSS中使用了微信定义的少量标签WXSS，可以理解为自定义CSS。实现逻辑部分的JS是通用的ES规范，运行时是Webview(IOS WKWEBVIEW，ANDROID X5)。

(学习推荐:小程序开发教程)

小程序；迷你程序

小程序目录结构

一个完整的小程序主要由以下几个部分组成:一个入口文件:app.js，一个全局样式:app.wxss，一个全局配置:app.json页面，每个页面分为文件夹，每个页面有四个文件视图:wxml，wxss逻辑:js，json(页面配置，非必须)

注意:页面也可以按照模块分为子目录和孙子目录，在app.json注册时填写路径即可

小程序打包

开发完成后，我们可以点击这里的可视化按钮，直接打包，上传发布，审批通过后用户就可以搜索了。

那么包装是如何实现的呢？这就涉及到这个编辑器的实现原理和方法了。它也是基于WEB技术系统实现的。nwjs+react是什么？简单来说就是node+webkit的意思。node为我们提供本地api能力，webkit为我们提供web能力。两者的结合将使我们能够使用JS+HTML来实现本地应用程序。现在有了nodejs，上面打包选项中的功能就很容易实现了。ES6到ES5:用babel-core完成节点包的CSS:用postcss和autoprefixer完成节点包(postcss和autoprefixer的原理见这里)代码压缩:用uglifyjs完成节点包。

注意:android上用的x5内核不太支持ES6。如果兼容，要么用ES5语法，要么引入babel-polyfill兼容库。

打包目录结构

applet的打包结构如下:

基本上所有的小程序最后都放到上面的结构里。1.WAService.js框架js库，提供逻辑层的基本API能力。2.WAWebview.js框架js库，提供视图层的基本API能力。3.WAConsole.js框架js库，控制台4，app-config.js小程序完整配置，它包含了app.json中的所有配置，集成了默认的配置类型5，app-service.js和我们自己的JS代码，全部打包到这个文件6，page-frame.html小程序视图的模板文件。所有的页面都是由这个文件加载和渲染的，所有的wxml都是为了JS实现而反汇编，打包到这里的所有页面中。这不是我们之前的WXML文件，它主要处理WXSS转换。

小程序架构

微信小程序的框架由视图层和App服务逻辑层两部分组成。视图层用于呈现页面结构，AppService层用于逻辑处理、数据请求和接口调用。它们在两个进程中运行(两个Webview)。视图层通过系统层的桥接与逻辑层通信。逻辑层通知视图层数据的变化，这触发了视图层的页面更新。视图层将触发的事件通知给逻辑层进行业务处理。

小程序架构图:

小程序启动时会从CDN下载小程序的完整包，一般用数字命名，比如:_ -2082693788 _ 4.wxapkg。

小程序技术实现

小程序的UI视图和逻辑处理是通过多个webviews实现的。所有逻辑处理的JS代码都加载到一个webview中，这个webview叫做AppService。只有一个小程序，整个生命周期都是内存常驻。所有视图(wxml和wxss)都由单独的webviews承载，这些webviews称为AppView。所以一个小程序打开的时候，至少会有两个webview进程。官方表示，由于每个视图都是独立的webview进程，考虑到性能消耗，小程序不允许打开五级以上的页面。当然，同样也是为了更好的体验。

应用服务

可以理解为AppService是一个简单的页面，主要功能是负责逻辑处理部分的执行。底层提供一个WAService.js的文件来提供各种api接口，主要包括以下几个部分:消息通信封装为WeixinJSBridge(开发环境为window.postMessage，Windows。WebKit。消息处理程序。InvokeHandler。IOS下的Postmessage，android下的weixin score . invoke handler)

1.日志组件报告程序包2。wx对象3下的api方法。app、page、getapp、getcurrentpages 4等全局方法。AMD模块规范的实现。

然后整个页面就是加载一堆js文件，包括小程序配置config，上面有WAService.js(调试模式下的asdebug.js)，剩下的都是我们自己写的js文件，都是一次性加载的。

在开发环境中

1.页面模板:app.nw/app/dist/weapp/tpl/appserviceTpl.js新协议。配置信息直接写入js变量__wxConfig。3.其他配置

在线环境

上线后应用部分会打包成两个文件，分别命名为app-config.json和app-service.js，然后微信打开webview加载。线上部分应该是微信自己提供了相应的模板文件，压缩包里没有。1、WAService.js(底层支持)2、app-config.json(应用配置)3、app-service.js(应用逻辑)

然后在JavaScriptCore引擎中运行。

AppView

这里可以理解为h5的页面，提供UI渲染，底层提供一个WAWebview.js来提供底层的功能，如下:1。消息通信封装为WeixinJSBridge(开发环境为window.postMessage，Windows。IOS下WKWebview的WebKit . message handlers . invoke handler . postmessage，android下weixinjcore.invokehandler。日志组件报告程序包3。wx对象下的api，这里的api和WAService里的不太一样。有几个在那边也有类似的功能，但是大部分都是UI显示相关的方法。4.applet组件的实现和注册。5.VirtualDOM、Diff和Render UI的实现。6.页面事件触发。

在此基础上，AppView有一个html模板文件，通过这个文件加载具体的页面。这个模板主要有一个方法，$gwx，主要返回指定页面的VirtualDOM。打包时，所有页面的WXML都会提前转换成ViirtualDOM，放入模板文件中。微信自己写了两个工具wcc(把WXML转换成VirtualDOM)和wcsc(把WXSS转换成一个JS字符串，通过style标签追加到头部)。

与服务视图通信。

消息发布和订阅机制用于实现两个Webview之间的通信。实现方法是统一封装一个WeixinJSBridge对象，但是不同环境封装的接口不一样。具体实现技术如下:

Windows环境

通过window.postMessage实现(利用chrome扩展的接口注入一个contentScript.js，封装了postMessage方法，实现了webview之间的通信，它还提供了一个通过chrome.runtime.connect直接操作chrome native原生方法的接口)，发送消息:window.postMessage(data，' * * ')；// data中指定的webviewID接收消息:window . addevent listener(' message '，消息处理程序)；//消息处理和分发也支持调用nwjs的原生能力。在contentScript里看到一句话，证实了appservice也是通过一个webview实现的。实现原理和view一样，只是业务逻辑不同。

'webframe # 39=== b？postMessageToWebPage(a): # 39；appservice # 39= = = b postMessageToWebPage(a)IOS

由WKWebview的window . WebKit . message handlers . name . postmessage实现。在微信navite的代码中实现了两个handler消息处理程序:invokeHandler:调用原生能力publishHandler:消息分发

Android是通过WeixinJSCore.invokeHanlder实现的，这是微信为JS调用提供的接口(原生实现):invokeHandler:调用原生能力publishHandler:消息分发。

微信组件

在WAWebview.js中，有一个名为exparser的对象，完全实现了小程序中的组件。具体实现方法见。这个想法和w3c的web组件规范是一样的，只是具体实现不同。我们使用的所有组件都会提前注册，在Webview中渲染时进行替换和组装。Exparser有一个核心方法:regiisterBehavior:注册组件的一些基本行为让它们继承registerElement:注册组件，和我们的接口主要是属性和事件。

组件触发事件(用webviewID)，调用WeixinJSBridge的接口，发布到native，然后native分发到AppService层中指定webviewID的页面注册事件处理方法。

摘要

小程序底层是基于Webview实现的，没有发明新技术。整个框架体系相对清晰简单，基于Web规范，保证现有技能价值的最大化。只有了解框架规范，才能使用现有的Web技术进行开发。易于理解和开发。

MSSM:逻辑和ui是完全隔离的，这和现在流行的react、agular、vue有本质区别。小程序的逻辑和UI完全运行在两个独立的Webview中，而后面的框架仍然运行在一个Webview中。如果愿意，还是可以直接操作dom对象，渲染UI。

组件机制:引入了组件机制，但并不完全基于组件开发。和vue一样，大多数ui都是以模板的形式呈现的。组件机制的引入可以更好的规范开发方式，升级维护更加方便。

多重气质:不能同时打开5个以上的窗口，打包文件不能大于1M，dom对象不能大于16000等。这些都是为了保证更好的体验。

以上是分析小程序实现原理的详细内容。更多请关注主机参考其他相关文章！

这几篇文章你可能也喜欢：

• applet实现原理分析(applet结构详解及实例)

本文由主机参考刊发，转载请注明：分析小程序的实现原理(小程序的工作原理) https://zhujicankao.com/79353.html