前言
对于iOS上一文简单介绍内存，可是还少了写东西，我自己感觉对于内存和线程的联系不够多。特别是app 在多线程处理任务和实际业务逻辑的联系，是不够的，随着以后的项目的叠加，这方面我会更新。
这篇简单介绍自己在app 时间消耗的检测
工具
还是instrument 工具是
Time profile 具体使用
打开后
线程模式
对于all process 不能确定到底是哪个线程，可以点击右上角的具体线程分析
在时间轴上进行区域选择，这样就能判断出来，具体的时间耗时。
第三个就是，第一个是对于cpu 哪个内核的消耗情况
线程区域选择
说明是主线程是主要耗时的线程，然后耗时的时间大概是269ms，下一步就是找出具体的函数方法
集中显示代码的耗时问题
1）Separate by Thread：按线程分开进行分析。容易找出消耗资源的问题线程，特别是对于主线程，因为主线程要处理和渲染所有的接口数据及UI视图，当主线程受到阻塞性操作，一定会造成程序的卡顿，或停止响应。
（2）Invert Call Tree：反向显示调用树。把调用层级最深的方法显示在最上面，容易找到最耗时的操作。
（3）Hide System Libraries：隐藏缺失的符号。把干扰信息屏蔽掉，即把列表中因为系统架构，或DSYM文件缺失造成奇怪的十六进制的数值。
（4）Flatten Recursion：拼合递归。把同一递归函数产生的多条堆栈合并为一条。
（5）Top Functions：找到最耗时的函数或方法。
不过，我在选择过程中，遇到个不大不小的问题，就是选择投票functions 的时候 instrument 崩溃。
寻找代码
对于自己代码中weight的比例 和self weight的时长，过大的要审查，是不是有复制的逻辑，或者大量的内存申请，大的图片缓存
一般如果网络请求，可以看看，是不是网络架构和网络请求的效率和json 解析的方式是不是最优。
这里的每一个细化，可能是选择第三方的依据，何必重复自己来造轮子呢。
例子
这里显然比较耗时的是tabbar 的设置，而不是他上班的loc 的定位，也不是网络请求。
问题确定来，下一步就是相关问题解决了。根据不同的项目，不同的责任人来进行代码的优化。
一看一个10% 不少，是不是可以剩下来，还要看业务逻辑是不是允许这样优化，一切的优化建立在产品需求的要求基础上。
具体方法寻找
图片设置在button 上的问题，更加确定和tabbar 也是没有关系。
利用imageWithContentsOfFile 设置图片 就解决了这个加载耗时的问题，为啥tabbar 对于小图片如此敏感呢？？？
这里的性能
时间消耗，直接影响是app 的流畅和使用的感受，作为客户单研发，这个还是尤为重要,可是当在优化app的时候，优化多少，哪里优化，哪里有优化的必要，还有谁来优化哪里，这些都需要图形化数据来体现，这个工具太棒来。
以后的性能
对于第三方的性能我们还有很多引用，不过哪个更好，这个还是性能说的算，如 YYModel ，JsonModel,等，解析对象时候，哪个更快，说时候，如果项目不够复杂，真是很难感觉到。
参考文献
官方文档
https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/Instrument-TimeProfiler.html
简书推荐
http://www.jianshu.com/p/68387876ebcc
