第一章：第二节：Understanding the Android thread model

Each forked application process runs independently and is scheduled frequent, small amounts of CPU time by the operating system. This time-slicing approach means that even a single-processor device can appear to be actively working in more than one application at the same time, when in fact, each application is taking very short turns on the CPU
每个 fork 出的应用进程都独立运行，并且通过操作系统频繁调度，并且只分配少量的CPU时间。 这种时间切片方法意味着即使是单处理器设备也可以同时使多个应用程序正常工作，而事实上，每个应用程序所分配到的CPU使用时间都非常短。

Within a process, there may be many threads of execution. Each thread is a separate sequential flow of control within the overall program—it executes its instructions in order, one after the other. These threads are also allocated slices of CPU time by the operating system.
在一个进程中，可能有许多执行线程。 每个线程在整个程序中是一个单独的顺序控制流 - 它按顺序一个接一个执行其指令。 这些线程仍然也需要操作系统分配CPU时间片。

While the application process is started by the system and prevented from directly interfering with data in the memory address space of other processes, threads may be started by application code and can communicate and share data with other threads within the same process
虽然应用程序进程由系统启动并且防止直接干扰其他进程的内存地址空间中的数据，但线程可以由应用程序代码启动，并且可以与同一进程中的其他线程通信和共享数据

The main thread

Within each DVM process, the system starts a number of threads to perform important duties such as garbage collection, but of particular importance to application developers is the single thread of execution known as the main or UI thread. By default, any code that we write in our applications will be executed by the main thread
在每个DVM进程中，系统启动许多线程来执行重要任务，例如垃圾收集，但对应用程序开发人员来说特别重要的是称为主线程或UI线程的单个执行线程。 默认情况下，我们在应用程序中编写的任何代码都将由主线程执行

For example, when we write code in an onCreate method in the Activity class, it will be executed on the main thread. Likewise, when we attach listeners to user-interface components to handle taps and other user-input gestures, the listener callback executes on the main thread.
例如，当我们在Activity类的onCreate方法中编写代码时，它将在主线程上执行。 同样，当我们在用户界面的组件中添加监听器来处理点击和其他用户输入手势时，监听器回调将在主线程上执行。

For apps that do little I/O or processing, this single thread model is fine. However, if we need to do CPU-intensive calculations, read or write files from permanent storage, or talk to a web service, any further events that arrive while we’re doing this work will be blocked until we’re finished
对于进行少量I / O或处理的应用程序，这个单线程模型毫无问题。 但是，如果我们需要进行CPU密集型计算，从永久存储中读取或写入文件，或者与Web服务通信，那么直到这项任务处理完成之前，到达的任何事件都会被block

Unresponsive apps and the ANR dialog

As you can imagine, if the main thread is busy with a heavy calculation or reading data from a network socket, it cannot immediately respond to user input such as a tap or swipe.
可以想象，如果主线程忙于大量计算或从网络套接字读取数据，它就无法立即响应用户输入，例如点击或滑动。

An app that doesn’t respond quickly to user interaction will feel unresponsive—anything more than a couple of hundred milliseconds delay is noticeable. This is such a pernicious problem that the Android platform protects users from applications that do too much on the main thread
一个不能对用户交互做出快速响应的应用程序会感觉到没有响应，任何超过几百毫秒的延迟都是显而易见的。这是一个非常有害的问题，Android平台保护用户不受在主线程上做得太多的处理的影响。

Android works hard to synchronize user interface redraws with the hardware refresh rate. This means that it aims to redraw at 60 frames per second—that’s just 16.67 ms per frame. If we do work on the main thread that takes anywhere near 16 ms, we risk affecting the frame rate, resulting in jank—stuttering animations, jerky scrolling, and so on
Android努力将用户界面重绘与硬件刷新率同步。这意味着它的目标是以每秒60帧的速度重新绘制，即每帧仅16.67毫秒。如果我们在主线程上做的工作需要16毫秒左右的时间，我们就有可能影响帧速率，从而导致动画延迟、急促的滚动等等。

At API level 16, Android introduced a new entity, the Choreographer, to oversee timing issues. It will start issuing dropped-frame warnings in the log if you drop more than 30 consecutive frames.
在API 16中，Android引入了一个新的实体，即Choreographer（编舞者），来监督时间问题。如果连续丢弃超过30帧，它将开始在日志中发出丢弃帧警告。

Ideally, of course, we don’t want to drop a single frame. Jank, unresponsiveness, and especially the ANR, offer a very poor user experience and translate into bad reviews and an unpopular application. A rule to live by when building Android applications is: do not block the main thread!
当然，理想情况下，我们不希望丢弃帧。 闪屏，反应迟钝，特别是ANR，提供了非常糟糕的用户体验，并转化为糟糕的评论和不受欢迎的应用程序。 构建Android应用程序时遵循的规则是：不要阻塞主线程！

Further protection was added to the platform in Honeycomb (API level 11) with the introduction of a new Exception class, NetworkOnMainThreadException, a subclass of RuntimeException that is thrown if the system detects network activity initiated on the main thread
在Honeycomb（API 11）中向平台添加了进一步的保护，引入了新的Exception类NetworkOnMainThreadException，如果系统检测到在主线程上启动的网络活动，则抛出RuntimeException的子类

Maintaining responsiveness

Ideally then, we want to offload long-running operations from the main thread so that they can be handled in the background, and the main thread can continue to process user interface updates smoothly and respond in a timely fashion to user interaction
理想情况下，我们希望从主线程移除长时间运行的操作，以便在后台处理，这样主线程可以继续平滑地处理用户界面更新并及时响应用户交互

For this to be useful, we must be able to coordinate work and safely pass data between cooperating threads—especially between background threads and the main thread
为了保证这样有效果，我们必须能够协调工作并安全地在协作线程之间传递数据，特别是在后台线程和主线程之间传递数据。

We also want to execute many background tasks at the same time and take advantage of additional CPU cores to churn through heavy processing tasks quickly.
我们还希望同时执行多个后台任务，并利用额外的CPU内核快速完成繁重的处理任务。

This simultaneous execution of separate code paths is known as concurrency.
这种同时执行不同代码的行为称为并发。