Chapter 1
第1章
搜索客户端的发展与价值

本章首先介绍我在百度参与或负责的7次与搜索客户端架构优化有关的工作、所解决的问题以及过程中的思考，并从搜索客户端的架构变化来看搜索客户端的价值；然后，从iOS和Android这两个移动操作系统提供的搜索能力来看搜索客户端的价值；最后，通过6款生活中常用的App实现的搜索功能来看搜索客户端的价值。

1.1 从我在百度的工作经历看搜索客户端架构演进

1.1.1 从零构建搜索客户端App

时间回到2011年，我们团队启动了一款新产品的研发——在iOS平台上实现一个搜索App，名为“百度搜索”。很荣幸，我作为研发负责人参与了这个App从无到有的构建过程。

这是我第一次站在实现者的角度来了解搜索业务。产品经理给“百度搜索”的定位为 “有乐趣的、轻量级的搜索客户端” ，那时我对搜索业务的理解还不够透彻，仅限于技术实现的水平。听到产品经理给出的搜索客户端的定位时，还在想搜索服务用浏览器就可以满足，为什么还要再做一个搜索客户端？十几年过去了，这个问题的答案换过好多次，每隔一段时间我都有新的理解。在这个项目中，我学到的基本知识到现在还很受用，一些知识点还在影响着我的工作方法及标准。

百度搜索初版为用户提供了文本和语音两种输入方式，用户点击搜索框或语音按钮后，便可以使用文本或语音输入想要搜索的内容（关于输入的过程，在第4章会有详细介绍）。

用户输入完成后向搜索服务器请求搜索结果，当时的搜索服务器以网页格式返回搜索结果（结果页），点击结果页中的结果所进入的页面（落地页）也是网页格式。在技术实现上，我们使用的是iOS系统提供的浏览内核 ，支持网页的展现及交互。

尽管通过浏览内核就可以满足用户的搜索浏览需求，但是为了提供页面加载切换控制功能，我们在百度搜索视图的底部增加了工具条，以实现最基础的页面浏览控制，如前进、后退、刷新等，这样一个基本的搜索App就实现了。

整个App使用原生（Native）方式实现了主体框架，并通过内置的浏览内核加载网页，实现了搜索客户端的基本功能。初版的搜索客户端在表面上看和浏览器有些相似，如图1-1所示。

此时的百度搜索主要使用系统原生应用程序接口（API）开发，可定制性不强。在这个阶段，研发团队和产品本身都处于成长期，架构设计的重点是构建产品的基础功能。

1.1.2 Ding：优化移动端搜索的高频搜索需求

在2011年，移动设备中各种垂类App还没有像现在这么普及，搜索天气、股票等信息于部分用户而言属于高频需求。为了满足这些高频需求并将对应信息更好地呈现给用户，产品侧提出的方案为：在用户发起搜索时，为用户展现两类结果，一类为原搜索结果页的数据，使用浏览内核加载；一类为自定义的数据，在App内自行解析渲染。我们把实现这种自定义数据的“卡片”称为Ding。Ding可定制数据内容和搜索关键字。Ding在结果页中的展现如图1-2所示。

用户可以把Ding添加到首页，以便打开App时在首页就可以直接看到Ding的卡片。Ding支持自动刷新及手动刷新，点击它还可以看到对应的详情页面。对于时效性较高且高频的搜索需求，通过Ding来获取，可明显降低成本。

在这个阶段不再局限于满足用户的搜索需求，端与云的协同实现了以搜索或Ding的方式获取、展现信息以及与用户进行交互。这个阶段架构设计的重点在于搜索闭环能力的建设，而Ding仅是其中一种实现方式。

搜索业务的本质是帮助用户找到所需信息，Ding满足了用户的一些长尾或高频需求，有了Ding，用户不再需要频繁搜索，就可以直接看到高频需求对应的最新信息。

1.1.3 搜索+浏览双框架：优化移动端搜索过程的体验

搜索业务有一个典型的特征，就是用户搜索一个信息后，会频繁地在结果页和落地页之间切换，直到找到想要的答案。若是没有找到，那么用户就会一直持续这个过程，或者重新描述需求并再次发起搜索，然后重复上述过程。这就意味着结果页需要多次加载，因为浏览内核的缓存能力有限，所以存在重新加载结果页的情况。而页面重新加载时用户需要等待，特别是在移动网络环境下，页面加载慢且出错的概率偏高。

