下载掌阅APP，畅读海量书库
立即打开
第1章介绍了搜索客户端的技术架构的演进、操作系统和几个典型App中搜索能力的演进，同时也说明了搜索客户端的价值。
本章以文本输入搜索为例，介绍搜索客户端的完整工作流程，同时对这个流程中的不同节点所使用的技术进行说明，掌握了这些技术，可以更好地理解后续内容。
上一章讲述了6个App与搜索功能相关的需求输入、结果页、落地页3个场景。本节综合搜索客户端、系统搜索及各垂类App中的搜索相关能力，对搜索全流程相关的3个核心场景的能力进行梳理，如图2-1所示。
❑ 需求输入场景 ：重点是让用户正确表达搜索需求。客户端通常包含文本、语音、图像这3种输入方式，我们还可以通过硬件设备对需求输入进行扩展，硬件设备主要分为有线和无线两种类型。
❑ 结果页场景 ：重点是让用户准确找到想要的内容。结果页通常是网页格式，在自有客户端的支持下，也可以使用非网页的格式或网页+非网页的复合格式，甚至在客户端中可以对结果页进行业务扩展。
❑ 落地页场景 ：重点是让用户看到更多与结果相关的内容。落地页主要是网页格式，在自有客户端的支持下，也可使用非网页的格式或网页+非网页的复合格式，同样，在客户端中也可以对落地页进行业务扩展。
图2-1 搜索业务核心场景的流程及关系
按照上述划分，搜索客户端应该支持对这3个场景的搜索相关功能进行构建及优化。在设计及实现客户端功能时，需要考虑上述3个场景之间的关系，以实现场景间的切换。常见的搜索过程的场景切换如：需求输入→结果页→落地页→结果页→落地页……直到用户找到所需或者输入新的搜索关键字。
从上面的描述来看，结果页和落地页场景所实现的能力很相近，为什么还要把这两个页面单独拆分出来？主要有以下5个原因。
❑ 从定义的角度来讲： 结果页是搜索结果页面的一种统称，落地页是点击搜索结果进入的页面的统称。
❑ 从分发的角度来讲： 由结果页分发落地页，通常在搜索结果页中，用户点击不同的结果查看会进入不同的落地页。
❑ 从业务的角度来讲： 搜索是一个业务，用户发起搜索后为用户展现结果页。点击结果进入的某个落地页，也可能是一个业务，比如地图、小说、视频和邮箱等，一些客户端是先有了具体业务，再有的搜索能力。
❑ 从扩展的角度来讲： 结果页和落地页支持的功能不同，实现的逻辑也有所不同。结果页中的功能扩展主要关注为用户提供更好的搜索体验，而落地页中的功能扩展则关注为用户提供更好的浏览体验，以及为用户在浏览过程中产生的新的搜索需求提供更好的支持。
❑ 从服务的角度来讲： 结果页对接的服务与落地页不同，结果页对接的是自有服务，而落地页对接的是自有服务或非自有服务。服务不同，可协同优化的方案也不同。
基于上述5个原因，将结果页和落地页拆分之后，流程变化可清晰描述，场景边界可明确管理，功能扩展可精准实施。
在需求输入场景中，客户端为用户提供的输入方式为文本、语音及图像等，本节以文本输入为例介绍搜索功能在需求输入场景中的主要流程和技术实现，语音和图像输入的相关内容在本书第4章介绍。
典型的文本输入搜索过程如图2-2所示，该过程主要分为输入搜索关键字、展现搜索建议、点击搜索按钮三个步骤，其中输入搜索关键字和点击搜索按钮的动作由用户触发，展现搜索建议为搜索客户端提供的辅助输入功能，下面对典型的文本输入过程进行介绍。
图2-2 典型的文本输入搜索过程
在搜索App中都会有搜索框，支持用户输入搜索关键字。搜索框可使用系统的文本输入控件实现，这类控件在不同的平台中都有，比如iOS平台中的UITextField。用户在点击搜索框后，软键盘弹出，这时搜索框变为输入态，用户可以输入想要搜索的文本内容。
在用户输入文本的过程中，客户端“监听”输入内容的变化，向服务端（服务器）实时提交输入的关键字信息，并由服务端生成用户可能会搜索的关键字列表（搜索建议），客户端在收到服务端的搜索建议后会展现给用户。如图2-3所示，用户输入“刘德”，客户端向服务端提交获取“刘德”搜索建议的请求，服务端返回一组搜索建议信息如“刘德华”“刘德凯”“刘德一”……当用户选中“刘德华”时，就进入了结果页场景，此时客户端向服务端提交搜索“刘德华”的请求，加载结果页。
在这个阶段，除了业务流程的逻辑实现，还需要使用一些基础的技术来完成功能的构建，如多线程技术、网络数据通信技术、数据处理技术、展现技术和交互技术等。
多线程技术是一种在计算机程序中同时运行多个任务的技术，旨在提高程序的并发性和效率。如在需求输入阶段，用户输入的过程和搜索建议的获取过程分别由两个线程并行执行，目的是两个任务在执行的过程中互不影响。
用户输入的过程与UI交互相关，一般来讲，UI相关的操作都是在主线程中完成的，而要想网络请求相关的过程与用户输入的过程并行处理、不相互等待，这时就需要使用多线程技术。
图2-3 搜索建议示例
在单核CPU上实现同个时间段运行多个线程，操作系统会将小的时间片分配给每一个线程，这样就能够让用户感觉到有多个任务在同时进行，避免任务之间相互等待。如果CPU是多核的，那么多线程就可以真正以并发方式执行，从而减少完成某项操作所需要的总时间。关于并行化的相关内容将在第4章介绍。
客户端与服务端的通信通常使用超文本传输协议（HTTP）实现，HTTP是一个用于传输超媒体文档（例如HTML）的应用层协议，是为网页浏览器与网页服务器之间的通信而设计的，也可以用于其他类型的请求。
iOS及Android系统都提供了用HTTP封装的API，其中，iOS系统中提供了NSURL Request、NSURLSession，Android系统提供了HttpURLConnection。
1.HTTP请求工作流程
接下来介绍HTTP请求的工作流程。在实际使用过程中，系统提供API的设计不同，使用方式也不同，网络请求的几个关键步骤如下。
1） 参数设定： 根据业务的需要进行HTTP请求的参数设定，如设定请求的URL、端口号、请求方式（GET、POST）、Header、Cookie、Body等信息。
2） 请求发送： 将客户端设定的参数以二进制数据流的方式传给服务端。
3） 客户端接收服务端的响应： 服务端即服务器接收到客户端的请求后，会向客户端返回响应，包括响应状态码、HTTP Header等信息。常见的状态码如下。
❑1××：信息响应，表示请求已收到，正在处理。
❑2××：成功响应，表示请求已成功完成。
❑3××：重定向，表示请求需要重定向到其他资源。
❑4××：客户端错误，表示客户端请求存在错误。
❑5××：服务端即服务器错误，表示服务端即服务器无法完成请求。
4） 客户端接收服务端即服务器返回数据： 如果响应数据量比较大，服务端即服务器可能会分多次发送数据，客户端需要多次接收通知。
5）客户端接收本次通信完成（或失败）通知的时候，相当于本次网络请求结束。
上述流程仅是一般情况下的HTTP请求工作流程，实际应用中可能会因网络环境、服务器配置等因素影响而有所不同。在设计和使用网络API时，需要根据具体需求和场景进行调整和优化。
2.HTTP请求参数介绍
在HTTP网络请求发出之前，需要对相关的参数进行设定，如请求的URL、端口号、请求方式、Header、Cookie、Body等。本节简单介绍URL、请求方式和Header。
1） URL ：统一资源标识符，又称统一资源定位器、定位地址、URL地址，俗称网页地址或直接简称网址，是因特网上标准的资源地址，如同网络上的门牌。
2） 请求方式 ：常用的请求方式为GET和POST，本节不作详细介绍。
3） Header ：对于客户端发出的请求，经常使用的Header是Referer和User-Agent。
❑ Referer ：Referer请求头包含了当前请求页面的来源页面的地址，即表示当前页面是通过此来源页面里的链接进入的。服务端一般使用Referer请求头识别访问来源，有时以此进行统计分析、日志记录以及缓存优化等。
❑ User-Agent（UA） ：请求头中包含的一组字符串，用于让网络协议的对端来识别发起请求的用户代理软件的应用类型、操作系统、软件开发商以及版本号，比如用来识别是Android平台还是iOS平台。
客户端通过网络通信把用户当前输入的关键字上报到服务端，并在接到来自服务端的搜索建议后对建议进行解析及展现。在这个过程中，客户端和服务端需要对网络通信数据进行结构化的封装、压缩、加解密及数据校验等，以实现安全有效的数据传输。
1.数据封装
常用的数据封装及解析格式有可扩展标记语言（XML）、JavaScript对象表示法（JSON）及协议缓冲区（PB），在日常工作中使用JSON的情况相对多一些。
1） XML （eXtensible Markup Language）：标准通用标记语言的子集，可以用来标记数据、定义数据类型，是一种允许用户对自己的标记语言进行定义的源语言，具有可扩展性良好、内容与形式分离、遵循严格的语法要求、保值性良好等优点。
2） JSON （JavaScript Object Notation）：一种轻量级的数据交换格式，具有简洁和清晰的层次结构，这使得它成为理想的数据交换语言，不仅易于相关人员阅读和编写，还易于机器解析和生成，并且能够有效地提升网络传输效率。
3） PB （Protocol Buffers）：Google公司开发的一种数据交换的格式，它独立于具体的语言和平台。并支持多种语言，如Java、C#、C++、Go和Python等，每一种语言都有相应的编译器以及库文件。相较于XML和JSON，PB序列化之后的数据是二进制的，不可读，更适合大数据量的传输。
这3种数据封装格式，iOS及Android均有支持。在实际的应用过程中，可参考数据传输场景、服务端支持情况等信息来确定使用哪一种。
2.数据压缩
数据压缩的目的是减少传输过程中的数据量，从而间接地减少网络传输时间。数据压缩常用gzip，gzip是常见的数据压缩及解压缩算法，在HTTP中也有使用，同时它还是UNIX系统默认的文件压缩格式。
3.数据加解密
加解密算法分为对称及非对称两类，常用的为Base64及RSA算法。
1） Base64： 一种对称的加解密算法，所谓对称，就是指该算法加密和解密所用的密钥是相同的，Base64基于64个可打印字符来表示二进制数据，由于64=2 6 ，所以可打印字符每6位（比特）为一个描述单元；Base64通常用于文本数据处理的场合，用来表示或存储数据，常见于页面中的二进制数据描述；为了保证所输出的编码为可读字符，Base64制定了一个编码表。编码表有64个字符，这也是Base64名称的由来；Base64编码把原来每3个8位的字节（3×8=24）转化为4个6位的字节（4×6=24），字节前两位均为0，常用的编码表如表2-1所示；对于私有内容的加解密，也可以自建编码表来实现。
表2-1 Base64编码表
2） RSA： 一种非对称加解密算法，所谓非对称，就是指该算法需要一对密钥，使用其中一个加密，则需要用另一个才能解密；基于这个特性，RSA常用于客户端与服务端的数据传输，在客户端及服务端分别存放加密及解密的密钥，如图2-4所示， 客户端发送数据时使用公钥对数据加密 ，然后通过网络传输加密后的数据， 服务端收到数据后使用私钥对数据解密 ，这样即便加密的公钥被公开了，数据传输的保密性也是有保障的。
图2-4 RSA发送数据加解密过程
4.数据校验
数据校验常用的算法为MD5。MD5是一种广泛使用的密码散列函数，可以产生一个128位（16字节）的散列值，用于确保被传输信息的完整性和一致性。它常用于数据完整性的校验，例如在客户端与服务器的数据传输过程中，先生成数据的MD5值，然后将数据及其MD5值一同传输。服务端在收到数据后，对其进行MD5计算，并将结果与收到的MD5值进行比较，以确定数据是否丢失或被篡改。
5.展现及交互
客户端收到服务端返回的搜索建议数据后，使用UI控件对搜索建议内容进行展现，常见的UI控件如TableView、ConllectionView等都支持列表的展现形式。系统一般会提供很多的UI控件供开发者使用，如按钮、文本框、进度条、文本绘制、图片绘制等，这些控件通常在App中展现内容及或提供App与用户交互的能力，是离用户最近的一层。
以文本搜索为例，当用户输入关键字确认搜索后，客户端将加载与关键字对应的结果页并将其展现给用户。也就是说，客户端需要具备展现结果页的能力，还需要支持用户浏览及选择某个结果条目进入落地页。
典型的结果页加载及浏览过程主要分为4个步骤，包括记录历史，拼装搜索关键字，加载结果页和浏览结果页。其中前3个步骤在App中实现，最后一个步骤由用户触发。
如图2-5所示，用户发起搜索时，客户端会保存搜索记录即记录历史，并将搜索关键字拼装到URL中传给搜索服务器。之后客户端切换到结果页场景，创建浏览内核及结果页相关功能模块，调用浏览内核向服务器请求加载携带搜索关键字的URL。服务器接收到请求后，提取URL中的关键字进行搜索，并生成结果页及相关资源。然后，服务器会将结果页主文档返回给客户端加载。浏览内核收到服务器的响应后，解析结果页内容。
如图2-6所示，通常情况下，结果页需要加载的资源可能有多个，因此浏览内核会依次向服务器提交请求，下载相关资源，并在下载完成后渲染结果页，直到整个页面加载完成。页面加载完成后，用户可通过上下滑动来浏览页面。当用户点击页面中的结果条目时，会加载落地页。
图2-5 结果页加载及浏览过程示例
图2-6 结果页相关资源加载
在页面加载过程中，有时会出现各种异常，这些异常可能源于网络问题或服务器、客户端传递的参数格式错误等。因此，需要在客户端对这些异常进行处理。
部分浏览器会在页面加载过程中显示进度条，提示用户当前页面加载的进度，让用户对页面当前加载状态有所感知。这些状态通常来自浏览内核API的通知，也可主动调用API获取。一般来说，系统提供的原生API具备获取基本页面状态和事件通知的能力。关于浏览内核的使用及扩展，将在第5章介绍。
在搜索过程中，记录用户输入的关键字并保存，以便下次用户搜索时进行选择。实现这一功能的主要技术是数据的持久存储和持久化存取。持久存储用于存储App中需要长期依赖的数据，持久化存取则涉及在需要时从存储设备中恢复数据。由于不同设备的存储特性不同，对于文件的存取操作可以抽象地分为三部分：存储路径、存储数据的方式和存储数据的格式。
❑存储路径是指每个数据存储在设备中的文件路径，在移动设备中，iOS和Android平台采用的都是沙盒机制，App内部对文件的读取也有权限管理，不同文件夹的权限不同，包括是否可以修改、创建、读取等。在具体的业务存储实现中，建议采用一个业务一个目录的方式进行管理，一个文件只存储一类内容。同时，文件及目录的命名也要有统一的规范，这样可以有效避免冲突并实现存储自治。
❑存储数据的方式是指将数据以何种方式存储在文件中，基本操作为文件的读取和写入。平台API或第三方开源库都提供了对数据存储方式的封装，例如Plist、NSUserDefaults、SQLite3、CoreData等。选择使用这些工具时，需要考虑要存储的数据量、数据的更新频率、更新方式（全量、增量、替换等）以及数据的格式等。
❑存储数据的格式是指持久化存取的文件数据格式。根据业务需要，对所依赖的数据项进行存储格式的封装，其中包括对数据的操作和存储更新相关能力的封装。在研发过程中，需要关注数据升级带来的变化以及数据异常对App的影响。前面提到的数据加解密和数据校验这些技术在持久化存取过程中也有重要应用。
在不同搜索客户端，URL携带搜索关键字的实现有所不同。这一节以浏览器携带搜索关键字为例，说明用户提交的搜索关键字是如何传送给搜索引擎的。
表2-2是不同的搜索引擎在Safari浏览器中搜索“刘俊启”这个搜索关键字时，浏览器发出的网络请求。
表2-2 不同搜索引擎在Safari浏览器中搜索“刘俊启”时发出的网络请求
为什么使用浏览器验证呢？因为搜索服务在浏览器中是使用业界公开的标准传递关键字信息的，其次从URL的定义标准来讲，同一个URL在不同的浏览器中打开，用户看到的内容应该是一致的（服务端差异化定制部分或与用户私人信息相关的部分除外）。若是相同的URL在不同的浏览器中所展现的内容不一样，说明网站对于不同的浏览器进行了差异化定制。
在使用Safari浏览器做不同的搜索引擎对比时，可以发现从地址栏中复制出来的URL中存在中文，直接把这种带中文的URL复制到浏览器中，页面也可以正常打开。这有些不符合人们对URL的常规认知。因此，我最后在浏览器的网络层对真正发出的网络请求进行了确认，发现所有网络请求都是经过URL编码处理的。至少从表面上来看，Safari浏览器对特殊字符进行了自动兼容。
而在Chrome浏览器中，通过使用上面的搜索引擎进行搜索，再从地址栏复制URL到浏览器中，可以发现它们都是经过URL编码的，其处理逻辑和Safari浏览器不太一样，但网络请求的URL是一样的。
在搜索客户端中，可能会遇到相同的问题。无论是用户发起的关键字搜索还是直接输入URL，当输入的内容不符合网络通信的标准时，客户端需要主动进行编码，以符合标准。用户输入关键字后，客户端向服务端发送搜索请求，这一动作会将关键字作为URL参数的一部分上传到服务端。这时，需要对URL中的特殊字符进行编码，否则即使在地址栏看起来正常，在实际的网络请求中也会出现异常。
通过上述分析可以发现，每个搜索引擎中URL携带关键字的方式都有所不同。以表2-2所示的内容为例，sogou.com中的关键字的key是query，而so.com中的关键字的key是q。如果你对此感兴趣，可以使用表中带有中文的URL进行一次URL编码，或者在不同的浏览器中尝试不同的搜索引擎，观察它们如何在URL中描述关键字。
众所周知，用户可以直接在浏览器中使用搜索业务，这是因为搜索业务都是基于网页格式承载的。无论是搜索结果还是点击结果后进入的落地页，都以网页的形式呈现。这样一来，整个搜索过程中用户的浏览、交互等需求都可以在浏览器中得到有效满足。而在搜索App中，结果页既可以是网页格式，也可以是非网页或网页+非网页的复合格式。
❑ 网页格式结果页： 搜索引擎展示内容和与用户进行交互的主要数据格式。对于搜索客户端而言，需要在客户端构建网页浏览能力，以支持网页的加载，其中包括结果页和落地页。只要客户端支持网页浏览能力，搜索的核心流程就可以运行。此时搜索框加上工具条（支持前进、后退、刷新等页面操作能力）就构成了搜索客户端的最小集合。
❑ 非网页格式结果页： 使用自定义的数据格式来传输结果页的数据内容，在客户端进行解析、渲染和交互。与网页格式相比，这种格式可以提供更大的定制空间，从而在能力、效率和效果等方面带来变化，为用户提供更好的搜索体验。然而，这种格式需要更高的开发和维护成本。服务端需要同时支持原浏览器的网页格式数据和自定义格式数据，否则以浏览器作为客户端的用户将无法使用搜索服务。
❑ 复合格式结果页： 以网页格式和非网页格式承载结果页的内容。通过技术手段将两类格式的内容组合在同一个页面，以实现复合格式的结果页，复合格式同样需要服务端的支持，同时还需要在客户端增加额外的逻辑来处理网页格式和自定义格式两类内容的传输、解析和渲染等，以支持它们在结果页中进行交互和切换。
为什么要关注数据格式呢？因为传统的搜索结果页是基于网页格式承载的，网页提供的能力受到浏览内核的限制，很难实现差异化定制。而非网页格式数据的传输、解析、渲染及交互是可以通过系统提供的原生API实现的，API的能力则受到操作系统的限制，定制成本低。从使用的能力层级来看，原生API提供的能力超过浏览内核提供的能力。因此，非网页的数据格式可以使用更多的能力，从而为用户提供更好的搜索体验，这也是搜索客户端的价值之一。
数据格式决定了数据的传输、解析、渲染、交互等能力的构建方法。构建时既需要考虑实现新能力的成本，也需要考虑搜索业务已有能力的迁移成本及所有能力的维护成本。只有搜索结果页和详情页都是非网页数据格式时，才可以不依赖浏览内核展现内容，否则需要提供网页浏览能力。故浏览内核的使用及扩展优化是一件极其重要的技术性工作，可以考虑利用系统原生API扩展网页浏览能力，或自建网页浏览能力。
在iOS平台中，自建网页浏览能力是不被允许的，App在提交到App Store时审核会不通过（iOS平台的Firefox和Chromium，使用的均是系统原生的API）。
当用户在结果页中看到一条与想要的结果相关的内容并点击对应条目时，系统就开始加载落地页了。落地页加载过程中相关事件的处理模式与结果页几乎一样，这里不做过多介绍。
在搜索客户端中，落地页同样可以是网页、非网页及复合格式。只要提供内容的服务是可协同的，那么理论上这个内容格式就是可接受的。
对比结果页，网页格式的落地页的功能扩展一般是缺少端云协同的，只能借助Web生态的标准进行搜索浏览体验的优化，常见的有扩展功能划词搜索、长按识图、字体大小调整、广告过滤、语音播报网页内容及性能优化等。这时依赖的技术主要与网页内容的提取及读写有关，比如网络通信，网页内容解析，浏览及交互事件处理，JS与网页通信等。一些功能还会依赖特定的技术，如语音播报需要TTS技术，长按识图需要图像识别技术。
一些自定义格式的内容在客户端以NA方式实现时，所依赖的技术不局限于浏览内核。例如，音视频内容可以自实现，或引入音频和视频的编码解码技术来承载；AR/VR内容则依赖3D建模、移动AI和大数据计算等技术；地图内容则依赖地理信息相关技术。实际上，不同类型的内容都需要特定的技术来支持，这些技术点与内容场景密切相关，此处不再赘述。
在用户进行搜索的过程中，结果页和落地页的切换是一个高频操作。如果结果页和落地页都是网页格式，那么它们可以在同一个浏览内核中打开，页面切换主要由浏览内核管理。而当结果页和落地页的格式不一致时，需要不同的容器承载，容器切换需要统一的能力支持。在客户端中，根据浏览内核是否管理结果页和落地页的切换分以下两种情况。
1）由浏览内核管理： 结果页和落地页都是网页格式，不需要其他数据解析及渲染能力，只需要在浏览内核中实现页面切换。客户端可以使用单浏览内核或多浏览内核技术方案，并通过浏览内核的事件通知来获取页面加载状态，以实现状态提示。
2）单独构建能力管理： 结果页或落地页的内容中包含非网页格式 （包括非网页格式和非网页+网页复合格式两种） 的数据，需要在客户端中实现数据传输、解析、渲染及交互相关的能力。这里页面的切换、展现以及页面关系的衔接需要借助技术框架来管理，同时也需要知晓新页面的加载时机及相关的状态，以便进行统一的调度。
结果页或落地页的内容中包含非网页格式的数据包含以下3种情况。
❑结果页是网页格式，落地页中包含非网页格式的数据。
❑结果页中包含非网页格式的数据，落地页中也包含非网页格式的数据。
❑结果页中包含非网页格式的数据，落地页是网页格式。
总的来说，当结果页和落地页包含非网页格式的数据时，超出了浏览内核可管理的范围。因为每类页面按需实现，且实现技术均有不同，所以页面相互独立，需要在技术框架层面对结果页和落地页提供支持及管理，第6章会对此进行详细介绍。
前面介绍了搜索流程相关的技术，基于这些技术可以实现移动搜索客户端的核心功能。本节重点介绍移动客户端与PC应用研发的区别，以及移动客户端与云端服务研发的区别。
在2005年，我从PC端研发转到Symbian系统（塞班公司为手机设计的操作系统，主要为诺基亚品牌的智能手机使用）端研发，当时做移动客户端研发的人员极少，大部分都是从PC端转到Symbian的（近几年团队中很多新同事依然没有移动研发经验，即在学校或之前的工作中没有接触过移动端研发）。当时的入职培训曾提到移动客户端研发和PC应用研发的区别，但由于部分细则我现在已经记不清楚了，所以本节将基于我的理解，来讲述二者的区别。
1.使用场景的区别
用户使用PC的场景比较固定，通常是在家、办公室、咖啡厅等比较固定的地点，一般有比较稳定的电源输入和网络环境（网速比较快），使用的时间也比较固定；而手机一般是随身携带的，主要以电池作为电源，使用的时间、场景（地点）通常是不固定的，以至于网络也是不稳定的（用户所在位置不同，存在不同网络切换的情况，比如WiFi、5G、4G等，也存在无网络、弱网络的情况。在移动网络下还需要考虑用户的流量资费问题）。因此进行移动客户端研发，需要关注不确定因素带来的异常情况，需要尽量降低对手机的资源消耗以保证手机有足够长的待机时间，还需要及时响应用户在碎片化场景中的需求，同时要注意对用户隐私数据的保护，特别是现在，手机中有非常多的传感器。
2.硬件配置的区别
与PC相比，手机在CPU计算能力、内存空间等方面存在一定差距，并且手机能够随身携带，因此长时间待机、重启或关机的情况较少。这意味着研发手机上的应用时，需要更加合理地利用和释放资源，减少不必要的计算，以降低电量消耗，或者避免因资源不足而产生使用异常、对手机的待机时间产生严重影响。
PC应用的主要输入设备是键盘和鼠标；而在移动客户端主要是触摸屏、软键盘和响应手势。在研发过程中，需要考虑交互方式的变化，例如用户点击、滑动的不同响应，以及展现软键盘时对布局的影响。如果是跨平台项目，在设计架构时还需要考虑输入层的隔离，以保证业务逻辑和基础能力具有较高的可迁移性。同时，移动设备还配备了麦克风、前/后置摄像头、地理位置信息等传感器，这些输入设备为移动设备的客户端产品提供了更多创新机会，可以在自有应用中使用。
PC应用的主要输出设备是显示器，显示器通常在20 in
以上，而手机屏幕通常在7 in以下。在显示器上可以同时显示多个运行的应用程序，而在手机上大多只能有一个App在前台运行。因此，在移动客户端研发过程中，需要区分App当前所处的状态，以及评估一些需要后台执行的任务是否可以得到支持。
3.研发生态的区别
PC生态以微软的Windows为主，而移动生态以苹果的iOS、谷歌的Android和华为的鸿蒙为主，还有一些厂商基于Android系统开发的生态。一个App选择了在哪个生态中发布，就意味着选择了这个生态中的研发、测试、发布方法，以及对应的市场和用户群体。这个生态中涉及的开发工具、开源代码、生态标准等均需要研发人员了解。在技术选型时，对于生态中的标准，系统提供的能力及研发语言，甚至生态中的上下游厂商的支持程度也需要研发人员考虑。
在开发阶段，iOS平台使用的集成开发环境（IDE）主要是Xcode，而Android平台主要是Android Studio。在生态的主语言方面，iOS平台从原来的OC逐渐向Swift过渡，Android平台也从原来的Java向Kotlin过渡。
不论使用什么语言进行，良好的编码习惯都可以帮助研发人员规避很多不必要的麻烦。对于团队来讲要想形成良好的编程习惯，需要有一些流程规范。如果流程规范不够完善，应该及时提出优化方案。流程规范是团队研发过程的底线保障，所以必须严格遵守。
在App产出阶段，研发人员可以根据业务需要实现不同的功能，还可以针对平台特性及业务需要积累一些实用的小工具。这些工具有些是来自开源的，有些是团队内部自研的，一般来说自研的工具，对于提升团队研发效率帮助较大，应该被熟练掌握。
在App发布阶段，iOS平台有App Store支持，Android平台不同的手机厂商也有自家的应用商店。iOS平台实际上也是面向厂商的，只不过他们的厂商只有苹果一家。
本节我们分3个维度来对比移动客户端与云端服务研发的区别。
1.数据版本兼容的区别
一般来说，客户端会在与服务端联调成功之后再发布新版本。数据协议的兼容主要由服务端支持，即在服务端兼容不同版本客户端的数据请求。但是客户端需要关注本机产生的历史数据文件的兼容性，比如数据文件格式的升级、更名、更改路径等，还需要关注服务端的协议异常，比如服务端下发空数据、数据格式不符合约定等。这些兼容性和容错性问题在客户端均需要考虑，否则就会影响客户端的稳定性。
2.质量保证方式的区别
通常来说，云端服务的接口稳定测试可以通过穷举法来完成，压力测试可以通过并行化来实现（同时也需要考虑不同网络、机房和运营商的区别），有很多对应的工具链可供使用。
相比之下，客户端业务场景会随着版本的迭代而升级，同时会受机型配置、设备授权状态、覆盖安装、功能开关、网络状态和测试环境等诸多因素的影响，这些因素都是易变的，留给开发自动化测试的有效周期较短，因此版本迭代测试机制的实现主要依赖人工。
3.新版本发布覆盖度
云端服务的发布过程主要由内部完成，上线之后可以在较短的时间内覆盖全量用户群体。而移动客户端研发完成，在上线时需要先提交到应用商店进行审核，存在被拒的风险。审核通过后发布给用户，需要用户先更新再使用，这个过程需要一段时间，并不是实时的。上线后一旦有严重Bug，修复Bug的更新包较大，那么成本会更高，时间也会更长。
App的技术架构需要尽可能保证代码变化是可控的、影响较小的、风险可评估的，这样一旦线上版本产生问题，可以把问题的影响降到最小。
本节重点介绍不同场景中，在客户端上实现搜索业务所依赖的技术方案。技术方案可以保证搜索客户端的主体业务实现得更为顺畅。方案中涉及的技术在业界中一般都有通用的解决方法，或者是在原生系统中由对应的API提供。如何使用这些技术构建流程中的业务能力，是一个关键问题。要构建的业务能力，通常都是功能需求所描述的目标，而实现这些目标的技术方案描述了某个功能在使用哪些技术，要经过什么样的流程、逻辑、调用等内容。同一个功能，可能会因为设计技术方案时的偏重点不同而有所不同，多轮评估及调整之后的技术方案会由多元化转为一体化。
通常来讲，技术方案的确定，至少需要通过团队中的高阶工程师评审，还需要团队成员达成共识，否则这个方案落地的可能性较低。写技术方案是研发人员必备的基础能力，大部分研发人员在写技术方案时，通常关注“如何去做”，也就是技术方案如何落地。实际上，技术方案的落地离不开团队的资源投入，在技术方案中适当增加一些与资源投入相关的内容，可以使方案更容易通过评审。
大多数研发人员在评估技术方案时，都会优先考虑方案的有效性，实际上，也存在方案有效性不完整的情况。除了有效性，对实施成本和价值的评估也是技术方案评估的重要环节。
本节重点介绍技术方案的3个评估点——方案的有效性、实施成本及价值。当然，在设计技术方案时，也需要结合功能实现的实际情况进行全面的评估。
1.技术方案的有效性评估
对于一个技术方案，首先要评估其 有效性 ，也就是说这个技术方案对于解决某个问题（实现某个目标）是否有效，是在全部场景下有效还是在部分场景下有效。如果在全部场景下有效，那就说明基于该技术方案研发的产品上线之后，不会出现场景不同造成的逻辑不统一的情况。如果在部分场景下有效，那么就说明要实现最终目标，需要针对不同的场景提供不同的技术方案，需要多个技术方案并行开发和维护。这时不仅会增加维护成本，也会因为方案的不统一导致支撑业务的流程不统一、效果不统一，甚至在一些场景下存在无效的情况。
有效性 是评估技术方案是否可行，如果技术方案对于目标实现没有效果，那么根本就不需要推进了。如果技术方案在将来某个时间会有效并趋于成熟，那就先评估是否有必要提前投入资源。
在技术方案设计的过程中，所依赖的技术点应该是确定的，如果这个都不能确定，那么实施风险就是不可控的。
2.技术方案的实施成本评估
确定技术方案有效之后，就要评估技术方案的实施 成本 了。技术方案的实施成本与业务的运营现状、团队的研发现状、线上用户规模有关。技术方案实施的最大成本来自现状的变化，以及实现该变化的复杂度和风险控制。
成本有很多种，比如使用成本、兼容成本、维护成本、协同成本等。对于部分技术来说，使用成本并不高，但维护成本非常高。特别是一些只在少量产品中应用且没有固定团队维护的技术，在评估时，既要关注可用性，又要关注可维护性，否则使用该技术方案获得的良好收益可能只是一时的，长期的维护过程会非常痛苦。使用某个技术的前提是清楚技术的边界和细节。
在评估技术方案实施成本时，既要关注短期投入又要关注长期投入，既要看投入的资源又要看交付的时间，人力成本和时间成本都是成本。
3.技术方案的价值评估
从技术角度来看，技术方案不仅要满足功能需求，还要提供额外的价值。这些价值可以通过短期和长期两种方式进行评估。短期价值是指在当前功能需求上线时直接产生的价值，包括业务流程、研发流程、用户体验、技术指标和收入等方面的变化。长期价值则是指与之前的技术方案相比，在实现相同功能需求时所产生的变化，例如业务接入方式和研发/维护成本等方面的变化。
技术方案的价值大小取决于方案的提出者对团队需求的理解程度。确定价值的过程，实际上就是确定技术方案目标的过程，确定成本的过程，实际上也是确认方案的实施依赖的过程。在有限的成本下，有效实现技术方案而达到价值的最大化，才是技术方案落地过程的终极目标。
技术方案确定后，在实施之前，通常需要经过团队相关人员的讨论，目的是对技术方案的实现思路达成共识。这个阶段常用的方式是技术方案评审。
在评审过程中，通常有评审发起人和评审人两种角色参与。除了方案的有效性外，技术方案的相关节点也需要在评审中被关注，这些节点包括用户、业务、团队、规范、生态及全局性等方面，会对团队及业务的长期价值产生影响。
1.用户优先原则
若是技术方案中存在损害用户使用体验的点，如让用户使用体验变差、资源消耗升高、用户数据隐私被窃取、稳定性变差等，那这个技术方案就不是好的方案。产品的使用体验是影响用户使用产品的一个关键因素，所以技术方案必须规避这类问题。
2.业务优先原则
所处的角度不同，一些隐藏的影响面在设计技术方案时没有被考虑，就可能出现技术方案与现有的业务流程相互冲突的情况，比如行为不一致、业务适配成本高、指标变化大等。一些技术看起来很厉害，但对业务没有帮助，那么这些技术的价值就很难体现出来，技术方案最终要更好地为业务增长赋能，要支持业务高质、高效迭代。
3.团队优先原则
若是技术方案中存在与团队的目标和需要不一致的点，就需要评估该技术方案是否有必要采用了。比如某些技术方案中涉及重复“造轮子”的工作，对于团队来说这不仅是重复投入研发资源，还会增加维护和设备投入等成本。如果技术方案对于团队来说不是最优解，在横向推进时必然会有阻力。
4.规范优先原则
若是技术方案中存在与现在运行规范冲突的点，一般情况下要么优化规范，要么调整技术方案。但规范是团队积累下来的经验，是团队内所有人员都要严防死守的底线，遵守规范是团队协同工作的基本原则，若是不能做到这些，规范将逐渐变为摆设，最终影响整个团队的工作和发展。
5.生态优先原则
若是技术方案中存在与平台、生态规则冲突的点，就需要考虑这个技术方案是否需要放弃了。在技术方案中应该通过技术手段首先规避这类冲突，只有大家共建，生态才会变得更好，破坏生态规则的要么自己出局，要么最终导致大家都陷入死局。
6.全局优先原则
若是技术方案在解决当下问题之时，牺牲了其他节点的收益，那么即使它实现了当前的目标，也需要谨慎对待。好的技术方案应该站在全局的收益基础之上考虑，不仅要局部变好，还要全局变好，若是实现局部变好的条件是全局变差，那么是不推荐这个技术方案的。