拥有自己的动态化引擎

App的“重”，导致了一系列让它们“变轻”的技术手段出现，包括了Apple App Clips、Google Instant Apps，也包括了中国市场发展起来的由手机厂商联盟推动的“快应用”，当然也包括了最成功的“小程序”。这些技术载体标准、规格各异，采用的技术开发工具、开发方式以及所运行的环境也不同，但是它们无疑都是要达成“轻快”体验的目标。

苹果App Clips

Apple的App Clips，有说是Apple版的“小程序”。Apple官方称之为「轻应用」，可以理解成是某个App的轻量级版本，它拥有该App（本体）的部分功能，可以把它看做已有App的某个功能碎片。App Clips体积相对小，压缩前包体积最大不超过 10 M，关键是无需经 App Store 下载，因此它能保证及时性。从这个角度看确实有点像小程序。

App Clips的界面是一个卡片，用户在iPhone上看到它显示的时候，它背后的代码几乎就已经安装在了设备上了，所以响应迅速。App Clips是用户快速访问和体验一个App功能的便利方式，作为该App的一小部分，可以随需随用，而且使用时该Clips所属的App并不需要被预先安装存在于用户设备上 - 这也是App Clips的主要卖点：让用户快速体验App的部分功能后，再决定是否下载完整的App本身。

App Clips提供了快速展示本体App价值的机会。要让用户更轻松地获取完整App，开发者可以适时的在 App Clips中显示下载选项。App Clips甚至可以保留用户提供的任何信息，并且无缝转移到完整 App 中。

但是，它有一些比较大的局限：

App Clips开发属于 iOS 原生开发，开发过程几乎和原生开发无异。所以，没有iOS开发工程师的企业或者团队，就别指望靠HTML5前端工程师去干这活了

App Clips号称无需经过App Store下载，但不要以为它就无需提交Apple经受比较痛苦的审核过程，你并没有这个自由。它既然是App的一部分，每次升级还是得提交审核发布

App Clips既然是iOS原生的代码实现，显然它就无法在Android等其他平台上存在。所以它不是一个跨平台保障一致性体验的机制。例如你很可能需要用Google Instant Apps的方式来重新实现一次类似功能（但用户体验无疑是很不一样的）

因为上述技术原因，更因为小程序这种形态的应用已经在国内市场取得巨大成功，App Clips估计难以得到广泛的应用。

Google Instant App

其主要目的是其针对本体App，提高被用户发现的能力。例如用户可以通过搜索引擎和产品网站发现和直接打开使用体验一个Instant App，并因此被“引流”去下载安装完整的本体App。其他方面与Apple的App Clips原理上有相似性。当然，具体技术实现手段从编程语言到工具都完全不同。它也是原生应用开发的一部分。

小程序

说到小程序，大部分的读者第一反应，可能就是某些互联网社交平台、支付平台上的小程序。确实，小程序的概念深入人心并且已经被约定俗成的绑定到某些互联网公司的App上，导致大众听到这个概念时无法分清它指的是某家企业的小程序平台、还是某个机构所开发的小程序应用、还是某种类型小程序软件技术。

仅仅在小程序这个范畴下，又有多家互联网巨头的技术竞品。除了上至80老翁下至8岁小儿都熟悉的“微信小程序”之外，尚有支付宝、百度、美团、京东、快手、头条等等多家的平台。

小程序之所以“轻”，是因为它基于HTML、CSS、JavaScript以及JavaScript基础上一些DSL（Domain Specific Language，通常以XML形态出现），以文本格式传播，加载后由“宿主”App提供解析、渲染、执行的能力。也就是说它只是一些供解析的指令。它可以视为是HTML5基础上的人机交互体验优化，它轻量、利于传播、能产生网络效应、发版敏捷、和Web内容可以无缝融合、跨设备支持、继承了HTML5的普适性又兼具了App的移动端体验。

快应用

受到小程序类技术启迪，由国内手机厂商和运营商共同发起的一种技术形态，因为与小程序的原理上有一定相似性，不在此赘述。值得一提的是，号称是欧盟嫡系、欧盟基因的开源组织OW2，支持了快应用在欧洲的推动。

什么是有生命力可持续发展的轻应用

虽然有Apple和Google这样的巨头在推动各自的“轻应用”技术，可是在此作为一家之言，我们并不看好这些技术形态能取得多大的成功。判断标准是什么呢？