为了解决这个问题，我们将结果页和落地页拆分开，结果页使用原框架——搜索框架进行加载，落地页使用新框架进行加载，这个新框架称为浏览框架。浏览框架没有搜索能力，但是可以快速关闭并回到搜索框架中，以便用户继续浏览结果页。

基于这样的设计，用户在落地页浏览内容时，如果想再查看其他结果，就可以快速切换到结果页。这个过程只需要进行两个框架的切换，因此实现了近零等待，提升了满足搜索需求的效率。搜索和浏览双框架共存的产品形态如图1-3所示。

因为搜索和浏览两个框架是相互独立的，所以技术上可以实现对落地页的预渲染，如果预渲染的准确率比较高，就可以实现点击后立即展现落地页。

1.1.4 搜索结果NA化：优化移动端搜索结果浏览体验

结果页的内容格式是基于网页的，页面的浏览及交互依赖于浏览内核。因为Web生态的开放性，所以在用户搜索和浏览过程中，会有很多站点参与其中，这就要求结果页的内容具有较高的适用性和扩展性，但结果页的实现受限于浏览内核，导致自有搜索客户端的优势不明显。

基于实现成本、可控性及影响面的考虑，对于股票和外卖这类有明确方向的需求（对应特色搜索关键字），我们在百度搜索中进行创新尝试，使用NA自定义内容的扩展方式来增强部分搜索结果的展现，我们称这种扩展方式为 搜索结果NA化 。

股票NA化案例： 使用双层视图的方式扩展，底层是通过搜索框架加载的结果页，上层是通过股票NA的容器加载的股票内容页，两个视图之间可以切换。首次对结果页进行加载时，可以自动调用端能力（客户端扩展的能力，在网页中可调用）展现股票NA的视图，如图1-4所示。

外卖NA化案例： 使用同层视图的方式定制。视图的上半部分为外卖NA视图，下半部分为浏览内核。NA视图内部可上下滑动，当滑动到底部后，框架根据用户的操作把当前活动的视图切换为浏览内核；反之，当前视图为结果页并向上滑动时，可以再切回外卖NA视图，如图1-5所示。

NA化的结果页较传统的网页格式结果页，在性能和用户体验等方面均有明显优势。对于用户来说，视觉效果和流畅度的提升对整体的浏览体验产生了正向影响，这带来的直接变化就是用户的使用时长提升，让用户更有意愿浏览更多的内容，找到所需。

这一阶段的整体的技术方案是在原有结果页框架的基础上进行扩展，在客户端实现网页内容+自定义内容的混合渲染，并通过端与云的协同实现结果页的差异化定制。

1.1.5 搜索异步化：优化搜索核心指标

NA化的搜索结果页在通用性及扩展性方面存在不足。搜索业务的历史积累较多，从面向浏览器服务进化为面向NA化服务，不是做几个NA化的场景这么简单，还需要考虑浏览器的生态。NA化的工作告一个段落后，要做的是优化用户在结果页上的体验，目标是优化页面的加载时长。

仔细研究搜索结果页会发现，用户在搜索不同的关键字时，页面中总会有一些资源是相同的，这些相同的资源与结果页的架构及布局相关，属于基础资源，不受具体的关键字影响。也就是说，如果提前加载这些基础资源，那么在用户发起搜索时，仅需加载与关键字相关的资源，这样就可以减少页面加载时间，实现优化结果页加载时长的目标。

团队的前端人员开发了一套异步搜索框架，提前对结果页的基础资源进行加载、解析、渲染。当有搜索请求时，由异步搜索框架实现对关键字相关资源的加载。但是，应用这套框架的前提是客户端需要提前创建一个浏览内核，预先加载这个异步搜索框架，当有搜索需求时，调用异步框架的接口，发起异步搜索。异步搜索框架有着不同的状态，也会出现异常的情况，当异步框架不可用的时候，客户端则使用原加载方案进行搜索。异步搜索流程如图1-6所示。

这时候的客户端的搜索框架依然采用单浏览内核的方式承载内容（单浏览内核管理框架），在App启动后先加载异步搜索框架。但单浏览内核架构有一个局限，如图1-7所示，异步搜索框架或其他页面只能加载一个。当进入落地页时，浏览内核中加载的是落地页，而不是异步搜索框架，这时用户再次发起搜索就只能采用同步的方式。由此可见，异步搜索的覆盖率没有达到预期。

