编辑：Coco Liang

时间倒回4月9日，9To5Mac通过iOS 14的代码，猜测苹果或将推出全新的APP下载和使用方式，用户只需扫描二维码或打开链接，即可体验应用程序的某些特定功能，而不需要在iPhone或iPad上安装APP的完整版本。

消息称，iOS 14将会使用一种被苹果内部称为“Clips”的API。 “Clips”允许开发人员向用户提供应用程序中交互式的动态内容（在用户尚未安装该应用程序的情况下）。

假设用户扫描的二维码带有指向YouTube视频的链接，但是该用户并没有在iPhone上安装YouTube官方应用程序，那么只要通过 “Clips”，用户便能够扫描该二维码，并在本地用户界面而不是Safari网页上观看视频内容。

由于目前关于 “Clips”的资料非常有限，我们专门采访了花椒直播技术部负责人唐赓，和他一起对“Clips”进行了一些有（大）限（胆）的探（猜）讨（测）：

有关第1、2点猜测，唐赓的看法是：

"先说说我熟悉的直播领域音视频技术的现状，目前iOS系统硬件已经很强大，H.264、H.265硬件编解码也已经很普及，此外，硬件回声消除效果也很令人满意，常规的采集和播放也不存在难度，更多的问题还是集中在网络层面。

低延迟、抗丢包、抗抖动以及多人实时互动等等，还需要技术优化。另外，基于AI的视频人脸识别、表情识别、肢体识别、背景分割、虚拟形象驱动、虚拟主播等也是目前非常重要的方向，可以提供很多面向未来的体验和玩法。

说回Clips，大家都拿安卓的Slices进行对比，不过我觉得安卓Slices主要出现在Search结果页和Assistant，目标是用于整合手机内部应用的功能。

而iOS的Clips从描述上看更接近国内用户早已熟悉的微信扫码和小程序，主要定位应该是和线下应用结合，进行动态展示和交互，就像现在大家常用的扫码购物、点餐、租车、导游和购票等等。

‘Clips’API允许开发人员向用户提供应用程序中交互式的动态内容，支持用户‘扫描二维码—跳出程序卡片—本地观看视频’。为了让用户无感下载显然应该要想方设法最小化Clips组件的体积，我认为开发者应该选择基于系统已有的组件来实现。

比如基于系统的HLS播放器、原生WebRTC，或者可以更激进一些，把一些原来基于客户端实现的一些特效如点赞、礼物特效等等，在服务端混入视频流后在Clips内进行展示，以提供更完整更接近App的用户体验。

估计苹果也会允许直接调用ApplePay、IAP进行支付，登录也会基于Apple ID（苹果要求6/30之前所有App都要支持苹果登录可能就是在给它铺路？）。

如果主要基于HLS播放的话，要实现低延迟的用户体验，采用去年苹果推出的低延迟HLS方案可能是一个必然选择。当然，如果不需要强调低延迟特性的话，普通HLS也应该够用了。

Clips的定位应该主要是线下应用，音视频方面应该是更倾向于点播类型的业务，实时类型的业务基于WebRTC也应该没有问题。

事实上，即使是Chrome也很难同时支持网络应用、iOS和Android，而我们最不需要的就是Android和iOS也同样加速脱离Web标准。

有网友称，如果你担心Chromium的影响太大，那么你也应该担心Webkit的控制太多。

拿HLS举例，HLS由苹果开发，也被广泛使用。但如果要在Apple设备上播放视频，则必须使用HLS。而iOS上的Webkit中不提供构建自己的播放器（MSE）所需的工具，并且由于用户无法使用其他浏览器引擎，事情因此变得很麻烦。

Safari不支持WebP或VP9之类的开放标准，苹果也在尽力禁用硬件解码器支持的类型。现在基本上每个大型流媒体平台都需要对内容分别进行DASH和HLS编码，类似与Webkit-iOS相关的问题肯定也存在于其他行业。而将所有人锁定在一个渲染引擎上是非常anti-consumer的。

不会有人想让一家公司控制Web标准，这将意味着这家公司可以在该标准损害其商业模式的情况下对其进行修改甚至是删除。这就类似于AppStore可以通过限制用户对应用程序类型的访问（例如游戏直播应用）来减少用户的选择，which，损害了消费者利益。

目前并不确定Clips的应用范围（iOS 14构建了QR码），但如果它被用在搜索结果或Siri中，也不足为奇。但Siri的功能因此被延伸的同时，也存在着很大的安全隐患就是了。