首先声明一点：子线程里面是可以更新UI的。
之所以说子线程不能操作UI是因为UIKit不是线程安全的。UI操作涉及到渲染访问各种View对象的属性，如果异步操作下会存在读写问题，而为其加锁则会耗费大量资源并拖慢运行速度。另一方面因为整个程序的起点UIApplication是在主线程进行初始化，所有的用户事件都是在主线程上进行传递（如点击、拖动），所以view只能在主线程上才能对事件进行响应。而在渲染方面由于图像的渲染需要以60帧的刷新率在屏幕上 同时 更新，在非主线程异步化的情况下无法确定这个处理过程能够实现同步更新。
只有极少数的UI能，因为开辟线程时会获取当前环境，如点击某个按钮，这个按钮响应的方法是开辟一个子线程，在子线程中对该按钮进行UI 更新是能及时的，如换标题，换背景图，但这没有任何意义。
试想下面这几种情况：
1.两个线程同时设置同一个背景图片，那么很有可能因为当前图片被释放了两次而导致应用崩溃。
2.两个线程同时设置同一个UIView的背景颜色，那么很有可能渲染显示的是颜色A，而此时在UIView逻辑树上的背景颜色属性为B。
3.两个线程同时操作view的树形结构：在线程A中for循环遍历并操作当前View的所有subView，然后此时线程B中将某个subView直接删除，这就导致了错乱还可能导致应用崩溃。
iOS4之后苹果将大部分绘图的方法和诸如 UIColor 和 UIFont 这样的类改写为了线程安全可用，但是仍然强烈建议讲UI操作保证在主线程中执行。
在主队列中的任务，一定会放到主线程执行; 所以只要是在主队列中的任务，既可以保证在主队列，也可以保证在主线程中执行。
UI更新一定要在UI线程里实现的原因
目的在于提高移动端更新UI的效率和和安全性，以此带来流畅的体验。原因是：
移动端（安卓和iOS）的UI访问是没有加锁的，多个线程可以同时访问更新操作同一个UI控件。也就是说访问UI的时候，系统当中的控件都不是线程安全的，这将导致在多线程模式下，当多个线程共同访问更新操作同一个UI控件时容易发生不可控的错误，而这是致命的。所以规定只能在UI线程中访问UI，这相当于从另一个角度给移动端的UI访问加上锁，一个伪锁。
多线程处理UI并没有给我们开发带来更多的便利，假如你代入了这些情景进行思考，你很容易得出一个结论： “我在一个串行队列对这些事件进行处理就可以了。” 苹果也是这样想的，所以UIKit的所有操作都要放到主线程串行执行。
