iOS开发，线上问题/crash如何排查

opentogether

于 2024-12-23 12:08:54 发布

阅读量1.3k

点赞数 21

文章标签： ios cocoa macos

本文链接：https://blog.youkuaiyun.com/opentogether/article/details/144662803

版权

线上问题

在 iOS 开发中，线上问题的排查通常是一个挑战，因为在开发环境中无法直接复现用户的设备和网络环境。然而，通过一系列有效的工具和排查方法，我们可以逐步缩小问题范围并最终找到原因。以下是常见的线上问题排查方法和步骤。

1. 日志分析

Console 日志：在 iOS 应用中，打印日志（如 print() 或 NSLog）是非常常见的调试方法。对于线上问题，使用日志分析平台（如 Firebase Crashlytics、Sentry 或 Bugsnag）可以帮助我们查看崩溃报告、异常日志以及用户操作路径。
日志级别：在开发中使用不同级别的日志，如：
- print() 用于简单的调试。
- NSLog() 可以输出更多详细的系统信息。
- 使用 os_log()（iOS 10+）进行高效的日志记录，可以设置不同的日志级别（debug, info, error 等）。
远程日志：对于线上问题，可以通过集成远程日志系统（如 CocoaLumberjack、XCGLogger 等）来记录错误信息，尤其是需要追踪一些用户无法复现的问题。

2. Crash 报告分析

Crashlytics / Sentry：这类工具能够捕获应用崩溃信息，并提供详细的崩溃堆栈信息，帮助开发者定位崩溃的具体位置。通过查看崩溃日志中的堆栈信息，可以知道崩溃发生在哪个方法、行号、调用栈，以及崩溃的具体原因。
崩溃分类：如果崩溃报告中显示大量相同类型的崩溃，表示可能是一个普遍性问题。例如，空指针异常、数组越界、网络请求异常等。

3. 性能问题

Time Profiler：可以在 Xcode 的 Instruments 中使用 Time Profiler 来分析性能瓶颈。它会显示方法调用的时间，并且通过分析 CPU 使用率和内存使用情况来找出性能瓶颈。
Network Profiler：使用 Network Profiler 来分析应用的网络请求情况，是否有网络请求阻塞、超时或错误响应。
Leaks / Memory Graph：通过 Leaks 和 Memory Graph 来查看内存泄漏和对象的持有情况，避免内存问题导致应用崩溃或卡顿。
CPU 和内存消耗：如果线上出现卡顿或性能瓶颈，使用 Instruments 中的 CPU、Memory 和 Energy Log来分析哪些方法消耗了过多的系统资源。

4. 用户行为跟踪

Analytics：通过集成 Firebase Analytics、Mixpanel 或 Google Analytics 等用户行为分析工具，查看是否有异常的用户行为或操作流程导致问题发生。
A/B 测试：可以通过 A/B 测试工具（如 Firebase Remote Config 或 Optimizely）来验证是否某些版本、配置或功能引发了问题。

5. 网络问题

请求失败：如果遇到网络请求失败的问题，可以使用 Charles Proxy 或 Wireshark 等抓包工具，查看请求和响应的内容，确认是否存在 HTTP 错误码、超时或请求参数错误等问题。
网络环境：考虑到移动设备可能处于不同的网络环境中，可以使用 Network Link Conditioner 模拟不同的网络速度、延迟和丢包情况，来检查应用在各种网络环境下的表现。

6. 设备/OS 兼容性问题

设备型号和系统版本：通过分析线上崩溃报告和日志，可以发现是否某个特定的设备型号或系统版本（iOS 版本）容易出现问题。
自动化测试：可以使用 XCUITest 或 Appium 等自动化测试工具，模拟不同设备和系统版本进行测试，确保应用在所有支持的环境下正常运行。

7. App 状态管理

