iOS Crash


title: iOS Crash

categories: iOS优化

Understanding and Analyzing Application Crash Reports

稳定性

APP 稳定性方面主要是减少异常及崩溃,针对这部分,可以从 Category、Method Swizzling 以及静态分析来入手。

1.1 Category 分析

Category可以为现有的类添加方法,但是Category方法的不规范使用很容易引发问题,其中最容易出现的就是重名问题。重名问题分为两种情况,一种是APP内的不同业务Category重名,另一种是APP内的Category方法与系统API重名,包括系统私有API。

首先是不同业务的Category方法重名。如果是相同的逻辑,这种情况是方法重复,只保留一份可以减少冗余代码及安装包大小,减少rebase/binding time。如果是不同的逻辑,那么会导致只有一份逻辑生效,其他业务就会产生逻辑错误甚至导致崩溃。

如果是与系统API重名,那么可能影响系统逻辑,尤其是与私有API重名时,很难发现问题(因为document中搜不到)。之前曾发生过APP逻辑异常但一直找不到原因的情况,后来发现是Category方法与系统私有API重名导致。

比较规范的做法是Category名加前缀,但是一些开发人员可能由于各种原因没有这么做。为了及时发现重名情况,爱奇艺技术团队创建了一个工具进行监控,工具会定期将APP中所有Category方法汇总,分析有无重名情况。与系统API的对比需要先将系统API提取出来,公开的API可以通过解析系统库头文件来提取API,私有API可以通过class dump系统库,然后用结果中所有的API减去头文件中的提取的API,就是私有API。这样就得到一份iOS系统的所有API,用APP中的Category方法跟系统所有API求交集,就可以得到与系统API重名的Category方法。

1.2 Method swizzling 分析

Method swizzling 可以解决很多问题,但也会引发一些问题。一般情况下,Method swizzling主要是为系统方法插入一些逻辑,但有时也会导致修改系统逻辑的情况出现。之前遇到过某些业务修改了系统实现,导致特殊情况下APP的崩溃,比如当NSArray的元素超过五万时,对象的一些方法会走系统优化后的方法,所以针对这些方法的swizzling都会出现问题。

为统计各业务Method swizzling的使用情况,团队针对使用了method_exchangeImplementations的库进行初筛,针对使用了swizzling的库使用ar -x后,再针对.o文件进行二次筛选。最后通过反编译工具,反编译.o文件,就可以查到使用swizzling的具体方法。对于新增了swizzling使用的库需要严格审核,确保无问题后才合并到主工程。

1.3 静态分析

静态分析可以有效地发现并预防一些问题,如使用 Xcode 自带的 Analyze 以及 Facebook 的 infer 工具。注册观察者未移除、delegate 没使用 weak 修饰、对象未使用以及未做类型或 null 的判断都可以通过静态分析及时发现。

这块要做的主要目的是跟踪分析结果,了解各版本以及各个库新增了多少,修复了多少,掌握其自动创建修复任务及分配情况,确保问题提早发现,数量能够及时收敛。

iOS Crash

上一篇:ELK-filter过滤器使用方法


下一篇:FBI*安全专家的黑历史:曾是天才诈骗犯