Android常见导致内存问题的案例

时间:2021-7-21 作者:qvyue
Android常见导致内存问题的案例

常见导致内存问题的案例

1. Handler的使用

    private val handler = Handler(Looper.getMainLooper(), object : Handler.Callback {
        override fun handleMessage(msg: Message): Boolean {
            //Looper内的message -> handler -> 匿名内部类 -> activity
            Log.d(TAG, "handleMessage")
            TAG = "Callback"
            return true;
        }
    })

    private val handler1 = object:Handler(Looper.getMainLooper()){
        override fun handleMessage(msg: Message) {
            TAG = "handler1"
            super.handleMessage(msg)
        }
    }

    inner class InnerHandler(context: Context?) : Handler(Looper.getMainLooper()) {
        override fun handleMessage(msg: Message) {
            TAG = "inner class"
        }
    }

    handler.postDelayed(Runnable {
        TAG = ""
    }, 200000)

    handler.sendEmptyMessageDelayed(0, 200000)

在 Handler 代码里 android.os.Handler#enqueueMessage 很明显能看到 message 持有 Handler 的引用。因为一个线程只有一个 Looper , 但是可以有多个 Handler ,所以 message 需要持有 Handler 引用来分发到指定的 Handler 。

然而上面三种写法都有导致 Handler 持有外部 Activity 的引用。

第一种是 object 为 实现了 Handler.Callback 接口的匿名内部类

第二种是 object 为继承了 Handler 的 匿名内部类

第三种是 InnerHandler 为继承了 Handler 的内部类

所以只要消息一直存在于主线程,就会导致 Activity 不能释放,导致了内存泄漏。

解决方法:

//静态内部类 kotlin 也为了避免内部类持有导致的内存泄漏频繁发生,所以 默认一个 class 代表的是静态内部类,不持有外部引用
//inner class 才是内部类
class Handler2(context: Context?) : Handler(Looper.getMainLooper()) {
  private val weakReference: WeakReference = WeakReference(context)
    override fun handleMessage(msg: Message) {
    //TAG = "weakReference"
    weakReference.get()?.let {
      Log.e("", "")
    }
  }
}

//如果 Message 在退出界面后可以忽略不处理时,可以选择移除消息
override fun onDestroy() {
  super.onDestroy()
    handler.removeCallbacksAndMessages(null)
}

2. Static/单例模式

Singleton.getInstance(MainActivity@this)

public class Singleton {
    private static Singleton mInstance;

    private Context context;

    private Singleton(Context context) {
        this.context = context;
    }

    public static Singleton getInstance(Context context){
        if(mInstance == null){
            mInstance = new Singleton(context);
        }
        return mInstance;
    }

}

一般情况下,静态变量 和 Class 与 ClassLoader 的生命周期,进程的生命周期一致。上诉写法会导致 第一次调用 getInstance 传入的activity 不会释放,从而导致内存泄漏。所以 Static 关键字修饰的成员变量要注意引用关系。

解决方案:

  1. 尽量不在单例里构造函数使用 context , 如果一定要用的话,可以传入 ApplicationContext 因为它与进程的生命周期一致。大部分情况下不会涉及界面的修改, ApplicationContext 就足够了。
  2. 如果实在非要使用 Activity 的 context,可以使用软引用。

3. 非静态匿名内部类

val thread = Thread(mRunnable)
thread.start()

private val mRunnable = object :Runnable {
  override fun run() {
    try {
      TAG = "mRunnable"
        Thread.sleep(200000);
    }catch (e: Exception){
      e.printStackTrace()
    }
  }
}

mRunnable 为非静态匿名内部类实例,持有了外部引用,与 handler 例子类似导致了泄漏。

解决方案:

JAVA 中 设置 mRunnable 为静态 。

kotlin 编译阶段有优化,只要不掉用外部变量,则不会持有引用。

4.属性动画

anim = ValueAnimator.ofFloat(0f, 1f)
anim.duration = 30000

animator = ObjectAnimator.ofFloat(textview, "alpha", 1f, 0f, 1f)
animator.duration = 500000
animator.start()

主要原因在于 android.animation.AnimationHandler#sAnimatorHandler 是 static 的,导致了内存泄漏。

可以按如下顺序跟代码:

