Bootstrap

导读 | 如何打造高质量的应用?

年初去上海参加一个移动技术会议,问了很多开发者最近在忙啥。令我非常惊讶的是,大家讲的最多的还是用户体验和应用质量。特别是出海东南亚的同学,面对一堆 512MB 内存的设备、无处不在的弱网络流下了无助的眼泪。

除了内存优化、弱网络优化,想做一款高质量的应用还远远不止这些。一方面,我们面对的环境越来越复杂。过去的 iOS 开发者可能做梦也想不到,现在也要开始适配屏幕和双卡双待了,更不用说 Android 那多如繁星的机型、厂家和系统。如果你的应用也要出海,那么还要面对几十个国家不同的语言、环境。

另一方面,我们的代码跟业务也越来越复杂了。先不说大量“年久失修”的历史代码,业务越来越复杂,如何管理好几十上百个模块?还要面对 React Native、Flutter、TensorFlow 等各种语言跟框架堆积在一起的情况,再加上复杂的环境和庞大的系统,想想做一款高质量的应用真的不容易。

从应用交付的流程说起

既然打造一款高质量的应用那么困难,我们可以先从哪里入手做些什么呢?我的方法是把应用当成一件商品,想象一下商品在流水线生产的过程,那么怎样在每个步骤做好“质检”呢?这就要从应用交付的流程说起。

在我看来,一个应用至少会经过开发、编译 CI、测试、灰度和发布这几个阶段。每个阶段需要关注什么问题呢?

1. 开发阶段。在面试的时候,常常有人说自己熟练掌握各种开发工具。但是,我们真的懂吗?就拿我们比较熟悉的耗时分析工具 Traceview 来说,它背后的实现原理是什么?能不能做一个完全没有性能损耗的 Traceview?或者怎么样将它移植到线上使用?

2. 编译 CI 阶段。如何防止代码不断地恶化?怎样进一步优化性能?d8 与 ReDex 有什么神奇的黑科技?如何利用好 Coverity、Infer 这些静态分析工具?这部分可能需要一些编译原理的知识,你会发现移动开发也有很多值得深入研究的东西。

3. 测试阶段。我们常说敏捷开发,用户是最好的测试。遇到问题在线上反复试错,对自己、对用户都十分痛苦。我们希望可以做到测试“左移”,尽可能早地发现问题。但是很多时候我们不是不想测试,而是发现测不出什么问题。那么怎样提升实验室发现问题的能力呢?如何尽可能地模拟用户的操作路径?做好测试并不容易,自动化测试结合 AI 或许可以帮助我们解决一些痛点。

4. 灰度和发布阶段。动态部署流行起来之后,很多开发变得松懈起来。有问题发补丁,一个不行就两个,两个不行就十个。怎样去保证产品质量?很多线上问题概率很低,基本很难复现,比如对于一个印度的用户,我们希望有一个远程的听诊器,而不需要把用户拉到我们的手术台上。

对照应用的交付流程,介绍一下专栏的学习方法。专栏“高质量开发”模块主要对应的是开发阶段,你可以带着实践过程的困惑去深入学习开发需要的各种武器。专栏“高效开发”模块主要对应编译 CI、测试、灰度和发布阶段,你可以结合实际工作全面提升整个应用交付的效率。另外,我认为一个好的架构可以减少甚至避免团队出错,也是打造一款高质量应用非常重要的一环,因此会在最后的“架构演进”模块和你聊聊如何设计一个好的架构,以及架构该如何选型。

移动 APM 质量平台

请你思考一下,在应用交付的这几个阶段中,我们对高质量的目标和实现方式是否一样呢?开发阶段有开发人员,可能希望采集尽可能多的数据;测试阶段有测试人员,可能更针对实验室环境或与竞品对比进行测试;灰度和发布阶段可能也有专门的运维人员,策略会相对保守一些。很明显,不同阶段我们对高质量的目标跟手段可能不太一样。

一个公司有多套质量系统,这在大公司是非常普遍的现象。我们希望有一个统一的平台,整合应用的人员和开发流程,这就是我们常说 APM 质量平台。

APM 的全称是“Application Performance Management”,即应用性能管理。据我了解,国内像阿里、腾讯、美团点评、饿了么、爱奇艺这些公司都在大力投入。Google 今年也发力 Android Vitals 监控,新增了耗电、权限管理模块。那么 APM 质量平台究竟有着什么样的魅力呢?

1. 统一管理。A 同学写了一个耗时监控工具,B 同学写了一个内存监控工具,它们在不同的仓库,上报格式可能不太一样,各自都搭了一个简单的页面。如果想评估一个应用的质量,总是要去几个系统汇总数据,想想都费劲。

2. 统一三端。一个公司可能有多个应用,一个应用也可能有 H5、iOS、Android 多个端。我们希望它们只是采集数据方式有所不同,上报、后台分析、展示、报警都是共用的。随着技术的发展,我们可能会增加 React Native、Flutter 这些新模块的监控,这个平台应该是统一演进的。当然我们非常希望业界有一套开源的方案,大家可以一起优化。

