关于小程序:浅谈小程序

小程序的由来
最后微信 WebView 逐步成为挪动 web 重要入口，微信公布了一整套网页开发工具包，称之为 JS-SDK，给所有的 Web 开发者关上了一扇全新的窗户，让所有开发者都能够应用到微信的原生能力，去实现一些之前做不到或者难以做到的事件。
但 JS-SDK 的模式并没有解决应用挪动网页遇到的体验不良的问题，比方受限于设施性能和网络速度，会呈现白屏的可能。因而又设计了一个增强版 JS-SDK，也就是“微信 Web 资源离线存储”，但在简单的页面上仍然会呈现白屏的问题，起因体现在页面切换的僵硬和点击的通畅感。这个时候须要一个 JS-SDK 所解决不了的，使用户体验更好的一个零碎，小程序应运而生
疾速的加载
更弱小的能力
原生的体验
易用且平安的微信数据凋谢
高效和简略的开发

与 h5 页面的区别
运行环境：小程序基于浏览器内核重构的内置解析器，而 h5 的宿主环境是浏览器。所以小程序中没有 DOM 和 BOM 的相干 API，jQuery 和一些 NPM 包都不能在小程序中应用，以及禁止页面跳转的一些相干 api，因为这与小程序的初衷相违反，为了防止浏览器 api 更新一次就打一次补丁，小程序建设了本人的语法；
零碎权限：小程序能取得更多的零碎权限，如网络通信状态、数据缓存能力等；
渲染机制：小程序的逻辑层和渲染层是离开的，而 h5 页面 UI 渲染跟 JavaScript 的脚本执行都在一个单线程中，互斥。所以 h5 页面中长时间的脚本运行可能会导致页面失去响应。
其实，小程序开发过程中咱们面对的是 iOS 和 Android 微信客户端和辅助开发的小程序开发者工具。依据官网文档，这三大运行环境也是有所区别的：

所以微信小程序介于 web 端和原生 App 之间，可能丰盛调用性能接口，同时又跨平台。
小程序架构
双线程模型
小程序的渲染层和逻辑层别离由 2 个线程治理：
渲染层：界面渲染相干的工作全都在 WebView 线程里执行。一个小程序存在多个界面，所以渲染层存在多个 WebView 线程。
逻辑层：采纳 JsCore 线程运行 JS 脚本。
WeixinJsBridage 起到架起下层开发与 Native（零碎层）的桥梁，使得小程序可通过 API 应用原生的性能，且局部组件为原生组件实现，从而有良好体验。
视图层和逻辑层通过零碎层的 WeixinJsBridage 进行通信：逻辑层把数据变动告诉到视图层，触发视图层页面更新，视图层把触发的事件告诉到逻辑层进行业务解决。

（页面渲染的具体流程是：在渲染层，宿主环境会把 WXML 转化成对应的 JS 对象，在逻辑层产生数据变更的时候，咱们须要通过宿主环境提供的 setData 办法把数据从逻辑层传递到渲染层，再通过比照前后差别，把差别利用在原来的 Dom 树上，渲染出正确的 UI 界面）


双线程模型是小程序框架与业界大多数前端 Web 框架不同之处。基于这个模型，能够更好地管控以及提供更平安的环境。毛病是带来了无处不在的异步问题（任何数据传递都是线程间的通信，也就是都会有肯定的延时），不过小程序在框架层面曾经封装好了异步带来的时序问题。

这样做还有一个目标是管控和平安: 须要阻止开发者应用一些，例如浏览器的 window 对象，跳转页面、操作 DOM、动静执行脚本的开放性接口。小程序的 webview 标签以跳转网页，但集体类型的小程序暂不反对应用。可关上关联的公众号的文章，其它网页需登录小程序管理后盾配置业务域名。

Service 和 View 通信
应用音讯 publish 和 subscribe 机制实现两个 Webview 之间的通信，实现形式就是对立封装一个 WeixinJSBridge 对象，而不同的环境封装的接口不一样，具体实现的技术如下：
windows（开发环境）
通过 window.postMessage 实现（应用 chrome 扩大的接口注入一个 contentScript.js，它封装了 postMessage 办法，实现 webview 之间的通信，并且也它通过 chrome.runtime.connect 形式，也提供了间接操作 chrome native 原生办法的接口）
发送音讯：window.postMessage(data,‘*’);，// data 里指定 webviewID
接管音讯：window.addEventListener(‘message’, messageHandler); // 音讯解决并散发，同样反对调用 nwjs 的原生能力

