首次揭秘，快手自研性能监控系统开源项目KOOM

嘉宾：薛秋实

编辑：马红伟

随着用户数量扩大，业务不断发展，移动端技术也在突飞猛进中暴露出了诸多“疑难杂症”，比如应用的稳定性如何保障、性能如何提升等等，都是移动端领域需要重点攻克的技术方向。

“以我在快手的工作经验来看，开发效率是当前移动端开发所面临的最大的问题，这体现在多个方面，如业务复杂度和代码量指数级提升，线上同时有上千个 A/B 测试，庞大的工作量造成开发同学很难写出足够健壮的代码，经常会出现千奇百怪的 bug。而要高效的完成大量开发任务，则对架构设计、CI/CD 基础设施建设、基础库的质量和代码防劣化等等都提出了很高的要求；另一方面是动态化，目前快手单周迭代已经是业内比较极限的发版速度了，依然很难满足大型运营活动的需求，目前业内还没有比较完美的统一解决方案，要结合业务场景选用合适的方案。”薛秋实说。

本篇文章中，InfoQ 采访到快手客户端团队稳定性负责人薛秋实，就“疑难杂症”之一的稳定性治理进行深入探讨，而稳定性治理中尤以 OOM 为重中之重，薛秋实会介绍快手在 OOM 治理方面的实践和思考。此外，相关的技术案例也将会在 5 月 29-31 日 QCon 全球软件大会 2021 ·北京站上进行分享。

1快手自研的线上内存监控体系解决了哪些“顽疾”？

InfoQ：为什么快手选择自研 KOOM？KOOM 主要解决了哪些技术问题？

薛秋实：客户端的稳定性治理中，OOM 是最难解决的。一般的崩溃问题，只要获取崩溃瞬时的数据（比如异常类型、堆栈等）就可以解决，而 OOM 往往是多个因素累加在一起形成的，并且和用户使用的过程有很大关系。在没有成熟的线上内存监控体系时，我们只能采用线下复现的方式，效率非常低下且完全不能满足需求，业内也没有开源的成熟方案。

在此背景下，我们决定集中力量自研一套线上内存监控体系。这套体系最大的难点在于监控本身的性能保障问题，由于要在生产环境中采集内存数据（比如 Java 的内存镜像，Malloc/Free 的堆栈等等），非常耗性能，严重影响用户体验。经过大量的优化，KOOM 解决了各种技术难题，做到了相关信息采集下用户无感知的水平。

InfoQ：KOOM 落地成果如何？在研发过程中遇到过哪些挑战？

薛秋实：项目一期上线后基本解决了 Java OOM 的线上定位问题，线上实时采集，并通过服务器聚合头部问题，实现自动分发，直达相关业务开发同学，非常高效，虽然还有很多细节有待完善，但总体效果符合预期。项目中最大的挑战是解决采集内存镜像的性能问题，这一部分用传统做法是完全无法绕过的，采集一次会冻结整个 App 进程 10s 以上，最终通过子进程采集的方案将采集造成的卡顿降低到了几十毫秒，基本做到了用户无感知，这也是整个方案最核心的部分。

InfoQ：KOOM 有哪些具体的实践吗？

薛秋实：我有幸参与了 2020 和 2021 两年的春节活动，这个经历非常难得，期间遇到了很多平时难以想象的技术挑战，经过多个团队的通力合作和艰苦奋战，解决了一个又一个难题，活动取得了理想的效果，个人获得了很多成长，很有成就感。

出于保密需求，春节活动是无法做大规模的线上灰度的，出了问题也没有重新发版补救的机会，成败就在活动开始的一瞬间，是“一锤子买卖”，给稳定性保障提出了很多非常规的挑战。在内存方面，我们预先做了很多降级方案，安排了多轮内测和公测，在这些测试中，通过线上开关控制 KOOM 监控采样率和触发监控的阈值，收集到了一些内存泄漏和不合理的大对象使用，有力的保障了用户体验。

InfoQ：在 OOM 的治理层面，如果其他团队也想实践，有哪些经验和建议可以给大家分享一下？

薛秋实：我们认为 OOM 治理是业界共同的难题，KOOM 取得的一点进展对行业是具有普遍价值的，因此我们选择将其进行开源，可以切实帮助大家解决一些问题，并起到抛砖引玉的作用，吸引大家共同来解决 OOM 问题，同时我们在方案调研阶段也参考了业内大量的优秀方案，学到了很多东西，反馈开源社区是自然而然的。

