Androidi性能优化之Java代码优化(摘自Android性能优化一书)

  1. 云栖社区>
  2. 博客>
  3. 正文

Androidi性能优化之Java代码优化(摘自Android性能优化一书)

最美的回忆 2017-11-15 14:12:00 浏览620
展开阅读全文

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

在平台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

网友评论

登录后评论
0/500
评论
最美的回忆
+ 关注