※ 引述《ntuleo (里欧)》之铭言：
: 我们都知道要开一个thread去改UI的话是不行的，需要用handler机制把thread用
: sendmessage的方式回call main thread的handle message才能修改
: 这边有个疑问是
: 这样跟直接用method在main thread中修改UI有什么差异呢?
: 因为用handler新开的thread虽然是在后台跑
: 但是回call回来还是block住main thread不是吗? 这样跟用method有什么不同呢?
不错不错。
你有在思考为什么Android Framework不允许你在main thread之外的thread操作UI。
很多人其实搞不清楚这是怎么一回事，
所以就会有一些倒因为果的回答，比如说ANR或阻塞之类的。
就好像你问人为什么要吃东西，大家都回答因为肚子饿啊之类的回答。
这算是答案吗？
若是单纯要说有回答，是的，是有回答。
但这回答有意义吗？
不过这是典型台湾教育的人会出现的想当然尔。唉…
好的，继续回答标题问的这个问题。
现代的UI Framework通常会设计为操作UI只能在某一个特定的thread，我们通常会叫它UI thread。这里要厘清一下，我在这里说的UI thread和main thread语意上不一定是同一个thread。
WTF？
因为我指的不仅仅是Android Framework，而是指现代的UI Framework设计。只是Android Framework让main thread 成了UI thread。所以只写过Android的人会以为在其他系统上，main thread 就是UI thread。不是！是Android选择了这样的设计。你要我举main thread不是UI thread的Framewor。OK，Java标准的UI Framework，叫swing，main thread就不是UI thread。
厘清了这个观念后，接下来的问题是，为什么现代的系统都要设计UI只能跑在单一thread上？不能让很多个thread都操纵UI吗？
不行。因为不这样设计会容易 deadlock。
为什么？
这要分两方面讲。
第一个概念，
如果有两个thread写程式时上锁的顺序，
thread 1是 拿到Lock A再来是 拿Lock B。
而thread 2 是 拿到Lock B 再来是拿 Lock A。
这样有可能thread 1 拿到Lock A，
这时thread 2拿到Lock B。
完蛋了，情况变成是thread 1永远拿不到Lock B，
thread 2永远拿不到Lock A，产生了deadlock。
也就是多执行绪程式很重要的一条，
不同执行绪上锁的顺序要一致。
第二个概念
我们电脑系统的UI运作可以大概这样分层
App 应用程式
UI Framework 框架
OS 作业系统
HW 硬件
你写程式更改UI时程式是从APP>>UI Framework>> OS >> HW
而你写某个UI元件被触摸到时的反应是
HW>>OS>>UI Framework>>APP
嗯，两者方向相反。
好了今天要是这两者跑在不同thread上，而程式要取得某两个lock，lock A，lock B。
可能会有这样子的情况你写程式更改UI时程式是从
APP>>UI Framework part 1>>拿lock A>>UI Framework part 2>>拿lock B>>UI Framework part 3>>OS >> HW
而按钮触发实的反应执行时是
HW>>OS >>UI Framework part a >>拿lock B >>UI Framework part b>>拿lock A>>UI Framework part c>>APP
刚好满足了deadlock的条件
这就是为什么UI要限制在单ㄧthread ，我们通常称呼为UI thread上执行。
你又会问那要是UI Framework设计为多执行绪会如何？
嗯，那你要很聪明，又很小心，很了解UI内部运作的细节来避开死锁。
但是要是死锁会很难侦错，因为死锁有时会发生有时不会发生。
而以前有人这样设计系统的情况是，没人读UI Framework设计者的说明档案和提醒，写程式的人遇到死锁时只是骂UI Framework设计的人是白痴，设计很烂。所以设计UI Framework现在都流行把UI限制在专门的thread上跑。
大概4酱。
读到这个问题很久了，只是我很懒得回答，因为要写这么多。而且我当下还是只用手机写，两年了，我终于断断续续写完了。
这篇文章送给认真思考这个问题的你。