iOS app性能优化（转）

iPhone上面的应用一直都是以流畅的操作体验而著称，但是由于之前开发人员把注意力更多的放在开发功能上面，比较少去考虑性能的问题，可能这其中涉及到objective－c,c++跟lua，优化起来相对复杂一些，导致应用在比如touch等较低端的产品上，光从启动到进入页面就花了将近一分钟的时间，页面之间的切换没有那种很流畅的感觉，内存也居高不下，比较影响应用的用户体验，所以很有必要进行一些优化，下面记录一下我在优化的过程中的一些心得：

1 instruments

  在iOS上进行性能分析的时候，首先考虑借助instruments这个利器分析出问题出在哪，不要凭空想象，不然你可能把精力花在了1%的问题上，最后发现其实啥都没优化，比如要查看程序哪些部分最耗时，可以使用Time Profiler，要查看内存是否泄漏了，可以使用Leaks等。关于instruments网上有很多资料，作为一个合格iOS开发者，熟悉这个工具还是很有必要的。

2 不要阻塞主线程

  在iOS里关于UIKit的操作都是放在主线程，因此如果主线程被阻塞住了，你的UI可能无法及时响应事件，给人一种卡顿的感觉。大多数阻塞主线程的情况是在主线程做IO操作，比如文件的读写，包含数据库、图片、json文本或者log日志等，尽量将这些操作放放到子线程(如果数据库有一次有较多的操作，记得采用事务来处理，性能相差还是挺大的)，或者在后台建立对应的dispatch queue来做这些操作，比如一个低级别的serial queue来负责log文件的记录等等。程序中如果你的代码逻辑是按照同步的逻辑来写的，尽量修改逻辑代码吧。。。

3 使用cache

  一般为了提升用户体验，都会在应用中使用缓存，比如对于图片资源可以使用SDWebImage这个开源库，里面就实现了一个图片缓存的功能。参考SDWebImage的代码自己也可以实现缓存功能:

cache简单示意图

业务层根据资源的url向resourcemanager获取对应的资源，resourcemanager首先会到memorycache这边去获取资源，memorycache可以利用NSCache实现，因为NSCache首先是线程安全的，而且在收到内存警告的时候会自己释放对应的内存；如果memorycache没有对应的资源再去disk查找，disk也没有的话再去internet获取，获取到的话会更新到memorycache和disk中，具体可以去参考一下SDWebimage的实现细节。

4 减少程序启动过程中的任务

当用户点击app的图标之后，程序应该尽可能快的进入到主页面，尽可能减少用户的等待时间，比如我们的应用程序在启动的时候会去做3d模型的渲染操作，完成之后在进入首页面展示，但其实我们可以先进入到主页面，将渲染3d的任务放到子线程去完成，缩短用户需要等待的时间。

3d

5 使用合适的数据结构

根据不同的业务场景来选择合适的数据结构，可能在数据量比较少的时候看不出什么区别，但是假如你存储的数据量比较大且数据结构比较复杂的话，这有可能会影响到你的程序性能。一般用的比较多的数据结构就是array，但我们知道它的查找复杂度是O(n)，因此假如需要快速的查找某个元素，可以使用map。可以参考下 Apple Collections Programming Topics 。

6 内存

一般开发都使用的ARC，不太需要开发者去关注内存的创建和释放这块，但假如你使用的是MRC，并且跟其它语言混杂在一起(比如c++和lua)等的时候，如何确保内存正确释放就是你需要考虑的问题了。有时候一些内存泄漏instruments可能无法准确的分析出来，那么就需要自己去排查了，可以使用method swizzling方法来辅助我们排查内存泄漏的问题，确保程序的正确运行。

7 懒加载view

不要在cell里面嵌套太多的view，这会很影响滑动的流畅感，而且更多的view也需要花费更多的CPU跟内存。假如由于view太多而导致了滑动不流畅，那就不要在一次就把所有的view都创建出来，把部分view放到需要显示cell的时候再去创建。

8 lua优化

由于项目的业务是以及部分框架是用lua语言实现的，因此也顺便说一下lua这块遇到的问题。lua号称是最快的脚本语言，一般性能上不会有什么问题，如果lua代码要优化的话，网上也有很多这块优化的注意点，这次我主要说个可能影响性能的点---lua的垃圾回收。垃圾回收是一个比较耗时的操作，假如垃圾回收的操作太过于频繁势必会影响到这个程序的运行，比如在iPod在利用lua_cjson解析一份4.7M的json文件是花了3.43s的时间，后来发现跟垃圾回收这块有关。一般内存的使用量适中的话，可以不用去理他，让lua的incremental模式自己去处理，正常情况这个会工作的比较好；假如想要自己去控制gc的运行，可以设置gc的参数，这些参数可能会跟项目有一定的关系，可以自己多试验取最优值。

