理解UI线程——swt, Android, 和Swing的UI机理

在做GUI的时候, 无论是SWT, AWT, Swing 还是Android, 都需要面对UI线程的问题, UI线程往往会被单独的提出来单独对待, 试着问自己,

当GUI启动的时候, 后台会运行几个线程? 比如

1. SWT 从Main函数启动

2. Swing 从Main函数启动

3. Android 界面启动

常常我们被告知, 主线程, UI线程, 因此这里很多会回答, 有两个线程, 一个线程是Main, 另外一个是UI.  如果答案是这样, 这篇文章就是写给你的。

 

OK, 我们以SWT为例, 设计以下方案寻找答案, 第一步, 我们看能否找到两个线程:

1. 从Main中启动SWT的界面, 在启动界面前, 将Main所在的线程打印出来 这里设计为Shell中嵌入一个Button

2. 点击Button, 运行一个耗时很长的操作, 反复修改Button的文字, 在该线程中打印该线程的名称

 

代码是这样的:

 

haveArest方法在最后出现, 只是封装了一个让线程等待一段时间, 打印的结果都为main, 于是得到第一个重要的结论:

UI所在的线程和Main所在的线程都是同一个线程。

 

再来推断一把:

UI在哪个线程启动的, 则这个线程就是UI线程.

通过打印结果发现, 推论是正确的.

 

根据铺天盖地参考书提示, 有这样一条定律:

只可以存在一个UI线程

验证一下, 我们的验证方式是创建两个UI线程:

但这里确实创建了两个线程。看来一个进程是可以创建两个线程的。

 可以存在一个或者多个UI线程, 下次看到参考书这么写的时候, 可以BS它了。  

 

之前犯了一个错误就是用Diplay display = Display.getDefault(); 这样得到的是前一个线程创建的Display,故不能创建. 造成只能创建一个UI线程的错觉

 

当然我们的研究不能到此为止, 我们需要探究一下, 为什么总是被告知更新UI的动作要放在UI线程中?

回到第一个例子中, 即:


 

 

运行的时候拖动试试, 发现不动, 直到for循环中修改btn的操作完成.

这里我们不难明白一个观点:

同一个线程的情况下, 一个操作(拖动), 是需要等待另外一个操作(更新btn)完成后, 才可以进行的。

不难理解, 我们常用的做法是:

通过启动另外一个线程, 在cpu微小的间隔时间内,完成两个动作的交替

于是有了下面的代码:


 

但这样发现会报错, 原因是, 线程访问出错了, 因为有一个这样的规则需要我们保障:

所有的UI相关的操作, 务必保证在UI线程中更新.

为什么会有这样一条铁律? 原因是界面的消息需要分发到各大控件上面去, 如果不能保证UI在相同的线程, 分发起来就会比较复杂. UI本身占用的资源比较多.  如果在将UI分属不同的线程, 切换起来, 将耗费大量的CPU资源.

 

为了保证这条, SWT 是这么做的, 利用Diplay这个变量获取UI线程, 然后在其中做UI访问和操作:

 

后面会继续关注Swing和Android的例子, 相信这些也是大同小异的. 关键是, UI特殊, 但特殊性不在于它是一个额外的线程.

 

这样的应用其实很多, 比如我们不断刷表格的时候, 为了让界面能接受其它的响应事件, 一般都把刷表格的动作放置到另外的线程中, 用Display.asychronize()来保障其访问UI元素的安全行(即在UI中访问). 

 

总结一下, 本文由如下结论:
UI线程和主线程,普通线程的关系
1. UI线程和Main线程没有必然联系, 从Main函数启动, 也可以从一个其它的线程启动. 启动UI的线程, 则为UI线程
2. 如果第一个线程启动了UI. 则第一个线程则成为UI线程. 如果第二个线程涉及UI操作, 则需要保证这个操作放在UI线程中. 否则会出现Invalid thread access错误.

SWT为什么会有Display.asyncExec(new Runnable())操作:
1. 当界面执行了长时段的UI操作, 比如进度条, 此时如果把更新UI的操作放在唯一的UI线程中执行, 那么本线程将全部消耗CPU资源, 造成界面无法拖动.拖动则界面死掉MethodA()。
2. 为了解决问题1, 我们一般另外启动一个线程进行操作, 这样使得界面可以拖动, 但是UI的操作无法在其它的线程中完成, 只能在UI线程中完成,
3. Display.asyncExec(new Runnable()的目的就是将这个动作放在UI线程中完成. 这样避免报错Invalid thread access

 

 

补充SWT的知识, 很多不明白Display.asyncExec 和Display.syncExec的区别, 用个例子说明一下:

 

按注释运行下, 就会发现这里面大有玄机, 不过我这边并不是为了解决SWT的问题, 而是针对所有的UI线程来的, 所以, 不再做解释.

 

推荐阅读. 该牛人的长篇大作.

 

多谢同事章导对SWT修正的问题. 即使弥补了误导大家的观点, :)

 

 


 

Android 也是相同的原理:

 

1. 通过多线程避免界面假死


2. 通过Hander保证访问界面元素在UI线程中进行.

 

其它的一些细微差别, 不需要多讲. 原理乃一个模子出来的.

 

一个Android Helloworld运行起来的时候, 有四个线程

 

1. 传说中的Main线程

 

2. 另外三个都是Binder Thread, 貌似是为了跨进程通信用的监听线程.

 

貌似很多Android的教程都把UI线程当特殊的一个线程.

 

 


 

至于Swing/awt 貌似无需费心机去了解了.

 

 

  • 0
    点赞
  • 9
    收藏
    觉得还不错? 一键收藏
  • 16
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 16
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值