Android性能优化方案

Android性能优化有以下一个方面:

ANR,内存溢出,内存抖动,内存泄漏,UI卡顿,冷启动优化等方面来回答

1.ANR

  • 主线程被io操作阻塞(4.0后网络io不允许主线程中)。
  • 主线程做了耗时任务超过 5秒。
  • Service做了耗时操作超过20秒,这是由于service默认执行在主线程,可以使用IntentService 。
  • BroadcastReceiver的onReciver做了耗时操作超过10秒。

解决方式:

  • 开一个子线程,使用Handler来处理。
  • 使用AsyncTask来处理耗时任务。

2.内存溢出

内存溢出主要是由于加载大的图片引起的。解决方式:

  1. 及时释放bitmap,调用.recycler(Bitmap会占用java内存和c(native)内存,java内存会自动释放,c内存需要手动释放)。
  2. 使用lru 最近最少使用
    LruCache来存储对象put(key,value),,使用的使用LinkHashMap()。
  3. 计算inSampleSize
    官方提供的方法,使用BitmapFactory.Options来计算inSampleSize(图片的缩略比)
  4. 缩略图
    使用Options的inJustDecodeBounds属性来处理加载缩略图
  5. 三级缓存
    内存,本地,网络。

3.内存泄露

内存泄漏是指无用对象(不在使用的对象)持续占有内存或无用对象的内存得不到及时释放,从而造成的内存空间的浪费称为内存泄漏。

(1)单例导致内存泄漏

public class SingleInstanceTest { 
    private static SingleInstanceTest sInstance; 
    private Context mContext; 
    private SingleInstanceTest(Context context){ 
            this.mContext = context; 
    } 
    public static SingleInstanceTest newInstance(Context context){ 
            if(sInstance == null){ 
                sInstance = new SingleInstanceTest(context); 
            } return sInstance; 
    } 
}

上面是一个比较简单的单例模式用法,需要外部传入一个 Context 来获取该类的实例,如果此时传入的 Context 是 Activity 的话,此时单例就有持有该 Activity 的强引用(直到整个应用生命周期结束)。这样的话,即使该 Activity 退出,该 Activity 的内存也不会被回收,这样就造成了内存泄露,特别是一些比较大的 Activity,甚至还会导致 OOM(Out Of Memory)。

解决方式:

public class SingleInstanceTest { 
    private static SingleInstanceTest sInstance; 
    private Context mContext; 
    private SingleInstanceTest(Context context){ 
            his.mContext = context.getApplicationContext();
    } 
    public static SingleInstanceTest newInstance(Context context){ 
            if(sInstance == null){ 
                sInstance = new SingleInstanceTest(context); 
            } return sInstance; 
    } 
}

(2)内部类导致内存泄漏

非静态内部类会默认持有外部类的引用。会导致内部类的生命周期过长。
正确的做法就是修改成静态内部类。

(3)Handler
看下面的代码

 

public class HandlerActivity extends AppCompatActivity {
    private final static int MESSAGECODE = 1 ;
    private final Handler handler = new Handler(){
        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
            Log.d("mmmmmmmm" , "handler " + msg.what ) ;
        }
    };
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_handler);
        //点击结束Activity
        findViewById( R.id.finish ).setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                finish();
            }
        });
         //新建线程,内部类
        new Thread(new Runnable() {
            @Override
            public void run() {
                handler.sendEmptyMessage( MESSAGECODE ) ;
                try {
                    Thread.sleep( 8000 );
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                //持有对象的引用
                handler.sendEmptyMessage( MESSAGECODE ) ;
            }
        }).start() ;
    }
}

这段代码运行起来后,立即点击 finish 按钮,通过检测,发现 HandlerActivity 出现了内存泄漏。

当Activity finish后,延时消息会继续存在主线程消息队列中8秒钟,然后处理消息。而该消息引用了Activity的Handler对象,然后这个Handler又引用了这个Activity。这些引用对象会保持到该消息被处理完,这样就导致该Activity对象无法被回收,从而导致了上面说的 Activity泄露。

Handler 是个很常用也很有用的类,异步,线程安全等等。如果有下面这样的代码,会发生什么呢? handler.postDeslayed ,假设 delay 时间是几个小时… 这意味着什么?意味着只要 handler 的消息还没有被处理结束,它就一直存活着,包含它的 Activity 就跟着活着。

我们来想办法修复它,修复的方案是 WeakReference ,也就是所谓的弱引用。垃圾回收器在回收的时候,是会忽视掉弱引用的,所以包含它的 Activity 会被正常清理掉。

解决方式
1.静态内部类
2.弱引用
3.注意在onDestroy中移除消息

public class HandlerActivity extends AppCompatActivity {
    private final static int MESSAGECODE = 1 ;
    private static Handler handler ;
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_handler);
        findViewById( R.id.finish ).setOnClickListener(new View.OnClickListener() 
            @Override
            public void onClick(View v) {
                finish();
            }
        });
        //创建Handler
        handler = new MyHandler( this ) ;
        //创建线程并且启动线程
        new Thread( new MyRunnable() ).start();
    }
    private static class MyHandler extends Handler {
        WeakReference<HandlerActivity> weakReference ;
      public MyHandler(HandlerActivity activity ){
            weakReference  = new WeakReference<HandlerActivity>( activity) ;
        }
        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
            if ( weakReference.get() != null ){
                // update android ui
                Log.d("mmmmmmmm" , "handler " + msg.what ) ;
            }
        }
    }
    private static class MyRunnable implements Runnable {
        @Override
        public void run() {
            handler.sendEmptyMessage( MESSAGECODE ) ;
            try {
                Thread.sleep( 8000 );
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            handler.sendEmptyMessage( MESSAGECODE ) ;
        }
    }
}

 

4.UI卡顿

  1. 在UI线程中做轻微耗时操作,会导致UI线程卡顿
  2. 布局Layout过于复杂,无法再16ms内完成渲染
    60fps-->16ms
    60ms一帧 每过16ms就会更新一下ui,要达到60ms一帧,否则可能会卡顿
  3. 同一时间动画执行的次数过多,导致cpu或gpu负载过重。
  4. View过度绘制,导致某些像素在同一时间内被绘制多次,从而导致cpu,gpu负载过重。
    overdraw
    过度绘制,
  5. view频繁的触发measure。layout,导致measure。layout累计耗时过多以及整个view频繁的重新渲染
  6. 内存频繁触发Gc过多,导致展示阻塞渲染操作
  7. 屯余资源及逻辑导致加载和执行缓慢

解决ui卡顿:
1.布局优化 include,merge,viewsuble
2.背景和图片等内存分配优化

 

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值