软件性能优化是一个很大的概念。 首先，从附带的工具开始，利用工具帮助优化性能。
解决系统性能问题的主要步骤是搜索-决策-协调
寻找：要优化，请先找出那个部分有性能问题。 例如，有用户投诉所的APP。 你和他沟通后，他说他会在主界面上滑动进程。 这样，大致找到了需要优化的范围点。 接下来需要定位呢。 当然这是一种游击的、碎片化的方式，最好还是对程序进行多种针对性的测试，得到测试数据，然后根据需要制定调整目标，要求达到什么样的优化效果。 例如，启动时间是2310ms、1320ms编程等。
定：找到了问题的大致方向，需要更具体地分析系统瓶颈，分析测试数据，找出其中的bottleneck。
调：要找到瓶颈，当然需要优化bottleneck的代码。
关于瓶颈，一般主要有以下三个类别。
低功耗：函数被调用的次数很少，但每次调用都很费时间。
低功耗：指那些函数本身占用时间不长但调用非常频繁的函数。
高功耗：它频繁调用，函数本身需要很长时间，绝对是着眼于对象。
要找到这些瓶颈，请使用TraceView
像路一样，首先单击“Start Method Profile”
按钮，然后分别单击与这两个函数对应的按钮，以便程序记录下下载位置。 执行后的效果请点击下图查看大图
翠西视图介绍
我需要介绍一下这个界面的内容
整个界面主要分为两大块，上部由a和c构成的时间线面板(Timeline Panel )和下部的分析面板(Profile Panel )。
enter image description here
Tips :双击上面的函数信息栏可以缩小。 用鼠标稍微水平拉动线程的颜色部分，图表的颜色脉冲bar的高度表示cpu的利用率，高度越高表示cpu的利用率越高。 白色gap中的白色块表示该线程当前不占用cpu，其他线程占用了黑色块。 (系统空闲)。
仔细看看下面顶部的时间板吧。 放大后，将鼠标停留在某个刻柱上，上部会显示对应的时间、系统正在执行的程序信息。 左边表示对应的线程信息。 点击某个刻度柱，对应的柱也会移动一下！
从图中可以看到，在2509.181毫秒的时候，我们的CPU正在运行我们的简单功能()。
函数下行中的excl cpu msec、incl cpu msec和excl readl msec等时间信息将在后面详细介绍。
名字
线程执行过程中调用的函数名称
Incl Cpu Time
某个函数占用的CPU时间。 包含内部调用其他函数的CPU时间
Excl Cpu Time
某个函数消耗的CPU时间。 不包括内部调用中其他函数消耗的CPU时间
Incl Real Time
函数执行的实际时间。 毫秒单位。 包含调用其他函数所用的实际时间
Excl Real Time
函数执行的实际时间。 毫秒单位。 不包括调用其他函数所用的实际时间
呼叫接收呼叫/总
递归调用占调用函数的次数和调用总数的百分比
Cpu Time/Call
某个函数调用CPU的时间与调用次数之比。 相当于该函数的平均执行时间
Real Time/Call
与CPU Time/Call类似，只是统计单位变成了实时
Incl Cpu Time %
表示按时间百分比聚集的incl CPU时间
了解了这些名字的含义之后，现在我们可以用Traceview来寻找我们的瓶颈了！
寻找瓶颈
高频低功耗
首先，看看我们的高频低功耗系统。 根据定义，他是个传呼较多的家伙。 在我们前面的介绍中，有一个叫Call Recur Calls/Total的列，他说明了被调用的次数。 所以，首先，我们根据这个属性，按照从高到低的顺序排列一下。 排序结果如下图所示。 次数，我们的simplyFunc被使用了666次，发现是正确的。 是的，就这样看看他上面的几个667次的吧。 由于我们的SimplyFunc的内容是将字符串连接起来打印日志，所以也多次调用了与String有关的一些函数。
privatevoidsimplyfunc ((stringa=' hello '； 字符串b=' world '； log.e(tag，' simplyFunc ) ) print=' a b )； }
直观上，编译器可能会在一个StringBuilder中处理第三行代码。
时间确认了该函数的调用次数很多，频率很高，但这并不意味着人很费时间，所以从右边占用的CPU时间来看，他的Incl Cpu Time为37.183，占总数的75.9% 是的，这样我们确认这个函数是瓶颈，我们需要时间来处理。
p>到这里基本我们确定了，完成了找的步骤。现在需要完成的是定的步骤，确定下瓶颈实际在哪里。我们再看下图，在我们的函数展开的下面，有些内容，我们需要看下。Parents ： 这个表示调用这个函数的父方法，就是指是onRepeatClick
调用了这个函数。
Children：相对于Parents，这个就是他调用的。
我们看它耗费的时间多的是去调用StringBuilder去了。嗯，我们明明没调用这个类，为何他耗费时间去和Stringbuilder玩去了呢？因为这是编译后的运行效果，编译器会做些手脚嘛。
根据Children的信息，告诉我们SimplyFunc主要耗费的时间都去做了什么去了，这样我们可以根据这些信息，对我们的函数做针对性的优化内容。你也可以一直点children
里面最耗费时间的，一直跟进去，直到你觉得找到答案为主。
细看函数
上面的整流程是相对粗糙的，因为整个下面的面板还有很多我们不关心的内容，有时函数多起来就找的麻烦，为了细化范围，这里提供另外的方案
用Debug.startMethodTracing()
和Debug.stopMethodTracing()
方法，当我们再函数加多这对函数，运行完这段代码后，在/sdcard
路径就会有一个trace文件生成。另外也可以调用startMethodTracing(String traceName)
设置trace文件的文件名，最后你可以用adb pull /sdcard/test.trace /tmp
命令将trace文件复制到你的电脑中，然后像刚才那样，用DDMS工具打开。
用这种更精确的方法，虽然罗嗦些，但非常适合检测某一个方法的性能，颗粒度更细。
public void onRepeatClick(View view) { Debug.startMethodTracing("simplyFunc"); for (int i = 0; i < 666; i++) { simplyFunc(); } Debug.stopMethodTracing();}