微信小程序的执行流程是怎么样的?


① 底层框架解决开发效率 , 将复杂的部分做成一个黑匣子 , 给页面开发展示的只是固定的三板斧 , 固定的模式下开发即可
② 工程部门为业务开发者封装最小化开发环境 , 最优为浏览器 , 确实不行便为其提供一个类似浏览器的调试环境
如此一来 , 业务便能快速迭代 , 因为业务开发者写的代码大同小异 , 所以底层框架配合工程团队(一般是同一个团队) , 便可以在底层做掉很多效率性能问题 。
稍微大点的公司 , 稍微宽裕的团队 , 还会同步做很多后续的性能监控、错误日志工作 , 如此形成一套文档->开发->调试->构建->发布->监控、分析 为一套完善的技术体系
如果形成了这么一套体系 , 那么后续就算是内部框架更改、技术革新 , 也是在这个体系上改造 , 但很可惜 , 很多团队只会在这个路径上做一部分 , 后面由于种种原因不在深入 , 有可能是感觉没价值 , 而最恐怖的行为是 , 自己的体系没形成就贸然的换基础框架 , 戒之慎之啊!
从第三方应用接入来说 , 微信应该是做的最好的 , 百度这边有直达号等类似的产品 , 但是其体系化感觉还是有待提高的 , 阿里应该也有类似的技术产品诞生 , 从我们这层来说 , 都没有太多知晓 , 所以要么是运营的不好要么是做的不好 。
而从小程序诞生以来 , 我这边便一直在关注 , 至今整个小程序体系已经十分完备了 , 腾讯小程序和腾讯云深度整合了 , 如果使用内测的开发者工具 , 全免费 , 纯js就搞定小程序前后端 , 不用服务器、存储、cdn、服务代码 , 都是免费 , 开发完后端不用自己运维 , 大杀器的节奏 , 我有时候在想 , 腾讯的技术实力真的是强啊!
小程序的结构追溯
小程序的开发文档还是比较完善的 , 依旧是 账号申请->demo 流程 , 等熟悉后便可以走代码上架等流程了 , 前端代码用工具构建后上传 , 后台服务自己维护 , 配置地址映射 , 我们这里仅关注开发流程 , 所有使用其测试账号即可 。

Appid wx0c387cc8c19bdf78
appsecret acd6c02e2fdca183416df1269d2e3fb9
经过一年多的发展 , 小程序形成的文档已经比较完善了 , 我们可以从文档和demo对小程序做出大概的判断:
微信小程序的执行流程是怎么样的?

文章插图
 
这里就是小程序给业务人员可以看到的代码了 , 我们从这个代码以及运行 , 基本可以将小程序的梗概猜测一番 , 这里首先看看其全局控制器APP:
//app.js
App({
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实例化是怎么做的 , 这里首先明确几个点:


推荐阅读