现在的位置: 首页 > 编程语言 > 正文

Android性能优化篇:从代码角度进行优化

2017年11月14日 编程语言 ⁄ 共 7460字 ⁄ 字号 评论关闭

通常我们写程序,都是在项目计划的压力下完成的,此时完成的代码可以完成具体业务逻辑,但是性能不一定是最优化的。一般来说,优秀的程序员在写完代 码之后都会不断的对代码进行重构。重构的好处有很多,其中一点,就是对代码进行优化,提高软件的性能。下面我们就从几个方面来了解Android开发过程 中的代码优化。

基本上,优化我觉得分好几部分:一种是JAVA语法层次通用优化的,如尽量使用局部变量(栈变量),IO缓冲等。二是应用程序内部的,如内部逻辑、数据插入及查找、数据结构的安排与组织。三是通用的Android性能优化,如各种缓存机制。

一、性能调优点

主要包括同步改异步、缓存、Layout优化、数据库优化、算法优化、延迟执行。

1. 同步改异步


这个就不用多讲了,耗时操作放在线程中执行防止占用主线程,一定程度上解决anr。

但需要注意线程和service结合(防止activity被回收后线程也被回收)以及线程的数量(Java线程池)



2. 缓存


java的对象创建需要分配资源较耗费时间,加上创建的对象越多会造成越频繁的gc影响系统响应。主要使用单例模式、缓存(图片缓存、线程池、View缓存、IO缓存、消息缓存、通知栏notification缓存)及其他方式减少对象创建。

单例模式:

2). 缓存
程序中用到了图片缓存、线程池、View缓存、IO缓存、消息缓存、通知栏notification缓存等。
1. 图片缓存:

及 时的销毁(Activity的onDestroy时将bitmap回收,在被UI组件使用后马上进行回收会抛 RuntimeException:Canvas:tryingtousearecycledbitmapandroid.graphics.Bitmap) 设置一定的采样率(有开发者提供的图片无需进行采样,对于有用户上传或第三方的大小不可控图片,可进行采样减少图片所占的内存),从服务端返回图片,建议
同时反馈图片的size巧妙的运用软引用drawable对应resid的资源,bitmap对应其他资源任何类型的图片,如果获取不到(例如文件不存 在,或者读取文件时跑OutOfMemory异常),应该有对应的默认图片(默认图片放在在apk中,通过resid获取);



2. 线程池:
使用Java的Executors类,通过newCachedThreadPool、newFixedThreadPool、newSingleThreadExecutor、newScheduledThreadPool提供四种不同类型的线程池



3. View缓存:

listView的getView缓存

(1)复用convertView

通过convertView是否为null减少layout inflate次数,通过静态的ViewHolder减少findViewById的次数,这两个函数尤其是inflate是相当费时间的

(2)异步加载图片

item中如果包含有webimage,那么最好异步加载

(3
快速滑动时不显示图片

当快速滑动列表时(SCROLL_STATE_FLING),item中的图片或获取需要消耗资源的view,可以不显示出来;而处于其他两种状态(SCROLL_STATE_IDLE和SCROLL_STATE_TOUCH_SCROLL),则将那些view显示出来

(4)应用开发中自定义View的时候,交互部分,千万不要写成线程不断刷新界面显示,而是根据TouchListener事件主动触发界面的更新。

Drawable

ui组件需要用到的图片是apk包自带的,那么一律用setImageResource或者setBackgroundResource,而不要根据resourceid

注意:get(getResources(),R.drawable.btn_achievement_normal)该方法通过resid转换为drawable,需要考虑回收的问题,如果drawable是对象私有对象,在对象销毁前是肯定不会释放内存的。

4. IO缓存:

使用具有缓存策略的输入流,BufferedInputStream替代InputStream,BufferedReader替代Reader,BufferedReader替代BufferedInputStream.对文件、网络IO皆适用。



5. 消息缓存:
通过 Handler 的 obtainMessage 回收 Message 对象,减少 Message 对象的创建开销

handler.sendMessage(handler.obtainMessage(1));



6. 通知栏notification缓存:
下载中需要不断改变通知栏进度条状态,如果不断新建Notification会导致通知栏很卡。这里我们可以使用最简单的缓存

Map<String, Notification> notificationMap = new HashMap<String, Notification>();如果notificationMap中不存在,则新建notification并且put into map.



(3). 其他

能创建基类解决问题就不用具体子类:
除需要设置优先级的线程使用new Thread创建外,其余线程创建使用new Runnable。因为子类会有自己的属性创建需要更多开销。
控制最大并发数量:使用Java的Executors类,通过Executors.newFixedThreadPool(nThreads)控制线程池最大线程并发

使用线程池,分为核心线程池和普通线程池,下载图片等耗时任务放置在普通线程池,避免耗时任务阻塞线程池后,导致所有异步任务都必须等待
对于http请求增加timeout

http用gzip压缩,设置连接超时时间和响应超时时间

http请求按照业务需求,分为是否可以缓存和不可缓存,那么在无网络的环境中,仍然通过缓存的httpresponse浏览部分数据,实现离线阅读。

 

3. Layout优化

使用抽象布局标签(include, viewstub, merge)、去除不必要的嵌套和View节点、减少不必要的infalte及其他Layout方面可调优点,顺带提及布局调优相关工具(hierarchy viewer和lint)。具体

TextView属性优化:TextView的android:ellipsize=”marquee”跑马灯效果极耗性能!、

1)利用系统定义的id

