iOS性能优化

CPU和GPU

在屏幕成像的过程中，CPU 和 GPU 起着至关重要的作用。

CPU（Central Processing Unit，中央处理器）

• 对象的创建和销毁、对象属性的调整、布局计算、文本的计算和排版、图片的格式转换和解码、图像的绘制（Core Graphics）

GPU（Graphics Processing Unit，图形处理器）

• 纹理的渲染

在 iOS 中是双缓冲机制，有前帧缓存、后帧缓存。

卡顿解决的主要思路就是尽可能减少 CPU、GPU 资源消耗。

屏幕成像原理

当电子束完成一帧的扫描，将要从头开始扫描时，就会发出一个 垂直同步信号，然后发出多个 水平同步信号。

只有当视频控制器接收到 VSync 之后，才会将帧缓冲器中的位图更新为下一帧，进而将帧缓存中的数据传输给显示器。

卡顿产生原因

在收到 VSync 后，CPU 计算 和 GPU 渲染还未处理完，就会导致丢帧（掉帧），屏幕上还是显示上一帧的数据。

卡顿优化

CPU

尽量用轻量级的对象，比如用不到事件处理的地方，可以考虑使用 CALayer 取代 UIView。

不要 频繁地 调用 UIView 的相关属性，比如 frame、bounds、transform 等属性，尽量减少不必要的修改。

尽量提前计算好布局，在有需要时一次性调整对应的属性，不要多次修改属性。

Autolayout 会比直接设置 frame 消耗更多的 CPU 资源。

图片的 size 最好刚好跟 UIImageView 的 size 保持一致。

控制一下线程的最大并发数量。

尽量把耗时的操作放到子线程，比如：

• 文本处理（尺寸计算、绘制）
• 图片处理（解码、绘制）

GPU

尽量避免短时间内大量图片的显示，尽可能将多张图片合成一张进行显示。

GPU 能处理的最大纹理尺寸是 4096x4096，一旦超过这个尺寸，就会占用 CPU 资源进行处理，所以纹理尽量不要超过这个尺寸。

尽量减少视图数量和层次。

减少透明的视图（alpha<1），不透明的就设置 opaque 为 YES。

尽量避免出现 离屏渲染。

离屏渲染

在 OpenGL 中，GPU 有 2 种渲染方式：

• On-Screen Rendering：当前屏幕渲染，在当前用于显示的屏幕缓冲区进行渲染操作。
• Off-Screen Rendering：离屏渲染，在当前屏幕缓冲区以外新开辟一个缓冲区进行渲染操作。

离屏渲染消耗性能的原因：

• 需要创建新的缓冲区。
• 离屏渲染的整个过程，需要多次切换上下文环境，先是从当前屏幕（On-Screen）切换到离屏（Off-Screen）；等到离屏渲染结束以后，将离屏缓冲区的渲染结果显示到屏幕上，又需要将上下文环境从离屏切换到当前屏幕。

哪些操作会触发离屏渲染？
光栅化：layer.shouldRasterize = YES。

遮罩：layer.mask。

圆角：同时设置 layer.masksToBounds = YES、layer.cornerRadius 大于 0。考虑通过 CoreGraphics 绘制裁剪圆角，或者叫美工提供圆角图片。

阴影：layer.shadowXXX，如果设置了 layer.shadowPath 就不会产生离屏渲染。

卡顿检测

平时所说的 卡顿 主要是因为在主线程执行了比较耗时的操作。

可以添加 Observer 到主线程 RunLoop 中，通过监听 RunLoop 状态切换的耗时，以达到监控卡顿的目的。

具体流程

创建一个 CFRunLoopObserverContext 观察者。

将创建好的观察者添加到主线程 RunLoop 的 kCFRunLoopCommonModes 模式下观察。

创建一个持续的子线程专门用来监控主线程的 RunLoop 状态。

一旦发现进入睡眠前的 kCFRunLoopBeforeSources 状态，或者唤醒后的状态 kCFRunLoopAfterWaiting，在设置的时间阈值内一直没有变化，即可判定为卡顿。

dump 出堆栈的信息，从而进一步分析出具体是哪个方法的执行时间过长。

RunLoop 所有状态：

typedef CF_OPTIONS(CFOptionFlags, CFRunLoopActivity) {
    kCFRunLoopEntry , // 进入 loop
    kCFRunLoopBeforeTimers , // 触发 Timer 回调
    kCFRunLoopBeforeSources , // 触发 Source0 回调
    kCFRunLoopBeforeWaiting , // 等待 mach_port 消息
    kCFRunLoopAfterWaiting ), // 接收 mach_port 消息
    kCFRunLoopExit , // 退出 loop
    kCFRunLoopAllActivities  // loop 所有状态改变
}

开源的卡顿监控代码：https://github.com/UIControl/LXDAppFluecyMonitor

耗电优化

iOS 中耗电主要来源于下面4个方面：

• CPU 处理，Processing
• 网络，Networking
• 定位，Location
• 图像，Graphics

耗电优化具体实施

尽可能降低 CPU、GPU 功耗

少用定时器

优化 I/O 操作

