iOS内存优化方案

1.ARC模式下的多重强引用，MRC模式下的引用计数
2.tableview等ui组件cell的复用
3.透明的Views你应该设置它们的opaque属性为YES
如果设为YES，渲染系统就认为这个view是完全不透明的，这使得渲染系统优化一些渲染过程和提高性能。如果设置为NO，渲染系统正常地和其它内容组成这个View。默认值是YES。

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

你可以在模拟器中用Debug\Color Blended Layers选项来发现哪些view没有被设置为opaque。目标就是，能设为opaque的就全设为opaque!
4.避免过于庞大的XIB
5.不要阻塞主线程，尤其是使用GCD时一定要注意
6.避免在Image Views中调整图片大小，在运行中缩放图片是很耗费资源的，特别是UIImageView嵌套在UIScrollView中的情况下。
7.选择正确的Collection
学会选择对业务场景最合适的类或者对象是写出能效高的代码的基础。当处理collections时这句话尤其正确。
一些常见collection的总结：
· Arrays: 有序的一组值。使用index来lookup很快，使用value lookup很慢，插入/删除很慢。
· Dictionaries: 存储键值对。用键来查找比较快。
· Sets: 无序的一组值。用值来查找很快，插入/删除很快。
8.打开gzip压缩，好消息是，iOS已经在NSURLConnection中默认支持了gzip压缩，当然AFNetworking这些基于它的框架亦然。像Google App Engine这些云服务提供者也已经支持了压缩输出。
9.重用和延迟加载(lazy load) Views
10.缓存Cache的使用，NSURLConnection默认会缓存资源在内存或者存储中根据它所加载的HTTP Headers。你甚至可以手动创建一个NSURLRequest然后使它只加载缓存的值。
11.权衡渲染方法，在iOS中可以有很多方法做出漂亮的按钮。你可以用整幅的图片，可调大小的图片，uozhe可以用CALayer， CoreGraphics甚至OpenGL来画它们，你需要权衡一下利弊，到底是要性能能还是要bundle保持合适的大小。
12.处理内存警告
13.重用大开销对象
14. 正确设定背景图片
在View里放背景图片就像很多其它iOS编程一样有很多方法:
使用UIColor的 colorWithPatternImage来设置背景色；
在view中添加一个UIImageView作为一个子View。
如果你使用全画幅的背景图，你就必须使用UIImageView因为UIColor的colorWithPatternImage是用来创建小的重复的图片作为背景的。这种情形下使用UIImageView可以节约不少的内存
15. 减少使用Web特性
UIWebView很有用，用它来展示网页内容或者创建UIKit很难做到的动画效果是很简单的一件事。
但是你可能有注意到UIWebView并不像驱动Safari的那么快。这是由于以JIT compilation为特色的Webkit的Nitro Engine的限制。
所以想要更高的性能你就要调整下你的HTML了。第一件要做的事就是尽可能移除不必要的javascript，避免使用过大的框架。能只用原生js就更好了。
另外，尽可能异步加载例如用户行为统计script这种不影响页面表达的javascript。
最后，永远要注意你使用的图片，保证图片的符合你使用的大小。使用Sprite sheet提高加载速度和节约内存。
16.选择正确的数据存储选项
当存储大块数据时你会怎么做？
你有很多选择，比如：
· 使用NSUerDefaults
· 使用XML, JSON, 或者 plist
· 使用NSCoding存档
· 使用类似SQLite的本地SQL数据库
· 使用 Core Data
NSUserDefaults的问题是什么？虽然它很nice也很便捷，但是它只适用于小数据，比如一些简单的布尔型的设置选项，再大点你就要考虑其它方式了
XML这种结构化档案呢？总体来说，你需要读取整个文件到内存里去解析，这样是很不经济的。使用SAX又是一个很麻烦的事情。
NSCoding？不幸的是，它也需要读写文件，所以也有以上问题。
在这种应用场景下，使用SQLite 或者 Core Data比较好。使用这些技术你用特定的查询语句就能只加载你需要的对象。
在性能层面来讲，SQLite和Core Data是很相似的。他们的不同在于具体使用方法。Core Data代表一个对象的graph model，但SQLite就是一个DBMS。Apple在一般情况下建议使用Core Data，但是如果你有理由不使用它，那么就去使用更加底层的SQLite吧。
如果你使用SQLite，你可以用FMDB(https://GitHub.com/ccgus/fmdb)这个库来简化SQLite的操作，这样你就不用花很多经历了解SQLite的C API了。
17.选择是否缓存图片
常见的从bundle中加载图片的方式有两种，一个是用imageNamed，二是用imageWithContentsOfFile，第一种比较常见一点。
既然有两种类似的方法来实现相同的目的，那么他们之间的差别是什么呢？
imageNamed的优点是当加载时会缓存图片。imageNamed的文档中这么说:这个方法用一个指定的名字在系统缓存中查找并返回一个图片对象如果它存在的话。如果缓存中没有找到相应的图片，这个方法从指定的文档中加载然后缓存并返回这个对象。
相反的，imageWithContentsOfFile仅加载图片。
下面的代码说明了这两种方法的用法:
UIImage *img = [UIImage imageNamed:@“myImage”];// caching
// or
UIImage *img = [UIImage imageWithContentsOfFile:@“myImage”];// no caching
那么我们应该如何选择呢？
如果你要加载一个大图片而且是一次性使用，那么就没必要缓存这个图片，用imageWithContentsOfFile足矣，这样不会浪费内存来缓存它。
然而，在图片反复重用的情况下imageNamed是一个好得多的选择。
18.避免日期格式转换
如果你要用NSDateFormatter来处理很多日期格式，应该小心以待。就像先前提到的，任何时候重用NSDateFormatters都是一个好的实践。
然而，如果你需要更多速度，那么直接用C是一个好的方案。Sam Soffes有一个不错的帖子(https://soff.es/how-to-drastically-improve-your-app-with-an-afternoon-and-instruments)里面有一些可以用来解析ISO-8601日期字符串的代码，简单重写一下就可以拿来用了。
嗯，直接用C来搞，看起来不错了，但是你相信吗，我们还有更好的方案！
如果你可以控制你所处理的日期格式，尽量选择Unix时间戳。你可以方便地从时间戳转换到NSDate:

• (NSDate*)dateFromUnixTimestamp:(NSTimeInterval)timestamp {
  return[NSDate dateWithTimeIntervalSince1970:timestamp];
  }
  这样会比用C来解析日期字符串还快！需要注意的是，许多web API会以微秒的形式返回时间戳，因为这种格式在javascript中更方便使用。记住用dateFromUnixTimestamp之前除以1000就好了。