Android开发响应检测及内存分析 - 【StrictMode】

StrictMode

       在运行操作应用时候，如果应用出现卡顿、不流畅、甚至出现ANR。通常，100到200毫秒是一个让用户感觉到阻滞的阈值，作为开发者首先要想到的是在代码编写过程中是否在主线程中做了耗时的操作(硬件问题暂不考虑 )。

       假设这些细微的问题很难寻找，没关系。这里有些小技巧让你用来使你的应用看起来响应更灵敏。从Android 2.3开始提供了一个新的类StrictMode，并在后续的版本陆续增加新的更能。可以帮助开发者改进他们的Android应用，StrictMode可以用于捕捉发生在应用程序主线程中耗时的磁盘、网络访问或函数调用(简单理解就是哪里堵塞主线程就会捕捉到并打印出来)，可以帮助开发者使其改进程序，避免主线程被阻塞、卡顿，甚至导致ANR的发生，使应用UI刷新显得更加平滑流畅。

StrictMode使用

兼容：

       考虑到有些App要兼容低版本，或者当前使用的SDK版本较低，没关系，StrictMode开发调试阶段改成2.3版本或更新版本，发布的时候再改回原来的SDK版本。

配置：

       在应用的Application类中配置StrictMode策略，越早越好，最早也就是OnCreate函数里了一般情况下配置detectAll()就行，省的多写代码。

public class GameCenterAppliction extends Application {
	@Override
	public void onCreate() {
		if (DXConstants.DEBUG) {
			// 调试时候，统计各个函数的调用时间，为的是优化程序，提高流畅
			StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
					.detectDiskReads()// 读磁盘
					.detectDiskWrites()// 写磁盘
					.detectNetwork()// 访问网络
					.detectCustomSlowCalls()// 自定义函数调用
					.detectAll() // 所有堵塞主线程的都会捕捉,一般配置这个就够了，上面四个就不用
					.penaltyLog()// 打印logcat
					.build());
			StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
					.detectLeakedSqlLiteObjects()
					// 探测SQLite数据库操作
					.penaltyLog()
					// 打印logcat
					.penaltyDeath().build());
		}
		super.onCreate();
	}

StrictMode使用案例

以点心定制游戏中心为例，在进入主界面时，有一段时间的卡顿(在低端机上更明显)。StrictMode捕捉到并将问题信息打印出来，在Eclipse -> LogCat 添加TAG过滤为StrictMode。(小技巧：Ctrl +C 复制Log到notepad里看，还能高亮显示，一般人我不告诉他)

原因：DService初始化时做了数据库查询的操作，耗时698毫秒，调用时间过长，被StrictMode标记为缓慢调用，就会出现如上的日志。不科学啊，通常类初始化都是在主线程中，如果查询数据库，这样不就堵塞的主线程了么？!

解决方法：可考虑改为在子线程中完成。