能否解决跨设备、全端支持问题。企业们都希望能够让自己的应用，开发一次、多处运行。硬件/操作系统厂商显然不在解决这个问题的最佳位置上。当前即便有Flutter、RN等跨平台技术去一定程度替代原生App的开发，但这些并非“轻应用”类型技术替代品。说到App Clips和Instant Apps，你依然需要采用iOS和Android的原生手段实现。

能否提供灵活多样的发现机制。用户不仅通过应用商店搜索发现App，更可以通过互联网搜索引擎、网站传播、朋友分享转发，获得相关应用信息并在发现后即可“就地”使用。

是否对开发者也足够轻。采用指令式的、解析型的语言编程，换句话说，基于脚本型动态语言、标签语言，应该是对大部分开发者而言门槛较低、开发较为敏捷。事实上也只有采用这种类型的技术，才能让代码轻巧体积小和便于下载、转发。

传播是否安全。原生的代码，因为对设备端操作系统资源的访问权限较大，越过应用商店机制的“越狱式”随意分发，导致的是病毒泛滥，对消费者数据安全、隐私保护造成极大伤害。App Clips和Instant Apps是尝试在应用商店机制之外提供依然安全但又便利的折衷方案。但代价是比较复杂的技术机制。

是否建立在一个松散耦合的架构基础上。轻应用往往都是一些功能单元、场景片段，如果它们之间的高度耦合、互相依赖、难分难解的，就无法独立开发测试、互不影响的发布。这好比服务器端的服务，如果彼此紧密关联，则最终它们形成一个事实上的单体应用，难以拆分和扩展，更遑论多团队并行开发。Apple App Clips和Google Instant Apps，本质上是一个App的碎片，和App本体是一一对应、紧密耦合的关系。

相较之下，小程序则是宿主应用与动态“插件”的离散关系，插件与宿主的关系是如此之松散，乃至插件的开发者、拥有者数量可以无穷无尽，并且和宿主拥有者无需有任何前置商业关系。一个互联网大平台的App，动辄支持百万级别的小程序。这种松耦合程度的技术架构，才可以支持高度敏捷性、高度可运营性、和高度的规模化。

如果基于上述的判断条件，我们看好小程序这种技术形态是轻应用领域的良好选择。因为：

• 便于在用户之间、设备之间的分享传播
• 用户之间的推荐，也是一种发现机制
• 基于JavaScript、CSS、XML而扩展/衍生，开发门槛相对低，能找到大量的Web开发者胜任开发工作
• 代码运行在基于浏览器内核的容器中，往往与运行环境所在的设备的其他软硬件资源隔离，安全性得到保障，但复杂度较低（无需开发者深入了解内部原理）
• 向未来兼容 - 正因为技术栈建立在Web技术基础上，Web上不断出现的开源框架、工具往往都可以被利用
• 宿主应用与小程序之间极度松散耦合，让敏捷轻量成为可能

所以，接下来我们主要讨论小程序作为未来主流的轻应用形态。

是时候重新理解小程序

小程序的出现，已经有五、六年以上时间。是不是就已经发展到高峰甚至过了它的鼎盛期？实际上，这是一个在继续演进的领域，还有很大的创新空间，是时候重新检视，并对小程序这个概念作出一些澄清，因为它负载了过多的含义在里面，往往在不同的语境下说的是不同的意思，导致了交流过程说明清楚的困难。

从手机用户的角度看，小程序是一种应用，就是衣食住行、医疗健康、市政服务等等各种生活场景的服务交互方式，在终端用户的印象里它们似乎都是依附、归属在某个互联网大平台的App里面的。

但对于开发者来说，小程序首先是一种技术载体，用什么工具开发、基于什么语言和规范、打包成什么样的格式、遵循什么样的要求才能申请上架到什么互联网平台。

对于企业来说，往往要考虑自己的小程序投放到多个小程序平台，这些平台各自拥有其自己全权管控的小程序内容生态。企业不过是把自己的业务以小程序形态“进驻”到这些平台上。

此外，小程序是一种正在形成的互联网技术标准，W3C的Mini-App工作组正在形成标准化的建议稿（上文提到的欧盟开源组织OW2所支持的快应用实现，也将遵循这个标准）。它不再是某个互联网公司的“专利”，“小程序”这个名字也不代表是哪一家的技术。它是一种轻应用形态，一种数字内容的表现方式，或者我们称之为“小程序化的数字内容”。

