博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
80.Android之内存管理
阅读量:4604 次
发布时间:2019-06-09

本文共 4972 字,大约阅读时间需要 16 分钟。

转载:

1. Android中的内存

1.1 Android中的垃圾回收机制

Android 平台最吸引开发者的一个特性:有垃圾回收机制,无需手动管理内存,Android 系统会自动跟踪所有的对象,并释放那些不再被使用的对象

  • Young Generation 新生代

    1. 大多数新建对象都位于Eden(伊甸园)区
    2. 当Eden区被对象填满时,就会执行Minor GC(轻量GC)。并把所有存活下来的对象转移到其中一个survivor区
    3. Survivor Space:S0、S1有两个,存放每次垃圾回收后存活的对象
    4. Minor GC 同样会检查survivor区中存活下来的对象,并把他们转移到另一个survivor区,这样在一段时间内,总会有一个空的survivor区

  • Old Generation 老生代

    1. 存放长期存活的对象和经过多次Minor GC后依然存活下来的对象
    2. 满了进行Major GC(较重GC)

  • Permanent Generation 永久代

  • 存放方法区,方法区中有,要加载的类信息、静态变量、final类型的常量、属性和方法信息

1.2 垃圾回收

  • 内存占用过多,需要为新对象分配空间
  • 不同的虚拟机发生GC时采用的策略不同,可能会暂停当前程序的执行

1.3 垃圾回收机制&FPS

  • Android系统每隔16ms发出VSYNC信号,触发对UI进行渲染,那么整个过程如果保证在16ms以内就能达到一个流畅的画面。60FPS
  • 如果某一帧的操作超过了16ms就会让用户感觉到卡顿
  • UI渲染过程发生GC,导致某一帧绘制时间超过16ms

1.4 内存泄漏

在整个Android开发过程中,内存泄漏是导致OOM(Out Of Memory内存溢出)的一个重要因素

  1. 应用程序分配了大量不能回收的对象
  2. 这导致可分配的内存越来越少
  3. 当新对象的创建需要的内存不够
  4. 当发现内存不够就会调用一次GC进行垃圾回收
  5. 结果:就会发生卡顿

1.5 内存抖动

原因:内存抖动是因为应用程序在短时间内创建大量的对象,又被马上释放。

  1. 瞬间产生大量的对象会严重占用Young Generation的内存区域
  2. 当达到阈值,剩余空间不够,就会触发GC从而导致刚产生的对象又很快被回收。
  3. 即时每次分配的对象占用了很少的内存,频分GC叠加在一起会增加Heap的压力
  4. 从而触发更多其他类型的GC。
  5. 结果:这个操作有可能会影响到帧率,并使用户感知到性能问题

2. 内存检测工具

2.1 Memory Monitor 内存监视器

  • 优点
    • 方便显示内存使用和GC情况
    • 快速定位卡顿是否和GC有关
    • 快速定位Crash崩溃是否和内存占用过高有关
    • 快速定位潜在的内存泄漏问题
    • 简单易用
  • 缺点
    • 不能准确定位问题

2.2 Allocation Tracker 分配跟踪器

  • 优点
    • 定位代码中分配对象的类型,大小,时间,线程,堆栈等信息
    • 定位内存抖动问题
    • 配合HeapViewer一起定位内存泄漏问题
  • 缺点
    • 使用复杂
  • 显示所有对象的信息(环形图)

2.3 Heap Viewer 堆视图

  • 优点
    • 内存快照信息
    • 每次GC之后收集一次信息
    • 查找内存泄漏利器
  • 缺点
    • 使用复杂
  • 显示已分配的对象大小信息(包视图)

