Androidi性能优化之Java代码优化（摘自Android性能优化一书）

代码优化不是应用开发的首要任务，提供良好的用户体验并专注于代码的可维护性，这才是你的首要任务。事实上，代码优化应该是最后才做，甚至完全可能不去做，不过，良好的优化可以使程序性能直接达到一个可接受的水平，因而也就无需再重审查代码中的缺陷并耗费更多的精力来解决他们。

在平台Android 2.2（代号Froyo）和更高版本的情况下尤其如此，因为在Android 2.2中引入了实时（JIT）编译器，Dalvik JIT编译器把Dalvik字节码编译成本地代码，这明显加快执行速度。JIT编译器（有时简称JIT）可以显著提高性能。因为：

　　a:本地代码直接由CPU执行，而不必由虚拟机解释执行

　　b:本地代码可以为特定架构予以优化

对于无JIT的android 2.1或更早的版本而言，优化策略的选用可能会受到很大影响，如果打算针对运行android 1.5、 1.6、2.1的设备开发，你要先仔细地审查应用在这些环境下需要提供哪些功能。此外，这些运行android早起版本的旧设备是没有新设备强劲的。尽管运行android 2.1和更早版本的设备所占的市场份额在萎缩，但直到2011年12月，其数量任然占大约12%，可选策略有三条：

　　a:不予优化，因为应用在这些旧设备上运行相当缓慢

　　b:限制应用的Android API等级为最低8级，让它只能安装在android 2.2或更高版本

　　c:即使没有JIT编译器，也要针对旧设备优化，给用户以舒畅的体验，也就是说禁掉那些非常耗CPU资源的功能

在应用的manifest配置的application节点可以用：Android：vmSafeMode启用或者禁用JIT编译器，默认是启用的（如果平台有JIT）.这个属性石Android 2.2引入的。

 

从递归到迭代

　　递归算法在开发者当中名声不太好，尤其是在没有太多内存可以用的嵌入式系统开发者中，主要是因为递归算法往往要消耗大量栈空间。递归算法也有可能导致栈溢出，让应用崩溃，因此应该尽量用迭代来实现。

 

oncreate()方法中一般会包含调用setContentView或任何其他负责展开资源的方法，因为展开资源师一个开销相对较大的操作，所以你可以通过降低布局的复杂性来使资源展开加快，几个降低布局复杂性的步骤如下：

　　a:使用RelativeLayout来代替LinearLayout，尽可能保持“扁平化”的布局，此外减少创建的对象数量，也会让事件的处理速度加快

　　b:使用ViewStub推迟对象创建

 

StrictMode

写程序时，你应该始终假设下列两种情况：

　　　a:网路很慢（你正在试图连接的服务器甚至可能没有响应）

　　   b:文件系统的访问速度很慢

结论就是：不要在主线程内进行网络操作和访问文件系统，因为缓慢的操作会拖累系统的响应能力。虽然在开发中，你永远不会遇到任何网络问题或任何文件系统的性能问题，但用户可能不像你那么幸运。

注意： SD卡并不都具有相同的“速度”，如果应用在很大程度上依赖外部存储设备的性能，那么你应该确保在来自不同制造商的各种SD卡上测试过你的应用。

Android 有实用工具来帮助应用检测这种缺陷。它提供的StrictMode是检测不良行为的良好工具。通常情况下，在应用启动时，即当onCreate()被调用时，启用StrictMode

StrictMode是Android 2.3引入的，在Android 3.0中加入了更多功能，所以应该确保选择正确的Android版本，让代码抱在适当的Android平台上。

　　Android 3.0中引入的需要特别留意的方法包括detectCUstomSlowCall()和noteSlowCall()，他们都是用来检测应用中执行缓慢的代码或潜在缓慢的代码。

public class MyApplication extends Application {

	@Override
	public void onCreate() {
		super.onCreate();
		ueHandler = new UEhandler(this);
		Thread.setDefaultUncaughtExceptionHandler(ueHandler);
		StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
				.detectCustomSlowCalls()  //API等级 11， 使用StrictMode.noteSlowCode
				.detectDiskReads()
				.detectDiskWrites()
				.detectNetwork()
				.penaltyLog()
				.penaltyFlashScreen()     //API等级 11
				.build());
		
		//其实和性能无关，但如果使用StrictMode,最好也定义VM策略
		try {
			StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
					.detectLeakedSqlLiteObjects()
					.detectLeakedClosableObjects() 	//API等级 11
					.setClassInstanceLimit(Class.forName("com.apress.proandroid.SomeClass"), 100)
					.penaltyLog()
					.build());
		} catch (ClassNotFoundException e) {
			e.printStackTrace();
		}
	}
}

　　从主线程调用执行时间过长，如果StrictMode Thread策略配置为检测缓慢调用时，会在logcat日志中看到关于StrictMode的信息

Android提供了一些辅助方法，可以再主线程中进行零时磁盘读写：

 

StrictMode.ThreadPolicy oldPolicy = StrictMode.allowThreadDiskReads();
//从磁盘读取文件
StrictMode.setThreadPolicy(oldPolicy);

目前没有临时允许网络访问的方法，但实在没有理由在主线程中允许这种访问，即使是暂时的，也没有合适的方法知道访问是否很快。

注意：只是在开发阶段启用StrictMode，发布应用时，记得要禁用它，如果你使用detectAll()方法去简历策略总是可行的，那将来更可行，未来的Android版本会检测出更多的不良行为。

 

SQLite

大多数应用都不会是SQLite的重度使用者，因此，不用太担心与数据库打交道时的性能。不过在优化应用中的SQLite相关代码时，需要了解几个概念：

　　a:SQLite语句

　　b:事物

　　c:查询