//gc 的参数设置，根据情况取最优值
collectgarbage("setpause", 150)
collectgarbage("setstepmul", 200)

---

  以上是我在优化过程中的一些记录总结

 

关于iOS图形性能这块的优化

 这次我们来说说iOS app中滑动的那些事。iOS为了提高滑动的流畅感，特意在滑动的时候将runloop模式切换到UITrackingRunLoopMode，在这个过程中专心做跟滑动相关的工作，这也就是在滑动过程中为什么nstimer无法工作的原因，因为两个没在同一mode下面。但我们可能经常会遇到滑动不怎么流畅的情况，比如在项目中碰到在滑动tableview的时候不怎么顺畅，感觉有点不爽，即便是在测试中表现最好的5s(touch之类的感受更直观)。

tableview 滑动不流畅

  那碰到这种情况该怎么处理，分析图像动画性能主要用的是Core Animation这个组件，先简单介绍一下里面一些经常用到的选项：

• Color Blended layers
  标示混合的图层会为红色,不透明的图层为绿色，通常我们希望绿色的区域越多越好。
• Color Hits Green and Misses Red
  假如我们设置viewlayer的shouldRasterize为YES，那些成功被缓存的layer会标注为绿色，反之为红色，下面会有详细介绍。
• Color copied images
  标示那些被Core Animation拷贝的图片。这主要是因为该图片的色彩格式不能被GPU直接处理，需要在CPU这边做转换，假如在主线层做这个操作对性能会有一定的影响。
• Color misaligned images
  被缩放的图片会被标记为黄色,像素不对齐则会标注为紫色。
• Color offscreen-rendered yellow
  标示哪些layer需要做离屏渲染(offscreen-render)。

---

简单介绍完Core Animation的一些东西之后我们回过头来看看哪些问题会影响到图形的性能，下面这张图摘自WWDC2014(Advanced Graphics and Animations for iOS Apps，这上面的一些分享非常有技术性)

performance investigation mindset.png

当你碰到性能问题的时候，你可以思考一下：

是否受到CPU或者GPU的限制？
是否有不必要的CPU渲染？
是否有太多的离屏渲染操作？
是否有太多的图层混合操作？
是否有奇怪的图片格式或者尺寸？
是否涉及到昂贵的view或者效果？
view的层次结构是否合理？

那么哪些是你最该开始考虑的方向呢？通常发生图形性能问题的时候，比如列表滑动不顺畅、动画卡顿等，大部分都是由于Offscreen Rendering(离屏渲染)或者blending导致的，因为这在动画的每一帧都会涉及到。

offscreen-render

什么是offscreen-render？offscreen-render涉及的内容比较多，有offscreen-render那就有onscreen render，onscreen render指的是GPU在当前用于显示的屏幕缓冲区进行渲染，相反offscreen-render就是不在当前的屏幕缓存区，而在另外的缓冲区进行渲染，offscreen-render有两种形式：

CPU的offscreen-render

使用CPU来完成渲染操纵，通常在你使用：

• drawRect (如果没有自定义绘制的任务就不要在子类中写一个空的drawRect方法，因为只要实现了该方法，就会为视图分配一个寄宿图，这个寄宿图的像素尺寸等于视图大小乘以 contentsScale的值，造成资源浪费)
• 使用Core Graphics
  上面的两种情况使用的就是CPU离屏渲染，首先分配一块内存，然后进行渲染操作生成一份bitmap位图，整个渲染过程会在你的应用中同步的进行，接着再将位图打包发送到iOS里一个单独的进程--render server，理想情况下，render server将内容交给GPU直接显示到屏幕上。

GPU的offscreen-render

使用GPU在当前屏幕缓冲区以外开辟一个新的缓冲区进行绘制，通常发生的情况有：

• 设置cornerRadius, masks, shadows,edge antialiasing等
• 设置layer.shouldRasterize ＝ YES

渲染流程

offscreen-render对性能到底有什么影响？通常大家说的离屏渲染指的是GPU这块(当然CPU这块也会有影响，也需要消耗一定的资源)，比如修改了layer的阴影或者圆角，GPU需要做额外的渲染操作。通常GPU在做渲染的时候是很快的，但是涉及到offscreen-render的时候情况就可能有些不同，因为需要额外开辟一个新的缓冲区进行渲染，然后绘制到当前屏幕的过程需要做onscreen跟offscreen上下文之间的切换，这个过程的消耗会比较昂贵，涉及到OpenGL的pipeline跟barrier，而且offscreen-render在每一帧都会涉及到，因此处理不当肯定会对性能产生一定的影响，所以可以的话尽量减少offscreen-render的图层，查看哪些图层需要离屏渲染可以用Instruments的Core Animation工具进行检测，Color Offscreen-Rendered Yellow选项会将对应的图层标记为黄色。