Background / Foreground 切换：某些问题只有在应用从后台切换到前台时才会发生。你需要特别关注应用的生命周期方法（如 applicationWillEnterForeground、applicationDidEnterBackground）以及这两个状态之间的数据同步。
App State：确保应用在不同状态下（如后台、前台、锁屏）能正确管理状态，例如中断的网络请求需要在恢复时正确处理。

8. 重现线上问题

用户重现步骤：有时线上问题是由于某些特定的用户操作步骤导致的。通过向用户询问他们的操作流程，或者通过日志追踪可以得知问题发生的前因后果。
设备和环境重现：如果有多种设备或 OS 版本，尝试在不同的设备上复现问题（例如，在模拟器和真机上）。

9. 时间相关问题

时间漂移：如果应用依赖于服务器时间或本地时间，在不同的设备、时区或夏令时情况下，可能会出现时间相关的错误。例如，日期计算、闹钟等问题。
定时器：使用不当的定时器或 GCD 定时任务可能会在应用挂起后重新启动时产生问题。

10. 异常处理

异常捕获：iOS 提供了 NSException 异常机制，能够捕获一些在运行时产生的异常错误。如果线上有崩溃，查看是否有未被捕获的异常。
错误回调：网络请求、文件操作等异步任务通常有错误回调，确认错误信息是否正确捕获，避免未处理的错误导致崩溃。

11. 回滚和版本控制

版本差异：如果线上问题出现在某个版本，可以通过版本对比（例如，使用 Git）查看具体的差异，并快速定位问题。
回滚操作：如果问题无法快速解决，及时回滚到之前的稳定版本，确保用户体验不受影响。

总结

线上问题的排查是一个多方面的工作，涉及到工具的使用、日志分析、用户行为追踪以及多种测试方法。通过以下几个步骤可以有效地排查问题：

分析崩溃报告和日志。
使用性能分析工具（如 Instruments）来排查性能瓶颈。
跟踪用户行为，发现潜在的用户操作问题。
网络抓包和调试，确认请求和响应的正确性。
重现线上问题，找到可能的根本原因。

通过这些方法，我们可以有效地定位线上问题并尽快修复，提高用户体验。

没有堆栈信息的crash，如何排查

在 iOS 开发中，没有堆栈信息的崩溃（crash）通常意味着崩溃发生在非托管代码（例如 C 或 C++ 代码）中，或者崩溃的堆栈信息由于某些原因（如内存损坏、过早的崩溃或优化等）没有被正确记录。解决这种崩溃的排查可以是非常具有挑战性的，但通过以下几种策略，可以帮助你尽可能地诊断和解决问题。

1. 启用符号化和崩溃日志

符号化崩溃日志：确保 Xcode 和你的构建设置正确配置，以便在应用崩溃时能够符号化崩溃日志。在没有符号化的情况下，你看到的崩溃日志通常只是一些内存地址，无法帮助你定位崩溃的具体位置。要符号化崩溃日志：
1. 在 Xcode 中，选择 Product -> Archive。
2. 在 Organizer 中，选择你的应用并查看崩溃报告。
3. 如果没有符号信息，可以从 App Store Connect 或 Firebase Crashlytics 下载符号文件（dSYM）并进行符号化。
Firebase Crashlytics 或 Sentry：集成崩溃报告工具，如 Firebase Crashlytics 或 Sentry，它们提供更加详细的崩溃信息，并且支持符号化未符号化的日志。

2. 查看崩溃日志的上下文信息

即使没有堆栈信息，崩溃日志中通常仍然包含有用的信息。仔细检查以下信息：

崩溃发生的线程：查看崩溃是否发生在主线程或后台线程。如果是主线程崩溃，可能是 UI 更新问题。
崩溃前的环境：检查崩溃时的设备类型、iOS 版本、设备内存等信息，可能会帮助你判断是否存在系统问题或硬件问题。
崩溃日志中的错误代码：有些崩溃会直接显示错误代码（例如，EXC_BAD_ACCESS，EXC_CRASH），这些信息有时能够指示崩溃原因。

