产品价值

小程序带来的更大的价值就是它的产品价值，它帮助例如微信这种超级app构筑了更加完整的生态，扩充了更多的业务场景，这才是小程序最最重要的价值。当然它也在技术上带来了很多价值，我们后面都会讲。其实不论什么技术，最终都是要为业务服务的，技术本省不存在优劣，只存在是否适合。

发展历程

17、18年是小程序的发展初期，这个阶段最早由微信开始进行探索。17年1月小程序正式发布，这个时候小程序就有了很高的关注度，但这个时候还没有完全对个人开发者开发，到3月份，小程序正式面向个人开发者开放，自此，小程序数量进入爆发期，4月份最重要的带来了称为小程序码的新型图形码，为什么说小程序码很重要。因为它的到来真正能够让线下场景和线上小程序沟通串联起来。9月份支付宝小程序也开始了公测，标志着各大厂竟相进入到小程序领域开始竞争，因为围绕着小程序各大超级app能够构筑和丰富独属于自己的生态。12月份轻度游戏，小游戏上线，跳一跳风靡一时，不知道大家都有没有玩过，进入18年，小程序在1月份带来了打开app的能力， 这也标志着小程序为其他引流功能的功能开放
image.png
同时在18年，百度小程序，qq小程序、头条小程序（现在叫字节小程序），都相继上线。”巨头"都加速布局小程序生态，19年小程序被纳入腾讯最高战略，同时微信为小程序带来更加丰富的入口，开放更多的流量，如，微信主页下拉出现小程序桌面，微信搜索也可以搜索到小程序，同时微信公众号也可以自由挂载小程序，这些入口意味着更多的场景滲透。9月份，小程序开放贴片广告，正式开始商业化建设，其实对所有企业来说所以业务最终都是为了赚钱嘛。随着小程序越来越复杂，小程序包4M的限制越来越无法满足，所以在11月份小程序开发包的总包上线上升至12M，让开发者能够构建更加复杂的小程序应用。
image.png
进入2020年疫情的出现也加速了各种小程序的出现，同时微信为小程序赋予了直播和小商店更多的属性，为小程序的商业化带来更多的可行性。后面的就不说了，总之就是越来越多的场景，小程序整体也逐渐发展的越来越成熟
image.png

核心数据

说完发展历程我们可以看一组核心数据，这是到20年底的数据，可以看出小程序的数量特别的庞大，虽然出现的不是特别久。到现在只会更多
image.png

小程序生态

小程序是超级app发展到一个阶段的必然产物，因为这些超级App想要构筑更多的场景，让更多的人用只靠自己做是永远做不完的，所以需要开放出來给其他开发者做。所以小程序目前的生态也基本是围绕各个超级app来的
image.png

业务价值

  • 有着固定的语法以及统一的版本管理，平台可以更方便的进行审核
  • 平台能够控制各个入口，如二维码，文章内嵌，端内分享。入口上也能带来更好的用户体验
  • 小程序基于特殊的架构，在流畅度上比WEB更好，有更优秀的跳转体验

三大价值

渠道价值

由于小程序的便捷性，依托于超级平台，小程序能够充分为很多场景导流，如美团和美团优选微信小程序带来的流量占比分别是40%和80%

业务探索价值

相比原生APP来说，小程序的开发难度和成本都降低的很多，这就创造了很多场景开发者能够用小程序来快速试错，不断探索新的业务价值

数字升级价值

线下到线上如何做？从轻消费类的快餐、茶饮到地产汽车等大宗消费，小程序都展示了良好的容错空间。我们线下场景的小程序覆盖范围很广

技术解析

第三方开发应用最简单最方便的方式
WebView + JSBridge
我现在有一个超级app，比如说抖音，微信，我要让外部的开发者在我的平台上开发三方应用，怎样是最简单的？
很多同学可能也想到了最简单的是使用我们的web技术来开发，其实没错。我这里写的是webview和jsbridege，可能有同学还不太清楚，
我来简单解释下这两个词，webview我们可以简单理解为app内置的浏览器，我们可以在app内展示网页，但是除了web，我们想让开发者能够通过js调用更多app上的功能怎么办App上的功能比如打开相机，打开地图等，这些单靠web api本身做不到，这就需要用到我们的jsbridege了，顾名思义jsbridege就是js和native代码之间的桥梁，让两者能够沟通相互调用，实现sbridge的方式有很多，如代码注入，url拦截等，感兴趣的同学可以自己查下，我们不
展开说了。总之它的作用就是让js和native代码能够相互沟通和调用。
那么我们这种方式有没有什么问题那？

  • 无网络的情况体验不佳
  • 网页切换体验不佳
  • 如何管控保证安全

