Handler 之 初识及简单应用

咕咚 发表于 2016-03-10 阅读次数

这篇文章主要讲解和记录自己对 Handler 的理解。因为一开始接触 Android 就接触到了 Handler,所以对 handler 的了解应该比较多,加上项目中在消息传递以及异步控制方面都要用到 Handler。自己也不止一遍的看过 Handler 源码,不过每次看的时候都能明白,但是时间久了,就很容易忘记。所以这次就有了这个 Handler 系列。从 Handler 的使用场景,到具体使用再到源码解析,自己重新再走一遍,同时通过博客记录下来,方便以后查阅。我想,这也是写博客的意义所在。

谈一个东西之前,首先说明白他为什么要存在。也就是它存在的意义。

为什么要有 Handler

在 Android 中,默认所有的代码都执行在主线程,我们已经在 Activity 中 happy 的写了很久的代码,如设置一个 Button 的颜色、 获取输入框内的文本、设置 ImageView 的图片属性等等,这些操作执行起来都很快,只要设置,我们可能就会马上看到效果,这就是我们常见的 UI 操作。完成 他们几乎都是瞬时的。

但是,在 Android 中有一些操作是很耗费时间的,比如从网络加载一个大图片。因为要建立连接,请求服务端,解析数据等等的操作,所以完成这样的操作,就不是一下两下能做到的。

试想,这个操作发生在主线程,由于线程同一时间只能执行一个操作,所以在请求网络图片的过程中,主线程不能做一些其他的更新 UI 相关的操作,所以我们现在能看到的就是,界面被卡住了,原因已经很清楚,主线程被耗时操作阻塞了。这种卡住的状态直到请求成功。

这里,卡主状态首先不是一种好的用户体验,与此同时, Android 也有一个相关的规定,在主线程完成一个操作的时间不能超过5秒,否则 Android 系统就会给用户弹出一个 ANR 的奔溃对话框。

下面是从官方文章中摘抄的一段

In Android, application responsiveness is monitored by the Activity Manager and Window Manager system services. Android will display the ANR dialog for a particular application when it detects one of the following conditions:
No response to an input event (such as key press or screen touch events) within 5 seconds.
A BroadcastReceiver hasn't finished executing within 10 seconds. 这里需要说明的一点,在 Android 4.0 之后,系统已经不允许在 UI 线程访问网络了,以前只是 ANR,4.0 之后就直接 FC 了。

所以,作为开发者,你一定不希望这样的事发生在你的 App 里,所以我们一定要避免把一个耗时可能超过5秒的操作放在主线程,那怎么才能做到呢?

其实目前已经有很多方法可以做到这一点,用 Thread + Handler 的组合或者使用 AsyncTask,当然如果你知道 RxJava 的话,用 RxJava 也是相当不错的选择。上述三种方式都可实现。

官方也已经提供了一个指南,用于介绍如何避免这种问题,他用到了 AsyncTask,原文 Keeping Your App Responsive,可以一看。

作为自己今天的研究,我主要说 Handler。

使用

由于主线程不能做耗时操作,所以可以在主线程中建立一个子线程,把耗时操作放在子线程完成,这样不就能避开 Android 系统的 ANR 规则了吗?

是的,所以我们可以在主线程 new 一个子线程,让它开启工作,像下面这样

private void executeTask(){
  new Thread(new Runnable() {
      @Override
      public void run() {
          try {
              Bitmap bitmap = loadImg("http://blog.happyhls.me/wp-content/uploads/2015/12/fresco-og-image-1024x362.png");
          } catch (IOException e) {
              e.printStackTrace();
              mHandler.sendMessage(mHandler.obtainMessage(-1,e.getMessage()));
          }
      }
  }).start();
}

如上所示,loadImg() 就是一个耗时操作,可以猜想的到,它里面都发生了什么。

首先发送了网络请求,接着获取到对应的图片数据,然后还把数据解析成 Bitmap,恩恩,这是一个标准的网络请求操作。代码不贴了。

恩,回到正题,你不是很耗时吗?我把你放到一个子线程中去执行,随你怎么耗时,你都不会影响我主线程中的 UI 更新操作。

但是问题来了,子线程 跨过山河大海,飘过远洋高山,终于气喘吁吁的回来了,手里还拿着 bitmap。

此时,我们很容易的想到,赶紧把这个从服务端解析到的 bitmap 通过 ImageView 的 setImageBitmap() 方法设置到 ImageView 上啊,这样我们就可以看到图像了。

此时当你调用上面的方法后,你的应用又崩了。因为此时的 setImageBitmap() 方法调用发生在子线程,同时,这个方法属于更新界面 UI 的操作,而 Android 系统不允许我们的代码在子线程中去更新 UI,更新 UI 的操作只能发生在主线程,so ~ 我们的代码执行到 setImageResource 这里的时候就崩溃了。