3. 使用调试工具

如果崩溃发生在开发阶段或某个特定版本上，调试工具是查找没有堆栈信息的崩溃的重要手段：

Address Sanitizer：启用 Address Sanitizer 可以帮助你捕获内存损坏、缓冲区溢出等问题。在 Xcode 中启用 Address Sanitizer：
1. 打开 Scheme 设置。
2. 在 Diagnostics 选项卡中勾选 Address Sanitizer。
启用后，Xcode 会在应用崩溃时提供更多详细的内存访问错误信息，有助于定位崩溃原因。
Zombie Objects：如果崩溃是由于访问已释放的对象引起的，可以启用 Zombie Objects 来帮助捕获这个问题：
1. 在 Product -> Scheme -> Edit Scheme 中选择 Run。
2. 在 Diagnostics 选项卡中勾选 Enable Zombie Objects。
启用后，已释放的对象会变成“僵尸对象”，你可以在日志中看到哪些对象被访问了，这对查找崩溃原因非常有帮助。
Instruments：使用 Instruments 的 Leaks、Time Profiler 和 Allocations 等工具来检查内存泄漏、性能瓶颈和内存使用情况。这些工具可以帮助你检测到潜在的内存问题或资源消耗异常，间接帮助你排查崩溃。

4. 检查资源耗尽问题

没有堆栈信息的崩溃有时可能是由于资源（如内存、线程、CPU）耗尽造成的。可以通过以下方式进一步排查：

内存问题：使用 Xcode Instruments 中的 Leaks、Allocations 和 Memory Usage 工具来检查内存泄漏或过度使用内存的情况。内存泄漏和内存过度使用可能会导致应用崩溃。
CPU 占用率：如果崩溃时应用的 CPU 占用率非常高，可能是因为某个循环或计算占用了过多的 CPU 资源，导致应用崩溃。使用 Time Profiler 来检查应用的 CPU 使用情况。
线程问题：崩溃可能由并发问题引起（例如死锁或线程竞争），可以使用 Thread Sanitizer 来检查线程问题：
1. 打开 Product -> Scheme -> Edit Scheme。
2. 在 Diagnostics 中勾选 Thread Sanitizer。

5. 回溯崩溃前的用户操作

重现步骤：尝试回溯崩溃前用户的操作。如果可以重现，便可以在本地调试来进一步分析问题。例如，崩溃是否发生在特定功能或用户操作上，如网络请求、图片加载等。
崩溃模式：如果崩溃发生在特定的设备或 iOS 版本中，确定是否存在设备特有的兼容性问题。你可以通过获取设备信息、操作日志和用户报告来查看问题是否与特定环境有关。

6. 代码审查

非托管代码（C/C++）：崩溃可能发生在非托管代码中，如通过 Swift 或 Objective-C 调用 C/C++ 库。仔细审查可能涉及的 C/C++ 代码，确保指针操作、内存管理没有问题。
多线程和异步问题：仔细检查是否在多个线程或异步任务中对共享资源进行了访问，尤其是 UI 组件的访问。确保 UI 更新总是发生在主线程，避免竞争条件导致崩溃。

7. 第三方库问题

依赖检查：如果崩溃发生在第三方库中，检查该库是否为最新版本，或者是否存在已知的 bug。可以查看该库的 GitHub 或相关文档，确认是否有其他开发者报告了类似问题。
库更新：确保第三方库和 SDK（如 Firebase、Alamofire、CocoaPods 等）是最新的，并且没有已知的崩溃问题。

8. 排查工具和流程

Remote Debugging：在某些情况下，使用 remote debugging 工具可以帮助获取更多运行时信息。对于一些难以重现的问题，远程调试可能会有用。
Remote Logging：如果崩溃发生在线上用户设备，可以利用 Firebase Crashlytics、Sentry、Bugsnag 等远程日志工具来收集设备信息、崩溃时间、发生时的用户操作等信息。