什么是Handler?
Handler主要用于异步消息的处理:当发出一个消息之后,首先进入一个消息队列,发送消息的函数即刻返回,而另外一个部分在消息队列中逐一将消息取出,然后对消息进行处理
相信大部分Android开发者对于Handler都有所了解,概念的知识就不做赘述,下面我们主要是带着几个问题去分析(面试中常被问到的问题~)
- ① Handler是否存在内存泄漏?
- ② 为什么不能在子线程创建Handler?
- ③ textView.setText() 只能在主线程执行??
- ④ new Handler() 两种写法有什么区别?
- ⑤ ThreadLocal 用法和原理
①首先第一个问题比较简单,我们直接测试下:
代码也比较简单,简单说下,在MainActivity
中创建了一个Handler
,并且开启了一个子线程,休眠5s后,handler发送一条消息,handler
收到消息跳转到SecondActivity
,,贴下代码
private static final String TAG="HANDLER_TEST";
private TextView mTextView;
//第一种方式创建handler
Handler handler = new Handler(){
@Override
public void handleMessage(Message msg) {
//跳转另一个Activity
startActivity(new Intent(MainActivity.this,SecondActivity.class));
super.handleMessage(msg);
}
};
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
mTextView = findViewById(R.id.tv);
leakTest();
}
//内存泄露测试,开启一个线程,休眠5s后handler发送消息
private void leakTest() {
new Thread(new Runnable(){
@Override
public void run() {
Message message = new Message();
message.what=123;//可以不设置
message.obj="并没有销毁";
//休眠五秒钟,假设是一些耗时操作
SystemClock.sleep(5000);
handler.sendMessage(message);
}
}).start();
}
@Override
protected void onDestroy() {
super.onDestroy();
Log.e(TAG,"onDestroy");
}
我们的操作是,在休眠过程中,点击返回键,销毁MainActivity
,看下效果和日志:
日志:
com.frizzle.handler E/HANDLER_TEST: onDestroy
我们可以看到,我们点击返回按钮销毁了,并且MainActivity
触发了onDestroy()
,但是休眠结束,还是跳转了SecondActivity
,所以这里是存在内存泄漏的,并且很严重,看到这里其实,很多小伙伴会说,在onDestroy()
方法中调用handler.removeCallbacksAndMessages(123)
不就可以解决内存泄露的问题了,然而这么做并没有效果,还是会造成内存泄漏,表现与上面一致,这是为什么呢?原因是上述代码的方式,handler
会在休眠五秒结束之后之后,才会sendMessage()
,也就是将消息放进队列queue
,在message
没有被放入队里中时,调用handler.removeCallbacksAndMessages()
是没有实际意义的。
正确的处理方式举例:
//内存泄露测试,开启一个线程,休眠5s后handler1发送消息
private void leakTest() {
new Thread(new Runnable(){
@Override
public void run() {
Message message = new Message();
message.what=123;//可以不设置
message.obj="并没有销毁";
//休眠五秒钟,假设是一些耗时操作
SystemClock.sleep(5000);
if (handler!=null) {
handler.sendMessage(message);
}
}
}).start();
}
@Override
protected void onDestroy() {
super.onDestroy();
Log.e(TAG,"onDestroy");
if (handler!=null) {
handler.removeCallbacksAndMessages(123);
handler=null;
}
}
需要注意的是:如果发送消息是采用的是handler.sendMessageDelayed()
的方式,在onDestroy()
中通过handler.removeCallbacksAndMessages()
是可以已解决内存泄漏的问题的,因为handler.removeCallbacksAndMessages()
会将消息放进队列queue
,但是handler.sendMessageDelayed()
在开发中并不常用,因为耗时操作耗时多久通常是不确定的,还有一点是Message
对象的创建建议使用Message.obtain()
,还有就是如果Message被定义为全局变量的话,使用时也需要注意,比如如下方式会发生异常This message is already in use.
:
//内存泄露测试,开启一个线程,休眠5s后handler1发送消息
private void leakTest() {
new Thread(new Runnable(){
@Override
public void run() {
message = new Message();
message.what=123;//可以不设置
message.obj="并没有销毁";
//休眠五秒钟,假设是一些耗时操作
SystemClock.sleep(5000);
if (handler1!=null) {
handler1.sendMessage(message);
}
}
}).start();
}
@Override
protected void onDestroy() {
super.onDestroy();
Log.e(TAG,"onDestroy");
message.recycle();
}
和上面内存泄漏的原因类似~
②为什么不能在子线程中创建Handler?
这里需要说明下,不是所有Android手机在子线程中new Handler()
都会抛异常,比如华为的部分手机改写了源码,并不会出现异常,这里我们主要关注出现异常的原因,那么出现异常的原因是什么?
- 首先我们要知道应用启动时,
ActivityThread
是创建了一个主线程的Looper
对象的,过程大致如下:
在应用启动时创建开启ActivityThread
,在ActivityThread
的main()
方法中调用了Looper.prepareMainLooper()
方法,然后创建了一个Looper
对象,这个Looper对象是存在主线程
中的,并且调用了sThreadLocal.set(new Looper(quitAllowed));
sThreadLocal
是存在在ThreadLocalMap
中的,sThreadLocal
在存和取的时候,调用的是ThreadLocalMap
的get()
和set()
方法,并且key
就是当前线程 - 然后我们在使用
new Handler()
系统做了什么呢?
api
的调用循序大概是这样的: mLooper = Looper.myLooper()
→sThreadLocal.get()
因为子线程没有创建Looper
对象,所以已子线程作为key
找到的Looper
对象为null
就会抛出异常
mLooper = Looper.myLooper();
if (mLooper == null) {
throw new RuntimeException(
"Can't create handler inside thread " + Thread.currentThread()
+ " that has not called Looper.prepare()");
}
注:
在子线程创建Looper并开启轮询,这种方式可以在子线程使用Handler,这种方式这里不做讨论~
③textView.setText() 只能在主线程执行??
首先我们先写一段测试代码:
//开启子线程
private void leakTest() {
new Thread(new Runnable(){
@Override
public void run() {
}
}).start();
}
然后我们在run()
方法中写几行代码,并记录现象和日志~
①直接改变TextView的文本内容
mTextView.setText("子线程更新文本内容");
现象:
华为手机 : 没有闪退,文本内容发生改变!
谷歌手机 : 没有闪退,文本内容发生改变!
对上述有疑问的小伙伴请自行测试~
在下面会分析原因 ↓
②休眠一秒钟,改变TextView的文本内容
SystemClock.sleep(1000);
mTextView.setText("子线程更新文本内容");
现象:
华为手机 : 闪退
谷歌手机 : 闪退
闪退的日志为:
Only the original thread that created a view hierarchy can touch its views.
③弹Toast提示
Toast.makeText(MainActivity.this,"子线程弹吐司",Toast.LENGTH_SHORT).show();
现象:
华为手机 : 部分闪退,部分没有发生闪退,但是也不显示Toast内容
谷歌手机 : 闪退
闪退的日志为:
Can't toast on a thread that has not called Looper.prepare()
根据第②点的日志,可以我们可以找到源码中抛出异常的地方,在ViewRootImpl
类的checkThread()
方法:
void checkThread() {
if (mThread != Thread.currentThread()) {
throw new CalledFromWrongThreadException(
"Only the original thread that created a view hierarchy can touch its views.");
}
}
对于子线程不能更新UI,小伙伴们应该都是比较了解的,这里不做过多赘述,简单说就是View
或ViewGroup
在更新UI时调用的invalidate()
都会在ViewRootImpl
中执行线程的检查,如上,如果不是主线程,会直接抛异常。
注:
TextView
继承自View
实现了ViewParent接口
,而ViewRootImpl
是接口实现类,在ViewRootImpl
的requestLayout
中调用checkThread()
校验线程
所以为什么第一种写法不会抛异常呢?
原因是: ViewRootImpl
是在 Activity 创建对象完毕之后再创建对象的,如果我们调用setText()
等api的速度快于 ViewRootImpl
对象的创建,就不会抛出异常!所以我们直接调用不会异常,而子线程休眠一秒钟之后就会抛出异常,对于第三种方式使用Toast
的情况,首先这种方式最终会调用,setText()
的api,与上面两种情况类似,但是在这中间还有很多代码要执行,相当于延迟了一段时间,更新UI的方法是在ViewRootImpl
对象创建之后做的,所以会发生异常。
所以textView.setText() 只能在主线程执行
这种说法太过绝对
④ new Handler() 两种写法有什么区别?
创建Handler的两种方式示例如下:
创建Handler的两种方式
在Android Studio中使用第一种方式的话会自动加浅黄色背景,如上图,因为这种方式并不推荐使用,我们直接看下源码中是如何使用的:
/**
* Handle system messages here.
*/
public void dispatchMessage(@NonNull Message msg) {
if (msg.callback != null) {
handleCallback(msg);
} else {
if (mCallback != null) {
if (mCallback.handleMessage(msg)) {
return;
}
}
handleMessage(msg);
}
}
两者的区别:
第一种重写的handleMessage()
方法是Handler
对外提供可重写的方法
第二种重写的handleMessage()
方法是Handler.ClaaBack
接口的重写方法
注
使用Hander切换主线程的实现方式:
message.callback是主线程的Runnable对象,使用切换主线程其实就会调用了调用了主线程的Runnable的run()
方法
这里说的run()
方法是Thread
必须实现的run()
方法,源码如下:
private static void handleCallback(Message message) {
message.callback.run();
}
⑤ ThreadLocal 用法和原理
这个问题网上有很多文章是讲解ThreadLocal 的用法和原理,有兴趣的可以去搜一下,这里主要说下在使用的时候注意的问题:
① ThreadLocal 的使用key
是线程,所以不同的线程调用set方法是互不影响的
② 线程中使用ThreadLocal .set()
方法使用完毕记得remove()
,避免不必要的内存浪费~
Handler + Message原理
对于Handler + Message原理分析,网上有很多很多文章了,这里主要就主要用流程图来简单介绍吧~
我们都知道要分析Handler + Message,离不开四个对象:
Handler
、 Message
、Looper
、 MessageQueue
先看下运作的流程图
运作流程
简单来说:就是Handler发送消息
和处理消息
(知识最少原则)
大致流程就是: 应用在启动时,ActivityThread
创建了一个主线程唯一的Looper
对象,调用了Looper.loop()
开启了消息轮询(死循环),然后Handler对象就可以调用sendMessage()
方法将消息压入消息队列,压入的过程调用的就是equeueMessage()
方法,Looper
通过轮询取出队首的message
(先进先出),并且调用message.target.dispatchMessage()
方法分发消息,而message.target
对象就是Handler
,也就是回调了Handler
的handleMessage()
方法
这里有几点要说明:
- ① Handler的
sendMessage()
、post()
、sendEmptyMessageAttime()
等这些发送消息的api都会通过equeueMessage()
将消息压入消息队列 - ② 利用Handler的可以切换主线程的原因是
Message
中有个变量callback
是一个Runnable
对象并且这个Runnable
是在主线程当中的代码如下,我们可以看到如果msg.callback != null
最终就调用了它的run()
方法,所以post()
能实现线程的调度的原因就在这里
public void dispatchMessage(Message msg) {
if (msg.callback != null) {
handleCallback(msg);
} else {
if (mCallback != null) {
if (mCallback.handleMessage(msg)) {
return;
}
}
handleMessage(msg);
}
}
private static void handleCallback(Message message) {
message.callback.run();
}
如果觉得上面的图有点抽象的话,结合下面这种详细的流程图,可能更容易理解:
流程图
到这里差不多就分析完了,但是还有一个疑问没有说明,既然在Looper.loop()
中是一个死循环,为什么主线程不会ANR?
//这里就贴了几行代码,相信大部分小伙伴都看过~
for (;;) {
Message msg = queue.next(); // might block
if (msg == null) {
// No message indicates that the message queue is quitting.
return;
}
.....
}
首先要明确一点,如果ActivityThread
没有在主线程调用Looper.loop()
,ActivityThread
的main()
方法执行完毕就退出了,这显然是不符合实际情况的
其实在Looper.next()开启死循环的时候,一旦需要等待时或还没有执行到执行的时候,
会调用NDK里面的JNI方法,释放当前时间片,这样就不会引发ANR异常了代码大致如下:
- ①
Binder.clearCallingIdentity()
// Make sure that during the course of dispatching the
// identity of the thread wasn't corrupted.
final long newIdent = Binder.clearCallingIdentity();
- ②
Trace.traceBegin(traceTag, msg.target.getTraceName(msg))
if (traceTag != 0 && Trace.isTagEnabled(traceTag)) {
Trace.traceBegin(traceTag, msg.target.getTraceName(msg));
}
最后总结几个相对重要的问题:
- ①
Q :
为什么主线程用Looper死循环不会引发ANR异常?
A :
因为在Looper.next()开启死循环的时候,一旦需要等待时或还没有执行到执行的时候,
会调用NDK里面的JNI方法释放当前时间片,这样就不会引发ANR异常了,同上~
-
②
Q :
为什么Handler构造方法里面的Looper不是直接new?
A :
如果在Handler构造方法里面new Looper,怕是无法保证保证Looper唯一,只有用
Looper.prepare()才能保证唯一性, 具体去看prepare方法 -
③
Q :
MessageQueue为什么要放在Looper私有构造方法初始化?
A :
因为一个线程只绑定一个Looper, 所以在Looper构造方法里面初始化就可以保证mQueue也是
唯的Thread对应一个Looper 对应一个mQueue -
④
Q :
主线程里面的Looper.prepare/Looper.loop, 是一直在无限循环里面的吗?
A :
yes
网友评论