本文已参与掘金创作者训练营第三期「话题写作」赛道,详情查看:掘力计划|创作者训练营第三期正在进行,「写」出个人影响力。
一、崩溃 crash
- 崩溃在iOS开发也是非常常见的一个问题,很优秀的程序也是有可能崩溃的。比如QQ、微信等。
- 对于用户而言也是一个不好的体验,在维护成本也会变大
常见的一个崩溃问题
- 数组越界
- 野指针
- 多线程安全
- KVO 。。。等等
解法
- 数组越界
- 如果是oc的开发者,可以使用方法交换,在调用函数中,先去判断是否越界(如果是字典,key是否存在)再去处理
- 或者在每次使用值的去判断,其是否存在
- 野指针
- oc中最常见的方法,就是中每次调用之前判断某个对象是否为nil
- 或者在oc中,通过runtime属性,给每一个属性添加一个get方法,进行初始化
- 这个其实中swift中很少出现,swift是强类型语言,强大的可选机制,但对象不存在的时候就不会执行其对应的数据的
- 多线程安全
- 使用线程的时候,注意多线程问题,避免僵尸对象,同时操作一个对象,记得加锁
try catch
try catch 主要用于捕获 crash
- try 就是需要捕获异常的对象
- catch 抛出异常
- finally 就是出现异常以后,执行以下代码
NSArray *arr = [[NSArray alloc] init];
@try {
NSLog(@"%@", arr[0]);
} @catch (NSException *exception) {
NSLog(@"%@", exception);
} @finally {
NSLog(@"finally");
}
感觉绝大多数iOS开发者对try catch的使用都是非常少的,没有后端对exception的面感度高;系统给我们很好的扩展我们需要多去使用
第三方工具
-
比如可以尝试app里接入一些第三方工具 bugly、bugtags、等等
-
通过分析发送给第三方工具的crash信息来确定具体的crash 原因
-
打完包以后要留一下打包文件,里面是有一个dSYM文件,可以找到对应的符号表信息
需要注意的是,构建版本会自动生成dSYM文件,但debug的时候,是没有的,需要我们手动开启。在build setting中搜索debug,将下面两项内容修改为正确的设置
最后根据bugly的文档,去解析平台的crash文件
最终找到crash的文件及方法
二、卡顿
app 卡顿常见的问题
- 文件加载过大
- 阻塞主线程
- 渲染 。。。等等
解法
- 绝大多数的耗时操作,尽量放到子线程去做
- 最终在主线程更新UI
- 在操作多线程的时候一定要注意线程安全
可以多用 Cache 比较大的数据的是做缓存处理
- 渲染的优化:
- 离屏渲染:在对layer做复杂操作的时候,会触发离屏渲染
- shouldRasterize(光栅化)
- masks(遮罩)
- shadows(阴影)
- edge antialiasing(抗锯齿)
- group opacity(不透明)
- 能操作view的尽量不去操作layer
table View 优化
- 避免使用比较复杂的Cell,可以使用hidden来隐藏,尽量减少在复用的时候去添加、减少view
- 尽量少用自动计算高度,label的自适应等(对于复杂的cell,尽量提前计算好)
- 减少xib、sb的cell布局(这个影响其实很小)
- 在滚动过程中,减少对cell的操作,布局等
- 根据滚动状态,cell的显示,来优化数据显示,cell的刷新,减少没显示的cell过多消耗性能
- 一定一定要检查UI更新正常, 不被网络,等其他异步操作阻塞线程
其他
可以使用xcode自带工具instrument来检测内存、耗时、僵尸进程等等
也可以使用tests,看测试某个函数的耗时情况
三、耗电
在xcode工具instrument选择测试的app,选中energy log来查看app的耗电情况
可以直接分析网络、Wi-Fi、cpu等使用的耗电情况
也可以结合卡顿去分析,卡死现场也是最耗电的。