这个阶段的端与云的协同优化，不仅关注功能的构建，还开始兼顾核心指标的优化。关于指标优化的更多内容，将在第8章和第9章详细介绍。

1.1.6 多容器管理：突破单浏览内核的限制

解决异步搜索覆盖率问题的理想方案，是在页面加载落地页时，创建一个新的浏览内核来加载异步框架。但是这种方案实现成本较高。团队从2018年开始推进搜索NA化，将自有落地页的内容（如视频、地图等）在百度App中改用NA方式实现。然而，现有的单浏览器内核架构无法实现多种不同类型内容的统一接入和管理，这就导致技术实现成本过高且不能保证搜索和浏览体验的统一，需要新的技术架构来支持。

针对上述问题和技术目标，我们实现了多容器管理框架：将线上单浏览内核架构升级为可扩展的多容器共存的架构。多容器管理框架由框架层确定容器化的标准，统一管理容器的生命周期和事件，并根据业务、性能等目标进行合理调度，支持不同容器接入。我们还构建了容器内存/磁盘缓存管理机制，以及预创建、预加载、预渲染等优化策略，在效果体验及资源消耗方面实现了较好的平衡。多容器管理框架核心能力如图1-8所示。

将原网页浏览相关功能升级为网页容器，在多容器管理框架中，可创建多个网页容器。当一个网页容器被使用后，可再创建一个新网页容器来加载异步搜索框架以支持搜索。对比原单浏览内核管理框架，多容器管理框架在异步搜索方面的转换率有明显的提升。

在这个阶段，多容器管理框架像一个简版的操作系统，支持不同类型的容器接入，并统一管理容器的生命周期、状态切换、事件分发、通信等，多容器管理机制作为基础能力支持搜索业务的全流程优化。详细的内容会在第6章介绍。

1.1.7 变体发布：多App复用搜索能力

多容器管理框架上线之后，不同类型的内容可通过较低成本接入，团队的并行研发效率得到了改善。每个容器在各自的模块内独立迭代，相互影响较小。

时间到了2020年，各大厂均在构建自家的App矩阵，以超级App为中心孵化出一批矩阵App，如京东极速版、头条极速版、快手极速版等。这些矩阵App不仅具备主线App的核心能力，甚至还会有一些定制化功能。百度App也需要孵化矩阵App，但矩阵App复用百度App功能模块的成本较高，主要问题在于，矩阵App既需要基于百度App的能力进行裁剪，或者进行差异化定制，又需要周期性地从主线App同步最新的能力。和传统的模块复用方式不同，这种同步主线App的操作是App级的复用，这样的能力需要技术架构层提供支持。

我们当时提出了变体发布的思路，即一个App可以通过工程化的配置实现功能快速裁剪和低影响面的差异化定制，主要实现方式包括技术分层、容器化、插件化、动态化、接口与实现分离等，最终实现业务模块低成本剥离和定制。通过这个思路，矩阵App单次同步主线App功能的耗时下降了70%以上。支持变体发布的App架构如图1-9所示。变体发布相关的内容将在第11章详细介绍。

1.1.8 小结

在2013年，我有幸以架构师的身份参与了百度手机浏览器iOS版的技术研发工作，因为我之前有过手百（手机百度或百度App的简称）的研发经验，所以有同事问我：“俊启，咱们已经有了手百，做浏览器还有意义吗？”

我当时给的答复是“ 手百作为搜索产品的客户端应该更关注搜索全流程的体验，而浏览器以网页浏览的能力作为根本，应该更关注浏览过程的体验 ”。貌似聊到搜索，浏览器是永远绕不开的话题。

在20多年前的个人计算机时代，搜索引擎通常基于Web生态构建，用户不需要专门的搜索类客户端产品，使用浏览器即可免费享受搜索服务——打开浏览器，进入搜索引擎的主页，输入关键字，搜索引擎对关键字进行检索，并以网页的形式返回结果信息。Web生态是一个开放的生态，基于万维网联盟（W3C）标准构建，每个站点再按照其标准建立并生产内容，搜索引擎则基于这些标准进行信息的抓取、分析、分类和建库，并为用户提供信息检索服务。

