写了很多 OS X 和 iOS 相关的产品和技术，很少涉及 Android 的内容，其实 iOS 和 Android 分别源于 OS X 和 Linux 架构，而 OS X 和 Linux 的老祖宗又都是 Unix，打了半天，斗了许久，说开了都是一家人。iOS 与 Android 在发展的过程中也常常相互借鉴和融合，用户则获得了越来越好的用户体验。

Android 领域同样有很多好的技术和创意，有些功能甚至是 iOS 不具备的，比如我们今天要谈到的「应用内搜索」。

应用内搜索其实就是移动互联网搜索，在谈移动互联网搜索之前，我们看看 PC 互联网时代的搜索是怎么干的。1991年8月，大牛蒂姆·伯纳斯-李在 NeXTSTEP 操作系统上创建出了第一个网页浏览器和网页服务器，那一年，你豆蔻年华，我风华正茂，互联网方兴未艾，却在蒂姆的浏览器上开启了征服世界的第一步。互联网在90年代末和21世纪初迅速席卷全球，人们在互联网上创建出了数以亿计的网页和超链接。但是仅仅有网页和超链是不够的，人们需要在浩如烟海的信息中寻找自己需要的内容，于是互联网搜索和 Page Rank 应运而生。

Google 之前，曾经出现了很多通用或专业领域的搜索引擎，但是最终他们都败给了 Google，因为这些引擎没有解决「按照搜索结果的重要性和相关性排序」的关键问题。Google 成功了，因为有互联网搜索的金钥匙 Page Rank。Page Rank 又叫网页级别，是一种搜索引擎根据网页之间相互超链接引用的权重来计算网页重要性和相关度的算法，由 Google 的两位创始人发明。Page Rank 通过网络浩瀚的超链接关系来确定一个网页的等级，Google 把 A 页面中指向 B 页面的链接解释为 A 页面为 B 页面投票，然后根据投票来源和投票目标的等级来计算新的等级。

可以这样理解，如果你认为《MacTalk·人生元编程》是一本靠谱的书，那么书中提到的王小波的作品、吴军的作品、冯唐的作品、Linus 的作品，大体上也不会差到哪去，当你去读这些作品时，又会发现更多好的作品，这就是一种生活中的 Page Rank。当然，永远会存在一些例外，比如我的一位读者，读了一年多的 MacTalk，没有买《MacTalk·人生元编程》，而是直接买了一台 Mac，然后跑过来问我，为神马在 IE 上可以流畅的访问草榴社区，而 Safari 不行。这条神奇的PageRank 路径是：MacTalk —> Mac —> Safari —> 草榴社区。对于这种奇葩的路径，海量的数据样本可以将其稀释掉，所以整体上来讲，Google 搜索结果的排名还是非常精准的，而且没有竞价排名。

到了移动互联网时代，这一切都行不通了，因为我们到了另一个江湖。在这个江湖里，浏览器只是和上百万 App 平级的一个应用，它不再握有互联网入口的唯一金钥匙。浏览器从带头大哥变成了初入江湖的小球，原来的青龙偃月刀变成了小木棍，大家都在拄着木棍摸着石头过河。理论上，每一个 App 都是互联网的入口！在新的江湖里，所有的 App 都在肆意成长，数据继续以几何量级不管不顾的增加，每个 App 都形成了自己的王国，你想要搜索数据，可以，但必须在这个国度里检索。

每个 App 都形成了当年互联网诞生时候的「孤岛网站」，你想检索「多看阅读」里书籍，那么必须打开「多看阅读」App，如果你想查找「知乎」的问答，那么必须打开「知乎」 App。所有的应用都是封闭的，但搜索的需求永远存在，我们期待在一个统一的入口去搜索，当找到一本书的时候，直接进入多看或 Kindle 去阅读。

目前 Apple 在这个领域还无所作为，那么 Google 会不会再次拿到移动互联网搜索的金钥匙呢？我们看看 Google 做了什么。2013 年 12 月，Google 发布了 App Indexing，当你的应用接入了 App Indexing 时，在手机上的 Chrome 里使用 Google 搜索网页时，如果检索到和你的产品相关的内容，就可以看到「Open In App」按钮，点击可以跳转到对应应用的内容页面。App Indexing 虽然已经可以进行移动互联网搜索了，但是这种做法依然延续了 PC 时代的思路，试图通过 Web 把 App 链接起来。对于没有任何网页内容的 App 怎么处理呢？目前还没有答案。

其他厂商，例如 Quixey、Facebook、百度和360等都做了类似的尝试，但是在这个领域走的最深远的，或者实际可用的「应用内搜索」，是豌豆荚。

在我的 T1手机上打开豌豆荚，在搜索框输入「池建强」，可以直接检索到我的书《MacTalk·人生元编程》，点击打开，选择「多看」应用，然后就可以在多看里阅读这本书了。

