超级 App 手机百度移动搜索优化与平台化方案

2015 年 6 月 28 日下午，百度与 InfoQ 携手举办了手机百度“云和端技术实践”沙龙活动。这是手机百度首次公开超级 App 背后的技术知识。活动分云端和客户端技术两个会场同时进行，吸引了众多技术爱好者前来学习交流。现场人数爆满，气氛热烈。

手机百度产品总经理，百度副总监黎科峰出席沙龙并简要介绍了手机百度的业务状况和讲师团队成员。他谈到，手机百度作为百度在移动互联网时代的亿级用户流量入口，不仅支撑着百度内部产品，更希望打造一个开放平台，支撑众多第三方行业及应用的发展，从连接人与信息拓展到连接人与服务。比如打开手机百度就可以看到 9 块 9 上门推拿服务。手机百度的未来应用前景拥有很大的想像空间，在云端和移动客户端技术业务的实现上也积累了很多宝贵经验和创新实践！

下面是此次技术沙龙活动云端分会场的主题演讲概要总结：

主题一：移动客户端搜索速度优化（程逸凡）

搜索是手机百度核心业务，工程师对它的优化也做了很多工作，本主题主要分享了手机百度客户端速度优化上面的实践经验，分享针对 Android 平台，但同样适用于 iOS 平台。

主题首先介绍了手机百度中的移动搜索。在介绍技术方案之前，主题明确给出了百度移动搜索优化的目标，主题后续分享了很多独特的优化方案，让期待干货的听众感觉不虚此行。

接下来主题给出了移动客户端中常见的加载模式，一是本地 Native 界面切换，二是 Native 展现云端数据，三是加载 Web Content：

• Native 的界面切换，它的优化重点是 UI 效率，数据库读取速度，启动的过程首先要给移动一个路口进入开始它的各种功能，它的优化里面还避免网络连接，因为网络连接在移动互联网上它的速度是非常不可控的，所以要通过数据缓存等等机制，在手机启动过程中减少一些非必要的运算来加速它的启动速度。
• Native 展现云端数据。对这一类流程来说它的优点是，UI 生成与渲染，数据解析非常快，服务器响应快，优化它的时候通过一些数据缓存和优化网络通信。在搜索过程中会频繁出现 Native 上云端数据的情况，也就是搜索建议，相对来说这是一个比较简单的界面，所以对它来说系统优化方面并不会有很大的困难。
• 加载 Web Content，WebView 加载一个网页内容，百度是一个非常庞大的系统，它仍然是以页面做展示。它就是用一个 WebView 去加载。对 Web Content 的优化是其中一个比较大的挑战，因为搜索流程里面有很大一块是用户等待，点击搜索之后等待看到结果，这是最难以忍受的一段时间，但是对于客户端来说它对于这个加载过程的控制力是比较弱的，对于 App 来说，WebView 加载的过程是一个黑盒，连接网络一般由 WebView 控制，渲染性能依赖于 WebView 的内核，页面优化来于前端实现。

在手机百度做性能优化的过程中，主要应用有两个指标，一是首屏时间，二是完成时间。首屏时间对应的是用户可见速度，它代表的是用户看到首屏界面，这个极大的影响到用户的感知，也是大多数用户认为界面加载速度的一个评价标准。可以通过一些技术方案，把这个时间提前。用户无法感知到，他也不需要知道，他一般是通过首屏时间来推测这个时间，然后他来感觉到速度和流畅度。首屏时间极大的影响用户感知，是最着重优化的一个点。完成时间影响到用户的使用体验，它是其次要保证的时间。

接下来主题介绍了几种优化方法如下：

• 利用首屏后 300~600 毫秒的时间差，在 UI 线程上完成必要的初始化操作的优化方法，顺序是优先初始首屏可见界面，然后利用时间差完成必要的数据与逻辑，而对于独立功能则用到时再初始化。
• 优化 WebView 加载速度，即加载过程中，让 WebView 专心的干活，复用 TCP 连接和设置预连接页面等。
• Layout 优化，考虑到 Activity、Fragment 切换都有耗时，因此在速度敏感场景中应采用 View 组织界面，并自定义 Layout。