浏览器是基于W3C标准实现的网页加载、浏览及交互的能力，操作系统一般都会内置浏览器，这相当于用户可以零成本使用搜索服务。在当时的网络环境下，搜索引擎基于Web生态构建，并通过浏览器为用户提供免费的搜索服务，搜索类客户端产品的优势并不明显。

以W3C标准为基础，内容的生产由站点提供，内容的筛选由搜索引擎提供，内容的浏览由浏览器提供，一切看起来这么自然，这完全得益于整个生态是公开、开放、共享的。浏览器可以基于标准实现互联网中网页的加载及浏览能力，在这个基础之上，任何一个公开站点提供的服务都是以网页的形式在浏览器产品中展示的，搜索服务也不例外。在浏览器中进行搜索抓取成为一个重要的需求，2006年左右，IE 7.0和火狐浏览器开始内置搜索引擎服务，用户在浏览器的地址栏中输入关键字就可以直接使用搜索服务。浏览器通常会内置多个搜索引擎，并向用户提供多个搜索引擎选项，让用户自行选择。图1-10为Safari浏览器提供的选择默认搜索引擎的界面。而在搜索客户端中，默认仅有自家的搜索引擎服务。

搜索引擎的核心能力是信息检索，当用户使用浏览器进行搜索时，搜索引擎会通过算法和策略检索出更符合用户需求的结果。用户点击搜索结果中的某个条目从而打开一个第三方的落地页，这个过程的浏览体验与浏览器的产品设计有关，不受搜索引擎控制。落地页中的大部分结果是第三方页面，当用户发现所浏览的内容质量不好时，由于这些结果是由搜索引擎检索得到的，故基于页面打开的先后关系，部分用户会认为是搜索引擎的问题。总的来说就是在浏览器中使用搜索引擎服务，在搜索及浏览体验方面是不可控的，搜索引擎对第三方的内容质量也无法干预，只有搜索服务和自有内容是可控的，具体示例如图1-11中灰色区域所示。

而当搜索引擎的服务有了自建客户端的支持，搜索及浏览的体验就成了可控的，此时第三方的内容质量问题也可以被识别并干预，这时相当于搜索全流程是可控的，如图1-12中的灰色区域所示。

同时，因为有搜索客户端产品的支持，从输入关键字到展现结果页，再到打开落地页，每一步都可以定向优化，也就是说从用户打开客户端到满足搜索需求的整个过程均可进行定制和优化，这拉开了与其他搜索产品的差距。图1-13列出了搜索客户端对搜索业务研发的影响（部分内容在本节前面已有介绍），这些正向影响都得益于搜索客户端。不断地创新及优化端与云的协同，可以为用户提供更好的搜索体验。

总的来说，当使用第三方浏览器进行搜索时，搜索引擎只能通过优化搜索的准确度和检索速度来提升搜索体验，并通过自建落地页来丰富搜索生态中的内容，无法控制搜索全流程中其他节点的体验。而在搜索客户端中，可以实现从用户输入关键字到搜索、浏览第三方或自建内容页的全流程支持，从而实现端云一体化的搜索全流程优化。这将提升用户使用搜索服务的体验，增强用户使用搜索客户端的意愿。相比于浏览器产品中的搜索服务，搜索客户端的优势在于能够提供更好的搜索全流程体验，从而提升用户的满意度和忠诚度。

1.2 移动操作系统级的搜索能力支持

在移动设备中，主流的操作系统为苹果生态的iOS系统和谷歌生态的Android系统，这两个系统都提供了全局的搜索能力，主要针对应用内的内容搜索，默认支持系统级应用中对内容的搜索，也支持对设备中安装的App中的内容进行搜索。

1.2.1 iOS系统搜索能力

iOS系统从2009年（iOS3.0）开始内置全局搜索框（通常称为Spotlight），支持对联系人、应用、短信、地图、文件、邮件等进行搜索。苹果公司在2015年的全球开发者大会（WWDC）上推出了iOS Search API，它重点实现对应用内的内容进行搜索的能力，分为以下3类子API。

1.NSUserActivity

NSUserActivity API用来支持App向全局搜索框（Spotlight）中注册用户之前看过的内容，以便用户在App中对这些内容进行搜索。如图1-14所示，用户在京东App浏览过iPhone 15 Pro相关的商品，在全局搜索框中搜索iPhone 15 Pro时，浏览过的内容就会被展现，点击结果条目则可进入京东App，同时App跳转至对应的页面供用户继续浏览。

