前言随着移动互联网的发展，产品的更新迭代，公司业务的不断扩展，移动应用页面布局也越来越复杂，效果越来越炫，自身业务功能越来越多。市面上大部分产品中还接入了大量三方的SDK。随之而来的是App安装包越来越大，界面加载越来越慢，运行速度越来越低。当界面响应时间超出用户能容忍的时间临界点后，大多数用户都会选择强制关闭该应用，不再等待响应。应用给用户留下了很卡，很笨重的印象后，将会大大提高用户的流失率。
CPU和GPU
CUP 中央处理器（CPU，central processing unit）对象的创建和销毁、对象属性的调整、布局计算、文本的计算和排版、图片格式转换和解码、图像的绘制（Core Graphics）
GPU 图形处理器（Graphics Processing Unit) 纹理（Texture）和顶点描述（三角形），应用变换（transform）、混合（合成）并渲染，然后输出到屏幕上。通常你所能看到的内容，主要也就是纹理（图片）和形状（三角模拟的矢量图形）两类
由上图可知：屏幕上显示视图，需要CPU和GPU一起协作，CPU 负责计算，将计算好的数据提交给GPU，GPU进行渲染并放入到缓冲区，然后视频控制器按照VSync信号逐行读取帧缓冲区的数据，经过数模转换传递为显示器，显示到屏幕上
注意：在iOS中是双缓冲机制，有前帧缓冲、后帧缓冲。即GPU会预先渲染好一帧放入一个缓冲区内（前帧缓存），让视频控制器读取，当下一帧渲染好后，GPU会直接把视频控制器的指针指向第二个缓冲器（后帧缓存）。当你视频控制器已经读完一帧，准备读下一帧的时候，GPU会等待显示器的VSync信号发出后，前帧缓存和后帧缓存会瞬间切换，后帧缓存会变成新的前帧缓存，同时旧的前帧缓存会变成新的后帧缓存。
屏幕成像原理
解释 绿色的可以当做我们的手机屏幕，如果要显示一个页面，会发出一个垂直同步信号(Vsync) 代表这一帧的开始，然后发出水平同步信号(HSync)等最后一条结束，也就代表这一帧数据渲染完成。然后在进行下一帧的播放
卡顿产生的原因
CPU将计算好的数据提供给GPU进行渲染，这时来一个垂直同信号VSync，将这一帧渲染到屏幕上 ，代表这一帧结束，然后进行下一帧的渲染。
上图，CPU消耗时间过长，交付给GPU时，垂直信号VSync到了，GPU还在渲染。下一帧，CPU把处理好的数据交付给GPU渲染屏幕，垂直信号到了，但是CPU还在渲染，就会把上一帧的数据显示到屏幕上，这就造成了卡顿。
因此，在CPU和GPU还在处理数据的时候，垂直信号VSync已经来了，便造成了卡顿
卡顿解决的主要思路
- 尽可能减少
CPU、GPU资源消耗 - 按照60FPS的刷帧率，每隔16ms就会有一次VSync信号
卡顿优化——CPU
- 尽量用轻量级的对象(1,2,3数字的显示直接使用Int就行，不用使用NSNumber)，比如用不到事件处理的地方，可以考虑使用CALayer取代UIView
- 不要频繁地调用UIView的相关属性，比如Frame、bounds、transform等属性，尽量减少不必要的修改
- 尽量提前计算好布局，在有需要时一次性调整对应的属性，不要多次修改属性
- Autolayout会比直接设置frame消耗更多的CPU资源
- 图片的size最好刚好跟UIImageView的size保持一致
- 控制一下线程的最大并发数量
- 文本处理（尺寸计算、绘制）
// 文字计算
[@"text" boundingRectWithSize:CGSizeMake(100, MAXFLOAT) options:NSStringDrawingUsesLineFragmentOrigin attributes:nil context:nil];
// 文字绘制
[@"text" drawWithRect:CGRectMake(0, 0, 100, 100) options:NSStringDrawingUsesLineFragmentOrigin attributes:nil context:nil];
- 图片处理（解码、绘制）
UIImageView *imageView = [[UIImageView alloc] init];
imageView.frame = CGRectMake(100, 100, 100, 56);
[self.view addSubview:imageView];
self.imageView = imageView;
// 通过imageNamed加载图片，（加载上来的是经过压缩后的二进制数据，真正想要渲染到屏幕上，还需要解码成屏幕所需要的那种格式才会显示到屏幕上（解码是在主线程操作的，要是话费很长时间，就行形成卡顿））因此我们放在子线程，去解码，放在主线程显示
// self.imageView.image = [UIImage imageNamed:@"timg"];
dispatch_async(dispatch_get_global_queue(0, 0), ^{
// 获取CGImage
CGImageRef cgImage = [UIImage imageNamed:@"timg"].CGImage;
// alphaInfo
CGImageAlphaInfo alphaInfo = CGImageGetAlphaInfo(cgImage) & kCGBitmapAlphaInfoMask;
BOOL hasAlpha = NO;
if (alphaInfo == kCGImageAlphaPremultipliedLast ||
alphaInfo == kCGImageAlphaPremultipliedFirst ||
alphaInfo == kCGImageAlphaLast ||
alphaInfo == kCGImageAlphaFirst) {
hasAlpha = YES;
}
// bitmapInfo
CGBitmapInfo bitmapInfo = kCGBitmapByteOrder32Host;
bitmapInfo |= hasAlpha ? kCGImageAlphaPremultipliedFirst : kCGImageAlphaNoneSkipFirst;
// size
size_t width = CGImageGetWidth(cgImage);
size_t height = CGImageGetHeight(cgImage);
// context
CGContextRef context = CGBitmapContextCreate(NULL, width, height, 8, 0, CGColorSpaceCreateDeviceRGB(), bitmapInfo);
// draw
CGContextDrawImage(context, CGRectMake(0, 0, width, height), cgImage);
// get CGImage
cgImage = CGBitmapContextCreateImage(context);
// into UIImage
UIImage *newImage = [UIImage imageWithCGImage:cgImage];
// release
CGContextRelease(context);
CGImageRelease(cgImage);
// back to the main thread
dispatch_async(dispatch_get_main_queue(), ^{
self.imageView.image = newImage;
});
});
卡顿优化——GPU
- 尽量避免短时间内内大量图片的显示，尽可能将多张图片合成一张进行显示
- GPU能处理的最大纹理尺寸是4096*4096，一旦超过这个尺寸，就会占用CPU资源进行处理，所以纹理尽量不要超过这个尺寸
- 尽量减少视图数量和层次
- 减少透明的视图（alpha<1），不透明的就设置opaque为YES
- 尽量避免出现离屏渲染
离屏渲染
在OpenGL中，GPU有2中渲染方式
1、On-Screen Rendering ：当前屏幕渲染，在当前用于显示的屏幕缓冲区进行渲染操作
2、Off-Screen Rendering：离屏渲染，在当前屏幕缓冲区以外新开辟一个缓冲区进行渲染操作
离屏渲染消耗性能的原因
- 需要创建新的缓冲区
- 离屏渲染的整个过程，需要多次切换上下文环境，先是从当前屏幕（On-Screen）切换到离屏（Off-Screen）；等到离屏渲染结束以后，将离屏渲染缓冲区结果显示到屏幕上，又需要将上下文环境从离屏渲染切换到当前屏幕
哪些操作会触发离屏渲染
- 光栅化，
layer.shouldRasterize = YES - 遮罩，
layer.mask - 圆角，同时设置
layer.masksToBounds = YES和layer.cornerRadius大于0 （可以使用CoreGraphics绘制裁剪圆角，或者美工提供圆角） - 阴影，但是设置了
layer.shadowPath就不会产生离屏渲染，（如果不设置，会默认是四周）
卡顿检测
平时所说的“卡顿”主要是因为在主线程执行了比较耗时的操作
可以添加Observer到主线程RunLoop中，通过监听RunLoop状态切换的耗时，已达到监控卡顿的目的
可以使用第三方来检查
LXDAppFluecyMonitor
耗电
耗电的主要来源
- CPU处理，Processing
- 网络，Networking
- 定位，Location
- 图像，Graphics
耗电优化
- 尽可能降低CPU、GPU功耗
- 少用定时器
- 优化I/O操作
- 尽量不要频繁写入小数据，最好批量一次写入
- 读写大量重要数据是，考虑用dispatch_io，其提供了基于GCD的异步操作文件I/O的API，用dispatch_io 系统会优化磁盘访问
- 数据量比较大的，建议使用数据库
- 网络优化
- 减少。压缩网络数据
- 如果多次请求的结果是相同的，尽量使用缓存
- 使用断点续传，否则网络不稳定是可能多次传输相同的内容
- 网络不可用时，不要尝试执行网络请求
- 让用户可以取消长时间运行或者速度很慢的网络操作，设置合适的超时时间
- 批量传输，比如，下载视频流时，不要传输很小的数据包，直接下载整个文件或者一大块一大块的下载，如果下载广告，一次性多下载一些，然后慢慢展示，如果下载电子邮件，一次下载多封，不要一封一封的下载
- 定位优化
- 如果只是需要快速确定用户位置，最好用
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
-
Total pre-main time: 517.71 milliseconds (100.0%)
dylib loading time: 77.67 milliseconds (15.0%)
rebase/binding time: 341.38 milliseconds (65.9%)
ObjC setup time: 68.20 milliseconds (13.1%)
initializer time: 30.33 milliseconds (5.8%)
slowest intializers :
libSystem.B.dylib : 5.86 milliseconds (1.1%)
libMainThreadChecker.dylib : 15.35 milliseconds (2.9%)
- 如果需要更详细的信息，那就将
DYLD_PRINT_STATISTICS_DETAILS设置为1
total time: 934.78 milliseconds (100.0%)
total images loaded: 258 (0 from dyld shared cache)
total segments mapped: 767, into 102624 pages with 7415 pages pre-fetched
total images loading time: 574.67 milliseconds (61.4%)
total load time in ObjC: 54.87 milliseconds (5.8%)
total debugger pause time: 400.53 milliseconds (42.8%)
total dtrace DOF registration time: 0.18 milliseconds (0.0%)
total rebase fixups: 2,723,929
total rebase fixups time: 260.40 milliseconds (27.8%)
total binding fixups: 286,643
total binding fixups time: 18.46 milliseconds (1.9%)
total weak binding fixups time: 0.42 milliseconds (0.0%)
total redo shared cached bindings time: 26.57 milliseconds (2.8%)
total bindings lazily fixed up: 0 of 0
total time in initializers and ObjC +load: 25.74 milliseconds (2.7%)
libSystem.B.dylib : 2.44 milliseconds (0.2%)
libBacktraceRecording.dylib : 3.09 milliseconds (0.3%)
CoreFoundation : 2.08 milliseconds (0.2%)
Foundation : 1.29 milliseconds (0.1%)
libMainThreadChecker.dylib : 14.34 milliseconds (1.5%)
total symbol trie searches: 134026
total symbol table binary searches: 0
total images defining weak symbols: 22
total images using weak symbols: 62
APP的冷启动可以概括为3个阶段
- dyld
dyld（dynamic link editor），Apple的动态链接器，可以用来装载Mach-O文件（可执行文件、动态库等）
启动APP时，dyld所做的事情有
1、装载APP的可执行文件，同时会递归加载所有依赖的动态库
2、当dyld把可执行文件、动态库都装载完毕后，会通知Runtime进行下一步的处理
- runtime
启动APP时，runtime所做的事情有
1、调用map_images进行可执行文件内容的解析和处理
2、在load_images中调用call_load_methods，调用所有Class和Category的+load方法
3、进行各种objc结构的初始化（注册Objc类 、初始化类对象等等）
4、调用C++静态初始化器和__attribute__((constructor))修饰的函数
5、到此为止，可执行文件和动态库中所有的符号(Class，Protocol，Selector，IMP，…)都已经按格式成功加载到内存中，被runtime 所管理
- main
1、APP的启动由dyld主导，将可执行文件加载到内存，顺便加载所有依赖的动态库
2、并由runtime负责加载成objc定义的结构
3、所有初始化工作结束后，dyld就会调用main函数
4、接下来就是UIApplicationMain函数，AppDelegate的application:didFinishLaunchingWithOptions:方法
启动优化方案
dyld
- 减少动态库，合并一些动态库（定期清理不必要的动态库）
- 减少Objc类、分类的数量、减少Selector数量（定期清理不必要的类、分类）。
- 减少C++虚函数数量
- Swift尽量使用struct
runtime
- 用
+initialize方法和dispatch_once取代所有的_attribute_((constructor))、C++静态构造器、Objc的load
main
- 在不影响用户体验的前提下，尽可能将一些操作延迟、不要全部都放在finishLaunching方法中
- 按需加载
安装包瘦身
安装包（IPA）主要由可执行文件、资源组成
资源（图片、音频、视频等）
- 采取无损压缩
- 去除没有用到的资源：https://github.com/tinymind/LSUnusedResources
可执行文件瘦身
编译器优化
Strip Linked Product、Make Strings Read-Only、Symbols Hidden by Default设置为YES(一般Xcode会自动设置为yes)
去掉异常支持，Enable C++ Exceptions、Enable Objective-C Exceptions设置为NO， Other C Flags添加-fno-exceptions
利用AppCode（https://www.jetbrains.com/objc/）检测未使用的代码：菜单栏 -> Code -> Inspect Code
编写LLVM插件检测出重复代码、未被调用的代码
LinkMap
-
生成LinkMap文件，可以查看可执行文件的具体组成
linkMap
- 可借助第三方工具解析LinkMap文件： https://github.com/huanxsd/LinkMap
获取linkMap文件
1.在XCode中开启编译选项Write Link Map File \n
XCode -> Project -> Build Settings -> 把Write Link Map File选项设为yes，并指定好linkMap的存储位置
2.工程编译完成后，在编译目录里找到Link Map文件（txt类型) 默认的文件地址：~/Library/Developer/Xcode/DerivedData/XXX-xxxxxxxxxxxxx/Build/Intermediates/XXX.build/Debug-iphoneos/XXX.build/ \n\
可以看到 下面是项目每个类生成的.o文件
