iOS性能优化

小编致力于用精简的语言说明不精简的问题

入门级：

• 1.用ARC管理内存
• 2.使用重用机制
• 3.视图不透明
• 4.避免庞大的XIB
• 5.开启新线程
• 6.调整图片大小
• 7.选择正确的集合
• 8.打开gzip压缩

中级：在一些相对复杂情况下可能用到的

• 9.延迟加载
• 10.缓存
• 11.权衡渲染方法
• 12.处理内存警告
• 13.避免重用大开销对象：NSDateFormatter、NSCalendar
• 15.避免处理数据格式
• 16.选择正确的数据形式
• 18.减少使用Web
• 19.shadowPath替代shadowOffset
• 20.优化TableView
• 21.选择正确的数据存储方法

进阶级：这些建议，在你确信他们可以解决问题并且得心应手的情况下，采用

• 22.加速启动时间
• 23.使用Autorelease Pool
• 24.选择加载图片方法
• 25.尽量避免日期格式转换

入门级具体讲解

1.用ARC管理内存

• 自动引用计数和iOS5一起发布，它可以尽量避免内存泄露，自动为你管理retain和release的过程

2.在正确的地方使用重用机制

• 一个开发中常见的错误就是没有给UITableViewCells， UICollectionViewCells，甚至是UITableViewHeaderFooterViews设置正确的reuseIdentifier

• 自iOS6起，你也应该在header和footer 的 views中使用reuseIdentifiers

3.尽量把views设置为完全不透明

• 如果有透明的Views，应该设置它们的opaque属性为YES

• Apple的文档对于opaque属性的描述是：

  • 设置为YES， 系统会优化渲染过程，提高性能
  • 设置为NO，系统认为视图透明，会和其它内容一起组成这个视图
  • 默认值是YES

• 在相对比较静止的画面中，设置这个属性不会有太大影响。然而当这个view嵌在scrollview里边，或者是一个复杂动画的一部分，不设置这个属性的话会在很大程度上影响app的性能

为什么Blending会导致性能的损失？

如果一个图层是完全不透明的,则系统直接显示该图层的颜色即可。而如果图层是带透明效果的,则会引入更多的计算,因为需要把下面的图层也包括进来,进行混合后颜色的计算

4. 避免过于庞大的XIB

• 加载XIB的时候所有内容都被放在了内存里，包括图片。如果有一个不会即刻用到的view，就是在浪费内存资源。storyboard仅在需要时加载入内存

5. 不要阻塞主线程

6. 调整图片大小

• 运行中缩放图片很消耗资源，最好保证bundle里图片大小和imageView大小一致；如果从网络中获取图片资源，那么最好在新的线程中缩放图片后，放在imageView上。

7.选择正确的集合：

• array中，有序数组，用索引查找相对较快，用值来查找相对较慢，插入删除很慢
• 字典中，用key查找比较快
• sets，无序数组，用value查找很快，插入删除很快

8. 打开gzip压缩

减小文档的一个方式就是在服务端和你的app中打开gzip。这对于文字这种能有更高压缩率的数据来说会有更显著的效用。好消息是，iOS已经在NSURLConnection中默认支持了gzip压缩，当然AFNetworking这些基于它的框架亦然

中级

9. 延迟加载

UITableView和UICollectionView的操作: 不要一次创建所有的子视图，需要时才创建，当它们完成了使命，把他们放进一个可重用的队列中

10. Cache

• 缓存那些不大可能改变但是需要经常读取的东西
  • 比如UITableView的行高。
• NSCache和NSDictionary类似，不同的是系统回收内存的时候它会自动删除

11. 权衡渲染方法

在iOS中可以有很多方法做出漂亮的按钮。你可以用整幅的图片，可调大小的图片，uozhe可以用CALayer， CoreGraphics甚至OpenGL来画它们。

简单来说，就是用事先渲染好的图片更快一些，因为如此一来iOS就免去了创建一个图片再画东西上去然后显示在屏幕上的程序。问题是你需要把所有你需要用到的图片放到app的bundle里面，这样就增加了体积 – 这就是使用可变大小的图片更好的地方了: 你可以省去一些不必要的空间，也不需要再为不同的元素(比如按钮)来做不同的图。

然而，使用图片也意味着你失去了使用代码调整图片的机动性，你需要一遍又一遍不断地重做他们，这样就很浪费时间了，而且你如果要做一个动画效果，虽然每幅图只是一些细节的变化你就需要很多的图片造成bundle大小的不断增大。

总得来说，你需要权衡一下利弊，到底是要性能能还是要bundle保持合适的大小。

12. 处理内存警告

• 在appdelegate中的applicationDidReceiveMemoryWarning:方法中接收警告
• 在自定义的UIViewController的子类中覆盖该方法，注册并接收 UIApplicationDidReceiveMemoryWarningNotification 的通知；一旦收到这类通知，你就需要释放任何不必要的内存使用
• 一个有图片缓存的app可以移除不在屏幕上显示的图片

13. 避免重用大开销对象

• 避免初始化比较慢的对象，比如NSDateFormatter和NSCalendar

• 可以通过添加属性到类里或者创建静态变量来避免重复创建对象

X14. 使用Sprite Sheets

