1.RunLoop的应用
Runloop应用
1）NSTimer
2）ImageView显示：控制方法在特定的模式下可用
3）PerformSelector
4）常驻线程：在子线程中开启一个runloop
5）自动释放池
第一次创建：进入runloop的时候
最后一次释放：runloop退出的时候
其它创建和释放：当runloop即将休眠的时候会把之前的自动释放池释放，然后重新创建一个新的释放池
runloop结构.png
runloop内部逻辑.png
3.runloop个人小结
4.runloop应用
1.在主线程中做耗时操作
耗时操作，包括从网络下载、从网络加载、从本地数据库读取数据、从本地文件中读取大量数据、往本地文件中写入数据等。（这一点，相信大家都知道，要尽量避免在主线程中执行，一般都是创建一个子线程来执行，然后再回到主线程）
2.动态计算UITableViewCell的高度，时间过久
在iOS7之前，每一个Cell的高度，只会计算一次，后面再次滑到这个Cell这里，都会读取缓存的高度，也即高度计算的代理方法不会再执行。但是到了iOS8,不会再缓存Cell的高度了，也就是说每次滑到某个Cell，代理方法都会执行一次，重新计算这个Cell的高度（iOS 9以后没测试过）。
所以，如果计算Cell高度的这个过程过于复杂，或者某个计算使用的算法耗时很长，可能会导致计算时间大于1/60，那么必然导致界面的卡顿，或不流畅。
关于这一点，我以前的做法是在Cell中定义一个public方法，用来计算Cell高度，然后计算完高度后，将高度存储在Cell对应的Model中（Model里定义一个属性来存高度），然后在渲染Cell时，我们依然需要动态计算各个子视图的高度。（可能是没用什么太过复杂的计算或算法，时间都很短滑动也顺畅）
其实，更优的做法是：再定义一个ModelFrame对象，在子线程请求服务器接口返回后，转换为对象的同时，也把各个子视图的frame计算好，存在ModelFrame中，ModelFrame 和 Model 合并成一个Model存储到数组中。这样在为Cell各个子控件赋值时，仅仅是取值、赋值，在计算Cell高度时，也仅仅是加法运算。
3.界面中背景色透明的视图过多
为什么界面中背景色透明的视图过多会影响UITableView的流畅？
很多文章中都提到，可以使用模拟器—>Debug—>Color Blended Layers来检测透明背景色，把透明背景色改为与父视图背景色一样的颜色，这样来提高渲染速度。