资源离线化。最重要的一点如何管控保证安全，我们对外开放先不说功能是否齐全，最重要的一点就是要保证平台的安全，因为你永远无法杜绝有人恶意在你的平台作恶。这个问题是很大的，我们先想下我们的方案，比如我们可以靠人来审核，我们把所有的网页链接都管控起来，经过我们审核的链接才可以在平台打开，先不考虑数量的问题，网页的动态性我们无法解决

我们需要一种全新的方案来解决管控问题

  • 开发门槛低
    • HTML + JS + CSS
  • 接近原生的使用体验
    • 资源加载＋ 渲染＋ 页面切换
    • 资源加载我们可以用资源离线化来解决，页面切换的问题我们可以每次切换页面保留之前的页面，降低成本。我们可以使用这个结构
    • 多 webview
    • CleanShot 2022-08-19 at 11.53.37.png
  • 能够保证安全可控
    • 独立 JS 沙箱
    • 如何安全管控，我们不是可以通过js操作dom么，那么我们就把dom的api都禁用掉，都不允许使用。
    • CleanShot 2022-08-19 at 11.54.39.png

不操作DOM如何控制页面渲染
CleanShot 2022-08-19 at 11.55.28.png
整合全新方案
我们前面渲染问题还留了个坑，在浏览器中，当js操作频繁的时候我们的动画就会卡顿，因为他们是在同一进程中的，我们这种结构将js和渲染分离顺带解决了这个问题。
这样的通信结构，决定了小程序的性能问题在数据传递。
image.png

相关扩展

跨端框架

复杂应用构建，一次开发可以跨多端，
目前主流框架
CleanShot 2022-08-19 at 11.58.50.png

跨端框架原理

编译时

手把手带你入门 AST 抽象语法树
抽象语法树（abstract syntax tree，AST） 是源代码的抽象语法结构的树状表示，树上的每个节点都表示源代码中的一种结构，这所以说是抽象的，是因为抽象语法树并不会表示出真实语法出现的每一个细节，比如说，嵌套括号被隐含在树的结构中，并没有以节点的形式呈现。 抽象语法树并不依赖于源语言的语法，也就是说语法分析阶段所采用的上下文无文文法，因为在写文法时，经常会对文法进行等价的转换（消除左递归，回溯，二义性等），这样会给文法分析引入一些多余的成分，对后续阶段造成不利影响，甚至会使合个阶段变得混乱。因些，很多编译器经常要独立地构造语法分析树，为前端，后端建立一个清晰的接口。 抽象语法树在很多领域有广泛的应用，比如浏览器，智能编辑器，编译器。
语法树的作用：

  • IDE的错误提示、代码格式化、代码高亮、代码自动补全等
  • JSLint、JSHint、ESLint对代码错误或风格的检查等
  • webpack、rollup进行代码打包等
  • Babel 转换 ES6 到 ES5 语法
  • 注入代码统计单元测试覆盖率

image.png
image.png
编译时方案有个天然的缺陷，无法完全抹平差异，不论是React和vue等各种框架，它们的用法都十分多样，而且会不断添加新的特性，而小程序本身确有很多的限制，那么在转换过程中，很多特性没有办法进行转换，所以就要给框架的书写代码的时候加上很多限制，这背离了我们的初衷，所有现在更多的方案采用运行时的方案

运行时

运行时的方案能够实现主要依赖这两个部分，一个是虚拟dom，一个template组件
image.png
CleanShot 2022-08-19 at 12.06.48.png
当然运行时的方案也不是完美的，我们前面在讲小程序原理的时候不是说setData是小程序的性能瓶颈吗，运行时的方案，因为要传递虚拟dom的各种属性到渲染层
在一些场景下相比小程序原生语法性能会更差，比如长列表，当然现在针对各种场景出现了有很多优化手段，这个时候我们可以采用混合开发，使用小程序原生语法和框架语法搭配开发