应用启示录—呼唤内置应用搜索引擎的出现

iPhone和iPad的应用超过50万个，Android上的应用超过30万，其他平台上还有成千上万（参见
移动应用总量突破百万）。平均每个用户手机上的应用数量为65（来源：
Flurry）。相信各位看官的可能比这还要多。

甚至还有专门成立用解决“应用发现”问题的公司—由于供应商自己的应用商店所提供的应用搜索机制手段有限，这些公司就冒出来填补其空白。应用开发者当然受益匪浅，因为自己的作品只是在应用汪洋大海当中的沧海一粟，很难被发现。这些产品最后的结果是给消费者提供诸如此类的工具：“找出新的酷应用”，“找出朋友喜欢的应用”或者“找出做X事的最佳应用”。

这些努力，应用开发者感激，最终用户乐意，尽管如此，它们还是没有办法解决一个真正的问题：找出你已经安装进自己手机的应用。

一个有趣的事实是，在平均应用安装数量方面，非科学调查的结论与分析机构的精确数据大抵一致，65个。

但是，实际使用的究竟有多少呢？根据Flurry的数据，
每周消费者平均仅使用
15
个应用
。这意味着安装在手机上的应用大部分都只是偶尔使用。消遣的时候才会玩游戏，跟朋友吃饭的时候才会用到小费计算器或者分账器，开始节食的时候才会用到卡路里计数器，车库拍卖查找器，照片上传工具，还有那些孩子们都喜欢的游戏……要是再算上商业工具的话，还可以数得出多少来？

问题就在这里。

除非你的应用起的名字刚好合适，并针对搜索进行了优化，内置的应用搜索机制是严重缺乏的，起码iPhone和Android那两大平台是这样的，本文将会讨论这一问题。

举个例子，在我的iPhone上做个测试，在iPhone的Spotlight Search输入框上敲“deal（交易）”，你可以搜不到
Groupon或者
LivingSocial。Android的也不行—你得敲应用的名字。

不过，古怪的是，事情并非总是如此。输入“recipes（食谱）” 就会出现
Epicurious。但是Android上就不行。在iPhone上敲“deals”，会出
BiteHunter。在iPhone上输入“Shopping”就会得到
FastMall和
Zoomingo，但是却没有
Target或者
Best Buy。在Android上的测试类似，应用只能按名字搜索，而非功能。

怎么会发生这样的事？

在利用iOS内置搜索能力方面，似乎有的应用开发者比其他的开发者更加擅长。也就是说，用关键字填充自己的应用名字。（比如说，Epicurious的全名叫做“Epicurious Recipes & Shopping List”）

这是个问题，因为搜索是寻找应用的最快方式。毕竟，Android设计的初衷就是隐藏大部分的应用，只把你喜欢的几个放在屏幕上。与此同时，iOS则是用文件夹来处理应用过载问题的……丑陋的文件夹，极不优雅的处理方式。

这些解决方案与有效的搜索机制相比显得苍白无力。但是即便现在是以关键字为基础的搜索，由于搜索结果是按照字母排列的，在将来也不见得那么有用。

我的意思是说，真的，按字母排列搜索结果！想象一下，如果Google是这么排列web的搜索的结果的话！当然应用商店的生态系统规模很难跟web相提并论。但是它还在一直疯长，不断壮大。

与此同时，用户还将遭遇应用的另一个停止点—一道心理上的鸿沟，不仅仅是手机存储空间的限制，还由于自己的心智能力有限，没办法处理安装了500至1000个应用的手机。

因此这里我们提出一个疯狂的主意：让我们的设备拥有一个真正的搜索引擎，这个引擎的能力起码要跟应用商店的引擎一样强大，如果不是更好的话。应用应当经过关键字优化，由数十种信号进行排名和评价。内置应用搜索引擎应该知道你都安装了哪些应用，使用的频率如何，安装多久了，什么时候买的，排名情况如何，你对其的评价又如何，你的朋友有谁在用它，这款应用能够做什么，不能做什么。

在iPone上，Siri也许有朝一日会成为引擎—我们“再现”已安装应用的方式也许是通过开发者跟Siri的集成实现的。你问一个问题，然后Siri就打开相关应用。不过Siri乌托邦还有很长一段路要走—它现在还只是alpha版的产品。

与此同时，我们不应该下载每一个喜欢的应用，相反，我们应该提供一个快速访问这些应用的手段，不管其是否在我们的设备上即可。iCloud是实现这一点的一个很好的起步—你喜爱的应用可以存储在云端，并通过Spotlight Search浮出水面。而对于Google来说，这个搜索巨头当然可以做出更好引擎供我们搜索手机上的应用。

时不我待。现在我们的手机上的应用已经非常拥挤了，副作用已经开始出现。如果内置应用搜索还得不到改善，没有人会想要试一下你的新应用的，“非常感谢，但是我的应用已经够多了”。

若如此，那可真是一件相当悲哀的事情。

Via：
TC