Android lint工具是Android studio中集成的一个代码提示工具，它主要负责对你的代码进行优化提示，包括xml和java文件，很强大。编写完代码及时进行lint测试，会让我们的代码变得非常规范而且避免代码冗余。让我们及时发现代码中隐藏的问题。 lint的使用时非常简单的，我看可以用它实现代码布局的优化，Java代码的优化，不过我觉得根本解决问题还是得依赖于开发者的素质。 例子：我们需要删除掉一些无用的变量和布局文件等，这对代码的冗余有很大的帮助。 [img]http://files.jb51.net/file_images/article/201703/2017031911430012.png[/img] [img]http://files.jb51.net/file_images/article/201703/2017031911430413.png[/img] [img]http://files.jb51.net/file_images/article/201703/2017031911430414.png[/img] 代码提示我们在6行需要为ImageView添加ContentDescription属性，突然感觉好强大。 其实我们还可以用它自定义搜索，主要是删除一些无用的文件用的。 [img]http://files.jb51.net/file_images/article/201703/2017031911430415.png[/img] [img]http://files.jb51.net/file_images/article/201703/2017031911430516.png[/img] [img]http://files.jb51.net/file_images/article/201703/2017031911430517.png[/img] 然后按要求优化下代码就好了。 [b]TraceView[/b] TraveView是Android studio集成的一个性能优化工具，相信很多人都用过它，之前也专门讲过，它主要计算工程内方法运行所占用的时间，调用次数，以此来优化App运行效率。 [b]使用TraceView主要有两种方式：[/b] 1.最简单的方式就是直接打开DDMS，选择一个进程，然后按上面的“Start Method Profiling”按钮，等红色小点变成黑色以后就表示TraceView已经开始工作了。然后我就可以滑动一下列表（现在手机上的操作肯定会很卡，因为Android系统在检测Dalvik虚拟机中每个Java方法的调用，这是我猜测的）。操作最好不要超过5s，因为最好是进行小范围的性能测试。然后再按一下刚才按的按钮，等一会就会出现上面这幅图，然后就可以开始分析了。 2.第2种方式就是使用android.os.Debug.startMethodTracing();和android.os.Debug.stopMethodTracing();方法，当运行了这段代码的时候，就会有一个trace文件在/sdcard目录中生成，也可以调用startMethodTracing(String traceName) 设置trace文件的文件名，最后你可以使用adb pull /sdcard/test.trace /tmp 命令将trace文件复制到你的电脑中，然后用DDMS工具打开就会出现第一幅图了 [img]http://files.jb51.net/file_images/article/201703/2017031911430518.png[/img] 步骤：1.选择你要调试的进程。            2.点击start mothod profiling，待图标变黑。            3.选择sample base profiling，等待一会，然后再次点击这个按钮停止（开始的时候红点会变成灰色小方块，停止的时候再次点击这个按钮就               好了） 注意事项：在第三步的时候，需要选择监听的属性。 Trace base profiling 整体监听，项目中所有方法都会监听，资源消耗比较大。 sample base profiling 抽样监听，以指定的频率进行抽样调查，一般不要超过5s，需要较长时间获取准确的样本数据。 再次点击start mothod profiling，就会生成检测样本。 [img]http://files.jb51.net/file_images/article/201703/2017031911430619.png[/img] 整个界面包括上下两部分，上面是你测试的进程中每个线程的执行情况，每个线程占一行；下面是每个方法执行的各个指标的值。 上面一部分是你测试进程的中每个线程运行的时间线，下图中可以可以看到，主要只有一个main线程在执行。 下面是分析面板(Profile Panel) - 每一列内容  Inclusive time - 函数本身运行花费时间 + 函数调用其他函数时间 Exclusive time - 函数本身运行花费时间。 Calls + RecurCall/Total 调用 + 重复调用次数 / 函数总调用次数 Cpu Time/Call 总的Cpu时间与总的调用次数之比 [img]http://files.jb51.net/file_images/article/201703/2017031911430620.png[/img] Profile Panel面板有一些参数需要注意下

