iOS优化
2017-09-13 本文已影响0人
xiaoyaoyouzi
性能优化一般分为两类：
- 业务逻辑实现优化
- 卡顿情况优化
卡顿情况优化方式
- 合理的线程
由于GCD太方便了，如果不加控制，大部分需要抛到子线程操作都会被直接加在global队列中，这样会导致两个问题：1.开的线程越来越多，线程的开销逐渐明显，因为开启线程需要占用一定的内存空间（默认情况下，主线程占1M，子线程占用512k）。2.多数情况下，网络回调的时序问题，导致数据处理错乱，而且不容易发现，为此我们为项目制定了一些基本原则：
- UI和DataSource的操作一定在主线程
- DB操作，日志记录和网络回调都是在各自固定的县城
- 不同业务可以通过创建队列保证数据一致性。
合理的线程分配，最终目的就是保证主线程尽量少的处理非UI操作，同时控制整个APP的子线程数量在合理的范围之类。
- 预处理和延时加载
- 预处理是将初次显示需要耗费大量线程时间的操作，提前放到后台线程进行计算，再将结果数据拿来显示
- 延时加载，首先加载当前必须的可视内容，再稍后一段时间内，或特定事件时，在触发其他内容的加载，这种方式可以很有效地提升页面绘制速度，使体验更加流畅。（UITableView就是最典型的例子）。
这两种方法都是在资源比较紧张的情况下，优先处理马上要得到的数据，同时尽可能地提前加载即将要用到的数据。在微信读书中，阅读的排版是优先级最高的，所以在阅读过程中会预处理下一页，下一章的排版，同时可能会延时加载阅读相关的其他数据（如想法、划线、书签等）。
- 缓存
cache可能是所有性能优化中最常用的手段。但也是我们极不推荐的手段，cache建立的成本低，见效快，但是带来维护的成本也很高，如果一定要用，也请谨慎使用，并注意一下几点：
- 并发访问cache时，数据一致性问题
- cache线程安全问题，防止一边修改一边遍历的crash。
- cache查找时的性能问题
- cache的释放与重建，避免占用空间无限扩大，同时释放的粒度也依实际需求而定。
- 使用正确的API
使用正确的API，是指在满足业务的同时，能够选择性能更优的API。
-
选择合适的容器
-
了解ImageNamed:和imageWithContentOfFile:的差异。
-
缓存NSDateFormatter的结果
-
寻找 (NSDate *)dateFromString:(NSString )string 的替换品。
-
不要随意使用 NSLog().
-
当试图获取磁盘中一个文件的属性信息时，使用 [NSFileManager attributesOfItemAtPath:error:] 会浪费大量时间读取可能根本不需要的附加属性。这时可以使用 stat 代替 NSFileManager，直接获取文件属性：
离屏渲染问题
总结
RoundedCorner 在仅指定cornerRadius时不会触发离屏渲染，仅适用于特殊情况：contents为 nil 或者contents不会遮挡背景色圆角；
Shawdow 可以通过指定路径来取消离屏渲染；
Mask 无法取消离屏渲染；
以上效果在同等数量的规模下，对性能的影响等级：Shadow > RoundedCorner > Mask > GroupOpacity(迷之效果)。
任何时候优先考虑避免触发离屏渲染，无法避免时优化方案有两种：
Rasterization：适用于静态内容的视图，也就是内部结构和内容不发生变化的视图，对上面的所有效果而言，在实现成本以及性能上最均衡的。即使是动态变化的视图，开启 Rasterization 后能够有效降低 GPU 的负荷，不过在动态视图里是否启用还是看 Instruments 的数据。
规避离屏渲染，用其他手法来模拟效果，混合图层是个性能最好、耗能最少的通用优化方案，尤其对于 rounded corer 和 mask。
