iOS和Mac开发 如何挖掘项目做性能优化点

特别鸣谢老大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：很多第三方库可以选择的。

## 其它内容？

有些什么其他的耗电啊，内存泄漏啊，有些都是在特别明显再处理(耗电)或者是代码层面(规范编写)在处理或者避免的。所以不算太大的优化点。

当然也是需要的，只是在必要时再做，考虑投入产出比即可。

方案的制定

优化的大体方向已经有了，那具体优化细节点，该如何确定呢？

大体步骤：

1. 现状是啥？
2. 问题点有哪些？每个问题点的可能影响占比是多少？
3. 针对占比大的问题，分析问题所属类型，使用对应类型解决办法尝试
4. 优化前优化后结果对比，输出优化结果。确定优化成效
5. 总结

最后还是感谢lunzi哥的分享内容！醍醐灌顶

一些大牛的总结

落影 -- 启动时间的一些分析