拓展：[window.postMessage]: 能够实现跨文本文档, 多窗口, 跨域消息传递, 跨域通信解决方案.
语法：otherWindow.postMessage(message, targetOrigin]);
其中，otherWindow：窗口的一个援用, 比方 iframe 的 contentWindow 属性, 执行 window.open 返回的窗口对象, 或者是命名过的或数值索引的 window.frames.
targetOrigin：通过窗口的 origin 属性来指定哪些窗口能接管到音讯事件, 指定后只有对应 origin 下的窗口才能够接管到音讯, 设置为通配符 ”*” 示意能够发送到任何窗口。

IOS
通过 WKWebview 的 window.webkit.messageHandlers.NAME.postMessage 实现
微信 navite 代码里实现了两个 handler 音讯处理器
invokeHandler: 调用原生能力
publishHandler: 音讯散发

组件零碎 -Exparser 框架
如 view 会编译成 wx-view 组件渲染，不会编译成 h5 的标签。防止开发者通过 a 标签等实现跳转；这些根本组件就是基于 Exparser 框架。
Exparser 基于 WebComponents 的 ShadowDOM 模型，然而不依赖浏览器的原生反对，而且可在 纯 JS 环境中运行。长处：
1. 基于 Shadow DOM 模型：模型上与 WebComponents 的 ShadowDOM 高度类似，但不依赖浏览器的原生反对，也没有其余依赖库；实现时，还针对性地减少了其余 API 以反对小程序组件编程。
2. 可在纯 JS 环境中运行：这意味着逻辑层也具备肯定的组件树组织能力。
3. 高效轻量：性能体现好，在组件实例极多的环境下体现尤其优异，同时代码尺寸也较小。

小程序中，所有节点树相干的操作都依赖于 Exparser，包含 WXML 到页面最终节点树的构建、CreateSelectorQuery 调用和自定义组件个性等。

原生组件
在内置组件中，有一些组件并不齐全在 Exparser 的渲染体系下，而是由客户端原生参加组件的渲染。比如说 Map 组件。它渲染的层级比在 WebView 层渲染的一般组件要高。
引入原生组件的长处是：
扩大 Web 的能力
体验更好，加重 WebView 的渲染工作
绕过 setData、数据通信和重渲染流程，性能更好

运行机制
启动
热启动：：如果用户曾经关上过某小程序，而后在肯定工夫内再次关上该小程序，此时无需重新启动，只需将后盾态的小程序切换到前台，这个过程就是热启动；（相应周期 onHide，onShow）
冷启动：用户首次关上或小程序被微信被动销毁后再次关上的状况，此时小程序须要从新加载启动，即冷启动。

销毁
只有当小程序进入后盾肯定工夫，或者系统资源占用过高，才会被真正的销毁。
更新机制
开发者在后盾公布新版本之后，无奈立即影响到所有现网用户，但最差状况下，也在公布之后 24 小时之内下发新版本信息到用户。
小程序每次冷启动时，都会查看是否有更新版本，如果发现有新版本，将会异步下载新版本的代码包，并同时用客户端本地的包进行启动，即新版本的小程序须要等下一次冷启动才会利用上。
所以如果想让用户应用最新版本的小程序，能够利用 wx.getUpdateManager 做个查看更新的性能。

开发时遇到的一些问题：
Dataset 取值时都转成小写，如 data-ID=‘{{header}}’，e.currentTarget.dataset.id;
调用其如保留图片的 api 时安卓和苹果返回的错误码是不同的。解决：用机型进行真机调试或者在 vconsole 上打印。
笼罩原生组件 map、video、canvas、camera、live-player、live-pusher、textarea。（placeHolder 穿透蒙层等问题，自定义视频播放按钮等），用 cover-view 写；留神，在 cover-view 中只能嵌套 cover-view、cover-image 和 button。
开发工具申请失常真机异样，通常是域名没配置
this.setData({[‘messages[‘+ targetIndex +’].isLoad’]:false})
不波及页面渲染的变量能够不放在 this 里，在改值的时候不须要触发渲染