大家好，2018年准备写一个性能优化的系列，那个时候还是在腾讯，结果给自己埋了一个坑没有填，只写了两篇 iOS性能优化系列篇之“优化总体原则”和iOS性能优化系列篇之“列表流畅度优化”。 2019年加入了阿里，就渐渐忘记了之前文章的事情。今年刚好部门开始做体验优化的专项，因此重新想起来性能文章系列的事情。下面文章同时在阿里巴巴CBU微信公众号（牛技）也发表了，以下为转载内容，后续系列文章也会第一时间同步到掘金中。

我们是阿里巴巴CBU部门的内容互动和端技术团队，主要负责1688、1688工业品和采源宝三款App的开发。近期我们启动了iOS&Android客户端的体验优化专项，本文会对体验优化技术方案做整体的介绍，后续还会有一系列子专项的详细方案和成果的文章，以链接形式补充到这里。拟定主题有：

• 《启动优化》

• 《页面容器性能优化》

• 《性能动态弹缩》

• 《性能优化价值挖掘》

• 《稳定日志体系建设》

• 其他

下面切入正题：

1 背景与挑战

移动互联网从第一台iPhone揭开序幕开始，十几年来一路狂奔，从最初的蒙眼狂奔、野蛮式增长，到现在的精细化运营、一步一个脚印。作为一名参与者，有幸参与了大部分的发展历程。至今还清晰的记得那个万众创业、没有一个App都不好意思去跟风投谈融资的时代，在那个时代，靠着引流、补贴、社交裂变等各种粗犷的运营策略，造就了一批在不同垂直领域的超级App。

不过近些年，随着资本的理性、移动设备饱和，新增的移动用户逐年减少。下图是2020年8月， 艾瑞咨询发布的《中国移动互联网流量半年度分析报告》。

从图中可以看出来，截止2020年6月，月独立设备数达到了14.26亿台，较去年仅增长3018万台，且流量增速持续走低，6月增速低至2.2% 。和2019年、2018年的同比增幅都有较大的减少。在流量红利见顶的大背景下，移动互联App的获客成本也越来越大。同时艾瑞咨询报告也指出，虽然流量红利见顶，但是时长红利可期。

在业务快速扩张的前期，由于需求多、迭代周期短，往往忽视了诸如性能等体验问题，这就导致用户在App使用过程中会遇到很多体验问题。如果不加以改善就会对用户留存、交易转化、跳失率会造成一定的影响。在快速扩张的前期，这种影响是可以接受的，但是等App到了成熟、用户增长瓶颈期时，就需要对现有用户做精细化运营，优化用户体验，提升户留存、交易转化，降低用户的跳失率。

因此在整个移动互联网“流量红利见顶”、“时长红利可期”的大背景下，给每个App带来的挑战是要转变传统的流量思维，深耕用户，挖掘单用户的价值。

2 我们的极致体验

2.1 我们要做什么？

上面论述过，在“流量红利见顶”、“时长红利可期”的大背景下，需要深耕用户、挖掘单用户的价值，提升用户体验。我们做极致体验也同样如此。

从上面的用户操作动线图（路径图）可以看出，用户从下载安装，到启动，再到最后的交易转化，中间可能会遇到上图中黄色圆圈里提到的诸多体验问题，虽然看似繁杂和琐碎，但是可以抽象为性能、稳定性和交互体验三大方面。因此为了阻止这三大体验问题带来负面的影响，具体action可以拆解为以下三点：

• 优化性能

• 提升稳定性

• 用户反馈闭环，提升用户满意度指数

2.2 带来什么价值？

从上图可以看出，用户在不同的操作路径上会遇到不同的体验问题，都会带来相应的负面影响。

以下载安装为例，如果安装包过大，在第一步下载到安装的转化就会有较大的流失漏斗。在iOS平台如果包下载超过200M，在蜂窝网络下回提示下载产生额外费用，出现“稍后使用无线局域网”的选择弹窗，如果用户开启“低数据模式”，在200M一下也会受到弹窗提示。在Android平台上，由于使用性能差机器的用户相对会更多，因此包大小会更为敏感，在一些外投场景，包大小会直接影响下载安装转化进而影响外投的ROI。

