最近开发的时候，使用了一个单例模式，当我返回键退出App，再重新启动，发现App的确是从首页启动，但还没有执行为单例类设置数值的位置。可是！断点调试的时候发现这时候已经有了一个数据，并且是上一次运行留下的数据，当时觉得很神奇，明明根Activity已经执行了OnDestroy()，而且再启动的确是从首页过来的，讲道理应该是“everything will be new”，但是单例里面的数据仍然存在，这可是为什么呢？

Google搜了一下，噢！恍然大悟，看到这一块的知识很久没有用就忘掉了，或者说对运行机制相关还不太熟悉吧，所以在此重新整理总结一份。

返回键退出和直接杀死进程退出的区别？

直接杀死退出：所有的内存都会被回收，重新启动应用程序时，会重新调用Application的OnCreate()方法，会调用onSaveInstanceState方法。

返回键退出程序：退出程序后，一些加载过的静态变量并没有被回收，重新启动也不需要调用Application的OnCreate()方法。

于是我们就知道，静态变量并没有被回收，而我们的单例模式实例就是静态变量，没有被回收，于是我们就知道为什么单例模式数据还存在了，于是在响应的位置对其数据进行释放。可是 why？这两者的差异究竟是什么导致的？我们要知其然，也要知其所以然。

关于直接杀死进程

这里我们应该很好去理解，Android中的每一个App都是运行在自己VM实例之中(沙盒)。每一个VM实例在linux中又是一个单独的进程，通过任务管理杀掉一个进程，那么对应进程里面的数据全部被回收掉。

关于返回键退出

通过对源码的追溯，如果不对onBackPressed()做特殊的处理，无论是AppCompatActivity还是android.app.Activity，发现都会通过执行onBackPressed(),最后到Activity的finish()方法，也就是说当App退出到根的时候，最终只是执行的是当前App根Activity的finish()方法，整个App“依然在运行”，只是看不到界面了，那么也就是说，如果在App中运行的Service之类的后台任务并没结束，仍然在运行。

那为什么单例模里面的静态变量没有回收呢？如果问你的话，你怎么答？emmmmm……因为……它没有被销毁嘛，所以它还在。当然不能这么回答了，需要用理论依据来解释。

关于方法区与静态变量

我们知道静态变量存在与JVM的方法区中，静态变量在类被加载的时候分配内存，Java虚拟机规范中说过可以不要求虚拟机在方法区实现垃圾收集，如下图所示：

那么我们是不是可以理解为方法区中不会进行垃圾回收？查到来自《深入理解Java虚拟机》中的解释：

很多人以为方法区（或者HotSopt 虚拟机中的永久代）是没有垃圾收集的，Java虚拟机规范中确实说过可以不要求虚拟机在方法区实现垃圾收集，而且性价比一般较低，在对的新生代生一般能回收70%~95%的空间，而永久代远低于此。

永久代的垃圾手机主要回收两部分内容：废弃常量和无用的类。 回收废弃常量与回收Java堆中的对象非常相似。以常量池中字面量的回收为例，若字符串“abc”已经进入常量池中，但当前系统没有任何String对象引用常量池中的“abc”常量，也没有其他地方引用该字面量，若发生内存回收，且必要的话，该“abc”就会被系统清理出常量池。常量池中其他的类（接口）、方法、字段的符号引用与此类似。

无用的类需要满足3个条件：

（1）该类所有的实例都已经被回收，即Java堆中不存在该类的任何实例；
（2）加载该类的ClassLoader已经被回收；
（3）该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

那么对于我们的静态变量来说，如果不是我们手动处理的话设置实例为null的话，或其他操作的话，那么就不会满足上面的条件。那么静态变量会在什么时候被销毁呢？答案很简单了就：静态变量在类被卸载的时候销毁，类在什么时候被卸载？在进程结束的时候。那么这也自然能解释我最开始遇到的情况了，返回键返回结束App后进程并没有结束，当下一次再启动App的时候，进程并没有销毁而，因是同一个进程，所以单例中的数据依然存在。

