面试题：Objective-C崩溃日志符号化后的深入分析

Question

假设你已经获取了Objective-C项目符号化后的崩溃日志，日志中显示某个方法调用导致崩溃，然而该方法在项目代码中有多处重载。你如何利用崩溃日志中的信息，更精准地定位到引发崩溃的具体代码位置，并说明可能涉及到的调用栈分析方法。

Answer 1

1. 定位具体代码位置：
   • 查看崩溃日志中的调用栈信息：崩溃日志的调用栈通常会包含方法调用的顺序以及所在文件和行号（如果符号化正确）。在Objective - C中，调用栈会显示类名和方法名。例如，调用栈可能类似这样：-[MyViewController myOverloadedMethod:withParam:] (in MyApp) (MyViewController.m:42)。这里MyViewController是类名，myOverloadedMethod:withParam:是方法名，MyViewController.m:42指明了在MyViewController.m文件的第42行调用了这个方法，由此可定位到引发崩溃的代码位置。
   • 关注参数信息：如果崩溃日志能获取到方法调用时传入的参数，不同重载方法可能接受不同类型或数量的参数。通过分析参数类型和数量，与项目中各重载方法的声明对比，可确定具体调用的是哪个重载方法。比如一个重载方法声明为-(void)myOverloadedMethod:(NSString *)str;，另一个为-(void)myOverloadedMethod:(NSNumber *)num;，若崩溃日志显示传入的是NSString类型参数，就可确定调用的是第一个重载方法。
2. 调用栈分析方法：
   • 符号化调用栈：确保崩溃日志已经符号化，符号化后的调用栈能将内存地址转换为具体的类名、方法名和文件行号等有意义的信息。如果没有符号化，需要使用atos工具（在Mac系统终端中），结合对应的dSYM文件（包含符号表信息）对调用栈中的地址进行符号化。例如，假设调用栈中有一个地址0x100002f34，在终端中使用命令atos -arch arm64 -o /path/to/MyApp.app/MyApp 0x100002f34 -l 0x100000000（其中arm64是架构，/path/to/MyApp.app/MyApp是应用程序路径，0x100000000是加载地址，可从崩溃日志中获取），将地址转换为可读的符号信息。
   • 分析方法执行顺序：调用栈是按方法调用顺序从下到上排列的。从栈底开始，最底部的方法通常是应用程序的入口点相关方法（如main函数等），往上逐步分析每个方法的调用，了解方法调用的逻辑链条。通过这种方式，可以理解崩溃发生前整个业务逻辑的执行路径，有助于发现错误的源头。例如，可能发现某个数据预处理方法没有正确处理数据，导致后续重载方法调用时崩溃。
   • 结合项目代码和业务逻辑：将调用栈中的方法与项目代码对应起来，结合业务逻辑分析。比如在一个电商购物车功能中，调用栈显示在-[CartViewController updateCart:withProduct:]方法处崩溃，结合业务逻辑可知这个方法用于更新购物车商品信息，那么就可以重点检查该方法的实现逻辑，以及调用该方法之前对商品数据的处理逻辑是否正确。