2.CoreSpotlight

CoreSpotlight API用来支持App向Spotlight中注册任意内容，使得这些在App中注册的内容在全局搜索框中就可以被搜索到，且这些内容是在本机建立的索引。CoreSpotlight API比较适合搜索App中的内容及用户特有的数据，比如记事本中的内容、社交App中的聊天记录等。

3.Web Markup

调用NSUserActivity API和CoreSpotlight API生成的索引都有一个限制——须先安装App后才能搜索到App中的内容。如果App中的内容大部分都是网页形式，并且用户希望在没有安装App时也能搜索到这些内容，怎么办？苹果为此准备了第三类子API——Web Markup API。开发者调用该API，就表示允许苹果的爬虫抓取自己的网页内容，并且声明了网页内容和应用的关联性，这样就有机会在未安装App的情况下让网页内容出现在全局搜索框的搜索结果中。

1.2.2 Android系统搜索能力

Android系统也是从2009年（Android 1.6）开始支持全局搜索的，当时Android系统中的全局搜索不仅可以搜索网页上的内容，还可以搜索手机中的联系人、文件、短信和邮件等内容，为用户查找手机里的信息提供了快捷入口。具体通过以下两个功能实现。

1.Firebase App Indexing

Google在2013年开始提出将应用像网站一样编入索引（Indexing App just like websites）的思路，相当于在网页中索引App中的内容。这种思路可以增强Google的搜索能力。原来Google只可以检索网页内容，将来还可检索App中的内容。整体的解决方案称为Firebase App Indexing。Firebase App Indexing可以将某个App与Google搜索建立关系。当用户搜索到关联的内容时，如果用户在本机安装了这个App，他们就可以启动这个App，并直接在这个App中跳转到用户正在搜索的内容页。

Firebase App Indexing不仅可以帮助这个App的用户在其设备上查找公开内容，甚至还可以提供查询自动补全功能帮助用户更快速地找到所需内容。如果用户还没有安装这个App，相关查询会在搜索结果中显示这个App的安装提示。

从2022年开始，Google建议使用Android App Links，它支持用户从搜索结果、网站和其他App中直接链接到某App中的特定内容。

2.In Apps

Google在2016年8月推出了搜索本地App中的内容的功能——In Apps，目的也是让用户可以通过系统提供的全局搜索框搜索Android手机App内的内容。In Apps还支持查询联系人、短信等信息，同时支持对Gmail、Spotify、LinkedIn、Facebook等App内容进行检索。

1.2.3 小结

在系统中，全局搜索功能为用户提供了快速查找信息的能力，并且该功能有便捷的触发方式。系统实现的搜索能力与传统网页的搜索能力存在一些差异，系统提供的全局搜索功能主要用于解决App内的信息孤岛问题，通过一系列API支持的可搜索内容，实现对预置App和第三方App内的信息整合。

而App中提供的搜索服务则主要基于搜索引擎，现阶段的搜索能力主要是检索网页和自有内容。由于网页格式是公开的，第三方网页内容可以被抓取。若要检索第三方App中的内容，则需要在内容可抓取、可展现和可交互这三个方面进行定制，缺一不可。

从可抓取的角度来看，小程序或自建内容生态对于传统网页搜索具有重要意义，它们以另一种方式解决了App信息孤岛的问题。事实上，系统中的搜索也需要内容的支持，这也是iOS和Android系统开放搜索相关API，鼓励不同App参与其中的主要原因。虽然两者都在进行信息整合，但实现层级不同，提供的能力也有差异。

从可展现和可交互的角度来看，现阶段搜索业务中的内容格式主要是网页，其展现和交互依赖于浏览内核。若要实现差异化的内容定制，则需要客户端的支持。例如，小程序需要在运行时有框架的支持，而多容器管理框架实际上解决了不同类型内容的展现和交互扩展问题。这些非网页格式的内容并不像网页格式那样通过统一资源定位符（URL）直接在浏览内核中打开，而是采用自定义的指令格式。因此，指令的解析需要单独定制，也需要客户端的支持。

1.3 App中的搜索功能建设

