「There's an App for That.」（这个功能有个专门的应用！）

自从 2008 年以来，这句话就成为了手机产业的商标口号。编程集训班一个接一个地出现，号称能在几周内就教会你自己开发应用；各种产品也会通过广告推销自己和相关新应用；就连楼下的餐厅都推出了自己的菜单应用。

2008 年世界上出现了第一家手机应用商店，Apple 也因此成为了推广把手机应用包装好并给用户提供下载的「应用商店」这个概念的第一商家。但事实上，类似的软件集中提供的概念对人们而言并非陌生。不少移动或桌上电子设备早在 Apple  App Store 之前就有了自己的应用商店。然而 Apple 之所以能从中脱颖而出大获成功，主要还是由于他们掌握着过硬的技术和天时地利人和。2008 年，iOS 平台已经能给用户提供非常成熟的 3G 网络、资料存档完善的开发环境、极佳的屏幕显示等一系列成熟的特性。Apple 提出的手机应用商店概念也非常顺理成章：想给用户在第一时间提供最新的服务和内容，同时又保障最好的体验和性能的话，「应用商店」确实是最高效的渠道。

用户从来不关心那些功能和服务是如何运作的。对他们来说，用的舒服就行。在 Apple App Store 刚刚上线的时候，Apple 的应用商店凭其下载方便、应用质量高等一系列 iPhone 用户独享的特性占据了市场的领导地位。不过 Android 也很快跟上了这套模式。智能手机开始变得廉价，网速变得更快，设备的处理能力直线上升，应用也做得越来越好。

「所以呢？哪儿不好了？」

现在的这套模式并没有什么不好，但我们能做得更好。手机应用之所以会如此成功是因为它结合了高速的网络和设备的处理能力。但这些年来科技已经进步了太多，市场上的手机应用也早已多到泛滥。产品在市场上的渗透度已经成为了一个无数厂商最头疼的问题之一，而说道渗透度，最关键的两个因素就是产品内容的「传递」和「可发现性」。

相信每个智能手机用户都有过类似的经历：「哇，这家餐厅有 8 折优惠活动诶！哦……不过得要先下载这个应用」，或者「等等，我只是想看我朋友发了啥啊？一定要下载这个应用才能看得到吗？」有时候你会碰巧从朋友那里听说或者在排行榜里看到某个好玩的应用，但又犹豫到底要不要下载或者付费。

问题有两点。首先来说第一个，内容的表达和传递。人们使用电子产品的时候已经步入从前那样有耐心了。以前，下载或是购买应用本是个非常自然、流畅又普通的体验；但如今，这更像是对产品的莫大的认可。说真的，这年头要说服人们尝试一个新应用实在是太难了。你给出十几条值得信服的理由，无比诚恳的演说，他们才可能会勉强愿意试试看你的新作品。不信的话你想想身边那些拒绝下载 Messenger 的朋友们就理解了——更别说 Messenger 已经是个各方面都非常完善的应用。开发商希望能把内容和服务以最简单、最迅速的方式传递给用户，但客户越来越不愿意下载新应用，这门槛自然也就越来越高。某种意义上我们的手机界面简直就是新旧金山，寸土寸金，想要进来那简直和登天一样难。

第二个问题就是这个应用的「可发现性」。这问题看似无关紧要，但曾被不少科技媒体提到过。Instagram、The Daily 等热门应用不少都是内容质量上乘但只有在应用里才能看到。想看你朋友的 Instagram 照片？首先你得下载和注册。我非常确定除了我们知道的这些以外，还有很多内容极好的应用只是无法在浏览器上搜到。如此把原创性的内容封锁起来的碎片化网络可不是我们当初想要的。

「应用关联」和「索引」确实有效，但还不够好

现在我们已经知道问题在哪里了；那下一步就是解决方案了。「应用关联」这个词听起来或许有些陌生，但我们其实在日常生活中经常会体验。比如每一次你从一个应用里点击 YouTube 链接，跳转到 YouTube 应用播放视频的时候，这就是「应用关联」。Google，Apple 和 Facebook 都有采用这项技术。应用关联这个功能确实非常实用，它能让用户用最合适的应用打开想看的内容。

目前我们有的还有一个解决方法就是应用索引。Google 和 Apple 都会在用户搜查时给出相关的第三方应用内容，让之前「封印」的内容成为系统的焦点。

这两个功能似乎能完美地解决我们的问题。用户搜索关键词，应用内容就会出现，用户只需点击链接就能进入该应用。