主题二：手机百度android平台平台化解决方案（张斌）

主题主要分三部分，分别介绍了手机百度的 APS（Advance Plugins System）、APS 技术方案和开发方式，正是这个插件系统撑起了手机百度的平台化方案。

主题先介绍了 APS 的由来和发展情况。手机百度是一个非常大的公司，有很多的事业部和产品线。如何把这些事业部、这些产品线所有人的资源能整合在一起，能很好的与微信、淘宝达到一个同等的竞争力，这是百度去年一直在做并且做成功的一件事情。目前安卓中已集成信息类如百度新闻、贴吧，生活服务类如百度钱包、糯米，工具类如视频播放器、小说阅读器、百度云等常用插件。

APS 平台分为云端和客户端，在云端可以一键接入多个平台，开发非常简单，病能够提供非常友好的 NA 搜索体验。这样一来，用户获得了更好的体验，生态的转化率得到了提升，而手机百度本身的开发效率和灵活度也得到了极大的改变。值得一提的是，APS 使得应用提供方无需再费力推广安装自己的 apk，用户通过点击插件即可使用。APS 的优点在设计之初便有所体现，如平台化、接口化方面的二进制插件，独立开发方面的独立性，分散测试，自主升级方面的可配置，独立下载方面的动态下发等。

主题第二个介绍了 APS 的技术方案。整个 APS 系统分为客户端部分、合作开发者、服务的前端和后端、业务线的接入。应用提供方关注业务服务器，APS 后端和业务线服务器是一个非常标准的协议，业务服务器将会通过具体业务的特点再去对协议的字段进行扩充。合作开发者会接入到 APS 的前端，APS 前端是一个非常复杂的网站，在这个前端中它包括了开发者中心，这里有开发者帐号、开发者一些审核和申请相关的功能。手机百度的产品经理可以根据插件的准入情况，比如说完全经过准入之后，就可以通过这个平台针对于手机百度的某一个版本进行下发，同时在控制平台中可以根据它监控系统发现的问题，对某个插件进行云端的接入，完全可以通过云端去控制。还有质量保证系统，当开发者进行插件准入的时候，会走准入系统，准入系统有一个标准的工作流，插件测试通过后就提交到系统中去了，质量保证系统会做全自动化的系统扫描，质量保证系统会自动生成一个质量保证报告，如果发现问题的话，会打还给开发者，开发者进行修改之后，再重新去走这个平台。当质量保证系统这边准入通过之后，插件包就会接入到 APS 后端的存储模块；当产品经理在控制平台中进行配置的时候，后端会通过控制模块、存储模块取消标准包，下发给请求的业务线。

同时在后端有一个数据模块和测试模块，数据模块主要是针对于客户端，客户端很注重安全性和稳定性，稳定性也是根据客户端实时监控插件的运行状态，产生正常数据和异常数据的时候会及时上报给数据模块，可以看到一个完整的可视化数据，当数据出现异常的时候，就会通过这个控制平台去控制模块，去进行一些相关的处理。APS 客户端由几大部分组成，有 APS 内核，控制模块，监控模块，沙盘模块、破壳模块、安全管理模块、插件中心等。

主题最后介绍一下 APS 的开发方式。产品层面、UI 都定好之后进入开发，开发者先开发一个独立的 apk，这个 apk 可以在安卓里运行，但是需要替换掉 sdk，放在插件容器中运行。apk 里面所有集成的组件的基类都替换成 sdk 里面的基类。内核里面是有一个运行内核。联调接口。最后通过开发者中心的 APS 准入，以及各种 PK，质量的 PK 等等。

主题三：手机百度iOS平台平台化解决方案（王聪）

主题主要介绍了在开发中遇到的问题，以及如何分析这些问题，最终给出一个解决方案以及现在这些方案的效果。

