卡顿优化优化方向

卡顿解决的主要思路

  1. 尽可能减少CPU、GPU资源消耗

  2. 按照60FPS的刷帧率，每隔16ms(1s/60)就会有一次VSync信号(也叫垂直同步信号)

  3. 在屏幕成像的过程中，CPU和GPU起着至关重要的作用 如果在这一帧内cpu或gpu的工作没有完成就会出现卡顿掉帧

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

对象的创建和销段、对象性的调整、布局计算、文本的计算和排板、图片的格式转换和解码、图像的绘制( Core Graphics)

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

纹理的渲染

工作流程

CPU进行计算之后交给GPU进行渲染然后存放到帧缓存，然后视频控制器读取帧缓存里面的内容显示到屏幕上去

卡顿优化详解

CPU的优化

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

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

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

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

  5. 图片的Size最好刚好跟UIImageView的size保持一致

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

  7. 尽量把耗时的操作放到子线程

  • (1)文本处理（尺寸计算、绘制）

  • (2)图片处理（解码、绘制）

GPU的优化

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

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

  3. 尽量減少视图数量和层次

  4. 减少透明的视图(alpha < 1)，不透明的就设置opaque为YES

  5. 尽量避免出现离屏渲染

离屏渲染

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

  1. On-Screen Rendering： 当前屏幕渲染，在当前用于显示的屏幕缓冲区进行渲染操作

  2. Off-Screen Rendering：商屏這染，在当前屏幕缓冲区以外新开牌一个缓冲区进行渲染操作

商屏渲染消耗性能的原因

  1. 需要创建新的缓冲区

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

哪些操作会触发离屏渲染？

  1. 光栅化，Layer.shouldRasterize = YES

  2. 遮罩，layer.mask

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

  4. 阴影，layer.shadow 当然如果设置了 layer.shadowPath就不会产生离屏渲染

卡顿检测

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

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

耗电优化

还是通过尽可能降低CPU、GPU功耗来减少耗电

  1. 少用定时器

  2. 优化IO操作

  • (1)尽量不要频繁写入小数据，最好批量一次性写入

  • (2)读写大量重要数据时，考虑用dispatch_io，其提供了基于GCD的异步操作文件I/O的API。用dispatch_io系统会优化磁盘访问

  • (3)数据量比较大的，建议使用数据库（比如SQLite、CoreData）

  • (4)网络优化

  • (5)减少、压缩网络数据

  • (6)如果多次请求的结果是相同的，尽量使用缓存

  • (7)使用断点续传，否则网络不稳定时可能多次传输相同的内容

  • (8)网络不可用时，不要尝试执行网络请求

  • (9)让用户可以取消长时间运行或者速度很慢的网络操作，设置合适的超时时间

  • (10) 批量传输，比如，下载视频流时，不要传输很小的数据包，直接下载整个文件或者一大块一大块地下载。如果下载广告，一

  • (11)次性多下载一些，然后再慢慢展示。如果下载电子邮件，一次下载多封，不要一封一封地下载

定位优化

  1. 如果只是需要快速确定用户位置，最好用CLLocationManager的requestLocation方法。定位完成后，会自动让定位停止

  2. 如果不是导航应用，尽量不要实时更新位置，定位完毕就关掉定位服务

  3. 尽量降低定位精度，比如尽量不要使用精度最高的kCLLocationAccuracyBest

  4. 需要后台定位时，尽量设置pausesLocationUpdatesAutomatically为YES，如果用户不太可能移动的时候系统会自动暂停位置更新

APP启动