Only the original thread that created a view hierarchy can touch its views.
at android.view.ViewRootImpl.checkThread(ViewRootImpl.java:6581)
at android.view.ViewRootImpl.requestLayout(ViewRootImpl.java:924) 奔溃提示如上所示,注意中间那句提示,说的很明白,简单翻译一下

Only the original thread that created a view hierarchy can touch its views.

只有创建了这个 view 树的线程才可以去 touch(泛指操作)这个 View

因为 Activity 的 view 层次树是在主线程完成初始化的,所以对所有依附于这个层次树的 view ,你要是后续想要 touch 它,就一定要在主线程中 touch,不能挪到其他子线程中去 touch。

关于上面说到的, View 层次树的创建以及初始化是在主线程中完成这一点,一些人可能怀疑。这里也不具体深挖代码,简单分析下。

一般的,我们在 onCreate 中调用 setContent() 方法就可以完成布局的设置和加载,如下所示。

  setContentView(R.layout.activity_handler);

很明显,setContent() 是在主线程中调用完成的,这里如果深究 setContent(),你会发现是 PhoneWindow 最终执行了相关的逻辑,而最终通过 Window 的一系列操作,这个 Activity 对应的 View 层次树也就创建成功。同时,这个 Activity 中的所有 view 都将依附于这个层次树。

我们平时可能看过很多这样的结论,『Android 中不允许在子线程中更新 UI』,其实归根结底是这个原因。

说道这里,你不禁想说,Android 也太麻烦了,这么多规则,但是正所谓『无规矩,不成方圆』。有规矩总是好的,况且他也不是只定规矩,不给 API。

既然有问题,Android 就提供了一整套的解决方案。

既然子线程不能更新 UI ,那么就只能去主线程更新,但是现在的程序流正在子线程中,我们要怎么才可以把当前的代码逻辑切换到主线程中去?从而达到更新 UI 的目的。

Handler 来了~

Handler 用法

既然要在主线程中处理 UI ,那么你应该先在主线程里去定义好你的 Handler 。

此时只要在子线程中去调用 handler 的 sendMessage(msg,obj) 方法,你就可以把自己的逻辑,或者程序流给甩到主线程(暂且让我们这么形容吧~)。

private void executeTask(){
     new Thread(new Runnable() {
         @Override
         public void run() {
              // 子线程

              //............. 耗时操作 ................... //

              Bitmap bitmap = loadImg("http://i.imgur.com/DvpvklR.png");

              //............. 耗时操作 ................... //

              Message msg = new Message();
              msg.what = 1;
              msg.obj = bitmap;
              mHandler.sendMessage(msg);
         }
     }).start();
 }

上面可以看到,在子线程里,在执行完耗时操作,得到 bitmap 后,我们简单封装了一个 msg 对象,我们就把这个 msg 通过 mHandler 的 sendMessage 方法,甩到了主线程,主线程中 mHandler 的 handMessage() 方法会处理被甩过来的 msg 对象; 如下所示:

private Handler mHandler = new Handler(){
    @Override
    public void handleMessage(Message msg) {
        super.handleMessage(msg);
        switch (msg.what){
            case 1:
                Bitmap bitmap = (Bitmap) msg.obj;
                imageView.setImageBitmap(bitmap);
                break;
            case -1:
                Toast.makeText(MainActivity.this, "msg "+msg.obj.toString(), Toast.LENGTH_SHORT).show();
                break;
        }
    }
};

注意,这里我把它定义成了一个 Activity 的成员变量,它是在主线程中创建完成的。

这里你可能就要问了,为什么在上面的子线程中调用了

mHandler.sendMessage(msg);

后,msg 就能被甩到主线程中去呢,你说能就能吗?证据在哪里?

其实通过运行代码,我们发现这样确实没问题了,我们在上面的 handlerMessage 方法中的 case 1 中获得了 对应 bitmap,而且 通过调用 setImageBitmap() 方法,我们确实也看到了实际的图片效果。

这就是证据啊,有图有真相,msg 就是被甩到主线程了,否则你怎么看到的图像。

话虽这样说,现象也确实证明了上面说的,但是为什么简单调用了 sendMessage() 方法后,msg 就到了 主线程中呢?背后的具体逻辑到底是什么呢?

下面具体带你进入 Handler 的背后。其实不是带你进入,同时也是带我进入,我虽然看过好多次,但是老是忘记,这次就通过博客的方式记录下。

以备以后再次忘记,哈哈~

具体可以看下一遍文章 Handler 之 源码解析