用户下载安装完成，在使用App过程中，经历的第一个环节就是App启动，如果App启动用户等待时间过长，会十分影响用户的体验，同时也会到来一定的跳失率。同时在进入App到最终交易转化过程中，如果发生了页面加载时间过长、滑动卡顿、白屏、crash等体验问题，都会有一定概率造成用户跳失。因此做极致体验本身就是要从用户的视角出发，优化每个用户在使用App时每一次交互的真实体验。

从上述论述可以看出，做极致体验可以带来如下价值：

• 优化性能，带来的是更快、更流畅的用户体验。

• 提升稳定性，带来的是更高的可用性。

• 用户反馈闭环，可以在用户发生负面体验的时候，可以有通畅、易用的反馈渠道。通过产品迭代最终提升用户满意度。

• 在更快、更流畅、更稳定、更满意的价值之上，从业务视角来看，极致体验带来的价值是提升访问漏斗和业务价值。

2.3 我们做极致体验有什么不一样？

首先，今年至疫情以来，1688的用户增长情况还是很不错的。这一点和上面讲的整个移动互联网的“流量红利见顶”的大背景略微有点不同。但是我们今年要做高质量的发展，对于一个面向批发行业的电商行业，毋庸置疑B类买家（专注批发生意的买家，后续简称B买或者B类买家）对平台的用户价值，比C类买家的价值要大的多。从平台战略上看，B类买家也是亟需增长的。因此从用户分层的角度来看，在提升整体用户体验的同时，我们通过“性能动态弹缩方案”、“性能数据用户分层下钻”、“反馈平台分人群聚合”等方案，有针对性的对B类买家做适当的倾斜， 是我们在做极致体验上的第一个不同的地方。

其次，作为部门唯一的移动端团队，在iOS和Android每端10人左右的规模下，我们需要开发和维护1688、1688工业品和采源宝三款App。如何在人力有限的情况下完成三款App的极致体验是我们面临的一个挑战。今年我们也发起了“躺平”的项目，目的就是希望能够最大效率地支持三款App，后面也会有我们躺平方案的具体文章介绍。目前我们在具体业务承接上，采用了容器化的架构。针对不同业务的特点，主要有“搭建容器”、“Native容器”和“前端容器”。因此在体验优化上，我们将各种优化策略和方案都沉淀到对应的容器上，这样就可以无缝的将体验优化成果迁移到不同App上，做到“躺平”，这是我们在做极致体验上的第二个不同的地方。

第三，上面也讲到，在更快、更流畅、更稳定、更满意的价值之上，我们希望极致体验能够带来的价值是提升访问漏斗和业务价值，这里我们会和业务数据平台“弗洛伊德”做联动，将性能数据和业务数据做关联，分析二者的相关性，挖掘提升业务价值的地方，这是我们在做极致体验上的第三个不同的地方。

3 技术方案

上面论述了极致体验需要做的三个action：性能优化、提升稳定性和用户反馈闭环。下面会将性能优化作为整体，提升稳定性和用户反馈闭环作为另一部分去介绍整体技术方案。其中的一些技术专项，目前已经有了阶段性成果，后面会有一系列文章针对每个专项做具体的方案介绍和成果汇报。

3.1 性能优化

整个性能优化主要分两大部分，一个是性能优化解决方案，另一个是我们做优化的目标和价值阐述。整个方案的设计也体现了“我们做极致体验有什么不一样”所阐述的特点。主要特点有：

• 容器化架构下的性能优化

• 性能动态弹缩方案

• 性能数据和业务数据关联，挖掘性能优化价值

• 性能优化对B、潜B等不同类型的人群下钻

3.1.1 性能目标和价值

架构图从下到上，是目标的拆解 和 目标与价值的链接。

最下面是我们的总体目标。今年整个集团对移动应用的体验都十分重视，提出了55318的性能目标，在此基础上我们希望能够更进一步，在一些子项上有更好的性能表现。

在总体目标基础上，是容器化架构下的目标拆解。上面讲过目前在我们容器化的架构下，主要有“搭建容器”、“Native容器”和“前端容器”三大页面容器。由于不同容器的内在机理不同，因此在诸如页面流畅度、页面加载时间的性能指标上，会具体拆解到每一类容器。同时我们在启动优化过程中也沉淀了启动容器。

