性能调优和监控体系

[ShannonChenCHN]

性能调优和监控体系

• 性能优化
  • 结案侧、量化：Instruments 的使用
  • 瓶颈
  • 优化
  • 领域：
    • 网络
    • UI 卡顿
    • 内存
    • 启动速度
• 监控体系
  • 日志系统
  • 卡顿监控
  • 崩溃预防和监控
    • 崩溃收集
  • 错误码监控
  • 耗时监控
  • 网络监控
  • 内存泄漏监控
  • OOM
  • 硬件监控
  • 业务监控
  • 补救措施
    • 后台配置
    • 热修复
• 第三方工具
  • bugtags

参考资料汇总

• 详见ShannonChenCHN/iOSAppOptimization

关联专题

• 编译、链接和装载 编译、链接和装载 #47
• 操作系统 操作系统 #54
• 内存管理 内存管理 #38

[ShannonChenCHN]

iOS监控编程（by 陈奕龙）

简介

这是一本介绍iOS监控编程的书籍,内容涉及日志监控，监控崩溃，监控网络，监控卡顿，监控硬件，内存泄漏监控等方面。所有的功能都是通过自行编程实现，而不是通过使用第三方工具。每个章节记录了功能的实现细节，以及笔者一路探索过来的心路历程。当然，笔者后续依旧会寻求与探索新的监控方向，一旦有所得都会更新到本书的章节中。 这本书产出的工具GodEye能全自动，零代码入侵，一行代码接入来监控应用的日志，卡顿，崩溃，网络，内存泄漏，CPU以及内存使用率，帧率等信息。 https://github.com/zixun/GodEye

目录

前言 1.1

1. 日志监控 1.2
   1.1 监控NSLog日志 1.2.1
   1.2 监控print日志 1.2.2
2. 崩溃监控 1.3
   2.1 监控未捕获异常崩溃 1.3.1
   2.2 监控底层信号崩溃 1.3.2
3. 卡顿监控 1.4
   3.1 Runloop监控方案 1.4.1
   3.2 DispatchQueue监控方案 1.4.2
4. 网络监控 1.5
   4.1 URLProtocol网络监控 1.5.1
   4.2 URLSessionConfiguration网络监控 1.5.2
5. 硬件监控 1.6
   5.1 系统CPU使用率监控 1.6.1
   5.2 应用CPU使用率监控 1.6.2
   5.3 系统内存使用率监控 1.6.3
   5.4 应用内存使用监控 1.6.4
   5.5 系统网络流量监控 1.6.5
   5.5 帧率FPS监控 1.6.6
6. 内存泄露监控 1.7
   6.1 微信阅读MLeaksFinder方案 1.7.1
   6.2 MrPeak's PLeakSniffer方案 1.7.2
7. GodEye介绍 1.8
   7.1 GodEye简介 1.8.1
   7.2 GodEye提供的功能 1.8.2
   7.3 GodEye解决的痛点 1.8.3

[ShannonChenCHN]

崩溃分析

• 获取 Crash Log
• Symbolicating Crash Reports
  • Bitcode
  • Determining Whether a Crash Report is Symbolicated
  • Symbolicating iOS Crash Reports With Xcode
  • Symbolicating Crash Reports With atos
  • Symbolication Troubleshooting
• 分析 Crash Reports
  • Header
  • Exception Information
  • Additional Diagnostic Information
  • Backtraces
  • Thread State
  • Binary Images

参考

• Understanding and Analyzing Application Crash Reports - Apple Developer Center（了解和分析iOS Crash Report）
• 深入iOS系统底层之crash解决方法介绍
• 深入理解iOS Crash Log【推荐阅读】
• Understanding Crashes and Crash Logs - WWDC 2018

[ShannonChenCHN]

Crash Reporter

1.崩溃监控的原理：

• 监听崩溃，崩溃发生的原因有三类：

  • 理论上应该可以 try-catch 到的、但没有处理的 UncaughtException：可以通过 NSSetUncaughtExceptionHandler() 注册监听异常
  • 指针问题引发的崩溃：可以依赖 Linux/Unix 信号处理机制实现监听（signal(int signo, void * handler)和sigaction(int signo, void handler, void pre_handler) ）
  • 内存占用过高导致进程被系统杀掉：监听 didReceiveMemoryWarning 方法

• 采集崩溃信息：可以从监听函数的行参（NSException 对象）获取当前异常堆栈信息

• 分析崩溃信息:对于 iOS 应用的崩溃堆栈，需要进行堆栈地址的符号化处理，这个处理过程使用系统的atos工具，借助iOS应用的符号调试信息文件dSYM 就可以完成。

2.相关开源框架和平台：

开源框架：

• KSCrash：使用较广泛，现在仍然在维护中
• PLCrashReporter：很久不更新了

平台：

• 友盟统计
• BugHUD（实际上就是用的 KSCrash 框架）
• Crashlytics（Fabric）
• Bugly

3.选用第三方平台的考察点：

- 免费
- 方便追踪和分析 bug
- 不存在审核被拒风险

4.第三方平台对比

	Bugly	BugHUD	Crashlytics(Fabric)	友盟
