一、双线程模型
渲染线程和逻辑线程
小程序的双线程指的就是渲染线程和逻辑线程，这两个线程别离承当 UI 的渲染和执行 JavaScript 代码的工作
渲染线程应用 Webview 进行 UI 的渲染出现。Webview 是一个残缺的类浏览器运行环境，自身具备运行 JavaScript 的能力，然而小程序并不是将逻辑脚本放到 Webview 中运行，而是将逻辑层独立为一个与 Webview 平行的线程，应用客户端提供的 JavaScript 引擎运行代码，iOS 的 JavaScriptCore、安卓是腾讯 X5 内核提供的 JsCore 环境以及 IDE 工具的 nwjs
并且逻辑线程是一个只可能运行 JavaScript 的沙箱环境，不提供 DOM 操作相干的 API，所以不能间接操作 UI，只可能通过 setData 更新数据的形式异步更新 UI
事件驱动的通信形式
你要留神上图渲染线程和逻辑线程之间的通信形式，与 Vue/React 不同的是，小程序的渲染层与逻辑层之间的通信并不是在两者之间间接传递数据或事件，而是由 Native 作为两头媒介进行转发。
整个过程是典型的事件驱动模式：
渲染层（也能够称为视图层）通过与用户的交互触发特定的事件 event；而后 event 被传递给逻辑层；逻辑层继而通过一系列的逻辑解决、数据申请、接口调用等行为将加工好的数据 data 传递给渲染层；最初渲染层将 data 渲染为可视化的 UI。总的来说，跟浏览器的线程模型相比，小程序的双线程模型解决了或者说躲避了 Web Worker 堪忧的性能同时又实现了与 Web Worker 雷同的线程平安，从性能和平安两个角度实现了晋升。能够概括地说，双线程模式是受限于浏览器现有的过程和线程管理模式之下，在小程序这一具体场景之内的一种改良的架构计划。
留神：浏览器中 Worker 内的 JavaScript 代码不能操作 DOM，能够将其了解为线程平安的
性能方面
在保障性能的前提下尽量应用构造简略的 UI；尽量升高 JavaScript 逻辑的复杂度；尽量减少 setData 的调用频次和携带的数据体量。二、小程序的用户体系与 OAuth 标准
微信小程序残缺的登录流程
整个登录流程中形容了三种角色和六个术语，理解它们的定位和作用，是了解小程序登录流程的根底。
登录流程里的三个角色
客户端在整个登录流程中次要承当两种行为：
作为整个流程的发起者，获取长期登录凭证 code；作为整个流程的终结者，存储登录态令牌 token。不过客户端的所有信息和网络申请简直都是能够被破解或拦挡的，所以出于平安的思考，小程序登录流程中的一些接口被限度不能在客户端中间接调用，而是须要在服务端发动，开发者服务的工作便是解决这些平安敏感的网络申请，体现为上图中应用 code 获取 openid 和 session_key 的申请，这个申请应用了微信提供的 auth.code2Session 接口。而微信接口服务的工作对于开发者来说是不通明的，你须要做的仅仅是依据接口的标准，组装网络申请发送给它，而后依据返回的接口执行散发逻辑。微信服务器会验证网络申请的合法性，对于非法申请下发密钥 session_key 和用户 openid
登录流程的六个术语
code
它是在客户端（即小程序）内通过 wx.login API 获取的，而后通过 HTTP 申请发送给开发者服务器。code 的作用体现在“长期”两字上，它的有效期限仅有 5 分钟，并且仅可能应用一次（即申请一次 auth.code2Session 接口）。appid
每个微信小程序在创立之后（即在微信公众平台注册并初始化实现）便同时生成了一 appid，这个 ID 标记了小程序的唯一性，等同于网站的 URL（通过备案的）、App 的包名等标记利用唯一性的信息
appsecret
它是小程序的密钥，能够在微信公众平台的后盾管理系统中获取。appsecret 是十分私密的信息，所以微信在制订小程序登录的流程时，将携带此信息的网络申请限度在只能通过开发者服务器发送给微信接口服务，这样对于客户端来说是不可见的，进而升高了被泄露的可能性。与 appid 不同的是，appsecret 能够被重置，但每次重置之后，历史的 appsecret 便会生效，所以请审慎操作。openid
这里你要留神，很多开发者容易走入一个误区：误将 openid 了解为用户的惟一 ID。这句话如果放在某个小程序的特定语境下是没有问题的，然而如果放在微信生态的全局角度上是谬误的。为什么呢？微信对于用户 openid 的定义是：微信号在某个应用程序中的惟一 ID。这里的“某个应用程序”指的是小程序、公众号、接入开放平台的利用。微信生态中目前有公众平台和开放平台两种，其中公众平台又细分为小程序和公众号，开放平台能够接入网站、挪动利用等。同一个微信号在不同的应用程序中有不同的 openid。在微信生态下另外有一个标记微信号的惟一 ID：UnionId。这个 ID 跟应用程序无关。所以，能够简略地了解为 UnionId 与 appid 综合加密后的后果，见下图：
编辑
UnionId 通常用来关联在不同应用程序中各个 openid，比方同一个微信号在小程序和公众号内须要配置同样的权限，仅通过 openid 无奈实现，便须要获取此微信号的 UnionId。尽管获取 UnionId 的流程并不在这节课的探讨范畴之内，但我置信你在后续工作中肯定会遇到解决 UnionId 和 openid 的场景，所以先理解一下没啥害处
session_key
session_key 是对用户数据进行加密签名的密钥，微信服务器应用它将用户的数据进行加密和解密。你能够简略地将 session_key 了解为获取用户数据的“绿卡”，登录之后所有波及拜访微信服务器的申请个别都须要带上它，微信服务器会校验 session_key 的合法性。其实到这一步（即拿到了 openid 和 session_key）曾经实现了小程序的登录流程，但对于一个应用程序来说，用户进行登录操作应该是“一劳永逸”的，即登录过一次之后在肯定工夫之内的后续操作都不须要再次登录，用技术语言形容就是应该保留用户的登录态。这个时候就须要用到接下来的一个术语：token。token
{ “token_1”: {
“openid”: “ 获取到的 openid 1”,
“session_key”: “ 获取到的 session_key 1”
}，
“token_2”: {
“openid”: “ 获取到的 openid 2”,
“session_key”: “ 获取到的 session_key 2”
}，
}
关联实现之后开发者服务器将 token 下发到客户端，客户端保留在本地，后续的所有申请均须要携带此 token，携带的办法并没有既定的标准，能够通过 URL Query、HTTP Body、Header 等，但通常倡议通过 Header 传递，这样相对来说更平安一些。登录态是个逻辑词汇，token 能够了解为登录态的具象化、数据化。在小程序的登录流程图中，你能够看出，token 是由开发者服务器创立的一个字符串，而且须要跟 openid 和 session_key 相关联。其实这里并不是强制关联 openid，因为 openid 并不算是私密信息，能够释怀公开发到客户端（即小程序）。然而 session_key 是十分私密的信息，一旦泄露有很大的安全隐患，所以强烈建议不要把它下发到客户端。在获取到 openid 和 session_key 之后，开发者服务器创立一个 token，而后与 openid 和 session_key 进行关联，具体的办法依据服务器编程语言的不同有多种实现计划。咱们以 JavaScript 语言作为示例，能够创立一个对象，对象的 key 是 token 的值，value 是一个蕴含 openid 和 session_key 的对象，如下：OAuth 2.0 标准中的角色划分
咱们先思考一个问题：小程序登录之后如果须要拜访用户的数据（比方昵称、地区、性别等）须要失去谁的受权？是微信？还是用户？
答案是用户。用户的数据尽管寄存在微信的服务器之上，然而这些数据的所有权属于用户本人，而不是微信。这里其实引出了 OAuth 2.0 标准中的两个基本概念。
Resource Owner：资源所有者，即用户；Resource Server：资源服务器，即微信。而小程序在获取用户数据中的角色是作为微信平台的第三方应用程序，在 OAuth 2.0 标准中的术语为 Third-party application。
三、自定义组件
自定义组件的资源管理
创立微信小程序自定义组件须要应用 Component 结构器，这是微信小程序结构体系内最小粒度的结构器，外层是 Page 结构器，最外层的是 App 结构器，三者的关系如下图：
Component({
behaviors:[],
properties:{},
data: {},
lifetimes: {},
pageLifetimes: {},
methods: {}
});
咱们能够对照 Vue 和 React 解说 Component 结构器的几个属性，这样更容易了解：
behaviors 相似于 Vue 和 React 中的 mixins，用于定义多个组件之间的共享逻辑，能够蕴含一组 properties、data、lifetimes 和 methods 的定义；properties 相似于 Vue 和 React 中的 props，用于接管外层（父组件）传入的数据；data 相似于 Vue 中的 data 以及 React 中的 state，用于形容组件的私用数据（状态）；lifetimes 用于定义组件本身的生命周期函数，这种写法是从小程序根底库 2.2.3 版本引入的，本来的写法与 Vue 和 React 相似，都是间接挂载到组件的一级属性上
pageLifetimes 是微信小程序自定义组件独创的一套逻辑，用于监听此组件所在页面的生命周期。个别用于在页面特定生命周期时扭转组件的状态，比方在页面展现时（show）把组件的状态设置为 A，在页面暗藏时（hide）设置为 B；methods 与 Vue 的 methods 相似，用于定义组件外部的函数
自定义组件的生命周期
组件间的通信流程
与 Vue/React 不同，小程序没有相似 Vuex 或 Redux 数据流治理模块，所以小程序的自定义组件之间的通信流程采纳的是比拟原始的事件驱动模式，即子组件通过抛出事件将数据传递给父组件，父组件通过 properties 将数据传递给子组件
假如小程序的某个页面中存在两个组件，两个组件均依赖父组件（Page）的局部属性，这部分属性通过 properties 传递给子组件
当组件 A 须要与组件 B 进行通信时，会抛出一个事件告诉父组件 Page，父组件接管到事件之后提取事件携带的信息，而后通过 properties 传递给组件 B。这样便实现了子组件之间的消息传递。
除了事件驱动的通信形式以外，小程序还提供了一种更加简略粗犷的办法：父组件通过 selectComponent 办法间接获取某个子组件的实例对象，而后就能够拜访这个子组件的任何属性和办法了。随后将这个子组件的某个属性通过 properties 传递个另外一个子组件。相较而言，事件驱动的办法更加优雅，在流程上也更加可控，所以通常倡议应用事件驱动的通信形式。
四、性能优化
微信 IDE 的小程序评分性能位于调试器 -> Audits 面板中
点击“运行”之后，微信 IDE 会对以后的小程序我的项目进行评测（包含代码层面的检测、通过记录用户交互行为的体验检测）。最终从性能、体验和最佳实际三个维度别离打分以及综合分：
性能评分是通过对页面渲染、网络、JS 脚本等方面的评估综合得来的；体验评分是从设计和交互等方面的评估而来，因为设计和交互存在肯定的主观因素，所以体验的评分权当倡议；最佳实际波及的方面更宽泛，除了代码编写方面的倡议
小程序性能优化的具体维度
微信 IDE 对小程序性能进行评分有以下几个维度
防止过大的 WXML 节点数目
防止执行脚本的耗时过长的状况
防止首屏工夫太长的状况
防止渲染界面的耗时过长的状况
对网络申请做必要的缓存以防止多余的申请
所有申请的耗时不应太久
防止 setData 的调用过于频繁
防止 setData 的数据过大
防止短时间内发动太多的图片申请
防止短时间内发动太多的申请
- 防止过大的 WXML 节点数目
WXML 是基于 HTML 的一种 DSL（Domain Specific Language，畛域专属语言），除了原生组件（比方 Camera 相机组件）以外，惯例组件最终会被小程序的渲染线程通过 WebView 渲染为 HTML，所以从性能优化的角度上，HTML 的大部分性能优化计划均实用于 WXML，尽量减少节点数目就是计划之一
节点数目会影响渲染性能，要了解这句话，你要对浏览器的渲染流程有大略理解，来看上面这张图：
HTML 是 XML 的变体，在渲染的时候首先会被浏览器内核解析为 DOM 树，这是一种树形构造，而后会解析每个节点标签的类型、属性等因素，最初与 JavaScript 脚本和 CSS 联合起来进而在通过布局和绘制实现整个渲染流程
实践上 HTML 的节点数目和深度是没有限度的，然而从浏览器的渲染流程中不难看出，DOM 树的构造越简单，渲染的管线就会越慢
升高节点数目对于性能优化的另外一个起因，是与小程序 /Vue/React 这种 MVVM 框架的 DOM 更新机制无关。这类框架在更新 UI 时不间接操作 DOM，而是应用 VDOM（Virtual DOM，虚构 DOM）技术来实现，VDOM 的高性能来源于高效的 Diff 算法，在内存中对 VDOM 树结构进行比照后提取差别点再映射到实在 DOM 中。- 防止执行脚本的耗时过长
执行脚本的耗时过长对于性能的不良影响次要体现在两个期间：
第一是在小程序加载实现后的首次渲染期间；第二是小程序运行过程中的解决用户交互期间。JavaScript 脚本对小程序首次渲染的影响与浏览器环境下 <script> 标签对 HTML 渲染的影响相似，尽管小程序中不容许应用 <script> 标签，双线程模型下 JavaScript 脚本也并不会齐全阻塞 UI 线程的行为，然而逻辑线程执行 JavaScript 代码时仍旧是单线程的，通过工作队列治理代码的有序执行。如果某一段 JavaScript 代码逻辑占时太长，造成工作队列过长，最终会影响小程序在响应用户交互行为上的长延时或卡顿
- 防止首屏工夫太长
影响首屏工夫的因素十分多（比方 DNS 解析耗时、TCP 链接的建设耗时……）对于小程序开发者来说，有些因素是不可控的（比方 DNS 解析），那么在可控的泛滥因素当中，最外围的两个优化方向是：
代码优化；网络优化。代码方向的优化措施重点关注这样几点：
升高 WXML 的构造复杂度，比方节点个数和深度；升高首次渲染的数据规模，首次渲染只蕴含外围数据，非核心数据的渲染可推延到首屏渲染实现之后进行；从设计和交互的角度登程，在理论内容被渲染之前展现敌对的 loading 成果。而网络方向的优化外围是为了升高 RTT（Road-Trip Time，往返时延），也就是微信 IDE 给出的“6. 所有申请的耗时不应太多”这条倡议。因为小程序的所有资源均托放在微信的服务器，所以不存在 CDN 和 DNS 优化问题，对于开发者来说，升高 RTT 最无效的两个措施是：
缩小网络申请所携带的数据体积，这是最直观的网络优化计划；进步服务器解决网络申请的速度，这一点是对服务端的要求，除了服务端代码自身的性能以外，当用户量回升到肯定规模之后，还须要服务器有解决高并发的能力。对于专一于端侧的传统前端和小程序开发者来说，这些常识是绝对生疏的，往往须要后端的同学配合实现。这也是云开发相较于传统开发模式的次要劣势之一，应用云开发能够让端侧的开发者也可能开发出弹性伸缩、高并发、高 QPS 解决的服务层
- 防止渲染界面的耗时过长的状况
这是一条综合性能指标，渲染次要包含两个角度：
一是首屏的渲染工夫；二是小程序运行期间的界面更新所需的渲染工夫，咱们无妨称之为动静渲染。动静渲染是由 JavaScript 脚本中调用 setData 更新数据所触发，所以优化动静渲染的切入点便高深莫测：优化 setData。至于具体的优化计划，便是微信 IDE 给出的两点倡议：
防止 setData 的调用过于频繁。频繁调用 setData 会造成逻辑线程与渲染线程之间过多的通信，01 讲咱们提到双线程之间的通行须要借助微信原生平台作转发，两头必然是有肯定的性能损耗和时延。除此之外，渲染线程在接管到逻辑线程传递的数据之后，须要进行解析、VDOM 比照、更新 UI 等一套管线流程，在前一条流程执行完结之前，前面的数据只能排队期待执行。所以频繁调用 setData 就会造成队列加长，用户交互行为触发的 UI 更新就会迟缓甚至可能因为计算量太大造成卡顿。防止 setData 的数据量太大。频繁调用 setData 会造成队列中的工作太多，而如果 setData 的数据量太大，则会造成单个工作的解决耗时加长。与上一条相比，一个是工作数量过多，一个是单个工作过重，两者最终对于性能产生的负面影响是统一的。此外，因为双线程之间须要借助微信原生平台转发，所以 setData 数据量过大也会造成通信时延的加长。- 对网络申请做必要的缓存以防止多余的申请
小程序的资源文件托管在微信的服务器，所以小程序开发者不须要关注前端开发畛域中对于动态资源的 HTTP 缓存策略，这件事件微信会帮忙开发者实现。
这一条倡议所指的是在代码层面，将局部重复使用的网络申请后果在代码或 storage 中进行正当缓存以实现复用，对于应用同一个网络申请后果的代码能够间接从缓存中读取，进而缩小了不必要的网络申请个数。每次网络申请不管工夫长短，均须要用户期待，缩小网络申请的个数相当于缩小了用户等待时间，晋升了用户体验
- 防止短时间内发动太多的图片申请
这一条与微信 IDE 给出的另一条倡议“10. 防止短时间内发动太多的申请”的方向是统一的，均是为了解决过多 HTTP 申请造成用户等待时间过长的问题。图片资源绝对非凡的一个特点是体积较大，前端畛域最早的懒加载计划便是次要针对图片资源，所以图片资源的申请对性能的影响更加直观一些。目前前端和小程序畛域中应用的仍旧是 HTTP 1.1 协定，一个 TCP 链接同时只能解决一个 HTTP 申请，在前一个申请失去服务器的响应之后才会发动第二个申请，如果同一时间的 HTTP 申请太多就会产生排队。浏览器为了应答这种问题，提供了建设多个 TCP 连贯以实现并行发送 HTTP 申请的目标，目前市面上的浏览器最多反对同时建设 4~8 个 TCP 连贯。也就是说，最多能够同时解决 4~8 个 HTTP 申请。如果同一时刻须要发送的 HTTP 申请数量远大于这个数字，那么还是会产生排队。后面的内容咱们反复地提到了“排队”一词，不论是线程间的通信排队、工作队列的排队、还是 HTTP 申请的排队，这些行为都是须要用户期待的，对于用户的切身体验来说，便是响应迟缓甚至卡顿
五、应用 Webpack 晋升小程序研发效率
治理第三方 npm 模块
微信小程序的晚期版本不反对应用第三方 npm 包，在根底库 2.2.1 版本才开始反对。然而微信小程序应用 npm 模块的形式与 Node.js 的并不完全相同，尽管同样能够用包管理工具（npm/yarn）装置 npm 模块，然而在小程序源码中引入（require）npm 模块的门路并不是 node_modules，而是 miniprogram_npm 目录。
开发者在应用 npm 模块之前必须应用微信 IDE 菜单栏中的“工具”-“构建 npm”，将原始的 npm 模块（即 node_modules 目录中的模块）进行一次预构建，预构建的产出目录便是 miniprogram_npm，最初才能够在小程序源码中引入（流程如下图所示）
而且，小程序预构建 npm 模块的过程并不是简略地将原始模块从拷贝 node_modules 目录到 miniprogram_npm 目录，而是会将原始模块的所有散列文件打包成一个单 js 文件，而后再将这个 js 文件作为模块入口裸露进来
整个预编译的流程如下：
读取小程序我的项目的 package.json 文件（位于 miniprogram/package.json）中有哪些依赖（dependencies）在 node_modules 目录内顺次寻找这些依赖的原始 npm 模块，读取模块的 package.json 文件，搜查 main 字段指定的入口 js 文件
剖析模块的入口 js 文件援用了哪些子文件
将所有文件打包为一个单 js 文件
你要留神，在执行第四步时，微信 IDE 并不会将原始 npm 模块所依赖的其余 npm 模块一并打包。比方，事实工作中的网络申请模块 axios，这个根底模块可能被某个 npm 模块（假如为模块 A）依赖，如下
import axios from ‘axios’;
那么微信 IDE 在编译 A 的时候并不会将 axios 的代码一起打包为单 js 文件，而是会保留代码中对于 axios 模块的援用。同时会依据依赖关系寻找 axios 模块的 package.json 文件，而后执行上述的 2~3 步骤，也就是把 axios 模块也编译为单 js 文件
最终的成果就是 miniprogram_npm 目录中存在模块 A 和模块 axios 两个子目录。这样就存在一个很重大的问题：通常咱们的代码中只应用了第三方 npm 模块的一个或几个 API 而不是全副，微信 IDE 形式却始终会把 npm 模块内的全副代码进行打包，最终造成的结果是代码体积增大
又因为小程序对于代码体积有严格的限度（目前是 2M），应用微信 IDE 打包后很可能会超过下限。尽管在前端开发畛域内，一些构建工具（比方 Webpack）会通过 Tree Shaking 机制在打包过程中将没有用到的代码片段舍弃，缩小打包后的文件体积，但微信 IDE 目前却并没有这种个性
那么对于习惯了规范 npm 应用形式的前端开发者来说，微信小程序这种 npm 模块的治理和打包计划是很难承受的，单纯从研发效率的角度登程，这个计划也简直没有可取之处。
所以，业内广泛的做法就是：放弃微信 IDE 的 npm 治理计划，应用前端构建工具打造一套构建体系
一个未经批改的微信小程序源码目录如下图所示：
其中 cloudfunctions 是云函数的根目录，miniprogram 中的文件是小程序本体的源码，包含小程序的业务代码和 npm 模块
应用 Webpack 打造的构建体系通常会另外建设一个与 cloudfunctions 和 miniprogram 平行的目录用于治理源码，而后将 miniprogram 目录作为构建产出目录，如下：
同时禁用微信 IDE 编译相干的性能，把这些工作全副交给 Webpack：
这样一来，在自建的构建体系下，咱们不仅能够应用规范的 npm 模块治理形式，同时能够施展 Webpack 对于研发效率的加持，比方 Tree-Shaking 减小打包文件体积、联合 Babel 应用最新的 ECMAScript 个性、联合 Lint 工具对立代码标准等。这是接下来咱们要探讨应用 Webpack 实现的几项具体工作的根底
六、数据监控
数据建模：性能、用户和异样
- 性能数据
优化性能的指标次要有两个：
缩小用户关上小程序（或某个页面）后的等待时间，这部分的性能称为启动性能；进步用户操作小程序的晦涩度，这部分的性能称为运行时性能。- 用户数据
用户的数据能够分为两种类型：一是静态数据，包含用户的年龄、性别、地区等信息，这些数据叫“用户画像”；二是动态数据，或者称为用户行为数据，这是一个比拟宽泛的概念，能够细分为很多子项，比方：
用户在应用小程序期间的一些交互操作数据，比方点击某个按钮，从页面 A 切换到页面 B；用户的行为形迹，比方先点击页面 A 的某个按钮而后点击另一个按钮最初切换到页面 B；用户在某个页面的停留时长；用户的留存率；- 异样数据
异样数据有三种类型：
端侧的代码异样，比方小程序 JavaScript 脚本的某段逻辑执行报错；服务异样，不过这类异常情况不仅仅是小程序服务端的问题，也可能是用户设施所在网络环境造成的 HTTP 申请失败；行为异样，最常见的一种就是爬虫脚本频繁地申请某个服务接口。性能数据、用户数据和异样数据三者绝对独立，而咱们统计数据的目标并不是收集这些独立的数据，而是心愿将它们综合在一起进行剖析，这样能力从多维度、多方面获取数据暗藏的信息。也就是将所有数据通过肯定的分割归属到在更上一层的畛域内剖析
在小程序场景下，把这三种类型数据分割到一起的下层畛域就是小程序的每个页面 -Page。页面再上一层的畛域就是小程序的运行环境（包含用户设施信息和小程序的版本信息）。由此咱们能够总结出小程序的数据统计所应用的的数据模型，如下图所示
确定了数据模型，接下来就是制订针对每种数据的采集计划。
采集计划：自动化工具和 API 劫持
- 性能数据采集
性能数据的采集通常会放在小程序公布前的研发或测试阶段，将其作为自动化测试的一部分。当然这并不是说采集小程序线上的性能数据没价值，而是必要性有余，因为影响线上性能数据的外界因素太多了，用户的网络状况、设施状态等都有可能造成某一时刻（甚至某一时间段之内）的性能数据稳定，这种状况下统计的数据大多是没有理论价值的。而在研发或测试阶段往往是在固定的外界环境中进行性能数据的采集，屡次抽样取期望值，而后与历史数据进行比照和评估
具体到性能数据的采集办法上，支流的有两种：
截图 + 图片比对。在对小程序进行仿真操作的过程中依照肯定的频率进行截图，而后应用工具进行图片比对，从而获取到一些性能数据，比方小程序启动耗时、首屏渲染耗时等等。通过这种办法获取到的性能数据有一个特点，数据的精密度与截图的频率和图片比对工具的准确性成正比，施行的老本绝对比拟高。应用官网提供的性能 Trace 工具导出数据。间接获取到各项性能指标的数值，包含启动耗时、下载耗时、渲染耗时……比第一种办法施行的成本低很多，而且数据精准度更高。但目前只能在 Android 手机上拿到 Trace 工具的数据，iPhone 临时不反对。- 异样数据和用户数据采集
行为异样比方爬虫，在端侧是无奈知悉的，防爬防刷是服务器平安保障的一部分，所以行为异样的监控个别都是由服务端承当，你能够把这项工作交给服务端的共事。服务异样的数据起源有两种，一种是用户网络起因导致的申请失败或超时，一种是服务器自身出了问题。第二种与行为异样同样是属于服务端的职责，而在小程序端侧只可能染指第一种异样数据的采集，在采集计划上与代码异样是统一的。异样数据的采集也能够称为异样监控，采集到异样自身并不是次要指标，更重要的是可能采集到引起异样的用户行为门路。比方对于电商小程序典型的购买商品的链路：用户点击了商品详情页的“购买”按钮，首先跳转到“购物车”页面，而后持续点击“下单”跳转到订单页面，最初点击“领取”调起微信领取。这个过程用户一共须要四个步骤：
如果在这条链路中的“购物车”页面呈现了异样，咱们要采集的并不仅仅是以后页面脚本抛出的异样自身，而是要同时获取到引起异样的前序门路，即“商品页”信息。
用户行为数据的采集同样如此。咱们要获取的并不仅仅是用户点击了哪个按钮，还须要采集到这个按钮所在的页面，如果此页面是由其余页面跳转而来还须要采集前序页面的门路信息
还是以方才的商品购买链路为例，点击商品页的“购买”按钮会触发跳转购物车，如下：
Page({
gotoCart(){
wx.navigateTo({
url: ‘pages/cart?id=xxx’
});
}
});
而后在购物车页面中获取 URL 中携带的商品 ID：
Page({
onLoad(query){
const {id} = query;
}
});
如果应用最原始的代码埋点，须要在两个页面的函数中手动填写埋点代码，如下：
// 商品页
Page({
gotoCart(){
reportClientLog({
// … 上报商品页数据
});
wx.navigateTo({
url: ‘pages/cart?id=xxx’
});
}
});
// 购物车页面
Page({
onLoad(query){
reportClientLog({
// … 上报购物车页面数据
});
const {id} = query;
}
});
这种形式既费时、费劲又难以保护，因为如果在后续迭代中不须要统计某个函数的行为，就要找到这个函数的埋点代码手动删除。所以咱们要来解决这样的问题，这里须要用到 ES 6 的一些新个性：Proxy 和 Reflect。目前小程序运行时还不反对这些个性，你能够借助 Babel 将其转化为 ES 5 语法
用 Proxy 和 Reflect 实现埋点的思路非常简单：代理（也能够称为劫持）小程序的 API，在调用 API 的同时采集数据。以上述案例中用到的小程序 Page 对象为例，应用 Proxy 和 Reflect 实现 API 代理
Page = new Proxy(Page, {
get(target,key,context){
const originHandler = Reflect.get(target,key,context);
// 只代理函数
if(typeof originHandler === ‘function’){
return function(…args){
reportClientLog({
// … 上报数据
});
originHandler.call(context,…args);
}.bind(context);
}
return originHanlder;
}
});
将以上代码封装为一个独立的 JavaScript 文件，假如名称为 report.js，而后在小程序中引入：
require(‘./report.js’);
Page({
// …
})
通过以上革新，每当调用 Page 的 API 时都会上报数据。然而当调用 Page 的任何一个 API 都会上报数据，而大多数状况下只须要统计无限的几个 API，所以要为 report.js 引入一种白名单机制：只有在名单之内的 API 上报数据。革新的形式也很简略
export default function report(obj,apilist){
return new Proxy(obj, {
get(target,key,context){
const originHandler = Reflect.get(target,key,context);
// 只代理列表内的函数
if(typeof originHandler === ‘function’ && apiList.includes(key)){
return function(…args){
reportClientLog({
// … 上报数据
});
originHandler.call(context,…args);
}.bind(context);
}
return originHanlder;
}
});
}
你应该也留神到了，下面这段代码不仅退出了白名单机制，而且还把被代理的对象改成了动静的参数，这样便能够实用于任何对象，比方小程序的 App 和 Page 对象：
const report = require(‘./report.js’);
// app.js
App = report(App, [
‘onShow’,
‘onLoad’,
‘onLaunch’
]);
App({
// …
});
// page.js
Page = report(Page, [
‘onShow’,
‘onHide’,
‘onLoad’,
‘gotoCart’
]);
Page({
// …
});
到目前为止，咱们实现了数据采集的实施方案，当然咱们必定会依据事实业务的需要做出调整和革新，比方制订上报数据的格局标准、上报机会、解决离线数据等细节（这些内容与业务有强关联性）
- 采集到所需数据之后，而后就是依据这些数据做剖析、决策了
性能数据可能帮忙技术研发人员发现影响应用程序性能的不良因素，而后进行专项优化。异样数据次要的作用是监控线上环境存在的问题，而后依据问题影响面的大小制订告警策略，比方当监控到影响性能逻辑的重大脚本谬误，后盾监控服务会通过邮件、短信、电话的形式告诉责任人督促尽快解决
整体的数据监控体系能够简化为上面这张图：
总结
数据不仅仅对产品和经营有价值，对于研发同样意义不凡，你须要明确这一点，在当前的工作中将数据器重起来；性能的评估通常作为自动化测试的一部分，而异样监控则是针对生产环境的。作为一名研发，你须要时刻关注这两种数据，并且有针对性地进行改善；采集小程序的异样数据和用户数据能够通过劫持小程序 SDK 的 API，这样可能加重代码埋点的工作量，并且升高后续保护的老本。七、小程序的更新策略
小程序的资源能够抽象地分为前端和后端资源：前端资源也能够被称为端侧资源（包含脚本、款式文件等），后端资源指的是小程序的一些服务接口。
端侧更新策略
网站的前端资源能够分为动静资源和动态资源，动态的资源包含 js、css、图片等文件，为了进步性能通常会将这些文件尽量缓存到本地。动静的资源只有 HTML 文件
网站的 HTML 文件最后是由服务端通过模板引擎渲染进去的，比方 freemarker、smarty 等，当初依然有很多网站应用这种形式，不过更风行的是用 React/Vue SSR 以及 SPA 的动态 HTML。尽管在 SPA 架构中，HTML 文件与 js 文件、css 文件一样作为动态资源部署，但跟 js 和 css 不同的是，咱们并不会让浏览器缓存 HTML 文件，而是通过服务器配置将 HTML 文件的 HTTP 申请的 Cache-Control Header 设置为 no-cache。这是为了保障用户每次关上网站都会失去最新版的 HTML 文件，而其余动态资源都要通过 HTML 文件才会被引入，这保障了 HTML 文件的实时性，也保障了网站所有动态资源的实时性
跟网站不同的是，小程序的“所有”端侧资源都是动态的
小程序的资源是托管在微信服务器上的，跟网站不同，微信不会在用户每次关上小程序时，从服务器拉取最新的小程序资源，而是尽可能地施展缓存的劣势
当用户关上小程序时，微信客户端会先从缓存中拉取小程序的端侧资源，有的话就展现给用户，没有的话会从微信服务器拉取，这时，拉取的必定是最新版本，而后放入缓存并展现给用户。
以上就是小程序的端侧资源的管理机制。从这套流程里你会发现一个问题：既然优先应用缓存中的资源，那么当我公布了小程序新版本之后，怎么保障用户尽可能快地更新为新版本呢？这就是咱们要探讨的重点：小程序的端侧资源更新机制。
本地没有缓存会触发是最简略的一种机会，除此之外还有两种机会。
未启动时：指的是小程序处于非沉闷状态时（比方处于后盾），然而请留神，这种状态是用户曾经用过小程序后才会产生的，如果用户素来都没有用过你的小程序，就不存在状态的概念了，因为对于这个用户来说，你的小程序是无状态的。冷启动时：小程序被销毁从新关上后会进入冷启动状态
当你在小程序管理后盾公布新版本的小程序之后，微信会依据用户设施上小程序的状态施行不同的更新策略
如果小程序处于未启动状态，微信客户端会在“若干个机会”去查看缓存中的小程序有没有新版本，如果有会默默把新版本资源拉取到本地缓存中
如果小程序处于冷启动状态，微信客户端会被动查看是否有新版本，同时会向用户展现缓存中的旧版本。有新版本的话会默默地拉取到本地，而后在用户再次触发小程序冷启动时展现给用户。也就是说，须要两次冷启动能力将最新版本的小程序展现给用户。整个流程如下图所示：
从上述内容中，你能够得出一个论断：当你公布一个新版本后，用户并不能“立刻”取得更新。
小程序未启动时最慢 24 小时能够笼罩全副用户，或者须要经验两次冷启动，这对一些紧急的版本更新来说太慢了，所以在事实工作中往往要将小程序的更新提速，让用户尽可能快地获取到新版本。具体实施办法是通过小程序的 UpdateManager 对象，在代码里被动查看并利用更新信息。咱们对照流程图和代码解说，来看上面这张图：
const axios = require(‘axios’)
const updateManager = wx.getUpdateManager()
updateManager.onCheckForUpdate(function (res) {
// 将是否有新版本信息挂载到全局对象上
this.globalData.hasUpdate = res.hasUpdate
})
updateManager.onUpdateReady(function () {
if(!this.globalData.hasUpdate){
return
}
const {miniProgram} = wx.getAccountInfoSync()
// 获取以后小程序的版本号
const currVersion = miniProgram.version
// 从你的开发者服务器接口中获取是否有紧急版本须要更新
axios.get(${<your-url?}?currVersion=${currVersion}).then(res=>{
if(res.needUpdate){
// 紧急版本立刻重启小程序利用更新
updateManager.applyUpdate()
}
})
})
首先在代码中创立一个 UpdateManager 对象，而后增加 onCheckForUpdate 和 onUpdateReady 监听，当微信客户端从微信服务器中获取到小程序的更新信息后会触发 onCheckForUpdate 函数，入参携带 hasUpdate 属性标记是否有新版本未更新。咱们将这个信息挂载到全局对象上以便后续应用。当微信客户端从微信服务器中将最新版本的小程序端侧资源拉取到本地之后，会触发 onUpdateReady 函数，此时须要你的开发者服务器提供一个接口，对应上述代码中的 your-url。这个接口的入参是用户以后应用的小程序版本，而后依据这个版本号判断以后用户的小程序版本是否存在重大 Bug 须要更新到最新版本。你须要在小程序的脚本代码中，当 onUpdateReady 函数被触发时调用这个接口，如果须要更新则通过调用 updateManager.applyUpdate() 强制重启小程序利用更新。上述这套更新机制相比拟须要两次冷启动的默认更新机制来说，可能缩小一次冷启动的工夫，能更疾速地令用户获取最新版本的小程序，对于一些修复紧急 Bug 的版本是一种卓有成效的计划。当然，咱们只展现了端侧的调用流程，在后端公布小程序时，你须要记录每次公布版本的详细信息，包含是否有紧急 Bug 修复，这样才可能为端侧的调用提供数据起源。
后端服务灰度公布策略
后端服务的公布流程中有一个十分重要且通用的策略：灰度公布。所谓的灰度公布简略了解就是将新版本的服务只向肯定比例的用户凋谢，而另一部分用户依然应用旧版本的服务，而后察看新版本的状态，如果一切正常则缓缓扩充新版本的用户比例，直到全副用户都切入新版本，便实现了灰度公布的全流程。
灰度公布须要提前制订用户申请的转发策略，个别有两种：
依照新旧服务所占用的服务器比例随机转发；依照用户的 ID 转发。第一种简略粗犷，比方你有 10 台服务器，其中 2 台部署了新版本的服务，负载均衡器会在接管到用户申请时依照 20% 的概率随机转发到新版本服务器上，残余的转发到旧版本服务器。第二种须要进行肯定的编码工作，比方 Nginx 配置 Lua 脚本，当接管到用户申请时，从申请中获取到用户的 ID，在小程序场景下就是用户的 OpenId，而后匹配转发策略中是否这个 ID 在新版本服务的白名单中，如果是的话便转发到新版本服务，否则转发到旧版本服务。如下图所示：八、云开发
云开发其实是一种后端服务，和服务器所表演的角色相似，都是服务端角色。不过云开发把服务所须要的一些资源（比方计算、存储、音讯推送等）封装打包，以不便开发者应用。整体上讲，云开发包含了云函数、云数据库、云存储、云托管等一些根底服务资源，以及云上的各种扩大能力（比方图像处理、客服服务等）。在调用形式上，云开发的应用办法和前端开发差不多，它将触手可及的各种资源以接口 SDK 的模式给到开发者。举个例子，如果开发微信小程序，须要存储用户的集体数据以不便利用业务，你能够用云开发的接口把数据存入数据库，这个接口并不是 URL 地址，而是一个函数办法（function），举例如下：
编辑
如果你想对这些数据进行一些简单的解决（比方对数据做剖析，生成报表）波及其余的数据，能够把解决的逻辑放到云开发云函数中进行，而云函数也能够在小程序中用函数办法（function）的模式调用，举例如下：
编辑
再深一步，如果你的微信小程序想存储一些文件，也能够间接应用云开发接口，调用上传文件，文件能够同时被小程序端和云函数端获取到，不便利用性能的开发，举例如下：
以上在开发小程序时所用到的数据库、云函数、云存储都是云开发提供的资源：
云函数是独立的计算资源，通过触发执行逻辑运算或者资源解决，最终返回后果；数据库是遵循 Mongo 协定的非关系型数据库，能够间接通过各种 API 进行调用解决；云存储是云开发提供的专门的存储空间，有根底 API 进行文件治理。而这些根底服务资源（数据库、云函数、云存储）都被整合到一套接口调用规范中，依据这套规范以及实用端场景，会产生各种 SDK，别离专一于客户端、云函数端、治理端等进行资源兼顾和解决。