1 通过TraceView发现程序代码可优化的点
1.1 TraceView简介
TraceView 简介
TraceView 是 Android 平台特有的数据采集和分析工具，它主要用于分析 Android 中应用程序的 hotspot。TraceView 本身只是一个数据分析工具，而数据的采集则需要使用 Android SDK 中的 Debug 类或者利用 DDMS 工具。二者的用法如下：
开发者在一些关键代码段开始前调用 Android SDK 中 Debug 类的 startMethodTracing 函数，并在关键代码段结束前调用 stopMethodTracing 函数。这两个函数运行过程中将采集运行时间内该应用所有线程（注意，只能是 Java 线程）的函数执行情况，并将采集数据保存到 /mnt/sdcard/ 下的一个文件中。开发者然后需要利用 SDK 中的 TraceView 工具来分析这些数据。
1.2 TraceView使用
借助 Android SDK 中的 DDMS 工具。DDMS 可采集系统中某个正在运行的进程的函数调用信息。对开发者而言，此方法适用于没有目标应用源代码的情况。
DDMS 中 TraceView 使用示意图如下，调试人员可以通过选择 Devices 中的应用后点击
在Android Studio --> Tools --> Android --> Android Device Monitor打开DDMS
按钮 Start Method Profiling（开启方法分析）和点击
Stop Method Profiling（停止方法分析）
点击开始录制后，我们就可以开始操作App，想测试哪里就点哪里（步步高打火机，哪里不会点哪里）。
录制完成后点击同一个按钮结束，就可以看到以下的TraceView界面。
TraceView 界面比较复杂，其 UI 划分为上下两个面板，即 Timeline Panel（时间线面板）和 Profile Panel（分析面板）。上图中的上半部分为 Timeline Panel（时间线面板），Timeline Panel 又可细分为左右两个 Pane：
左边 Pane 显示的是测试数据中所采集的线程信息。由图可知，本次测试数据采集了 main 线程，传感器线程和其它系统辅助线程的信息。
右边 Pane 所示为时间线，时间线上是每个线程测试时间段内所涉及的函数调用信息。这些信息包括函数名、函数执行时间等。由图可知，Thread-1412 线程对应行的的内容非常丰富，而其他线程在这段时间内干得工作则要少得多。
另外，开发者可以在时间线 Pane 中移动时间线纵轴。纵轴上边将显示当前时间点中某线程正在执行的函数信息。
上图中的下半部分为 Profile Panel（分析面板），Profile Panel 是 TraceView 的核心界面，其内涵非常丰富。它主要展示了某个线程（先在 Timeline Panel 中选择线程）中各个函数调用的情况，包括 CPU 使用时间、调用次数等信息。而这些信息正是查找 hotspot 的关键依据。
1.3 然后我们根据Incl Cpu Time进行降序排列，看看那些方法调用的时间最长，如下图所示：
先说说标题栏上的各个指标是什么意思：
结合Excl Real Time查看方法自身耗时，同时注意CPU占用率，CPU占用率达到100%的基本上都很可疑了，需要看看是否有死循环调用。
结合方法的调用次数查看，方法调用次数特别多的也可以看看有什么可以优化的地方。
1.4 点开调用占用CPU时间最长的第一个方法，Thread.run()方法，看看是哪里调用了
看起来这个方法非常可疑，到代码里看看
FlowerCanvasLayout里面的mThread变量的run方法果然干了件坑爹的事情，我们都知道代码是要在CPU里跑的（这特么不是废话吗？），很多刚开始开发Android的同学觉得，虽然Android主线程不能随便进行耗时操作，同理也不能死循环，那我在子线程里死循环就可以啦，但是这样是有问题的，在子线程中进行死循环操作，虽然CPU会剥夺子线程的时间片，但是子线程里会抢占主线程的时间片，就好像虽然一个子线程能抢的时间片不多，但是如果有多个子线程呢？子线程里还有死循环的代码，这是万万不可的，因此这里我们需要在子线程中单次循环进行线程挂起，在合适的时候唤醒此线程避免一直进行死循环等待。
1.5 JSON在主线程解析
继续通过TraceView查找调用特别耗时的方法，看到一个，图片可能不好看清，主要看看方法调用时间，
查看代码，发现在SocketActivity中调用了SocketMessageHelper.handleSocketMessage，看看这个方法里干了什么。
这个JSON是服务器通过Socket分发的各种事件，非常长，连Logcat都无法完成打印出来，可想而知在主线程里解析这么长的JSON字符串会导致多么的卡顿。
解决办法：把JSON解析移动到工作线程中完成，解析完成后分发给主线程
1.6 更多的优化例子持续更新...
主要的是要学会使用TraceView找出App中可以优化的点，每个例子只是一种方法
1.7 写代码过程中避免主线程卡顿的注意事项：
1）不要大量使用new Thread()的方式初始化子线程，这样会导致大量的线程创建活动，线程创建是很耗时的，而且还带有内存占用（好像是64KB？），尽量使用线程池的方式复用线程。
2）不要创建太多子线程，太多子线程会抢占主线程时间片，导致UI卡顿，使用缓存线程池。
3）创建子线程时记得设置优先级为较低优先级
线程池框架：
private static final ThreadFactory sThreadFactory = new ThreadFactory() {
private final AtomicInteger mCount = new AtomicInteger(1);
public Thread newThread(Runnable r) {
Thread t = new Thread(r, "TaskExecutor #" + mCount.getAndIncrement());
t.setPriority(Thread.MIN_PRIORITY);
return t;
}
};
HandlerThread:
mHandlerThread = new HandlerThread(threadName, android.os.Process.THREAD_PRIORITY_BACKGROUND);
mHandlerThread.start();
4）不要让主线程和工作线程竞争同一个锁，容易让主线程卡顿等待，导致ANR，尽量让主线程不需要获取锁，需要获取锁的方法尽量在子线程调用。
5）解析JSON等耗时操作不要在主线程执行
6）不要让工作线程进行死循环，这样会大大增加CPU使用率，增加设备耗电并且降低主线程的效率。
7）减少SharePreferences打开关闭次数，尽量合并写入，减少磁盘读取写入次数，使用apply()代替commit()，这个虽然是简单的优化，但是能大大减少主线程读写文件带来的卡顿（SharePreference是XML文件，使用commit同步写入的话在主线程读写磁盘会有性能损耗，使用apply异步写入代替，很多开发人员不重视这一点）
8）避免在主线程操作文件和数据库
9）使用适当大小的Buffer读写文件 ，过小的Buffer会导致多次读写磁盘，例如一个1M的文件，你使用1K的Buffer就需要读十次，10M的文件呢？
//buffer的大小根据业务文件平均大小选择
FileInputStream in = ...
byte[] buffer = new byte[8196];
while (len = in. read(buffer,0,8196)) != -1) {
}
10）除非必要，否则尽量不要使用索引（AUTOINCREMENT），使用索引需要维护多一张索引表，写入时都需要进行多次写入磁盘，会影响写入效率，频繁查询的表才适合使用索引，频繁写入少查询的表不适合使用索引。
SQLite创建一个叫sqlite_sequence的内部表来记录该表使用的最大行号。如果指定使用AUTOINCREMENT来创建表，则sqlite_sequence也随之创建。UPDATE、INSERT、DELETE语句可能会修改sqlite_sequence的内容。因为维护sqlite_sequence表带来的额外开销会导致INSERT的效率降低。
11）避免使用低效率的API，如上面的JSON解析方法，原来的代码直接使用了Java自带的JSON API解析，这个库的解析效率较低，替换使用GSON解析，并且解析方法放到工作线程中。
12）某些特别消耗计算能力的方法，可以通过RenderThread放到GPU中调用。
