特别鸣谢老大lunzi哥的分享。短短几分钟，感觉学到了很多！
这只是一篇方法论或者是个引子，性能优化具体操作，请参考另外一篇文章
各种性能优化方案
前言
项目代码在随着业务需求的不断迭代和数据量不断增加时，原有代码的逻辑处理方式在性能方面可能就跟不上要求了。要不就是处理时间过长，要不就是某些异常情况没有考虑，导致了一系列奇怪的问题。
性能优化，就是为了解决上述问题而想到的一个方案。我们可以分析性能可能发生异常的情况和借助一些工具，从而制定出对应的优化策略，让程序得以优化
性能瓶颈分类
具体的内容直接写出：
I/O开销
- 网络I/O
- 文件I/O
- 内存I/O
计算
计算又可以分为
绘制/渲染
排版
具体细说
I/O相关
-
网络
这一方面，其实在客户端可做的不多，因为，我们如果正常的发送一个请求，更多的耗时操作或者瓶颈出现在server端，高并发，多线程，多表格查询，都有可能导致server响应速度增加。
所以在通常情况下，网络我们暂时不去考虑(因为需要考虑性价比和提升结果，一切以结果为出发点)
-
文件 和 内存
-
内存
在计算机中，我们默认内存的操作速度是很快的，虽然其可缓存的数据相对文件操作来说相当少，但也不影响其操作速度的快慢，所以，我们正常去操作内存IO，也不会太过影响性能
-
文件
在IO这部分，最大头的就是文件IO了。文件的读写，保存或者查找，都是IO操作里最花费时间。所以如果想要优化IO，从文件IO操作着手效益最高
相关的例子说明：
- 二进制重排
- 多个framework的合并
- 减少项目中文件数量
都能提高相关的内容
-
计算
绘制/渲染
- 缓存复用
- 视图层级
最典型例子UITableView的tableviewcell缓存机制，其初衷就是为了防止过多的cell视图被创建，创建没有什么，就是分配一个内存地址，但是view上的内容绘制、渲染，在从创建到获得view对象之间，占比相对较大。
还有一个不太恰当的例子：离屏渲染。圆角触发离屏渲染终究还是因为layer层太多视图层级，导致需要一层层解析处理渲染，再统一合并渲染处理。
排版
解决方案：预排版
缓存cell高度就是最好的例子
最典型例子还是在UITableView的UITableViewDelegate方法heightForRowAtIndexPath。此方法在创建并滑动的时候，会被多次调用。如果，cell的高度每次都要通过计算获得，那将大大降低滑动效率。这也是为什么UITableView会增加一个预估高度的属性，虽然有时候觉得很鸡肋，且会影响页面显示(跳动什么的)。但也是为了减少应要排版而引发计算的消耗。
性能的具体体验
时间
启动时间也好，方法调用时间也好，视图滚动耗时时间也好，都与时间有关。所以通过时间来判断性能的好坏，是个不错的选择。
-
前提
前面所说，除网络IO操作外，这个的大头决定与server，客户端没有太多能力可以处理。所以时间计算时，需要剔除网络请求带来的影响
如滑动操作，1000条数据要滑动展示，最好先将这1000条数据内容加载并缓存，然后剔除网络的影响来测量，就能较为准确的知道计算可能导致的时延问题。
-
工具
时间：instruments的time profiler就是很好的工具。
FPS：很多第三方库可以选择的。
## 其它内容？
有些什么其他的耗电啊，内存泄漏啊，有些都是在特别明显再处理(耗电)或者是代码层面(规范编写)在处理或者避免的。所以不算太大的优化点。
当然也是需要的，只是在必要时再做，考虑投入产出比即可。
方案的制定
优化的大体方向已经有了，那具体优化细节点，该如何确定呢？
大体步骤：
- 现状是啥？
- 问题点有哪些？每个问题点的可能影响占比是多少？
- 针对占比大的问题，分析问题所属类型，使用对应类型解决办法尝试
- 优化前优化后结果对比，输出优化结果。确定优化成效
- 总结
最后还是感谢lunzi哥的分享内容！醍醐灌顶
网友评论