搜索架构之道:App中的搜索系统设计与优化实践
上QQ阅读APP看本书,新人免费读10天
设备和账号都新为新人

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

1.1.1 从零构建搜索客户端App

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

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

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

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

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

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

注意

Native App,简写为NA,即原生应用程序,是某一个移动平台(比如iOS或Android)所特有的,使用相应平台支持的开发工具和语言(比如iOS平台支持Xcode、Objective-C、Swift)开发的App。同一个App,需要开发者针对不同的系统平台开发不同的版本。

图1-1 初版的搜索客户端与浏览器样式对比

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