比如我们有一个定义ListView的xml文件,一般的,我们会写类似下面的代码片段。

?
1
2
3
4
<ListView 
    android:id="@+id/mylist" 
    android:layout_width="fill_parent" 
    android:layout_height="fill_parent"/>

这里我们定义了一个ListView,定义它的id是"@+id/mylist"。实际上,如果没有特别的需求,就可以利用系统定义的id,类似下面的样子

?
1
2
3
4
<ListView 
    android:id="@android:id/list" 
    android:layout_width="fill_parent" 
    android:layout_height="fill_parent"/>

在xml文件中引用系统的id,只需要加上“@android:”前缀即可。如果是在Java代码中使用系统资源,和使用自己的资源基本上是一样的。不同的是,需要使用android.R类来使用系统的资源,而不是使用应用程序指定的R类。这里如果要获取ListView可以使用android.R.id.list来获取。

2)利用系统的图片资源

3)利用系统的字符串资源

4)利用系统的Style

5)利用系统的颜色定义


 

4. 数据库优化

主要包括索引和事务及针对Sqlite的优化。保证Cursor占用的内存被及时的释放掉,而不是等待GC来处理。并且Android明显是倾向于编程者手动的将Cursorclose掉

5. 算法优化

这个就是个博大精深的话题了,只介绍本应用中使用的。

使用hashMap代替arrayList,时间复杂度降低一个数量级




6. 延迟执行


对于很多耗时逻辑没必要立即执行,这时候我们可以将其延迟执行。
线程延迟执行 ScheduledExecutorService scheduledThreadPool = Executors.newScheduledThreadPool(10);
消息延迟发送 handler.sendMessageDelayed(handler.obtainMessage(0), 1000);

7、静态变量引起内存泄露

在代码优化的过程中,我们需要对代码中的静态变量特别留意。静态变量是类相关的变量,它的生命周期是从这个类被声明,到这个类彻底被垃圾回收器回收 才会被销毁。所以,一般情况下,静态变量从所在的类被使用开始就要一直占用着内存空间,直到程序退出。如果不注意,静态变量引用了占用大量内存的资源,造 成垃圾回收器无法对内存进行回收,就可能造成内存的浪费。

先来看一段代码,这段代码定义了一个Activity。

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
privatestatic

Resources mResources;  
 
@Override
 
protectedvoid

onCreate(Bundle state) {
 
super.onCreate(state);
 
if(mResources
== 
null)
{
 
    mResources
this.getResources();
 
    }
 
}

这段代码中有一个静态的Resources对象。代码片段mResources = this.getResources()对Resources对象进行了初始化。这时Resources对象拥有了当前Activity对象的引 用,Activity又引用了整个页面中所有的对象。

如果当前的Activity被重新创建(比如横竖屏切换,默认情况下整个Activity会被重新创建),由于Resources引用了第一次创建 的Activity,就会导致第一次创建的Activity不能被垃圾回收器回收,从而导致第一次创建的Activity中的所有对象都不能被回收。这个 时候,一部分内存就浪费掉了。

经验分享:

在实际项目中,我们经常会把一些对象的引用加入到集合中,如果这个集合是静态的话,就需要特别注意了。当不需要某对象时,务必及时把它的引用从集合中清理掉。或者可以为集合提供一种更新策略,及时更新整个集合,这样可以保证集合的大小不超过某值,避免内存空间的浪费。

2)使用Application的Context

在Android中,Application Context的生命周期和应用的生命周期一样长,而不是取决于某个Activity的生命周期。如果想保持一个长期生命的对象,并且这个对象需要一个 Context,就可以使用Application对象。可以通过调用Context.getApplicationContext()方法或者 Activity.getApplication()方法来获得Application对象。

依然拿上面的代码作为例子。可以将代码修改成下面的样子。

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
privatestatic

Resources mResources;  
 
@Override
 
protectedvoid

onCreate(Bundle state) {
 
super.onCreate(state);
 
if(mResources
== 
null)
{
 
    //
mResources = this.getResources();
 
    mResources
this.getApplication().getResources();
 
    }
 
}