由于是容器化的架构，对页面容器和启动容器的性能监控可以收敛到对应的容器里，不需要为每个业务单独去做性能监控。这里我们也与前端团队和测试团队共建了性能数据平台，与集团高可用平台相比，有更细致的性能数据和人群下钻分层。

在业务价值链接这块，在业务数据平台“弗洛伊德”上，我们会将性能数据和业务数据做关联，在性能优化带来流畅、极速的体验基础上，去挖掘性能数据和业务数据之间的关联，希望性能优化能够带来切实的业务价值。目前业界在做性能优化的时候，大多数情况下，还仅仅针对某一性能指标进行优化。比如做启动优化，目标就是尽可能减小启动时间。做流畅度优化，目标就是尽可能提高页面滑动时候的fps。做内存优化时，目标就是尽可能减少内存的使用和发生OOM的频率，等等。当然，从用户视角来看，性能优化的目的是给用户带来更好的使用体验。因此单点地考虑某一性能指标，并将其优化到极致也无可厚非。但是从商业视角来看，一切行为的最终目的还是追求商业目标的最大化。性能优化也亦如此，因此我们还是希望性能优化能够对业务指标有正向的影响，这就意味着应当将性能指标和业务指标关联起来。一方面，通过将性能指标和业务指标做关联，可以方便的查看和分析出性能优化和业务指标的正向关系，给性能优化赋予更多的业务价值。另一方面，将业务价值作为一个维度，可以辅助确定优化指标的基线。众所周知，做性能优化时会针对某一指标制定一个性能基线。目前对于基线的确定，大多是基于竞品的指标和直观的用户体感，再结合经验大体确定一个值，我将其定义为“体验基线”。但如果能够将业务指标维度结合进来，就可以从业务视角去帮助确定性能基线，我将其定义为“业务基线”，可以认为是性能影响业务数据的“基线”。

3.1.2 性能优化方案

性能优化方案主要分为通用性能能力和性能动态弹缩两大部分。

通用性能能力

我们在“搭建容器”、“Native容器”和“前端容器”三大页面容器上，沉淀了诸如预加载、预渲染、同层渲染、缓存渲染等基础能力，这样不需要为每一个业务做单独的性能优化策略，同时也避免了因为业务开发同学水平参差不齐导致的单点性能问题。

在启动优化专项过程中，我们针对启动时间长、性能随迭代腐化、启动任务无管控、无监控、无编排等问题，沉淀了启动容器。具有有任务监控、任务卡口、任务编排、场景化调度等能力，为解决启动性能问题提供了有力的支撑。

除了在页面容器、启动容器沉淀性能优化的通用能力，我们还专注对容器本身的基础性能做优化。这部分涉及到许多繁杂的技术细节优化和流程优化，但好处是在容器化的架构下，所有承接的业务都会自动享受到这部分优化带来的福利。

具体的方案后面会有文章介绍。目前这些通用能力已经支撑了线上大部分业务，同时也无缝支撑我们的1688、1688工业品、采源宝三款App。

性能动态弹缩方案

弹缩方案在服务端是比较常见的策略，这次我们在端基础通用能力基础上，提出来在端上的性能动态弹缩方案，主要是根据用户机型的性能差异和用户人群等特征，使用不同的性能弹缩方案。

在做性能优化的时候，往往要在不同性能指标间权衡，以达到总体最优。这需要我们要有整体的意识，App的性能可以分为很多类，不同的性能指标对用户体验造成的影响也不尽相同，比如fps主要影响的是用户的滑动体验，页面加载时间和应用启动时间影响的是用户等待时间上的体验。我们在优化的过程中，要牢记我们的目标是希望App的整体体验最优，而不是某一单项的性能指标最优。不同优化指标之间可能是呈正相关，比如优化了滑动过程中大量函数的耗时时间，使得fps性能提升，可能会导致App的耗电量变少。同时，不同优化指标也可能是负相关、相互制约的，比如为了流畅性做了过多的cache，会导致内存性能下降，甚至导致因为memory warning导致被系统kill掉，这无疑对App的整体体验造成了负面的影响。