APP的启动可以分为2种

  1. 冷启动(Cold Launch ）：从零开始启动APP

  2. 热启动(Warm Launch）：APP已经在内存中，在后台存活着，再次点击图标启动APP

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

通过添加环境变量可以打印出APP的启动时间分析(Edit scheme -> Run -> Arguments)

  1. DYLD_PRINT_STATISTICS设置为1

  2. 如果需要更详细的信息，那就将DYLD_PRINTSTATISTICS_ DETAILS设置为1

APP的启动

APP的冷启动可以概括为3大阶段

  1. dyld

  2. runtime

  3. main

APP的启动 - dyld

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

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

1.装载APP的可执行文件，同时会递归加载所有依赖的动态库

2.当dyid把可执行文件、动态库都装载完毕后，会通知Runtime进行下一步的处理

APP的启动 - runtime

  1. 启动APP时,runtime所做的事情有

  2. 调用map.images进行可执行文件内容的解析和处理

  3. 在load images中调用callL load_ methods,调用所有Class和Category的+load方法

  4. 进行各种objc结构的初始化（注册Objc类、初始化类对象等等）

调用C++静态初始化器和_attribute_((constructor)修饰的函数，到此为止,可执行文件和动态库中所有的符号(Class,Protocol,Selector,IMP,…都已经按格式成功加载到内存中,被runtime 所管理

APP的启动- main

APP的启动由dyld主导，将可执行文件加载到内存，顺便加载所有依赖的动态库，并由runtime负责加载成objc定义的结构，所有初始化工作结束后，dyld就会调用main函数，接下来就是UIApplicationMain函数，AppDelegate的application：didFinishLaunching WithOptions：方法

APP的启动优化总结

按照不同的阶段进行总结

dyld

  1. 减少动态库、合并一些动态库（定期清理不必要的动态库）

  2. 减少Objc类、分类的数量、减少Selector数量（定期清理不必要的类、分类）

  3. 减少C++虚函数数量

  4. Swift尽量使用struct结构体

runtime

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

main

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

安装包瘦身

安装包（IPA)主要由可执行文件、资源组成,资源（图片、音频、视频等）

  1. 采取无损压缩

  2. 去除没有用到的资源：https://github.com/tinymind/LSUnusedResources，可通过这个工具执行文件瘦身

编译器优化

1.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

不过这个现在默认编译器是打开的 所以不需要关心 只需要做了解就好

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

AppCode这个软件是JetBrains出品的，该软件是收费的 可以免费试用30天。

形成tableView卡顿的缘由有哪些？

1.最经常使用的就是cell的重用， 注册重用标识符

若是不重用cell时，每当一个cell显示到屏幕上时，就会重新建立一个新的cell，若是有不少数据的时候，就会堆积不少cell。若是重用cell，为cell建立一个ID，每当须要显示cell 的时候，都会先去缓冲池中寻找可循环利用的cell，若是没有再重新建立cell

2.避免cell的从重新布局

cell的布局填充等操做比较耗时，通常建立时就布局好，如能够将cell单独放到一个自定义类，初始化时就布局好

3.提早计算并缓存cell的属性及内容

当咱们建立cell的数据源方法时，编译器并非先建立cell 再定cell的高度，而是先根据内容一次确定每个cell的高度，高度确定后，再建立要显示的cell，滚动时，每当cell进入屏幕都会计算高度，提早估算高度告诉编译器，编译器知道高度后，紧接着就会建立cell，这时再调用高度的具体计算方法，这样能够防止浪费时间去计算显示之外的cell缓存

4.减小cell中控件的数量

尽可能使cell得布局大体相同，不一样风格的cell可使用不同的重用标识符，初始化时添加控件，不适用的能够先隐藏数据结构

5.不要使用ClearColor，无背景色，透明度也不要设置为0

因为渲染耗时比较长多线程

6.使用局部更新

若是只是更新某组的话，使用reloadSection进行局部更新

7.加载网络数据，下载图片，使用异步加载，并缓存

8.少使用addView 给cell动态添加view

9.按需加载cell，cell滚动很快时，只加载范围内的cell

10.不要实现无用的代理方法，tableView只遵照两个协议

11.缓存行高：estimatedHeightForRow不能和HeightForRow里面的layoutIfNeed同时存在，这二者同时存在才会出现“窜动”的bug。

因此个人建议是：只要是固定行高就写预估行高来减小行高调用次数提高性能。若是是动态行高就不要写预估方法了，用一个行高的缓存字典来减小代码的调用次数便可

12.不要作多余的绘制工做。

在实现drawRect:的时候，它的rect参数就是须要绘制的区域，这个区域以外的不须要进行绘制。例如上例中，就能够用CGRectIntersectsRect、CGRectIntersection或CGRectContainsRect判断是否须要绘制image和text，而后再调用绘制方法。

13.预渲染图像。当新的图像出现时，仍然会有短暂的停顿现象。

解决的办法就是在bitmap context里先将其画一遍，导出成UIImage对象，而后再绘制到屏幕；

14.使用正确的数据结构来存储数据。

如何提高 tableview 的流畅度？

本质上还是降低 CPU、GPU 的工作，从这两个大的方面去提高性能。

CPU：对象的建立和销毁、对象属性的调整、布局计算、文本的计算和排版、图片的格式转换和解码、图像的绘制

GPU：纹理的渲染

其实跟上面所讲到的卡顿优化的方案是差不多的

iOS 保持界面流畅的技巧

1.预排版，提早计算

在接收到服务端返回的数据后，尽可能将 CoreText 排版的结果、单个控件的高度、cell 总体的高度提早计算好，将其存储在模型的属性中。须要使用时，直接从模型中往外取，避免了计算的过程。

尽可能少用 UILabel，可使用 CALayer 。避免使用 AutoLayout 的自动布局技术，采起纯代码的方式

2.预渲染，提早绘制

例如圆形的图标能够提早在，在接收到网络返回数据时，在后台线程进行处理，直接存储在模型数据里，回到主线程后直接调用就能够了

避免使用 CALayer 的 Border、corner、shadow、mask 等技术，这些都会触发离屏渲染。

3.异步绘制

4.全局并发线程

5.高效的图片异步加载

怎么检测图层混合

  1. 模拟器debug中color blended layers红色区域表示图层发生了混合

  2. Instrument-选中Core Animation-勾选Color Blended Layers

避免图层混合

  1. 确保控件的opaque属性设置为true，确保backgroundColor和父视图颜色一致且不透明

  2. 如无特殊须要，不要设置低于1的alpha值

  3. 确保UIImage没有alpha通道

  4. UILabel图层混合解决方法：iOS8之后设置背景色为非透明色而且设置label.layer.masksToBounds=YES让label只会渲染她的实际size区域，就能解决UILabel的图层混合问题

iOS8 以前只要设置背景色为非透明的就行，为何设置了背景色可是在iOS8上仍然出现了图层混合呢？

UILabel在iOS8先后的变化，在iOS8之前，UILabel使用的是CALayer做为底图层，而在iOS8开始，UILabel的底图层变成了_UILabelLayer，绘制文本也有所改变。在背景色的四周多了一圈透明的边，而这一圈透明的边明显超出了图层的矩形区域，设置图层的masksToBounds为YES时，图层将会沿着Bounds进行裁剪 图层混合问题解决了

平常如何检查内存泄露？

目前我知道的方式有如下几种：

Memory Leaks

  1. Alloctions

  2. Analyse

  3. Debug Memory Graph

  4. MLeaksFinder

泄露的内存主要有如下两种：

  1. Laek Memory 这种是忘记 Release 操做所泄露的内存。

  2. Abandon Memory 这种是循环引用，没法释放掉的内存。