2.4 Leak Canary

  • 引用

    dependencies {      debugCompile 'com.squareup.leakcanary:leakcanary-android:1.3'      releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.3'  }
  • 使用

    // 内存泄漏检测  private RefWatcher refWatcher;  public static RefWatcher getRefWatcher(Context context) { TTApplication application = (TTApplication) context.getApplicationContext(); return application.refWatcher; } @Override public void onCreate() { super.onCreate(); refWatcher = LeakCanary.install(this); // 检测 } public void onDestroy() { RefWatcher refWatcher = TTApplication.getRefWatcher(getActivity()); refWatcher.watch(this); //内存泄露检测 }

3. 常见的内存泄漏问题

3.1 单例造成的泄漏

将Context对象保存在单例模式中,instance对象本身持有一个Context对象的引用,活动即时被销毁也不能被回收,因为静态变量一直持有它的引用

public class AppManager {    private static AppManager instance; private Context context; private AppManager(Context context) { this.context = context; } public static AppManager getInstance(Context context) { if (instance != null) { instance = new AppManager(context); } return instance; } }

可以改为

public class AppManager {    private static AppManager instance; private Context context; private AppManager(Context context) { // 使用Application的Context(也可以用自定义的Application) this.context = context.getApplicationContext(); } public static AppManager getInstance(Context context) { if (instance != null) { instance = new AppManager(context); } return instance; } }

3.2 非静态内部类的静态实例造成的泄漏

静态的sResource在创建时会间接持有一个MainActivity实例的引用,导致MainActivity无法被回收

public class MainActivity extends Activity { private static TestResource sResource = null; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); if (sResource == null) { sResource = new TestResource(); } // ... } // 非静态内部类 class TestResource { // ... } }

将该内部类设为静态内部类或将该内部类抽取出来封装成一个单例

如果用到Context就使用Application的Context

但是Dialog不能使用Application和Service的Context

3.3 Handler 造成的内存泄漏问题

当创建匿名对象时,该对象会间接持有外部类实例的一个引用,mHandler对象本身会持有MainActivity的引用,导致MainActivity销毁后无法即时被回收

public class MainActivity extends Activity { private Handler mHandler = new Handler() { @Override public void handleMessage(Message msg) { } }; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); loadData(); } private void loadData() { // ...request Message message = Message.obtain(); mHandler.sendMessage(message); } }

在Activity中避免使用非静态内部类,比如将Handler声明为静态的,这样Handler的存活时间就与Activity无关了

同时引入弱引用的方式引入Activity,避免将Activity作为Context传入

使用前判空

public class MainActivity extends Activity { private static class MyHandler extends Handler { private final WeakReference
mActivity; private MyHandler(MainActivity activity){ mActivity = new WeakReference
(activity); } @Override public void handleMessage(Message msg) { } } @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); loadData(); } private void loadData() { // ...request Message message = Message.obtain(); mHandler.sendMessage(message); } }

3.4 集合类泄漏

  • 如果集合类是全局的变量(类中的静态属性,全局性的map等既有静态引用或final一直指向它)
  • 没有相应的删除机制
  • 很可能导致集合所占用的内存只增不减

4. 避免内存泄漏的方法

  1. 尽量不要让静态变量引用Activity
  2. 使用WeakReference弱引用,会保证GC时会被回收
  3. 使用静态内部类来代替内部类,静态内部类不持有外部类的引用
  4. 静态内部类使用弱引用来引用外部类
  5. 在声明周期结束的时候释放资源

5. 减少内存使用

  1. 使用更轻量的数据结构(SpareArray代替HashMap)

    • Google自己定义的类占用内存更小
  2. 避免在onDraw方法中创建对象

    • onDraw()方法被频繁调用,在其中创建对象会导致临时对象过多,发生内存抖动
  3. 对象池(Message.obtain())

    • 当一定要在onDraw中创建对象,推荐使用对象池
    • 相当于对象缓冲,在创建时查找是否已经存在对象,没有在创建
  4. LRUCache

    • 大大减少内存使用
  5. Bitmap内存复用,压缩(inSampleSize,inBitmap)

  6. StringBuilder

    • 代替String,尤其是进行拼接操作时

转载于:https://www.cnblogs.com/benchao/p/6032222.html

你可能感兴趣的文章
js 循环读取 json的值
查看>>
c# 范型Dictionary实用例子
查看>>
C#实现动态页面静态化
查看>>
可选参数、命名参数、.NET的特殊类型、特性
查看>>
利用CGLib实现动态代理实现Spring的AOP
查看>>
面试之SQL(1)--选出选课数量>=2的学号
查看>>
IIS处理并发请求时出现的问题
查看>>
数学作业
查看>>
使用pycharm开发web——django2.1.5(二)创建一个app并做一些配置
查看>>
[ZPG TEST 105] 扑克游戏【Huffman】
查看>>
_bzoj2005 [Noi2010]能量采集
查看>>
pat 团体天梯赛 L3-010. 是否完全二叉搜索树
查看>>
烟草MES系统介绍-序
查看>>
优先队列小结
查看>>
线程安全与可重入函数之间的区别与联系
查看>>
bat批处理中如何获取前一天日期
查看>>
{Nodejs} request URL 中文乱码
查看>>
异常及日志使用与项目打包
查看>>
努力,时间,坚持,自律
查看>>
真三 bug PT的凤凰
查看>>