背景 MQTT是一个客户端服务端架构的发布/订阅模式的消息传输协议。它的设计思想是轻巧、开放、简单、规范，易于实现。这些特点使得它对很多场景来说都是很好的选择，特别是对于受限的环境如机器与机器的通信（M2M）以及物联网环境（IoT）。 ——MQTT协议规范中文版
MQTT协议最初版本是在1999年建立的。该协议的发明人是的Andy Stanford-Clark和Arlen Nipper。
MQTT 的诞生，是在一个利用卫星通讯监控输油管道的项目。
所以它最初是面对 低带宽、高延迟或不可靠的网络 而设计的。虽然历经几十年的更新和变化，以上这些特点仍然是MQTT协议的核心特点。但是与最初不同的是，MQTT协议已经从嵌入式系统应用拓展到开放的物联网（IoT）领域。
版本 MQTT协议有三个版本，分别是：
MQTT v3.1 MQTT v3.1.1 MQTT v5.0 目前客户端很多主流的MQTT库都是基于MQTT v3.1.1版本。而且后续的5.0是完全兼容3.1.1版本的，所以优先学习这个3.1.1版本。
基本通信介绍 和其他网络通信流程一致，MQTT通信中的角色也是分为服务端和客户端。
服务端是MQTT信息传输的枢纽，负责将MQTT客户端发送来的信息传递给MQTT客户端。MQTT服务端还负责管理MQTT客户端。确保客户端之间的通讯顺畅，保证MQTT消息得以正确接收和准确投递。 客户端可以往服务端推送消息和获取消息。 MQTT协议的通信架构是独特的 订阅/发布机制 ，不像HTTP那种 请求/响应机制 ，从服务端获取数据需要客户端主动发起请求，服务端才能返回数据。
MQTT的通信机制更像是Android里的广播 ，客户端可以订阅(Subscribe) 某个主题，当服务端发现这个主题被某一个客户端发布(Publish) 更新时，就会将消息推送给订阅了该主题的客户端。
订阅发布机制 MQTT服务端在管理MQTT信息通讯时，就是使用一个个的“主题”来控制的。
比如车载云平台开发时，就会有一个 车辆状态 的主题，当车辆状态发生变化时，就会往这个 车辆状态 主题发送消息。具体的，当汽车的胎压传感器有数据上报时，就会往“胎压传感器”这个主题发送消息。手机客户端，订阅了这个胎压主题，就可以收到胎压传感器上报到服务器，而后分发下来的消息。
同时，手机端可以往 座椅加热 这个主题发布消息，打开开关。服务器收到消息后，就会下发到订阅这个主题的汽车客户端，车辆控制器收到后就可以远程打开座椅加热。在冬天，司机上车之前就可以提前打开座椅加热，上车之后就不会被冻了。
订阅发布的特性 从以上实例我们可以看到，MQTT通讯的核心枢纽是MQTT服务端。有了服务端对MQTT信息的接收、储存、处理和发送，客户端在发布和订阅信息时，可以相互独立，且在空间上可以分离，时间上可以异步。
相互可独立 MQTT客户端是一个个独立的个体。它们无需了解彼此的存在，依然可以实现信息交流。客户端本身可以完全不知道有多少个MQTT客户端订阅了这一主题。而订阅了同一主题的客户端也完全不知道彼此的存在。大家只要订阅了同一个主题，MQTT服务端就会在每次收到新信息时，将信息发送给订阅的客户端。
空间可分离 空间分离相对容易理解，MQTT客户端在通讯必要条件是连接到了同一个MQTT通讯网络。这个网络可以是互联网或者局域网。只要客户端联网，无论他们远在天边还是近在眼前，都可以实现彼此间的通讯交流。
时间可异步 MQTT客户端在发送和接收信息时无需同步 。这一特点对物联网设备尤为重要。有时物联网设备会发生意外离线的情况。当我们的汽车在行驶过程中，可能会突然进入隧道，这时汽车可能会断开与MQTT服务端的连接。假设在此时我们的手机客户端向汽车客户端所订阅的“空调温度”主题发布了信息，而汽车恰恰不在线。这时，MQTT服务端可以将“空调温度”主题的新信息保存，待汽车再次上线后，服务端再将“空调温度”信息推送给汽车。
主题Topic MQTT协议中，消息的传输是通过主题来实现的。主题是一个字符串，用来标识消息的类型。当客户端订阅了一个主题时，服务端会将该主题的信息发送给客户端。当客户端发布了一个主题时，服务端会将该主题的信息发送给所有订阅了该主题的客户端。
主题格式 MQTT主题是一个字符串，用来标识消息的类型。主题可以包含多个单词，单词之间使用斜杠（/）分隔。同时，主题也可以分级，例如：
motor_speed motor_speed/left motor_speed/right 这些主题可以用来标识不同类型的消息。例如，“motor_speed”主题可以用来标识电机的速度信息，而“motor_speed/left”主题可以用来标识左电机的速度信息。
定义主题时，需要注意以下几点：
主题是区分大小写的 。如上列表中的主题 motor_speed和Motor_speed是两个完全不同的主题。主题可以使用空格 ，如以上列表中的current time，虽然有空格分隔current和time这两个词，但这实际是一个MQTT主题。不过，虽然我们可以使用空格，但是笔者强烈建议您不要在主题中使用空格。我们在开发时一不小心，可能就会漏掉空格，这将造成不必要的麻烦。大部分MQTT服务端是 不支持中文主题 的，所以我们应使用英文字符或ASCII字符来作为MQTT主题。 主题通配符 当客户端订阅主题时，可以使用通配符同时订阅多个主题。通配符只能在订阅主题时使用，下面我们将介绍两种通配符：单级通配符和多级通配符。
单级通配符: + 顾名思义，单级通配符可以代替一个主题级别。 以下为含有单极通配符的主题示例。
home/sensor/+/temperature
当客户端订阅了以上主题后，它将会收到以下主题的信息内容：
home/sensor/kitchen/temperature
home/sensor/bedroom/temperature
我们可以看到，在home后面的级别中，由于客户端订阅的主题使用了+ 单级通配符，因此无论home级别后面的内容是什么，客户端都能收到这些主题的信息。
相反，客户端将无法收到以下主题的信息。
home/sensor/bedroom/brightness
office/sensor/bedroom//temperature
home/screen/livingroom/temperature
以上主题的红色部分都是客户端无法收到信息的原因。这些红色的部分都是与客户端订阅的主题“home/sensor/+/temperature”不相符的部分。
多级通配符 # 单级通配符仅可代替一个主题级别，而多级通配符”#”可以涵盖任意数量的主题级别。如下示例所示， 多级通配符必须是主题中的最后一个字符。
当客户端订阅了以上含有”#”的主题后，可以收到以下主题的信息。
home/sensor/kitchen/temperature
home/sensor/bedroom/brightness
home/sensor/data
多级通配符可以代替多级主题信息，因此无论”home/sensor”后面有一级还是多级主题，都可以被订阅了”home/sensor/#”的客户端接收到。
注意事项 以$开始的主题 以 $ 开始的主题是 MQTT服务端系统保留的特殊主题 ，我们不能随意订阅或者向其发布信息。以下是此类主题的示例：
$SYS/broker/clients/connected
$SYS/broker/clients/disconnected
$SYS/broker/clients/total
$SYS/broker/messages/sent
$SYS/broker/uptime
类似的主题还有很多。不过请记住一点，以$符号开头的主题是系统保留的特殊主题，我们不能随意订阅或者向其发布信息 。
不要用 “/” 作为主题开头 MQTT允许使用“/”作为主题的开头，例如/home/sensor/data。但是这将这么做毫无意义，而且会额外产生一个没有用处的主题级别。所以我们应避免使用/作为主题的开头。
连接服务器 分为两步，第一步是客户端发送连接请求，第二步是服务端发送连接确认。
一、客户端连接请求 首先MQTT客户端将会向服务端发送连接请求。该请求实际上是一个包含有连接请求信息的数据包。这个数据包的官方名称为CONNECT。
有三个必选参数：
客户端ID – 客户端的唯一标识。 cleansession – 是否清除该客户端之前的会话。 keepalive – 心跳时间，用于确认连接状态。 clientId ClientId 是MQTT客户端的标识。MQTT服务端用该标识来识别客户端。因此ClientId必须是独立的 。如果两个MQTT客户端使用相同ClientId标识，服务端会把它们当成同一个客户端来处理。
通常ClientId是由一串字符所构成的，如上图所示，此示例中的clientID是“client-1”。在车载端，clientID是由车载设备的唯一标识所构成的，通常为内部项目号加上车架号 ，也就是俗称的 VIN 码。
cleanSession 如果 cleanSession 被设置为“true”。那么服务端不需要客户端确认收到报文，也不会保存任何报文。在这种情况下，即使客户端错过了服务端发来的报文，也没办法让服务端再次发送报文。
将 cleanSession 设置为”false”。那么服务端就知道，后续通讯中，客户端可能会要求我保存没有收到的报文。
如果某个客户端用于收发非常重要的信息 （比如前文示例中汽车自动驾驶系统），那么该客户端在连接服务端时，应该将 cleanSession 设置为 false 。这样才能让服务端保存那些没有得到客户端接收确认的信息。以便服务端再次尝试将这些重要信息再次发送给客户端。请注意，如果需要服务端保存重要报文，光设置cleanSession 为false是不够的，还需要传递的MQTT信息QoS级别大于0。
相反的，如果某个客户端用于收发不重要的信息 （比如前文示例中车载音乐系统）那么该客户端在连接服务端时，应该将cleanSession设置为 true 。
keepalive keepalive是一个心跳时间 。该时间用来检测客户端是否在线 。如果客户端超过所设置的keepalive时间后，仍然没有收到服务端的任何报文，那么服务端就会认为客户端已经掉线。此时服务端会断开与客户端的连接。
其他参数 除了这三个必选的参数，同时还有几个可选参数 ：
用户名 – 连接到MQTT服务端的用户名。 密码 – 连接到MQTT服务端的密码。 遗嘱消息 – 当客户端意外断开连接时，发布遗嘱消息。 遗嘱主题 – 当客户端意外断开连接时，会像该遗嘱主题发布遗嘱消息。 遗嘱QoS – 当客户端意外断开连接时，遗嘱消息的服务质量。 用户密码认证 username(用户名)和password（密码）是可选的CONNECT信息 。也就是说，有些服务端开启了客户端用户密码认证，这种服务端需要客户端在连接时正确提供认证信息才能连接。当然，那些没有开启用户密码认证的服务端无需客户端提供用户名和密码认证信息。
有些公用MQTT服务端也利用此信息来识别客户端属于哪一个用户，从而对客户端进行管理。比如用户可以拥有私人主题 ，这些主题只有该用户可以发布和订阅。对于私人主题，服务端就可以利用客户端连接时的用户名和密码来判断该客户端是否有发布订阅该用户私人主题的权限。
二、服务端连接确认 MQTT服务端收到客户端连接请求后，会向客户端发送连接确认。同样的，该确认也是一个数据包。这个数据包官方名称为CONNACK。
returnCode 这里可以类比HTTP的状态码。当服务端收到了客户端的连接请求后，会向客户端发送returnCode(连接返回码)，用以说明连接情况。如果客户端与服务端成功连接 ，则返回数字 “0” 。如果未能成功连接，连接返回码将会是一个非零的数值，具体这个数值的含义如下：
0——成功连接 1——连接被服务端拒绝，原因是不支持客户端的MOTT协议版本 2——连接被服务端拒绝，原因是不支持客户端标识符的编码可能造成此原因的是客户端标识符编码是UTF-8，但是服务端不允许使用此编码， 3——连接被服务端拒绝，原因是服务端不可用。即，网络连接已经建立，但MQTT服务不可用。 4——连接被服务端拒绝，原因是用户名或密码无效。 5——连接被服务端拒绝，原因是客户端未被授权连接到此服务。 sessionPresent sessionPresent是一个布尔值。如果该值为“true”，则表示服务端已经保存了与客户端的会话。如果该值为“false”，则表示服务端没有保存与客户端的会话。
当重要客户端连接服务端时， 服务端可能保存着没有得到确认的报文 。如果是这样的话，那么客户端在连接服务端时，就会通过sessionPresent来了解服务端是否有之前未能确认的信息。
QoS服务质量 MQTT协议有三种服务质量级别：
QoS = 0 – 最多发一次 QoS = 1 – 最少发一次 QoS = 2 – 保证收一次
以上三种不同的服务质量级别意味着不同的MQTT传输流程。对于较为重要的MQTT消息，我们通常会选择QoS>0的服务级别（即QoS 为1或2）。
QoS=0 0是服务质量QoS的最低级别。当QoS为0级时，MQTT协议并不保证所有信息都能得以传输。也就是说，QoS=0的情况下，MQTT服务端和客户端不会对消息传输是否成功进行确认和检查。消息能否成功传输全看网络环境是否稳定。
也就是说，在QoS为0时。发送端一旦发送完消息后，就完成任务了。 发送端不会检查发出的消息能否被正确接收到。
QoS=1 QoS=1是服务质量QoS的中间级别。当QoS为1级时，MQTT协议会保证消息至少被传输一次。
当QoS=1时，MQTT服务端和客户端会对消息传输进行确认。也就是说，当MQTT服务端收到了客户端的消息后，会向客户端发送一个PUBACK（发布确认）报文。客户端收到PUBACK报文后，就知道消息已经被服务端成功接收。 保证收到一次消息的兜底机制，救赎客户端发送后会启动一个计时器，当倒计时结束还没有收到服务端反馈时，就再次发送。所以QoS为1时，有重复发送的可能。
QoS=2 MQTT服务质量最高级是2级，即QoS = 2。当MQTT服务质量为2级时，MQTT协议可以确保接收端只接收一次消息。这个最高质量的通信，是通过 两阶段确认，共四次握手 来实现的。
流程：
发送端发送QoS=2的 PUBLISH 报文给接收端，这条报文会附带一个 packetId 数据包标识符，用于识别单次通信并作为去重的依据； 接收端收到QoS为2的消息后，会把此报文进行临时存储，并立即返回 PUBREC （Publish Received） 报文作为应答。后面如果再次收到同一个 packetId 的消息时，会主动去重； 发送端收到接收端反馈的 PUBREC 报文后，可以确定接收方已经收到了第一次的消息，就不会再重复发送PUBLISH消息。然后，发送端会再次发送一条 PUBREL（Publish Release） 释放报文作为应答； 当接收端收到PUBREL报文后，会应答发送端一条 PUBCOMP（Publish Complete） 报文。至此，一次QoS=2的MQTT消息传输就结束了。 发布，订阅，取消订阅 PUBLISH – 发布信息 SUBSCRIBE – 订阅主题 SUBACK – 订阅确认 UNSUBSCRIBE – 取消订阅 一、PUBLISH发布信息 MQTT客户端可以向MQTT服务端发布信息。发布信息的数据包的官方名称为PUBLISH。
MQTT 中的 PUBLISH 消息具有多个决定其行为的属性，包括数据包标识符、主题名称、服务质量、保留标志、有效负载和 DUP 标志。让我们逐一了解一下。
topicName – 主题名 主题名用于识别此信息应发布到哪一个主题。
qos – 服务质量 QoS（Quality of Service）表示MQTT消息的服务质量等级。QoS有三个级别：0、1和2。QoS决定MQTT通讯有什么样的服务保证。
packetId – 数据包标识符 报文标识符可用于对MQTT报文进行标识。不同的MQTT报文所拥有的标识符不同。MQTT设备可以通过该标识符对MQTT报文进行甄别和管理。请注意：报文标识符的内容与QoS级别有密不可分的关系。只有QoS级别大于0时，报文标识符才是非零数值。如果QoS等于0，报文标识符为0。
retainFlag – 保留标志 在默认情况下，当客户端订阅了某一主题后，并不会马上接收到该主题的信息。只有在客户端订阅该主题后，服务端接收到该主题的新信息时，服务端才会将最新接收到的该主题信息推送给客户端。
但是在有些情况下，我们需要客户端在订阅了某一主题后马上接收到一条该主题的信息。这时候就需要用到保留标志这一信息。
在需要发布保留消息时，MQTT设备需要将PUBLISH报文中retainFlag设置为true（如上图所示）。
当然，如果要发布非保留消息，那么PUBLISH报文中retainFlag设置为false。
更新保留消息 每一个主题只能有一个“保留消息”，如果客户端想要更新“保留消息”，就需要向该主题发送一条新的“保留消息”，这样服务端会将新的“保留消息”覆盖旧的“保留消息”。当有客户端订阅该主题时，服务端就会将最新的“保留消息”发送给订阅客户端了。
删除保留消息的方法 如果要删除主题的“保留消息”，可以通过向该主题发布一条空的“保留消息”，也就是发送一条0字节payload的“保留消息”
payload – 有效负载 有效載荷是我们希望通过MQTT所发送的实际内容。我们可以使用MQTT协议发送文本，图像等格式的内容。这些内容都是通过有效載荷所发送的。
dupFlag – 重复标志 当MQTT报文的接收方没有及时确认收到报文时，发送方会重复发送MQTT报文。在重复发送MQTT报文时，发送方会将此“重发标志”设置为true。请注意，重发标志只在QoS级别大于0时使用。
二、SUBSCRIBE订阅主题 客户端要想订阅主题，首先要向服务端发送主题订阅请求。客户端是通过向服务端发送SUBSCRIBE报文来实现这一请求的。
该报文包含有一系列“订阅主题名”。请留意，一个SUBSCRIBE报文可以包含 有单个或者多个 订阅主题名。可以同时订阅一个或者多个主题。
在以上PUBLISH报文讲解中，我们曾经提到过QoS（服务质量等级）这一概念。同样的，客户端在订阅主题时也可以明确QoS。服务端会根据SUBSCRIBE中的QoS来提供相应的服务保证。
另外每一个SUBSCRIBE报文同样包含有“报文标识符”。
三、SUBACK订阅确认 服务端接收到客户端的订阅报文后，会向客户端发送SUBACK报文确认订阅。SUBACK报文包含有“订阅返回码”和“报文标识符”这两个信息。
客户端可通过一个SUBSCRIBE报文发送多个主题的订阅请求。服务端会针对SUBSCRIBE报文中的所有订阅主题来 逐一回复给客户端一个返回码 。
返回码含义：
返回码 Return Code Response 0 订阅成功 – QoS 0 1 订阅成功- QoS 1 2 订阅成功- QoS 2 128 订阅失败
四、UNSUBSCRIBE取消订阅 当客户端要取消订阅某主题时，可通过向服务端发送UNSUBSCRIBE – 取消订阅报文来实现。
UNSUBSCRIBE报文包含两个重要信息，第一个是取消订阅的主题名称。同一个UNSUBSCRIBE报文可以同时包含多个取消订阅的主题名称。另外，UNSUBSCRIBE报文也包含“报文标识符”，MQTT设备可以通过该标识符对报文进行管理。
当服务端接收到UNSUBSCRIBE报文后，会向客户端发送取消订阅确认报文 – UNSUBACK报文。该报文含有客户端所发送的“取消订阅报文标识符”。
客户端接收到UNSUBACK报文后就可以确认取消主题订阅已经成功完成了。
心跳机制 客户端并不经常发送消息给服务端。对于这种客户端，服务端可以使用类似心跳检测的方法，来判断客户端是否在线。
这个心跳机制不仅可以用于服务端判断客户端是否保持连接，也可以用于客户端判断自己与服务端是否保持连接。如果客户端在发送心跳请求（PINGREQ） 后，没有收到服务端的心跳响应（PINGRESP） ，那么客户端就会认为自己与服务端的连接已经被断开了。
客户端发送心跳请求的时间间隔就是连接时CONNECT报文中keepalive的值。
双方对齐了心跳间隔之后，不是每次都必须要发送消息才可以确认连接在线。
如果客户端在心跳时间间隔内 发布了业务消息给服务端 ，那么服务端不需要客户端发送心跳请求也可以确定该客户端肯定在线。
当客户端在心跳间隔内没有新消息发送给服务端，这时客户端才会主动发送一个心跳请求消息给服务端。以表明自己仍让在线。
在实际运行中，如果服务端没有在1.5倍心跳时间间隔内收到客户端发布消息(PUBLISH)或发来心跳请求(PINGREQ)，那么服务端就会认为这个客户端已经掉线。
遗嘱消息 在CONNECT报文里，同样有一条遗嘱消息。客户端可以提前设置好一条遗嘱消息，当客户端异常掉线之后，由服务端将这条遗嘱消息发送给其他订阅了这条遗嘱主题的客户端。如果是正常断开，则不会发送。
正常断联 当客户端正常断开连接时，会向服务端发送DISCONNECT报文，服务端接收到该报文后，就知道，客户端是正常断开连接，而并非意外断开连接。
意外断联 然而，当服务端在没有收到DISCONNECT报文的情况下，发现客户端“心跳”停止了，这时服务端就知道客户端是意外断线了。
回顾一下CONNNECT报文：
有关遗嘱消息的参数含义如下：
lastWillTopic – 遗嘱主题 遗嘱消息也有主题和正文内容。lastWillTopic的作用正是告知服务端，本客户端的遗嘱主题是什么。只有那些订阅了这一遗嘱主题的客户端才会收到本客户端的遗嘱消息。
lastWillMessage – 遗嘱消息 遗嘱消息定义了遗嘱消息内容。在本示例中，那些订阅了主题”hans/will”的客户端会在客户端意外断线时，收到服务端发布的“unexpected exit”。
lastWillQoS – 遗嘱QoS 对于遗嘱消息来说，同样可以使用服务质量来控制遗嘱消息的传递和接收。这里的服务质量与普通MQTT消息的服务质量是一样的概念。
lastWillRetain – 遗嘱保留 遗嘱消息也可以设置为保留消息，服务端会根据此处内容，对遗嘱消息进行相应的保留与否处理
HTTP over SSL 的简称，即⼯作在 SSL （或 TLS）上的 HTTP。说⽩了就是加密通信的 HTTP，注意并不是一个单独的协议。HTTPS（SSL/TLS）是计算机网络的知识，主要用来对HTTP协议传输的文本进行加密，提高安全性的一种协议。
SSL：Secure Socket Layer TSL: Transport Layer Secure 因为HTTP是明文传输，所以会很有可能产生中间人攻击（获取并篡改传输在客户端及服务端的信息并不被人发觉），HTTPS加密应运而生。在HTTP之下增加一个安全层，其位于HTTP和TCP之间，更靠近应用层，作用是来加密解密。
本质：在客户端和服务器之间协商出⼀套对称密钥，每次发送信息之前将内容加密，收到之后解密，达到内容的加密传输。 用非对称加密来商讨出一套对称式密钥，再用这个对称密钥来通信。
为啥不直接用非对称加密通信？因为非对称加密效率低，速度慢。
实现流程:
客户端请求建立TLS连接 服务器发回证书 客户端验证服务器的证书 客户端新任服务器之后，和服务器协商对称密钥 最后使用对称密钥开始通信 最后一步才进入HTTP通信的范畴，前面均是TCP通信。
Client Hello 客户端跟服务器请求建立连接，附带告诉服务器，我所支持的TLS版本，还有Cipher Suite加密套件，里面是客户端支持的对称加密算法，非对称加密算法，Hash算法。同时还有一个随机数X。 Server Hello 服务器给客户端返回数据，选择好TLS版本，算法等。同时返回一个随机数Y。 服务器给客户端发送证书，里面核心是非对称加密的公钥，还有服务器的域名，地址，等信息，最后还有服务器的签名，对本次传输所有数据进行签名，表明确实是这个服务器所发。还有证书机构的公钥和证书机构的其他信息签名来对这个服务器的证明数据进行签名，即下图黄色机构对蓝色数据进行签名证明。但是只是可以说明数据确实是由这个公钥对应私钥的持有者所签发。还需要根证书机构的签名对证书机构的签名进行签名，即紫色根证书机构对黄色的证书机构进行签名证明。这个根证书机构的验证来自操作系统内部，到了这一层如果签名能对得上，就可以确定来源的可信了。
根证书的来源：在操作系统生产出的时候，被研发方所认证了的，级上方为一个信任链，到最底层的根证书列表就需要无条件信任。根证书机构很忙，需要一个中间机构去分担压力。
服务器证书验证就通过了。客户端浏览器拿到服务器公钥的时候，使用这个公钥加密一个信息： Pre-master Secret，这也是一个随机数。整个通信过程中唯一一次非对称加密来处理的数据。现在就有三个随机数了，X， Y， Pre-master Secret。前两个随机数X, Y大家都能看见，虽然是明文传输，但加上之后就可以使密钥更安全。现在双方就有足够的信息来生产一个对称加密的密钥了。即Master Secret。这个密钥实际上包含四个东西：客户端加密密钥，服务端加密密钥，客户端Hash Key，服务端Hash Key。HMAC：hash-based message authenticate code，改良版的Hash算法。虽然是对称加密，服务端和客户端之间的通信仍然是用不同的加密密钥来通信，客户端发送时使用客户端加密密钥来加密，服务端接收到之后，使用客户端密钥来解密。用作证明身份，双方都会用MAC Secret来作签名和验证。 双方作一次验证，看上面沟通的加密算法能不能用。 简要的连接建立过程：
Client Hello Server Hello 服务器证书 信任建⽴ Pre-master Secret 客户端通知：将使⽤加密通信 客户端发送：Finished 服务器通知：将使⽤加密通信 服务器发送：Finished 问题：如果另一个拥有合法证书的机构把消息拦截下来，而且也发生给客户端一份完整的ServerHello返给客户端，这样可以建立起HTTPS连接吗？ 客户端请求时，会将要访问的Host地址附加在报文里。同样，在服务端的证书包里，也会附加Host名。客户端收到之后，会对Host主机地址进行校验，只有两者域名一致才能通过验证继续往下建立连接。签发证书的机构会将证书和域名进行绑定。
安全性 非对称加密可以防范中间人攻击吗？
鉴于非对称加密的机制，我们可能会有这种思路：服务器先把公钥以明文方式传输给浏览器，之后浏览器向服务器传数据前都先用这个公钥加密好再传，这条数据的安全似乎可以保障了！因为只有服务器有相应的私钥能解开公钥加密的数据。
然而反过来由服务器到浏览器的这条路怎么保障安全？如果服务器用它的私钥加密数据传给浏览器，那么浏览器用公钥可以解密它，而这个公钥是一开始通过明文传输给浏览器的，若这个公钥被中间人劫持到了，那他也能用该公钥解密服务器传来的信息了。所以目前似乎只能保证由浏览器向服务器传输数据的安全性。用两组私钥公钥对即可解决。
所以我们证明了一组公钥私钥，至少可以确保单向的数据安全，那么我可不可以合理推断如果我有两组公钥私钥，那我就可以保证双向数据传输的安全了呢？
某网站服务器拥有公钥A与对应的私钥A’；浏览器拥有公钥B与对应的私钥B’。
浏览器把公钥B明文传输给服务器。
服务器把公钥A明文给传输浏览器。
之后浏览器向服务器传输的内容都用公钥A加密，服务器收到后用私钥A’解密。由于只有服务器拥有私钥A’，所以能保证这条数据的安全。
同理，服务器向浏览器传输的内容都用公钥B加密，浏览器收到后用私钥B’解密。 同上也可以保证这条数据的安全。
bingo！好像成功了！但是这个方法并没有被大范围推广，并且也不可能被大范围推广。很重要的原因是非对称加密算法非常耗时，而对称加密快很多。
好家伙，说来说去又回到对称加密了，合着你就非得用对称加密是吗？
对！就是要找一个方法，让客户端和服务端都知道那个公共密钥并且确保第三方不会获取，那我就是可以放心的使用对称加密传输数据了
对称加密和非对称加密的综合版本 某网站拥有用于非对称加密的公钥A、私钥A’
浏览器向网站服务器请求，服务器把公钥A明文给传输浏览器。
浏览器随机生成一个用于对称加密的密钥X，用公钥A加密后传给服务器。
服务器拿到后用私钥A’解密得到密钥X。
这样双方就都拥有密钥X了，且别人无法知道它。之后双方所有数据都通过密钥X加密解密即可。
成功！HTTPS基本就是采用了这种方案。
但是这并不是完美的，这仍然有漏洞喔！
对称加密和非对称加密的综合版本的漏洞 如果在数据传输过程中，中间人劫持到了数据，此时他的确无法得到浏览器生成的密钥X，这个密钥本身被公钥A加密了，只有服务器才有私钥A’解开它，然而中间人却完全不需要拿到私钥A’就能干坏事了。请看：
某网站有用于非对称加密的公钥A、私钥A’。 浏览器向网站服务器请求，服务器把公钥A明文给传输浏览器。 中间人劫持到公钥A，保存下来，把数据包中的公钥A替换成自己伪造的公钥B（它当然也拥有公钥B对应的私钥B’）。 浏览器生成一个用于对称加密的密钥X，用公钥B（浏览器以为是公钥A）加密后传给服务器。 中间人劫持后用私钥B’解密得到密钥X，再用公钥A加密后传给服务器（保证两方通信能顺利进行）。 服务器拿到后用私钥A’解密得到密钥X。 这样在双方都不会发现异常的情况下，中间人通过一套“狸猫换太子”的操作，掉包了服务器传来的公钥，进而得到了密钥X。根本原因是客户端浏览器无法确认收到的公钥是不是服务器发来的，因为公钥本身是明文传输的。
所以！我们只剩下最后一个问题，那就是怎么确保浏览器收到的公钥是网站的，而不是中间人的！
网站在使用HTTPS前，需要向CA机构申领一份数字证书，数字证书里含有证书持有者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书里获取公钥就行了，证书就如身份证，证明“该公钥对应该网站”。而这里又有一个显而易见的问题，“证书本身的传输过程中，如何防止被篡改”？
注意这个CA机构需要完全可信，他的证明需要是有效的。
服务器将自己的公钥，Hash后用服务器的私钥制作签名。再将CA机构的证书一同打包发送给客户端。
每次发送HTTPS请求都需要在TLS/SSL层进行握手传输密钥吗？
如果是的话，那也太浪费资源和时间了吧。
服务器会为每个浏览器（或客户端软件）维护一个session ID，在TLS握手阶段传给浏览器，浏览器生成好密钥传给服务器后，服务器会把该密钥存到相应的session ID下，之后浏览器每次请求都会携带session ID，服务器会根据session ID找到相应的密钥并进行解密加密操作，这样就不必要每次重新制作、传输密钥了！
在Android中使用时 一般都是正常用即可。
需要自己写证书验证过程的场景：
⽤的是⾃签名证书（例如只⽤于内⽹的 https） 证书信息不全，缺乏中间证书机构（可能性不⼤） ⼿机操作系统较旧，没有安装最新加⼊的根证书 TCP/IP模型是实际应用中广泛使用的网络分层架构，它将网络通信分为四个层次：
网络接口层：对应于OSI模型的物理层和数据链路层，负责将数据帧从一个网络节点传输到另一个网络节点。 网络层：与OSI模型的网络层功能相同，负责在不同网络之间进行路由选择和数据包转发。 传输层：与OSI模型的传输层功能相同，提供端到端的可靠数据传输服务。 应用层：对应于OSI模型的会话层、表示层和应用层，为用户提供各种网络应用服务。 网络分层架构的优点包括：
模块化设计：每个层次都有明确的功能和接口，便于设计、实现和维护。 独立性：各层次可以独立发展和更新，互不影响。 易于理解：分层架构使得网络通信的过程更加清晰和易于理解。 灵活性：可以根据需要在不同层次上添加或修改功能。 通过这种分层架构，网络通信变得更加有序和高效，不同层次的技术可以协同工作，为用户提供可靠的网络服务。
网络分层架构 为什么要分层？ 从客户端到服务器的各节点
网络不稳定，所以需要分层。
比如客户端往服务端发起请求的过程中，中间某个节点如果损坏，客户端需要知道信息没发过去，再次发起重传。 但是如果很大的数据，就会传很多次，原本50ms的时间，可能需要传2s才能完成。解决：把这个大的数据切成5块，这5块分别来传，先把能传成功的全部发过去，如果检索到某一块没有收到，再把对应的块给传过去，就只需要多发20%，效率比较高。
分层：有分块传输所以需要分层。上层通信协议众多，http, ftp, mqtt等都有这种分块的需求。所以把包的分发这个工作专门抽出来一层。上层不管传输了，他们只需要把所有要传的数据准备好，再丢给下层TCP去处理。
那么有TCP了，为什么还要往下拉一层？
TCP叫传输层，用来传东西，其注重数据完整性。
但是并不是所有数据我们都需要重传，比如CS枪战游戏数据，如果网络卡顿了，这个数据不能再重传了，只需要不断将最新的数据传输过去就行了。这种需求所产生的协议叫UDP，强调传输性能而不是传输的完整性。
这两种协议又都有网络的需求，都需要从一个主机找到另一个主机。
TCP现在也不去传了，只是将数据分块，并全部按顺序的传输，并检测。UDP也一样，只管分块，不用管传输完整性与顺序。
而下一层的IP只管闷头传，负责寻址，找路由，上层有什么东西丢下来就直接传过去。
阶段小结：这三层都是共同的目的，将数据从一个地方传到另一个地方。 分层原因都是网络不稳定 ，如果网络稳定，所有东西都可以一次性到达，那就不需要这么麻烦了。
数据链路层：这层就是实际的网络，以太网，比如网线，WIFI。其为网络提供显示的实质的支持。
另外还有七层网络模型，它把数据链路层分开了，数据链路层和物理层。物理层为网线，交换器。
具体的分层：
Application Layer 应⽤层：HTTP、FTP、DNS Transport Layer 传输层：TCP、UDP Internet Layer ⽹络层：IP Link Layer 数据链路层：以太⽹、Wi-Fi 对于应用层工程师来说，可以只关心这四层模型。
TCP连接 什么叫连接？
TCP是有状态的，他有很多小包需要发送。先建立起第一步通信，来共同确认数据传输包该怎么拼。
连接建立：
连接的关闭：
长连接 为什么需要长连接？ 首先了解内网，一个网关，其内部有很多的主机，某个主机需要和外部的主机通信，网关会先开一个端口，走这个端口和外界主机通信。内网的主机所占用的端口实际是网关的端口。例如，我们的手机网络都是运行在运营商的内网里面的。 长连接：网关给内部主机开端口通信，需要耗费资源的。当内部主机一段时间里没有进行数据通信，网关会把这个端口给关闭掉。那么过一会，当外部主机再走这个端口想要通信时，就连不上了，网路就断了。为了突破这个限制，让网关不去主动关掉这个端口，就需要定时地通信一次，这就是心跳，实现长连接的方式。网关发现这个端口一直在用，就不会将这个端口给关掉了。 长连接很复杂，需要了解的东西相当多，实现很难。
登录：身份认证，确认“你是你”，用户“把我的权限授予我自己” 授权：把权限授予用户，可以持有令牌
登录 Cookie和Authorization都是Headers里的内容。
Cookie 起源：购物车，在 NetScape 网景浏览器时期。某电商网站希望有购物车功能，现在的购物车数据是存在服务器的，当时的人希望将购物车数据存在客户端本地。那么即使浏览器开发者与网站开发者的身份，开发这个就非常方便。
流程：服务器希望你记住什么，就把这个发过来，并标记这个是需要保存在本地的。客户端就将这些数据存在本地。浏览器下次访问相关域的时候，客户端就会自动附加这些数据，服务器不需要再次发送。
移动开发中使用cookie非常少了。
服务器需要客户端保存的内容，放在 Set-Cookie headers ⾥返回，客户端会自动保存。 客户端保存的 Cookies ，会在之后的所有请求⾥都携带进 Cookie header ⾥发回给服务器。 客户端保存 Cookie 是按照服务器域名来分类的，例如 shop.com 发回的 Cookie 保存下来以后，在之后向 games.com 的请求中并不会携带。 客户端保存的 Cookie 在超时后会被删除、没有设置超时时间的 Cookie （称作 SessionCookie）在浏览器关闭后就会⾃动删除；另外，服务器也可以主动删除还未过期的客户端Cookies。
作用：一般都是客户端给自己作标记，服务器拿本地的 Cookie 来对比。HTTP是无状态的，使用这个机制可以让服务器标识不同的用户。例如会话管理，登录状态，购物车，用户偏好，分析用户行为。
用户tracking流程图：
XSS(Cross-site scripting) 跨站脚本攻击 如果Cookie里有用户关键信息，比如密码等。那么本地有恶意的JavaScript脚本的话，就可以将这些Cookie发走，窃取用户数据。 应对：在Header里加入HttpOnly关键字。那本地脚本就看不到这个Cookie了。
XSRF 跨站请求伪造 即在⽤户不知情的情况下访问 已经保存了 Cookie 的⽹站，以此来越权操作⽤户账户（例如盗取⽤户资⾦）。应对⽅式主要是 从服务器安全⻆度考虑，就不多说了。
Referer校验
Authoriztion Basic 使用的不多 格式：Authorization: Basic <username:password(Base64ed)> 有安全风险，用户名和密码相当于明文传输，万一被截获。
Bearer “持有者” 格式：Authorization: Bearer token需要找授权方取得
Oauth2 例如：使用github登录稀土掘金，第三方是掘金。即将授权的令牌授予给要用的第三方的网站。 流程：
第三⽅⽹站向授权⽅⽹站申请第三⽅授权合作，拿到 client id 和 client secret ⽤户在使⽤第三⽅⽹站时，点击「通过 XX (如 GitHub) 授权」按钮，第三⽅⽹站将⻚⾯跳转到授权⽅⽹站，并传⼊ client id 作为⾃⼰的身份标识 授权⽅⽹站根据 client id ，将第三⽅⽹站的信息和第三⽅⽹站需要的⽤户权限展示给⽤户，并询问⽤户是否同意授权 ⽤户点击「同意授权」按钮后，授权⽅⽹站将⻚⾯跳转回第三⽅⽹站，并传⼊ Authorization code 作为⽤户认可的凭证。 第三⽅⽹站客户端将 Authorization code（只是表明用户同意授权） 发送回第三方⾃⼰的服务器 第三方网站的服务器将 Authorization code 和⾃⼰的 client secret（第三方向授权方申请时附加的表明自己的身份） ⼀并发送给授权⽅的服务器，说用户已经同意了。注意这个secret是需要绝对安全的。授权⽅服务器在验证通过后，返回 access token给第三方的服务器。OAuth 流程结束。 在上⾯的过程结束之后，第三⽅⽹站的服务器（或者有时客户端也会）就可以使⽤授权的 access token 作为⽤户授权的令牌，向授权⽅⽹站发送请求来获取⽤户信息或操作⽤户账户。但这已经在 OAuth 流程之外。 可以看到，最大的好处就是token是保密的，只在两个服务器方进行交互，保证登录安全。
易混淆：第三方登录 我和掘金之间的登录操作，利用了github登录，那么github属于第三方。
例子：微信登录（第三方登录）
流程：
第三⽅ App 向腾讯申请第三⽅授权合作，拿到 client id 和 client secret 用户在使⽤第三⽅ App 时，点击「通过微信登录」，第三⽅ App 将使⽤微信 SDK 跳转到微信，并传⼊⾃⼰的 client id 作为⾃⼰的身份标识 微信通过和服务器交互，拿到第三⽅ App 的信息，并限制在界⾯中，然后询问⽤户是否同意授权该 App 使⽤微信来登录 ⽤户点击「使⽤微信登录」后，微信和服务器交互将授权信息提交，然后跳转回第三⽅App，并传⼊ Authorization code 作为⽤户认可的凭证 第三⽅ App 调⽤⾃⼰服务器的「微信登录」Api，并传⼊ Authorization code，然后等待服务器的响应。让服务器去和微信的服务器换取token。 服务器在收到登录请求后，拿收到的 Authorization code 去向微信的第三⽅授权接⼝发送请求，将 Authorization code 和⾃⼰的 client secret ⼀起作为参数发送，微信在验证通过后，返回 access token 服务器在收到 access token 后，⽴即拿着 access token 去向微信的⽤户信息接⼝发送请求，微信验证通过后，返回⽤户信息 服务器在收到⽤户信息后，在⾃⼰的数据库中为⽤户创建⼀个账户，并使⽤从微信服务器拿来的⽤户信息填⼊⾃⼰的数据库，以及将⽤户的 ID 和⽤户的微信 ID 做关联 ⽤户创建完成后，服务器向客户端的请求发送响应，传送回刚创建好的⽤户信息 客户端收到服务器响应，⽤户登录成功 与github授权登录没有区别，只是叫法与概念不同。也是微信把自己的token授权给第三方的网站使用。
自己的服务器 使用Bearer token（流程需要加深理解，与OAuth第三方授权的区别）
有的 App 会在 Api 的设计中，将登录和授权设计成类似 OAuth2 的过程，但简化掉Authorization code 概念。即：登录接⼝请求成功时，会返回 access token，然后客户端在之后的请求中，就可以使⽤这个 access token 来当做 bearer token 进⾏⽤户操作了。
就是一种简化版的OAuth授权，直接使用code和自家服务器换取token。
refresh token ⽤法：access token 有失效时间，在它失效后，调⽤ refresh token 接⼝，传⼊ refresh_token 来获取新的 access token。
{
"token_type": "Bearer",
"access_token": "xxxxx",
"refresh_token": "xxxxx",
"expires_time": "xxxxx"
}
⽬的：安全。当 access token 失窃，由于它有失效时间，因此坏⼈只有较短的时间来「做坏事」；同时，由于（在标准的 OAuth2 流程中）refresh token 永远只存在与第三⽅服务的服务器中，因此 refresh token ⼏乎没有失窃的⻛险。
背景 HTTP协议是Hyper Text Transfer Protocol（超文本传输协议）的缩写,是用于从万维网（WWW:World Wide Web ）服务器传输超文本到本地浏览器的传送协议。
HTTP是一个基于TCP/IP通信协议来传递数据（HTML 文件, 图片文件, 查询结果等）。
HTTP是一个属于 应用层 的面向对象的协议，由于其简捷、快速的方式，适用于分布式超媒体信息系统。它于1990年提出，经过几年的使用与发展，得到不断地完善和扩展。
HTTP协议工作于客户端-服务端架构为上。浏览器作为HTTP客户端通过URL向HTTP服务端即WEB服务器发送所有请求。Web服务器根据接收到的请求后，向客户端发送响应信息。
主要特点 简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。 灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。 无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。 无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。 支持B/S及C/S模式。 HTTP之URL HTTP使用统一资源标识符（Uniform Resource Identifiers, URI）来传输数据和建立连接。URL是一种特殊类型的URI，包含了用于查找某个资源的足够的信息
URL,全称是UniformResourceLocator, 中文叫统一资源定位符,是互联网上用来标识某一处资源的地址。以下面这个URL为例，介绍下普通URL的各部分组成：
http://www.aspxfans.com:8080/news/index.asp?boardID=5&ID=24618&page=1#name
从上面的URL可以看出，一个完整的URL包括以下几部分：
协议部分：该URL的协议部分为“http：”，这代表网页使用的是HTTP协议。在Internet中可以使用多种协议，如HTTP，FTP等等本例中使用的是HTTP协议。在”HTTP”后面的“//”为分隔符 域名部分：该URL的域名部分为“www.aspxfans.com”。一个URL中，也可以使用IP地址作为域名使用 端口部分：跟在域名后面的是端口，域名和端口之间使用“:”作为分隔符。端口不是一个URL必须的部分，如果省略端口部分，将采用默认端口 虚拟目录部分：从域名后的第一个“/”开始到最后一个“/”为止，是虚拟目录部分。虚拟目录也不是一个URL必须的部分。本例中的虚拟目录是“/news/” 文件名部分：从域名后的最后一个“/”开始到“？”为止，是文件名部分，如果没有“?”,则是从域名后的最后一个“/”开始到“#”为止，是文件部分，如果没有“？”和“#”，那么从域名后的最后一个“/”开始到结束，都是文件名部分。本例中的文件名是“index.asp”。文件名部分也不是一个URL必须的部分，如果省略该部分，则使用默认的文件名 锚部分：从“#”开始到最后，都是锚部分。本例中的锚部分是“name”。锚部分也不是一个URL必须的部分。锚的主要作用是在一个HTML文档中标识出一个特定的位置，这样当用户点击包含这个锚的链接时，浏览器就会直接滚动到文档中对应的位置。 参数部分：从“？”开始到“#”为止之间的部分为参数部分，又称搜索部分、查询部分。本例中的参数部分为“boardID=5&ID=24618&page=1”。参数可以允许有多个参数，参数与参数之间用“&”作为分隔符。 URI和URL的区别 URI，是uniform resource identifier，统一资源标识符，用来唯一的标识一个资源。
Web上可用的每种资源如HTML文档、图像、视频片段、程序等都是一个来URI来定位的。
URI一般由三部组成：
访问资源的命名机制 存放资源的主机名 资源自身的名称，由路径表示，着重强调于资源。 URL是uniform resource locator，统一资源定位器，它是一种具体的URI，即URL可以用来标识一个资源，而且还指明了如何locate这个资源。
URL是Internet上用来描述信息资源的字符串，主要用在各种WWW客户程序和服务器程序上，特别是著名的Mosaic。
采用URL可以用一种统一的格式来描述各种信息资源，包括文件、服务器的地址和目录等。URL一般由三部组成：
协议(或称为服务方式) 存有该资源的主机IP地址(有时也包括端口号) 主机资源的具体地址。如目录和文件名等 URN，uniform resource name，统一资源命名，是通过名字来标识资源，比如mailto:java-net@java.sun.com
URI是以一种抽象的，高层次概念定义统一资源标识，而URL和URN则是具体的资源标识的方式。
URL和URN都是一种URI。
笼统地说，每个 URL 都是 URI，但不一定每个 URI 都是 URL。这是因为 URI 还包括一个子类，即统一资源名称 (URN)，它命名资源但不指定如何定位资源。
上面的 mailto、news 和 isbn URI 都是 URN 的示例。
在Java的URI中，一个URI实例可以代表绝对的，也可以是相对的，只要它符合URI的语法规则。而URL类则不仅符合语义，还包含了定位该资源的信息，因此它不能是相对的。
在Java类库中，URI类不包含任何访问资源的方法，它唯一的作用就是解析。 相反的是，URL类可以打开一个到达资源的流。
HTTP之请求消息Request 客户端发送一个HTTP请求到服务器的请求消息包括以下格式：
请求行（request line）、请求头部（header）、空行和请求数据 四个部分组成。
请求行以一个方法符号开头，以空格分开，后面跟着请求的URI和协议的版本。 Get请求例子，使用Charles抓取的request：
GET /562f25980001b1b106000338.jpg HTTP/1.1
Host img.mukewang.com
User-Agent Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36
Accept image/webp,image/*,*/*;q=0.8
Referer http://www.imooc.com/
Accept-Encoding gzip, deflate, sdch
Accept-Language zh-CN,zh;q=0.8
第一部分：请求行，用来说明请求类型,要访问的资源以及所使用的HTTP版本. GET说明请求类型为GET， [/562f25980001b1b106000338.jpg] 为要访问的资源，该行的最后一部分说明使用的是HTTP1.1版本。
第二部分：请求头部，紧接着请求行（即第一行）之后的部分，用来说明服务器要使用的附加信息。从第二行起为请求头部，HOST将指出请求的目的地。User-Agent，服务器端和客户端脚本都能访问它，它是浏览器类型检测逻辑的重要基础。该信息由你的浏览器来定义,并且在每个请求中自动发送等等。
第三部分：空行，请求头部后面的空行是必须的。即使第四部分的请求数据为空，也必须有空行。
第四部分：请求数据也叫主体，可以添加任意的其他数据。这个例子的请求数据为空。
POST请求例子，使用Charles抓取的request：
POST / HTTP1.1
Host:www.wrox.com
User-Agent:Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)
Content-Type:application/x-www-form-urlencoded
Content-Length:40
Connection: Keep-Alive
name=Professional%20Ajax&publisher=Wiley
第一部分：请求行，第一行明了是post请求，以及http1.1版本。 第二部分：请求头部，第二行至第六行。 第三部分：空行，第七行的空行。 第四部分：请求数据，第八行。
请求头 请求头（Request Header）在HTTP通信中扮演着至关重要的角色，它为服务器提供了关于客户端请求的额外信息，帮助服务器更好地理解和处理请求。以下是请求头的一些主要作用：
传递元数据：请求头可以包含关于请求的各种元数据，如请求的方法（GET、POST等）、请求的目标资源（URL）、请求的协议版本（如HTTP/1.1）等。
身份验证：通过包含认证信息（如Authorization头部），客户端可以向服务器证明自己的身份，以便访问受保护的资源。
内容协商：客户端可以通过Accept、Accept-Encoding、Accept-Language等头部字段告知服务器自己能够接受的内容类型、编码方式和语言，服务器可以根据这些信息返回最合适的响应内容。
缓存控制：客户端可以通过Cache-Control、If-Modified-Since、If-None-Match等头部字段来控制缓存行为，减少不必要的网络传输。
会话管理：通过Cookie头部，客户端可以向服务器发送之前存储的会话信息，以便服务器识别用户并维护会话状态。
代理信息：请求头中可以包含关于客户端所使用的代理服务器的信息，如Via头部。
内容长度：Content-Length头部字段用于指示请求体的长度，帮助服务器正确处理请求。
内容类型：Content-Type头部字段用于指定请求体的媒体类型，如application/json、application/x-www-form-urlencoded等。
在移动端开发中，以下是一些最常用的请求头及其使用方法举例：
User-Agent：用于标识客户端的类型和版本，服务器可以根据这个信息返回适合移动端设备的内容。
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 14_4 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0.3 Mobile/15E148 Safari/604.1
Accept：用于指定客户端能够接受的内容类型。
Accept: application/json, text/plain, */*
Authorization：用于传递认证信息，通常用于访问需要身份验证的API。
Authorization: Bearer <token>
Content-Type：用于指定请求体的媒体类型。
Content-Type: application/json
Accept-Language：用于指定客户端能够接受的语言。
Accept-Language: zh-CN,zh;q=0.9
Cache-Control：用于控制缓存行为。
Cookie：用于发送之前存储的会话信息。
Cookie: session_id=abc123; user_id=12345
If-Modified-Since：用于检查资源是否在指定时间之后被修改过。
If-Modified-Since: Mon, 26 Jul 2021 12:00:00 GMT
这些请求头在移动端开发中经常被使用，它们帮助客户端和服务器之间进行有效的通信，确保请求和响应的正确处理。
请求数据 HTTP请求数据（也称为请求体或请求正文）在客户端向服务器发送请求时扮演着重要的角色。它包含了客户端希望发送给服务器的额外信息，这些信息通常是在请求方法（如POST、PUT等）中需要传递的数据。以下是HTTP请求数据的主要作用：
传递数据：请求数据允许客户端向服务器发送数据，这些数据可以是表单提交的数据、文件上传的数据、API调用的参数等。
更新资源：在使用PUT或PATCH请求方法时，请求数据用于更新服务器上的资源。
创建资源：在使用POST请求方法时，请求数据用于创建新的资源。
在移动端开发中，最常用的请求数据格式和类型包括：
JSON：JavaScript Object Notation，是一种轻量级的数据交换格式，易于阅读和编写，同时也易于机器解析和生成。它是移动端开发中最常用的数据格式之一，特别是在与RESTful API进行通信时。 {
"username" : "john.doe" ,
"password" : "secret123"
}
Form Data：表单数据是一种常见的请求数据格式，通常用于提交表单数据。在移动端开发中，表单数据通常用于用户登录、注册、提交表单等场景。 username=john.doe&password=secret123
Multipart Form Data：多部分表单数据是一种特殊的表单数据格式，用于上传文件。在移动端开发中，多部分表单数据通常用于上传图片、视频等文件。 Content-Disposition: form-data; name="file"; filename="example.jpg"
Content-Type: image/jpeg
<binary data>
XML：可扩展标记语言，是一种用于标记电子文件使其具有结构性的标记语言。虽然JSON在移动端开发中更为流行，但XML仍然在某些场景下被使用，特别是在与一些传统的Web服务进行通信时。 <user>
<username> john.doe</username>
<password> secret123</password>
</user>
Text：纯文本格式，通常用于发送简单的文本信息，如日志、错误消息等。
This is a sample text message.
这些请求数据格式在移动端开发中经常被使用，具体使用哪种格式取决于服务器端的API设计和客户端的需求。
HTTP之响应消息Response 一般情况下，服务器接收并处理客户端发过来的请求后会返回一个HTTP的响应消息。
HTTP响应也由四个部分组成，分别是：状态行、消息报头、空行和响应正文。
例子
HTTP / 1.1 200 OK
Date : Fri, 22 May 2009 06:07:21 GMT
Content-Type : text/html; charset=UTF-8
<html>
<head></head>
<body>
<!--body goes here-->
</body>
</html>
第一部分：状态行，由HTTP协议版本号，状态码，状态消息 三部分组成。第一行为状态行，（HTTP/1.1）表明HTTP版本为1.1版本，状态码为200，状态消息为（ok） 第二部分：消息报头，用来说明客户端要使用的一些附加信息。第二行和第三行为消息报头，Date:生成响应的日期和时间；Content-Type:指定了MIME类型的HTML(text/html)，编码类型是UTF-8 第三部分：空行，消息报头后面的空行是必须的。 第四部分：响应正文，服务器返回给客户端的文本信息。空行后面的html部分为响应正文。 HTTP之状态码 状态代码有三位数字组成，第一个数字定义了响应的类别，共分五种类别:
1xx：指示信息–表示请求已接收，继续处理 2xx：成功–表示请求已被成功接收、理解、接受 3xx：重定向–要完成请求必须进行更进一步的操作 4xx：客户端错误–请求有语法错误或请求无法实现 5xx：服务器端错误–服务器未能实现合法的请求 常见状态码：
200 OK //客户端请求成功
400 Bad Request //客户端请求有语法错误，不能被服务器所理解
401 Unauthorized //请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用
403 Forbidden //服务器收到请求，但是拒绝提供服务
404 Not Found //请求资源不存在，eg：输入了错误的URL
500 Internal Server Error //服务器发生不可预期的错误
503 Server Unavailable //服务器当前不能处理客户端的请求，一段时间后可能恢复正常
消息报头 HTTP响应中的消息报头（Response Headers）用于向客户端提供关于响应的附加信息。这些信息可以帮助客户端更好地理解和处理服务器返回的响应内容。消息报头通常包含了以下几种类型的信息。
内容类型和编码：例如Content-Type和Content-Encoding，用于指定响应体的媒体类型和编码方式。 缓存控制：例如Cache-Control、Expires和ETag，用于控制客户端和代理服务器如何缓存响应。 重定向和跳转：例如Location，用于指示客户端应该重定向到的新URL。 认证和授权：例如WWW-Authenticate和Set-Cookie，用于要求客户端进行身份验证或设置会话信息。 内容长度和范围：例如Content-Length和Content-Range，用于指示响应体的长度和范围。 跨域资源共享：例如Access-Control-Allow-Origin和Access-Control-Allow-Methods，用于控制跨域请求的访问权限。 常见的响应数据 HTTP响应中的响应正文（Response Body）包含了服务器返回给客户端的实际数据。这些数据可以是HTML页面、JSON对象、图像、音频、视频或任何其他类型的文件。响应正文的主要作用是向客户端提供请求的资源或数据。
在移动端开发中，最常见的HTTP响应正文类型包括：
HTML页面：用于在移动浏览器中显示网页内容。 <html>
<head>
<title> Example Page</title>
</head>
<body>
<h1> Welcome to Example Page</h1>
<p> This is an example HTML page.</p>
</body>
</html>
JSON数据：用于在移动应用中与后端API进行数据交互。 {
"message" : "Hello, World!" ,
"status" : "success"
}
图像文件：如JPEG、PNG或GIF格式的图片。 Content-Type: image/jpeg
<binary data>
音频文件：如MP3、AAC或WAV格式的音频。 Content-Type: audio/mpeg
<binary data>
视频文件：如MP4、WebM或AVI格式的视频。 Content-Type: video/mp4
<binary data>
文件下载：用于从服务器下载文件，如PDF、Word文档等。 Content-Disposition: attachment; filename="example.pdf"
Content-Type: application/pdf
<binary data>
纯文本文件：用于返回简单的文本信息，如日志、错误消息等。 This is a sample text message.
这些响应正文类型在移动端开发中经常被使用，具体使用哪种类型取决于客户端的请求和服务器的响应。
HTTP请求方法 根据HTTP标准，HTTP请求可以使用多种请求方法。
HTTP1.0定义了三种请求方法： GET, POST 和 HEAD方法。 HTTP1.1新增了五种请求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。
GET 请求指定的页面信息，并返回实体主体。
HEAD 类似于get请求，只不过返回的响应中没有具体的内容，用于获取报头
POST 向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。
PUT 从客户端向服务器传送的数据取代指定的文档的内容。
DELETE 请求服务器删除指定的页面。
CONNECT HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
OPTIONS 允许客户端查看服务器的性能。
TRACE 回显服务器收到的请求，主要用于测试或诊断。
HTTP工作原理 HTTP协议定义Web客户端如何从Web服务器请求Web页面，以及服务器如何把Web页面传送给客户端。HTTP协议采用了请求/响应模型。客户端向服务器发送一个请求报文，请求报文包含请求的方法、URL、协议版本、请求头部和请求数据。服务器以一个状态行作为响应，响应的内容包括协议的版本、成功或者错误代码、服务器信息、响应头部和响应数据。
以下是 HTTP 请求/响应的步骤：
1、客户端连接到Web服务器 一个HTTP客户端，通常是浏览器，与Web服务器的HTTP端口（默认为80）建立一个TCP套接字连接。例如，http://www.oakcms.cn。
2、发送HTTP请求 通过TCP套接字，客户端向Web服务器发送一个文本的请求报文，一个请求报文由请求行、请求头部、空行和请求数据4部分组成。
3、服务器接受请求并返回HTTP响应 Web服务器解析请求，定位请求资源。服务器将资源复本写到TCP套接字，由客户端读取。一个响应由状态行、响应头部、空行和响应数据4部分组成。
4、释放连接TCP连接 若connection 模式为close，则服务器主动关闭TCP连接，客户端被动关闭连接，释放TCP连接;若connection 模式为keepalive，则该连接会保持一段时间，在该时间内可以继续接收请求;
5、客户端浏览器解析HTML内容 客户端浏览器首先解析状态行，查看表明请求是否成功的状态代码。然后解析每一个响应头，响应头告知以下为若干字节的HTML文档和文档的字符集。客户端浏览器读取响应数据HTML，根据HTML的语法对其进行格式化，并在浏览器窗口中显示。
例如：在浏览器地址栏键入URL，按下回车之后会经历以下流程：
1、浏览器向 DNS 服务器请求解析该 URL 中的域名所对应的 IP 地址;
2、解析出 IP 地址后，根据该 IP 地址和默认端口 80，和服务器建立TCP连接;
3、浏览器发出读取文件(URL 中域名后面部分对应的文件)的HTTP 请求，该请求报文作为 TCP 三次握手的第三个报文的数据发送给服务器;
4、服务器对浏览器请求作出响应，并把对应的 html 文本发送给浏览器;
5、释放 TCP连接;
6、浏览器将该 html 文本并显示内容;
GET和POST请求的区别 GET请求
GET /books/?sex=man&name=Professional HTTP/1.1
Host: www.wrox.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
Gecko/20050225 Firefox/1.0.1
Connection: Keep-Alive
注意最后一行是空行
POST请求
POST / HTTP/1.1
Host: www.wrox.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
Gecko/20050225 Firefox/1.0.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 40
Connection: Keep-Alive
name=Professional%20Ajax&publisher=Wiley
差异一 地址栏 GET提交，请求的数据会附在URL之后（就是把数据放置在HTTP协议头中），以?分割URL和传输数据，多个参数用&连接；例如： login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0 %E5%A5%BD 。如果数据是英文字母/数字，原样发送，如果是空格，转换为+，如果是中文/其他字符，则直接把字符串用BASE64加密，得出如： %E4%BD%A0%E5%A5%BD，其中％XX中的XX为该符号以16进制表示的ASCII。
POST提交：把提交的数据放置在是HTTP包的包体中。上文示例中红色字体标明的就是实际的传输数据
因此，GET提交的数据会在地址栏中显示出来，而POST提交，地址栏不会改变
差异二 数据长度限制 传输数据的大小：首先声明：HTTP协议没有对传输的数据大小进行限制，HTTP协议规范也没有对URL长度进行限制。
而在实际开发中存在的限制主要有：
GET:特定浏览器和服务器对URL长度有限制，例如 IE对URL长度的限制是2083字节(2K+35)。对于其他浏览器，如Netscape、FireFox等，理论上没有长度限制，其限制取决于操作系统的支持。
因此对于GET提交时，传输数据就会受到URL长度的限制。
POST:由于不是通过URL传值，理论上数据不受限。但实际各个WEB服务器会规定对post提交数据大小进行限制，Apache、IIS6都有各自的配置。
差异三 安全性 POST的安全性要比GET的安全性高。比如：通过GET提交数据，用户名和密码将明文出现在URL上，因为(1)登录页面有可能被浏览器缓存；(2)其他人查看浏览器的历史纪录，那么别人就可以拿到你的账号和密码了，除此之外，使用GET提交数据还可能会造成Cross-site request forgery攻击。
4、Http get,post,soap协议都是在http上运行的
（1）get：请求参数是作为一个key/value对的序列（查询字符串）附加到URL上的查询字符串的长度受到web浏览器和web服务器的限制（如IE最多支持2048个字符），不适合传输大型数据集同时，它很不安全。
（2）post：请求参数是在http标题的一个不同部分（名为entity body）传输的，这一部分用来传输表单信息，因此必须将Content-type设置为:application/x-www-form-urlencoded。post设计用来支持web窗体上的用户字段，其参数也是作为key/value对传输。但是：它不支持复杂数据类型，因为post没有定义传输数据结构的语义和规则。
（3）soap：是http post的一个专用版本，遵循一种特殊的xml消息格式 Content-type设置为: text/xml 任何数据都可以xml化。
Http协议定义了很多与服务器交互的方法，最基本的有4种，分别是GET,POST,PUT,DELETE. 一个URL地址用于描述一个网络上的资源，而HTTP中的GET, POST, PUT, DELETE就对应着对这个资源的查，改，增，删4个操作。 我们最常见的就是GET和POST了。GET一般用于获取/查询资源信息，而POST一般用于更新资源信息.
总结 GET提交的数据会放在URL之后，以?分割URL和传输数据，参数之间以&相连，如EditPosts.aspx?name=test1&id=123456. POST方法是把提交的数据放在HTTP包的Body中.
GET提交的数据大小有限制（因为浏览器对URL的长度有限制），而POST方法提交的数据没有限制.
GET方式需要使用Request.QueryString来取得变量的值，而POST方式通过Request.Form来获取变量的值。
GET方式提交数据，会带来安全问题，比如一个登录页面，通过GET方式提交数据时，用户名和密码将出现在URL上，如果页面可以被缓存或者其他人可以访问这台机器，就可以从历史记录获得该用户的账号和密码。
学习文章基于豪哥的教程，源地址：
Android Framework
源码分区 Android 常用的四个分区：
System 分区 Vender 分区 Odm 分区 Product 分区 ARM + Android 这个行业，一个简化的普遍流程：
Google 开发迭代 AOSP + Kernel 芯片厂商，针对自己的芯片特点，移植 AOSP 和 Kernel，使其可以在自己的芯片上跑起来。 方案厂商（很多芯片厂商也扮演了方案厂商的角色），设计电路板，给芯片添加外设，在芯片厂商源码基础上开发外设相关软件，主要是驱动和 hal，改进性能和稳定性。 产品厂商，主要是系统软件开发，UI 定制以及硬件上的定制(添加自己的外设)，改进性能和稳定性. Google 开发的通用 Android 系统组件编译后会被存放到 System 分区，原则上不同厂商、不同型号的设备都通用。
芯片厂商和方案厂商针对硬件相关的平台通用的可执行程序、库、系统服务和 app 等一般放到 Vender 分区。（开发的驱动程序是放在 boot 分区的 kernel 部分）
到了产品厂商这里，情况稍微复杂一点，通常针对同一套软硬件平台，可能会开发多个产品。比如：小米 12s，小米12s pro，小米12s ultra 均源于骁龙8+平台。
每一个产品，我们称之为一个 Variant（变体）。
通常情况下，做产品的厂商在同一个硬件平台上针对不同的产品会从硬件和软件两个维度来做定制。
硬件上，产品 A 可能用的是京东方的屏，产品 B 可能用的是三星的屏；差异硬件相关的软件部分都会放在 Odm 分区。这样，产品 A 和产品 B 之间 Odm 以外的分区都是一样的，便于统一维护与升级。(硬件相关的软件共用部分放在 vendor 分区)
软件上，产品 A 可能是带广告的版本，产品 B 可能是不带广告的版本。这些有差异的软件部分都放在 Product 分区，这样产品 A 和产品 B 之间 Product 以外的分区都是一样的，便于统一维护与升级。(软件共用部分都放在 System分区)
总结一下，不同产品之间公共的部分放在 System 和 Vender 分区，差异的部分放在 Odm 和 Product 分区。
Product配置 在编译之前执行的 lunch 命令，所展示的那些列表，就是一个个不同的product。可以看到后缀大致有user，userdebug，eng三种。
区别如下：
用户模式 user
仅安装标签为 user 的模块 设定属性 ro.secure=1，打开安全检查功能 设定属性 ro.debuggable=0，关闭应用调试功能 默认关闭 adb 功能 打开 Proguard 混淆器 打开 DEXPREOPT 预先编译优化
用户调试模式 userdebug
安装标签为 user、debug 的模块 设定属性 ro.secure=1，打开安全检查功能 设定属性 ro.debuggable=1，启用应用调试功能 默认打开 adb 功能 打开 Proguard 混淆器 打开 DEXPREOPT 预先编译优化
工程模式 eng
安装标签为 user、debug、eng 的模块 设定属性 ro.secure=0，关闭安全检查功能 设定属性 ro.debuggable=1，启用应用调试功能 设定属性 ro.kernel.android.checkjni=1，启用 JNI 调用检查 默认打开 adb 功能 关闭 Proguard 混淆器 关闭 DEXPREOPT 预先编译优化
由于我使用的是谷歌官方的Pixel 5设备，所以所需的product已经在源码里面配置完毕了。
此设备配置文件在这个目录：
device/google_car/redfin_car
主要集成相关的配置文件：
#
# Copyright 2020 The Android Open Source Project
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
#
$(call inherit-product, device/google_car/common/pre_google_car.mk)
$(call inherit-product, device/google_car/redfin_car/device-redfin-car.mk)
$(call inherit-product-if-exists, vendor/google_devices/redfin/proprietary/device-vendor.mk)
$(call inherit-product-if-exists, vendor/google_devices/redfin/prebuilts/device-vendor-redfin.mk)
$(call inherit-product, device/google_car/common/post_google_car.mk)
PRODUCT_MANUFACTURER := Google
PRODUCT_BRAND := Android
PRODUCT_NAME := aosp_redfin_car
PRODUCT_DEVICE := redfin
PRODUCT_MODEL := Stephen_Car001
PRODUCT_PACKAGES += \
RedfinDemo \
hello \
hellojava \
Kugou \
Sougou \
BaiduMap \
Term \
Gemini \
Google \
busybox \
SystemAppDemo \
helloseandroid \
initscript
PRODUCT_BROKEN_VERIFY_USES_LIBRARIES := true
PRODUCT_PROPERTY_OVERRIDES := \
persist.sys.language=zh \
persist.sys.country=CN \
persist.sys.timezone=Asia/Shanghai
BOARD_SEPOLICY_DIRS += \
device/google_car/redfin_car/sepolicy
要自己定制，可以直接基于Google的源码改。
新定义一个product 如果是使用模拟器，直接跑X86_64的环境的话。就需要自己重新定义product。
针对我们选择的 aosp_x86_64-eng，我们主要关注以下几个文件：
/board/generic_x86_64/BoardConfig.mk ： 用于硬件相关配置
/product/AndroidProducts.mk 和 /product/aosp_x86_64.mk：用于配置 Product
BoardConfig.mk 用于定义和硬件相关的底层特性和变量，比如当前源码支持的 cpu 位数(64/32位)，bootloader 和 kernel, 是否支持摄像头，GPS导航等一些板级特性。主要和硬件相关，有一个基本的了解即可。一般很少改动。 AndroidProducts.mk 定义我们执行 lunch 命令时，打印的列表以及每个选项对应的配置文件 PRODUCT_MAKEFILES 用于引入产品的配置文件。 COMMON_LUNCH_CHOICES 用于添加 lunch 时的选项，选项的名字由两部分过程 产品名 + 构建模式： 产品名就是 PRODUCT_MAKEFILES 中引入的产品配置文件名去掉 .mk 后缀，例如 aosp_x86_64 构建模式有三种：用户模式 user、用户调试模式 userdebug 和工程模式 eng。在上面已经展示了它们的区别。 aosp_x86_64.mk：这个文件就是模拟器产品配置的主基地。 PRODUCT_USE_DYNAMIC_PARTITIONS := true
# The system image of aosp_x86_64-userdebug is a GSI for the devices with:
# - x86 64 bits user space
# - 64 bits binder interface
# - system-as-root
# - VNDK enforcement
# - compatible property override enabled
# This is a build configuration for a full-featured build of the
# Open-Source part of the tree. It's geared toward a US-centric
# build quite specifically for the emulator, and might not be
# entirely appropriate to inherit from for on-device configurations.
# GSI for system/product
$(call inherit-product, $(SRC_TARGET_DIR)/product/core_64_bit.mk)
$(call inherit-product, $(SRC_TARGET_DIR)/product/gsi_common.mk)
# Emulator for vendor
$(call inherit-product-if-exists, device/generic/goldfish/x86_64-vendor.mk)
$(call inherit-product, $(SRC_TARGET_DIR)/product/emulator_vendor.mk)
$(call inherit-product, $(SRC_TARGET_DIR)/board/generic_x86_64/device.mk)
# Enable mainline checking for excat this product name
ifeq (aosp_x86_64,$(TARGET_PRODUCT))
PRODUCT_ENFORCE_ARTIFACT_PATH_REQUIREMENTS := relaxed
endif
PRODUCT_ARTIFACT_PATH_REQUIREMENT_WHITELIST += \
root/init.zygote32_64.rc \
root/init.zygote64_32.rc \
# Copy different zygote settings for vendor.img to select by setting property
# ro.zygote=zygote64_32 or ro.zygote=zygote32_64:
# 1. 64-bit primary, 32-bit secondary OR
# 2. 32-bit primary, 64-bit secondary
# init.zygote64_32.rc is in the core_64_bit.mk below
PRODUCT_COPY_FILES += \
system/core/rootdir/init.zygote32_64.rc:root/init.zygote32_64.rc
# Product 基本信息
PRODUCT_NAME := aosp_x86_64
PRODUCT_DEVICE := generic_x86_64
PRODUCT_BRAND := Android
PRODUCT_MODEL := AOSP on x86_64
inherit-product 函数表示继承另外一个文件
$(call inherit-product, $(SRC_TARGET_DIR)/product/emulator_vendor.mk)
$(call inherit-product-if-exists, device/generic/goldfish/x86_64-vendor.mk)
在 Makefile 中可使用 “-include” 来代替 “include”，来忽略由于包含文件不存在或者无法创建时的错误提示（“-”的意思是告诉make，忽略此操作的错误。make继续执行）,如果不加-,当 include 的文件出错或者不存在的时候， make 会报错并退出。
-include $(TARGET_DEVICE_DIR)/AndroidBoard.mk
include 和 inherit-product 的区别：
假设 PRODUCT_VAR := a 在 A.mk 中, PRODUCT_VAR := b 在 B.mk 中。
如果你在 A.mk 中 include B.mk，你最终会得到 PRODUCT_VAR := b。
但是如果你在 A.mk inherit-product B.mk，你会得到 PRODUCT_VAR := a b。
并且 inherit-product 确保您不会两次包含同一个 makefile 。
添加product 在device目录下新建一个产品名：
Jelly/
└── Rice14
├── AndroidProducts.mk
├── BoardConfig.mk
└── Rice14.mk
BoardConfig.mk 包含了硬件芯片架构配置，分区大小配置等信息这里我们直接使用 aosp_x86_64 的 BoardConfig.mk 就行。BoardConfig.mk 拷贝自 build/target/board/generic_x86_64/BoardConfig.mk
Rice14.mk 拷贝自 build/target/product/aosp_x86_64.mk
其中的 if 语句需要注释掉，同时需要修改最后四行:
PRODUCT_USE_DYNAMIC_PARTITIONS := true
# The system image of aosp_x86_64-userdebug is a GSI for the devices with:
# - x86 64 bits user space
# - 64 bits binder interface
# - system-as-root
# - VNDK enforcement
# - compatible property override enabled
# This is a build configuration for a full-featured build of the
# Open-Source part of the tree. It's geared toward a US-centric
# build quite specifically for the emulator, and might not be
# entirely appropriate to inherit from for on-device configurations.
# GSI for system/product
$(call inherit-product, $(SRC_TARGET_DIR)/product/core_64_bit.mk)
$(call inherit-product, $(SRC_TARGET_DIR)/product/gsi_common.mk)
# Emulator for vendor
$(call inherit-product-if-exists, device/generic/goldfish/x86_64-vendor.mk)
$(call inherit-product, $(SRC_TARGET_DIR)/product/emulator_vendor.mk)
$(call inherit-product, $(SRC_TARGET_DIR)/board/generic_x86_64/device.mk)
# Enable mainline checking for excat this product name
#ifeq (aosp_x86_64,$(TARGET_PRODUCT))
PRODUCT_ENFORCE_ARTIFACT_PATH_REQUIREMENTS := relaxed
#endif
PRODUCT_ARTIFACT_PATH_REQUIREMENT_WHITELIST += \
root/init.zygote32_64.rc \
root/init.zygote64_32.rc \
# Copy different zygote settings for vendor.img to select by setting property
# ro.zygote=zygote64_32 or ro.zygote=zygote32_64:
# 1. 64-bit primary, 32-bit secondary OR
# 2. 32-bit primary, 64-bit secondary
# init.zygote64_32.rc is in the core_64_bit.mk below
PRODUCT_COPY_FILES += \
system/core/rootdir/init.zygote32_64.rc:root/init.zygote32_64.rc
# Overrides
PRODUCT_BRAND := Jelly
PRODUCT_NAME := Rice14
PRODUCT_DEVICE := Rice14
PRODUCT_MODEL := Android SDK built for x86_64 Rice14
AndroidProducts.mk 内容如下：
PRODUCT_MAKEFILES := \
$(LOCAL_DIR)/Rice14.mk
COMMON_LUNCH_CHOICES := \
Rice14-eng \
Rice14-userdebug \
Rice14-user
验证：
source build/envsetup.sh
lunch Rice14-eng
make -j16
emulator
集成脚本编写 mk文件 以下是一个简单的示例，展示了如何编写一个基本的Android.mk文件来编译一个C或C++库：
# 定义本地路径
LOCAL_PATH := $(call my-dir)
# 清除变量
include $(CLEAR_VARS)
# 定义模块名称
LOCAL_MODULE := mylibrary
# 定义源文件
LOCAL_SRC_FILES := \
file1.cpp \
file2.cpp \
file3.cpp
# 定义编译标志
LOCAL_CFLAGS := -Wall -Werror
# 定义链接库
LOCAL_LDLIBS := -llog
# 构建静态库
include $(BUILD_STATIC_LIBRARY)
LOCAL_PATH: 定义了当前Android.mk文件所在的目录。 LOCAL_PATH := $(call my-dir)
CLEAR_VARS: 清除所有之前定义的变量，以确保每个模块的编译都是独立的。 LOCAL_MODULE: 定义了要生成的模块名称。 LOCAL_SRC_FILES: 列出了所有要编译的源文件。 LOCAL_SRC_FILES := file1.c file2.c
LOCAL_CFLAGS: 定义了编译时的标志，如警告和错误处理。 LOCAL_CFLAGS := -Wall -Werror
LOCAL_LDLIBS: 定义了链接时需要的库。 LOCAL_C_INCLUDES：指定头文件目录。 LOCAL_C_INCLUDES := $(LOCAL_PATH)/include
include $(BUILD_STATIC_LIBRARY)
include：包含其他 Makefile 文件。 include $(LOCAL_PATH)/../SomeOther.mk
LOCAL_C_INCLUDES：指定头文件目录。 LOCAL_C_INCLUDES := $(LOCAL_PATH)/include
LOCAL_SHARED_LIBRARIES 和 LOCAL_STATIC_LIBRARIES：指定依赖的共享库或静态库。 LOCAL_SHARED_LIBRARIES := libutils libcutils
LOCAL_STATIC_LIBRARIES := libmylib
LOCAL_PRELINK_MODULE：指定模块是否需要预链接。 LOCAL_PRELINK_MODULE := false
LOCAL_PACKAGE_NAME：定义 APK 包的名称。 LOCAL_PACKAGE_NAME := MyApp
LOCAL_JAVA_LIBRARIES：指定依赖的 Java 库。 LOCAL_JAVA_LIBRARIES := android-support-v4
bp文件 Android.bp 文件使用类似 JSON 的语法，但有一些特定的扩展。以下是一些基本的语法规则：
模块定义：使用 module 关键字定义一个模块，后面跟着模块类型（如 cc_binary、java_library 等）和模块的属性。
属性赋值：属性使用键值对的形式，键和值之间用冒号 : 分隔。值可以是字符串、列表或嵌套的对象。
列表：列表使用方括号 [] 表示，列表中的元素用逗号 , 分隔。
嵌套对象：嵌套对象使用花括号 {} 表示，嵌套对象中的属性也使用键值对的形式。
示例： 以下是一个简单的 Android.bp 文件示例，定义了一个 C++ 可执行文件：
cc_binary {
name: "hello",
srcs: ["hello.cpp"],
cflags: ["-Werror"],
}
cc_binary：表示这是一个 C++ 可执行文件模块。 name：指定模块的名称，这里是 “hello”。 srcs：指定源文件列表，这里只有一个源文件 “hello.cpp”。 cflags：指定编译标志，这里是 “ -Werror”，表示将所有警告视为错误。 常见模块类型 cc_binary：C++ 可执行文件。 cc_library：C++ 库。 java_library：Java 库。 java_binary：Java 可执行文件。 android_app：Android 应用程序。
模块属性 不同类型的模块有不同的属性，但一些常见的属性包括：
name：模块的名称。 srcs：源文件列表。 cflags：编译标志。 ldflags：链接标志。 shared_libs：依赖的共享库列表。 static_libs：依赖的静态库列表。
系统签名制作 如果系统供应商和app是不同的开发人员，又想在系统app的上下文中进行应用的开发，就需要制作一系统签名文件，提供给app开发人员，这样app就可以在系统的环境下进行开发和调试了。
生成系统签名需要java的openssl工具，可以使用apt工具安装。
首先切到~/aaos/build/target/product/security目录下，应有如下文件：
stephen@CODE01:~/aaos/build/target/product/security$ ls
Android.bp fsverity-release.x509.der platform.jks shared.pk8 verity.x509.pem
Android.mk media.pk8 platform.p12 shared.x509.pem verity_key
README media.x509.pem platform.pem testkey.pk8
cts_uicc_2021.pk8 networkstack.pk8 platform.pk8 testkey.x509.pem
cts_uicc_2021.x509.pem networkstack.x509.pem platform.x509.pem verity.pk8
执行命令：
第一，生成platform.pem文件
openssl pkcs8 -inform DER -nocrypt -in platform.pk8 -out platform.pem
第二，将在目录下生成platform.p12文件。
其中，pass后的字段为签名密码password，name后字段为Keyalias，根据自己喜好设置。
openssl pkcs12 -export -in platform.x509.pem -out platform.p12 -inkey platform.pem -password pass:stephen -name stephen
第三，就是生成jks签名文件了。
其中-deststorepass后也会用到上一步设置的password字段。
keytool -importkeystore -deststorepass stephen -destkeystore platform.jks -srckeystore platform.p12 -srcstoretype PKCS12 -srcstorepass stephen
生成的platform.jks就是我们需要的系统签名了。
将这个签名文件部署到我们应用文件夹里，并在app应用级的gradle里进行配置：
release {
storeFile file('../platform.jks')
storePassword 'stephen'
keyAlias 'stephen'
keyPassword 'stephen'
}
之后在AndroidManifest文件里，设置android:sharedUserId="android.uid.system"和系统进程共享userid，就可以获取到系统权限了。
集成C程序 源码集成 在product的目录下，新建一个hello文件夹，用来放置源代码文件和编译脚本文件。
~/aaos/device/google_car/redfin_car/hello
# Android.bp
cc_binary{
name:"hello",
srcs:["hello.cpp"],
cflags:["-Werrors"],
}
hello . cpp
#include <cstdio>
int main (){
printf ( "hello world! \n " );
return 0 ;
}
最后在aosp_redfin_car.mk里面添加：
PRODUCT_PACKAGES += \
RedfinDemo \
···
hello \
集成C可执行文件 busybox介绍： busybox 是一个类 Unix 操作系统的工具箱，它提供了许多常用的命令，例如 ls、cp、rm 等。
一样的，提前新建一个prebuilt文件夹，用来放置可执行文件。
# Android.bp
cc_prebuilt_binary {
name: "busybox",
srcs: ["busybox-armv8l"],
product_specific: true,
}
第二个就是busybox的可执行文件了，busybox-armv8l
同样需要在aosp_redfin_car.mk里面加入编译的包。
集成Java程序 新建一个helloJava的文件夹。
# Android.bp
java_library {
name: "hellojava",
installable: true,
product_specific: true,
srcs: ["**/*.java"],
sdk_version: "current"
}
java文件放置在包里面，目录结构为：
helloJava/com/stephen/main/HelloJava.java
package com.stephen.main ;
public class HelloJava
{
public static void main ( String [] args )
{
System . out . println ( "Hello Java" );
}
}
apk的方式集成系统app apk文件形式集成 RedfinDemo是第一个项目，里面是一些调试使用的功能，版本信息罗列，app管理等。
# Amdroid.mk
LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := RedfinDemo
LOCAL_MODULE_CLASS := APPS
LOCAL_MODULE_TAGS := optional
LOCAL_BUILT_MODULE_STEM := package.apk
LOCAL_MODULE_SUFFIX := $(COMMON_ANDROID_PACKAGE_SUFFIX)
LOCAL_CERTIFICATE := PRESIGNED
LOCAL_PRIVILEGED_MODULE := true
LOCAL_VENDOR_MODULE := false
LOCAL_SRC_FILES := RedfinDemo.apk
LOCAL_OVERRIDES_PACKAGES := \
Calendar \
CalendarProvider \
Email \
Exchange2 \
Gallery2 \
HoloSpiralWallpaper \
HTMLViewer \
SharedStorageBackup \
SoundRecorder \
TelephonyProvider \
VideoEditor \
VoiceDialer \
VoicePlus \
Camera \
Clock \
Contacts \
include $(BUILD_PREBUILT)
LOCAL_OVERRIDES_PACKAGES 是一个列表，其中包含了要覆盖的系统应用程序的包名。当 RedfinDemo.apk 安装时，它会覆盖这些系统应用程序。
同样，需要在aosp_redfin_car.mk里面加入编译的包。
PARODUCT_PACKAGES += \
RedfinDemo \
···
源码方式集成系统app 首先，我们敲定包名为package="com.example.systemappdemo"
在product目录下新建一个SystemAppDemo文件夹，用来放置源码。
定义Android.bp脚本：
android_app {
name: "SystemAppDemo",
srcs: ["src/**/*.java"],
resource_dirs: ["res"],
manifest: "AndroidManifest.xml",
platform_apis: true,
privileged: true,
sdk_version: "",
//签名证书
certificate: "platform",
//依赖
static_libs: ["androidx.appcompat_appcompat",
"com.google.android.material_material",
"androidx-constraintlayout_constraintlayout"],
}
借助Android Studio，新建一个空项目，注意新建VIEW架构而不是Compose的。然后进行文件的复制。
将res文件夹完全复制到这个目录下 然后将AndroidManifest.xml文件复制到这个目录下。 最后将MainActivity.java文件，复制到: SystemAppDemo/src/com/example/systemappdemo/MainActivity.java
引入其他的库 当我们的系统 App 需要引入一个库的时候，通常会在 prebuilds 目录下查找：
androidx 相关库引入，先在 prebuilts/sdk/current/androidx 下寻找配置好的 bp 文件 其他库引入，先在 prebuilts/tools/common/m2 下寻找寻找配置好的 bp 文件 都没有，就得自己引入了 以recyclerView为例，在Android.bp文件中添加现成的源码：
android_library_import {
name: "androidx.recyclerview_recyclerview-nodeps",
aars: ["m2repository/androidx/recyclerview/recyclerview/1.1.0-alpha07/recyclerview-1.1.0-alpha07.aar"],
sdk_version: "current",
min_sdk_version: "14",
static_libs: [
"androidx.annotation_annotation",
"androidx.collection_collection",
"androidx.core_core",
"androidx.customview_customview",
],
}
三方app集成 有时候需要集成一些第三方的app，比如国内的输入法，影音媒体等软件。
拿到第三方的apk之后，直接在product目录下建立对应的目录，将apk放进去，然后配置mk文件，最后在aosp_redfin_car.mk里面加入编译的包。
注意大多数app都有专门的动态库文件，需要在编译时提取出来编译对应平台的so库。
以百度地图为例：
# Android.mk
LOCAL_PATH := $(call my-dir)
APK_NAME_FULL :=$(shell cd $(LOCAL_PATH); ls -A | grep apk)
APK_NAME :=$(shell echo $(APK_NAME_FULL) | sed 's/.apk//g')
$(warning --------------fullName=$(APK_NAME_FULL)---------------------name=$(APK_NAME))
define get-all-libraries-module-name-in-subdirs
$(sort $(shell cd $(LOCAL_PATH) ; rm -rf lib >/dev/null ; unzip $(APK_NAME_FULL) 'lib/*.so' -d . >/dev/null ; find -L $(1) -name "*.so"))
endef
ALL_LIBRARIES_MODULE_NAME := $(call get-all-libraries-module-name-in-subdirs, lib/arm64-v8a)
$(warning ALL_LIBRARIES_MODULE_NAME:--- $(ALL_LIBRARIES_MODULE_NAME) )
#integrate the apk
include $(CLEAR_VARS)
LOCAL_MODULE := BaiduMap
LOCAL_MODULE_TAGS := optional
LOCAL_MODULE_CLASS := APPS
LOCAL_CERTIFICATE := PRESIGNED
LOCAL_MODULE_SUFFIX := .apk
LOCAL_SRC_FILES := $(APK_NAME_FULL)
LOCAL_PRIVILEGED_MODULE := true
LOCAL_VENDOR_MODULE := false
LOCAL_MODULE_PATH := $(TARGET_OUT_SYSTEM_APPS)
LOCAL_PREBUILT_JNI_LIBS := $(ALL_LIBRARIES_MODULE_NAME)
include $(BUILD_PREBUILT)
背景 学习C++之余，想把原生AOSP的开机动画给更新替换下，换换口味。
我们都知道，AOSP的默认开机动画是一个“ANDROID”的字样，配合一个渐变的底色动画。定制一个自己的开机动画，对于手机厂商来说，有利于宣传品牌，彰显企业文化。
像国内广为人知的定制系统，比如MIUI，ColorOS，FlymeOS等，都是没有直接使用默认动画的，定制了一套他们自己厂商的开机动画。而考虑到大厂都是人力充足，设计师，动效师，应有尽有。
那像我这自己在下面玩玩源码的，没有设计师帮忙，该怎么搞一套看得过去的定制化的开机动画呢？
开始制作 从压缩包制作倒推流程 首先经过调研了解到，我们如果想要自己定制Android的开机动画，需要准备一个名为bootanimation.zip的压缩包，去替换系统默认的动画。
那压缩包里放什么文件呢？
zip包里面的文件格式一般比较固定：
disc.txt，用来描述帧动画的播放策略和显示大小。 若干个文件夹，里面是按照顺序命名的帧动画文件。 像我的就是下面这个结构：
disc.txt 这个文件里的内容格式也比较简单：
第一排364 830 15，依次表示：开机动画显示区域heiht高度364，width宽度830，帧数15
后面可以设置多行不同表现形式的动画，这里我设置一个简单动画，只有一行p 1 0 part0 ，首个字母表示动画播放的时段，有三种方案可选：
p -- this part will play unless interrupted by the end of the boot
c -- this part will play to completion, no matter what
f -- same as p but in addition the specified number of frames is being faded out while continue playing. Only the first interrupted f part is faded out, other subsequent f parts are skipped
p 就表示直接全程播放，直到开机完成。第二位的 1 表示播放一次，如果是 0 就是循环播放。
第三位的0表示每两帧图片之间时间间隔为 0 ms，
最后的part0表示需要展示的这些帧动画在这个文件夹中。
注意：最后需要留出一个空行，编辑时需要注意。
文件写法明确了。难点在于，没有UI设计师帮忙，如何搞到这些帧动画呢？
帧动画的制作 直接先展示制作路线：
Android应用里手动写一个简单的渐亮动画——>录屏——>MP4转PNG
我准备在Android应用里手写一个动画，在想办法转成png。
设计上力求简洁，我使用“Stephen OS”作为文案，也是做一个渐亮的表现形式。
方案定下来了，接下来随便新建一个demo项目。我找到一个免费字体Cooper Black，到应用xml里添加TextView控件，设置字体fontFamily:
<TextView
android:id= "@+id/tv_animationtext"
android:layout_width= "wrap_content"
android:layout_height= "wrap_content"
android:fontFamily= "@font/cooper_black"
android:rotation= "90"
android:alpha= "0"
android:text= "Stephen OS"
android:textColor= "@color/white"
android:textSize= "88sp"
app:layout_constraintBottom_toBottomOf= "parent"
app:layout_constraintEnd_toEndOf= "parent"
app:layout_constraintStart_toStartOf= "parent"
app:layout_constraintTop_toTopOf= "parent" />
因为我是Pixel 5手机上刷的AOSP车机系统，所以开机时的屏幕方向还是vertical方向的，而我需要让其横向展示，所以在这个控件放置时直接旋转了90度。而且初始的透明度为0.
然后在Activity里准备写逻辑，顺手在工具类里写一个顶层扩展方法，给Activity设置强制全屏：
fun AppCompatActivity . setFullScreenMode () {
val layoutParams = window . attributes
layoutParams . layoutInDisplayCutoutMode =
WindowManager . LayoutParams . LAYOUT_IN_DISPLAY_CUTOUT_MODE_SHORT_EDGES
window . attributes = layoutParams
window . setFlags (
WindowManager . LayoutParams . FLAG_FULLSCREEN ,
WindowManager . LayoutParams . FLAG_FULLSCREEN
)
val uiOptions = ( View . SYSTEM_UI_FLAG_HIDE_NAVIGATION
or View . SYSTEM_UI_FLAG_IMMERSIVE_STICKY or View . SYSTEM_UI_FLAG_FULLSCREEN )
window . decorView . systemUiVisibility = uiOptions
}
动画编码为求简洁迅速，没有用传统的ValueAnimator，而是直接协程里使用repeat加delay，这种写法相当简单粗暴。
val logoText = rootView . findViewById < TextView >( R . id . tv_animationtext )
MainScope (). launch {
delay ( 2000L )
repeat ( 255 ) {
delay ( 7 )
infoLog ( it . toString ())
logoText . alpha = ( it / 255.0 ). toFloat ()
}
}
然后开启录屏软件，减去首尾多余部分，得到一个纯净的MP4，就是预设的开机动画了。
最后用到这样一个网站，可以将MP4转为png：Video to PNG image sequence converter
得到png后我们下载到本地，批量重命名成顺序的格式。将其放置到part0的文件夹中。准备和disc.txt一起打包。这里有一个坑，不可以直接用7zip打包成zip，最好使用winrar，压缩方式要选择存储：
集成到源码 压缩完成后，我们将bootanimation.zip放置到源码的某一个文件夹中。然后在你设备product的mk文件中，随意一个位置，加一句文件复制的指令：
PRODUCT_COPY_FILES += \
<path-to-your-bootanimation.zip>:system/media/bootanimation.zip
含义为在打包时，将这个zip包复制到ROM的system/media文件夹下。
设备开机后android系统会检索这个文件夹下有没有名为bootanimation.zip的文件，有的话就优先播这个动画替换默认的开机动画。
Pixel5使用体验 去年2022年中的时候网购了一台Pixel5的库存机，现在闲置成备用机了。
之所以有这个在手机上跑车机的想法，是因为笔者是车机Android应用层开发，想着谷歌手机原生支持那么好，能不能整一个Google Automotive的车机系统上去跑跑，顺便还可以学习学习AOSP源码、系统编译、系统apk集成、权限管理、CarService服务等等。
一看官方网站居然还真有定制，而且目前恰好支持Pixel4a和Pixel5，另外还有Pixel6，但是是Experimental实验性的，拿6代设备的朋友整活有风险。
2024-12-31更新：目前已经支持到了Pixel8手机
废话不多说，开始正经的经验记录！
系统环境准备 首先最低硬盘控件需要准备300G，低于这个数就很危险了。
打开Windows功能 注意Google的AOSP开源项目，谷歌宣称其开发和调试均是在Ubuntu14上进行的。强烈建议开发者也需要使用Ubuntu系统进行AOSP源码的拉取和编译。
不想把自己电脑刷成Ubuntu系统的话，也可以使用windows上的wsl虚拟机，这个也是需要win10及以上可以使用，直接通过微软Microsoft应用商店搜索Ubuntu即可下载安装。注意安装之前要在控制面板的“程序和功能”里打开“windows子系统选项”，重启系统后生效。
WSL迁移其他盘与空间扩展 安装完成后，进行简单的username用户名和password设置就可以进入系统了，啊，还是熟悉的terminal指令。然后下一步我们需要将这个子系统的位置从C盘移出去。
因为安装位置默认在C盘，而一份源码下载和编译后至少需要300G的空间，所以为了windows系统的流畅运行，我们最好不要将其挤在C盘，使用工具将其迁移到其他盘下面。为了完成这个操作，我们需要下载一个第三方工具 LxRunOffline，这个是由国人开发的 WSL 工具，其可以弥补官方工具的不足，比如说他可以实现将任何发行版的 Linux 以 WSL 形式安装到 Windows 10 中，增强 WSL 发行版管理功能，甚至可以实现 WSL 系统备份和恢复，这样无论是学习 Linux 还是进行开发工作都要比以往操作更为方便。
# 以管理员权限打开PowerShell，首先关闭wsl虚拟机
wsl --shutdown
#切到LxRunOfflin目录下，查看系统里wsl有哪些
.\LxRunOffline.exe list
#迁移wsl,需要十几分钟，完成后会生成虚拟硬件磁盘ext4.vhdx文件
.\LxRunOffline.exe move -n Ubuntu-20.04 -d f:\wsl_ubuntu20
#迁移完成,查看迁移后路径
.\LxRunOffline.exe get-dir -n Ubuntu-20.04
完成后还有一个问题，WSL默认只支持最大256G的硬盘空间，我们下载源码编译后很有可能就会超过256G，那么WSL就会报错，编译等操作也会中断。想要将WSL的最大硬盘空间突破这个限制，需要通过扩展 VHD 大小来解决：
#关闭wsl
wsl --shutdown
#查看wsl版本
wsl -l -v
NAME STATE VERSION
* Ubuntu-20.04 Stopped 2
#进入disk命令行
diskpart
#选择虚拟磁盘
DISKPART> Select vdisk file=f:\wsl_ubuntu20\ext4.vhdx
#查看VHD的详细信息
DISKPART> detail vdisk
#扩展vdisk空间，xxx为空间大小，以MB为单位，默认为256000,我拓展到了1000000
DISKPART> expand vdisk maximum=xxx
#退出DISKPART，进入wsl
DISKPART> exit
$wsl
#查看分区
$df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sdb 251G 991M 238G 1% /
tools 200G 53G 148G 27% /init
none 4.9G 0 4.9G 0% /dev
tmpfs 4.9G 0 4.9G 0% /sys/fs/cgroup
none 4.9G 4.0K 4.9G 1% /run
...
#在wsl中操作，使wsl知道磁盘大小限制已经更改
$sudo mount -t devtmpfs none /dev
# 将none挂载到/dev目录下，若返回'mount: /dev: none already mounted on /dev.'，可忽略
$mount | grep ext4
# 得到none挂载到/dev目录下的磁盘路径名
# 本句命令返还的信息 '/dev/sdX' 即为磁盘路径名,X可能是a,b,c等,xxx为前面分配的vhd大小，M为MB单位
$ sudo resize2fs /dev/sdb 1000000M
resize2fs 1.44.1 (24-Mar-2018)
Filesystem at /dev/sdb is mounted on /; on-line resizing required
old_desc_blocks = 32, new_desc_blocks = 123
The filesystem on /dev/sdb is now 256000000 (4k) blocks long.
# 重新查看分区配置
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sdb 961G 1000M 918G 1% /
tools 200G 53G 148G 27% /init
none 4.9G 0 4.9G 0% /dev
WSL拉取同步Android源码 上面WSL移出C盘和硬盘空间扩展完成之后，Ubuntu环境准备完成，即可开始Android源码的拉取了，注意拉代码前一定要提前下载这些辅助工具，以免正式开始后缺工具，手忙脚乱。
代码拉取前的程序安装 注意不要习惯性的将Ubuntu换源阿里或者中科大，我们直接使用WSL上自带的默认软件源，否则有些官方工具的安装会产生链式依赖问题，在Ubuntu18及以上终端输入：
sudo apt-get install git-core gnupg flex bison build-essential zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 libncurses5 lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z1-dev libgl1-mesa-dev libxml2-utils xsltproc unzip fontconfig
另外别忘了安装java，后面编译，还有开发系统应用生成Android系统platform签名，需要用到java的keytool工具。
sudo apt install oracle-java8-installer
WSL不可使用adb，刷机流程更改 使用wsl的话，我们虽然可以使用usbipd这个工具来配置，访问windows电脑连接的usb设备，但是不可以识别手机，也不可以在wsl上使用adb进行调试刷机。所以我最终采用的方案是Ubuntu编译，将编译产物同步到windows，再在windows上连接手机，最后进行设备刷写推送。
# 这个目录就是windows的文件夹在wsl的挂载同步，可以以此作为两个系统的文件同步区域
cd mnt/d/Pixel5
# 复制编译产物到Windows下的文件夹
cp -r /aaos/build/product/XXXX /mnt/d/Pixel5
使用repo进行源码拉取同步 首先明确一点，Pixel 5手机其支持的车机版本只有一个，我们必须使用 Android 12，和build SP1A.210812.016.A1，对应AOSP分支为 android-12.0.0_r3
Android的AOSP源码使用repo来进行版本管理，repo是Google开发的用于管理Android版本库的一个工具，repo是使用Python对git进行了一定的封装，并不是用于取代git，它简化了对多个Git版本库的管理。用repo管理的版本库都需要使用git命令来进行操作。
下载repo工具：
mkdir ~/bin
PATH=~/bin:$PATH
curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
chmod a+x ~/bin/repo
建议在home的个人文件夹下，建立放置源码的工作目录，一开机ls就是它了：
# 新建文件夹
mkdir aaos_on_phone
# 切换工作目录
cd aaos_on_phone
为了下载速度能拉满，我没有使用谷歌的官方仓库来拉取同步代码，而是改为使用清华大学的镜像网站，内容是相同的：清华大学开源软件镜像站 | Tsinghua Open Source Mirror 打开后，可以看到第一个就是AOSP项目。
在新建好的工作目录下，使用如下命令通过repo工具拉取AOSP源码，笔者没有WI-FI，直接使用手机流量来硬刚的，大概需要70个G左右，耗时2小时。
# 初始化repo仓库，拉取某一个特定的分支
repo init -u https://mirrors.tuna.tsinghua.edu.cn/git/AOSP/platform/manifest -b android-12.0.0_r3
# 开始同步拉取代码
repo sync
经过漫长的等待之后，打开工作目录，应该是下面的目录结构，因为我已经编译过，还加入了设备build文件，所以会多一点东西：
特定设备的二进制文件下载解包 源码拉取完成后，需下载特定设备的专有二进制文件和补丁程序，在如下网站找到对应设备与安卓版本的二进制包Nexus 和 Pixel 设备的驱动程序二进制文件 | Google Play services | Google for Developers
对于Pixel 5，需要找到：适用于 Android 12.0.0 (SP1A.210812.016.A1) 的 Pixel 5 二进制文件。
下载完毕之后，将此文件copy到源码目录进行解压：
# 复制供应商映像和高通的驱动二进制文件到源码目录
cp mnt/d/Downloads/extract-google_devices-redfin.sh /home/stephen/aaos
cp mnt/d/Downloads/extract-qcom-redfin.sh /home/stephen/aaos
# 解压缩两个文件
curl --output - https://dl.google.com/dl/android/aosp/google_devices-redfin-sp1a.210812.016.a1-8813b219.tgz | tar -xzvf -
tail -n +315 extract-google_devices-redfin.sh | tar -zxvf -
curl --output - https://dl.google.com/dl/android/aosp/qcom-redfin-sp1a.210812.016.a1-8d32b5b1.tgz | tar -xzvf -
tail -n +315 extract-qcom-redfin.sh | tar -xzvf -
开始编译源码 WSL运行内存分配 源码和设备二进制文件准备完成后，可能有的朋友就按耐不住要开始编译了，其实还有很重要的一个步骤。
源码的编译是非常非常耗性能的，特别是内存，默认分配的是物理机一半的运行内存，对于编译源码是不太够的，所以我们要对WSL子系统进行一些特殊的性能配置，在个人用户文件夹下，新建一个 .wslconfig 文件，里面配置的字段含义可以参考微软官方文档：WSL 中的高级设置配置 | Microsoft Learn
[wsl2]
# Limits VM memory to use no more than 24 GB, this can be set as whole numbers using GB or MB
memory=24GB
# Sets the VM to use 6 virtual processors
processors=6
# Sets amount of swap storage space to 8GB, default is 25% of available RAM
swap=0
# Turn on default connection to bind WSL 2 localhost to Windows localhost
localhostForwarding=true
# 一些实验性的配置
# Enable experimental features
[experimental]
autoMemoryReclaim=gradual
networkingMode=mirrored
dnsTunneling=true
firewall=true
autoProxy=true
配置完成后，笔者电脑是32G内存，核显显存分出去1个G，虚拟机分配24G，合理设置保证性能同时不会使windows系统其他功能可用内存太局促。
切换到wsl的源码目录，准备开始编译。
launch起编系统 名词解释：
Makefile → Android平台编译系统，用Makefile写出来的一个独立项目，定义了编译规则，实现自动化编译，将分散在数百个Git库中的代码整合起来，统一编译，而且把产物分门别类地输出到一个目录，打包成手机ROM，还可以生成应用开发时使用的SDK、NDK等。 Android.mk → 定义一个模块的必要参数，使模块随着平台编译，简单点说就是告诉系统以什么规则编译源代码，并生成对应目标文件； kati → Google专门为Android研发的小工具，基于Golang和C++，作用是：将Android中的Makefile转换为Ninja文件 Ninja → 致力于速度的小型编译系统，把Makefile看做高级语言，那它就是汇编，文件后缀为.ninja； Android.bp → 替换Android.mk的配置文件； Blueprint → 解析Android.bp文件翻译成Ninja语法文件； Soong → Makefile编译系统的替代品，负责解析Android.bp文件，并将之转换为Ninja文件； 起编的命令不多，只有两三行：
# 预声明环境命令
. build/envsetup.sh
# 编译Pixel系统，target选择aosp_redfin_car
lunch <target>
# 开始make编译，新版上直接一个m即可
m
# 构建与汽车相关的软件包
m android.hardware.automotive.audiocontrol@1.0-service android.hardware.automotive.vehicle@2.0-service
每次开始编译开始的第一个命令便是. build/envsetup.sh。在文件envsetup.sh声明了当前会话终端可用的命令，这里需要注意的是当前会话终端，也就意味着每次新打开一个终端都必须再一次执行这些指令。build/envsetup.sh文件存在的意义就是，设置一些环境变量和shell函数为后续的编译工作做准备。
而后的lunch操作执行的其实就是build/envsetup.sh脚本中的lunch函数，选择一个版本进行编译，一般可选user，userdebug，eng三种版本，其上的权限是逐步升级的。如果launch后没有参数，那么会出现一列版本可供选择，选择对应版本前的数字即可。
最后m开始起编，过程很长，笔者第一次编译晚上11点开始，等了两小时才到40%，于是放下电脑睡觉去，早上醒来就编完了。在编译过程中，以前只在论坛文章里看到的那些类，现在全部在命令行里一个个闪现出来参与编译，站在上层应用开发者的角度来看，就很神奇。
源码单编某个模块 除了系统整体进行编译，我们也可以对单个应用模块进行编译，编完的apk可以push推送到系统对应文件夹下，完成单个模块的置换。
source build/envsetup.sh
lunch aosp_bonito-eng
#进入模块目录
cd package/apps/Setting
#编译单独模块的可选指令如下：
#mm → 编译当前目录下的模块，不编译依赖模块
#mmm → 编译指定目录下的模块，不编译依赖模块
#mma → 编译当前目录下的模块及其依赖项
#mmmma → 编译指定路径下所有模块，切包含依赖
mm
#编译成功会提示生成文件的存放路径，除了生成Setting.odex外，还会在
#priv-app/Settings目录下生成Settings.apk，可直接adb push或adb install
#安装APK验证效果，也可以使用make snod命令重新打包生成system.img，运行模拟器查看
开始刷机流程 AOSP编译产物 经过make编译后的产物，都位于源码的 /out目录 ，该目录下我们主要关注下面几个目录：
/out/host：Android开发工具的产物，包含SDK各种工具，比如adb，dex2oat，aapt等。 /out/target/common：通用的一些编译产物，包含Java应用代码和Java库； /out/target/product/[product_name]：针对特定设备的编译产物以及平台相关C/C++代码和二进制文件； 在/out/target/product/[product_name]目录下，有几个重量级的镜像文件：
system.img:挂载为根分区，主要包含Android OS的系统文件； ramdisk.img:主要包含init.rc文件和配置文件等； userdata.img:被挂载在/data，主要包含用户以及应用程序相关的数据； 当然还有boot.img，reocovery.img等镜像文件，这里就不介绍了。 查看/aaos/out/target/product/redfin文件夹下关于Pixel 5设备特定的文件：
stephen@CODE01:~/aaos/out/target/product/redfin$ ls
android-info.txt misc_info.txt
apex module-info.json
appcompat module-info.json.rsp
boot-debug.img obj
boot-test-harness.img obj_arm
boot.img previous_build_config.mk
bootloader.img product
build_fingerprint.txt product.img
build_thumbprint.txt radio.img
clean_steps.mk ramdisk
data ramdisk-debug.img
debug_ramdisk ramdisk-test-harness.img
dexpreopt_config ramdisk.img
dtb.img recovery
dtbo.img root
fake_packages super_empty.img
gen symbols
installed-files-product.json system
installed-files-product.txt system.img
installed-files-ramdisk-debug.json system_ext
installed-files-ramdisk-debug.txt system_ext.img
installed-files-ramdisk.json system_other
installed-files-ramdisk.txt system_other.img
installed-files-recovery.json test_harness_ramdisk
installed-files-recovery.txt testcases
installed-files-root.json userdata.img
installed-files-root.txt vbmeta.img
installed-files-system-other.json vbmeta_system.img
installed-files-system-other.txt vendor
installed-files-system_ext.json vendor.img
installed-files-system_ext.txt vendor_boot-debug.img
installed-files-vendor-ramdisk-debug.json vendor_boot-test-harness.img
installed-files-vendor-ramdisk-debug.txt vendor_boot.img
installed-files-vendor-ramdisk.json vendor_debug_ramdisk
installed-files-vendor-ramdisk.txt vendor_ramdisk
installed-files.json vendor_ramdisk-debug.img
installed-files.txt vendor_ramdisk.img
kernel
确认无问题后，我把整个文件夹全部转到mnt挂载的windows目录下，准备好手机设备后即可刷写了。
cp -r ~/aaos/out/target/product/redfin /mnt/d/Pixel5
设置设备，刷写镜像文件 首先打开pixel 5的开发者选项里的USB调试模式，也需要打开OEM锁：
adb reboot bootloader
fastboot flashing unlock
在编译产物的文件夹，执行以下指令。开始清空设备数据，刷写车机系统，完成后推送汽车相关文件：
# 这些命令也可以制作成sh脚本，每次刷完机都执行一遍即可，免去手动输入
# 等刷写完毕并主屏幕显示后，再推送汽车专用文件
adb root
adb remount
adb reboot
# 每次刷写新系统都需要执行上面三步，使文件系统重新挂载生效
# 就可以使windows的shell获取root权限
adb root
adb remount
adb sync vendor
adb reboot
等手机再次reboot重启后就是下面的动画和launcher界面了：
后续 刷完了系统，不光是走完了一次体验，还需要找到可以学习的角度，深入改动系统代码，通过定制系统，达到需要的效果。
原文链接：
Kotlin Language Documentation 2.2.0
查漏补缺 lambda作为函数参数类型 这个操作平时使用较少，将lambda作为返回参数类型的场景。例如：
val upperCaseString : ( String ) -> String = { text -> text . uppercase () }
fun main () {
println ( upperCaseString ( "hello" ))
// HELLO
}
将一个字符串对象全部转换为大写，将 upperCaseString 声明为lambda类型，就可以作为参数传递。
另外一种用法是作为返回的参数类型。
fun toSeconds ( time : String ): ( Int ) -> Int = when ( time ) {
"hour" -> { value -> value * 60 * 60 }
"minute" -> { value -> value * 60 }
"second" -> { value -> value }
else -> { value -> value }
}
fun main () {
val timesInMinutes = listOf ( 2 , 10 , 15 , 1 )
val min2sec = toSeconds ( "minute" )
val totalTimeInSeconds = timesInMinutes . map ( min2sec ). sum ()
println ( "Total time is $totalTimeInSeconds secs" )
// Total time is 1680 secs
}
toSeconds 函数会根据传入的用法名称，返回一个lambda类型的函数，该函数将一个Int类型的参数转换为另一个Int类型的参数。
页码92
之前写过协程api介绍和核心的挂起恢复原理，再次对其设计思想进行记录，以从更上层的思维模型构筑方面了解 Kotlin 语言的协程。
已有线程为何要使用协程呢 在 JVM 生态系统中，已经有了 Thread 这个设计，对异步计算进行建模的抽象。
但是，JVM 直接映射到 OS 线程的 线程很重 。对于每个线程，OS 必须在堆栈上 分配大量上下文信息 。此外，每次计算达到 阻塞 操作时，底层线程都会暂停，JVM 必须加载另一个线程的上下文。上下文切换成本高昂，因此我们应避免在代码中使用阻塞操作。
JVM 线程上下文（Thread Context）指的是在 JVM 中每个线程所拥有的一组信息，这些信息定义了 线程在运行时的环境和状态 。包含： （1）程序计数器（Program Counter，PC）：用于记录线程当前执行的字节码指令地址。当线程被暂停后恢复执行时，程序计数器能让线程知道从哪里继续执行。 （2）栈帧（Stack Frame）：线程的栈内存用于存储方法调用的信息，每个方法调用都会在栈上创建一个栈帧。栈帧包含局部变量表、操作数栈、动态链接、方法返回地址等信息。 （3）线程局部存储（Thread Local Storage，TLS）：允许线程拥有自己独立的变量副本，不同线程对这些变量的操作互不影响。 （4）寄存器状态：包括 CPU 寄存器的值，如通用寄存器、指令指针寄存器等。这些寄存器的值反映了线程当前的执行状态。 （5）线程优先级：决定了线程在竞争 CPU 资源时的优先顺序。 （6）线程状态：如新建、就绪、运行、阻塞、终止等状态。
另一方面，正如我们将看到的，协程非常轻量级。它们不是直接映射到操作系统线程上，而是在用户级别，使用称为 Continuation 的简单对象。在协程之间切换不需要操作系统加载另一个线程的上下文，而是切换对 Continuation 对象的引用。
采用协程的另一个很好的理由是它们是一种 以同步方式编写异步代码 的方法。
作为替代方案，我们可以使用回调。但是，回调不太优雅，而且不可组合。此外，很难推理它们。很容易陷入回调地狱，代码难以阅读和维护：
a ( aInput ) { resultFromA ->
b ( resultFromA ) { resultFromB ->
c ( resultFromB ) { resultFromC ->
d ( resultFromC ) { resultFromD ->
println ( "A, B, C, D: $resultFromA, $resultFromB, $resultFromC, $resultFromD" )
}
}
}
}
上面的例子展示了使用回调风格执行四个函数。我们可以看出，收集四个函数返回的四个值需要很多工作。而且，代码还有很多优化空间，可以变得易于阅读和维护一些。
异步编程中使用的另一种模型是响应式编程。然而，问题在于它需要生成更复杂的代码才能理解和维护。让我们以 RxJava 库官方文档中的以下代码片段为例：
Flowable . fromCallable (() -> {
Thread . sleep ( 1000 ); // imitate expensive computation
return "Done" ;
})
. subscribeOn ( Schedulers . io ())
. observeOn ( Schedulers . single ())
. subscribe ( System . out :: println , Throwable: : printStackTrace );
上述代码模拟了在后台线程上运行某些计算和网络请求，并在 UI 线程上显示结果（或错误）。它不是自解释的，并不能立即看懂每个方法的作用是什么，我们需要熟悉该库才能理解发生了什么。
协程解决了上述所有问题。让我们看看它是如何解决的。
suspend挂起函数 首先，你可以将协程视为轻量级线程，这意味着它不直接映射到操作系统线程。它是一种可以 随时暂停和恢复 的计算任务。因此，在开始了解如何构建协程之前，我们需要了解如何暂停和恢复协程。
Kotlin 提供了 suspend 关键字来标记可以暂停协程的函数，即允许它暂停并稍后恢复：
suspend fun bathTime () {
logger . info ( "Going to the bathroom" )
delay ( 500L )
logger . info ( "Exiting the bathroom" )
}
该 delay(timeMillis: Long) 函数是suspend函数，会暂停协程500ms。
suspend函数只能从协程或其他suspend函数调用 。它可以被暂停和恢复。在上面的例子中，bathTime函数里，当协程执行到了delay函数时，batchTime函数可以被暂停。一旦delay执行完毕，batchTime恢复，其将从暂停后立即执行的行继续执行。
上述机制完全在 Kotlin 运行时中实现，但它是如何实现的呢？无需深入研究协程的内部结构，suspend function的整个上下文保存在类型为 的对象中 Continuation<T> 。T类型变量表示函数的返回类型。
Continuation 包含函数变量和参数的所有状态。此外，它还包括 一个标签 ，用于存储执行暂停的点。因此， Kotlin 编译器将重写每个suspend function ，在函数签名中添加一个 Continuation 类型的参数。我们的函数签名bathTime将被重写如下：
fun bathTime ( continuation : Continuation < * >): Any
为什么编译器还要 改变返回值类型 为 Any 呢？答案是，当函数suspend被挂起时，它不能直接返回函数的值。它必须返回一个值来标记该函数被挂起COROUTINE_SUSPENDED，这样调用方才知道自己调用了一个挂起函数，需要在这里暂停自身的执行。
在 continuation 对象内部，编译器将保存函数执行的状态。由于我们没有参数，也没有内部变量，因此 continuation 仅存储标记 执行进度的标签 。为了简单起见，我们引入一个 BathTimeContinuation 类型来存储函数的上下文。
在我们的示例中，运行时可以bathTime在函数开始时或delay函数之后调用该函数。如果我们使用Int标签，则可以表示函数的两种可能状态，如下所示：
fun bathTime ( continuation : Continuation < * >): Any {
val continuation =
continuation as ? BathTimeContinuation ?: BathTimeContinuation ( continuation )
if ( continuation . label == 0 ) {
logger . info ( "Going to the bathroom" )
continuation . label = 1
if ( delay ( 500L , continuation ) == COROUTINE_SUSPENDED )
return COROUTINE_SUSPENDED
}
if ( continuation . label == 1 ) {
logger . info ( "Exiting the bathroom" )
}
error ( "This line should never be reached" )
}
首先，必须检查continuation对象是否是 BathTimeContinuation 类型。如果不是，我们创建一个新BathTimeContinuation对象，并将该continuation对象作为参数传递。
当bathTime第一次调用该函数时，我们会创建一个新的continuation实例。正如我们所见，continuation就像一层层的洋葱：每次调用suspend function时，我们都会将 continuation 对象包装在一个新的 continuation 中。
然后，如果label是0，我们打印第一条消息并将标签设置为1。然后，我们调用该delay函数，传递continuation对象。如果delay函数返回COROUTINE_SUSPENDED，则表示该函数已暂停，我们也返回COROUTINE_SUSPENDED给调用者。
假设delay函数返回的值不同于COROUTINE_SUSPENDED。在这种情况下，这意味着函数已恢复，我们可以继续执行该bathTime函数。如果标签是1，则该函数刚刚恢复，我们打印第二条消息。
以上是 Kotlin 编译器生成并由 Kotlin 运行时运行的实际代码的简化版本。不过，这足以理解协程的工作原理。
简单来说，就是 将需要执行的代码封装在Continuation对象 中，并将其传递给JVM运行时。运行时将检查该Continuation对象是否已暂停。如果是，则运行时将暂停该函数的执行，并将该待执行的Continuation对象传递给该函数 ，作为一种回调。进入到下一层的挂起函数中，重复这个检查，直接遇到非 COROUTINE_SUSPENDED 状态的返回值，这时候运行时将一层层地恢复该函数的执行。
协程作用域和结构并发 现在我们可以开始研究 Kotlin 如何实现结构并发的概念。让我们声明另一个suspend function，它将模拟煮沸一些水的动作：
suspend fun boilingWater () {
logger . info ( "Boiling water" )
delay ( 1000L )
logger . info ( "Water boiled" )
}
我们介绍的第一个函数是 coroutineScope 挂起函数。此函数是协程的核心，用于创建新的协程作用域。它以挂起 lambda 作为参数，以 CoroutineScope 的实例作为接收者：
suspend fun < R > coroutineScope (
block : suspend CoroutineScope .() -> R
): R
协程作用域代表了 Kotlin 中结构化并发的实现。 运行时会阻塞 lambda 的执行，block直到 lambda 内部启动的所有协程block都完成 。这些协程被称为作用域的子协程。此外，结构化并发还为我们带来了以下特性：
子协程继承父协程的上下文 (CoroutineContext)，并且可以覆盖它。协程的上下文是Continuation我们之前见过的对象的一部分。它包含协程的名称、调度程序（即执行协程的线程池）、异常处理程序等。 当父协程被取消时，子协程也会被取消。 当子协程抛出异常时，父协程也会停止。 此外，该coroutineScope函数还创建了一个新的协程，它会暂停前一个协程的执行，直到其执行结束。因此，如果我们想按顺序执行晨间例程的两个步骤，我们可以使用以下代码：
suspend fun sequentialMorningRoutine () {
coroutineScope {
bathTime ()
}
// coroutineScope会挂起当前协程，等bathTime走完才会往下执行
coroutineScope {
boilingWater ()
}
}
为了执行sequentialMorningRoutine，我们必须声明一个暂停main函数，我们将在本文的其余部分重复使用该函数：
suspend fun main () {
logger . info ( "Starting the morning routine" )
sequentialMorningRoutine ()
logger . info ( "Ending the morning routine" )
}
该sequentialMorningRoutine函数将按顺序执行该bathTime函数，然后boilingWater在两个不同的协程中执行该函数。因此，我们不应该对上述代码的输出类似于以下内容感到惊讶：
15:27:05.260 [main] INFO CoroutinesPlayground - Starting the morning routine
15:27:05.286 [main] INFO CoroutinesPlayground - Going to the bathroom
15:27:05.811 [kotlinx.coroutines.DefaultExecutor] INFO CoroutinesPlayground - Exiting the bathroom
15:27:05.826 [kotlinx.coroutines.DefaultExecutor] INFO CoroutinesPlayground - Boiling water
15:27:06.829 [kotlinx.coroutines.DefaultExecutor] INFO CoroutinesPlayground - Water boiled
15:27:06.830 [kotlinx.coroutines.DefaultExecutor] INFO CoroutinesPlayground - Ending the morning routine
我们可以看到，执行是纯顺序的。但是，我们可以看到运行时使用两个不同的线程来执行整个过程，即 main 和 kotlinx.coroutines.DefaultExecutor 线程。协程的一个重要特性是， 当它们恢复时，它们可以在与暂停它们的线程不同的线程中执行 。例如，bathTime协程在 main 主线程上启动。然后，delay函数将其暂停。最后，它在 kotlinx.coroutines.DefaultExecutor 线程上恢复。
协程构建器 launch Builder 至此，我们应该了解suspend function和结构并发的基础知识。现在是时候明确创建我们的第一个协程了。Kotlin 协程库提供了一组称为 builders 的函数。这些函数用于创建协程并开始执行。我们将看到的第一个函数是launch：
public fun CoroutineScope . launch (
context : CoroutineContext = EmptyCoroutineContext ,
start : CoroutineStart = CoroutineStart . DEFAULT ,
block : suspend CoroutineScope .() -> Unit
): Job
该库将 launch 构建器定义为 CoroutineScope 类型的扩展函数。因此，我们需要一个作用域来以这种方式创建协程。要创建协程，我们还需要一个CoroutineContext和一个包含要执行的代码的 lambda。构建器将把它作为接收器传递CoroutineScope给blocklambda。这样，我们可以重用作用域来创建新的子协程。最后，构建器的默认行为是立即启动新的协程（CoroutineStart.DEFAULT）。
因此，让我们在早晨的例行工作中添加一些并发功能。我们可以在两个新的协程中启动boilingWater和bathTime函数，并观察它们的竞争情况：
suspend fun concurrentMorningRoutine () {
coroutineScope {
launch {
bathTime ()
}
launch {
boilingWater ()
}
}
}
上述代码的日志类似于以下内容：
09:09:44.817 [main] INFO CoroutinesPlayground - Starting the morning routine
09:09:44.870 [DefaultDispatcher-worker-1 @coroutine#1] INFO CoroutinesPlayground - Going to the bathroom
09:09:44.871 [DefaultDispatcher-worker-2 @coroutine#2] INFO CoroutinesPlayground - Boiling water
09:09:45.380 [DefaultDispatcher-worker-2 @coroutine#1] INFO CoroutinesPlayground - Exiting the bathroom
09:09:45.875 [DefaultDispatcher-worker-2 @coroutine#2] INFO CoroutinesPlayground - Water boiled
09:09:45.876 [DefaultDispatcher-worker-2 @coroutine#2] INFO CoroutinesPlayground - Ending the morning routine
我们可以从上面的日志中提取出很多信息。首先，我们可以看到我们有效地产生了两个新的协程，coroutine#1和coroutine#2。第一个运行bathTime挂起函数，第二个运行boilingWater。
两个函数的日志是交错的，因此两个函数的执行是并发的。这种并发模型是协作的。只有coroutine#1遇到suspend函数，暂停执行时，coroutine#2才有机会执行。
此外，coroutine#1在线程上运行 DefaultDispatcher-worker-1 暂停，而在 DefaultDispatcher-worker-2线程上恢复。协程在可配置的线程池上运行。正如日志所建议的那样，默认线程池被称为Dispatchers.Default。
最后但并非最不重要的一点是，日志显示了结构并发的一个清晰示例。执行main在两个协程执行后打印了方法中的最后一条日志。我们可能已经注意到，我们没有任何显式同步机制来实现main函数中的这一结果。我们没有等待或延迟main函数的执行。正如我们所说，这是由于结构并发。该coroutineScope函数创建一个用于创建两个协程的作用域。由于这两个协程是同一作用域的子代，因此它将等到它们两个的执行结束才返回。
我们也可以避免使用结构化并发。在这种情况下，我们需要添加一些等待协程执行结束的操作。我们可以使用GlobalScope对象而不是 coroutineScope 函数。它就像一个空的协程作用域，不强制任何父子关系。因此，我们可以重写晨间例程函数，如下所示：
suspend fun noStructuralConcurrencyMorningRoutine () {
GlobalScope . launch {
bathTime ()
}
GlobalScope . launch {
boilingWater ()
}
Thread . sleep ( 1500L )
}
上述代码的日志与前一个代码大体相同：
14:06:57.670 [main] INFO CoroutinesPlayground - Starting the morning routine
14:06:57.755 [DefaultDispatcher-worker-2 @coroutine#2] INFO CoroutinesPlayground - Boiling water
14:06:57.755 [DefaultDispatcher-worker-1 @coroutine#1] INFO CoroutinesPlayground - Going to the bathroom
14:06:58.264 [DefaultDispatcher-worker-1 @coroutine#1] INFO CoroutinesPlayground - Exiting the bathroom
14:06:58.763 [DefaultDispatcher-worker-1 @coroutine#2] INFO CoroutinesPlayground - Water boiled
14:06:59.257 [main] INFO CoroutinesPlayground - Ending the morning routine
由于我们没有使用任何结构化的并发机制GlobalScope，我们Thread.sleep(1500L)在函数末尾添加了一个，以等待两个协程的执行结束。如果我们删除该Thread.sleep调用，日志将类似于以下内容：
21:47:09.418 [main] INFO CoroutinesPlayground - Starting the morning routine
21:47:09.506 [main] INFO CoroutinesPlayground - Ending the morning routine
正如预期的那样，主函数在两个协程执行结束之前就返回了。因此，我们可以说，GlobalScope不是创建协程的好选择 。
如果我们查看该 launch 函数的定义，我们可以看到它返回一个Job对象。该对象是 coroutine 的句柄。我们可以使用它来取消协程的执行或等待其完成。让我们看看如何使用它来等待协程的完成。让我们为我们的钱包添加一个新的suspend function：
suspend fun preparingCoffee () {
logger . info ( "Preparing coffee" )
delay ( 500L )
logger . info ( "Coffee prepared" )
}
在我们的早晨例行工作中，我们只想在洗澡和烧水后准备咖啡。因此，我们需要等待两个协程的完成。我们可以通过join在结果Job对象上调用方法来做到这一点，join方法是一个suspend函数，可以用于等待协程的block完全执行完毕，代码如下：
suspend fun morningRoutineWithCoffee () {
coroutineScope {
val bathTimeJob : Job = launch {
bathTime ()
}
val boilingWaterJob : Job = launch {
boilingWater ()
}
bathTimeJob . join ()
boilingWaterJob . join ()
launch {
preparingCoffee ()
}
}
}
正如我们所料，从日志中我们可以看到，在两个协程执行结束后，我们才准备了咖啡：
21:56:18.040 [main] INFO CoroutinesPlayground - Starting the morning routine
21:56:18.128 [DefaultDispatcher-worker-1 @coroutine#1] INFO CoroutinesPlayground - Going to the bathroom
21:56:18.130 [DefaultDispatcher-worker-2 @coroutine#2] INFO CoroutinesPlayground - Boiling water
21:56:18.639 [DefaultDispatcher-worker-1 @coroutine#1] INFO CoroutinesPlayground - Exiting the bathroom
21:56:19.136 [DefaultDispatcher-worker-1 @coroutine#2] INFO CoroutinesPlayground - Water boiled
21:56:19.234 [DefaultDispatcher-worker-2 @coroutine#3] INFO CoroutinesPlayground - Preparing coffee
21:56:19.739 [DefaultDispatcher-worker-2 @coroutine#3] INFO CoroutinesPlayground - Coffee prepared
21:56:19.739 [DefaultDispatcher-worker-2 @coroutine#3] INFO CoroutinesPlayground - Ending the morning routine
但是，既然我们现在知道了结构并发的所有秘密，我们可以 使用coroutineScope函数 的功能重写上述代码：
suspend fun structuralConcurrentMorningRoutineWithCoffee () {
coroutineScope {
coroutineScope {
launch {
bathTime ()
}
launch {
boilingWater ()
}
}
launch {
preparingCoffee ()
}
}
}
上述代码的输出和前一个代码相同。
async Builder 如果我们想从协程的执行中返回一个值怎么办？例如，让我们定义两个新的挂起函数：前者产生我们准备的咖啡混合物。同时，后者返回烤面包：
suspend fun preparingJavaCoffee (): String {
logger . info ( "Preparing coffee" )
delay ( 500L )
logger . info ( "Coffee prepared" )
return "Java coffee"
}
suspend fun toastingBread (): String {
logger . info ( "Toasting bread" )
delay ( 1000L )
logger . info ( "Bread toasted" )
return "Toasted bread"
}
幸运的是，库提供了一种让协程返回值的方法。我们可以使用 async构建器 创建一个返回值的协程。具体来说，它会产生一个 Deferred<T> 类型的值，其行为或多或少类似于 java Future<T> 。在 Deferred<T> 类型的对象上，我们可以调用 await方法 等待协程完成并获取返回值。库还将async构建器定义为 CoroutineScope 扩展方法：
public fun < T > CoroutineScope . async (
context : CoroutineContext = EmptyCoroutineContext ,
start : CoroutineStart = CoroutineStart . DEFAULT ,
block : suspend CoroutineScope .() -> T
): Deferred < T >
让我们看看如何使用它来返回我们准备的咖啡和烤面包的混合：
suspend fun breakfastPreparation () {
coroutineScope {
val coffee : Deferred < String > = async {
preparingJavaCoffee ()
}
val toast : Deferred < String > = async {
toastingBread ()
}
logger . info ( "I'm eating ${coffee.await()} and ${toast.await()}" )
}
}
如果我们查看日志，我们可以看到两个协程的执行仍然是并发的。最后一条日志等待两个协程完成后打印，最终消息：
21:56:46.091 [main] INFO CoroutinesPlayground - Starting the morning routine
21:56:46.253 [DefaultDispatcher-worker-1 @coroutine#1] INFO CoroutinesPlayground - Preparing coffee
21:56:46.258 [DefaultDispatcher-worker-2 @coroutine#2] INFO CoroutinesPlayground - Toasting bread
21:56:46.758 [DefaultDispatcher-worker-1 @coroutine#1] INFO CoroutinesPlayground - Coffee prepared
21:56:47.263 [DefaultDispatcher-worker-1 @coroutine#2] INFO CoroutinesPlayground - Bread toasted
21:56:47.263 [DefaultDispatcher-worker-1 @coroutine#2] INFO CoroutinesPlayground - I'm eating Java coffee and Toasted bread
21:56:47.263 [DefaultDispatcher-worker-1 @coroutine#2] INFO CoroutinesPlayground - Ending the morning routine
协作调度 到这里，我们应该对协程的一些基础知识有所了解了。然而，我们仍然需要讨论协程的一个重要方面：协作调度。
协程调度模型与 Java 采用的Threads抢占式调度模型有很大不同。在抢占式调度中，操作系统决定何时从一个线程切换到另一个线程。在协作式调度中， 协程本身决定何时将控制权交给另一个协程 。
在 Kotlin 中，协程决定放弃控制权并到达挂起函数。只有此时执行它的线程才会被释放并允许运行另一个协程。
如果我们注意到，在迄今为止看到的日志中，执行控制在调用delay挂起函数时总是会发生变化。但是，为了更好地理解它，让我们看另一个示例。让我们定义一个新的挂起函数来模拟执行一个非常长时间运行的任务：
suspend fun workingHard () {
logger . info ( "Working" )
while ( true ) {
// Do nothing
}
delay ( 100L )
logger . info ( "Work done" )
}
无限循环会阻止函数到达delay挂起函数，因此协程永远不会放弃控制权。现在，我们定义另一个挂起函数与前一个函数并发执行：
suspend fun takeABreak () {
logger . info ( "Taking a break" )
delay ( 1000L )
logger . info ( "Break done" )
}
最后，让我们将所有内容整合到一个新的挂起函数中，该函数在两个专用协程中运行前两个函数。为了确保我们能看到协作调度的效果，我们将执行协程的线程池限制为单个线程：
@OptIn ( ExperimentalCoroutinesApi :: class )
suspend fun workingHardRoutine () {
val dispatcher : CoroutineDispatcher = Dispatchers . Default . limitedParallelism ( 1 )
coroutineScope {
launch ( dispatcher ) {
workingHard ()
}
launch ( dispatcher ) {
takeABreak ()
}
}
}
表示CoroutineDispatcher用于执行协程的线程池。该limitedParallelism函数是接口的扩展方法CoroutineDispatcher，用于 将线程池中的线程数限制为给定值 。由于这是一个实验性 API，因此我们需要用@OptIn(ExperimentalCoroutinesApi::class)注释注释该函数以避免编译器警告。
我们在唯一可用的线程上启动了两个协程dispatcher，日志向我们展示了协作调度的效果：
08:46:04.804 [main] INFO CoroutinesPlayground - Starting the morning routine
08:46:04.884 [DefaultDispatcher-worker-2 @coroutine#1] INFO CoroutinesPlayground - Working
-- Running forever --
由于workingHard协程从未到达挂起函数，因此它永远不会交出控制权。然后，takeABreak协程永远不会被执行。相反，如果我们定义一个挂起函数，将控制权交还给调度程序，takeABreak协程将有机会被执行：
suspend fun workingConsciousness () {
logger . info ( "Working" )
while ( true ) {
delay ( 100L )
}
logger . info ( "Work done" )
}
@OptIn ( ExperimentalCoroutinesApi :: class )
suspend fun workingConsciousnessRoutine () {
val dispatcher : CoroutineDispatcher = Dispatchers . Default . limitedParallelism ( 1 )
coroutineScope {
launch ( dispatcher ) {
workingConsciousness ()
}
launch ( dispatcher ) {
takeABreak ()
}
}
}
现在，日志显示takeABreak协程 有机会执行 ，即使 workingConsciousness 永远运行，并且我们只有一个线程：
09:02:49.302 [main] INFO CoroutinesPlayground - Starting the morning routine
09:02:49.376 [DefaultDispatcher-worker-1 @coroutine#1] INFO CoroutinesPlayground - Working
09:02:49.382 [DefaultDispatcher-worker-1 @coroutine#2] INFO CoroutinesPlayground - Taking a break
09:02:50.387 [DefaultDispatcher-worker-1 @coroutine#2] INFO CoroutinesPlayground - Break done
-- Running forever --
我们可以使用协程来获取相同的日志workingHard，并向线程池中添加一个线程：
@OptIn ( ExperimentalCoroutinesApi :: class )
suspend fun workingHardRoutine () {
val dispatcher : CoroutineDispatcher = Dispatchers . Default . limitedParallelism ( 2 )
coroutineScope {
launch ( dispatcher ) {
workingHard ()
}
launch ( dispatcher ) {
takeABreak ()
}
}
}
由于我们有两个线程和两个协程，因此并发度现在为 2。照例，日志证实了该理论：coroutine#1在 上执行DefaultDispatcher-worker-1，coroutine#2在 上执行DefaultDispatcher-worker-2。
13:40:59.864 [main] INFO CoroutinesPlayground - Starting the morning routine
13:40:59.998 [DefaultDispatcher-worker-1 @coroutine#1] INFO CoroutinesPlayground - Working
13:41:00.003 [DefaultDispatcher-worker-2 @coroutine#2] INFO CoroutinesPlayground - Taking a break
13:41:01.010 [DefaultDispatcher-worker-2 @coroutine#2] INFO CoroutinesPlayground - Break done
-- Running forever --
协作式调度迫使我们在设计协程时非常小心。假设一个协程执行了一个阻塞底层线程的操作，比如 JDBC 调用。在这种情况下，它会阻止该线程执行任何其他协程。
因此，该库允许我们针对不同的操作使用不同的调度程序。主要有：
Dispatchers.Default是库使用的默认调度程序。它使用线程数等于可用处理器数的线程池。它是 CPU 密集型操作的正确选择。 Dispatchers.IO是用于 I/O 操作的调度程序。它使用线程池，线程数等于可用处理器数，或最多 64 个。它是 I/O 操作（例如网络调用或文件操作）的正确选择。 从线程池创建的 Dispatcher：可以CoroutineDispatcher使用线程池来创建我们的实例。我们可以轻松使用接口asCoroutineDispatcher的扩展功能Executor。但是，请注意，当我们不再需要底层线程池时，我们有责任将其关闭：val dispatcher = Executors.newFixedThreadPool(10).asCoroutineDispatcher() 如果我们同时拥有 CPU 密集型部分和阻塞部分，我们必须同时使用Dispatchers.Default 和 Dispatchers.IO ，并确保在默认调度程序上启动 CPU 密集型协程，在 IO 调度程序上启动阻塞代码。
协程的取消 当我们思考并发编程时，取消始终是一个棘手的话题。终止线程并突然停止任务的执行并不是一个好的做法。在停止任务之前，我们必须释放正在使用的资源，避免泄漏，并使系统处于一致状态。
我们可以想象，Kotlin 允许我们取消协程的执行。该库提供了一种机制来协作取消协程以避免出现问题。该Job类型提供了一个cancel取消协程执行的函数。但是，取消不是立即的，只有当协程到达暂停点时才会发生。该机制与我们在协作调度中看到的机制非常接近。
让我们看一个例子。我们想模拟一下我们在工作期间接到一个重要电话。我们忘记了我们最好的朋友的生日，我们想在商场关门前去买一份礼物：
suspend fun forgettingTheBirthDayRoutine () {
coroutineScope {
val workingJob = launch {
workingConsciousness ()
}
launch {
delay ( 2000L )
workingJob . cancel ()
workingJob . join ()
logger . info ( "I forgot the birthday! Let's go to the mall!" )
}
}
}
此代码片段中发生了很多事情。首先，我们启动了workingConsciousness协程并收集了相应的Job。我们使用了workingConsciousness挂起函数，因为它在无限循环内挂起，并调用该delay函数。
同时，我们启动另一个协程，该协程workingJob在 2 秒后调用 workingJob 的取消函数，并等待其完成。workingJob被取消，但workingConsciousness协程不会立即停止。它继续执行，直到 到达暂停点 ，然后被取消。由于我们想等待取消，我们调用了workingJob的join函数。
日志证实了这一理论。在 coroutine#1 启动后约 2 秒，coroutine#2打印了其日志，并且coroutine#1被取消：
21:36:04.205 [main] INFO CoroutinesPlayground - Starting the morning routine
21:36:04.278 [DefaultDispatcher-worker-1 @coroutine#1] INFO CoroutinesPlayground - Working
21:36:06.390 [DefaultDispatcher-worker-2 @coroutine#2] INFO CoroutinesPlayground - I forgot the birthday! Let's go to the mall!
21:36:06.391 [DefaultDispatcher-worker-2 @coroutine#2] INFO CoroutinesPlayground - Ending the morning routine
cancel和join配合使用的模式非常常见，因此 Kotlin 协程库为我们提供了一个cancelAndJoin结合这两种操作的函数。
正如我们所说，在 Kotlin 中，取消是一种合作行为。 如果协程从不暂停，则根本无法取消 。让我们改用suspend function来更改上述示例workingHard。在这种情况下，该workingHard函数从不暂停，因此我们预计workingJob无法取消：
suspend fun forgettingTheBirthDayRoutineWhileWorkingHard () {
coroutineScope {
val workingJob = launch {
workingHard ()
}
launch {
delay ( 2000L )
workingJob . cancelAndJoin ()
logger . info ( "I forgot the birthday! Let's go to the mall!" )
}
}
}
这次，我们的朋友将不会收到她的礼物。workingJob被取消，但workingHard函数没有停止，因为它从未到达暂停点。 日志再次证实了这一理论：
08:56:10.784 [main] INFO CoroutinesPlayground - Starting the morning routine
08:56:10.849 [DefaultDispatcher-worker-1 @coroutine#1] INFO CoroutinesPlayground - Working
-- Running forever --
在后台，该cancel函数将 设置Job为“正在取消”状态。在第一次到达暂停点时，运行时抛出一个CancellationException，协程最终被取消。这种机制使我们能够安全地清理协程使用的资源。我们可以实施许多策略来清理资源，但首先，我们需要在示例中释放资源。我们可以定义代表我们办公室办公桌的 Desk 类：
class Desk : AutoCloseable {
init {
logger . info ( "Starting to work on the desk" )
}
override fun close () {
logger . info ( "Cleaning the desk" )
}
}
该类Desk实现了AutoCloseable接口。因此，它是协程取消期间释放资源的绝佳选择。由于它实现了AutoCloseable，我们可以使用该use函数在代码块完成时自动关闭资源：
suspend fun forgettingTheBirthDayRoutineAndCleaningTheDesk () {
val desk = Desk ()
coroutineScope {
val workingJob = launch {
desk . use { _ ->
workingConsciousness ()
}
}
launch {
delay ( 2000L )
workingJob . cancelAndJoin ()
logger . info ( "I forgot the birthday! Let's go to the mall!" )
}
}
}
use 是 Kotlin 标准库中的一个扩展函数，主要用于自动管理需要关闭的资源（如文件、网络连接等）。它确保资源在使用完毕后被正确关闭，即使发生异常也不会遗漏。
正如预期的那样，在我们搬到商场之前，我们清理了桌子，日志也证实了这一点：
21:38:30.117 [main] INFO CoroutinesPlayground - Starting the morning routine
21:38:30.124 [main] INFO CoroutinesPlayground - Starting to work on the desk
21:38:30.226 [DefaultDispatcher-worker-1 @coroutine#1] INFO CoroutinesPlayground - Working
21:38:32.298 [DefaultDispatcher-worker-2 @coroutine#1] INFO CoroutinesPlayground - Cleaning the desk
21:38:32.298 [DefaultDispatcher-worker-2 @coroutine#2] INFO CoroutinesPlayground - I forgot the birthday! Let's go to the mall!
21:38:32.298 [DefaultDispatcher-worker-2 @coroutine#2] INFO CoroutinesPlayground - Ending the morning routine
我们还可以使用invokeOnCompletion取消上的函数在函数完成workingConsciousness Job后清理桌面：
suspend fun forgettingTheBirthDayRoutineAndCleaningTheDeskOnCompletion () {
val desk = Desk ()
coroutineScope {
val workingJob = launch {
workingConsciousness ()
}
workingJob . invokeOnCompletion { exception : Throwable ? ->
desk . close ()
}
launch {
delay ( 2000L )
workingJob . cancelAndJoin ()
logger . info ( "I forgot the birthday! Let's go to the mall!" )
}
}
}
我们可以看到，该invokeOnCompletion方法将可空异常作为输入参数。如果Job被取消，则异常为CancellationException。
取消的另一个特性是它会传播到子协程。 当我们取消一个协程时，我们会隐式取消它的所有子协程 。让我们看一个例子。白天，保持水分是必不可少的。我们可以使用 drinkWater 来喝水：
suspend fun drinkWater () {
while ( true ) {
logger . info ( "Drinking water" )
delay ( 1000L )
logger . info ( "Water drunk" )
}
}
然后，我们可以创建一个协程，并生成两个新的协程，分别用于工作和饮用水。最后，我们可以取消父协程，并且我们期望两个子协程也被取消：
suspend fun forgettingTheBirthDayWhileWorkingAndDrinkingWaterRoutine () {
coroutineScope {
val workingJob = launch {
launch {
workingConsciousness ()
}
launch {
drinkWater ()
}
}
launch {
delay ( 2000L )
workingJob . cancelAndJoin ()
logger . info ( "I forgot the birthday! Let's go to the mall!" )
}
}
}
正如预期的那样，当我们取消 时workingJob，我们也会取消并停止其子协程。以下是描述情况的日志：
13:18:49.143 [main] INFO CoroutinesPlayground - Starting the morning routine
13:18:49.275 [DefaultDispatcher-worker-2 @coroutine#2] INFO CoroutinesPlayground - Working
13:18:49.285 [DefaultDispatcher-worker-3 @coroutine#3] INFO CoroutinesPlayground - Drinking water
13:18:50.285 [DefaultDispatcher-worker-3 @coroutine#3] INFO CoroutinesPlayground - Water drunk
13:18:50.286 [DefaultDispatcher-worker-3 @coroutine#3] INFO CoroutinesPlayground - Drinking water
13:18:51.288 [DefaultDispatcher-worker-2 @coroutine#3] INFO CoroutinesPlayground - Water drunk
13:18:51.288 [DefaultDispatcher-worker-2 @coroutine#3] INFO CoroutinesPlayground - Drinking water
13:18:51.357 [DefaultDispatcher-worker-2 @coroutine#4] INFO CoroutinesPlayground - I forgot the birthday! Let's go to the mall!
13:18:51.357 [DefaultDispatcher-worker-2 @coroutine#4] INFO CoroutinesPlayground - Ending the morning routine
这就是协程取消的全部内容！
协程上下文 在关于continuation的部分和关于构建器的部分中，我们简要介绍了协程上下文的概念。此外，CoroutineScope保留对协程上下文的引用。你可以想象， 这是一种存储从父级传递给子级的信息的方法 ，以在内部开发结构并发性。
表示协程上下文的类型称为CoroutineContext，它是 Kotlin 核心库的一部分。这是一个有趣的类型，因为它表示元素的集合，但同时，每个元素都是一个集合：
public interface CoroutineContext
// But also
public interface Element : CoroutineContext
CoroutineContext 的实现与 Continuation<T> 类型一起放在 Kotlin 协程库中。在实际实现中，我们有CoroutineName，它代表协程的名称：
val name : CoroutineContext = CoroutineName ( "Morning Routine" )
此外，CoroutineDispatcher和Job类型实现了CoroutineContext接口。我们在上面的日志中看到的标识符是CoroutineId。当我们启用调试模式时，运行时会自动将此上下文添加到每个协程中。
由于 CoroutineContext 其行为类似于集合，因此该库还定义了向上下文添加元素的 + 运算符。因此，创建一个包含许多元素的新上下文非常简单：
val context : CoroutineContext = CoroutineName ( "Morning Routine" ) + Dispatchers . Default + Job ()
也可以使用以下函数从上下文中删除元素minusKey：
val newContext : CoroutineContext = context . minusKey ( CoroutineName )
我们应该记住，我们可以将上下文传递给构建器来更改所创建协程的行为。例如，假设我们想要创建一个使用 Dispatchers.Default 的特定名称的协程。在这种情况下，我们可以按如下方式执行：
suspend fun asynchronousGreeting () {
coroutineScope {
launch ( CoroutineName ( "Greeting Coroutine" ) + Dispatchers . Default ) {
logger . info ( "Hello Everyone!" )
}
}
}
我们在main函数内部运行一下，在日志中我们可以看到，这个协程以指定的名称创建，并在调度器中执行Default：
11:56:46.747 [DefaultDispatcher-worker-1 @Greeting Coroutine#1] INFO CoroutinesPlayground - Hello Everyone!
协程上下文也可以表现得像一个映射，因为我们可以使用与我们要检索的元素相对应的类型的名称来搜索和访问它包含的元素：
logger.info("Coroutine name: {}", context[CoroutineName]?.name)
上述代码打印了上下文中存储的协程名称（如果有）。CoroutineName方括号内的既不是类型也不是类。实际上，它引用了Key类的伴生对象，即只是一些 Kotlin 语法糖。
该库还定义了 EmptyCoroutineContext 空的协程上下文，我们可以将其用作“零”元素来创建新的自定义上下文。
因此，上下文是一种在协程之间传递信息的方式。任何父协程都会将其上下文提供给其子协程。子协程将值从父级复制到它们可以覆盖的上下文的新实例。让我们看一个没有覆盖的继承示例：
suspend fun coroutineCtxInheritance () {
coroutineScope {
launch ( CoroutineName ( "Greeting Coroutine" )) {
logger . info ( "Hello everyone from the outer coroutine!" )
launch {
logger . info ( "Hello everyone from the inner coroutine!" )
}
delay ( 200L )
logger . info ( "Hello again from the outer coroutine!" )
}
}
}
上述代码的日志如下，它突出显示两个协程共享相同的名称：
12:19:12.962 [DefaultDispatcher-worker-1 @Greeting Coroutine#1] INFO CoroutinesPlayground - Hello everyone from the outer coroutine!
12:19:12.963 [DefaultDispatcher-worker-2 @Greeting Coroutine#2] INFO CoroutinesPlayground - Hello everyone from the inner coroutine!
12:19:12.963 [DefaultDispatcher-worker-1 @Greeting Coroutine#1] INFO CoroutinesPlayground - Hello again from the outer coroutine!
正如我们所说的，如果我们愿意，我们可以从子协程覆盖上下文中的值：
suspend fun coroutineCtxOverride () {
coroutineScope {
launch ( CoroutineName ( "Greeting Coroutine" )) {
logger . info ( "Hello everyone from the outer coroutine!" )
launch ( CoroutineName ( "Greeting Inner Coroutine" )) {
logger . info ( "Hello everyone from the inner coroutine!" )
}
delay ( 200L )
logger . info ( "Hello again from the outer coroutine!" )
}
}
}
上面代码的log显示了父协程被覆盖了，但是父上下文中的值还是原来的：
12:22:33.869 [DefaultDispatcher-worker-1 @Greeting Coroutine#1] INFO CoroutinesPlayground - Hello everyone from the outer coroutine!
12:22:33.870 [DefaultDispatcher-worker-2 @Greeting Inner Coroutine#2] INFO CoroutinesPlayground - Hello everyone from the inner coroutine!
12:22:34.077 [DefaultDispatcher-worker-1 @Greeting Coroutine#1] INFO CoroutinesPlayground - Hello again from the outer coroutine!
12:22:34.078 [DefaultDispatcher-worker-1 @Greeting Coroutine#1] INFO CoroutinesPlayground - Ending the morning routine
上下文继承规则的唯一例外是Job上下文实例。每个新协程都会创建自己的Job实例，该实例不会从父级继承。而其他上下文元素（例如CoroutineName或调度程序）则从父级继承。
Pagination © 2024. All rights reserved. LICENSE | NOTICE | CHANGELOG
Powered by Hydejack v9.2.1