我们的愿景是将 KOOM 做成一套客户端内存问题整体解决方案，目前只有 Java OOM 部分开源了出来，未来会逐步开源 Native 内存、线程、fd、iOS 内存等部分。移动端 OOM 治理这两年有井喷之势，不论是谷歌 / 苹果官方，还是业内的一些大厂，都在不断贡献优秀的方案出来，建议大家可以多关注业内的进展，以及一些高质量的开源项目，比如谷歌的 Perfetto，当然也包括 KOOM。

我们今年的重点就是持续完善 KOOM，包括我上面提到的 Native 内存、线程、fd、iOS 内存等等，内存治理虽然看到了一些曙光，但离最终取得胜利还有很长的一段路要走，需要付出很多艰辛的努力。

2移动开发被唱衰？选好方向很重要

InfoQ：移动开发被唱衰，您怎么看？

薛秋实：行业发展一般会经历萌芽、成长、成熟、衰退几个阶段，在我看来，移动开发刚刚进入成熟期，且会持续很长一段时间，还是有很多机会的。这里有一点值得注意，行业的技术人才、技术解决方案和技术话语权在迅速向头部公司集中，对开发者的技能要求也在提高，供需结构性矛盾增加，一方面公司招不到合适的人，另一方面开发者感觉求职越来越难。因此开发者需要持续学习，适应行业的发展。

InfoQ：移动端目前最火热的两个操作系统依旧是安卓和 iOS，在治理层面它们有哪些通用的办法吗？

薛秋实：Runtime 层的内存管理，Java 用的是可达性分析，OC 用的是引用计数，差别是比较大的，不过到了 C/C++ 层，二者都是类 Unix 系统，很多底层 API 语义都是一致的，编译工具链也在逐渐靠拢，因此不论是遇到的问题，还是解决方案，都有很多相通的地方。我们双端在一个团队里，设计方案的时候会互相借鉴，并尽可能复用基础设施。

InfoQ：移动端开发人员如果想要在这个领域走出一条成功的路，应该重点发展哪些能力？

薛秋实：一方面要打好基础，这就好比武侠小说里的内功和外功，只有打好根基，才能走的稳，走的远，像郭靖起初练功很笨拙，进展缓慢，但有赖于全真教内功基础扎实，厚积薄发，遇到名师指点后很快就成长为一名一流高手。计算机行业虽然日新月异，但是依然有可以终身受益的“内功”，比如操作系统、算法、编译原理等等，很多经典知识的内核是不变的，学好后可以触类旁通。另一方面则要找到自己的优势，普通人的精力是很有限的，不可能做到样样精通，选择一个自己擅长且对团队有价值的方向深入钻研，就可以成为团队的核心成员，为自己的职业发展构筑很深的护城河。

InfoQ：您曾在三星、乐视任系统工程师，那从系统到客户端，这个转变的过程中有碰到哪些困难吗？如何克服的？

薛秋实：最开始确实很不适应。系统开发的周期很长，发版是以双月为单位的，发布也很重，需要用户做 OTA，一旦有问题可能导致用户手机直接变砖。此外系统底层模块和业务无关，提供的都是基础能力，不存在“绕过”的选项，遇到问题就要实打实的解决，并且解决方案要力求完美，遇到的一些低概率问题都要调集大量的人力做复现和排查。

而客户端开发节奏快，以快手来说是单周迭代，遇到问题要快速响应，同时 App 的发布相对轻量级，可以通过 AB 测试和灰度发布来评估线上的影响范围，还可以通过热修复等方法及时止损，在问题处理上相对灵活。另一点重要区别是 App 的权限和系统相差很大，很多信息 App 很难获取，比如 CPU 的负载、系统日志等等，且系统开发时 ROM 源码是可修改的，想做一些埋点或新增一些功能时可以直接修改系统代码，但 App 不能修改系统代码，需要用 hook 等技术支持，比如做告警监控时需要对 Binder 调用做全局 hook 。

尽管系统和 App 解决问题的思路和方式截然不同，但对技术的要求都是类似的，都需要多阅读系统源码，深入了解其原理和实现，才能达成庖丁解牛的效果，找到合适的解决方案。只要思路转变过来了，在系统侧积累的经验和能力是可以很快在 App 侧发挥巨大作用的。

嘉宾简介：

薛秋实，快手客户端团队稳定性负责人，曾在三星、乐视任系统工程师，对移动端操作系统有较深入的研究，致力于搭建完善的性能优化 & 监控体系，保障交付质量，持续提升客户端的用户体验。