在移动设备中，由于很多内容提供方自建了App，且当用户有明确的场景需求时更倾向于使用对应的App搜索及浏览内容，这导致一些搜索流量被分走。针对这个问题，我认为作为搜索侧的高阶研发工程师，需要清楚搜索客户端在搜索生态中的定位，从而把握好技术方向，通过端云协同的方式更好地支持搜索业务，实现搜索业务的差异化。

我们应该以更广阔的视角来看待搜索业务相关的技术，而不能局限于搜索App本身。实际上，在许多App中搜索也是关键能力。为了深入了解不同App中的搜索能力，我挑选了6个生活中常用的App进行使用，覆盖了与搜索全流程紧密相关的需求输入、结果页和落地页3个场景。最终我得出的结论是：搜索是一个通用能力，不应仅限于传统的搜索引擎客户端。任何一个App都可能需要搜索功能，而不同的App实现的搜索能力也有所不同。下面是对几种不同类型App的搜索功能进行介绍。

1.3.1 京东App中的搜索功能

京东App一直都有搜索功能，只不过初期的版本只支持文本输入，主要用于搜索商品。后来的版本除支持文本输入外，还支持语音及图像输入，不仅可以搜索商品、订单，还可以搜索垂类的内容，比如搜索京东超市、京东电器等。京东App中与搜索功能相关的3个场景如图1-15所示。

❑ 需求输入： 支持文本、语音、图像等输入方式。在采用文本输入时，支持搜索建议（根据用户输入的文字推荐可能搜索的内容）功能，该功能不仅有相近字的联想，还有精细的分类推荐，比如输入“鼠标”时，有品牌、无线、游戏电竞专用等推荐。

❑ 结果页： 支持单列或双列的浏览方式，用户可以根据需要进行选择，搜索的内容支持二次筛选及排序，不同的关键字对应的筛选条件也有所不同。如果搜索的关键字为品牌，结果页中还有品牌京东自营旗舰店的入口。

❑ 落地页： 落地页中有商品的详细介绍，包括商品的图片、视频、价格、评价、好评率、关联推荐、购买方式（如加入购物车、直接购买）等。落地页中没有搜索框，基本上使用同一类模板展现内容。

1.3.2 微信App中的搜索功能

微信App从1.1版本开始支持搜索功能，包括对通讯录和会话列表的搜索，在后来的版本中，还支持对小程序、公众号、视频号等内容进行搜索。微信App中与搜索功能相关的3个场景如图1-16所示。

❑ 需求输入： 输入方式主要为文本、语音（语音转文本），在输入过程中可直接显示输入结果。

❑ 结果页： 以列表的形式展现，在搜索页面中点击“取消”可以回到首页。微信支持对联系人、群聊、聊天记录、收藏、视频号、朋友圈、公众号、小程序等进行搜索。

❑ 落地页： 微信的落地页展现形式与内容有关，不同内容的展现与非搜索时（正常浏览时）是一样的，只是在搜索状态下点击查看的落地页在返回时会回到搜索结果页。

1.3.3 快手App中的搜索功能

快手App的早期版本是没有搜索功能的，后来的版本支持通过文本、语音和拍照搜索商品。快手App中与搜索功能相关的3个场景如图1-17所示。

❑ 需求输入 ：输入方式主要为文本、语音，图片搜索仅提供了搜索商品的能力。在文本输入过程中会提供搜索建议，快手App中的搜索建议不区分类型，点击搜索建议后就可以发起搜索。

❑ 结果页 ：结果页包含综合、商品、直播、用户、视频、图片等多种内容，还支持针对发布时间、作品时长、发布城市进行筛选。结果页展现形式为双列图片流，包括视频、商品、搜索推荐等多种结果在其中展示。

❑ 落地页 ：落地页对于不同类型的内容，展现形式和交互形态均有不同，视频落地页没有强化浏览历史，用户浏览的层级较浅，上下滑动就可以切换内容。商品落地页重点展现商品详情及相关商品推荐。

1.3.4 有道词典App中的搜索功能

有道词典App早期的版本只支持文本搜索，现在已经支持在首页、直播、频道等分类中进行搜索，并且支持语音输入和拍图搜索。有道词典App中与搜索功能相关的3个场景如图1-18所示。

❑ 需求输入 ：支持文本、语音、拍图等输入方式。文本输入过程中有搜索建议，拍图翻译支持涂抹功能。有道词典还支持词典笔输入，前提是绑定有道词典笔。