在这里将this.getResources()修改为this.getApplication().getResources()。修改以 后,Resources对象拥有的是Application对象的引用。如果Activity被重新创建,第一次创建的Activity就可以被回收了。

3)及时关闭资源

Cursor是Android查询数据后得到的一个管理数据集合的类。正常情况下,如果我们没有关闭它,系统会在回收它时进行关闭,但是这样的效率 特别低。如果查询得到的数据量较小时还好,如果Cursor的数据量非常大,特别是如果里面有Blob信息时,就可能出现内存问题。所以一定要及时关闭 Cursor。

下面给出一个通用的使用Cursor的代码片段。

?
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
Cursor
cursor = 
null;
 
try{
 
    cursor
= mContext.getContentResolver().query(uri,
null,null,null,null);
 
    if(cursor
!= 
null)
{
 
        cursor.moveToFirst();
 
        //
处理数据
 
    }
 
catch(Exception
e){
 
    e.printStatckTrace();
 
finally{
 
    if(cursor
!= 
null){
 
        cursor.close();
 
    }
 
}

即对异常进行捕获,并且在finally中将cursor关闭。

同样的,在使用文件的时候,也要及时关闭。

4)使用Bitmap及时调用recycle()

前面的章节讲过,在不使用Bitmap对象时,需要调用recycle()释放内存,然后将它设置为null。虽然调用recycle()并不能保证立即释放占用的内存,但是可以加速Bitmap的内存的释放。

在代码优化的过程中,如果发现某个Activity用到了Bitmap对象,却没有显式的调用recycle()释放内存,则需要分析代码逻辑,增加相关代码,在不再使用Bitmap以后调用recycle()释放内存。

5)对Adapter进行优化

下面以构造ListView的BaseAdapter为例说明如何对Adapter进行优化。

在BaseAdapter类中提供了如下方法:

?
1
publicView
getView(
intposition,
View convertView, ViewGroup parent)

当ListView列表里的每一项显示时,都会调用Adapter的getView方法返回一个View,

来向ListView提供所需要的View对象。

下面是一个完整的getView()方法的代码示例。

?
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
30
31
publicView
getView(
intposition,
View convertView, ViewGroup parent) {
 
ViewHolder
holder;
 
if(convertView
== 
null)
{
 
    convertView
= mInflater.inflate(R.layout.list_item, 
null);
 
    holder
newViewHolder();
 
    holder.text
= (TextView) convertView.findViewById(R.id.text);
 
    convertView.setTag(holder);
 
else{
 
    holder
= (ViewHolder) convertView.getTag();
 
}
 
holder.text.setText("line"+
position);
 
returnconvertView;
 
}
 
privateclass

ViewHolder {
 
TextView
text;
 
}

当向上滚动ListView时,getView()方法会被反复调用。getView()的第二个参数convertView是被缓存起来的 List条目中的View对象。当ListView滑动的时候,getView可能会直接返回旧的convertView。这里使用了 convertView和ViewHolder,可以充分利用缓存,避免反复创建View对象和TextView对象。

如果ListView的条目只有几个,这种技巧并不能带来多少性能的提升。但是如果条目有几百甚至几千个,使用这种技巧只会创建几个convertView和ViewHolder(取决于当前界面能够显示的条目数),性能的差别就非常非常大了。

6)代码“微优化”

当今时代已经进入了“微时代”。这里的“微优化”指的是代码层面的细节优化,即不改动代码整体结构,不改变程序原有的逻辑。尽管Android使用的是Dalvik虚拟机,但是传统的Java方面的代码优化技巧在Android开发中也都是适用的。

下面简要列举一部分。因为一般Java开发者都能够理解,就不再做具体的代码说明。

创建新的对象都需要额外的内存空间,要尽量减少创建新的对象。

将类、变量、方法等等的可见性修改为最小。

针对字符串的拼接,使用StringBuffer替代String。

不要在循环当中声明临时变量,不要在循环中捕获异常。

如果对于线程安全没有要求,尽量使用线程不安全的集合对象。

使用集合对象,如果事先知道其大小,则可以在构造方法中设置初始大小。

文件读取操作需要使用缓存类,及时关闭文件。

慎用异常,使用异常会导致性能降低。

如果程序会频繁创建线程,则可以考虑使用线程池。

转自:http://www.open-open.com/lib/view/open1417161481252.html

经验分享:

代码的微优化有很多很多东西可以讲,小到一个变量的声明,大到一段算法。尤其在代码Review的过程中,可能会反复审查代码是否可以优化。不过我 认为,代码的微优化是非常耗费时间的,没有必要从头到尾将所有代码都优化一遍。开发者应该根据具体的业务逻辑去专门针对某部分代码做优化。比如应用中可能 有一些方法会被反复调用,那么这部分代码就值得专门做优化。其它的代码,需要开发者在写代码过程中去注意。

抱歉!评论已关闭.