怎么理解后App时代的轻应用技术

对于很多用户来说，App这个事物，似乎是人与机器打交道的最天经地义的方式，仿佛“自古以来”就是如此。00后的“后浪”们，使用App可以说是“与生俱来”了。而从未接触过电脑的七八十岁老人，则可能是通过使用手机而首次接触到“带芯片的机器”，App也是他们这辈子首次接触到的软件。前些年里，很多企业的“数字化”，也言必App。

但App这个东西，也就随着智能手机的大流行出现了不过十二三年，而移动互联网发展的高峰期显然已经过去了。App这种形态的软件，早在几年前，也已经遭遇到它的困境露出疲态。它对于使用者和开发者，都产生一定的局限。

App类技术的疲态

App的软件形态存在这些问题：

• 它们是用户手机里的一个又一个信息孤岛，明明在同一个设备上，却无法互相跳转连通。尤其是和开放的Web连接互通不顺畅平滑。甚至可以说，手机App之间的移动互联网，和PC时代以来浏览器中的互联网，是两个平行世界
• 对一个App的发现、安装和运行，过程并不流畅。发现机制，一是通过互联网搜索引擎，或者通过一些媒体内容介绍，从而找到跳转Google Play、Apple App Store、Huawei App Gallery等等的链接，然后再从这些应用商店里下载；二是直接在应用商店里搜索下载。然后安装使用。用户之间的互相推荐分享，没有什么特别便利的机制 - 通过邮件、短信发送链接，然后接收方重复上述过程，此过程中流失率高
• 应用商店的存在，对于开发者和消费者，都有点鸡肋。它隔断了用户在open Web直接通过链接下载App的可能，它里面的内容通常也不能被互联网搜索引擎直接索引，所以用户只能自己“逛店”，到里面主动发起搜索，或者看看当前的App排行榜，去发现有兴趣的东西，但显然现在越来越少人会去干这种事情。对于开发者而言，所开发的App申请上架，审核时间不可控，被驳回的理由不透明，发版周期长。发版后，想让自己的产品在有数百万App的应用商店中脱颖而出，营销成本极高
• 对于任何企业来说，信息化意味着养一个团队同时支持iOS、Android以及Web。三者功能不易对齐、进度不易同步、体验完全不同

时代召唤新软件形态 - 轻应用

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 中。

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

1. App Clips开发属于 iOS 原生开发，开发过程几乎和原生开发无异。所以，没有iOS开发工程师的企业或者团队，就别指望靠HTML5前端工程师去干这活了
2. App Clips号称无需经过App Store下载，但不要以为它就无需提交Apple经受比较痛苦的审核过程，你并没有这个自由。它既然是App的一部分，每次升级还是得提交审核发布
3. 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，至于是否投放到第三方平台，那是业务、法务、合规等等部门的联合决策问题了。

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

互联网巨头们自营的平台，在其中上架的小程序内容，均由他们进行审核、生杀予夺。所形成的数百万计的小程序内容生态，也是由平台掌握。当然，这些小程序也只能运行在他们提供的App中。

但这种连接能力强、数字化程度高、生态内容丰富的技术，能否为一般企业所掌握呢？这里所谓的“掌握”，不是说企业有能力去开发小程序然后上架至某个互联网平台开展业务、成为别人生态的一部分，而是企业能否拥有类似的技术，搭建自己的小程序运营平台、小程序商店、小程序开发者中心，自行掌握对其中内容的审核、上下架管理，把小程序投放至自己的App中运行，并让别人成为自己的合作生态。

拥有这样的技术，任何企业对内可以让IT把业务内容小程序化、对外可以采购或引入开发商提供的小程序化应用系统，然后上架至自己的“小程序商店”，对自己的员工、客户进行分发。

这种工具，我们称之为小程序化轻应用技术底座，它就是让企业以小程序这种“格式”、“规范”、“标准”去开发软件功能，并对这些功能单元进行生命周期管理、上下架发布审核以及传播渠道的投放与监控。

面向企业的小程序化轻应用技术，它的竞品是谁呢？答案并非拥有小程序生态的互联网平台，而是传统原生App开发模式、网页应用开发模式、desktop软件开发模式。这正如HTML、JavaScript首先盛行于互联网的网站，后来它们逐渐被运用于企业应用，出现国内曾经风行一时的所谓“B/S架构” （Browser-Server架构），从而与PC时代的C/S架构、基于Visual Basic/Visual C++的应用开发产生竞争并最终替代了后者。小程序化的轻应用技术，正处于从互联网进入企业市场的时刻。

FinClip：起源于金融业的轻应用技术底座

最早把小程序作为企业轻应用软件技术载体的产品是FinClip - 凡泰极客自2019年前后即开始深耕这一领域。

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

• 小程序是促进数字化连接的最佳载体
• 连接是企业数字化转型的核心关键
• 数字化内容资产的小程序化，最有利于敏捷发布业务场景、实时风控、降本增效

FinClip的命名本源，是 FinTech + Clip。因为这个技术起源于金融科技领域，原来的设计理念是，让银行、证券等金融机构把功能繁琐复杂、合规要求严格、数据安全风险控制性强的数字化业务场景，以一种“轻应用”的技术形态开发，让业务部门以“上下架”的机制自行进行功能碎片的发布管理，让消费者用户以随需随用的方式加载至App中进行使用，并且每次的使用，总是自动获得最新的版本。FinClip研发团队基于金融业务场景的需求，经过对系列相关技术的深度研究，决定采用“小程序”格式，并把它称之为“Clip”。

“Clip”这个词，也被Apple在其App Clips技术中采用。它是一词多义，浓缩了多个中文翻译的内涵，特别适合于技术命名：

因为小程序技术形态完全吻合这个单词所包含的多重含义：作为代码“片段”，被“夹在”某个应用“宿主”上迅捷运行；并且代码是加载到一个嵌入在宿主中的“弹匣”（或者说“容器”）里随时射出；适合于像附件一样转发分享传播的应用片段，启动时间短、运行速度快。所以，FinClip的含义，就是“金融科技场景的敏捷轻应用”。

FinClip让金融机构能够敏捷、动态的发布业务场景，并能迅速对有任何潜在合规风险、信息安全风险的场景实时下架，而无需重新发版App并经历手机操作系统平台的应用商店、应用市场长达数天的审核甚至打回。毕竟金融业务风险处理有巨大的时间压力，还有监管机构问责的压力。风控永远不嫌“实时”。

发展到今天，FinClip已经不再是金融业务场景的专用技术。事实证明，它能满足强监管、强信息安全与隐私保护规定、强风控要求的金融业诉求，也就能满足其他各行各业的应用诉求。它也不再仅仅支持在手机App中运行轻应用，它更支持在各种桌面端、物联网智能设备端的运行，逐渐发展成为一个在多终端、多设备进行数字内容发布与监测管控的平台型技术工具。