小程序的前世今生

先梳理一下小程序是怎么慢慢从出现，到现在的吧：

• 2011年9月，UC浏览器作为当时最大的手机浏览器厂商，推出了Web App
• 2011年10月19日，Android 4.0发布
• 2013年8月，百度世界大会推出“轻应用”
• 2014年10月，HTML5规范正式定稿
• 2016年1月，微信小程序概念被提出
• 2016年9月，微信小程序开始内测；支付宝小程序启动
• 2017年1月，微信小程序上线
• 2017年5月，Google Instant Apps 正式开放
• 2017年8月，支付宝小程序公测
• 2018年11月，头条小程序公测
• 2019年9月，W3C 首次公开发布小程序标准化白皮书

小程序和H5

说起小程序，就不得不提起H5。小程序无论是开发还是使用，都和H5十分类似。但从技术上，主要差距体现于：

• 视图层（View）和逻辑层运行于不同的进程中，因此，小程序需要一种“响应式”的结构。
• 具有渲染原生组件的能力，例如View、TextView等，性能和体验更好。
• 资源离线化，减少加载时间。
• 后台保活机制

进程隔离

这是小程序的基本特性之一：视图和逻辑隔离。这样有什么好处？当然是安全和性能了。你可以将其理解为网页和Service Worker的关系。这也就解释了，为什么小程序那么像React/Vue，因为它本身便是一个渲染分离的设计。

原生渲染

说起原生渲染，不知道大家有没有想到React Native、Weex？它们也有渲染原生组件的能力。事实上，支付宝小程序在做技术选型的时候，考虑过他们。支付宝小程序有基于RN的版本，淘系小程序则基于Weex。

不过，这样性能是好了，但也带来了问题：开发者不能在原生组件上覆盖东西。为了解决这个问题，微信推出了cover-view——但它只能在原生组件上覆盖另一个原生组件。支付宝则选择升级同层渲染技术，借助UC内核，实现了视图擦除，可以在原生组件上覆盖其他组件。

小程序的开发

小程序开发主要有几大“流派”：

• 原生
• 套壳
• 转换型
• Runtime

原生和套壳自然不必多说了。近几年来流行的框架主要是转换型，例如Taro、mpvue、Rax等，简单地说，他们做的事就是：

• 用框架的语法写一遍
• 提取DSL，然后转换为原生小程序的DSL
• 加一点polyfill
• 完事

这样好处是性能比较好，写起来也比较方便。坏处当然也有：限制比较多，部分能力缺失。例如使用React语法的Taro、Rax，相比于React本身或多或少都有一些限制。

另一个比较有意思的是Runtime型，以Remax为代表，它们把React给“搬”了过来。它们实现了一套“给小程序用的”React Native。这样做好处自然不少：基本无限制，可以完整使用React。缺点也很明显：性能低。

具体如何选择，仁者见仁智者见智吧。感兴趣的可以移步：Remax - 使用真正的 React 构建小程序

前景

其实各家推出小程序的目的并不完全一样。甚至于，哪怕是阿里自己，不同平台目的也不一样。例如：

• 微信、支付宝：和其自身生态（例如公众号等）互通，打造一体化平台。
• 钉钉：让更多ISV入驻，增加其办公协同能力。
• 淘宝：将自身复杂业务拆解，方便维护。（淘宝一点也不着急对外开放）

因此，做小程序之前，也要想清楚自身落地平台是否合适。小程序的形式，注定了其是一个简单、快捷场景下的选择。其场景一般是：

• 服务类：顾名思义，即为用户提供一些便利服务的，一般是以线下为主，例如：点餐、购票、共享单车等。当然，也不乏一些线上的服务，例如生活缴费等。
• 引流类：有自身平台，借助小程序引流的，例如微信里面的京东小程序、以前的头条等
• to B：to B是一个大场景，而且B端用户（公司）付费意愿比C端更高。但很大程度上依赖于平台，目前国内最大的平台自然是钉钉了。

在当前移动浪潮下，小程序未来的总体发展我是看好的。现阶段存在的最大问题是：标准割裂。微信由于其先发优势，它的设计基本上成为了事实上的标准。但如果你真的试着开发过多端小程序，你会发现很多“看上去”一样的API，其实总有那么一些地方不太一样。

2019年9月12日，W3C 首次公开发布了小程序标准化白皮书。但细心的人可能发现了：起草这份标准的主要人员，来自于阿里巴巴、百度、华为、Intel、小米、中国移动，其大概可以代表几类平台：阿里系（支付宝、钉钉等）、百度、快应用联盟（华为、小米等手机厂商为主），没有看到微信的身影。是他们想甩开微信单玩吗？其实不然。在起草这份标准之前，尝试过邀请微信，但微信拒绝了。想一想倒是也符合腾讯的习惯：打造垄断平台。希望微信不要成为下一个IE。