前言
本文只是为了复习handler，需要提前了解查看handler源码
记录的问题
1线程和handler有没有关系？message存在哪里？
2handler在activity中的内存泄漏怎么发生的？什么解决方案
线程和handler有没有关系？message存在哪里？
答案是有！message存在Looper的messageQueue里
那线程和handler关系是什么？
答案是Looper，首先我们看handler的几个构造函数
@Deprecated
public Handler() {
this(null, false);
}
@Deprecated
public Handler(@Nullable Callback callback) {
this(callback, false);
}
public Handler(@NonNull Looper looper) {
this(looper, null, false);
}
public Handler(@NonNull Looper looper, @Nullable Callback callback) {
this(looper, callback, false);
}
@UnsupportedAppUsage
public Handler(boolean async) {
this(null, async);
}
public Handler(@Nullable 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;
}
@UnsupportedAppUsage
public Handler(@NonNull Looper looper, @Nullable Callback callback, boolean async) {
mLooper = looper;
mQueue = looper.mQueue;
mCallback = callback;
mAsynchronous = async;
}
可以看到最终赋值的就四个变量，mLooper，mQueue，mCallback，mAsynchronous，其中mQueue是looper里的，从构造函数看出，主要创建handler的方式由两种
1传入Looper
2从Looper.myLooper();中获取
第一种稍后去研究，我们使用handler主要是通过第二种方式，所以需要查看Looper.myLooper()里干了什么
public static @Nullable Looper myLooper() {
return sThreadLocal.get();
}
发现这个Looper是在ThreadLocal中存储的，那ThreadLocal什么时候存入的Looper？AS功能很强大，搜就好了
/** Initialize the current thread as a looper.
* This gives you a chance to create handlers that then reference
* this looper, before actually starting the loop. Be sure to call
* {@link #loop()} after calling this method, and end it by calling
* {@link #quit()}.
*/
public static void prepare() {
prepare(true);
}
private static void prepare(boolean quitAllowed) {
if (sThreadLocal.get() != null) {
throw new RuntimeException("Only one Looper may be created per thread");
}
//这里设置了
sThreadLocal.set(new Looper(quitAllowed));
}
/**
* Initialize the current thread as a looper, marking it as an
* application's main looper. See also: {@link #prepare()}
*
* @deprecated The main looper for your application is created by the Android environment,
* so you should never need to call this function yourself.
*/
@Deprecated
public static void prepareMainLooper() {
prepare(false);
synchronized (Looper.class) {
if (sMainLooper != null) {
throw new IllegalStateException("The main Looper has already been prepared.");
}
sMainLooper = myLooper();
}
}
发现在prepare的时候会设置Looper，这个方法只提供给prepare()和prepareMainLooper()使用了，通过注解可以发现prepareMainLooper()已经执行了，所以主线程中我们可以默认理解已经执行过了，详细可以参考activity启动流程
quitAllowed这个参数主要是判断是否可以执行messageQueue是否可以执行quit用的，这里不展开讨论
最终我们发现，sThreadLocal里的Looper只有两种情况可以存在
ThreadLocal这个东西主要是为了保证当前线程中缓存的Looper只存在一个
那么通过以上代码我们确定了Thread
1主动调用prepare
2UI线程启动时直接通过prepareMainLooper创建
通过以上代码我们了解了创建handler时，需要观测Looper是在哪个线程创建的，创建的Looper里持有着messageQueue负责压入消息
那么我们需要反思几个问题
1如果我们自己在主线程创建的Looper是否是同一个MessageQueue？
首先这个问题本身就是不成立的，在ActivityThread创建时，当前线程的ThreadLocal已经持有了初始化时创建的Looper，所以不可能在主线程创建Looper的
2上面的问题，如果通过反射，重新设置ThreadLocal呢？
通过反射的方法是可以替换Looper的，但是我们替换的Looper必须还要通知ActivityThread，这和重启一个Activity的成本一样了
我简单做了个试验
var f = Looper::class.java.getDeclaredField("sThreadLocal")
var m = Looper::class.java.getDeclaredField("sMainLooper")
m.setAccessible(true);
f.setAccessible(true);
var t=ThreadLocal<Looper>();
f.set(Looper.myLooper(),t)
m.set(Looper.myLooper(),null)
t.set(null);
Looper.prepareMainLooper();
Handler(Looper)
h = Handler();
大体思路是把当前的Looper里的sThreadLocal和sMainLooper全部替换，通过prepareMainLooper重新创建Looper，前面几步都没什么问题，甚至创建的Handler里的MessageQueue也替换了
debug如下图
修改前创建handler的messageQueue
修改后创建handler的messageQueue
可以看到Looper和MessageQueue全部替换成功了，但是当执行UI操作的时候，会爆出类似如下的异常
为什么呢？
因为ActivityThread创建时，通过mainThread获取了一个Handler，这个Handler持有的Looper就是被我们替换掉的Looper，当UI更新的时候，发现当前的mainLooper和mainThread持有的Looper不一致，各种层层嵌套，抛出这个异常。
handler在activity中的内存泄漏怎么发生的
上面的分析我们知道handler持有的Looper是主线程里的Looper，我们创建Handler大多会通过内部类创建，内部类的实例会隐性持有当前类（Activity）的实例，这样就让Handler间接强持有了当前类的实例，而handler的生命周期是跟主线程Looper里的MessageQueue里的Message里的target保持一致的，因为处理Message时会通过Message里的target去获取handler，所以会造成handler生命周期可能会比Activity长，当Activity需要销毁时，因为Handler持有的Activity没有释放，造成内存泄露。
怎么解决呢？
1，持有的Handler在activity销毁前，将Message全部销毁，去除内部类的持有，handler销毁，让Handler的生命周期小于Activity(removeCallbacksAndMessages方法)
2，将Handler通过弱引用Activity创建（WeakReference<Activity>）
以上就是Handler的复习
