前言
不积跬步无以至千里，不积小流无以成江海。学如逆水行舟，不进则退。我是平平无奇游荡于各平台的搬运工。今天给大家讲解的是性能优化。废话不多说，直接给大家上干货，希望能对你有所帮助，优秀的人已经点赞了。
1.形成tableView卡顿的缘由有哪些？
-
1.最经常使用的就是cell的重用， 注册重用标识符
若是不重用cell时，每当一个cell显示到屏幕上时，就会从新建立一个新的cellhtml
若是有不少数据的时候，就会堆积不少cell。ios
若是重用cell，为cell建立一个ID，每当须要显示cell 的时候，都会先去缓冲池中寻找可循环利用的cell，若是没有再从新建立cellc++
-
2.避免cell的从新布局
cell的布局填充等操做 比较耗时，通常建立时就布局好面试
如能够将cell单独放到一个自定义类，初始化时就布局好swift
-
3.提早计算并缓存cell的属性及内容
当咱们建立cell的数据源方法时，编译器并非先建立cell 再定cell的高度xcode
而是先根据内容一次肯定每个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.使用正确的数据结构来存储数据。
2.如何提高 tableview 的流畅度？
-
本质上是下降 CPU、GPU 的工做，从这两个大的方面去提高性能。
CPU：对象的建立和销毁、对象属性的调整、布局计算、文本的计算和排版、图片的格式转换和解码、图像的绘制
GPU：纹理的渲染
-
卡顿优化在 CPU 层面
尽可能用轻量级的对象，好比用不到事件处理的地方，能够考虑使用 CALayer 取代 UIView
不要频繁地调用 UIView 的相关属性，好比 frame、bounds、transform 等属性，尽可能减小没必要要的修改
尽可能提早计算好布局，在有须要时一次性调整对应的属性，不要屡次修改属性
Autolayout 会比直接设置 frame 消耗更多的 CPU 资源
图片的 size 最好恰好跟 UIImageView 的 size 保持一致
控制一下线程的最大并发数量
尽可能把耗时的操做放到子线程
文本处理（尺寸计算、绘制）
图片处理（解码、绘制）
-
卡顿优化在 GPU层面
尽可能避免短期内大量图片的显示，尽量将多张图片合成一张进行显示
GPU能处理的最大纹理尺寸是 4096x4096，一旦超过这个尺寸，就会占用 CPU 资源进行处理，因此纹理尽可能不要超过这个尺寸
尽可能减小视图数量和层次
减小透明的视图（alpha<1），不透明的就设置 opaque 为 YES
尽可能避免出现离屏渲染
-
iOS 保持界面流畅的技巧
1.预排版，提早计算
在接收到服务端返回的数据后，尽可能将 CoreText 排版的结果、单个控件的高度、cell 总体的高度提早计算好，将其存储在模型的属性中。须要使用时，直接从模型中往外取，避免了计算的过程。
尽可能少用 UILabel，可使用 CALayer 。避免使用 AutoLayout 的自动布局技术，采起纯代码的方式
2.预渲染，提早绘制
例如圆形的图标能够提早在，在接收到网络返回数据时，在后台线程进行处理，直接存储在模型数据里，回到主线程后直接调用就能够了
避免使用 CALayer 的 Border、corner、shadow、mask 等技术，这些都会触发离屏渲染。
3.异步绘制
4.全局并发线程
5.高效的图片异步加载
3.APP启动时间应从哪些方面优化？
App启动时间能够经过xcode提供的工具来度量，在Xcode的Product->Scheme-->Edit Scheme->Run->Auguments中，将环境变量DYLD_PRINT_STATISTICS设为YES，优化需如下方面入手
-
dylib loading time
核心思想是减小dylibs的引用
合并现有的dylibs（最好是6个之内）
使用静态库
-
rebase/binding time
核心思想是减小DATA块内的指针
减小Object C元数据量，减小Objc类数量，减小实例变量和函数（与面向对象设计思想冲突）
减小c++虚函数
多使用Swift结构体（推荐使用swift）
-
ObjC setup time
核心思想同上，这部份内容基本上在上一阶段优化事后就不会太过耗时
initializer time
-
使用initialize替代load方法
减小使用c/c++的attribute((constructor))；推荐使用dispatch_once() pthread_once() std:once()等方法
推荐使用swift
不要在初始化中调用dlopen()方法，由于加载过程是单线程，无锁，若是调用dlopen则会变成多线程，会开启锁的消耗，同时有可能死锁
不要在初始化中建立线程
4.如何下降APP包的大小？
下降包大小须要从两方面着手
-
可执行文件
编译器优化：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插件检测出重复代码、未被调用的代码
-
资源（图片、音频、视频 等）
优化的方式能够对资源进行无损的压缩
去除没有用到的资源
5.如何检测离屏渲染与优化
-
检测，经过勾选Xcode的Debug->View Debugging-->Rendering->Run->Color Offscreen-Rendered Yellow项。
-
优化，如阴影，在绘制时添加阴影的路径
6.怎么检测图层混合
一、模拟器debug中color blended layers红色区域表示图层发生了混合
二、Instrument-选中Core Animation-勾选Color Blended Layers
避免图层混合：
- 确保控件的opaque属性设置为true，确保backgroundColor和父视图颜色一致且不透明
- 如无特殊须要，不要设置低于1的alpha值
- 确保UIImage没有alpha通道
UILabel图层混合解决方法：
iOS8之后设置背景色为非透明色而且设置label.layer.masksToBounds=YES让label只会渲染她的实际size区域，就能解决UILabel的图层混合问题
iOS8 以前只要设置背景色为非透明的就行
为何设置了背景色可是在iOS8上仍然出现了图层混合呢？
UILabel在iOS8先后的变化，在iOS8之前，UILabel使用的是CALayer做为底图层，而在iOS8开始，UILabel的底图层变成了_UILabelLayer，绘制文本也有所改变。在背景色的四周多了一圈透明的边，而这一圈透明的边明显超出了图层的矩形区域，设置图层的masksToBounds为YES时，图层将会沿着Bounds进行裁剪 图层混合问题解决了
7.平常如何检查内存泄露？
-
目前我知道的方式有如下几种
Memory Leaks
Alloctions
Analyse
Debug Memory Graph
MLeaksFinder
-
泄露的内存主要有如下两种：
Laek Memory 这种是忘记 Release 操做所泄露的内存。
Abandon Memory 这种是循环引用，没法释放掉的内存。
结尾
希望看到这里的客官都能够有所收获，如果觉得有所收获的话，不妨点上免费的赞支持一下。如需iOS资料，可关注主页加入圈子，免费获取哦！！
网友评论