最近做了一个需求：监听用户截屏，然后生成相关海报。
参考了Android 截屏事件监听的文章，大致思路是：a

1、利用ContentObserver用来监听指定Uri的所有资源变化,当媒体库中有相关图片新增的时候，则发送相关的通知。

2、得到回调的Uri后，借助ContentResolver在媒体数据库中查询最后一条数据

3、对数据做一些过滤。比如短时间重复截屏的情况以及其他App也插入了媒体文件等情况做处理。

不过有一些适配性的问题：

1、截屏后读取文件数据库后获取到件的绝对路径后，利用“screenshot”等关键字判断是否是截屏图片，并不能适配所有手机截屏的命名规则，以及其他应用同时间产生带有“screenshot”等关键词的文件也会有问题。

2、在某些型号手机中(现遇到Vivo)从数据库中读取的文件并不是获取到的最新的截屏文件，而且其他目录的文件，这里就有些难以理解了，所以今天取探究一下媒体数据库的读取。

其中ContentObserver如下代码所示：

` /**
 * 媒体内容观察者(观察媒体数据库的改变)
 */
private class MediaContentObserver extends ContentObserver {
    private Uri mContentUri;
    public MediaContentObserver(Uri contentUri, Handler handler) {
        super(handler);
        mContentUri = contentUri;
    }
    [@Override](https://my.oschina.net/u/1162528)
    public void onChange(boolean selfChange) {
        super.onChange(selfChange);
        handleMediaContentChange(mContentUri);
    }
}`

其中获取最后一次更新的媒体文件时的代码(为便于查看 删除了判空处理代码)：

 /**
 * 处理媒体数据库的内容改变
 */