你是一个游戏开发者吗，那么Sprite sheets一定是一个你的最好的朋友了。Sprite sheet可以让渲染速度加快，甚至比标准的屏幕渲染方法节省内存。

我们有两个很好的关于Sprite的教程：

How To Use Animations and Sprite Sheets in Cocos2D

How to Create and Optimize Sprite Sheets in Cocos2D with Texture Packer and Pixel Formats

第二个教程涵盖了可能在很大程度上影响你游戏性能的pixel格式的细节。

如果你对于spirte sheet还不是很熟悉，可以看下这两个(youtube)视频SpriteSheets – The Movie, Part 1 和Part 2。视频的作者是创建Sprite sheet很流行的工具之一Texture Packer的作者Andreas Löw。

除了使用Sprite sheets，其它写在这里的建议当然也可以用于游戏开发中。比如你需要很多的Sprite sheets，像敌人，导弹之类的动作类必备元素，你可以重用这些sprites而不用每次都要重新创建。

15. 避免处理数据格式

• 从服务器加载的json或xml等数据时，服务器格式最好方便客户端操作，避免客户端在内存中操作数据格式

16. 选择正确的数据形式

• 解析JSON会比XML更快一些
• JSON也通常更小
• 使用SAX 来解析XML就像解析本地文件一样；不需等到整个文档下载完成才开始解析；当处理很大数据的时候就会极大地降低内存占用

X17. 正确设定背景图片

在View里放背景图片就像很多其它iOS编程一样有很多方法:

使用UIColor的 colorWithPatternImage来设置背景色；

在view中添加一个UIImageView作为一个子View。

如果你使用全画幅的背景图，你就必须使用UIImageView因为UIColor的colorWithPatternImage是用来创建小的重复的图片作为背景的。这种情形下使用UIImageView可以节约不少的内存：

// You could also achieve the same result in Interface BuilderUIImageView*backgroundView = [[UIImageViewalloc] initWithImage:[UIImageimageNamed:@"background"]];[self.viewaddSubview:backgroundView];

如果你用小图平铺来创建背景，你就需要用UIColor的colorWithPatternImage来做了，它会更快地渲染也不会花费很多内存：

self.view.backgroundColor= [UIColorcolorWithPatternImage:[UIImageimageNamed:@"background"]];

18. 减少使用Web

• UIWebView用来展示网页内容，创建动画效果

  • UIWebView并不像驱动Safari的那么快。这是由于以JIT compilation 为特色的Webkit的Nitro Engine的限制

• 移除不必要的javascript，避免使用过大的框架，能只用原生js就更好了

19. shadowPath替代shadowOffset

...view.layer.shadowOffset=CGSizeMake(-1.0f,1.0f);view.layer.shadowRadius=5.0f;view.layer.shadowOpacity=0.6;

CoreAnimation先在后台得出图形，加好阴影，然后渲染。开销很大

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

20. 优化TableView

为了保证TableView平滑滚动，确保你采取了以下的措施:

1.缓存行高

2.尽量设定固定行高

3.异步加载数据

4.视图不透明

5.减少子视图

6.尽量不使用 `cellForRowAtIndexPath:` 如果用，用一次然后缓存结果

21. 选择正确的数据存储方式

1.NSUerDefaults
NSUserDefaults只适用于小数据，比如一些简单的布尔型的设置选项

2.使用XML, JSON, 或者 Plist
XML需要读取整个文件到内存里去解析

3.使用NSCoding存档
需要读取整个文件到内存里去解析

4.SQLite，Core Data
存储大块数据

SQLite更加底层，但SQLite和Core Data的性能是差不多的。他们的不同在于具体使用方法。Core Data代表一个对象的graph model，但SQLite就是一个DBMS

22. 加速启动时间

1.开启新线程
比如加载远端或者数据库数据、解析数据

2.避免过于庞大的XIB
他们是在主线程上加载的

注意，用Xcode debug时watchdog并不运行，一定要把设备从Xcode断开来测试启动速度

23. 使用AutoreleasePool

NSAutoreleasePool负责释放block中的自动释放对象。一般情况下它会自动被UIKit调用

假如你创建很多临时对象，你会发现内存一直在减少直到这些对象被release的时候。这是因为只有当UIKit用光了autorelease pool的时候memory才会被释放

好消息是你可以在你自己的@autoreleasepool里创建临时的对象来避免这个行为：

 // 千万不要写多次autorelease
 // 一个alloc, new对应一个autorelease
 //Person *p = [[[[Person alloc] init] autorelease] autorelease];
 // 如果写了autorelease就不要写release
 // 总之记住: 一个alloc/new对应一个autorelease或者release
 @autoreleasepool {
        Person *p = [[[Person alloc] init] autorelease];
 }

24. 选择是否缓存图片

imageNamed会缓存图片
imageWithContentsOfFile仅加载图片

25. 避免日期格式转换

如果用NSDateFormatter来处理很多日期格式，应该小心。重用NSDateFormatter是好的

然而，如果你需要更多速度，那么直接用C是一个好的方案。Sam Soffes有一个不错的帖子(http://soff.es/how-to-drastically-improve-your-app-with-an-afternoon-and-instruments)

日期格式尽量选择Unix时间戳。可以方便地从时间戳转换到NSDate: 这样会比用C来解析日期字符串还快:

[NSDatedateWithTimeIntervalSince1970:timestamp];