性能优化是一个大的问题，所以首先是需要把这个问题分而化之，把它分解成一个个影响app性能的小问题才能进行回答，所以在这里做出一些整理来回答这个问题，同时也提醒自己再次遇到如此大的问题时学会分析问题的本身以及从哪些方面去回答这些问题。
影响app性能的几个问题有：
1. 网络性能
网络性能优化涉及到DNS解析，路由算法，以及服务器端性能，不是很了解，可参看一下文章：
携程App的网络性能优化实践
影响移动应用网络性能的三大因素
2. 内存问题
在MRC时代，手动释放内存会导致大量内存的泄露。但是在ARC时代解决了大部分的内存泄露，但是仍然会出现内存泄露的问题：
1. 循环引用
2. Core Animation对象手动释放
3. UIWebView内存泄露
一些详细介绍如下：
ARC下的内存泄漏
ARC 下内存泄露的那些点
3. 主线程阻塞
所有的用户输入和UIKit的渲染是在主线程执行。所以要保证app的流畅度就一定不能阻塞主线程，把可以在子线程中做的事放到子线程中来减少主线程的计算与处理。
假如在主线程中执行如下操作：
1. 网络同步请求
2. I/O操作
3. 大量运算
4. 解压缩
...
因为需要处理的多所以会阻塞主线程，导致卡顿，因此要减少主线程中耗时的操作，使用多线程（NSThread、NSOperationQueue, GCD）来处理这些。可以查看OS X 和 iOS 中的多线程技术关于多线程的介绍。还有主线程关于渲染的处理会影响效率，所以这一块也是需要处理的。
4. Offscreen rendering(离屏渲染)
离屏渲染，指的是GPU在当前屏幕缓冲区以外新开辟一个缓冲区进行渲染操作。离屏渲染意味着你App的部分区域每一帧渲染了两次。所以会造成一定的性能损失。
对于UIView或者CALayer的frame,bounds,transform等属性的改变，消耗的资源远大于他们其他的属性改变。
可以参考以下文章：
绘制像素到屏幕上
绘制阴影引发的 iOS 绘图性能问题总结
iOS 离屏渲染的研究
5. 图片的处理
通常会用imageNamed:来加载mainbundle中的图片，此函数会缓存加载的image。因此，对于那些被重用的图片，这个API很高效。但是对于那些使用很少的图片，用这个就很耗内存。
所以在加载使用一次的应用图片时使用initWithContentsOfFile：函数，而在加载多次使用的图片时就使用imageNamed:函数。例如加载引导页的图片时使用载入路径的方式，而使用通用的背景图的就使用imageNamed：的方式。
//使用路径方式载入图片
NSString *path = [[NSBundle mainBundle] pathForResource:fileName ofType:fileType];
UIImage *image = [[UIImage alloc] initWithContentsOfFile:path];
//使用图片名的方式载入图片
UIImage *image = [UIImage imageNamed:fileName];
或
//读取本地图片的 和imageNamed一样，但是性能比后者要强很多，两个参数，前面一个是 文件名，后面一个是类型
#define LoadImage(_pointer) [UIImage imageNamed:[UIUtil imageName:_pointer]] //可以用来直接传图片名字
#define LoadImageWithType(file,ext) [UIImage imageWithContentsOfFile:[[NSBundle mainBundle]pathForResource:file ofType:ext]]
一般的优化技术就是在减少内存使用，减少主线程业务处理，用空间来换时间等等，基于这些策略及技术考虑来选择优化方向。
以下是iOS的一些细节优化策略
- 避免对UIView使用透明。（UIView默认是非透明）。原因是透明对性能要求较高，如果在滚动时页面比较复杂，体验上的差异会相对明显。
- 避免过于庞大的xib。（如果不得不使用一个ViewController作为xib,也应该将其其中的子视图拆成小的xib）。
需要注意的是，当你加载一个XIB的时候所有内容都被放在了内存里，包括任何图片。如果有一个不会即刻用到的view，你这就是在浪费宝贵的内存资源了。Storyboards就是另一码事儿了，storyboard仅在需要时实例化一个view controller.
不要阻塞主线程。
- 使图片符合UIImageView的尺寸。不要在运行的时候再让UIImageView自行压缩，因为这样会降低运行时的性能。(注：手动压缩图片的方法，在context中使用drawInRect)
- 选择合适的collection，数据结构决定了算法的效率。 如：Array使用下标查找较快，但插入和删除较慢。set进行插入和删除很快。
- 使用缓存，因为数据具有时效的，所以对于时效性要求不高的数据完全可以使用缓存来保证快速显示。例如URL对应的图片缓存（SDWebImage），通过数据库活core Data来保存不需要变动的数据，UIWeb的缓存等都属于这种。
- 处理低内存警告。在收到内存警告时，清除对cache的强引用，没有当前显示需要的image，以及一些其他可以再创建的对象。
- 重用一些高消耗的对象，如NSDateFormatter、NSCalender等。解决方法：可以将其作为property、甚至是静态变量作为单例在APP中使用。并且，NSDateFormatter的 setDateFormate也是非常消耗资源的一个操作。
- 网络传输过来的数据，往往是json或xml字符串。直接将这些字符串转换成我们需要的数据结构（自定义类或者NSDictionary）,避免后续使用的时候还要做数据结构转换产生不必要的消耗。
- 设置UIView的背景图片时，如果是整幅图，就采用addSubView一个UIImageView；如果是要重复平铺一个小图，就使用colorWithPatternImage，因为这个函数的设计上就是针对小图的，如果用于整幅大图来做背景，反而会消耗更多内存。
- 在临时创建大量对象时，使用NSAutoreleasepool，例如，一个循环用于创建包含多个对象的数组，在循环体内，即可使用@autoreleasepool包裹创建代码。使用系统的@autoreleasepool会有延迟，内存不会马上释放。
- 对于排版复杂的文字或者图文混排，使用CoreText技术。（而不是一味地堆UILabel）
- 在对渲染的效率要求较高的页面中，避免使用UILabel、UITextView等在主线程中进行排版和绘制的控件。应自定义文本控件，用TextKit或者CoreText进行文本异步绘制。另外，还有facebook的AsyncDisplayKit框架可以采用。
将绘制图像放在次线程中执行，如在次线程中使用 CGContext进行画图，在主线程中 layer.contents = img。
图片和视图的大小避免超过4096*4096，因为这是目前iphone5到iphone6p以及ipad仅仅通过GPU就直接处理的纹理尺寸上限，否则就GPU就会提交CPU先处理，这样开销很大。
- 减少视图或者layer的层级数量，在有多个层级时，可以将多图合并成一张图，再渲染显示。
- 电量消耗：减少耗电与流量的操作。GPS在获取用户位置之后，就进行关闭，因为它非常耗电。
- 关于后台运行。进入后台后，即尽量减少内存占用、释放所有的共享资源（如Calender或address book），因为iOS会kill后台中内存消耗最多的或者进入后台还占用共享资源的进程。
参考文章：
iOS App性能优化
让App的运行速度与响应速度趋于一流
程序猿进化必读：让App的运行速度与响应速度趋于一流（iOS）
iOS应用性能调优的4个建议和技巧
