对快应用的看法

转自： 文章来源

一不小心前端又出新框架系列。

国内厂商联合起来推出快应用，说说看法。

与小程序相同点

1. 前端技术栈：毫无疑问所有类似方案都只能是前端技术栈，从社区成熟度，开发者接受程度，开发效率各方面没有对手。
2. native 能力：都提供了比 web 更多的 native 能力。
3. 即时/离线：跟 web 一样即点即用，跟 native 一样离线使用，前提是应用不复杂，体积限制在1M以内，当然以后复杂了也可以做分包。

与小程序的不同点

1. native 渲染：快应用使用前端技术栈开发，native 渲染，性能体验会比较好，看代码挺像是直接拿 RN 改改用了，不过发布会上没提到 RN，而小程序目前是webview渲染。
2. 自定义框架和规范：与小程序不同的开发框架和规范，快应用更像 vue 的写法，文件结构不一样，样式上因为使用native渲染，只支持 flexbox 布局，CSS 属性的支持程度上不如 webview 渲染的小程序，能力会弱一些。
3. 系统级能力：目前看起来小程序没有的只有deeplink和push，通过url唤起快应用的deeplink，以及跟原生一样的push能力。

优势

1. 流量：目前看起来，对开发者来说，使用快应用最大的理由就是厂商的流量扶持，而这是不是个优势还得看各厂商的扶持力度。
2. 反垄断：小程序腾讯有绝对控制权，开发者把身家性命都放在腾讯的平台里，可能会导致任人宰割，自身对应用的控制力也弱，多一个渠道多一份活路。
3. 其他：native渲染，deeplink入口，原生桌面入口，push能力这些目前相对小程序算是有一些优势。

劣势

1. iPhone：联合再多的厂商，也联合不到苹果，中国高端手机市场 iPhone 份额高达85%，做快应用要不就是放弃这部分用户，要不就是针对 iPhone 再做一套，这个成本划不划算只能看能从厂商流量扶持里拿到多少好处，否则为什么不开发小程序。
2. 跨公司合作：一个大公司内跨部门协作都困难，何况跨N个公司的合作，而且还没有一个站在上一层的领导者，要做成非常困难。
3. 社交：快应用缺乏微信的社交场景能力和传播手段，推广拉新成本仍不低。

看法

移动开发向前端技术栈倾斜，原因：

1. 超级APP，业务越来越多，为了减体积和动态发布能力，大部分业务使用前端技术栈开发。
2. 普通APP，拉新成本高，用户装APP的意愿低，开始尝试转向即开即用的H5/小程序和类似平台拉新。

普通业务开发，按目前趋势越来越倾向前端技术栈，即使是独立APP，展示型业务在 APP 里也会倾向用前端技术栈开发，从开发效率/跨平台/动态性都很有优势，劣势是性能体验稍差，这点长期可以靠机器硬件的提升，短期可以用类似RN方案。

小程序为这样的需求提供了个很好的平台，但缺陷是开发者对应用没有控制力，无法 push 触达唤起用户，入口也一般，生命线掌握在腾讯上，快应用可以弥补这些缺陷，提供了另一个选择，不过不支持 iPhone 仍是个几乎无法解决的致命缺陷，加上上述提到的劣势，总体上不看好。这种事可能得由 google 联合苹果一起做才有戏。

native VS web 这个话题从 08/09 年开始开始到现在都没有结束，因为各有不小优势，即使是现在 web 技术栈占上风，原生 APP 的性能体验，快捷入口，品牌认知这些优势仍是不小，而且技术的发展同时给 native 和 web 两种模式提供了利好，并没有倾向其中一方：对于 web，硬件提升使得体验越来越好。对于 native，运营商无限流量的时代和越来越大的存储空间使得用户装 APP 成本下降，这两个开发模式在很长时间内仍是融合的状态。