简介	腾讯出品，在国内应用的比较多。Bugly 崩溃监控分析服务源于鹅厂内部，在经历通公司内终端应用的合作和持续打磨后，于2014年对外提供面向开发者的服务。Bugly的崩溃监控分析，除了关注崩溃捕获以外，还提供自动化堆栈解析，动态归类，实时统计，监控告警等功能，特有的ANR/卡顿监控分析，专属的游戏脚本错误监控分析和用户留存分析等功能。并且，Bugly服务平台持续开放更多研发流程相关的工具/服务给大家使用，诸如内测分发，CI等。	fir.im 旗下产品，基于开源框架 KSCrash	Crashlytics国外知名的崩溃监控分析服务，被Twitter收购后并入Fabric服务，目前Fabric提供Answers(统计分析)、Beta(内测发布)、Crashlytics(崩溃监控)服务。崩溃问题的堆栈分析做的比较赞	国内移动统计分析服务平台，提供统计分析、更新，分享，推送等服务，其中，错误分析也是在统计分析的基础上添加。
收费标准	免费	免费	免费	免费
主要功能	监控崩溃、监控卡顿、上报错误、上报自定义日志、支持自定义标签、符号表管理	监控崩溃、上报自定义异常
收集信息	崩溃次数、影响用户、app 版本、用户id、发生时间、机型、系统版本、出错堆栈、页面跟踪、跟踪日志、符号表 、自定义 log	出错堆栈、崩溃次数、app 版本、发生时间、影响设备
崩溃上报时机	上报卡顿：在App从后台切换到前台时，执行上报。上报崩溃：如果 crash 是发生在 SDK 初始化之前，发生崩溃会立即上报（猜测，待确认）。上报日志：默认值为BuglyLogLevelSilent，即关闭日志记录功能。如果设置为BuglyLogLevelWarn，则在崩溃时会上报Warn、Error接口打印的日志	发生崩溃会立即上报，如果上报不成功将会在在第二次启动时上报。
SDK 接入	支持 pod 安装，在application:didFinishLaunchingWithOptions: 方法中初始化 SDK，可添加自定义日志	支持 pod 安装，在application:didFinishLaunchingWithOptions: 方法中初始化 SDK，可以设置自定义参数、Exception
使用体验	在后台能看到除了崩溃本身相关的信息之外、还有跟踪日志、页面浏览记录、使用时长等，自己上报错误日志	功能比较简单，虽然能看到跟每个崩溃相关的信息，但是维度单一
技术支持	论坛、微信公众号、QQ 群	微博
是否存在被拒风险	如果是热修复版本，意味着使用了 JSPatch
实现机制,能捕获哪些异常	注册监听 NSSetUncaughtExceptionHandler() 和 Linux/Unix 信号	BugHD 通过注册 NSUnCaughtExceptionHandler 监听未被 try catch 的 Objective C(简称 OC)代码异常。 BugHD 通过注册 SIGABRT/SIGBUS/SIGFPE/SIGILL/SIGSEGV/SIGTRAP 几个 unix 信号，监听 C 代码引发的系统异常信号。		N/A
FAQ	常见问题汇总，iOS 常见问题
使用案例	QQ、微信、qq 音乐、美丽说
SDK 大小	(55.2M - 48.2M) ≈ 7 M

整体来说，各个服务平台崩溃监控采集上报能力基本相当，不乏部分基于开源框架开发而来。
但崩溃监控分析服务，除了需要关注监控崩溃问题的场景数据以外，还需考量额外辅助信息的全面性，场景覆盖，实时性和分析统计的能力。

综合比较，Crashlytics 因为服务器在国外，所以不太稳定，暂不考虑；友盟是以统计业务为主的，crash 分析后台使用起来也比不太友好。
Bugly 相比 BugHD 和 友盟 的优点在于以下几个方面：

• 平台功能强大，除了跟踪 bug，还有上报自定义错误（日志）、异常，以及监控卡顿的功能。
• 收集的崩溃信息比较全面，除了崩溃本身的信息之外，还记录了一些页面信息、用户停留时长、跟踪日志等辅助信息，更利于定位问题。
• 在技术支持方面，Bugly 有专门的论坛、微信公众号和活跃的 QQ 群。
• 使用者广泛，腾讯自家的产品也在用，国内许多产品也选择 bugly。
• 技术实力上，腾讯有更强的技术储备和人力。
• 个人使用经历上，之前使用过 Bugly，通过 Bugly 来记录、分析崩溃和上传日志，感觉都还不错，具体有什么坑还没碰到过。没用过BugHD，但是看过 BugHD 的演示 Demo，比较简单，更多地是用来单纯查看 crash 记录的。

5.问题

5.1 Crash 堆栈不可读，需要上传符号表？
上报的崩溃堆栈是应用部分只有地址信息的，需要配置符号表才能对上报的崩溃进行符号化，或者可以开启进程内还原。

5.2 什么是符号表？
iOS 的应用编译的时候生产的 dSYM 文件，一般在 build 目录下，名称为 *.app.dSYM 的一个目录。 BugHD 或者 bugly 会对这个符号表文件进行解析，取出有用的信息，得到一个较小的新符号表用于上传。

6.崩溃预防措施：

• 记录每一次发生崩溃的原因，减少同样问题的重复发生
• AvoidCrash
• 常见崩溃原因：
  • 数组越界
  • 处理字符串时索引越界
  • 内存溢出
  • 内存管理（访问已经释放掉的对象）
  • CPU 暴增
  • 未知选择器（unrecognized selector）
  • API 不兼容
  • 除以 0 导致后续访问一个 Nan 的值
  • 传空值，比如往 NSDictionary 或者 NSArray 中插入 nil
  • 解析服务端返回的 JSON 数据后，出现 NSNull，间接引起的崩溃
  • block 回调时没有判空
  • How Not to Crash
  • iOS崩溃crash大解析

7.参考：

• 漫谈iOS Crash收集框架

• iOS 启动连续闪退保护方案

• iOS开发技巧－崩溃调试

• iOS Crash文件的解析

• 做一个 App 前需要考虑的几件事

• 移动开发之崩溃监控分析服务

• Bugly iOS 符号表配置