private void handleMediaContentChange(Uri contentUri) {
    Cursor cursor = null;
    /** 读取媒体数据库时需要读取的列 */
    private static final String[] MEDIA_PROJECTIONS =  {
        MediaStore.Images.ImageColumns.DATA,
        MediaStore.Images.ImageColumns.DATE_TAKEN };
    try {
        // 数据改变时查询数据库中最后加入的一条数据
        cursor = mContext.getContentResolver().query(
                contentUri,
                 MEDIA_PROJECTIONS,
                null,
                null,
                MediaStore.Images.ImageColumns.DATE_ADDED + " desc limit 1"
        );
        // 获取各列的索引
        int dataIndex = cursor.getColumnIndex(MediaStore.Images.ImageColumns.DATA);
        int dateTakenIndex = cursor.getColumnIndex(MediaStore.Images.ImageColumns.DATE_TAKEN);

        // 获取行数据
        String data = cursor.getString(dataIndex);
        long dateTaken = cursor.getLong(dateTakenIndex);

        // 处理获取到的第一行数据
        handleMediaRowData(data, dateTaken);
}

这次的目的主要探究的是从数据库获取相关信息的过程

1、Android 的多媒体如何存储？

Android的多媒体文件主要存储在 /data/data/com.android.providers.media/databases 目录下，该目录下有连个db文件：

内部存储数据库文件：internal.db

存储卡数据库：external-XXXX.db

媒体文件的操作主要是围绕着这两个数据库来进行，这两个数据库的结构是一样的。

这两个数据库包含这些表：
album_art 、audio 、search 、album_info 、audio_genres、 searchhelpertitle、albums、 audio_genres_map、 thumbnails、
android_metadata、 audio_meta、 video、artist_info 、audio_playlists 、videothumbnails、artists 、audio_playlists_map、
artists_albums_map 、images

2、表的结构
对于Images表：主要存储images信息。表结构如下：

CREATE TABLE images (
_id INTEGER PRIMARY KEY, 
_data TEXT,
_size INTEGER,
_display_name TEXT,
mime_type TEXT,
title TEXT, 
date_added INTEGER, 
date_modified INTEGER,
description TEXT,
picasa_id TEXT,
isprivate INTEGER,
latitude DOUBLE, 
longitude DOUBLE, 
datetaken INTEGER, 
orientation INTEGER, 
mini_thumb_magic INTEGER, 
bucket_id TEXT, 
bucket_display_name TEXT );

`

各字段所表示意思，如图所示：

图片来自：Android MediaProvider数据库模式说明

所以在截屏监听数据的时候所读取的数据库返回值，分别为：

_data :图片据对路径

datetaken：取子EXIF照片拍摄事件，空的话为文件修改时间

private static final String[] MEDIA_PROJECTIONS =  {
      MediaStore.Images.ImageColumns.DATA,
      MediaStore.Images.ImageColumns.DATE_TAKEN };

在查询过程中构造的数据库代码为：

public final Cursor query (Uri uri, 
    String[] projection,
    String selection, 
    String[] selectionArgs, 
    String sortOrder)

`
其中对应的构造参数官方解释为：

uri The URI, using the content:// scheme, for the content to retrieve.

projection A list of which columns to return. Passing null will return all columns, which is inefficient.

selection A filter declaring which rows to return, formatted as an SQL WHERE clause (excluding the WHERE itself). Passing null will return all rows for the given URI.

selectionArgs You may include ?s in selection, which will be replaced by the values from selectionArgs, in the order that they appear in the selection. The values will be bound as Strings.

sortOrder How to order the rows, formatted as an SQL ORDER BY clause (excluding the ORDER BY itself). Passing null will use the default sort order, which may be unordered.

所以参数依次为：
所要查找的目标、所要的返回值、条件限制(类似sql中where)、匹配项、排序规则

所以这里的查询就显而易见了：获取最新图片数据库下data和datatoken列的数据

cursor = mContext.getContentResolver().query(
              contentUri,
              MEDIA_PROJECTIONS,
              null,
              null,
              MediaStore.Images.ImageColumns.DATE_ADDED + " desc limit 1"
      );

然而…并不能解释vivo手机为什么查找出来不是最新截图的图片的问题

复习一下消息机制，如下代码：

new Thread() {
        Handler handler = null;
        [@Override](https://my.oschina.net/u/1162528)
        public void run() {
            handler = new Handler();
        }
    }.start();

如果执行会抛出异常：

Can't create handler inside thread Thread.currentThread() that has not called Looper.prepare()

这是为什么呢？

我们进入Handler的构造方法

    public Handler(Callback callback, boolean async) {
    if (FIND_POTENTIAL_LEAKS) {
        final Class<? extends Handler> klass = getClass();
        if ((klass.isAnonymousClass() || klass.isMemberClass() || klass.isLocalClass()) &&
                (klass.getModifiers() & Modifier.STATIC) == 0) {
            Log.w(TAG, "The following Handler class should be static or leaks might occur: " +
                klass.getCanonicalName());
        }
    }

    mLooper = Looper.myLooper();
    if (mLooper == null) {
        throw new RuntimeException(
            "Can't create handler inside thread " + Thread.currentThread()
                    + " that has not called Looper.prepare()");
    }
    mQueue = mLooper.mQueue;
    mCallback = callback;
    mAsynchronous = async;
}

从上面的代码我们很清新的可以知道mLooper 为null,那么就会抛出这样的异常，那么mLooper 为什么会为空呢？这是因为在线程中的Looper还未被创建，所以在Looper.myLooper()中sThreadLocal.get()就会返回null。

我们知道 Handler的作用是处理消息，将消息传递给MessageQueue，而MessageQueue存在于Looper中，如果没有Looper那么就没有MessageQueue，所以创建Handler时，Looper不能够为空。

所以以上代码可以进行一个修改：

private void test() {
    new Thread() {
        Handler handler = null;
        [@Override](https://my.oschina.net/u/1162528)
        public void run() {
            Looper.prepare();
            handler = new Handler();
            Looper.loop();
        }
    }.start();
}

其中 Looper.prepare();为当前线程创建Looper并绑定在ThreadLocal中
Looper.loop();执行消息循环，这样子 Handler就能够正常工作了。

在平时最普通的Volley的网络请求中，我们StringRequest是这样请求网络数据的：

StringRequest stringRequest = new StringRequest("http://www.baidu.com",
        new Response.Listener<String>() {
            @Override
            public void onResponse(String response) {
                Log.d("TAG", response);
            }
        }, new Response.ErrorListener() {
    @Override
    public void onErrorResponse(VolleyError error) {
        Log.e("TAG", error.getMessage(), error);
    }

注意在onResponse的时候是拿到的string类型，拿到string后对其再进行相关的解析，我们是否是可以对其直接封装然后拿到具体想要类型的model数据结构呢？所以对其网络请求架构进行一次封装，到达如下效果：

GetGoodDetailByGidRequest getGoodDetailByGidRequest = new GetGoodDetailByGidRequest(mCouponId,
           new RequestListener<List<CouponModel>>() {
               @Override
               public void onSuccess(List<CouponModel> result) {
               }
               @Override
               public void onError(Exception e) {
                   e.printStackTrace();
                   stopLoadingDialog();
               }
           });

这里我们在构造Request的时候指定了返回数据的类型，这样的话就方便了我们在写业务的时候直接使用解析好的数据结构，具体如何做到的呢？

一、让每个Request基于一个带有范型请求类

public abstract class BaseApiRequest<T>  

这里的T就是目标请求期望的model类
在具体实现的时候继承基类，并指定返回类型，下面是一个例子：

public class GetGoodDetailByGidRequest extends BaseApiRequest<List<CouponModel>> {
    public static final String url = CURL.GoodDetailURL;
    public GetGoodDetailByGidRequest(String goodId, RequestListener<List<CouponModel>> requestListener) {
            super(requestListener);
            this.mUrlParams.put("id", goodId);
    }
    @Override
    public String getBaseUrl() {
            return url;
        }
}

二、在基类中构造网络请求

  protected StringRequest getStringRequest() {
    return new StringRequest(requestMethod, getRequestUrl(),
            response -> parseJson(response),
            error -> requestListener.onError(error)) {
        @Override
        protected Map<String, String> getParams() {
            return mEntityParams;
        }
    };
}

在此处实现可以看到Request在基类中进行，然后分别处理返回结果

三、对返回结果进行解析

    private void parseJson(String response) {
    int responseCode = 0;
    int errorCode = 400;
    try {
        JSONObject jsonObject = new JSONObject(response);

        String resultString = jsonObject.getString("data");

        if (jsonObject.has("code")) {
            responseCode = jsonObject.getInt("code");
        }
        if (jsonObject.has("error")) {
            errorCode = jsonObject.getInt("error");
        }

        if (responseCode == 200 || errorCode == 0) {
            if (!TextUtils.isEmpty(response)) {
                Type type = getTType(requestListener.getClass());
                //泛型是实体或者List等类型
                T t = JsonUtils.fromJson(resultString, type);
                requestListener.onSuccess(t);
                return;
            }
            ToastUtils.showToast("Data is empty!");
        }
        ToastUtils.showToast("Response code is error.");
        requestListener.onError(new ParseError());
    } catch (JSONException e) {
        ToastUtils.showToast(e.toString());
        e.printStackTrace();
    }
}

这里是最关键的一步，由于和后端约定好相关返回字段，那么只需要解析字段中目标model的数据，其中比较重要的是这段代码

Type type = getTType(requestListener.getClass());
//泛型是实体或者List等类型
 T t = JsonUtils.fromJson(resultString, type);
 requestListener.onSuccess(t);

通过封装好的 JsonUtils将String转化为对应的model类型，我们知道json转实体对象的时候，需要指明其类type，那这里的type是如何获取到的呢？

其中getTType ()的具体实现为：

 public static Type getTType(Class<?> clazz) {
    //以Type的形式返回本类直接实现的接口.
    Type[] types = clazz.getGenericInterfaces();
    clazz.getInterfaces();
    if (types.length > 0) {
        //返回表示此类型实际类型参数的 Type 对象的数组
        Type[] interfacesTypes = ((ParameterizedType) types[0]).getActualTypeArguments();
        return interfacesTypes[0];
    }
    return null;
}

通过次方法能够获取到请求实现中所指明的请求类型，其中getGenericInterfaces等相关原理可以阅读：https://my.oschina.net/617669559/blog/3012228

所以对于

public class GetGoodDetailByGidRequest extends BaseApiRequest<List<CouponModel>>

那么获取到的就是List类型

四、通过Listener回调相关解析结果

拿到解析好的result并回调给构造Request方法中的listener使用

T t = JsonUtils.fromJson(resultString, type);
requestListener.onSuccess(t);

这样对整个网络请求后的返回数据直接进行解析方便多了。

总结：

1、本文最主要是对基本Request类进行改造，以达到不需要每次重复写解析返回的String数据

2、在获取目标的类的类型的时候，主要是去获取基类中的“T”类型

3、设计不仅适用用Volley同样适用于其他类似的网络请求框架

小弟不才，如有问题，欢迎指出。

1.什么是内存泄漏

用动态存储分配函数动态开辟的空间，在使用完毕后未被得到释放，结果一直占据该用内存单元，直到程序结束，即所谓的内存泄漏。

2.是内存泄漏与内存溢出的区别

内存溢出 Out of Memory，是指程序在申请内存时，没有足够的内存空间供其使用，出现out of memory；比如申请了一个integer,但给它存了long才能存下的数，那就是内存溢出。

内存泄露 Memory Leak，是指程序在申请内存后，无法释放已申请的内存空间，一次内存泄露危害可以忽略，但内存泄露堆积后果很严重，无论多少内存,迟早会被占光。

用一个很形象的例子来说明：一个仓库，被无用的物资所占据，而得不到管理员的清理，这里的无用货物占用仓库空间的行为被叫做”内存泄漏“，而某一天仓库由于所存储的物品太多，而无法继续存放物资，这个时候就被叫做“内存溢出”。

3.内存泄漏导致的问题

相关内存无法被系统给回收，随着程序运行可以用的内存会越来越少，机子越来越卡，直到内存溢出。（这也是为什么手机电脑很卡之后重启一下后会好很多，主要是相关未被系统回收的内存被回收）

4、安卓中的内存泄漏

典型的可能产生内存泄漏的代码：

public class MemoryLeakActivity extends MyActivity {
//可能会导致内存泄漏的代码
private Handler handler = new Handler() {
    [@Override](https://my.oschina.net/u/1162528)
    public void handleMessage(Message msg) {
        super.handleMessage(msg);
    }
};}

产生内存泄漏可能的原因：Handler的工作机制中Handler与Looper以及MessageQueue一起工作的，App启动之后，系统会默认创建一个为主线程服务的Looper对象，负责处理主线程中所有的Message对象，它的生命周期则为整个应用的生命周期。在主线程使用Handler都会默认绑定到这个Looper上面，主线程创建Handler对象，会立即关联Looper对象的MessageQueue，这时发送MessageQueue重的Message会持有Handler的引用， 这样在Looper处理Message时候才会回调到Handler的handleMessage方法。因此，如果Message没有被处理完成，那么Handler对象就不会被垃圾回收。

上面的代码，将Handler的实例声明为MemoryLeakActivity类的内部类，在Java中：非静态内部匿名类会持有外部类的一个隐式引用，这样就可能导致外部类无法被垃圾回收。

最终由于MessageQueue中的Message 没有处理完成，就会持有Handler对象的引用，而非静态的Handler对象会持有外部类Activity的引用，这个activity无法被回收，从而导致内存泄漏。

5、解决方案

1、将Handler声明为静态内部类，这样就不会持有对外部类的引用。

2、创建一个Looper与一般Java对象一样的生命周期

private static InnerHandler extends Handler{       
      // 声明一个静态Handler类，并持有外部类引用
    private final WeakReference<MemoryLeakActivity> mActivity;
        public InnerHandler(MemoryLeakActivity activity){
                this.mActivity = new WeakReference<MemoryLeakActivity>(activity);
    }
}