主题首先提出了联调开发中的成本问题，主要来自 RD 联调、QA 联调和定位及修复 Bug 带来的频繁打包，解决这些问题的办法是通过平台化，通过构建接口平台、开发平台和准入平台等手段，尽量降低开发成本。具体来讲，接口平台化，把所有对外提供的能力以及插件对我们以外的能力，所有接口进行整合，把这个接口包装成一个品牌对外提供，所有插件可以很方便的去进行插件的接口开发。开发平台，做一个 APP，做一个功能，大家都离不开发，如何让一个插件的开发者能很有效的基于现有的环境去进行一个开发以及发布他们的插件，这是平台化最重要的。准入平台，准入平台主要是给插件开发者准入其插件，把插件准入流程可以系统流程的规范化，不用进行人员之间的沟通，就能得到一个流程规范的平台。

接下来，主题给出了百度手机平台的架构图如下，具体内容在 Android 主题中已做介绍：

这里 iOS 主题补充一下关于手机百度客户端平台化的三个核心概念的说明。客户端平台化的核心方案有三个重要概念，这三个概念组成了最终的平台化方案的最终版，一是壳工程，二是破壳系统，三是插件自身。壳工程是一个可运行的最终的一个工程，这个工程包含了手百所有的工程配置，包含了手百自身的资源文件，以及手百主体代码打包后的库文件，这个工程可以直接运行，插件方不做任何改动的情况下可以拿这个壳工程运行，可以得到最新版手机百度的 APP，然后壳工程中会有自己的安全机制，对各种用户隐私进行保护。然后是破壳系统，破壳系统是插件方唯一能看到的一个系统，它提供了插件调用端能力接够，包含插件管理以及插件入口的自动生成，插件入口的自动生成也是整个项目的核心，这一点保证了对所有插件开发者开放的都是一个同一个壳工程。插件方，为了适配平台，它除了自己的插件主体之外，还需要提供额外两个东西，这两个东西保证系统可以运行起来，插件方提供插件主体之后，需要提供指定协议实现类以及数文件，这个协议实现类是所有插件功能的主入口，它的描述文件描述了所有插件的 ID 版本信息以及插件的描述信息，可以通过这个描述文件得到插件所有的功能入口。

主题最后还介绍介绍了一下开发过程中遇到的实际问题和具体解决办法：

问题一：第三方库冲突的问题。现在很多大公司开放的库，它都会存在这个问题。手百的原则是所有第三方库统一由手百方进行接管，插件方在打包时将第三方库剥离。插件方打包的时候需要做一些编译选项控制，保证这些所谓的第三方库不被打包到最终的库文件之中，然后才能去集成他们的这样一个插件。

问题二：保证壳工程安全性。安全性可以说是移动互联网的生命线，所有的APP 必须把安全放在首位它才能良好的活下去。在壳工程方案之中它存在着几大风险点，一是壳工程如何避免插件方直接编译。二是由于iOS 的沙盒环境，没有办法做到根本性去限制某个插件有访问的内容限制。解决方案是，一是时间限制，超过这个时间之后，壳工程就不可用了。再就是BundlelD 验证，要进行登陆的时候，会判断一下BundleID 与现在的工程BundlelD 是不是一样，如果不一样就会有限制。重要功能会进行密钥保护，通过这些步骤就保证了壳工程的安全性。

问题三：端能力接口升级。这一点也是开发到后来的时候才发现这是一个有极大影响的绊脚石，手百方自己的业务在不停升级，而这些升级可能对插件方来说是无意义的，升级之后，就需要去改变这些接口，给接口增加参数或者减少参数，这就会经常出现莫名其妙的问题。针对这一点，现在破壳系统是实际端能力接口的封装，保持不变，能力升级时修改实际端能力接口，破壳接口不变。这样在端能力接口进行升级的时候就不

感谢 Raymond Zhao 对本文的审校。

给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入 InfoQ 读者交流群）。