这是我参与「第四届青训营」笔记创作活动的的第24天
发展历程
发展历程
17、18 年是小程序的发展初期，这个阶段最早由微信开始进行探索。17.1 小程序正式发布，这个时候小程序就有了很高的关注度，但这个时候还没有完全对个人开发者开发，到 3 月份，小程序正式面向个人开发者开放，自此，小程序数量进入爆发期。
4 月份最重要的带来了称为小程序码的新型图形码，为什么说小程序码很重要。因为它的到来真正能够让线下场景和线上小程序沟通串联起来。
9 月份支付宝小程序也开始了公测，标志着各大厂竟相进入到小程序领域开始竞争，因为围绕着小程序各大超级 app 能够构筑和丰富独属于自己的生态。
12 月份轻度游戏，小游戏上线，跳一跳风靡一时。
进入 18 年，小程序在 1 月份带来了打开 app 的能力，这也标志着小程序为其他引流功能的功能开放。
同时在 18 年，百度小程序，qq 小程序、头条小程序（现在叫字节小程序），都相继上线。“巨头”都加速布局小程序生态。
19 年，小程序被纳入腾讯最高战略，同时微信为小程序带来更加丰富的入口，开放更多的流量，如，微信主页下拉出现小程序桌面，微信搜索也可以搜索到小程序，同时微信公众号也可以自由挂载小程序，这些入口意味着更多的场景渗透。
9 月份，小程序开放贴片广告，正式开始商业化建设。随着小程序越来越复杂，小程序包 4M 的限制越来越无法满足，所以在 11 月份小程序开发包的总包上线上升至 12M，让开发者能够构建更加复杂的小程序应用。
进入 2020 年疫情的出现也加速了各种小程序的出现，同时微信为小程序赋予了直播和小商店更多的属性，为小程序的商业化带来更多的可行性。越来越多的场景，小程序整体也逐渐发展的越来越成熟。
核心数据
说完发展历程我们可以看一组核心数据，这是到 20 年底的数据，可以看出小程序的数量特别的庞大，虽然出现的不是特别久。到现在只会更多。
小程序生态
小程序是超级 app 发展到一个阶段的必然产物，因为这些超级 app 想要构筑更多的场景，让更多的人用只靠自己做是永远做不完的，所以需要开放出来给其他开发者做。所以小程序目前的生态也基本是围绕各个超级 app 来的。
业务价值
与 Web 的区别
- 有着固定的语法以及统的版本管理，平台可以更方便的进行审核。
- 平台能够控制各个入口，如二维码，文章内嵌，端内分享。入口上也能带来更好的用户体验。
- 小程序基于特殊的架构，在流畅度上比 WEB 更好，有更优秀的跳转体验。
三大价值
- 渠道价值
由于小程序的便捷性，依托于超级平台，小程序能够充分为很多场景导流，如美团和美团优选微信小程序带来的流量占比分别是 40% 和 80%。
- 业务探索价值
相比原生 APP 来说，小程序的开发难度和成本都降低的很多，这就创造了很多场景开发者能够用小程序来快速试错，不断探索新的业务价值。
- 数字升级价值
线下到线上如何做？从轻消费类的快餐、茶饮到地产汽车等大宗消费，小程序都展示了良好的容错空间。我们线下场景的小程序覆盖范围很广。
技术解析
小程序原理
WebView + JSBridge
第三方开发应用最简单最方便的方式
现在有一个超级 app，比如说抖音，微信，要让外部的开发者在我的平台上开发三方应用，怎样是最简单的？
最简单的是使用 web 技术来开发。
webview 可以简单理解为 app 内置的浏览器，我们可以在 app 内展示网页，但是除了 web 本身，我们想让开发者能够通过 js 调用更多 app 上的功能怎么办？
App 上的功能比如打开相机，打开地图等，这些单靠 web api 本身做不到，这就需要用到 jsbridege 了，顾名思义，jsbridege 就是 js 和 native 代码之间的桥梁，让两者能够沟通相互调用，实现 jsbridge 的方式有很多，如代码注入，url 拦截等。总之它的作用就是让 js 和 native 代码能够相互沟通和调用。
那么我们这种方式有没有什么问题那？
问题
1. 无网络的情况体验不佳
2. 网页切换体验不佳
3. 如何管控保证安全
提出问题，资源离线化。最重要的一点如何管控保证安全，我们对外开放先不说功能是否齐全，最重要的一点就是要保证平台的安全，因为你永远无法杜绝有人恶意在你的平台作恶。这个问题是很大的，我们先想下我们的方案，比如我们可以靠人来审核，我们把所有的网页链接都管控起来，经过我们审核的链接才可以在平台打开，先不考虑数量的问题，网页的动态性我们无法解决。
如何管控保证安全
看下这段代码：
可能审核时和上线时代码已经不同了。
所以到这里我们的 web 方案有一些走不通，那么我们需要设计一种新的方案，来解决我们这些问题，这个方案需要有以下特点：
特点 & 设计目标
1. 开发门槛低
2. 接近原生的使用体验
3. 能够保证安全可控
开发门槛低
什么样的是开发门槛低，大部分开发者都会，并且很容易学习的技术。没错就是我们的前端三板斧。HTML + JS + CSS
接近原生的使用体验
资源加载 + 渲染 + 页面切换
我们要解决这三个问题，资源加载我们可以用资源离线化来解决，渲染的问题我们等下说，页面切换的问题我们可以每次切换页面保留之前的页面，降低成本。我们可以使用这个结构：
安全管控
独立 JS 沙箱
下一个问题，如何安全管控，我们不是可以通过 js 操作dom 么，那么我们就把 dom 的 api 都禁用掉，都不允许使用。
这又带来一个问题，不操作 dom 如何渲染页面。其实这个方案，之前很多框架都有，比如 React，我们只需要关系数据流而不需要操作具体的 dom 就可以根据数据来渲染页面：
原理
这三个问题都提出了相应的方案，下面我们把这些合在一起形成这样的方案：
我们前面渲染问题还留了个坑，在浏览器中，当 js 操作频繁的时候我们的动画就会卡顿，因为他们是在同一进程中的，我们这种结构 将 js 和渲染分离 顺带解决了这个问题。
这样的通信结构，决定了小程序的性能问题在数据传递。
小程序语法
TTML
JS
TTSS
相关拓展
跨端框架介绍
问题
目前的小程序跨端框架主要为了解决两个问题：
- 复杂应用构建
- 一次开发可以跨多端
宽度框架
跨端框架原理
下面我们来说下跨端框架的原理，其实不论什么框架，都逃不开这两种实现方式，解释编译时和运行时。
编译时
源代码需要被编译成机器可以识别的程序，这个编译过程被称为编译时。
通过语法分析重新组合成小程序的代码：
<View>{foo ? <View /> : <Text />}</View>
=>
<view><block tt:if={foo}><view /></block><block tt:else><text /></block></view>
缺陷：无法完全抹平差异，所以大部分使用运行时方案。
运行时
用户可以运行编译过的程序，程序运行的过程被称为运行时。
关键：
虚拟 DOM： 通过虚拟 DOM 生成真实 DOM
Template 组件： 动态生成模板