在搜索框输入「绣春刀」，可以看到更多选项，包括电影、特辑、壁纸、推荐应用等。点击播放，系统会提示你选择播放来源，优酷、腾讯视频还是土豆。选择了之后就可以直接打开相关应用播放了。

另外，豌豆荚根据内容的相关度和优先级对搜素结果进行了排序处理。在搜索框输入「星际穿越」，搜索结果会先出现购票，之后是壁纸等相关内容。搜索的是已经下线的电影，才会出现视频条目。

搜索过程中，如果用户没有安装对应搜索结果的应用，系统会提示用户安装。

这是真正的应用内搜索，和传统的 PC 时代互联网搜索半毛钱关系都没有。

为了更好的了解「应用内搜索」技术，我又去挖了一下「豌豆荚」。最初从创新工场知道了这个公司，那时它还是一个比较纯粹的 App 分发渠道和市场。到了2013年，豌豆荚已经开始涉足「应用内搜索」了。他们在2013年9月正式推出了「视频搜索」功能，用户在豌豆荚搜索到的视频可以直接调用手机上各视频应用播放，是全球首个将「应用内搜索」落地的产品。2014年1月，豌豆荚发布了「移动内容搜索」战略，将「应用内搜索」扩展到视频、电子书、主题、电影票等多个内容类别。

到了今年3月份，豌豆荚正式发布了「应用内搜索技术协议」，开始制定自己的标准，同时兼容 Google 的 App Indexing 协议和 Quixey 的 AppURL。豌豆荚的协议提供了一整套开放的应用内内容检索、收录和调用的标准，开发者通过描述应用内的内容、向豌豆荚提交内容信息以及应用支持外部调用即可完成接入。

具体来说，一个应用想要接入豌豆荚的「应用内搜索」，需要完成以下步骤：

第一步，让自己的 App 支持外部调用。豌豆荚使用 AppURL 指向可以在应用中展现的资源，比如优酷的视频播放可以用 youku://play/video/12345 来表示，多看的电子书描述页可以用 duokan://detail/ebook/22345。点击即可跳转到相关 App 的相关界面。

第二步，描述 App 的内容。豌豆荚使用微数据（Microdata）来描述应用中的每个项目，微数据是 Google、Bing 和 Yahoo 都支持的结构化数据标注方案，符合 HTML5 的标准，同时也可以用 XML 来表示。一本电子书可以通过微数据的 itemtype（类型）和 itemprop（属性）的嵌套进行完整的描述，例如书名、作者、简介、出版日期等等，具体的细节在豌豆荚的开发者中心（ http://developer.wandoujia.com/search ）有详尽的描述。

第三部，开发者提交自己的 AppURL 和 App 内容信息，豌豆荚根据开发者提交的内容分门别类建立索引，最终实现应用内快速检索。

了解了这些，我们就明确了这么几个问题：

1、一个独立的 App 即使没有对应的 Web 页面，一样能够进行应用内搜索

2、开发者可以选择接入和拒绝应用内搜索，类似互联网的 Robots 协议

3、应用内搜索实际上是去豌豆荚的服务器端搜索，并把搜索结果返回到终端，并不是听起来的在「应用内搜索」

抛开商业模式不谈，豌豆荚的协议发布之后，他们已经在移动互联网搜索里有意无意的开始尝试 PC 时代互联网的 Google 的角色。但要想做的更为出色，豌豆荚还需要更大的创新和实践，比如接入的便捷性，搜索的速度，App 的规模，以及对非结构化数据的处理。

无论如何，豌豆荚已经在「应用内搜索」领域迈出了第一步，它让用户在茫茫的移动浪潮中迅速准确的找到自己需要的内容，然后顺畅安全的进行内容消费。相信「应用内搜索」会为移动互联网时代谱写出新的搜索篇章。

说完了 Android，再简单说说 iOS。其实苹果在 OS X 上的「应用内搜索」已经做的非常出色了，基于 Spotlight 技术，你可以快速查找和定位任何文件、资料和程序，无论是结构化还是非结构化。但是这个功能并没有完全移植到 iOS 上。

在 iOS 设备的任一屏幕中单指下滑，就可以使用 iOS 的 Spotlight 功能。你可以对原生应用进行「应用内检索」，例如日历、邮件、提醒事项、备忘录等等，这些是本地化检索，iOS 并没有索引其他 App 的应用内容，也没有提供接入方式和标准。在 iOS 8 里还可以可以对地图、维基百科、iTunes Store、App Store和 iBooks Store 等内容进行线上检索，很可惜的是，目前这些线上搜索功能目前还没有对国内用户开放。

可以看出，目前 iOS 上的 Spotlight 都是在索引自家的东西，但是，App Store 作为最大的移动 App 分发渠道，我相信他们一定会做面向所有 App 的「应用内搜索」。为什么现在没做，可能是因为安全因素，也可能是标准问题，也可能只是在等一个合适的机会罢了，比如 iOS 9……