Blending

假如最上层的view是不透明的，那直接使用这个view的对应颜色之就可以，但如果view是透明的，在计算像素的颜色值时就需要计算它下面图层，透明的视图越多，计算量就越大，因此也会对图形的性能产生一定的影响，所以可以的话也尽量减少透明图层的数目。

Demo

下面给出一个简单demo的优化过程，这个demo里面涉及到的问题是在实际项目中所碰到的，也就是最上面那张图里列表滑动不流畅情况---由阴影以及圆角导致的offscreen-render。
整个页面就是一个简单的tableview，其中头像为圆角，一个label有阴影效果，滑动的时候在iPod上帧率只有可怜的28FPS。

Color Offscreen-Rendered Yellow

28FPS.png

其中黄色的区域就是离屏渲染的地方，也就是含有圆角跟阴影的layer。

shadowPath

设置label的阴影效果可以通过：

    cell.sign.layer.shadowOffset = CGSizeMake(0, 2);
    cell.sign.layer.shadowOpacity = 0.5;
    cell.sign.layer.shadowColor = [UIColor blackColor].CGColor;

但是你可以发现这会导致离屏渲染，一个简单的不需要离屏渲染的方法就是制定阴影的路径，也就是设置layer的shadowPath属性，通过instruments发现阴影的地方没有黄色了，帧率也提高到了40FPS：

cell.sign.layer.shadowPath = [UIBezierPath  bezierPathWithRect:cell.sign.bounds].CGPath;

设置shadowPath消除离屏渲染.png

rasterize

对于圆角这种类似导致的性能问题，最简单的就是在列表中不要使用圆角，假如要使用圆角的话，一种最快提升性能的方式就是设置layer的shouldRasterize为YES：

    cell.layer.shouldRasterize = YES;
    cell.layer.rasterizationScale = [UIScreen mainScreen].scale;

虽然被Rasterize的图层也会引起离屏渲染，如下图所示，整个cell都被标示为黄色：

shouldRasterize.png

layer设置shouldRasterize＝YES之后，会把被光栅化的图层保存成位图并缓存起来，其中圆角或者阴影之类的效果也是直接保存到位图当中，当需要渲染到屏幕上的时候只需要到缓存中去取对应的位图进行显示就行了，加快了整个渲染过程。可以通过勾选instruments core animation中的Color Hits Green and Misses Red选项来查看图层是否被缓存了，如果图层显示为绿色则表示已经被缓存起来了，也就是这个缓冲区的内容被复用了，不用在去重新创建缓冲区，反之则是用红色标示。如下图可以看到设置shouldRasterize之后，cell都被标示为绿色了，如果滑动过程中发现都是红色的证明就有问题了：

cached.png

再看看现在滑动的帧率：

优化后.png

可以发现现在滚动的性能大大提高了，光栅化对于那些有很多子view嵌套在一起、view的层级复杂或者有很复杂特效效果的图层有很明显的提升，因为这些内容都被缓存到位图当中了。但是使用光栅化需要注意一些内容：

• 适用于内容基本不变的图层
  假如图层的内容经常变化，比如cell里面有涉及到动画之类的，那么缓存的内容就无效了，GPU需要重新创建缓存区，导致离屏渲染，这又涉及到OpenGL的上下文环境切换，反而降低性能。
• 不要过度使用
  缓存区的大小被设置为屏幕大小的2.5倍，假如过分使用同样会导致大量的离屏渲染。
• 如果缓存的内容超过100ms没有被使用则会被回收。

---

tips

• 对于圆角可以使用一张中间圆形透明的图覆盖在上面，虽然这会引入blending操作，但是大部分情况下性能会比离屏渲染好。
• 让你的view层次结构平坦一些，因为OpenGL在渲染layer的时候，在碰到有子层级layer的时候可能需要停下来把两者合成到一个buffer里再接着渲染。（When the OpenGL renderer goes to draw each layer, it may have to stop for some subhierarchies and composite them into a single buffer）.
• 延迟加载图片
  有时候在边滚动边设置图片的时候可能会有一定的影响，因此可以在滚动的时候imageview不执行setimage的操作，滚动停止的时候才加载图片，由于滚动的时候NSRunloop是处于UITrackingRunLoopMode模式下，可以采用如下的方式，将设置图片放到NSDefaultRunLoopMode模式下才进行：

  UIImage *downloadedImage = ...;
    [self.avatarImageView performSelector:@selector(setImage:)
                               withObject:downloadedImage
                               afterDelay:0
                                  inModes:@[NSDefaultRunLoopMode]];

• 图片加载的极限优化方式：FastImageCache