android.animation.ValueAnimator#cancel
android.animation.ValueAnimator#endAnimation
android.animation.ValueAnimator#removeAnimationCallback
android.animation.ValueAnimator#getAnimationHandler
android.animation.AnimationHandler#getInstance
android.animation.AnimationHandler#sAnimatorHandler

解决方案:

    override fun onDestroy() {
        super.onDestroy()
        anim.cancel()
        animator.cancel()
    }

5.资源未关闭

BraodcastReceiver,ContentObserver,File,游标 Cursor,Stream 等资源未及时解注册和释放

解决方案:

及时解注册。资源及时释放。有些语法糖比如Java 1.7 提供的try-with-resource。以及Kotlin FileReadWrite.kt 大多实现了kotlin.io.CloseableKt#use

6.自定义View onDraw 每次new对象

@Override
protected void onDraw(Canvas canvas) {
        Paint paint = new Paint();
}

onDraw执行非常频繁,如果在里面new 对象会导致频繁的申请内存和释放。另外一方面,频繁的 GC 也会导致卡顿。

解决方案:

private Paint mPaint;

public TestView(Context context) {
        super(context);
    mPaint = new Paint();
}

7. 所有图片都预先加载

 //mJustView 其实只有部分机型收到广播后才需要add到window上,然而这里直接在初始化时就已经加载到内存里了。
private void makeJustView() {
        RelativeLayout root = (RelativeLayout) View.inflate(mContext, R.layout.eye_layout, null);
        mConfrim = (Button) root.findViewById(R.id.confirm);
        mConfrim.setOnClickListener(this);
        mJustView = root;
}
private void init() {
        makeJustView();
}

解决方案:

//使用懒加载,仅有部分机型收到广播后,才会加载这张图,对于其他机型这部分内存就省下了
private BroadcastReceiver mIntentReceiver = new BroadcastReceiver() {
        @Override
        public void onReceive(Context conmTextView, Intent intent) {
                showProtectView(getJustView());
        }
    }
};

private View getJustView(){
        if(mJustView == null){
                makeJustView();
        }
        return mJustView;
}
private void init() {

}

8. 图片放错目录

假设本应该放在xhdpi的图片 放在了mdpi目录下,在xhdpi的机器上运行时,长宽会被放大两倍,相应的内存会变成两倍。

直接放错的概率不到,比较容易发生在换图,UI只提供了一张图什么的。

9. XML布局

有些view可能在布局里只显示一次的,比如引导图,其实是可以使用 ViewStub。代替VISIBLE/GONE的,需要时再加载。

imageView.setVisibility(View.VISIBLE);
imageView.setVisibility(View.GONE);

10.Bitmap使用

  • inSampleSize 采样加载bitmap
BitmapFactory.Options options = new Options();
options.inSampleSize = 2;
Bitmap bitmap = BitmapFactory.decodeResource(getResources(), resId, options);
  • Matrix 矩阵 小图放大,内存只有采样出来的大小,但是显示效果是放大的。

    Matrix matrix = new Matrix();
    matrix.postScale(2, 2, 0, 0);
    imageView.setImageMatrix(matrix);
    imageView.setScaleType(ScaleType.MATRIX);
    imageView.setImageBitmap(bitmap);
    
  • Bitmap的像素格式

    格式 描述
    ALPHA_8 只有一个alpha通道
    ARGB_4444 这个从API 13开始不建议使用,因为质量太差
    ARGB_8888 ARGB四个通道,每个通道8bit,默认。
    RGB_565 每个像素占2Byte,其中红色占5bit,绿色占6bit,蓝色占5bit。不需要 alpha 时资源为jpg时用这个比较理想
  • 帧动画 比如 loading动画 //用自定义view 代替

大家如果还想了解更多Android 相关的更多知识点,可以点进我的【GitHub项目中:https://github.com/733gh/GH-Android-Review-master】自行查看,里面记录了许多的Android 知识点。最后还请大家点点赞支持下!!!

Android常见导致内存问题的案例
声明:本文内容由互联网用户自发贡献自行上传,本网站不拥有所有权,未作人工编辑处理,也不承担相关法律责任。如果您发现有涉嫌版权的内容,欢迎发送邮件至:qvyue@qq.com 进行举报,并提供相关证据,工作人员会在5个工作日内联系你,一经查实,本站将立刻删除涉嫌侵权内容。