❑ 结果页 ：在有道词典App中，大部分内容都在结果页中展现，包括音标、发音，选择单词后还有不同词态翻译、网络释义、双语例句、专业解释、同义词、同根词、短语、百科等。对于拍照翻译，有道词典App会通过光学字符识别（OCR）技术提取照片中文字，并展示翻译内容。

❑ 落地页 ：点击广告、百科、网络释义等都可以直接进入落地页，落地页内容较简洁。

1.3.5 招商银行App中的搜索功能

招商银行App的搜索，更关注对具体业务、功能和服务介绍进行检索，目的是方便用户更好地使用招商银行App。招商银行App中与搜索功能相关的3个场景如图1-19所示。

❑ 需求输入 ：以文本输入方式为主，输入过程中没有搜索建议，直接显示搜索结果。

❑ 结果页 ：以列表的形式展现，点击取消可以返回首页。结果页中包含App功能、产品、社区、生活等。在结果页底部提供“ 提问小招 ”按钮，点击可进入客服页面。

❑ 落地页 ：不同落地页提供的功能不同，页面组织形式也有所不同。招商银行App的部分落地页需要先登录，在打开此类落地页时要先判断用户是否登录，若没有则执行登录步骤，登录成功后再打开该落地页。

1.3.6 夸克浏览器App中的搜索功能

浏览器是最贴近搜索客户端的产品，夸克是为数不多的有自建搜索引擎的浏览器产品。夸克浏览器App一直都有搜索功能，可使用自家的搜索引擎或合作的搜索引擎。夸克浏览器App中与搜索功能相关的3个场景如图1-20所示。

❑ 需求输入 ：支持文本、语音、图像等输入方式，在使用文本输入时会提供辅助网址输入功能，同时搜索建议与搜索框的布局方式与其他App不同。对于图像的输入，主要为拍照及照片选择两种形式。

❑ 结果页 ：和传统的浏览器一样，结果页主要为网页格式，区别在于夸克浏览器App的搜索框在结果页的底部，这样的设计可以使用户使用大屏设备时更容易操作。作为浏览器产品，夸克浏览器App支持更换搜索引擎，包括夸克、百度、谷歌、必应等搜索引擎。结果页的内容与用户选择的搜索引擎有关。

❑ 落地页 ：夸克浏览器App的落地页主要为网页形式，用浏览内核承载，同时实现了网页智能保护、智能预加载、智能无图等功能。

1.3.7 小结

通过对比多款App中的搜索功能我们发现，每个App的搜索流程基本都是一样的，但在不同场景内的实现细节均有不同。

❑ 需求输入 ：主要为文本、语音、图像及自定义的形式，有关输入过程中客户端的并行化响应及技术实现的内容将在第4章进行介绍。

❑ 结果页 ：结果页的内容主要是网页或自定义的格式，网页格式的内容主要依赖于浏览内核，网页功能扩展的实现在第5章进行介绍。搜索结果依赖于检索的能力，检索的内容与产品的定位有关，关于检索服务端相关的技术实现在第3章进行介绍。

❑ 落地页 ：落地页的内容主要是网页或自定义的格式，根据内容不同可以定制不同的能力扩展，实现搜索浏览过程的需求闭环。与页面加载、展现及交互过程优化相关的内容，在第6～9章均有介绍。

❑ 其他 ：例如登录、支付、理财、预加载、无图等功能是为了满足App的需要而构建的，这些功能要在客户端逐一实现，并支持App业务流程中的每个环节，甚至是可被搜索到及直接使用的。

为什么这些App都要构建搜索能力呢？答案只有一个——搜索是帮助用户找到所需信息的最高效的方法。当App中的信息量达到一定的量级时，如果没有提供搜索功能，那么用户找到所需信息的成本将会非常高，甚至可能无法实现。所以，随着App中信息量的不断增加，会有越来越多的App构建搜索能力，以实现帮助用户快速找到所需的目标。在用户有明确需求的场景中，相比于为用户推荐内容的功能，搜索功能显然是更合适的。从技术的角度来看，构建搜索能力的关键是理解用户的需求，产品中要有内容可供搜索，搜索到的内容要能正常展现及交互，这些过程都离不开客户端的支持。有了搜索客户端，还能够根据业务的需要来实现搜索能力的差异化定制。