性能问题的主要原因是什么，原因有相同的，也有不同的，但归根到底，不外乎内存使用、代码效率、合适的策略逻辑、代码质量、安装包体积这一类问题。
但从用户体验的角度去思考，当我们置身处地得把自己当做用户去玩一款应用时候，那么都会在意什么呢？假如正在玩一款手游，首先一定不希望玩着玩着突然闪退，然后就是不希望卡顿，其次就是耗电和耗流量不希望太严重，最后就是安装包希望能小一点。简单归类如下：
快：使用时避免出现卡顿，响应速度快，减少用户等待的时间，满足用户期望。
稳：不要在用户使用过程中崩溃和无响应。
省：节省流量和耗电，减少用户使用成本，避免使用时导致手机发烫。
小：安装包小可以降低用户的安装成本。
一、快
应用启动慢，使用时经常卡顿，是非常影响用户体验的，应该尽量避免出现。卡顿的场景有很多，按场景可以分为4类：UI 绘制、应用启动、页面跳转、事件响应。引起卡顿的原因很多，但不管怎么样的原因和场景，最终都是通过设备屏幕上显示来达到用户，归根到底就是显示有问题，
根据iOS 系统显示原理可以看到，影响绘制的根本原因有以下两个方面：
1.绘制任务太重，绘制一帧内容耗时太长。
2.主线程太忙，根据系统传递过来的 VSYNC 信号来时还没准备好数据导致丢帧。
绘制耗时太长，有一些工具可以帮助我们定位问题。主线程太忙则需要注意了，主线程关键职责是处理用户交互，在屏幕上绘制像素，并进行加载显示相关的数据，所以特别需要避免任何主线程的事情，这样应用程序才能保持对用户操作的即时响应。总结起来，主线程主要做以下几个方面工作：
1.UI 生命周期控制
2.系统事件处理
3.消息处理
4.界面布局
5.界面绘制
6.界面刷新
除此之外，应该尽量避免将其他处理放在主线程中，特别复杂的数据计算和网络请求等。
二、稳
应用的稳定性定义很宽泛，影响稳定性的原因很多，比如内存使用不合理、代码异常场景考虑不周全、代码逻辑不合理等，都会对应用的稳定性造成影响。其中最常见的两个场景是：Crash 和 ANR，这两个错误将会使得程序无法使用，比较常用的解决方式如下：
1.提高代码质量。比如开发期间的代码审核，看些代码设计逻辑，业务合理性等。
2.代码静态扫描工具。常见工具有Clang Static Analyzer、OCLint、Infer等等。
3.Crash监控。把一些崩溃的信息，异常信息及时地记录下来，以便后续分析解决。
4.Crash上传机制。在Crash后，尽量先保存日志到本地，然后等下一次网络正常时再上传日志信息。
三、省
在移动设备中，电池的重要性不言而喻，没有电什么都干不成。对于操作系统和设备开发商来说，耗电优化一致没有停止，去追求更长的待机时间，而对于一款应用来说，并不是可以忽略电量使用问题，特别是那些被归为“电池杀手”的应用，最终的结果是被卸载。因此，应用开发者在实现需求的同时，需要尽量减少电量的消耗。
1.CPU
不论用户是否正在直接使用, CPU 都是应用所使用的主要硬件, 在后台操作和处理推送通知时, 应用仍然会消耗 CPU 资源
应用计算的越多,消耗的电量越多.在完成相同的基本操作时, 老一代的设备会消耗更多的电量, 计算量的消耗取决于不同的因素
2.网络
智能的网络访问管理可以让应用响应的更快,并有助于延长电池寿命.在无法访问网络时,应该推迟后续的网络请求, 直到网络连接恢复为止. 此外,应避免在没有连接 WiFi 的情况下进行高宽带消耗的操作.比如视频流, 众所周知,蜂窝无线系统(LTE,4G,3G等)对电量的消耗远远大于 WiFi信号,根源在于 LTE 设备基于多输入,多输出技术,使用多个并发信号以维护两端的 LTE 链接,类似的,所有的蜂窝数据链接都会定期扫描以寻找更强的信号. 因此:我们需要
1)在进行任何网络操作之前,先检查合适的网络连接是否可用
2)持续监视网络的可用性,并在链接状态发生变化时给与适当的反馈
3).定位管理器和** GPS**
我们都知道定位服务是很耗电的,使用 GPS 计算坐标需要确定两点信息:
1)时间锁每个 GPS 卫星每毫秒广播唯一一个1023位随机数, 因而数据传播速率是1.024Mbit/s GPS 的接收芯片必须正确的与卫星的时间锁槽对齐
2)频率锁 GPS 接收器必须计算由接收器与卫星的相对运动导致的多普勒偏移带来的信号误差
计算坐标会不断的使用 CPU 和 GPS 的硬件资源,因此他们会迅速的消耗电池电量, 那么怎么减少呢？
1）关闭无关紧要的特性
判断何时需要跟踪位置的变化, 在需要跟踪的时候调用 startUpdatingLocation方法,无须跟踪时调用stopUpdatingLocation方法.
当应用在后台运行或用户没有与别人聊天时,也应该关闭位置跟踪,也就说说,浏览媒体库,查看朋友列表或调整应用设置时, 都应该关闭位置跟踪
2）只在必要时使用网络
为了提高电量的使用效率, IOS 总是尽可能地保持无线网络关闭.当应用需要建立网络连接时,IOS 会利用这个机会向后台应用分享网络会话,以便一些低优先级能够被处理, 如推送通知,收取电子邮件等
关键在于每当用户建立网络连接时,网络硬件都会在连接完成后多维持几秒的活动时间.每次集中的网络通信都会消耗大量的电量
要想减轻这个问题带来的危害,你的软件需要有所保留的的使用网络.应该定期集中短暂的使用网络,而不是持续的保持着活动的数据流.只有这样,网络硬件才有机会关闭
4.屏幕
屏幕非常耗电, 屏幕越大就越耗电.当然,如果你的应用在前台运行且与用户进行交互,则势必会使用屏幕并消耗电量
这里有一些方案可以优化屏幕的使用:
1)动画优化
当应用在前台时, 使用动画,一旦应用进入了后台,则立即暂停动画.通常来说,你可以通过监听 UIApplicationWillResignActiveNotification或UIApplicationDIdEnterBackgroundNotification的通知事件来暂停或停止动画,也可以通过监听UIApplicationDidBecomeActiveNotification的通知事件来恢复动画
2)视频优化
视频播放期间,最好保持屏幕常量.可以使用UIApplication对象的idleTimerDisabled属性来实现这个目的.一旦设置了 YES, 他会阻止屏幕休眠,从而实现常亮.
与动画类似,你可以通过相应应用的通知来释放和获取锁
用户总是随身携带者手机,所以编写省电的代码就格外重要, 毕竟手机的移动电源并不是随处可见, 在无法降低任务复杂性时, 提供一个对电池电量保持敏感的方案并在适当的时机提示用户, 会让用户体验良好。
四、小
应用安装包大小对应用使用没有影响，但应用的安装包越大，用户下载的门槛越高，特别是在移动网络情况下，用户在下载应用时，对安装包大小的要求更高，因此，减小安装包大小可以让更多用户愿意下载和体验产品。
当然，瘦身和减负虽好，但需要注意瘦身对于项目可维护性的影响，建议根据自身的项目进行技巧的选取。
App安装包是由资源和可执行文件两部分组成，安装包瘦身从以下三部分优化。
资源优化：
1.删除无用的资源
2.删除重复的资源
3.无损压缩图片
4.不常用资源换为下载
编译优化：
1.去除debug符号
2.开启编译优化
3.避免编译多个架构
可执行文件优化：
1.去除无用代码
2.统计库占用，去除无用库
3.混淆类/方法名
4.减少冗余字符串
5.ARC->MRC (一般不到特殊情况不建议这么做,会提高维护成本)
缩减iOS安装包大小是很多中大型APP都要做的事，一般首先会对资源文件下手，压缩图片/音频，去除不必要的资源。这些资源优化做完后，我们还可以尝试对可执行文件进行瘦身，项目越大，可执行文件占用的体积越大，又因为AppStore会对可执行文件加密，导致可执行文件的压缩率低，压缩后可执行文件占整个APP安装包的体积比例大约有80%~90%，还是挺值得优化的。
下面是一些常见的优化方案：
TableViewCell 复用
在cellForRowAtIndexPath:回调的时候只创建实例，快速返回cell，不绑定数据。在willDisplayCell: forRowAtIndexPath:的时候绑定数据（赋值）。
高度缓存
在tableView滑动时，会不断调用heightForRowAtIndexPath:，当cell高度需要自适应时，每次回调都要计算高度，会导致 UI 卡顿。为了避免重复无意义的计算，需要缓存高度。
怎么缓存？
字典，NSCache。
UITableView-FDTemplateLayoutCell
[if !supportLineBreakNewLine]
[endif]
视图层级优化
不要动态创建视图
在内存可控的前提下，缓存subview。
善用hidden。
[if !supportLineBreakNewLine]
[endif]
减少视图层级
减少subviews个数，用layer绘制元素。
少用clearColor，maskToBounds，阴影效果等。
[if !supportLineBreakNewLine]
[endif]
减少多余的绘制操作
图片
不要用JPEG的图片，应当使用PNG图片。
子线程预解码（Decode），主线程直接渲染。因为当image没有Decode，直接赋值给imageView会进行一个Decode操作。
优化图片大小，尽量不要动态缩放(contentMode)。
尽可能将多张图片合成为一张进行显示。
[if !supportLineBreakNewLine]
[endif]
减少透明view
使用透明view会引起blending，在iOS的图形处理中，blending主要指的是混合像素颜色的计算。最直观的例子就是，我们把两个图层叠加在一起，如果第一个图层的透明的，则最终像素的颜色计算需要将第二个图层也考虑进来。这一过程即为Blending。
会导致blending的原因：
UIView的alpha<1。
UIImageView的image含有alpha channel（即使UIImageView的alpha是1，但只要image含有透明通道，则仍会导致blending）。
[if !supportLineBreakNewLine]
[endif]
为什么blending会导致性能的损失？
原因是很直观的，如果一个图层是不透明的，则系统直接显示该图层的颜色即可。而如果图层是透明的，则会引起更多的计算，因为需要把另一个的图层也包括进来，进行混合后的颜色计算。
opaque设置为YES，减少性能消耗，因为GPU将不会做任何合成，而是简单从这个层拷贝。
[if !supportLineBreakNewLine]
[endif]
减少离屏渲染
离屏渲染指的是在图像在绘制到当前屏幕前，需要先进行一次渲染，之后才绘制到当前屏幕。
OpenGL中，GPU屏幕渲染有以下两种方式：
On-Screen
Rendering即当前屏幕渲染，指的是GPU的渲染操作是在当前用于显示的屏幕缓冲区中进行。
Off-Screen
Rendering即离屏渲染，指的是GPU在当前屏幕缓冲区以外新开辟一个缓冲区进行渲染操作。
[if !supportLineBreakNewLine]
[endif]
小结
性能优化不是更新一两个版本就可以解决的，是持续性的需求，持续集成迭代反馈。在实际的项目中，在项目刚开始的时候，由于人力和项目完成时间限制，性能优化的优先级比较低，等进入项目投入使用阶段，就需要把优先级提高，但在项目初期，在设计架构方案时，性能优化的点也需要提早考虑进去，这就体现出一个程序员的技术功底了。
什么时候开始有性能优化的需求，往往都是从发现问题开始，然后分析问题原因及背景，进而寻找最优解决方案，最终解决问题，这也是日常工作中常会用到的处理方式。
