【杂谈日记】小程序利弊背后的非良性竞争

刚打开了家里空调的暖气，突然有个小问题想吐槽一下，就是小程序这东西。

准确来说，现在被我们称为“小程序”的移动端应用形式，本质上是为了解决某种问题而提出的一个出发点很好的方案，但最终因为各种竞争性因素导致实际使用起来的感觉并不理想。

尤其是某产品经理的小而美，其平台下的小程序是又难用又让人不得不用，坑得要命。

小程序本质上是为了简化功能简单的手机应用的开发而提出的一种网页应用形式。比如说奶茶店的点单软件，智能空调的遥控器等等，都属于这种需要实现的功能特别简单，但是又有开发需求的移动端应用。

独立应用的开发存在一个稳定性、开发效率与应用体积不可兼得的情况，也就是真正意义上的“小而美”的应用，往往需要开发者较多的开发时间，而又快又小的软件，很容易出现不可控的bug，又稳又快不是不行，但那基本是通过直接调用成熟的底层框架来实现的。

如果你想知道有什么直观的例子？看看你手机QQ里的虚幻引擎就知道了，那是QQ为了实现超级QQ秀功能而塞进去的。

而小程序的设计初衷就是为了解决应用又快又稳又小的需求，本质上是在前述又快又稳的基础上，通过将大家都要用的通用代码集成在一起，并约束一个调用方式，让开发者只需要进行功能实现部分的代码而不需要怎么关心底层设计，减少手机内的重复代码。

这个目的实现了吗？实现了，但又没完全实现。

小程序确实做到了开发快，体积小，稳定性高的设计初衷，但同时又引入了新的问题，启动响应速度慢。

这是什么意思呢？我抄起实体遥控器，调空调温度，只需要3秒的时间；点开手机自带的红外遥控，调空调温度，也不过是5秒左右的时间；但即便我将空调控制小程序放在解锁之后直接就能看到的地方，30秒的时间，还不够我启动小程序。

为什么会这样呢？

遥控器小程序30秒的启动速度，其中大概10%是小程序的先天缺陷，90%是张小龙的问题。

小程序共用代码所需要支付的代价就是，小程序的启动必须先启动它的依赖程序，比如微信小程序的依赖程序就是微信，饿了么小程序的依赖程序就是支付宝，以此类推。

那么小程序的实际启动速度等于依赖程序的启动速度加上小程序自身的加载速度，而微信本身结构巨臃肿巨蠢不提，在小程序依赖的调用优先级方面也有很大的问题，必须得等微信基本功能加载完才能加载小程序，这就慢的要死了。

而这并不是不能解决的，毕竟我扫哈罗单车的时候基本没有等待支付宝启动的时间，很显然二者对于小程序依赖模块的启动优先级有很大的区别。

但实际上也可能是因为支付宝本身的很多功能都小程序化了，本身的应用本身就跟一个空壳一样，启动起来自然会快，这一点我也测试不出来。

不过，无论是支付宝还是微信，很显然都并不是小程序的依赖框架的最佳载体，甚至说，他们本身推出小程序的根本目的就并不是为了解决应用开发三难全的问题的，至少张小龙肯定不是。

对于他们而言，开发小程序最大的目的并不是为了让开发应用更简单，而是让使用小程序的人离不开小程序所以来的框架程序。

小程序最理想的状态就是依赖一个公共的，系统级的核心框架，这样的小程序很显然就能做到与原生应用相近的响应速度，就如同系统级红外遥控程序那样丝滑。

有人做出尝试吗？有，快应用联盟了解一下。

虽然这个联盟和对游戏厂商敲骨吸髓的硬核联盟有着同一个发起方，但整体的出发点和预设目标都是很好的。

但实际上呢？

小程序的本质并不是通过统一的标准降低应用的开发成本，而是利用小程序开发者提供的丰富功能来为自己圈城划寨，从这个根本原因出发，就不难理解为什么这个联盟基本不可能打得过微信和支付宝的小程序，甚至现在自己也基本处于“内讧”状态了。

用户体验？

从来都不是这些互联网企业所会考虑的东西捏。