小程序和H5真的有孰优孰劣吗？详解两者的适用场景

原创

海岛船长加西亚

修改于 2021-11-24 16:39:27

2.6K0

文章被收录于专栏：用户8927754的专栏用户8927754的专栏

小程序与H5（HTML5）均为前端开发语法之一，二者仅在技术上并不能直接做出诸如“小程序优于H5”或“H5优于小程序”的判断。二者在特定场景下、分别有各自更优秀的表现。因此，本文将尽量公允的就两种技术更适合的场景进行说明。

二者在App场景下的适用性

H5很少作为App内唯一的技术栈，通常App均采用原生+HTML5的混合型技术，该类方案在生态化、连接方面有较大的局限性，原因如下：

技术架构实现总体比较紧耦合，对于核心功能稳定、在核心功能之上提供相对独立、多元化的应用逻辑时，难以做到灵活轻量。虽然业界在这方面作了很多尝试，发展出各种框架（一定程度上是自我重新发明一种封闭的“类轻应用”），以HTML5为业务场景的应用逻辑载体，却依然未能达到实现业务场景的生命周期独立于App本身 – 即业务场景的独立开发、独立测试、独立发布、独立跟踪监控、在线管理。
一般不具备“应用市场”机制，没有通过工具去管理独立生命周期的应用场景的能力，只能通过IT人员进行场景的发布，不能通过运营人员、业务人员基于业务需求和行政审批去“上架”。
一般不具备开发者中心和开发者账户的概念，所以无法对IT以为的合作伙伴提供在线测试、发布的服务，也就无所谓生态化支持一说。
基于HTML5封装的商业场景，不是最适合于转发分享、社交传播的技术方式。原因（1）实际上都是网页，通过浏览器可直接打开，在信息安全方面需要做更多更复杂的技术保护，缺乏安全沙盒的管控；（2）分享转发到微信等社交平台，如果希望打开的是该些平台原生的小程序技术所实现的对应页面，则同一个业务场景需要实现两个版本。
较难达到业务平台所需要的要求，即业务部门可以在最大程度降低传统IT运维介入、省去App发版的情况下，自行对App中内容进行运营管理，例如上下架一些内容、升级一些模块、引入一些合作商家等等。

小程序是一个更优的、极度松散耦合的解决方案，正如微信已经充分证明，它能支持百万数量的开发者，超过四百万个的小程序，其根本在于微信App本身与这些小程序之间的耦合是非常低的，每一个小程序由独立的团队、独立的企业开发运营，提交腾讯进行审核上架，每天小程序的诞生与消亡都是海量的，但并不影响微信App自身的稳定性；而微信App本身在苹果应用市场、安卓应用市场的升级，也不干扰任何小程序个体。只有采用这样的技术，才有可能发展生态、建立与外部的连接。

二者在业务应用上的适用性

经过在多家机构的讨论、验证，我们建议参考下表判断业务应用所适用的技术手段：

除此之外，我再拿实际工作中证券公司开户业务为例，进一步分解小程序开户与H5开户应用的优缺点：

综上，H5在跨平台和分享行为上有着显著优势，但当业务内容较为复杂、涉及较长的业务逻辑与跳转时，小程序将是更优秀的选择。

混合开发模式：「Native+小程序」

当前大部分app 都会选择混合开发的模式，「Native+H5」是最常见的。而「native+小程序」的架构模式更多的是一些超级APP在使用，比如微信、美团、百度、抖音等，而对于中小公司来说还不够普及！主要原因在于：想在自己的 App 中打造与微信小程序类似的生态，小程序容器技术是无法绕过的门槛，而普通公司显然是没有这个研发成本和人力资源去投入小程序运行沙箱与 SDK 的研发。

在这里要为大家介绍一款小程序开放平台——FinClip，该平台可以为所有企业提供小程序容器技术。只需要几行代码就够将小程序运行环境集成到 App，从而让App具备小程序运行的能力。

FinClip 是啥？官方介绍 FinClip是与“微信小程序”、“百度小应用”等其他小程序开放平台具有类似属性的技术平台。从技术的角度来说，FinClip的核心是提供一个小程序容器技术。它由能渲染与执行小程序的客户端引擎、统一管理小程序上下架的中心、支撑小程序服务器端运行的云端设施、以及合规监管工具共同组成。