面试指南之 App 质量与性能如何保证

当你去应聘一个 iOS 开发工程师的岗位的时候,或多或少都会问到性能优化这方面的问题,而且有的公司会把性能优化作为一个重要的考察指标,答得好或许可以证明你是一个对技术有追求,有一定知识深度的开发者,如果答得不好,面试官可能会觉得你沉醉于业务,缺乏学习主动性。那么,就来谈谈对性能保证的理解吧,应该对大家解答性能优化相关问题有帮助。

平时遇到性能优化问题的时候,基本都是先通过工具来排查定位问题,然后对症下药,在大公司是有很完善的质量保障体系的,在开发阶段、测试阶段、线上运维阶段都有相应的手段来实时对性能进行监控,如果发现问题,在很短的时间内就可以修复、优化问题。

质量保障体系

在开发和测试阶段可以不那么顾虑性能检测带来的性能损耗,所以一些性能保障工作可以安排在这个阶段来做,当然,如果手动测试强度不够,是要结合自动化手段来收集相关数据的。

  • 内存泄漏检测
  • 内存大图片检测
  • 图片主线程解压缩检测
  • 卡顿检测
  • 帧率检测

在具有大量用户的 App 上是可能发生各种各样的问题的,在线上也需要做好各种指标的监控:

  • 网络性能监控
  • Crash 监控
  • Abort 监控 (指由于 jetsam 机制杀死 APP,或者主线程长时间未反应被 watchdog 杀死等情况,这些情况不具有堆栈,定位困难)
  • 基于页面级别的内存消耗监控
  • 卡顿监控
  • DNS 解析情况监控
  • 启动时间监控

基于以上的监控手段,我们可以及时发现性能问题的恶化情况,但是还有一些令人头痛的情况,比如业务逻辑执行不符合预期、用户个人反馈问题难以定位等问题。当用户反馈问题的时候,我们如果去数据库通过 SQL 来调数据其实是很慢的,导致问题跟进不及时,所以针对个人反馈的情况,需要特殊对待。同时上述所讲的性能监控与业务分离,当有一些业务逻辑不符合预期,导致用户问题的时候,也需要特别对待。

  • 实现一套日志系统,记录一些错误、重要业务逻辑结果等
  • 实现一套长链接系统,针对个人情况,主动去捞用户日志

质量保障的技术细节

其实上面列举的一些质量保障方案,实现起来需要很多基础知识支撑,本文自然也是无法完全描述出来,授人以鱼不如授人以渔,我会把相关资料尽可能多的推荐出来,相信这比一个题目的答案更佳具有价值。

首先对于内存泄漏的定位,主要依靠的 FaceBook 和微信读书的方案

对于内存大图片的监控呢,主要是担心图片带来内存陡增,增大 OOM 的几率,具体的监控方法也很简单,首先理解图片从磁盘加载的流程是怎么样子的,到这时候估计就知道如何去监控位图大小啦,对,没错,Hook UIImage 就可以啦,然后通过像素*每个像素所占大小就是位图大小。

对于卡顿检测,估计大家都已经很熟悉了,在这里列举出我所了解的四种方案,各有优劣,可以根据实现情况来选择。

  • iOS应用UI线程卡顿监控 :是通过 ping 主线程,看主线程一定时间呢,是否及时回复
  • iOS 实时卡顿监控:是通过 Runloop,监控主线程处理事件一次 loop 的时间
  • FPS :当帧率过低时,也可以表明卡顿,帧率主要是通过 CADisplayLink 来做的
  • 比较堆栈:主要是比较主线程一定时间内堆栈是否一致,假如一分钟获取一次,相邻两次获取结果相同,则代表被卡住了

网络性能的监控有两种方式,一种是通过NSUrlProtocol做拦截,通过 delegte 回调方法拿到性能相关数据;一种是通过 Method Swizzle去 Hook NSURLSession 拿到相关数据。具体的指标包括成功率、状态码、流量、网络响应时间、HTTP与HTTPS的 DNS 解析、TCP握手、SSL握手(HTTP除外)、首包时间等时间

Abort 率的监控无法获取堆栈,也无法捕获,只能通过排除法来做,具体原理如下:

  • 程序启动,设置标志位
  • 程序正常退出,清楚标志
  • 程序Crash,清楚标志
  • 程序电量过低导致关机,这个也没办法直接监控,可以加入电量检测来辅助判断
  • 第二次启动,标志位如果存在,则代表Abort一次,上传后台做统计
top Created with Sketch.