• 尽量不要频繁写入小数据，最好批量一次性写入。
• 读写大量重要数据时，考虑用 dispatch_io，其提供了基于 GCD 的异步操作文件 I/O 的 API。用 dispatch_io 系统会优化磁盘访问。
• 数据量比较大的，建议使用数据库（比如 SQLite、CoreData）。

网络优化

• 减少、压缩网络数据。
• 如果多次请求的结果是相同的，尽量使用缓存。
• 使用断点续传，否则网络不稳定时可能多次传输相同的内容。
• 网络不可用时，不要尝试执行网络请求。
• 让用户可以取消长时间运行或者速度很慢的网络操作，设置合适的超时时间。
• 批量传输，比如，下载视频流时，不要传输很小的数据包，直接下载整个文件或者一大块一大块地下载。如果下载广告，一次性多下载一些，然后再慢慢展示。如果下载电子邮件，一次下载多封，不要一封一封地下载。

定位优化

• 如果只是需要快速确定用户位置，最好用 CLLocationManager 的 requestLocation 方法。定位完成后，会自动让定位硬件断电。
• 如果不是导航应用，尽量不要实时更新位置，定位完毕就关掉定位服务。
• 尽量降低定位精度，比如尽量不要使用精度最高的 kCLLocationAccuracyBest。
• 需要后台定位时，尽量设置 pausesLocationUpdatesAutomatically 为 YES，如果用户不太可能移动的时候系统会自动暂停位置更新。
• 尽量不要使用 startMonitoringSignificantLocationChanges，优先考虑 startMonitoringForRegion:。

硬件检测优化

• 用户移动、摇晃、倾斜设备时，会产生动作 (motion) 事件，这些事件由加速度计、陀螺仪、磁力计等硬件检测。在不需要检测的场合，应该及时关闭这些硬件。

APP的启动优化

APP 的启动可以分为2种：

• 冷启动（Cold Launch）：从零开始启动 APP。
• 热启动（Warm Launch）：APP 已经在内存中，在后台存活着，再次点击图标启动 APP。

APP 启动时间的优化，主要是针对冷启动进行优化。

通过添加环境变量可以打印出 APP 的启动时间分析（Edit scheme -> Run -> Arguments）
DYLD_PRINT_STATISTICS 设置为 1。

如果需要更详细的信息，那就将 DYLD_PRINT_STATISTICS_DETAILS 设置为 1。

冷启动过程

APP 的冷启动可以概括为3大阶段：dyld、runtime、main。

dyld

dyld（dynamic link editor），Apple 的 动态链接器，可以用来装载 Mach-O 文件（可执行文件、动态库等）。

启动 APP 时，dyld 所做的事情有：

• 装载 APP 的可执行文件，同时会递归加载所有依赖的动态库。
• 当 dyld 把可执行文件、动态库都装载完毕后，会通知 Runtime 进行下一步的处理。

runtime

启动 APP 时，runtime 所做的事情有：

• 调用 map_images 进行可执行文件内容的解析和处理。
• 在 load_images 中调用 call_load_methods，调用所有 Class 和 Category 的 +load 方法。
• 进行各种 objc 结构的初始化（注册 Objc 类 、初始化类对象等等）。
• 调用 C++ 静态初始化器和 __attribute__((constructor)) 修饰的函数。

到此为止，可执行文件和动态库中所有的符号 (Class，Protocol，Selector，IMP，…) 都已经按格式成功加载到内存中，被 runtime 所管理。

main

APP 的启动由 dyld 主导，将可执行文件加载到内存，顺便加载所有依赖的动态库。

并由 runtime 负责加载成 objc 定义的结构。

所有初始化工作结束后，dyld 就会调用 main 函数。

接下来就是执行 UIApplicationMain 函数，AppDelegate 的 application:didFinishLaunchingWithOptions: 方法。

冷启动优化

dyld 阶段：

• 减少动态库、合并一些动态库（定期清理不必要的动态库）
• 减少Objc类、分类的数量、减少Selector数量（定期清理不必要的类、分类）
• 减少C++虚函数数量
• Swift尽量使用struct

runtime 阶段：

• 用 +initialize 方法和 dispatch_once 取代所有的 __attribute__((constructor))、C++ 静态构造器、ObjC 的 +load。

main 阶段：

• 在不影响用户体验的前提下，尽可能将一些操作延迟，不要全部都放在 application:didFinishLaunchingWithOptions: 方法中。
• 按需加载。

安装包瘦身

安装包（IPA）主要由可执行文件、资源组成。

资源（图片、音频、视频等）

• 采取无损压缩
• 去除没有用到的资源：https://github.com/tinymind/LSUnusedResources。

可执行文件瘦身

• Strip Linked Product、Make Strings Read-Only、Symbols Hidden by Default 设置为 YES。
• 去掉异常支持，Enable C++ Exceptions、Enable Objective-C Exceptions 设置为 NO，Other C Flags 添加 -fno-exceptions。

利用 AppCode 检测未使用的代码：菜单栏 -> Code -> Inspect Code。

编写 LLVM 插件检测出重复代码、未被调用的代码。

LinkMap

生成 LinkMap 文件，可以查看可执行文件的具体组成，检查每个类占用空间大小。

将 Build Settings -> Write Link Map File 设置为 YES 即可生成 LinkMap 文件。

可借助第三方工具解析 LinkMap 文件：https://github.com/huanxsd/LinkMap