那这个质量平台需要关注哪些问题呢?这需要看我们用户关心什么问题。有的问题可能是致命的,像崩溃、卡死、白屏。另一大类问题就是性能问题,安装包大小、启动、耗时、内存、耗电、流量都是这一个范畴。在这个专栏里,我并不会教你如何从头搭建一个 APM 平台,我会更期待你掌握背后所需要的知识,它们主要包括:

由于 Android 版本的碎片化和国内 Android 生态的乱象,或者换句话说,“Android 开发者很苦,国内的 Android 开发者更苦”。在 11 月举办的 Android 绿色联盟开发者大会上推出的应用体验标准,有对应用的兼容性、稳定性、性能、功能和安全做了详细的定义。贴张图,你可以看下。

在极致性能的同时,我们希望能更进一步地打造“绿色应用”。在这个过程中,一个全面而强大的 APM 质量平台会是我们坚实的后盾。当然对于大多数中小开发者来说,我们更建议选择成熟的第三方服务。但深入了解它们背后的原理,无论是对我们如何选择合适的服务,还是日常开发工作都会有很大的帮助。在学习完上面的这些内容之后,你也会觉得其实“性能优化”并不是那么“高不可攀”,我们也可以慢慢地迈向“性能优化专家”之路。

不过我们需要明确一点,虽然移动 APM 质量平台可以帮助我们快速发现和定位问题,但是监控并不能保证实现高质量,这里最关键的永远是人,而不是系统。为什么呢?举两个小例子。

你在工作中可能总能遇到这样的场景,我管它叫反馈问题三连击:“是我的问题吗?”“能复现吗?”“你的测试靠谱吗?”。虽然通过 APM 质量平台可以减少推卸责任,但有些人的做法通常还是发现空指针加一个判空,发现并发问题加一个锁。这里的空指针真正原因是什么?这里判空了后面的逻辑是否还会运行正常?有没有更加好的方法或架构可以避免这个问题?我们真正应该反问的是这三个问题,把“质量观”深入骨髓,真正去想要得到个人成长,深挖背后的原因。

第二个例子是,我发现许多人都在问题无法忍受,或者说是老板无法忍受的时候才去开启各种优化专项,但事后又不了了之。我们很多时候都在用战术的勤奋掩盖战略的懒惰,性能优化的关键在于如何解决存量问题,同时快速发现增量问题。APM 质量平台只可以协助我们,并不能解决组织内部的心态问题。

总结

看到这里可能你会有这样的疑问,我们在小公司根本没有机会学习到这些东西呀?确实如此,个人与公司一起成长是最快速,也是非常难得的事情,但并不一定人人都会有这样的机会。从我自己的经验来看,在搜狗、微信会遇到各种各样的疑难问题,也可以有很多时间去研究,让我在解决问题的过程中获得成长。

幸运的是现在大家都更加乐于去分享,在专栏和技术会议中,我们可以看到很多成熟的解决问题的经验和思路,在 GitHub 我们可以找到很多优秀的源代码。在这个环境下,我们需要耐得住寂寞,多抠一些细节,多深入研究,多停下来总结。

分享一个故事,面试前面都不太理想,最后还是通过了。后来有一次跟面试官闲聊说起这个事情,他们认为有一件事情打动了他们。2012 年的时候,LeakCanary 还没开源,我在使用 MAT 做内存泄漏分析的时候总觉得很不爽。为什么不能做自动化?为什么看不到 Bitmap 的图片?我当时深入研究了内存文件 Hprof 的格式,做了几个小创新:

1. 实现内存的自动化测试。在自动化测试后回到首页,这个时候获取应用的内存快照。自动分析内存中 Activity 实例,正常情况应该只存在一个,其他都认为是泄漏。为了支持正式包,还做了通过 mapping 文件反混淆 Hprof 文件的功能。

2. 查看图片。自动将内存中重复的图片、比较大的图片转换成 PNG 格式输出到文件。

现在看起来这些功能并不是太难,但如果放到六年前,想到而且能做到的人相信并不多。讲这个故事还是希望你能在工作和实践中多停下来思考,多深入研究一些细节,很多看似不经意的思考和创新,可能在日后发挥更大的价值。

课后作业

“纸上得来终觉浅,绝知此事要躬行”,只有通过实践,运用到自己的项目里面,才会对知识有更深入地理解。



移动应用的质量管理对于开发者来说至关重要。本文从应用交付的流程出发,介绍了开发、编译CI、测试、灰度和发布等阶段需要关注的问题,并提出了学习专栏来提升应用交付效率的建议。此外,文章还强调了移动APM质量平台的重要性,强调了统一管理和统一三端的优势,并提到了在学习过程中需要掌握的相关知识。最后,文章强调了虽然移动APM质量平台可以帮助快速发现和定位问题,但最关键的永远是人,而不是系统。作者分享了自己的经验,鼓励读者在工作和实践中多停下来思考,多深入研究一些细节。整体而言,本文涵盖了移动应用开发中的技术特点和重要性,对于读者快速了解移动应用质量管理具有一定的指导意义。 

;