1. 用ARC治理内存
ARC(Automatic ReferenceCounting, 主动援用计数)和iOS5一起公布，它防止了最常见的也就是常常是因为咱们遗记开释内存所造成的内存泄露。它主动为你治理retain和release的过程，所以你就不用去手动干涉了。忘掉代码段结尾的release几乎像记得吃饭一样简略。而ARC会主动在底层为你做这些工作。除了帮你防止内存泄露，ARC还能够帮你进步性能，它能保障开释掉不再须要的对象的内存。
iOS开发交换技术群：563513413，不论你是大牛还是小白都欢送入驻 ，分享BAT,阿里面试题、面试教训，探讨技术， 大家一起交流学习成长！
2.尽量把views设置为通明
如果你有通明的Views你应该设置它们的opaque属性为YES。
起因是这会使零碎用一个最优的形式渲染这些views。这个简略的属性在IB或者代码里都能够设定。
Apple的文档对于为图片设置通明属性的形容是：
(opaque)这个属性给渲染零碎提供了一个如何解决这个view的提醒。如果设为YES，渲染零碎就认为这个view是齐全不通明的，这使得渲染系统优化一些渲染过程和进步性能。如果设置为NO，渲染零碎失常地和其它内容组成这个View。默认值是YES。
在绝对比拟静止的画面中，设置这个属性不会有太大影响。然而当这个view嵌在scroll view里边，或者是一个简单动画的一部分，不设置这个属性的话会在很大水平上影响app的性能。
你能够在模拟器中用Debug\Color Blended Layers选项来发现哪些view没有被设置为opaque。指标就是，能设为opaque的就全设为opaque!
这里有一点须要留神，只有是有中文字符的Label，哪怕你设置成不通明，模拟器中这个Label仍然会变红，这个猜想是字符绘制的时候出的问题，这个目前没找到好的解决办法。
3.防止过于宏大的XIB
iOS5中退出的Storyboards(分镜)正在疾速取代XIB。然而XIB在一些场景中依然很有用。比方你的app须要适应iOS5之前的设施，或者你有一个自定义的可重用的view,你就不可避免地要用到他们。
如果你不得不XIB的话，使他们尽量简略。尝试为每个Controller配置一个独自的XIB，尽可能把一个View Controller的view层次结构扩散到独自的XIB中去。
须要留神的是，当你加载一个XIB的时候所有内容都被放在了内存里，包含任何图片。如果有一个不会即刻用到的view，你这就是在节约贵重的内存资源了。Storyboards就是另一码事儿了，storyboard仅在须要时实例化一个view controller.
当家在XIB是，所有图片都被chache，如果你在做OS X开发的话，声音文件也是。Apple在相干文档中的记述是：
当你加载一个援用了图片或者声音资源的nib时，nib加载代码会把图片和声音文件写进内存。在OS X中，图片和声音资源被缓存在named cache中以便未来用到时获取。在iOS中，仅图片资源会被存进named caches。取决于你所在的平台，应用NSImage 或UIImage的imageNamed:办法来获取图片资源。
这个问题我深有体会，用xib写的界面加载速度比间接用代码写的要慢好多
4. 在Image Views中调整图片大小
如果要在UIImageView中显示一个来自bundle的图片，你应保障图片的大小和UIImageView的大小雷同。在运行中缩放图片是很消耗资源的，特地是UIImageView嵌套在UIScrollView中的状况下。
如果图片是从远端服务加载的你不能管制图片大小，比方在下载前调整到适合大小的话，你能够在下载实现后，最好是用background thread，缩放一次，而后在UIImageView中应用缩放后的图片。
5. 抉择正确的Collection
学会抉择对业务场景最合适的类或者对象是写出能效高的代码的根底。当解决collections时这句话尤其正确。
一些常见collection的总结：
Arrays: 有序的一组值。应用index来lookup很快，应用value lookup很慢，插入/删除很慢。
Dictionaries: 存储键值对。用键来查找比拟快。
Sets: 无序的一组值。用值来查找很快，插入/删除很快。因为Set用到了哈希，所以插入删除查找速度比Array快很多
6. 关上gzip压缩
大量app依赖于远端资源和第三方API，你可能会开发一个须要从远端下载XML, JSON, HTML或者其它格局的app。
问题是咱们的指标是挪动设施，因而你就不能指望网络情况有多好。一个用户当初还在edge网络，下一分钟可能就切换到了3G。不论什么场景，你必定不想让你的用户等太长时间。
减小文档的一个形式就是在服务端和你的app中关上gzip。这对于文字这种能有更高压缩率的数据来说会有更显著的效用。
好消息是，iOS曾经在NSURLConnection中默认反对了gzip压缩，当然AFNetworking这些基于它的框架亦然。像Google App Engine这些云服务提供者也曾经反对了压缩输入。
7. 重用和提早加载(lazy load) Views
更多的view意味着更多的渲染，也就是更多的CPU和内存耗费，对于那种嵌套了很多view在UIScrollView里边的app更是如此。
这里咱们用到的技巧就是模拟UITableView和UICollectionView的操作:不要一次创立所有的subview，而是当须要时才创立，当它们实现了使命，把他们放进一个可重用的队列中。
这样的话你就只须要在滚动产生时创立你的views，防止了不划算的内存调配。
创立views的能效问题也实用于你app的其它方面。设想一下一个用户点击一个按钮的时候须要出现一个view的场景。有两种实现办法：
- 创立并暗藏这个view当这个screen加载的时候，当须要时显示它；
- 当须要时才创立并展现。
每个计划都有其优缺点。用第一种计划的话因为你须要一开始就创立一个view并放弃它直到不再应用，这就会更加耗费内存。然而这也会使你的app操作更敏感因为当用户点击按钮的时候它只须要扭转一下这个view的可见性。
第二种计划则相同-耗费更少内存，然而会在点击按钮的时候比第一种稍显卡顿。
8.衡量渲染办法
在iOS中能够有很多办法做出丑陋的按钮。你能够用整幅的图片，可调大小的图片，或者能够用CALayer， CoreGraphics甚至OpenGL来画它们。当然每个不同的解决办法都有不同的复杂程度和相应的性能。
简略来说，就是用当时渲染好的图片更快一些，因为如此一来iOS就免去了创立一个图片再画货色下来而后显示在屏幕上的程序。问题是你须要把所有你须要用到的图片放到app的bundle外面，这样就减少了体积–这就是应用可变大小的图片更好的中央了:你能够省去一些不必要的空间，也不须要再为不同的元素(比方按钮)来做不同的图。
然而，应用图片也意味着你失去了应用代码调整图片的机动性，你须要一遍又一遍一直地重做他们，这样就很浪费时间了，而且你如果要做一个动画成果，尽管每幅图只是一些细节的变动你就须要很多的图片造成bundle大小的一直增大。
总得来说，你须要衡量一下利弊，到底是要性能能还是要bundle放弃适合的大小。
9.解决内存正告
一旦零碎内存过低，iOS会告诉所有运行中app。在官网文档中是这样记述:
如果你的app收到了内存正告，它就须要尽可能开释更多的内存。最佳形式是移除对缓存，图片object和其余一些能够重创立的objects的strong references.
侥幸的是，UIKit提供了几种收集低内存正告的办法:
在app delegate中应用applicationDidReceiveMemoryWarning:的办法
在你的自定义UIViewController的子类(subclass)中笼罩didReceiveMemoryWarning
注册并接管 UIApplicationDidReceiveMemoryWarningNotification的告诉
一旦收到这类告诉，你就须要开释任何不必要的内存应用。
例如，UIViewController的默认行为是移除一些不可见的view，它的一些子类则能够补充这个办法，删掉一些额定的数据结构。一个有图片缓存的app能够移除不在屏幕上显示的图片。
这样对内存警报的解决是很必要的，若不器重，你的app就可能被零碎杀掉。
然而，当你肯定要确认你所抉择的object是能够被重现创立的来开释内存。肯定要在开发中用模拟器中的内存揭示模仿去测试一下。
当然，当初iOS设施运行内存越来越大，这一点很难呈现了
10. 应用Sprite Sheets
Sprite sheet能够让渲染速度放慢，甚至比规范的屏幕渲染办法节俭内存。
11.防止重复解决数据
许多利用须要从服务器加载性能所需的常为JSON或者XML格局的数据。在服务器端和客户端应用雷同的数据结构很重要。在内存中操作数据使它们满足你的数据结构是开销很大的。
比方你须要数据来展现一个table view,最好间接从服务器取array构造的数据以防止额定的两头数据结构扭转。
相似的，如果须要从特定key中取数据，那么就应用键值对的dictionary。
这一点在解决大量数据的时候极为重要，用空间换工夫的办法兴许是极好的。
12.抉择正确的数据格式
从app和网络服务间传输数据有很多计划，最常见的就是JSON和XML。你须要抉择对你的app来说最合适的一个。
解析JSON会比XML更快一些，JSON也通常更小更便于传输。从iOS5起有了官网内建的JSON deserialization就更加方便使用了。
然而XML也有XML的益处，比方应用SAX来解析XML就像解析本地文件一样，你不需像解析json一样等到整个文档下载实现才开始解析。当你解决很大的数据的时候就会极大地减低内存耗费和减少性能。