search

ShannonChenCHN / iOSDevLevelingUp

A journey of leveling up iOS development skills and knowledge.
365 stars 105 forks source link

性能调优和监控体系 #26

Open ShannonChenCHN opened 7 years ago

ShannonChenCHN commented 7 years ago

性能调优和监控体系

参考资料汇总

关联专题

ShannonChenCHN commented 6 years ago

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 commented 5 years ago

崩溃分析

参考

ShannonChenCHN commented 4 years ago

Crash Reporter

1.崩溃监控的原理：

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

开源框架：

平台：

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 和 友盟 的优点在于以下几个方面：

5.问题

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

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

6.崩溃预防措施：

7.参考：