不同性能指标间有复杂的相关关系，同时不同用户的偏好和上下文也不尽相同。比如一些B类买家，在1688上对类目的偏好相对固定，操作路径也相对固定，因此在做诸如预加载、预渲染等策略的时候，是可以利用用户的偏好做适当的预测，以达到最优的效果。同时不同用户的机器性能也对性能优化策略有很大的影响，在一些低端机型下，由于内存过小等因素，预加载等策略反而会影响整体的性能表现。

从上述分析，我们可以得出结论，实际优化过程是一个复杂的、动态的过程， 单一的、固定的优化策略是无法达到到整体的性能最优。因此我们提出了性能动态弹缩策略。整体思路是将诸如行为特征、设备特征、性能基线、人群特征、操作场景等特征作为输入，经过端智能模型的决策，输出针对用户当下场景最优的性能策略组合。整个配置下发和决策会借助我们的端实时运营平台“雷荷波”来实现。

这里举两个简单的应用，我们可以圈出B类买家，根据买家的偏好，在1688首页对其有偏好的tab页面做预加载和预渲染，从而提升B买的用户体验。在启动过程中，启动容器可以根据用户机型的性能、启动的场景（外链唤起、正常冷启）有针对性的编排启动任务，从而达到启动时间和后续用户操作性能的总体最优。在后面专项优化的文章里会有详细的介绍，这里暂不展开阐述。

有了性能动态弹缩方案，我们就可以在性能领域做到“千人千面”，可以较好地解决性能优化过程中的复杂性、动态性、个性化的问题。

3.2 稳定性和用户反馈闭环

对稳定性和用户反馈闭环，主要从研发阶段、测试阶段和灰度、线上阶段的全链路视角去阐述。

研发阶段

目前在研发阶段，虽然有一些简单的开发规范，但是存在的问题一个是相应的规范不够全面，无法覆盖从代码到架构整个流程。另外一个问题是缺少对应的卡口，导致规范主要靠口口相传，无法做到标准化、统一化。我们在日常版本迭代也遇到过因为开发同学没有遵守基本的开发规范，导致线上出现很难复现的bug，结果浪费了很多研发成本在查找bug上面。因此为了提高App稳定性和后续架构的可维护性，我们会在代码、基础库、架构、研发流程上制定一系列必要的规范和卡口。整个规范和卡口的制定会遵循充分讨论、最小化影响开发效率、自动化的原则。

在优化功能、交互方面，一个是优化现有全局反馈的能力，携带更多上下文信息。同时我们接入了集团uone的能力，通过投放用户满意度问卷调查的形式，为不同的业务测算用户满意度指数。然后通过研发提效实现快速的功能迭代，优化用户体验。

测试阶段

测试阶段主要的目的是为了在上线前更快、更容易发现bug。同时提供一系列debug辅助工具方便定位问题。目前端上已有很多针对不同场景的debug辅助工具，后续会对这些工具做收拢并补齐缺失的能力。 同时会配合测试做自动化测试提高测试效率，容灾测试和性能等专项测试，可以针对不同的专项做有针对性的测试。

灰度、线上阶段

灰度、线上阶段反应稳定性的主要指标之一就是crash。经过研发阶段和测试阶段的保障和一些crash容灾、页面容灾策略，线上的crash会有一定的下降。同时对在研发和测试阶段没有发现的crash，会通过预警通知到相应的开发同学来及时解决。对于一些因为信息不够而难以解决的问题，我们还发起了日志的专项，意在解决此类问题。

我们还和前端同学共建了柯南用户反馈平台，收集用户的反馈声音。柯南平台还提供分类、聚合和过滤等功能，可以对用户反馈做进一步的分析和过滤，例如之前一直强调的B买人群，可以在平台上圈出B买、潜B的反馈，提高解决优先级，从而减少重要用户的流失，促进B买用户的转化。

总结

本文主要介绍了CBU在极致用户体验上的思考和总体解决方案。目前启动优化、页面容器优化、性能数据平台、柯南平台等专项都有了一定的进展，后续会持续输出具体专项的详细方案和成果，希望能够对大家有一点点帮助。