导语：
微信小程序，小程序的一种，英文名wechat mini program，是一种不需要下载安装即可使用的应用，它实现了应用“触手可及”的梦想，用户扫一扫或搜一下即可打开应用。
全面开放申请后，主体类型为企业、政府、媒体、其他组织或个人的开发者，均可申请注册小程序。微信小程序、微信订阅号、微信服务号、微信企业号是并行的体系。
我们这边最近一直在做基础服务，这一切都是为了完善技术体系，这里对于前端来说便是我们需要做一个hybrid体系，如果做app，react native也是不错的选择，但是一定要有完善的分层：
① 底层框架解决开发效率，将复杂的部分做成一个黑匣子，给页面开发展示的只是固定的三板斧，固定的模式下开发即可
② 工程部门为业务开发者封装最小化开发环境，最优为浏览器，确实不行便为其提供一个类似浏览器的调试环境
如此一来，业务便能快速迭代，因为业务开发者写的代码大同小异，所以底层框架配合工程团队（一般是同一个团队），便可以在底层做掉很多效率性能问题。
稍微大点的公司，稍微宽裕的团队，还会同步做很多后续的性能监控、错误日志工作，如此形成一套文档->开发->调试->构建->发布->监控、分析 为一套完善的技术体系
如果形成了这么一套体系，那么后续就算是内部框架更改、技术革新，也是在这个体系上改造，但很可惜，很多团队只会在这个路径上做一部分，后面由于种种原因不在深入，有可能是感觉没价值，而最恐怖的行为是，自己的体系没形成就贸然的换基础框架，戒之慎之啊！
从第三方应用接入来说，微信应该是做的最好的，百度这边有直达号等类似的产品，但是其体系化感觉还是有待提高的，阿里应该也有类似的技术产品诞生，从我们这层来说，都没有太多知晓，所以要么是运营的不好要么是做的不好。
而从小程序诞生以来，我这边便一直在关注，至今整个小程序体系已经十分完备了，腾讯小程序和腾讯云深度整合了，如果使用内测的开发者工具，全免费，纯js就搞定小程序前后端，不用服务器、存储、cdn、服务代码，都是免费，开发完后端不用自己运维，大杀器的节奏，我有时候在想，腾讯的技术实力真的是强啊！
小程序的结构追溯
小程序的开发文档还是比较完善的，依旧是 账号申请->demo 流程，等熟悉后便可以走代码上架等流程了，前端代码用工具构建后上传，后台服务自己维护，配置地址映射，我们这里仅关注开发流程，所有使用其测试账号即可。
1 appid wx0c387cc8c19bdf782 appsecret acd6c02e2fdca183416df1269d2e3fb9
经过一年多的发展，小程序形成的文档已经比较完善了，我们可以从文档和demo对小程序做出大概的判断：
这里就是小程序给业务人员可以看到的代码了，我们从这个代码以及运行，基本可以将小程序的梗概猜测一番，这里首先看看其全局控制器app：
//app.jsapp({ onlaunch: function () { // 展示本地存储能力 var logs = wx.getstoragesync('logs') || [] logs.unshift(date.now()) wx.setstoragesync('logs', logs) // 登录 wx.login({ success: res => { // 发送 res.code 到后台换取 openid, sessionkey, unionid } }) // 获取用户信息 wx.getsetting({ success: res => { if (res.authsetting['scope.userinfo']) { // 已经授权，可以直接调用 getuserinfo 获取头像昵称，不会弹框 wx.getuserinfo({ success: res => { // 可以将 res 发送给后台解码出 unionid this.globaldata.userinfo = res.userinfo // 由于 getuserinfo 是网络请求，可能会在 page.onload 之后才返回 // 所以此处加入 callback 以防止这种情况 if (this.userinforeadycallback) { this.userinforeadycallback(res) } } }) } } }) }, globaldata: { userinfo: null }})
一个应用只会有一个app实例，而小程序为这个单例提供了几个基本的事件定义，我们用的最多的应该是onlaunch、onshow、onhide（我还没写小程序，所以猜测）：
我们这里来追溯一下小程序架构层的执行逻辑，从app到一个view实例化是怎么做的，这里首先明确几个点：
① 微信小程序事实上依旧是提供的webview执行环境，所以我们依旧可以在js环境中访问window、location等属性
② 微信小程序提供的展示的全部是native定制化的ui，所以不要去想dom操作的事
这里各位可以想象为，小程序界面中有一块webview在执行真正的代码逻辑，只不过这个webview除了装载js程序什么都没做，而所有的页面渲染全部是js通过url schema或者jscore进行的native通信，叫native根据设置的规则完成的页面渲染。
全局控制器app
这里我们重点关注全局控制器app这个类做了什么，因为拿不到源码，我们这里也只能猜测加单步调试了，首先微信容器会准备一个webview容器为我们的js代码提供宿主环境，容器与构建工具会配合产出以下页面：
他在这里应该执行了实例化app的方法：
这一坨代码，在这个环境下便相当晦涩了：
y = function() { function e(t) { var n = this; o(this, e), s.foreach(function(e) { var o = function() { var n = (t[e] || i.noop).bind(this); reporter.__route__ = "app", reporter.__method__ = e, (0, i.info)("app: " + e + " have been invoked"); try { n.apply(this, arguments) } catch (t) { reporter.thirderrorreport({ error: t, extend: "at app lifecyclemethod " + e + " function" }) } }; n[e] = o.bind(n) }); for (var r in t) !function(e) { g(e) ? (0, i.warn)("关键字保护", "app's " + e + " is write-protected") : v(e) || ("[object function]" === object.prototype.tostring.call(t[e]) ? n[e] = function() { var n; reporter.__route__ = "app", reporter.__method__ = e; try { n = t[e].apply(this, arguments) } catch (t) { reporter.thirderrorreport({ error: t, extend: "at app " + e + " function" }) } return n } .bind(n) : n[e] = t[e]) }(r); this.onerror && reporter.registererrorlistener(this.onerror); var l = function() { "hang" === (arguments.length > 0 && void 0 !== arguments[0] ? arguments[0] : {}).mode && (f = !0); var e = (0, a.getcurrentpages)(); e.length && (e[e.length - 1].onhide(), (0, u.triggeranalytics)("leavepage", e[e.length - 1], !0)), this.onhide(), (0, u.triggeranalytics)("background") } , h = function() { var e = arguments.length > 0 && void 0 !== arguments[0] ? arguments[0] : {}; if (0 === e.scene || "0" === e.scene ? e.scene = c : c = e.scene, e.query = e.query || {}, (0, i.hasexitcondition)(e) && (p = !0), this.onshow(e), (0, u.triggeranalytics)("foreground"), d || e.relaunch) d = !1; else { var t = (0, a.getcurrentpages)(); t.length && (t[t.length - 1].onshow(), (0, u.triggeranalytics)("enterpage", t[t.length - 1], !0)) } }; if ("undefined" != typeof __wxconfig && __wxconfig) { var y = __wxconfig.applaunchinfo || {}; y.query = y.query || {}, c = y.scene, (0, i.hasexitcondition)(y) && (p = !0), this.onlaunch(y), (0, u.triggeranalytics)("launch"), h.call(this, y) } else (0, i.error)("app launch error", "can not find __wxconfig"); wx.onappenterbackground(l.bind(this)), wx.onappenterforeground(h.bind(this)), _.call(this, "function" == typeof t.onpagenotfound) } return r(e, [{ key: "getcurrentpage", value: function() { (0, i.warn)("将被废弃", "app.getcurrentpage is deprecated, please use getcurrentpages."); var e = (0, a.getcurrentpage)(); if (e) return e.page } }]), e }();
这里会往app中注册一个事件，我们这里注册的是onlaunch事件，这里对应的是当小程序初始化时候会执行这个回调，所以原则上应该是native装在成功后会执行这个函数，这里再详细点说明下h5与native的交互流程（这里是我之前做hybrid框架时候跟native同事的交互约定，小程序应该大同小异）：
我们一般是在全局上会有一个对象，保存所有需要native执行函数的对象，比如这里的onlaunch，native在执行到一个状态时候会调用js全局环境该对象上的一个函数
因为我们js注册native执行是以字符串key作为标志，所以native执行的时候可能是window.app['onlauch...']('参数')
而我们在window对象上会使用bind的方式将对应的作用域环境保留下来，这个时候执行的逻辑便是正确的
这里在小程序全局没有找到对应的标识，这里猜测是直接在app对象上，native会直接执行app对象上面的方法，但是我这里有个疑问是view级别如果想注册个全局事件该怎么做，这个留到后面来看看吧，这里是native载入webview时，会执行对象定义的onlaunch事件，在下面的代码看得到：
这里会结合app.json获取首先加载页面的信息，默认取pages数组第一个，但是具体哪里获取和设置的代码没有找到，也跟主流程无关，我们这里忽略......然后我们看到代码执行了onshow逻辑：
然后流转到注册微信容器层面的事件，我觉得，无论如何，这里应该是像微信容器注册事件了吧，但是我找不到全局的key
page流程
如果有微信小程序的同学，麻烦这里指点一下，是不是猜测正确，顺便可以帮忙说明下这里，这里也是我觉得全局key，被native调用的点，然后，逻辑上会获取默认view的类开始做实例化，我们这里来到view级别代码：
//index.js//获取应用实例const app = getapp()page({ data: { motto: 'hello wor11ld', userinfo: {}, hasuserinfo: false, caniuse: wx.caniuse('button.open-type.getuserinfo') }, //事件处理函数 bindviewtap: function() { wx.navigateto({ url: '../logs/logs' }) }, onload: function () { if (app.globaldata.userinfo) { this.setdata({ userinfo: app.globaldata.userinfo, hasuserinfo: true }) } else if (this.data.caniuse){ // 由于 getuserinfo 是网络请求，可能会在 page.onload 之后才返回 // 所以此处加入 callback 以防止这种情况 app.userinforeadycallback = res => { this.setdata({ userinfo: res.userinfo, hasuserinfo: true }) } } else { // 在没有 open-type=getuserinfo 版本的兼容处理 wx.getuserinfo({ success: res => { app.globaldata.userinfo = res.userinfo this.setdata({ userinfo: res.userinfo, hasuserinfo: true }) } }) } }, getuserinfo: function(e) { console.log(e) app.globaldata.userinfo = e.detail.userinfo this.setdata({ userinfo: e.detail.userinfo, hasuserinfo: true }) }})
他首先一来便获取了当前app实例：
const app = getapp()
其次开始了view实例化流程，这个是page的类入口，大家要注意view.js只是定义的类，但是其实例化应该在全局的控制器，其实例化在这里完成的：
总结
我们这里一起瞎子摸象一般对微信小程序架构做了简单的摸索，这里发现事实上小程序流程与自己所想有一些出入，这里初步认为流程是这样的：
① 我们写好小程序代码后，提交代码
② 在发布流程中我们的代码经过构建流程，app.json以及入口的index.html（伪造页面），重新组装为一个只有js代码的空页面
③ 这里开始载入流程，用户点击一个微信按钮，进入小程序
④ 微信容器开启hybrid容器，webview载入入口页面（我感觉应该有个规则可以通过url去打开固定一个小程序页面，这里后续碰到开发案例再说）
⑤ webview执行环境实例化app，其后自动装载默认page（这里默认是index）
ps：这里我有个很疑惑的点，微信native容器的各个事件点什么时候执行，由谁执行？
⑥ 进入页面渲染逻辑
⑦ ......
这里我还比较在意，执行事件后，对应native页面是如何进行更新的，所以我们这里关注下这段代码：
1 debugger;2 this.setdata({3 userinfo: app.globaldata.userinfo,4 hasuserinfo: true5 })
这里出现了一段非常关键的代码：
可以看到，我们这里往微信容器注册了一个appdatachange的异步事件，而这个时候就将所有的逻辑交给了native本身，native执行结束后会根据webviewids找到后续要执行的回调继续执行。
至于，容器如何使用webviewid找到对应函数的代码，我没有找到。至此，我们对小程序结构的初步探索便结束了，我们本周后面时间继续来对小程序进行深入学习。
相关推荐：小程序开发教程
以上就是小程序执行流程分析的详细内容。