美图阿不：美图秀秀工具到社区优化二三事
编者注：查看阿不完整版 PPT，请在 TGO 鲲鹏会公众号回复“GTLC厦门站”自动获取。
阿不现场分享
我在 2015 年加入美图公司，目前负责美图秀秀技术团队。
在这几年中，我经历过的项目包括云存储、云处理，还有美图内部一些核心系统研发，比如流媒体系统和高可用体系建设等。在这些项目当中，我们非常注重用户体验，充分融合服务端和客户端技术、结合全链路链路技术来整体优化用户体验。
美图秀秀到目前为止，发展已经接近 10 年时间了，产品形态也从一开始做傻瓜式的图片处理工具，到精深比较专业的图片美化和人像处理。美图秀秀不仅获得了海量用户的信赖和喜欢，而且也让我们技术团队在图片处理领域积累了比较多的经验。从 2018 年开始，我们逐步尝试做社交圈，整个产品的风格变得更加时尚、现代一些。我们也是希望通过美图秀秀工具和社区的打通，给用户带来更多好玩的时尚生活方式。
接下来我会大体介绍下美图秀秀工具和社区的基础架构，通过两个核心案例来简单分享下我们是如何做技术性优化的工作。
接下来，我将主要介绍工具方面的技术原理。这个技术原理其实也是一个“技术套路”，流程大致分两步：第一、识别的图片都有什么样的内容；第二、需要在识别图片以后把部位分割出来，之后就可以选择任意的调整。
那么，在这个“技术套路”之下，美图会要用到哪些技术呢？
核心是视觉 AI，将图形图像结合机器学习的技术体系去训练我们的 AI 模型，完成内容识别和核心处理能力；
在视觉 AI 技术基础之上，还包括一些工程化的落地、效果的开发，基本上是和图形图像处理相关的技术领域；
最后应用到工程时，非常重要的就是结合我们的素材进行设计，素材设计是我们产品成功与否的一个核心，当然底层也需要匹配我们的处理算法。
美图公司不少黑科技来自于 AI 实验室，我相信不少人也听过，美图 AI 实验室在业界是比较出名的。目前该实验室已经开放了美图的一些 AI 能力，这些能力都可以在美图 AI 开放平台上能够找到。
美图社区技术架构和业界的架构不会有太大的差别。业务端有主 App、小程序、H5 这些入口；后端有基于大数据学习和 AI 相关的核心推荐算法，包括地理位置的服务等；底层是比较常用的资源服务。因为美图秀秀社区的承载对象是图片和视频，所以我们核心的部分就是存储和处理，还有整套流媒体的技术。
美图的业务和技术当前都是构建在容器平台上的，当然也有一套非常完善的大数据体系去支撑整套运营系统、统计分析和推荐系统。为了保证整个服务的稳定性，我们有比较完善的监控告警体系和配套保障。优化指标依赖的就是我们的监控告警体系。
其中，稳定性保障分为用户端和服务端。服务端的开发关注资源、服务层的稳定性及质量的情况。在大规模用户体验优化时，只看服务端是不够的，因为用户端才是最直接的质量体现。
我们构建了一套完整的监控体系，包括通用网络请求监控系统，流媒体专项监控、点播的起播时间、上传性能监控等等，这些都涵盖在我们整个体系里面。通过监控系统的不断完备，技术团队可以方便地查看各项指标，极大地为我们整体的优化提供了便利性。
我将技术上的体验优化归结为三大类，第一就是偏静态体验类的，比如产品的启动速度、运行流畅度、画质等，其中，画质是美图产品非常核心的指标。第二是稳定性，包括崩溃率以及比较影响用户的 ANR 的指标。第三是网络体验的优化，网络体验需要关注响应时间、错误率和服务稳定性等情况。这一项会相对复杂一些，因为网络有很强的动态性。
在整个体验优化过程中，核心是需要有数据。在产品研发过程中我们需要把数据的采集、分析、调整策略这个流程打通，最终需要闭环。通过数据能更为明确地指导整个优化过程。
下面我将重点分享崩溃率优化与网络体验优化，并且针对这两个案例来介绍下我们的一些经验。
稳定性在整个优化前后有了一个比较明显的提升，我们先来看下崩溃率优化效果：
在 5 月底之前，APP 崩溃率保持在一个相对比较高的状态，并且每个月都有在往下走的趋势；在 5 月底我们上了一个版本，崩溃数直接下降了 70% 左右。这里只是一个过程的缩影，其实从 4 月开始，我们就按照崩溃的严重程度，解决每个版本崩溃量高的崩溃，争取每个版本都能够解决大头的崩溃问题。
那为什么之前的崩溃率那么高？我们又是怎样去做的优化呢？
美图秀秀 10 年的产品迭代过程当中，产品，技术，系统都发生了很大的变化，加上团队的变动，由此带来了很多的历史包袱。此外，我们会接入很多第三方 SDK，每个第三方 SDK 都有自己的核心目标，有些可能甚至不会将稳定性列入他们的核心目标，由此就会带来更大的挑战。
有了这些问题之后，我们在上半年做了针对性的优化：
第一、找一个足于胜任这项工作的人专门负责这件事情，技术能力和推动事情的能力非常关键。
第二、产品内部逐步重构，所有的问题不是一步解决的，优先解决优先程度高的问题，并且不出现新的稳定性问题。
第三、对第三方接入的 SDK 制定性能标准和稳定性标准，确保在保证内部质量的前提下，对外部质量也必须要有充分的把控力。
在产品体验稳定性优化到一定程度的时候，我们会制定稳定性标准。不同的崩溃率指标，我们会制定不同介入规范，比如什么情况下我们会发紧急包等都会做出明确的约定。
除此之外，崩溃率的主动告警也是我们保证稳定性的重要一环。虽然 APP 的代码一旦发布后是稳定的（在没有动态更新的前提下），但是仍然有可能会受到在线配置的一些变化和调整引起意外的崩溃情况。所以要保证线上的 APP 稳定性，主动的崩溃告警就显得尤为重要。
随着这一系列的安排，我们产品稳定性表现也取得了明确的改善：
1、过去我们最严重的时候崩溃率接近 1%，到 6 月底的时候崩溃率下降到接近 0.07%，并且我们会持续化优化，未来目标是降至 0.05% 以下。
2、之前团队由于各方面的原因，没有足够的时间，不能很好处理好这个事情，给团队带来比较大的压力。通过这个这个问题的解决，让团队有打胜仗的感觉，能够让大家意识到团队的进步足够解决各种复杂的问题，建立了团队信心和团队成员的信任感，对于团队氛围改善有非常重大的作用。
让我们先来看看一个简单的例子，通过这个例子也能较清晰地引申出网络体验优化的问题。我们素材中心多年来一直遗留一个问题，进入素材浏览页面需要等待 3-4 秒，而且每次都需要这么长的时间，用户的使用成本相对比较高。那这里延伸出来的一个疑问是，什么样的体验才算是好的？极端情况下应该让用户等多久？
下图是我自己总结的用户在完成一个用户动作响应（比如打开页面，播放一个视频）的忍耐度指标。其中，200ms 是我认为比较理想的一个值，但是一般情况可能会相对比较难稳定的达到这个标准。在我的经验当中，600ms 到 1 秒之间也还是可以接受的。一旦用户访问一个页面启动一个产品需要达到 2s 时，用户可能会处于非常焦虑的情绪中。当然如果等 10-30s，我觉得用户使用过该产品一次就不会再使用第二次了。
网络请求具有非常大的不确定性，主要由三个影响因素决定：第一、网络链路因素，例如大家现在都用 4G 手机，想让 2G、3G 手机用户体验非常好是不可能的。第二、是服务端的优化，比如服务优化从 100ms 降低到 50ms 对整体用户动作响应的影响其实是微乎其微，几乎没有太大的影响，但是也必须得优化。第三、协议栈也很重要，当前我们的大部分网络栈协议都是基于 TCP 基础上的协议，目前比较前沿的协议栈的优化也在不断取得进展，比如基于 UDP 的 quic 和 未来的 HTTP 3 等。
我们在做网络优化的时候，第一需要数据，数据是指导我们做任何事情的标准。网络请求有不同的阶段，有很多指标，比如平均等待时间、DNS 解析时间、TCP 的时间等等，这些时间占了大头。在这些指标之后，才是我们的发送时间、收包时间等等。优化就是利用各种各样的手段去解决可能存在的问题。
针对客户端的网络优化手段，大概有以下的一些经验思路：
第一个是超时设置，大部分开发人员可能会忽略这个设置，而忽略的其中一个原因可能是无法去评估到底什么样的超时时间是一个相对合理的值。如果我们从用户的角度出发去思考，我们让用户等待多久会失去他。所以在工程实践当中，我最开始把大部分场景下的超时时间都设置成 10s，调整之前都是 60s。一个基本的思考逻辑就是，除非特殊情况下，大部分的请求基本都能够在几百毫秒之内返回，如果一旦出现丢包或者网络不好的情况，还不如尽快告知用户可以尽快停止这次的等待，让用户有机会作出其它的选择。
第二个是重试策略。短超时可以配合重试策略提升最终成功率。网络出现链路波动的时候，丢包一旦多了，等待的时间就会越长，快速把它失败掉，并且发送一个新的请求，可能很多时候会更快。
第三个是连接复用，即尽量复用链接，减少建联时间和维护连接的成本。
第四个是客户端缓存，梳理业务，去判断有哪些业务数据时效性不是那么高的，把能缓存在本地的数据都尽量缓存，这是优化客户端体验最有效直接的手段。
第五个是多路容灾的手段，尽量让资源避免单点，公网链路很大程度上也可以避免单点。行业内很多的大厂会做单元化的部署，让用户就近访问，把用户分割到就近的机房。如果是中心化的部署，可能有离部署节点很近的用户，也有很远的用户，所以要去看调度逻辑。专有的链路优化不是让我们自己去拉一条专线，因为 CDN 都能帮你解决这些问题。所以专有链路优化对服务来讲是非常简单，并且受益很大的事情。
同样，服务方面也得知道需要什么样的指标，才能指导你的优化逻辑。
我们关注响应时间可能会比较重视平均响应时间，还有一个很关键的时间就是响应时间的分布。因为一个服务有可能只有 10% 的请求是很慢很慢的，比如说 10s，但是就会因为这一个把服务整个打死了。
举个例子，我们服务启动的时候经常会有一波服务波动，波动的时候会有一系列的指标全部都有异常，这个问题非常困扰我们。
通过复现、分析，我们发现的一个问题就是偏向锁。除了对偏向锁的优化之外，很重要的一个点就是预热。假设没有发现是偏向锁的问题，现在第一波服务请求进来会出问题，我们也可以不解决这个偏向锁的问题，采用预热的方式，先慢慢逐步放量，把第一波的量降一些，降到可接受范围之内，后面再承接正式量的时候，就比较稳定了。
服务优化从延迟角度上带来的绝对收益有限，但最重要的是保证服务的稳定性，你需要经常模拟服务故障后的运行情况，常态化的故障演练是优化服务稳定性的保障。
小结今天议题的内容，我在一开始介绍了工具和社区，美图秀秀有完全不同的技术栈，工具的技术栈会偏领域性。美图秀秀的产品大概有十年左右的生命周期，在这十年当中会有很多历史问题的堆积，在未来持续迭代的时候还会有新的问题出来，我们就是在不断解决问题的过程中成长。同样地，优秀的产品体验也能够很好的帮助产品用户增长。业务团队经常是被产品需求赶着跑的，很多时候没有时间思考自己的成长，做着做着不知道自己的成长性在哪里。适度的对团队提出更高的要求，培养追求卓越的团队文化，是对个人和团队共同成长的最佳手段。
黄及峰（阿不），美图公司技术总监。目前负责美图秀秀技术团队工作。负责云存储系统，视频图片云处理系统开发与架构工作，主导美拍短视频成本体验优化项目实施和落地。致力于提升研发效率，标准化项目从研发到上线的整套流程，主导了业务容器化到自动弹性调度线上落地。关注用户体验，组件客户端体验优化团队，建立了基于数据驱动，涵盖到客户端和后端资源的全链路的体验优化和质量监控体系。