列名	描述
Name	该线程运行过程中所调用的函数名
Incl Cpu Time	某函数占用的CPU时间，包含内部调用其它函数的CPU时间
Excl Cpu Time	某函数占用的CPU时间，但不含内部调用其它函数所占用的CPU时间
Incl Real Time	某函数运行的真实时间（以毫秒为单位），内含调用其它函数所占用的真实时间
Excl Real Time	某函数运行的真实时间（以毫秒为单位），不含调用其它函数所占用的真实时间
Call+Recur Calls/Total	某函数被调用次数以及递归调用占总调用次数的百分比
Cpu Time/Call	某函数调用CPU时间与调用次数的比。相当于该函数平均执行时间
Real Time/Call	同CPU Time/Call类似，只不过统计单位换成了真实时间

[b]1. Incl Cpu Time[/b] define inclusive ： 全包括的 上图中可以看到0（toplevel） 的Incl Cpu Time 占了100%的时间，这个不是说100%的时间都是它在执行，请看下面代码： Incl Cpu Time表示方法top执行的总时间，假如说方法top的执行时间为10ms，方法a执行了1ms，方法b执行了2ms，方法c执行了3ms，方法d执行了4ms（这里是为了举个栗子，实际情况中方法a、b、c、d的执行总时间肯定比方法top的执行总时间要小一点）。 而且调用方法top的方法的执行时间是100ms，那么：

		Incl Cpu Time
top		10%
	a	10%
	b	20%
	c	30%
	d	40%

从上面图中可以看到： toplevel的 Incl Cpu Time 是1110.943，而io.bxbxbai.android.examples.activity.ExpandableLayoutMainActivity$SimpleAdapter.getItemView方法的Incl Cpu Time为12.859，说明后者的Incl Cpu Time % 约为1.2% 这个指标表示 这个方法以及这个方法的子方法（比如top方法中的a、b、c、d方法）一共执行的时间 [b]2. Excl Cpu Time[/b] 理解了Incl Cpu Time以后就可以很好理解Excl Cpu Time了，还是上面top方法的栗子： 方法top 的 Incl Cpu Time 减去 方法a、b、c、d的Incl Cpu Time 的时间就是方法top的Excl Cpu Time 了 [b]3. Incl Real Time[/b] 这个感觉和Incl Cpu Time 差不多，第7条会讲到。 [b]4. Excl Real Time[/b] 同上 [b]5. Calls + Recur Calls / Total[/b] 这个指标非常重要！ 它表示这个方法执行的次数，这个指标中有两个值，一个Call表示这个方法调用的次数，Recur Call表示递归调用次数，看下图： [img]http://files.jb51.net/file_images/article/201703/2017031911430621.jpg[/img] 我选中了一个方法，可以看到这个方法的Calls + Recur Calls 值是14 + 0，表示这个方法调用了14次，但是没有递归调用 从Children这一块来看，很多方法调用都是13的倍数，说明父方法中有一个判断，但是这不是重点，有些Child方法调用Calls为26，这说明了这些方法被调用了两遍，是不是可能存在重复调用的情况？这些都是可能可以优化性能的地方。 [b]6. Cpu Time / Call[/b] 重点来了！！！！！！！！！！ [img]http://files.jb51.net/file_images/article/201703/2017031911430622.jpg[/img] 这个指标应该说是最重要的，从上图可以看到，133这个方法的调用次数为20次，而它的Incl Cpu Time为12.859ms，那么133方法每一次执行的时间是0.643ms（133这个方法是SimpleAdapter的getItemView方法） 对于一个adapter的getView方法来说0.643ms是非常快的（因为这个adapter中只有一个TextView，我为了测试用的） 如果getView方法执行时间很长，那么必然导致列表滑动的时候产生卡顿现象，可以在getView方法的Children方法列表中找到耗时最长的方法，分析出现问题的原因： [list=1] [*]是因为有过多的计算？[/*] [*]还是因为有读取SD卡的操作？[/*] [*]还是因为adapter中View太复杂了？[/*] [*]还是因为需要有很多判断，设置View的显示还是隐藏[/*] [*]还是因为其他原因…[/*] [/list] [b]7. Real Time / Call[/b] Real Time 和 Cpu Time 我现在还不太明白它们的区别，我的理解应该是: [list=1] [*]Cpu Time 应该是某个方法占用CPU的时间[/*] [*]Real Time 应该是这个方法的实际运行时间 [/*] [/list] 感谢阅读，希望能帮助到大家，谢谢大家对本站的支持！