不过你还没看到问题所在。如果这个应用不支持应用关联和索引呢？想要让内容出现在索引结果里，开发者就必须花很大精力在这个功能上，因为本来你的应用内容在网上是根本看不到的。而且如果你想让用户通过 Google 看到你的内容，你必须还要开发应用内容的网页版。作为开发者，这些事真是想想就烦。同时消费者也心烦得慌：如果我没有这个应用呢？如果我就是不想下载这个应用但是我想读这篇文章呢？等等等等。

回想一下，当你打开浏览器查东西的时候，点开链接结果手机自动打开了你的应用商店。大多数用户都很嫌弃这个功能，而且没有人会愿意下载你的应用。

我想打破应用和互联网的这堵「城墙」，我想随意消费和创造应用的内容。那该怎么办呢？

解决办法很简单。只要世界上没有应用这种东西就行了。

Google：「应用串流」功能

Google 的对于「传递」和「可发现性」的解决办法也是基于应用关联和索引。如果开发者做得够好，用户就可以在任何版本的 Google 搜索结果里看到手机专用内容。Google 这个战略很好地促进了手机和网页的联系，因为如今手机应用内容已经越来越脱离网页搜索。但在中国和印度这些手机重于电脑、「Mobile-only」（唯移动）内容至上的地方，像 Google 这样的搜索引擎提供链接又有什么意义？「所有东西都能用 Google 找到」也就失去了吸引力。

大约四个月前，Google 推出了一项非常重要的功能「应用串流」，然而似乎没什么用；没多少人记得 Google 有这个功能。这个功能就如其名，我们无需下载应用，只要点开链接，Google 就会显示应用中你想看到的那段内容。你不用再去特意下载应用，因为 Google 已经在帮你运行了。Google 当年特意收购了初创企业 Agawi，就是为了这项技术。

像 Google 这样结合应用关联和索引以后，之前我们所说的手机应用的「屏障」顿时就烟消云散了。

Apple：On-Demand Resources（按需加载资源）

Google 的高大上的解决方案仍在试验阶段，而 Apple 这边也在往类似的方向研究开发。从 iOS9 开始，iPhone 加入了一项新功能：On-Demand Resources（ODR）。开发者可以将主程序 Bundle 中的非核心资源分离并存放于 App Store 让用户按需下载，以此来减少主程序内容的大小。大部分游戏都引入了 ODR，用户一开始只会下载少量的核心部分，例如图像、视频等等。随着用户升级，iOS 会逐渐为用户下载更多的关卡，同时也会为用户删去已经完成的关卡，保证空间资源。

是不是觉得这听起来和 Google 的一点都不像？但如果 ODR 进一步普及，基础配套够灵活多变，Apple 的这项技术迟早会大幅度普及和进化。ODR 的最终形态很有可能会是 install-free——人们使用应用时再也无需下载。

Web App 的需求度很有可能被低估

既然说到 Apple，容我提一下 Steve Jobs 对第一步 iPhone 的愿景。还记得吗？第一步 iPhone 是个封闭式平台，没有开发环境也没有第三方应用。乔布斯怎么解决的？用 Web App。

使用 Web App 无需下载。这些应用能在浏览器上运行，它们的内容也很容易能在搜索引擎上查到。等等，这个理念不就是我们现在想要的吗？我个人认为很有可能是。

当然我相信 Web App 不过是乔布斯为了转移成本地应用采用的缓兵之计，但我仍然觉得这种应用形式的潜力或许远远超出我们想象。如果 2008 年的时候 Javascript 框架就像今天这样强大，那或许 Web App 也会被淘汰。而我们今天所面对的应用的「传递」和「可发现性」的问题，乔布斯也确实早就预见到了。

没有应用的未来

很多应用串流技术所提供的东西其实都和 Web App 技术十分类似，因此这两者之间的竞争也逐渐缩小了本地和互联网应用之间的距离。但这两者之间最根本性的区别就在于，本地应用的外貌、性能和使用感往往是 Web App 无可比拟的。至于这一点，目前开发者们还没有办法解决。

除此之外，我们真正需要的是应用串流技术的过滤/诊断平台，彻底解决内容传递和可发现性等问题。我们需要的是手机版的 Java applets。总有一天，无论你用的设备是什么操作系统或者品牌，你都能无障碍地运行某个应用并查看它的内容，而其性能和体验就像在运行本地应用一样。开发者能在写完应用后第一时间就发布到所有设备和浏览器上。

Google 开发了应用串流，让我们在手机上无需下载打开所有应用；Apple 开发了 ODR，让开发者们把应用的部件存储在云端。我们可能刚刚迈入一个新的纪元，一个无需下载的时代，一个「网页」和「本地应用」没有界限的时代。手机应用的未来，就是没有应用。

原文来源 :Medium , 本文由 Tech2ipo / 创见 Locin 编译，首发于 TECH2IPO / 创见