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()，他们都是用来检测应用中执行缓慢的代码或潜在缓慢的代码。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
|
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:查询
本文转自demoblog博客园博客，原文链接http://www.cnblogs.com/0616--ataozhijia/p/3649136.html如需转载请自行联系原作者
demoblog
