为什么主线程是UI线程？

Question

Android是否有理由选择将主线程作为UI线程？

在单个离线程序或线程池上进行所有计算会不会更容易，然后只有在想要绘制内容时，才将其传递给UI处理程序？

有人可能会说你仍然可以将所有工作卸载到后台线程，然后发布到用户界面 - 但它更多地是关于心态。如果默认情况下它是非UI线程，那么开发人员会更加小心在UI线程上发布什么内容。

我不是在争论这是一个有效的选择还是没有 - 我更感兴趣的是，为什么主线程默认为UI线程的原因是什么？

Answer 1

  

为什么主线程默认为UI线程的原因是什么？

现在，正如我写的那样，它是2017年12月。

Android的架构，就线程模型而言，是在2005-2007时间段的某个地方创建的。它，它创建于十多年前。

当时：

• 移动设备应用非常简单

• 移动设备CPU是单核的，其核心运行速度仅为当今核心速度的一小部分（例如，33MHz，66MHz，133MHz）

• Dalvik纯粹被解释（没有JIT，没有AOT）

拥有“一个神奇的线程”的方法是典型的嵌入式系统解决方案，当您在慢速环境中运行并且线程同步的开销太大时（由解释语言加剧）。鉴于我们并未尝试在应用程序中做太多事情，这是一个合理的选择。创建多个线程，在它们之间传递控制等等，会增加相当大的开销，这是当时无法承受的开销。

在the Star Trek mirror universe中，2005年的CPU速度与今天的CPU速度相当，镜像世界Android团队可能做出了不同的决定，可能包括更灵活的UI工作线程。此外，团队中的所有人都会穿上运动山羊。

Answer 2

可能是让更多人开发应用程序。如果你只是从编程开始，你需要做的第一件事就是创建一个新的UI类，我想你已经害怕这个难度了。

Answer 3

这是一个同步问题，用户的操作和图形界面中显示的结果必须遵循严格的顺序，显然在单个UI线程中更容易实现

Answer 4

易于编程。如果默认情况下所有工作都在一个线程上完成，则不必担心同步，锁定或其他任何问题。鉴于未经正式CS培训的Android开发人员数量，这可能是明智的选择。

实际上从v21开始，有一个单独的渲染线程。传递给onDraw中的视图的Canvas不再绘制，它累积绘制命令，然后将绘制命令列表放入队列。渲染线程每16毫秒唤醒一次（每秒60次）并实际绘制命令列表。

Answer 5

我会说它是以这种方式实现的，因为：

1. 简单 - 你可以做一些简单的事情而不是计算量很大/ IO直接绑定在主线程中而根本不知道线程。
2. 效率与任何 UI操作需要线程间通信的模型相比。在一个线程中执行 tiny 计算和所有UI操作更有效。