内存优化

造成内存使用不合理的原因：

内存泄露：

1）静态变量持有对象

2）单例模式持有Activity对象，单例模式的特点是生命周期跟Application的保持一致

3）属性动画播放没有在onDestroy函数中停止动画，造成Activity中的View被动画持有

4）Handle持有Activity即内部类持有外部类

5) 监听器没有取消

6）WebView的泄漏

7）Cursor对象是否及时关闭

优化方案（如何避免OOM总结）

1、减小对象的内存占用

2、内存对象的重复利用

3、避免对象的内存泄露

4、内存使用策略优化

举个栗子：

1、避免OOM的第一步就是要尽量减少新分配出来的对象占用内存的大小，尽量使用更加轻量的对象

1）使用更加轻量的数据结构

2）避免在Android里面使用Enum

3）减小Bitmap对象的内存占用

       Bitmap是一个极容易消耗内存的大胖子，减小创建出来的Bitmap的内存占用可谓是重中之重，通常来说有以下2个措施：

inSampleSize：缩放比例，在把图片载入内存之前，我们需要先计算出一个合适的缩放比例，避免不必要的大图载入。
decode format：解码格式，选择ARGB_8888/RBG_565/ARGB_4444/ALPHA_8，存在很大差异。

4）使用更小的图片

2、内存对象的重复利用

1）复用系统自带的资源

2）注意在ListView/GridView等出现大量重复子组件的视图里对ConvertView的复用

@Override
public View getView(int position, View convertView, ViewGroup parent) {
        final ViewHolder holder;
        if (convertView == null) {//减少加载布局次数
            holder = new ViewHolder();
            convertView = View.inflate(context, R.layout.row_invite_msg, null);
            holder.reason = (TextView) convertView.findViewById(R.id.message);
            holder.name = (TextView) convertView.findViewById(R.id.name);
            convertView.setTag(holder);//使用tag减少加载组件次数
        } else {
            holder = (ViewHolder) convertView.getTag();
        }
            holder.reason.setText(msg.getReason());
            holder.name.setText("+"+msg.getFrom());
        }
        return convertView;
    }

private static class ViewHolder {
    TextView name;
    TextView reason;
}

/*
1，复用convertView
2，使用ViewHolder
3，item中有图片时，异步加载
4，快速滑动时，不加载图片
5，item中有图片时，应对图片进行适当压缩
*/

3）避免在onDraw方法里面执行对象的创建

4）StringBuilder

5）你需要避免在for循环里面分配对象占用内存，需要尝试把对象的创建移到循环体之外

3、避免对象的内存泄露

1）注意Activity的泄漏

最典型的场景是Handler导致的Activity泄漏，如果Handler中有延迟的任务或者是等待执行的任务队列过长，都有可能因为Handler继续执行而导致Activity发生泄漏。此时的引用关系链是Looper -> MessageQueue -> Message -> Handler -> Activity。为了解决这个问题，可以在UI退出之前，执行remove Handler消息队列中的消息与runnable对象。或者是使用Static + WeakReference的方式来达到断开Handler与Activity之间存在引用关系的目的。

Handler mHandler = new Handler() {
    @Override
    public void handleMessage(Message msg) {
            // do something.
    }
}

当我们这样创建Handler的时候Android Lint会提示我们这样一个`warning： In Android, Handler classes should be static or leaks might occur.`

Android程序第一次创建的时候，默认会创建一个Looper对象，Looper去处理Message Queue中的每个Message,主线程的Looper存在整个应用程序的生命周期.

Hanlder在主线程创建时会关联到Looper的Message Queue,Message添加到消息队列中的时候Message(排队的Message)会持有当前Handler引用，当Looper处理到当前消息的时候，会调用Handler#handleMessage(Message).就是说在Looper处理这个Message之前，会有一条链MessageQueue> Message -> Handler -> Activity，由于它的引用导致你的`Activity`被持有引用而无法被回收。在java中，no-static的内部类会隐式的持有当前类的一个引用。static的内部类则没有。

##具体分析

public class SampleActivity extends Activity {

  private final Handler mHandler = new Handler() {
                @Override
                public void handleMessage(Message msg) {
                  // do something
                }
  }
  @Override
  protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
        // 发送一个10分钟后执行的一个消息
        mHandler.postDelayed(new Runnable() {
          @Override
          public void run() { }
        }, 600000);
        // 结束当前的Activity
        finish();
}

在finish()的时候，该Message还没有被处理，Message持有Handler,Handler持有Activity,这样会导致该Activity不会被回收，就发生了内存泄露.

解决方案

①通过程序逻辑来进行保护。

如果Handler中执行的是耗时的操作，在关闭Activity的时候停掉你的后台线程。线程停掉了，就相当于切断了Handler和外部连接的线，Activity自然会在合适的时候被回收。

如果Handler是被delay的Message持有了引用，那么在Activity的onDestroy()方法要调用Handler的remove*方法，把消息对象从消息队列移除就行了。

关于Handler.remove*方法

removeCallbacks(Runnable r)——清除r匹配上的Message。

removeC4allbacks(Runnable r, Object token)` ——清除r匹配且匹配token（Message.obj）的Message，token为空时，只匹配r。

removeCallbacksAndMessages(Object token)` ——清除token匹配上的Message。

removeMessages(int what)` ——按what来匹配

removeMessages(int what, Object object)` ——按what来匹配

我们更多需要的是清除以该`Handler`为`target`的所有`Message(Callback)`就调用如下方法即可`handler.removeCallbacksAndMessages(null)`;

②将Handler声明为静态类。

