主要使用Traceview、monkey、monkey runner调试，traceview类似java web调优的visualvm
Traceview是android平台配备的一个很好的性能分析工具。它可以通过图形界面的方式让我们了解我们要跟踪的程序的性能，并且能具体到method。
性能调优点，包括同步改异步、缓存、Layout优化、数据库优化、算法优化、延迟执行、JNI等。
Android 编程下的 TraceView 简介及其案例实战 （http://www.cnblogs.com/sunzn/p/3192231.html）
TraceView 是 Android 平台配备一个很好的性能分析的工具。它可以通过图形化的方式让我们了解我们要跟踪的程序的性能，并且能具体到 method。详细内容参考：Profiling with Traceview and dmtracedump
TraceView 简介
TraceView 是 Android 平台特有的数据采集和分析工具，它主要用于分析 Android 中应用程序的 hotspot。TraceView 本身只是一个数据分析工具，而数据的采集则需要使用 Android SDK 中的 Debug 类或者利用 DDMS 工具。二者的用法如下：
- 开发者在一些关键代码段开始前调用 Android SDK 中 Debug 类的 startMethodTracing 函数，并在关键代码段结束前调用 stopMethodTracing 函数。这两个函数运行过程中将采集运行时间内该应用所有线程（注意，只能是 Java 线程）的函数执行情况，并将采集数据保存到 /mnt/sdcard/ 下的一个文件中。开发者然后需要利用 SDK 中的 TraceView 工具来分析这些数据。
- 借助 Android SDK 中的 DDMS 工具。DDMS 可采集系统中某个正在运行的进程的函数调用信息。对开发者而言，此方法适用于没有目标应用源代码的情况。
DDMS 中 TraceView 使用示意图如下，调试人员可以通过选择 Devices 中的应用后点击 
按钮 Start Method Profiling（开启方法分析）和点击 
Stop Method Profiling（停止方法分析）
开启方法分析后对应用的目标页面进行测试操作，测试完毕后停止方法分析，界面会跳转到 DDMS 的 trace 分析界面，如下图所示：
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 的关键依据。所以，对开发者而言，一定要了解 Profile Panel 中各列的含义。下表列出了 Profile Panel 中比较重要的列名及其描述。
TraceView 实战
了解完 TraceView 的 UI 后，现在介绍如何利用 TraceView 来查找 hotspot。一般而言，hotspot 包括两种类型的函数：
- 一类是调用次数不多，但每次调用却需要花费很长时间的函数。
- 一类是那些自身占用时间不长，但调用却非常频繁的函数。
测试背景：APP 在测试机运行一段时间后出现手机发烫、卡顿、高 CPU 占有率的现象。将应用切入后台进行 CPU 数据的监测，结果显示，即使应用不进行任何操作，应用的 CPU 占有率都会持续的增长。
按照 TraceView 简介中的方法进行测试，TraceView 结果 UI 显示后进行数据分析，在 Profile Panel 中，选择按 Cpu Time/Call 进行降序排序（从上之下排列，每项的耗费时间由高到低）得到如图所示结果：
图中 ImageLoaderTools$2.run() 是应用程序中的函数，它耗时为 1111.124。然后点击 ImageLoaderTools$2.run() 项，得到更为详尽的调用关系图：
上图中 Parents 为 ImageLoaderTools$2.run() 方法的调用者：Parents (the methods calling this method)；Children 为 ImageLoaderTools$2.run() 调用的子函数或方法：Children (the methods called by this method)。本例中 ImageLoaderTools$2.run() 方法的调用者为 Framework 部分，而 ImageLoaderTools$2.run() 方法调用的自方法中我们却发现有三个方法的 Incl Cpu Time % 占用均达到了 14% 以上，更离谱的是 Calls+RecurCalls/Total 显示这三个方法均被调用了 35000 次以上，从包名可以识别出这些方法为测试者自身所实现，由此可以判断 ImageLoaderTools$2.run() 极有可能是手机发烫、卡顿、高 CPU 占用率的原因所在。
代码验证
大致可以判断是 ImageLoaderTools$2.run() 方法出现了问题，下面找到这个方法进行代码上的验证：
1 package com.sunzn.app.utils; 2 3 import java.io.File; 4 import java.io.IOException; 5 import java.io.InputStream; 6 import java.lang.ref.SoftReference; 7 import java.util.ArrayList; 8 import java.util.HashMap; 9 10 import android.content.Context; 11 import android.graphics.Bitmap; 12 import android.os.Environment; 13 import android.os.Handler; 14 import android.os.Message; 15 16 public class ImageLoaderTools { 17 18 private HttpTools httptool; 19 20 private Context mContext; 21 22 private boolean isLoop = true; 23 24 private HashMap<String, SoftReference<Bitmap>> mHashMap_caches; 25 26 private ArrayList<ImageLoadTask> maArrayList_taskQueue; 27 28 private Handler mHandler = new Handler() { 29 public void handleMessage(android.os.Message msg) { 30 ImageLoadTask loadTask = (ImageLoadTask) msg.obj; 31 loadTask.callback.imageloaded(loadTask.path, loadTask.bitmap); 32 }; 33 }; 34 35 private Thread mThread = new Thread() { 36 37 public void run() { 38 39 while (isLoop) { 40 41 while (maArrayList_taskQueue.size() > 0) { 42 43 try { 44 ImageLoadTask task = maArrayList_taskQueue.remove(0); 45 46 if (Constant.LOADPICTYPE == 1) { 47 byte[] bytes = httptool.getByte(task.path, null, HttpTools.METHOD_GET); 48 task.bitmap = BitMapTools.getBitmap(bytes, 40, 40); 49 } else if (Constant.LOADPICTYPE == 2) { 50 InputStream in = httptool.getStream(task.path, null, HttpTools.METHOD_GET); 51 task.bitmap = BitMapTools.getBitmap(in, 1); 52 } 53 54 if (task.bitmap != null) { 55 mHashMap_caches.put(task.path, new SoftReference<Bitmap>(task.bitmap)); 56 File dir = mContext.getExternalFilesDir(Environment.DIRECTORY_PICTURES); 57 if (!dir.exists()) { 58 dir.mkdirs(); 59 } 60 String[] path = task.path.split("/"); 61 String filename = path[path.length - 1]; 62 File file = new File(dir, filename); 63 BitMapTools.saveBitmap(file.getAbsolutePath(), task.bitmap); 64 Message msg = Message.obtain(); 65 msg.obj = task; 66 mHandler.sendMessage(msg); 67 } 68 } catch (IOException e) { 69 e.printStackTrace(); 70 } catch (Exception e) { 71 e.printStackTrace(); 72 } 73 74 synchronized (this) { 75 try { 76 wait(); 77 } catch (InterruptedException e) { 78 e.printStackTrace(); 79 } 80 } 81 82 } 83 84 } 85 86 }; 87 88 }; 89 90 public ImageLoaderTools(Context context) { 91 this.mContext = context; 92 httptool = new HttpTools(context); 93 mHashMap_caches = new HashMap<String, SoftReference<Bitmap>>(); 94 maArrayList_taskQueue = new ArrayList<ImageLoaderTools.ImageLoadTask>(); 95 mThread.start(); 96 } 97 98 private class ImageLoadTask { 99 String path; 100 Bitmap bitmap; 101 Callback callback; 102 } 103 104 public interface Callback { 105 void imageloaded(String path, Bitmap bitmap); 106 } 107 108 public void quit() { 109 isLoop = false; 110 } 111 112 public Bitmap imageLoad(String path, Callback callback) { 113 Bitmap bitmap = null; 114 String[] path1 = path.split("/"); 115 String filename = path1[path1.length - 1]; 116 117 if (mHashMap_caches.containsKey(path)) { 118 bitmap = mHashMap_caches.get(path).get(); 119 if (bitmap == null) { 120 mHashMap_caches.remove(path); 121 } else { 122 return bitmap; 123 } 124 } 125 126 File dir = mContext.getExternalFilesDir(Environment.DIRECTORY_PICTURES); 127 128 File file = new File(dir, filename); 129 130 bitmap = BitMapTools.getBitMap(file.getAbsolutePath()); 131 if (bitmap != null) { 132 return bitmap; 133 } 134 135 ImageLoadTask task = new ImageLoadTask(); 136 task.path = path; 137 task.callback = callback; 138 maArrayList_taskQueue.add(task); 139 140 synchronized (mThread) { 141 mThread.notify(); 142 } 143 144 return null; 145 } 146 147 }
以上代码即是 ImageLoaderTools 图片工具类的全部代码，先不着急去研究这个类的代码实现过程，先来看看这个类是怎么被调用的：
1 ImageLoaderTools imageLoaderTools = imageLoaderTools = new ImageLoaderTools(this); 2 3 Bitmap bitmap = imageLoaderTools.imageLoad(picpath, new Callback() { 4 5 @Override 6 public void imageloaded(String picPath, Bitmap bitmap) { 7 if (bitmap == null) { 8 imageView.setImageResource(R.drawable.default); 9 } else { 10 imageView.setImageBitmap(bitmap); 11 } 12 } 13 }); 14 15 if (bitmap == null) { 16 imageView.setImageResource(R.drawable.fengmianmoren); 17 } else { 18 imageView.setImageBitmap(bitmap); 19 }
ImageLoaderTools 被调用的过程非常简单：1.ImageLoaderTools 实例化；2.执行 imageLoad() 方法加载图片。
在 ImageLoaderTools 类的构造函数（90行-96行）进行实例化过程中完成了网络工具 HttpTools 初始化、新建一个图片缓存 Map、新建一个下载队列、开启下载线程的操作。这时候请注意开启线程的操作，开启线程后执行 run() 方法（35行-88行），这时 isLoop 的值是默认的 true，maArrayList_taskQueue.size() 是为 0 的，在任务队列 maArrayList_taskQueue 中还没有加入下载任务之前这个循环会一直循环下去。在执行 imageLoad() 方法加载图片时会首先去缓存 mHashMap_caches 中查找该图片是否已经被下载过，如果已经下载过则直接返回与之对应的 bitmap 资源，如果没有查找到则会往 maArrayList_taskQueue 中添加下载任务并唤醒对应的下载线程，之前开启的线程在发现 maArrayList_taskQueue.size() > 0 后就进入下载逻辑，下载完任务完成后将对应的图片资源加入缓存 mHashMap_caches 并更新 UI，下载线程执行 wait() 方法被挂起。一个图片下载的业务逻辑这样理解起来很顺畅，似乎没有什么问题。开始我也这样认为，但后来在仔细的分析代码的过程中发现如果同样一张图片资源重新被加载就会出现死循环。还记得缓存 mHashMap_caches 么？如果一张图片之前被下载过，那么缓存中就会有这张图片的引用存在。重新去加载这张图片的时候如果重复的去初始化 ImageLoaderTools，线程会被开启，而使用 imageLoad() 方法加载图片时发现缓存中存在这个图片资源，则会将其直接返回，注意这里使用的是 return bitmap; 那就意味着 imageLoad() 方法里添加下载任务到下载队列的代码不会被执行到，这时候 run() 方法中的 isLoop = true 并且 maArrayList_taskQueue.size() = 0，这样内层 while 里的逻辑也就是挂起线程的关键代码 wait() 永远不会被执行到，而外层 while 的判断条件一直为 true，就这样程序出现了死循环。死循环才是手机发烫、卡顿、高 CPU 占用率的真正原因所在。
解决方案
准确的定位到代码问题所在后，提出解决方案就很简单了，这里提供的解决方案是将 wait() 方法从内层 while 循环提到外层 while 循环中，这样重复加载同一张图片时，死循环一出现线程就被挂起，这样就可以避免死循环的出现。代码如下：
1 private Thread mThread = new Thread() { 2 3 public void run() { 4 5 while (isLoop) { 6 7 while (maArrayList_taskQueue.size() > 0) { 8 9 try { 10 ImageLoadTask task = maArrayList_taskQueue.remove(0); 11 12 if (Constant.LOADPICTYPE == 1) { 13 byte[] bytes = httptool.getByte(task.path, null, HttpTools.METHOD_GET); 14 task.bitmap = BitMapTools.getBitmap(bytes, 40, 40); 15 } else if (Constant.LOADPICTYPE == 2) { 16 InputStream in = httptool.getStream(task.path, null, HttpTools.METHOD_GET); 17 task.bitmap = BitMapTools.getBitmap(in, 1); 18 } 19 20 if (task.bitmap != null) { 21 mHashMap_caches.put(task.path, new SoftReference<Bitmap>(task.bitmap)); 22 File dir = mContext.getExternalFilesDir(Environment.DIRECTORY_PICTURES); 23 if (!dir.exists()) { 24 dir.mkdirs(); 25 } 26 String[] path = task.path.split("/"); 27 String filename = path[path.length - 1]; 28 File file = new File(dir, filename); 29 BitMapTools.saveBitmap(file.getAbsolutePath(), task.bitmap); 30 Message msg = Message.obtain(); 31 msg.obj = task; 32 mHandler.sendMessage(msg); 33 } 34 } catch (IOException e) { 35 e.printStackTrace(); 36 } catch (Exception e) { 37 e.printStackTrace(); 38 } 39 40 } 41 42 synchronized (this) { 43 try { 44 wait(); 45 } catch (InterruptedException e) { 46 e.printStackTrace(); 47 } 48 } 49 50 } 51 52 }; 53 54 };
最后再附上代码修改后代码运行的性能图，和之前的多次被重复执行，效率有了质的提升，手机发烫、卡顿、高 CPU 占用率的现象也消失了。
TraceView有三种启动方式，下面逐一介绍：http://www.cnblogs.com/Android-and-android/archive/2013/03/05/2943859.html
1、 代码中启动
可以在代码中添加
Debug.startMethodTracing(“Tracelog”);
Debug.stopMethodTracing();
使用这种方式需要确保应用的AndroidMainfest.xml中的SD卡的读写权限是打开的，即
应用运行完后，会在SD卡下生成一个Tracelog文件，使用adb pull把这个文件拷贝至XP系统上，再在android sdk的tools目录下执行traceview Tracelog，则会弹出一个图形界面，通过这个图形界面就可以分析出应用的性能瓶颈;
2、 Eclipse中启动
Eclipse启动traceview及其简单，在DDMS中对需要分析的应用进程点击如下按钮
在需要停止traceview的地方点击相同的按钮，则Eclipse会自动弹出类似1中的一个图形界面;
3、 adb 命令行启动
adb shell am profile start
adb shell am profile stop
PROCESS_ID为应用的进程号，可以用ps命令获取，TRACE_FILE为需要存储的Trcaelog文件。
执行上面的命令后，会生成对应的TRACE_FILE，使用adb pull把这个文件拷贝至XP系统上，再在android sdk的tools目录下执行traceview Tracelog，则会弹出一个图形界面，通过这个图形界面就可以分析出应用的性能瓶颈;
Android应用性能优化之内存机制和不良代码
一、 Android的内存机制
Android的程序由Java语言编写，所以Android的内存管理与Java的内存管理相似。程序员通过new为对象分配内存，所有 对象在java堆内分配空间；然而对象的释放是由垃圾回收器来完成的。C／C++中的内存机制是“谁污染，谁治理”，java的就比较人性化了，给我们请了一个专门的清洁工（GC）。
那么GC怎么能够确认某一个对象是不是已经被废弃了呢？Java采用了有向图的原理。Java将引用关系考虑为图的有向边，有向边从引用者 指向引用对象。线程对象可以作为有向图的起始顶点，该图就是从起始顶点开始的一棵树，根顶点可以到达的对象都是有效对象，GC不会回收这些对象。如果某个 对象 (连通子图)与这个根顶点不可达(注意，该图为有向图)，那么我们认为这个(这些)对象不再被引用，可以被GC回收。
二、Android的内存溢出
Android的内存溢出是如何发生的?
Android的虚拟机是基于寄存器的Dalvik，它的最大堆大小一般是16M，有的机器为24M。因此我们所能利用的内存空间是有限的。如果我们的内存占用超过了一定的水平就会出现OutOfMemory的错误。
为什么会出现内存不够用的情况呢？我想原因主要有两个：
由于我们程序的失误，长期保持某些资源（如Context）的引用，造成内存泄露，资源造成得不到释放。
保存了多个耗用内存过大的对象（如Bitmap），造成内存超出限制。
三、万恶的static
static是Java中的一个关键字，当用它来修饰成员变量时，那么该变量就属于该类，而不是该类的实例。所以用static修饰的变量，它的生命周期是很长的，如果用它来引用一些资源耗费过多的实例（Context的情况最多），这时就要谨慎对待了。
public class ClassName { private static Context mContext; //省略 }
以上的代码是很危险的，如果将Activity赋值到么mContext的话。那么即使该Activity已经onDestroy，但是由于仍有对象保存它的引用，因此该Activity依然不会被释放。
我们举Android文档中的一个例子。
private static Drawable sBackground; @Override protected void onCreate(Bundle state) { super.onCreate(state); TextView label = new TextView(this); label.setText("Leaks are bad"); if (sBackground == null) { sBackground = getDrawable(R.drawable.large_bitmap); } label.setBackgroundDrawable(sBackground); setContentView(label); }
sBackground, 是一个静态的变量，但是我们发现，我们并没有显式的保存 Contex的引用，但是，当Drawable与View连接之后，Drawable就将View设置为一个回调，由于View中是包含Context的 引用的，所以，实际上我们依然保存了Context的引用。这个引用链如下：
Drawable->TextView->Context
所以，最终该Context也没有得到释放，发生了内存泄露。
如何才能有效的避免这种引用的发生呢？
第一，应该尽量避免static成员变量引用资源耗费过多的实例，比如Context。
第二、Context尽量使用Application Context，因为Application的Context的生命周期比较长，引用它不会出现内存泄露的问题。
第三、使用WeakReference代替强引用。比如可以使用WeakReference<Context> mContextRef
四、都是线程惹的祸
线程也是造成内存泄露的一个重要的源头。线程产生内存泄露的主要原因在于线程生命周期的不可控。我们来考虑下面一段代码。
public class MyActivity extends Activity { @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.main); new MyThread().start(); } private class MyThread extends Thread{ @Override public void run() { super.run(); //do somthing } } }
这段代码很平常也很简单，是我们经常使用的形式。我们思考一个问题：假设MyThread的run函数是一个很费时 的操作，当我们开启该线程后，将设备的横屏变为了竖屏，一般情况下当屏幕转换时会重新创建Activity，按照我们的想法，老的Activity应该会 被销毁才对，然而事实上并非如此。
由于我们的线程是Activity的内部类，所以MyThread中保存了Activity的一个引用，当MyThread的run函数没有结束时，MyThread是不会被销毁的，因此它所引用的老的Activity也不会被销毁，因此就出现了内存泄露的问题。
有些人喜欢用Android提供的AsyncTask，但事实上AsyncTask的问题更加严重，Thread只有在run函数不结束时才出现这种内 存泄露问题，然而AsyncTask内部的实现机制是运用了ThreadPoolExcutor,该类产生的Thread对象的生命周期是不确定的，是应 用程序无法控制的，因此如果AsyncTask作为Activity的内部类，就更容易出现内存泄露的问题。
这种线程导致的内存泄露问题应该如何解决呢？
第一、将线程的内部类，改为静态内部类。
第二、在线程内部采用弱引用保存Context引用。
五、超级大胖子Bitmap
可以说出现OutOfMemory问题的绝大多数人，都是因为Bitmap的问题。因为Bitmap占用的内存实在是太多了，它是一个“超级大胖子”，特别是分辨率大的图片，如果要显示多张那问题就更显著了。
如何解决Bitmap带给我们的内存问题？
第一、及时的销毁。
虽然，系统能够确认Bitmap分配的内存最终会被销毁，但是由于它占用的内存过多，所以很可能会超过java堆的限制。因此，在用完 Bitmap时，要及时的recycle掉。recycle并不能确定立即就会将Bitmap释放掉，但是会给虚拟机一个暗示：“该图片可以释放了”。
第二、设置一定的采样率。
有时候，我们要显示的区域很小，没有必要将整个图片都加载出来，而只需要记载一个缩小过的图片，这时候可以设置一定的采样率，那么就可以大大减小占用的内存。如下面的代码：
private ImageView preview; BitmapFactory.Options options = new BitmapFactory.Options(); options.inSampleSize = 2;//图片宽高都为原来的二分之一，即图片为原来的四分之一 Bitmap bitmap = BitmapFactory.decodeStream(cr.openInputStream(uri), null, options); preview.setImageBitmap(bitmap);
第三、巧妙的运用软引用（SoftRefrence）
六、其它要说的：
其实，要减小内存的使用，其实还有很多方法和要求。比如不要使用整张整张的图，尽量使用9path图片。Adapter要使用convertView等等，好多细节都可以节省内存。这些都需要我们去挖掘。
[Android] 内存泄漏调试经验分享 (一)http://rayleeya.iteye.com/blog/727074
Android 内存泄漏调试
Made by 李文栋
liwd@thunderst.com | rayleeya@gmail.com
2010-07-25 Friday
二、Android(Java)中常见的容易引起内存泄漏的不良代码 1
(二) 构造Adapter时，没有使用缓存的 convertView 3
(三) Bitmap对象不在使用时调用recycle()释放内存 4
四、内存分析工具 MAT(Memory Analyzer Tool) 7
一、概述
Java编程中经常容易被忽视，但本身又十分重要的一个问题就是内存使用的问题。Android应用主要使用Java语言编写，因此这个问题也同样会在Android开发中出现。本文不对Java编程问题做探讨，而是对于在Android中，特别是应用开发中的此类问题进行整理。
由于作者接触Android时间并不是很长，因此如有叙述不当之处，欢迎指正。
二、Android(Java)中常见的容易引起内存泄漏的不良代码
Android主要应用在嵌入式设备当中，而嵌入式设备由于一些众所周知的条件限制，通常都不会有很高的配置，特别是内存是比较有限的。如果我们编写的代码当中有太多的对内存使用不当的地方，难免会使得我们的设备运行缓慢，甚至是死机。为了能够使得Android应用程序安全且快速的运行，Android的每个应用程序都会使用一个专有的Dalvik虚拟机实例来运行，它是由Zygote服务进程孵化出来的，也就是说每个应用程序都是在属于自己的进程中运行的。一方面，如果程序在运行过程中出现了内存泄漏的问题，仅仅会使得自己的进程被kill掉，而不会影响其他进程（如果是system_process等系统进程出问题的话，则会引起系统重启）。另一方面Android为不同类型的进程分配了不同的内存使用上限，如果应用进程使用的内存超过了这个上限，则会被系统视为内存泄漏，从而被kill掉。Android为应用进程分配的内存上限如下所示：
位置： /ANDROID_SOURCE/system/core/rootdir/init.rc 部分脚本
# Define the oom_adj values for the classes of processes that can be
# killed by the kernel. These are used in ActivityManagerService.
setprop ro.FOREGROUND_APP_ADJ 0
setprop ro.VISIBLE_APP_ADJ 1
setprop ro.SECONDARY_SERVER_ADJ 2
setprop ro.BACKUP_APP_ADJ 2
setprop ro.HOME_APP_ADJ 4
setprop ro.HIDDEN_APP_MIN_ADJ 7
setprop ro.CONTENT_PROVIDER_ADJ 14
setprop ro.EMPTY_APP_ADJ 15
# Define the memory thresholds at which the above process classes will
# be killed. These numbers are in pages (4k).
setprop ro.FOREGROUND_APP_MEM 1536
setprop ro.VISIBLE_APP_MEM 2048
setprop ro.SECONDARY_SERVER_MEM 4096
setprop ro.BACKUP_APP_MEM 4096
setprop ro.HOME_APP_MEM 4096
setprop ro.HIDDEN_APP_MEM 5120
setprop ro.CONTENT_PROVIDER_MEM 5632
setprop ro.EMPTY_APP_MEM 6144
# Write value must be consistent with the above properties.
# Note that the driver only supports 6 slots, so we have HOME_APP at the
# same memory level as services.
write /sys/module/lowmemorykiller/parameters/adj 0,1,2,7,14,15
write /proc/sys/vm/overcommit_memory 1
write /proc/sys/vm/min_free_order_shift 4
write /sys/module/lowmemorykiller/parameters/minfree 1536,2048,4096,5120,5632,6144
# Set init its forked children's oom_adj.
write /proc/1/oom_adj -16
正因为我们的应用程序能够使用的内存有限，所以在编写代码的时候需要特别注意内存使用问题。如下是一些常见的内存使用不当的情况。
(一) 查询数据库没有关闭游标
描述：
程序中经常会进行查询数据库的操作，但是经常会有使用完毕Cursor后没有关闭的情况。如果我们的查询结果集比较小，对内存的消耗不容易被发现，只有在常时间大量操作的情况下才会复现内存问题，这样就会给以后的测试和问题排查带来困难和风险。
示例代码：
Cursor cursor = getContentResolver().query(uri ...);
if (cursor.moveToNext()) {
... ...
}
修正示例代码：
Cursor cursor = null;
try {
cursor = getContentResolver().query(uri ...);
if (cursor != null && cursor.moveToNext()) {
... ...
}
} finally {
if (cursor != null) {
try {
cursor.close();
} catch (Exception e) {
//ignore this
}
}
}
(二) 构造Adapter时，没有使用缓存的 convertView
描述：
以构造ListView的BaseAdapter为例，在BaseAdapter中提高了方法：
public View getView(int position, View convertView, ViewGroup parent)
来向ListView提供每一个item所需要的view对象。初始时ListView会从BaseAdapter中根据当前的屏幕布局实例化一定数量的view对象，同时ListView会将这些view对象缓存起来。当向上滚动ListView时，原先位于最上面的list item的view对象会被回收，然后被用来构造新出现的最下面的list item。这个构造过程就是由getView()方法完成的，getView()的第二个形参 View convertView就是被缓存起来的list item的view对象(初始化时缓存中没有view对象则convertView是null)。
由此可以看出，如果我们不去使用convertView，而是每次都在getView()中重新实例化一个View对象的话，即浪费资源也浪费时间，也会使得内存占用越来越大。ListView回收list item的view对象的过程可以查看:
android.widget.AbsListView.java --> void addScrapView(View scrap) 方法。
示例代码：
public View getView(int position, View convertView, ViewGroup parent) {
View view = new Xxx(...);
... ...
return view;
}
修正示例代码：
public View getView(int position, View convertView, ViewGroup parent) {
View view = null;
if (convertView != null) {
view = convertView;
populate(view, getItem(position));
...
} else {
view = new Xxx(...);
...
}
return view;
}
(三) Bitmap对象不在使用时调用recycle()释放内存
描述：
有时我们会手工的操作Bitmap对象，如果一个Bitmap对象比较占内存，当它不在被使用的时候，可以调用Bitmap.recycle()方法回收此对象的像素所占用的内存，但这不是必须的，视情况而定。可以看一下代码中的注释：
/**
* Free up the memory associated with this bitmap's pixels, and mark the
* bitmap as "dead", meaning it will throw an exception if getPixels() or
* setPixels() is called, and will draw nothing. This operation cannot be
* reversed, so it should only be called if you are sure there are no
* further uses for the bitmap. This is an advanced call, and normally need
* not be called, since the normal GC process will free up this memory when
* there are no more references to this bitmap.
*/
(四) 释放对象的引用
描述：
这种情况描述起来比较麻烦，举两个例子进行说明。
示例A：
假设有如下操作
public class DemoActivity extends Activity {
... ...
private Handler mHandler = ...
private Object obj;
public void operation() {
obj = initObj();
...
[Mark]
mHandler.post(new Runnable() {
public void run() {
useObj(obj);
}
});
}
}
我们有一个成员变量 obj，在operation()中我们希望能够将处理obj实例的操作post到某个线程的MessageQueue中。在以上的代码中，即便是mHandler所在的线程使用完了obj所引用的对象，但这个对象仍然不会被垃圾回收掉，因为DemoActivity.obj还保有这个对象的引用。所以如果在DemoActivity中不再使用这个对象了，可以在[Mark]的位置释放对象的引用，而代码可以修改为：
... ...
public void operation() {
obj = initObj();
...
final Object o = obj;
obj = null;
mHandler.post(new Runnable() {
public void run() {
useObj(o);
}
}
}
... ...
示例B:
假设我们希望在锁屏界面(LockScreen)中，监听系统中的电话服务以获取一些信息(如信号强度等)，则可以在LockScreen中定义一个PhoneStateListener的对象，同时将它注册到TelephonyManager服务中。对于LockScreen对象，当需要显示锁屏界面的时候就会创建一个LockScreen对象，而当锁屏界面消失的时候LockScreen对象就会被释放掉。
但是如果在释放LockScreen对象的时候忘记取消我们之前注册的PhoneStateListener对象，则会导致LockScreen无法被垃圾回收。如果不断的使锁屏界面显示和消失，则最终会由于大量的LockScreen对象没有办法被回收而引起OutOfMemory,使得system_process进程挂掉。
总之当一个生命周期较短的对象A，被一个生命周期较长的对象B保有其引用的情况下，在A的生命周期结束时，要在B中清除掉对A的引用。
(五) 其他
Android应用程序中最典型的需要注意释放资源的情况是在Activity的生命周期中，在onPause()、onStop()、onDestroy()方法中需要适当的释放资源的情况。由于此情况很基础，在此不详细说明，具体可以查看官方文档对Activity生命周期的介绍，以明确何时应该释放哪些资源。
本文为Android性能优化的第三篇——Java(Android)代码优化。主要介绍Java代码中性能优化方式及网络优化，包括缓存、异步、延迟、数据存储、算法、JNI、逻辑等优化方式。(时间仓促，后面还会继续完善^_*)
性能优化专题已完成五部分：
性能优化总纲——性能问题及性能调优方式
性能优化第三篇——Java(Android)代码优化
性能优化第二篇——布局优化
性能优化第一篇——数据库性能优化
性能优化实例
1、降低执行时间
这部分包括：缓存、数据存储优化、算法优化、JNI、逻辑优化、需求优化几种优化方式。
(1). 缓存
缓存主要包括对象缓存、IO缓存、网络缓存、DB缓存，对象缓存能减少内存的分配，IO缓存减少磁盘的读写次数，网络缓存减少网络传输，DB缓存较少Database的访问次数。
在内存、文件、数据库、网络的读写速度中，内存都是最优的，且速度数量级差别，所以尽量将需要频繁访问或访问一次消耗较大的数据存储在缓存中。
Android中常使用缓存:
a. 线程池
b. Android图片缓存，Android图片Sdcard缓存，数据预取缓存
c. 消息缓存
通过handler.obtainMessage复用之前的message，如下：
d. ListView缓存
e. 网络缓存
数据库缓存http response，根据http头信息中的Cache-Control域确定缓存过期时间。
f. 文件IO缓存
使用具有缓存策略的输入流，BufferedInputStream替代InputStream，BufferedReader替代Reader，BufferedReader替代BufferedInputStream.对文件、网络IO皆适用。
g. layout缓存
h. 其他需要频繁访问或访问一次消耗较大的数据缓存
(2). 数据存储优化
包括数据类型、数据结构的选择。
a. 数据类型选择
字符串拼接用StringBuilder代替String，在非并发情况下用StringBuilder代替StringBuffer。如果你对字符串的长度有大致了解，如100字符左右，可以直接new StringBuilder(128)指定初始大小，减少空间不够时的再次分配。
64位类型如long double的处理比32位如int慢
使用SoftReference、WeakReference相对正常的强应用来说更有利于系统垃圾回收
final类型存储在常量区中读取效率更高
LocalBroadcastManager代替普通BroadcastReceiver，效率和安全性都更高
b. 数据结构选择
常见的数据结构选择如：
ArrayList和LinkedList的选择，ArrayList根据index取值更快，LinkedList更占内存、随机插入删除更快速、扩容效率更高。一般推荐ArrayList。
ArrayList、HashMap、LinkedHashMap、HashSet的选择，hash系列数据结构查询速度更优，ArrayList存储有序元素，HashMap为键值对数据结构，LinkedHashMap可以记住加入次序的hashMap，HashSet不允许重复元素。
HashMap、WeakHashMap选择，WeakHashMap中元素可在适当时候被系统垃圾回收器自动回收，所以适合在内存紧张型中使用。
Collections.synchronizedMap和ConcurrentHashMap的选择，ConcurrentHashMap为细分锁，锁粒度更小，并发性能更优。Collections.synchronizedMap为对象锁，自己添加函数进行锁控制更方便。
Android也提供了一些性能更优的数据类型，如SparseArray、SparseBooleanArray、SparseIntArray、Pair。
Sparse系列的数据结构是为key为int情况的特殊处理，采用二分查找及简单的数组存储，加上不需要泛型转换的开销，相对Map来说性能更优。不过我不太明白为啥默认的容量大小是10，是做过数据统计吗，还是说现在的内存优化不需要考虑这些东西，写16会死吗，还是建议大家根据自己可能的容量设置初始值。
(3). 算法优化
这个主题比较大，需要具体问题具体分析，尽量不用O(n*n)时间复杂度以上的算法，必要时候可用空间换时间。
查询考虑hash和二分，尽量不用递归。可以从结构之法 算法之道或微软、Google等面试题学习。
(4). JNI
Android应用程序大都通过Java开发，需要Dalvik的JIT编译器将Java字节码转换成本地代码运行，而本地代码可以直接由设备管理器直接执行，节省了中间步骤，所以执行速度更快。不过需要注意从Java空间切换到本地空间需要开销，同时JIT编译器也能生成优化的本地代码，所以糟糕的本地代码不一定性能更优。
这个优化点会在后面单独用一片博客介绍。
(5). 逻辑优化
这个不同于算法，主要是理清程序逻辑，减少不必要的操作。
(6). 需求优化
这个就不说了，对于sb的需求可能带来的性能问题，只能说做为一个合格的程序员不能只是执行者，要学会说NO。不过不能拿这种接口敷衍产品经理哦。
2、异步，利用多线程提高TPS
充分利用多核Cpu优势，利用线程解决密集型计算、IO、网络等操作。
关于多线程可参考：
在Android应用程序中由于系统ANR的限制，将可能造成主线程超时操作放入另外的工作线程中。在工作线程中可以通过handler和主线程交互。
3、提前或延迟操作，错开时间段提高TPS
(1) 延迟操作
不在Activity、Service、BroadcastReceiver的生命周期等对响应时间敏感函数中执行耗时操作，可适当delay。
Java中延迟操作可使用ScheduledExecutorService，不推荐使用Timer.schedule;
Android中除了支持ScheduledExecutorService之外，还有一些delay操作，如
handler.postDelayed，handler.postAtTime，handler.sendMessageDelayed，View.postDelayed，AlarmManager定时等。
(2) 提前操作
对于第一次调用较耗时操作，可统一放到初始化中，将耗时提前。如得到壁纸wallpaperManager.getDrawable();
4、网络优化
以下是网络优化中一些客户端和服务器端需要尽量遵守的准则：
a. 图片必须缓存，最好根据机型做图片做图片适配
b. 所有http请求必须添加httptimeout
c. api接口数据以json格式返回，而不是xml或html
d. 根据http头信息中的Cache-Control域确定是否缓存请求结果。
e. 减少网络请求次数，服务器端适当做请求合并。
f. 减少重定向次数
g. api接口服务器端响应时间不超过100ms
google正在做将移动端网页速度降至1秒的项目，关注中https://developers.google.com/speed/docs/insights/mobile
对于一些Android项目，影响性能瓶颈的主要是Android自己内存管理机制问题，目前手机厂商对RAM都比较吝啬，对于软件的流畅性来说RAM对性能的影响十分敏感，除了 优化Dalvik虚拟机的堆内存分配外，我们还可以强制定义自己软件的对内存大小，我们使用Dalvik提供的 dalvik.system.VMRuntime类来设置最小堆内存为例:
- private final static int CWJ_HEAP_SIZE = 6* 1024* 1024 ;
- VMRuntime.getRuntime().setMinimumHeapSize(CWJ_HEAP_SIZE);
//设置最小heap内存为6MB大小。当然对于内存吃紧来说还可以通过手动干涉GC去处理
bitmap 设置图片尺寸，避免 内存溢出 OutOfMemoryError的优化方法
★android 中用bitmap 时很容易内存溢出，报如下错误：Java.lang.OutOfMemoryError : bitmap size exceeds VM budget
● 主要是加上这段：
- BitmapFactory.Options options = new BitmapFactory.Options();
- options.inSampleSize = 2;
● eg1：(通过Uri取图片)
- private ImageView preview;
- BitmapFactory.Options options = new BitmapFactory.Options();
- options.inSampleSize = 2;//图片宽高都为原来的二分之一，即图片为原来的四分之一
- Bitmap bitmap = BitmapFactory.decodeStream(cr
- .openInputStream(uri), null, options);
- preview.setImageBitmap(bitmap);
以上代码可以优化内存溢出，但它只是改变图片大小，并不能彻底解决内存溢出。
● eg2:（通过路径去图片）
- private ImageView preview;
- private String fileName= "/sdcard/DCIM/Camera/2010-05-14 16.01.44.jpg";
- BitmapFactory.Options options = new BitmapFactory.Options();
- options.inSampleSize = 2;//图片宽高都为原来的二分之一，即图片为原来的四分之一
- Bitmap b = BitmapFactory.decodeFile(fileName, options);
- preview.setImageBitmap(b);
- filePath.setText(fileName);
★Android 还有一些性能优化的方法：
● 首先内存方面，可以参考 Android堆内存也可自己定义大小 和 优化Dalvik虚拟机的堆内存分配
● 基础类型上，因为Java没有实际的指针，在敏感运算方面还是要借助NDK来完成。这点比较有意思的是Google 推出NDK可能是帮助游戏开发人员，比如OpenGL ES的支持有明显的改观，本地代码操作图形界面是很必要的。
● 图形对象优化，这里要说的是Android上的Bitmap对象销毁，可以借助recycle()方法显示让GC回收一个Bitmap对象，通常对一个不用的Bitmap可以使用下面的方式，如
- if(bitmapObject.isRecycled()==false) //如果没有回收
- bitmapObject.recycle();
● 目前系统对动画支持比较弱智对于常规应用的补间过渡效果可以，但是对于游戏而言一般的美工可能习惯了GIF方式的统一处理，目前Android系统仅能预览GIF的第一帧，可以借助J2ME中通过线程和自己写解析器的方式来读取GIF89格式的资源。
● 对于大多数Android手机没有过多的物理按键可能我们需要想象下了做好手势识别 GestureDetector 和重力感应来实现操控。通常我们还要考虑误操作问题的降噪处理。
Android堆内存也可自己定义大小
对于一些大型Android项目或游戏来说在算法处理上没有问题外，影响性能瓶颈的主要是Android自己内存管理机制问题，目前手机厂商对RAM都比较吝啬，对于软件的流畅性来说RAM对性能的影响十分敏感，除了上次Android开发网提到的优化Dalvik虚拟机的堆内存分配外，我们还可以强制定义自己软件的对内存大小，我们使用Dalvik提供的 dalvik.system.VMRuntime类来设置最小堆内存为例:
- private final static int CWJ_HEAP_SIZE = 6* 1024* 1024 ;
- VMRuntime.getRuntime().setMinimumHeapSize(CWJ_HEAP_SIZE);
//设置最小heap内存为6MB大小。当然对于内存吃紧来说还可以通过手动干涉GC去处理，我们将在下次提到具体应用。
优化Dalvik虚拟机的堆内存分配
对于Android平台来说，其托管层使用的Dalvik JavaVM从目前的表现来看还有很多地方可以优化处理，比如我们在开发一些大型游戏或耗资源的应用中可能考虑手动干涉GC处理，使用 dalvik.system.VMRuntime类提供的setTargetHeapUtilization方法可以增强程序堆内存的处理效率。当然具体原理我们可以参考开源工程，这里我们仅说下使用方法: private final static floatTARGET_HEAP_UTILIZATION = 0.75f; 在程序onCreate时就可以调用 VMRuntime.getRuntime().setTargetHeapUtilization(TARGET_HEAP_UTILIZATION); 即可。
【编辑推荐】
1.采用硬件加速，在androidmanifest.xml中application添加 android:hardwareAccelerated="true"。不过这个需要在android 3.0才可以使用。
2. View 中设置缓存属性. setDrawingCache为true.
3. 优化你的布局。通过Android sdk中tools目录下的layoutopt 命令查看你的布局是否需要优化。
4. 动态加载View. 采用ViewStub 避免一些不经常的视图长期握住引用.
5.将Acitivity 中的Window 的背景图设置为空。getWindow().setBackgroundDrawable(null); android的默认背景是不是为空。
6. 采用<merge> 优化布局层数。 采用<include >来共享布局。
7. 查看Heap 的大小
8. 利用TraceView查看跟踪函数调用。有的放矢的优化。
9. cursor 的使用。不过要注意管理好cursor,不要每次打开关闭cursor.因为打开关闭Cursor非常耗时。Cursor.require用于刷新cursor.
10.采用环形Buffer(可以采用链表数据结构实现)。可以设置一个链表长度的上限，根据手势的变化来不断地更新环形Buffer的内容。
11.采用SurfaceView在子线程刷新UI, 避免手势的处理和绘制在同一UI线程（普通View都这样做）。
12.采用JNI，将耗时间的处理放到c/c++层来处理。
13.有些能用文件操作的，尽量采用文件操作，文件操作的速度比数据库的操作要快10倍左右。
14. 懒加载和缓存机制。访问网络的耗时操作启动一个新线程来做，而不要再UI线程来做。
扫一扫
1109
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