标准形成后，小程序技术的底层实现方式，依然可以是各家厂商不同。这好比浏览器厂家有Google、Microsoft、Apple、Mozilla、Opera... 它们各自的产品Chrome、Edge、Safari、Firefox、Opera等等也完全基于各自的技术而产生，但这不影响它们都能正确的在各种电脑、手机上解析、渲染和展现HTML的内容。

规范、既成事实标准、最终工业标准的形成，带来了对企业应用软件的重新解构。市场上出现新的技术门类，就是让企业以小程序这种形态为技术载体实现业务功能，并帮助企业以敏捷的方式，开发、运营、管理自己的“小程序化”的业务场景、应用服务、业务内容。小程序化，首先发生在企业内部的数字化进程中，它和互联网上的平台们，没有必然的联系。企业里开发的同一个小程序，它首先是供给给了自己的App，至于是否投放到第三方平台，那是业务、法务、合规等等部门的联合决策问题了。

新生物种：以小程序为载体的企业轻应用方案

自2017年上线以来，小程序就一直是互联网巨头的“兵家必争之地”，腾讯、阿里、百度、字节等都期望借助小程序的能力建设来丰富自家的生态，将自家的主流平台打造成为超级App。

但，时至今日，互联网巨头的蜂拥而至却反而为小程序开发者和品牌商家提供了更多元的选择，使得旗下的小程序应用不需要局限在单一平台生态之下。

虽然互联网大厂并未将这部分小程序运行能力技术开放出来，但是我们也不必望而生羡，市面上早就推出了类似的技术能力，我们一般称之为小程序容器技术。

今天要给大家分享的也正是目前在 GitHub 很热门的前端容器技术 —— FinClip 。

一句话介绍 FinClip ：可以让小程序脱离微信环境最快运行在自有APP中

只需简单集成 FinClip SDK , 即可在 iPhone、Android、Windows、Linux、macOS、统信等平台下的应用中运行你的小程序。

这意味着，移动端、PC 端、车载设备、智能电视、智能手表、智能家居都能运行小程序了。

而且 FinClip SDK 极其轻量，应用在集成后安装包的体积仅仅增大了不到 3MB。

下面这个功能特性对于研发人员应该会比较友好， FinClip 支持微信小程序语法 WXML，也就是说微信小程序代码可以直接在 FinClip 复用，无需再二次开发，体验与微信端保持一致。

FinClip 还自研了一个 小程序 IDE 开发工具，界面与微信小程序的开发工具类似，自带调试和真机预览，简单易上手。

你可以在这个 FIDE 里面，对现有项目进行二次开发，扩展功能和接口。

同时，它还支持 小程序一键转换成 App，可以将已有小程序代码导出为 IOS 与 Android 中可用的工程文件,并上架至各应用市场 。由于导出的工程文件自动集成了 FinClip SDK ，所以直接拥有小程序的运行能力，后续可在这个 APP 上继续上架更多小程序，自建自己的小程序生态。

并且 FIDE 中还包含各类扩展插件和接口（支付、人脸识别、音视频、OCR 等），开发者可自主勾选所需的支持插件，从而增强所生成 App 原生能力。

最后简单总结一下 FinClip 可以帮助企业/开发者实现什么：

「促进连接。」只要把FinClip SDK嵌入到自己的App中，马上获得小程序运行能力。小程序已经在互联网上被充分证明是一个非常有效的促进连接的技术形态。

「动态更新。」借助 FinClip 将应用中业务功能均以小程序形式替代，功能模块互相解耦，实现模块化开发，极大的提升开发效率，降低开发成本。

「多端支持。」同一个业务场景，小程序化之后，可以展现在手机端、也可以运行在PC端、更可以出现在智能电视和车载大屏上，多端同步、转发分享、一致体验，甚至可以无缝对接至互联网公共平台，代码只写一次，多处运行。

「生态共建。」让开发者、企业拥有自己的小程序应用商店，在这里可以实现与合作伙伴的资源整合 - 例如让合作伙伴把数字服务以小程序方式上架、投放到自己的App中。

FinClip 的技术方案，目的就是要让任何行业的任何企业，均可以拥有自主打造小程序生态、发布管理小程序内容、在自己的各终端App中运行小程序的能力。