静态类不持有外部类的对象，所以你的`Activity`可以随意被回收。但是不持有`Activity`的引用，如何去操作`Activity`中的一些对象？这里要用到弱引用

public class MainActivity extends AppCompatActivity {

    private MyHandle myHandle;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        myHandle = new MyHandle(MainActivity.this);
    }

    @Override
    protected void onDestroy() {
        myHandle.removeCallbacksAndMessages(null);
        super.onDestroy();
    }

    static class MyHandle extends Handler{
        private WeakReference<MainActivity> mOuter;

        public MyHandle(MainActivity mainActivity) {
            this.mOuter = new WeakReference<MainActivity>(mainActivity);
        }

        @Override
        public void handleMessage(Message msg) {
            MainActivity mainActivity = mOuter.get();
            if (mainActivity != null){
                //do something with mOuter
            }
        }
    }
}

2）考虑使用Application Context而不是Activity Context

对于大部分非必须使用Activity Context的情况（Dialog的Context就必须是Activity Context），我们都可以考虑使用Application Context而不是Activity的Context，这样可以避免不经意的Activity泄露

3）注意临时Bitmap对象的及时回收

4）注意监听器的注销

在Android程序里面存在很多需要register与unregister的监听器，我们需要确保在合适的时候及时unregister那些监听器。自己手动add的listener，需要记得及时remove这个listener。

5）注意缓存容器中的对象泄漏

有时候，我们为了提高对象的复用性把某些对象放到缓存容器中，可是如果这些对象没有及时从容器中清除，也是有可能导致内存泄漏的。例如，针对2.3的系统，如果把drawable添加到缓存容器，因为drawable与View的强应用，很容易导致activity发生泄漏。而从4.0开始，就不存在这个问题。解决这个问题，需要对2.3系统上的缓存drawable做特殊封装，处理引用解绑的问题，避免泄漏的情况。

6）注意WebView的泄漏

Android中的WebView存在很大的兼容性问题，不仅仅是Android系统版本的不同对WebView产生很大的差异，另外不同的厂商出货的ROM里面WebView也存在着很大的差异。更严重的是标准的WebView存在内存泄露的问题，请看这里。所以通常根治这个问题的办法是为WebView开启另外一个进程，通过AIDL与主进程进行通信，WebView所在的进程可以根据业务的需要选择合适的时机进行销毁，从而达到内存的完整释放。

7）注意Cursor对象是否及时关闭

在程序中我们经常会进行查询数据库的操作，但时常会存在不小心使用Cursor之后没有及时关闭的情况。这些Cursor的泄露，反复多次出现的话会对内存管理产生很大的负面影响，我们需要谨记对Cursor对象的及时关闭。

4、内存使用策略优化

①资源文件需要选择合适的文件夹进行存放

我们知道hdpi/xhdpi/xxhdpi等等不同dpi的文件夹下的图片在不同的设备上会经过scale的处理。例如我们只在hdpi的目录下放置了一张100100的图片，那么根据换算关系，xxhdpi的手机去引用那张图片就会被拉伸到200200。需要注意到在这种情况下，内存占用是会显著提高的。对于不希望被拉伸的图片，需要放到assets或者nodpi的目录下。

②Try catch某些大内存分配的操作

在某些情况下，我们需要事先评估那些可能发生OOM的代码，对于这些可能发生OOM的代码，加入catch机制，可以考虑在catch里面尝试一次降级的内存分配操作。例如decode bitmap的时候，catch到OOM，可以尝试把采样比例再增加一倍之后，再次尝试decode。

③谨慎使用static对象

因为static的生命周期过长，和应用的进程保持一致，使用不当很可能导致对象泄漏，在Android中应该谨慎使用static对象

④优化布局层次，减少内存消耗

越扁平化的视图布局，占用的内存就越少，效率越高。我们需要尽量保证布局足够扁平化，当使用系统提供的View无法实现足够扁平的时候考虑使用自定义View来达到目的

⑤谨慎使用依赖注入框架

那些注入框架会通过扫描你的代码执行许多初始化的操作，这会导致你的代码需要大量的内存空间来mapping代码，而且mapped pages会长时间的被保留在内存中。除非真的很有必要，建议谨慎使用这种技术。

⑥使用ProGuard来剔除不需要的代码

ProGuard能够通过移除不需要的代码，重命名类，域与方法等等对代码进行压缩，优化与混淆。使用ProGuard可以使得你的代码更加紧凑，这样能够减少mapping代码所需要的内存空间。

优化内存工具

Memory Monitor：整个app所占用的内存，以及发生GC的时刻，短时间内发生大量的GC操作是一个危险的信号。

Heap Viewer：查看当前内存快照，便于对比分析哪些对象有可能发生了泄漏。

Allocation Tracker：追踪内存对象的来源。

LeakCanary开源控件:发现内存泄露的情况

Heap Snapshot：获取Java堆内存详细信息，可以分析出内存泄漏的问题

MAT：详细分析Java堆内存的工具

TraceView：从代码层面分析性能问题，针对每个方法来分析。

内存优化

内存优化

造成内存使用不合理的原因：

优化方案（如何避免OOM总结）

1、避免OOM的第一步就是要尽量减少新分配出来的对象占用内存的大小，尽量使用更加轻量的对象

2、内存对象的重复利用

3、避免对象的内存泄露

1）注意Activity的泄漏

2）考虑使用Application Context而不是Activity Context

3）注意临时Bitmap对象的及时回收

4）注意监听器的注销

5）注意缓存容器中的对象泄漏

6）注意WebView的泄漏

7）注意Cursor对象是否及时关闭

4、内存使用策略优化

优化内存工具

results matching ""

No results matching ""