美团上面试

http 三次握手 / 四次挥手具体过程，信号量的变化，只有两次握手行不行

三次握手过程：
- 第一次握手：客户端向服务器发送一个 SYN（同步）标志位为 1 的 TCP 报文段，其中包含客户端的初始序列号（ISN），此时客户端进入 SYN_SENT 状态，表示客户端请求建立连接。
- 第二次握手：服务器收到客户端的 SYN 报文段后，会向客户端发送一个 SYN 和 ACK（确认）标志位都为 1 的 TCP 报文段，其中包含服务器的初始序列号和对客户端序列号的确认号，此时服务器进入 SYN_RCVD 状态，表示服务器同意建立连接并向客户端确认。
- 第三次握手：客户端收到服务器的 SYN+ACK 报文段后，会向服务器发送一个 ACK 标志位为 1 的 TCP 报文段，其中包含对服务器序列号的确认号，此时客户端进入 ESTABLISHED 状态，表示客户端与服务器的连接已建立。服务器收到客户端的 ACK 报文段后，也进入 ESTABLISHED 状态。

四次挥手过程：
- 第一次挥手：客户端向服务器发送一个 FIN（结束）标志位为 1 的 TCP 报文段，表示客户端请求关闭连接，此时客户端进入 FIN_WAIT_1 状态。
- 第二次挥手：服务器收到客户端的 FIN 报文段后，会向客户端发送一个 ACK 标志位为 1 的 TCP 报文段，表示服务器已经收到客户端的关闭请求，此时服务器进入 CLOSE_WAIT 状态，客户端收到服务器的 ACK 报文段后，进入 FIN_WAIT_2 状态。
- 第三次挥手：服务器向客户端发送一个 FIN 标志位为 1 的 TCP 报文段，表示服务器也请求关闭连接，此时服务器进入 LAST_ACK 状态。
- 第四次挥手：客户端收到服务器的 FIN 报文段后，会向服务器发送一个 ACK 标志位为 1 的 TCP 报文段，表示客户端已经收到服务器的关闭请求，此时客户端进入 TIME_WAIT 状态，等待 2MSL（最长报文段寿命）后，客户端进入 CLOSED 状态。服务器收到客户端的 ACK 报文段后，进入 CLOSED 状态。
信号量的变化：在三次握手中，每一次握手都会使双方的状态发生变化，同时也会使一些信号量发生变化，如序列号、确认号等。在四次挥手中，同样会使双方的状态和信号量发生变化，如 FIN 标志位、ACK 标志位等。
只有两次握手行不行：不行。如果只有两次握手，当客户端发送的 SYN 报文段在网络中延迟或丢失时，客户端会因为长时间未收到服务器的 ACK 报文段而重新发送 SYN 报文段。而服务器在收到延迟或丢失的 SYN 报文段后，会向客户端发送 SYN+ACK 报文段，并进入 SYN_RCVD 状态，等待客户端的 ACK 报文段。如果此时客户端的重新发送的 SYN 报文段到达服务器，服务器会认为这是一个新的连接请求，而客户端却认为这是对之前连接请求的确认，这样就会导致服务器和客户端之间的状态不一致，从而导致连接建立失败。

TCP/UDP 区别，应用场景（举例），什么情况下用 UDP 而非 TCP

TCP 和 UDP 的区别：
- 连接性：TCP 是面向连接的协议，在数据传输之前需要先建立连接，数据传输完成后需要释放连接；UDP 是无连接的协议，不需要建立连接就可以直接发送数据。
- 可靠性：TCP 提供可靠的数据传输服务，通过序列号、确认号、重传机制等保证数据的准确性和完整性；UDP 不提供可靠的数据传输服务，数据可能会丢失、重复或乱序。
- 传输效率：TCP 由于需要建立连接、维护连接状态和进行可靠传输，传输效率相对较低；UDP 不需要建立连接和进行可靠传输，传输效率相对较高。
- 报文结构：TCP 的报文头结构比较复杂，包含了序列号、确认号、窗口大小等字段；UDP 的报文头结构比较简单，只包含了源端口、目的端口、长度和校验和等字段。
应用场景：
- TCP 应用场景：适用于对数据传输可靠性要求较高的应用，如文件传输、电子邮件、远程登录等。例如，在文件传输过程中，需要确保文件的完整性和准确性，因此通常使用 TCP 协议。
- UDP 应用场景：适用于对实时性要求较高、对数据准确性要求相对较低的应用，如视频直播、音频通话、游戏等。例如，在视频直播中，为了保证视频的流畅性，通常使用 UDP 协议。
使用 UDP 而非 TCP 的情况：
- 实时性要求高：如视频会议、在线游戏等应用，对实时性要求非常高，少量的数据丢失对整体体验影响不大，但对延迟非常敏感，UDP 的低延迟特性更适合。
- 广播或多播：UDP 支持广播和多播功能，适用于需要向多个接收者发送相同数据的情况，如网络视频广播、音频广播等。
- 资源受限的环境：在一些资源受限的设备或网络环境中，UDP 的简单性和低开销可以减少对系统资源的占用，提高系统的性能和响应速度。

http 拥塞控制：滑动窗口机制 / 流量控制的具体方法

滑动窗口机制：
- 发送方和接收方都维护一个窗口，窗口大小表示可以发送或接收的数据量。发送方根据接收方的窗口大小和网络拥塞情况来调整自己的发送窗口大小，从而控制发送数据的速率。
- 发送方在发送数据时，会将数据放入发送窗口中，并等待接收方的确认。接收方在收到数据后，会向发送方发送确认报文段，其中包含接收方的窗口大小。发送方根据接收方的窗口大小来调整自己的发送窗口大小，如果接收方的窗口大小为 0，则发送方停止发送数据，等待接收方的窗口大小变为非 0。
- 当网络出现拥塞时，发送方会减小发送窗口的大小，从而降低发送数据的速率，以避免网络拥塞进一步加剧。当网络拥塞缓解后，发送方会逐渐增大发送窗口的大小，以提高发送数据的速率。
流量控制的具体方法：
- 流量控制主要是通过接收方控制发送方的发送速率来实现的。接收方在接收数据时，会根据自己的接收能力和处理能力来调整发送方的发送窗口大小，从而控制发送方的发送速率。
- 接收方在收到数据后，会向发送方发送确认报文段，其中包含接收方的窗口大小。发送方根据接收方的窗口大小来调整自己的发送窗口大小，如果接收方的窗口大小为 0，则发送方停止发送数据，等待接收方的窗口大小变为非 0。
- 接收方可以通过调整自己的接收窗口大小来控制发送方的发送速率，从而实现流量控制。例如，当接收方的接收缓冲区已满时，接收方可以将接收窗口大小设置为 0，通知发送方停止发送数据，直到接收方的接收缓冲区有足够的空间为止。

如何保证 http 的可靠传输，报文的有序，丢失重传机制

保证 HTTP 可靠传输的方法：
- 使用 TCP 协议：HTTP 协议通常建立在 TCP 协议之上，利用 TCP 的可靠传输机制，如序列号、确认号、重传机制等，保证数据的准确性和完整性。
- 数据校验：在 HTTP 报文中添加校验和字段，接收方在收到报文后可以对报文进行校验，确保报文在传输过程中没有被篡改或损坏。
- 确认与重传：发送方在发送数据后，会等待接收方的确认报文段。如果发送方在一定时间内没有收到接收方的确认报文段，则会重新发送数据。
保证报文有序的方法：
- TCP 序列号：TCP 协议为每个字节的数据都分配了一个序列号，接收方可以根据序列号对收到的数据进行排序，确保数据的顺序与发送方发送的顺序一致。
- 缓存与重组：接收方在收到数据后，会将数据缓存起来，等待所有的数据都收到后，再按照序列号的顺序对数据进行重组，确保数据的顺序与发送方发送的顺序一致。
丢失重传机制：
- 超时重传：发送方在发送数据后，会启动一个定时器，如果在定时器超时之前没有收到接收方的确认报文段，则会认为数据丢失，重新发送数据。
- 快速重传：当接收方收到一个乱序的报文段时，会立即向发送方发送一个重复的确认报文段，通知发送方该报文段可能丢失。发送方在收到三个重复的确认报文段后，会立即重传该报文段，而不需要等待定时器超时。

http 和 https 的区别

连接安全性：HTTP 是超文本传输协议，数据以明文形式传输，这意味着在数据传输过程中，黑客可以通过网络监听等手段获取传输的内容，存在安全风险；HTTPS 则是在 HTTP 的基础上加入了 SSL/TLS 协议，对数据进行加密处理，使得数据在传输过程中变成密文，大大提高了数据的安全性，防止数据被窃取、篡改或监听。
连接端口：HTTP 默认使用 80 端口进行数据传输；而 HTTPS 默认使用 443 端口。
证书：HTTPS 需要向权威的证书颁发机构申请数字证书，以证明服务器的身份真实性。客户端在与服务器建立连接时，会验证服务器的证书，如果证书不合法或不可信，客户端会发出警告或拒绝连接；HTTP 则不需要数字证书来验证身份。
性能：由于 HTTPS 需要对数据进行加密和解密处理，因此在性能上会比 HTTP 略低一些。但是，随着现代硬件性能的不断提高和加密算法的不断优化，这种性能差异在大多数情况下并不明显。
兼容性：HTTP 是一种通用的协议，几乎所有的网络设备和浏览器都支持 HTTP 协议；HTTPS 由于需要 SSL/TLS 协议的支持，在一些老旧的设备或浏览器上可能存在兼容性问题。
成本：HTTPS 需要购买数字证书，并且需要对服务器进行配置和维护，因此在成本上会比 HTTP 略高一些。

HTTPS 的 TLS 协议握手过程，为什么不直接用证书上的公钥加密信息

TLS 协议握手过程如下：

客户端发起请求：客户端向服务器发送一个 “Client Hello” 消息，其中包含客户端支持的 TLS 版本、加密算法套件、随机数等信息。
服务器响应：服务器收到客户端的请求后，选择一个合适的加密算法套件，并向客户端发送 “Server Hello” 消息，其中包含服务器选择的加密算法套件、随机数等信息。同时，服务器还会发送自己的数字证书，证书中包含服务器的公钥等信息。
客户端验证证书：客户端收到服务器的证书后，首先验证证书的合法性，包括证书是否由可信的证书颁发机构颁发、证书是否过期等。如果证书验证通过，客户端会生成一个随机的对称密钥，并用服务器的公钥对该对称密钥进行加密，然后发送给服务器。
服务器解密并获取对称密钥：服务器收到客户端发送的加密后的对称密钥后，使用自己的私钥对其进行解密，从而获取到对称密钥。
双方使用对称密钥进行加密通信：客户端和服务器都获取到对称密钥后，双方就可以使用该对称密钥对后续的通信数据进行加密和解密，从而保证通信的安全性。

不直接用证书上的公钥加密信息主要有以下原因：

性能问题：公钥加密算法通常比对称加密算法计算复杂度高、速度慢。如果直接使用公钥加密所有通信数据，会导致加密和解密过程非常耗时，严重影响通信效率。
密钥管理复杂：在通信过程中，如果每次都使用公钥加密，那么对于每个通信连接都需要进行公钥的交换和管理，这会增加密钥管理的复杂性和风险。而对称密钥则可以在一次握手过程中生成并共享，后续通信中只需要使用该对称密钥进行加密和解密，大大简化了密钥管理的过程。

TCP 属于哪个层

TCP 属于传输层。在网络体系结构中，传输层负责在不同主机的应用程序之间提供可靠的、端到端的通信服务。它的主要作用是将应用层的数据分割成合适的报文段，并在接收端将这些报文段重新组装成完整的应用层数据，同时还负责实现流量控制、拥塞控制、差错控制等功能，以确保数据的可靠传输。

TCP 如何保证可靠传输等

TCP 通过以下机制来保证可靠传输：

序列号和确认应答：TCP 为每个发送的字节都分配一个序列号，接收方收到数据后会返回一个确认应答，其中包含期望收到的下一个字节的序列号。发送方通过确认应答来确定数据是否被正确接收，如果在一定时间内没有收到确认应答，发送方会重发数据。
超时重传：当发送方发送数据后，如果在规定的时间内没有收到确认应答，就会认为数据丢失，然后重新发送该数据。
流量控制：TCP 通过滑动窗口机制来实现流量控制，接收方会在确认应答中告知发送方自己的接收窗口大小，发送方根据接收窗口大小来调整发送数据的速度，避免接收方因接收缓冲区溢出而导致数据丢失。
拥塞控制：TCP 通过慢启动、拥塞避免、快重传和快恢复等算法来实现拥塞控制，根据网络的拥塞程度来调整发送数据的速度，避免网络拥塞导致数据丢失。

说说 TCP 传输数据的过程

TCP 传输数据的过程主要包括以下几个步骤：

建立连接：通过三次握手建立 TCP 连接，确保客户端和服务器之间能够进行可靠的通信。
数据分割与编号：应用层将数据传递给 TCP 层后，TCP 会将数据分割成合适的报文段，并为每个报文段分配一个序列号。
数据传输：发送方按照一定的顺序将报文段发送给接收方，接收方收到报文段后，会检查报文段的序列号和校验和等信息，以确保数据的完整性和正确性。
确认应答与重传：接收方收到报文段后，会向发送方发送一个确认应答，其中包含期望收到的下一个字节的序列号。如果发送方在一定时间内没有收到确认应答，就会认为数据丢失，然后重新发送该数据。
流量控制与拥塞控制：在数据传输过程中，TCP 会根据接收方的接收能力和网络的拥塞程度来调整发送数据的速度，以确保数据的可靠传输。
关闭连接：当数据传输完成后，客户端和服务器会通过四次挥手关闭 TCP 连接。

HTTP1.0，1.1，2.0，3.0 区别

HTTP1.0：是早期的 HTTP 协议版本，连接方式简单，每次请求都需要建立新的连接，传输完数据后即断开连接，效率较低。不支持长连接，无法复用连接以减少连接建立和断开的开销。不支持请求的优先级，服务器按照接收到请求的顺序依次处理，无法对重要请求进行优先处理。
HTTP1.1：引入了持久连接，在一个 TCP 连接上可以传送多个 HTTP 请求和响应，减少了建立和关闭连接的消耗。支持管道化技术，允许在同一个连接上同时发送多个请求，而不用等待上一个请求的响应，进一步提高了性能。还增加了请求头和响应头的字段，如 Host 字段，使得一台服务器可以在同一个 IP 地址和端口上同时服务多个域名。
HTTP2.0：采用二进制格式传输数据，相比于 HTTP1.x 的文本格式，解析更高效，错误率更低，并且更易于实现。支持多路复用，允许在一个连接上同时进行多个请求和响应的交错传输，解决了 HTTP1.1 中管道化技术的队首阻塞问题，大大提高了连接的利用率和性能。头部压缩功能可以对请求头和响应头进行压缩，减少了头部数据的传输量，提高了传输效率。
HTTP3.0：基于 UDP 协议而不是 TCP 协议，解决了 HTTP2.0 在 TCP 协议上存在的一些性能问题，如队首阻塞和连接建立延迟等。使用 QUIC 协议，它在 UDP 之上实现了类似 TCP 的可靠传输、流量控制和拥塞控制等功能，同时还具有更低的延迟和更好的移动性支持。支持零 RTT 连接建立，在某些情况下可以在第一次发送数据时就开始传输，而不需要等待连接建立完成，进一步提高了性能。

TCP/IP 协议，三次握手四次挥手 why？如何保证数据可靠性？数据包没有到达如何保证到达？

三次握手的原因：为了确保客户端和服务器之间的连接是可靠的双向连接。第一次握手，客户端向服务器发送 SYN 包，请求建立连接，此时客户端进入 SYN_SENT 状态，等待服务器确认。第二次握手，服务器收到 SYN 包后，向客户端发送 SYN+ACK 包，确认客户端的请求，同时自己也进入 SYN_RCVD 状态。第三次握手，客户端收到 SYN+ACK 包后，向服务器发送 ACK 包，确认服务器的连接请求，此时客户端和服务器都进入 ESTABLISHED 状态，连接建立成功。通过三次握手，可以防止已失效的连接请求报文段突然又传送到服务器，从而产生错误。
四次挥手的原因：因为 TCP 连接是全双工的，即双方都可以同时发送和接收数据，所以在关闭连接时需要双方都进行确认。第一次挥手，客户端向服务器发送 FIN 包，请求关闭连接，此时客户端进入 FIN_WAIT_1 状态。第二次挥手，服务器收到 FIN 包后，向客户端发送 ACK 包，确认客户端的关闭请求，此时服务器进入 CLOSE_WAIT 状态，客户端进入 FIN_WAIT_2 状态。第三次挥手，服务器处理完剩余的数据后，向客户端发送 FIN 包，请求关闭连接，此时服务器进入 LAST_ACK 状态。第四次挥手，客户端收到 FIN 包后，向服务器发送 ACK 包，确认服务器的关闭请求，此时客户端进入 TIME_WAIT 状态，等待 2MSL（最长报文段寿命）后进入 CLOSED 状态，服务器收到 ACK 包后直接进入 CLOSED 状态。
保证数据可靠性的方法：通过序列号和确认应答机制，发送方在发送数据时会为每个字节分配一个序列号，接收方收到数据后会返回确认应答，告知发送方已正确接收的数据范围，发送方根据确认应答来决定是否重发数据。还采用了超时重传机制，发送方在发送数据后会启动一个定时器，如果在定时器超时之前没有收到接收方的确认应答，就会重发数据。TCP 还通过流量控制和拥塞控制机制来避免网络拥塞和数据丢失，确保数据的可靠传输。
保证数据包到达的方法：除了上述的超时重传机制外，TCP 还采用了滑动窗口机制来控制发送方的发送速度和接收方的接收能力，确保接收方能够及时处理接收到的数据，避免数据丢失。同时，TCP 在网络层采用了 IP 协议，IP 协议提供了数据报的路由和转发功能，确保数据包能够在网络中正确传输，即使在传输过程中出现数据包丢失或损坏的情况，也可以通过上层的 TCP 协议进行重传和恢复。

说说 OSI 五层结构和 OSI 七层网络结构

OSI 五层结构：由下到上依次是物理层、数据链路层、网络层、传输层和应用层。物理层负责在物理介质上传输原始的比特流，定义了物理连接的机械、电气、功能和规程特性，如网线的规格、接口的形状等。数据链路层负责将物理层接收到的比特流组织成帧，进行差错检测和纠正，以及实现介质访问控制，如以太网中的 CSMA/CD 协议。网络层负责将数据链路层的帧封装成数据包，并进行路由选择和转发，使数据能够在不同的网络之间传输，如 IP 协议。传输层负责为应用层提供端到端的可靠或不可靠的传输服务，如 TCP 和 UDP 协议。应用层为用户提供各种网络应用服务，如 HTTP、FTP、SMTP 等协议。
OSI 七层网络结构：在 OSI 五层结构的基础上，增加了表示层和会话层。表示层负责处理数据的表示和转换，如加密、解密、压缩、解压缩等操作，使不同的系统能够正确地理解和处理数据。会话层负责建立、维护和管理会话，如会话的建立、拆除、同步等操作，使不同的应用程序之间能够进行有效的通信。OSI 七层网络结构更加详细和全面地描述了网络通信的过程和功能，但在实际应用中，由于其过于复杂，通常采用简化的 OSI 五层结构或 TCP/IP 四层模型。

TCP、UDP 在 OSI 七层模型四层模型中所在层级

在 OSI 七层模型中的位置：TCP 和 UDP 都位于传输层。传输层的主要功能是为应用层提供端到端的通信服务，负责将应用层的数据分割成适合网络传输的数据包，并在接收端将数据包重新组装成应用层的数据。TCP 和 UDP 通过不同的机制为应用层提供可靠或不可靠的传输服务，实现了不同的应用需求。
在 TCP/IP 四层模型中的位置：在 TCP/IP 四层模型中，TCP 和 UDP 同样位于传输层。TCP/IP 四层模型是在 OSI 七层模型的基础上进行简化和合并得到的，它将 OSI 七层模型中的物理层和数据链路层合并为网络接口层，将网络层、传输层和应用层分别对应为网际层、传输层和应用层。TCP 和 UDP 在 TCP/IP 四层模型中的功能和在 OSI 七层模型中的功能基本相同，都是为应用层提供传输服务。

HTTP 和 socket 区别

HTTP 是一种超文本传输协议，主要用于在网络上传输文本、图像、音频、视频等各种类型的数据，是一种基于请求 / 响应模式的无状态协议。而 Socket 是一种网络编程接口，它提供了一种在网络上进行双向通信的机制，允许应用程序在不同的主机之间进行数据传输，它本身并不是一种协议，而是一种实现网络通信的编程接口。

HTTP 基于 TCP 协议，通过请求和响应的方式进行数据交互，通常用于客户端向服务器获取网页、图片、视频等资源，或者向服务器提交表单数据等。而 Socket 则更加灵活，可以基于 TCP 或 UDP 协议，应用场景更为广泛，比如实时聊天系统、在线游戏、视频直播等对实时性要求较高的场景。

在连接方式上，HTTP 连接在一次请求 / 响应完成后通常会立即关闭连接，而 Socket 连接可以在建立连接后长时间保持连接状态，进行多次数据交互。在数据传输格式上，HTTP 有固定的报文格式，包括请求行、请求头、请求体和响应行、响应头、响应体等，而 Socket 传输的数据格式可以由开发者自行定义。

HTTP 基于 TCP 协议。TCP 协议提供了可靠的、面向连接的字节流传输服务，确保了数据在网络中的可靠传输。当客户端向服务器发送 HTTP 请求时，首先会通过 TCP 协议与服务器建立连接，然后将 HTTP 请求报文作为 TCP 报文段的数据部分发送给服务器。服务器接收到请求后，处理请求并将 HTTP 响应报文作为 TCP 报文段的数据部分发送回客户端。最后，客户端和服务器通过 TCP 协议关闭连接。

HTTP 成功消息，HTTP 4 开头的错误

HTTP 成功消息通常以状态码 200 开头，表示请求已成功被服务器接收、理解并处理。常见的成功消息还有 201 Created，表示请求成功并且服务器创建了新的资源；204 No Content，表示服务器成功处理了请求，但没有返回任何内容。

HTTP 4 开头的错误表示客户端错误，即请求中存在语法错误或无法完成请求。其中，400 Bad Request 表示客户端发送的请求语法错误，服务器无法理解；401 Unauthorized 表示请求要求用户的身份验证；403 Forbidden 表示服务器理解请求客户端的请求，但是拒绝执行此请求；404 Not Found 是最常见的错误之一，表示服务器无法找到请求的资源。

应用层协议了解多少，DNS 和 Http 在什么层

常见的应用层协议有 HTTP、DNS、FTP、SMTP、POP3 等。HTTP 用于在网络上传输超文本信息，实现网页浏览、数据交互等功能。DNS 主要用于将域名解析为 IP 地址，使得用户可以通过方便记忆的域名访问网络资源。FTP 用于在网络上进行文件传输，支持文件的上传和下载。SMTP 用于发送电子邮件，POP3 则用于接收电子邮件。

DNS 和 HTTP 都属于应用层协议。在网络通信中，应用层是最接近用户的一层，它为用户提供各种网络服务和应用程序接口。DNS 负责将域名转换为 IP 地址，使得用户可以使用域名来访问网络资源，而 HTTP 则负责在客户端和服务器之间传输超文本数据，实现网页浏览、数据交互等功能。

数据包在 tcp 中如何传输，数据包在网络中如何传输？

在 TCP 中，数据包的传输首先需要建立连接，通过三次握手来确保双方都准备好进行数据传输。发送方将应用层的数据进行分割和封装，添加 TCP 首部，形成 TCP 报文段。TCP 首部包含了源端口、目的端口、序列号、确认号、窗口大小等重要信息，用于保证数据的可靠传输和顺序控制。然后，TCP 报文段被交给 IP 层进行进一步封装，添加 IP 首部，形成 IP 数据包。IP 首部包含了源 IP 地址、目的 IP 地址等信息，用于在网络中路由数据包。

在网络中，IP 数据包根据目的 IP 地址进行路由选择，路由器根据路由表将数据包转发到下一跳路由器或目标主机所在的网络。在传输过程中，数据包可能会经过多个路由器和网络链路，每个路由器都会根据目的 IP 地址和自身的路由表进行转发决策。当数据包到达目标主机后，目标主机的 IP 层会对 IP 数据包进行解封装，将 TCP 报文段交给 TCP 层。TCP 层根据 TCP 首部中的信息进行校验、排序和确认等操作，将正确的报文段中的数据交给应用层。

HTTPS 为什么安全

首先，HTTPS 采用了 SSL/TLS 协议进行加密处理，在 SSL/TLS 握手阶段，客户端和服务器会协商出一套加密算法和密钥，之后的数据传输都使用该密钥进行加密，使得数据在传输过程中变成密文，黑客即使拦截到数据也难以破解其内容。其次，HTTPS 要求服务器拥有数字证书，数字证书由权威的证书颁发机构颁发，证书中包含了服务器的公钥和身份信息等，客户端在连接服务器时会验证证书的合法性，确认服务器的身份是否可信，有效防止中间人攻击。此外，SSL/TLS 协议还提供了消息完整性验证机制，通过在数据中添加消息验证码等方式，确保数据在传输过程中未被篡改，一旦数据被篡改，接收方可以及时发现并拒绝接受该数据。

HTTPS 流程以及如何加密，为什么不全部都用非对称加密

HTTPS 的流程如下：客户端向服务器发送连接请求，服务器返回其数字证书，客户端验证证书的合法性，包括证书是否由权威机构颁发、证书是否过期、证书中的域名与服务器域名是否一致等，如果证书验证通过，客户端会从证书中提取出服务器的公钥，然后客户端生成一个随机的对称密钥，并使用服务器的公钥对该对称密钥进行加密，发送给服务器，服务器使用自己的私钥解密得到对称密钥，之后客户端和服务器就可以使用该对称密钥对数据进行加密传输。在 HTTPS 中不全部使用非对称加密主要是因为非对称加密的效率较低，非对称加密算法复杂，计算量较大，在大量数据传输时会导致性能下降明显，而对称加密算法相对简单，加密和解密速度快，适合大量数据的加密传输，因此在实际应用中，HTTPS 采用非对称加密来传输对称密钥，然后使用对称加密来传输实际的数据，这样既能保证安全性又能兼顾效率。

非对称加密和对称加密区别

在加密密钥方面，对称加密使用的是同一个密钥进行加密和解密，发送方和接收方需要事先共享这个密钥；非对称加密则使用一对密钥，即公钥和私钥，公钥可以公开，任何人都可以获取，而私钥则由持有者严格保密，发送方使用接收方的公钥进行加密，接收方使用自己的私钥进行解密。在加密速度上，对称加密算法相对简单，加密和解密的速度非常快，适合对大量数据进行加密；非对称加密算法复杂，涉及到大量的数学运算，加密和解密的速度较慢，不适合对大量数据进行加密。在安全性上，对称加密的安全性依赖于密钥的保密性，如果密钥泄露，那么所有使用该密钥加密的数据都可能被破解；非对称加密中，公钥是公开的，私钥是保密的，即使公钥被获取，也很难通过公钥推导出私钥，因此安全性相对较高。在密钥管理上，对称加密需要在通信双方之间安全地共享密钥，在大规模的网络环境中，密钥的分发和管理较为复杂；非对称加密中，公钥可以公开分发，私钥由用户自己保管，密钥管理相对简单。

Ddos 攻击，TCP 攻击知道吗？如何进行攻击？

DDoS 攻击即分布式拒绝服务攻击，是一种通过控制大量的计算机（僵尸网络）向目标服务器发送海量请求，导致服务器资源耗尽，无法正常响应合法用户请求的攻击方式。攻击者通常会利用各种手段感染大量的主机，使其成为僵尸主机，然后通过控制这些僵尸主机向目标服务器发起攻击。常见的攻击手段包括发送大量的 TCP SYN 请求，利用 TCP 三次握手的漏洞，使服务器在等待客户端的 ACK 确认时，占用大量的连接资源，导致正常的连接请求无法得到处理；还可以发送大量的 UDP 数据包，使服务器的网络带宽被占满，无法正常处理其他请求；另外，攻击者也可能利用应用层的漏洞，发送大量的 HTTP 请求等，使服务器的 CPU 和内存资源耗尽。

TCP 攻击主要是针对 TCP 协议的漏洞进行攻击，除了上述提到的 SYN Flood 攻击外，还有 ACK Flood 攻击，攻击者向服务器发送大量伪造的 ACK 包，使服务器忙于处理这些无效的 ACK 包，消耗服务器的资源；还有 RST Flood 攻击，攻击者通过发送伪造的 RST 包，中断合法的 TCP 连接，影响服务器的正常服务；另外，还有 TCP 会话劫持攻击，攻击者通过嗅探等手段获取合法用户的 TCP 会话信息，然后伪造数据包插入到会话中，获取敏感信息或篡改数据等。这些攻击行为都是非法和不道德的，会对网络安全和正常的网络服务造成严重的破坏。

输入一个美团 url，出现网页都发生了那些过程，每个层级都发生了什么事

当在浏览器中输入美团的 URL 后，首先在应用层，浏览器会对 URL 进行解析，提取出协议、域名、路径等信息。然后根据域名进行 DNS 解析，通过 DNS 服务器将域名转换为对应的 IP 地址，这一过程涉及到向多个 DNS 服务器查询，直到获取到目标 IP 地址。

在传输层，浏览器与服务器之间建立 TCP 连接，通过三次握手确保连接的可靠性。连接建立后，浏览器会根据 HTTP 协议向服务器发送 HTTP 请求报文，包括请求方法、URL、协议版本、请求头和请求体等，请求报文会被分割成多个 TCP 数据包进行传输。

网络层负责将 TCP 数据包封装成 IP 数据包，并根据目标 IP 地址进行路由选择，通过路由器等网络设备将数据包转发到目标服务器所在的网络。

数据链路层将 IP 数据包封装成帧，通过物理介质如网线、无线信号等将数据传输到下一个网络节点，如路由器或交换机等，每个节点会对帧进行解封装和转发，直到到达目标服务器。

服务器接收到请求后，按照相反的过程进行处理，将响应报文通过 TCP 连接发送回浏览器，浏览器接收到响应后，对报文进行解析，根据响应头中的信息判断内容类型，如 HTML、CSS、JavaScript 等，并进行相应的渲染和显示，最终呈现出美团的网页。

说说 TCP 的报文

TCP 报文由首部和数据部分组成。首部包含多个字段，主要有：

源端口和目的端口：各占 2 个字节，用于标识发送方和接收方的应用程序进程，使数据能够准确地在不同的应用之间传输。
序号：占 4 个字节，用于标识 TCP 报文段所发送的数据在整个数据流中的位置，保证数据的顺序性和完整性，接收方可以根据序号对收到的数据进行排序和重组。
确认号：占 4 个字节，是对对方发送的序号的确认，表示期望收到对方下一个报文段的序号，用于确认已经正确接收的数据。
首部长度：占 4 位，以 4 字节为单位表示 TCP 首部的长度，因为 TCP 首部的长度是可变的，需要这个字段来指示首部的实际长度。
保留字段：占 6 位，目前尚未使用，通常设置为 0。
控制位：共 6 个比特，分别为 URG、ACK、PSH、RST、SYN、FIN，用于控制 TCP 连接的建立、维护和拆除，以及数据传输的方式等。
窗口大小：占 2 个字节，用于告知对方本端的接收窗口大小，即能够接收的数据量，以便对方控制发送数据的速率，实现流量控制。
校验和：占 2 个字节，用于检验 TCP 报文段在传输过程中是否出现错误，发送方在发送报文段之前计算校验和，接收方在收到报文段后重新计算校验和并与发送方的校验和进行比较，如果不一致则说明报文段在传输过程中出现了错误。
紧急指针：占 2 个字节，只有当 URG 控制位为 1 时才有效，用于指示紧急数据在报文段中的位置。

数据部分则是实际要传输的应用层数据，长度不固定，根据具体的应用需求和网络状况而定。

android 生命周期和各部分的区别

Android 的生命周期主要包括 Activity、Service、Broadcast Receiver 和 Content Provider 等组件的生命周期。

Activity 生命周期：从创建到销毁经历多个阶段，如 onCreate () 在 Activity 首次创建时调用，用于进行初始化操作，如加载布局、绑定数据等；onStart () 在 Activity 即将可见时调用；onResume () 在 Activity 获取焦点并可以与用户交互时调用；onPause () 在 Activity 失去焦点但仍然可见时调用，通常用于保存临时数据等；onStop () 在 Activity 完全不可见时调用；onDestroy () 在 Activity 即将被销毁时调用，用于释放资源等。不同的 Activity 状态之间的转换时机和操作重点各不相同，例如从后台恢复到前台时，会依次调用 onRestart ()、onStart ()、onResume ()。
Service 生命周期：分为两种启动方式，startService () 启动的 Service 会经历 onCreate ()、onStartCommand () 等方法，主要用于执行长时间运行的后台任务，如后台下载等，即使启动它的组件销毁了，Service 仍然可以继续运行；bindService () 启动的 Service 会经历 onCreate ()、onBind () 等方法，主要用于与其他组件进行交互，当所有绑定的组件都解除绑定后，Service 会自动销毁。
Broadcast Receiver 生命周期：是一种用于接收系统或应用发出的广播消息的组件，其生命周期非常短暂，在接收到广播时会调用 onReceive () 方法，在该方法执行完毕后，Broadcast Receiver 的实例就会被销毁，因此在 onReceive () 方法中不能执行耗时操作。
Content Provider 生命周期：在 Content Provider 被创建时会调用 onCreate () 方法，通常用于初始化数据库连接等资源，在整个应用的运行过程中，Content Provider 会一直存在，直到应用被销毁。

Activity A 启动 Activity B A 和 B 的调用情况

当 Activity A 启动 Activity B 时，首先在 Activity A 中会调用 startActivity () 或 startActivityForResult () 方法，这会触发系统的一系列操作。

系统会暂停 Activity A 的执行，此时会调用 Activity A 的 onPause () 方法，在该方法中，Activity A 会失去焦点，但仍然可见，通常可以在该方法中保存一些临时数据，如用户在界面上输入但尚未提交的内容等。

然后系统会创建 Activity B 的实例，并调用其 onCreate () 方法进行初始化操作，如加载布局、绑定数据等。接着会调用 Activity B 的 onStart () 方法，此时 Activity B 即将可见，再调用 onResume () 方法，使 Activity B 获取焦点并可以与用户交互。

在 Activity B 启动完成后，如果 Activity A 不再需要显示在前台，系统会调用 Activity A 的 onStop () 方法，使 Activity A 完全不可见。如果在启动 Activity B 时使用了 startActivityForResult () 方法，那么在 Activity B 完成操作并返回结果时，会调用 Activity A 的 onActivityResult () 方法，将结果传递给 Activity A，以便 Activity A 根据结果进行相应的处理。

如何摧毁一个 Activity

在 Android 中，可以通过多种方式摧毁一个 Activity。

在代码中手动调用 finish () 方法：可以在 Activity 内部的任何地方调用该方法，例如在某个按钮的点击事件处理方法中，当用户点击按钮时，执行 finish () 方法，此时系统会立即调用 Activity 的 onDestroy () 方法来销毁该 Activity，释放其占用的资源。
按返回键：当用户按下手机的返回键时，系统会自动调用当前 Activity 的 onBackPressed () 方法，默认情况下，该方法会调用 finish () 方法来销毁当前 Activity。当然，也可以重写 onBackPressed () 方法，根据具体的业务需求来决定是否销毁 Activity 或进行其他操作。
通过系统回收机制：当系统内存不足时，会自动回收处于后台的 Activity，系统会首先调用 Activity 的 onSaveInstanceState () 方法来保存 Activity 的状态信息，然后调用 onDestroy () 方法来销毁 Activity。当用户再次回到该 Activity 时，系统会根据之前保存的状态信息来恢复 Activity 的界面和数据。
在其他组件中调用 finishActivity () 方法：例如在 Service 或 Broadcast Receiver 中，如果需要销毁某个特定的 Activity，可以通过获取该 Activity 的引用或使用 Activity 的任务栈信息，然后调用 finishActivity () 方法来销毁指定的 Activity。

onStart，onResume 的区别，onPause 和 onStop 区别

onStart 方法在 Activity 开始被用户可见时调用，但此时 Activity 可能还没有获取焦点，无法与用户进行交互。例如，当一个透明的 Activity 在另一个 Activity 之上启动时，被覆盖的 Activity 会先执行 onPause 方法，然后新的 Activity 执行 onStart 方法，但此时被覆盖的 Activity 仍然可见，只是失去了焦点。

onResume 方法在 Activity 准备好与用户进行交互时调用，此时 Activity 已经获取了焦点，用户可以对其进行操作。比如，当一个 Activity 从后台重新回到前台时，会先执行 onRestart 方法，然后执行 onStart 方法，最后执行 onResume 方法，此时 Activity 就可以正常地接收用户的输入和操作。

onPause 方法在 Activity 失去焦点但仍然可见时调用，通常用于暂停一些动画、视频播放等操作，以及保存一些临时数据。因为这个方法执行时，Activity 可能很快就会重新获取焦点或者被销毁，所以不能执行耗时操作，否则会影响用户体验，甚至可能导致系统出现 ANR（Application Not Responding）错误。

onStop 方法在 Activity 完全不可见时调用，此时可以进行一些更重量级的资源释放操作，比如关闭数据库连接、停止网络请求等。但需要注意的是，如果系统内存紧张，处于 onStop 状态的 Activity 可能会被系统回收。

为什么 onPause 不能执行耗时操作

首先，onPause 方法执行时，Activity 可能很快就会重新获取焦点或者被销毁。如果在 onPause 中执行耗时操作，会导致 Activity 切换不流畅，用户可能会感觉到明显的卡顿，影响用户体验。例如，在从一个 Activity 切换到另一个 Activity 时，如果前一个 Activity 的 onPause 方法执行耗时过长，那么新的 Activity 就不能及时显示出来，用户会看到长时间的白屏或者等待界面。

其次，Android 系统对于应用的响应性有严格的要求，如果在 onPause 方法中执行耗时操作超过一定时间，系统会认为应用无响应，从而弹出 ANR 对话框，这对于用户来说是非常糟糕的体验，可能会导致用户直接关闭应用。

最后，在 onPause 方法中执行耗时操作可能会导致一些不可预期的问题。比如，如果在 onPause 中进行网络请求，而此时网络环境发生变化或者用户快速切换 Activity，可能会导致网络请求失败或者数据不一致等问题。

说说 Activity 的四种启动模式和区别

standard：这是默认的启动模式。每次启动一个 Activity 时，都会创建一个新的实例并放入任务栈中。例如，在一个应用中，多次点击同一个按钮启动同一个 Activity，每次都会创建一个新的 Activity 实例，这些实例会依次放入任务栈中，按返回键时会依次出栈。
singleTop：如果要启动的 Activity 已经位于任务栈的栈顶，那么不会创建新的实例，而是直接复用栈顶的实例，并调用其 onNewIntent 方法。如果要启动的 Activity 不在栈顶，则会创建新的实例并放入栈顶。比如，在一个新闻阅读应用中，点击新闻列表中的一篇新闻进入新闻详情页，如果再次点击同一篇新闻，由于详情页已经在栈顶，就不会重新创建，而是直接更新内容。
singleTask：在整个任务栈中，只会存在一个该 Activity 的实例。如果要启动的 Activity 已经存在于任务栈中，那么系统会将该 Activity 之上的所有其他 Activity 出栈，使该 Activity 位于栈顶。例如，在一个应用中，有登录页面和主页面，登录成功后进入主页面，当再次点击登录按钮时，由于登录页面已经存在于任务栈中，系统会将主页面出栈，使登录页面位于栈顶，而不是创建新的登录页面实例。
singleInstance：该模式会为每个使用该启动模式的 Activity 创建一个单独的任务栈。例如，在一个应用中，有一个视频播放 Activity 采用了 singleInstance 启动模式，当从其他 Activity 启动该视频播放 Activity 时，会创建一个新的任务栈来存放该视频播放 Activity，并且该任务栈中只有这一个 Activity。当视频播放 Activity 启动其他 Activity 时，会在另一个新的任务栈中创建，与视频播放 Activity 所在的任务栈相互独立。

SingleTop 和 SingleTask 启动模式的应用场景

SingleTop：适用于一些频繁启动但又不希望重复创建的 Activity，并且该 Activity 在栈顶时可能需要接收新的意图来更新界面或数据。比如，浏览器的书签页面，用户可能会频繁地在不同页面之间切换并回到书签页面，如果每次都重新创建书签页面会浪费资源，而使用 SingleTop 模式可以在书签页面位于栈顶时直接复用，同时可以通过 onNewIntent 方法更新书签内容。
SingleTask：常用于应用中的主界面或者登录界面等。对于主界面，通常希望在整个应用的生命周期中只有一个实例存在，并且在从其他界面返回主界面时，能够快速地显示出来，而不需要重新创建和加载。对于登录界面，当用户已经登录成功后，再次进入登录界面时，应该直接显示之前的登录界面，而不是重新创建一个新的登录界面，这样可以保证登录状态的一致性和用户数据的安全性。

Activity 生命周期变化（如 Activity A -> B 生命周期变化等多种类似表述场景）

当从 Activity A 启动 Activity B 时，Activity A 会先执行 onPause 方法，此时 Activity A 失去焦点但仍然可见。然后 Activity B 会依次执行 onCreate、onStart、onResume 方法，当 Activity B 的 onResume 方法执行完毕后，Activity A 会执行 onStop 方法，如果系统内存紧张，处于 onStop 状态的 Activity A 可能会被系统回收。

如果在 Activity B 中按返回键返回 Activity A，Activity B 会先执行 onPause 方法，然后 Activity A 会执行 onRestart、onStart、onResume 方法，最后 Activity B 会执行 onStop、onDestroy 方法。

如果在 Activity B 中启动透明的 Activity C，Activity B 会先执行 onPause 方法，然后 Activity C 会依次执行 onCreate、onStart、onResume 方法，此时 Activity B 仍然可见，但失去了焦点，不会执行 onStop 方法。当 Activity C 被关闭后，Activity B 会重新获取焦点，执行 onResume 方法。

如果在 Activity A 中启动一个对话框风格的 Activity D，Activity A 的生命周期不会发生变化，因为对话框风格的 Activity D 不会覆盖整个屏幕，Activity A 仍然可见且有焦点，只有当 Activity D 获取焦点时，Activity A 会失去焦点，但不会执行 onPause 方法。

Android 四大组件

Android 四大组件分别是 Activity、Service、Broadcast Receiver 以及 Content Provider。

Activity 是用于构建用户界面，与用户进行交互的组件，一个 Activity 通常对应一个屏幕的内容，比如在一个社交应用中，登录界面、好友列表界面、聊天界面等都是一个个不同的 Activity，用户可以通过点击、滑动等操作与之交互，它有着完整的生命周期，从创建、启动到暂停、停止以及销毁等阶段，每个阶段都有相应的回调方法用于开发者处理不同的业务逻辑，像初始化布局、保存数据等操作。

Service 主要用于在后台执行长时间运行的操作，不提供用户界面，例如在音乐播放应用中，后台播放音乐的任务就可以交给 Service 来完成，它不会因为切换应用或者手机锁屏等情况而中断，持续运行在后台，并且可以与其他组件进行协作，为应用提供各种后台服务支持。

Broadcast Receiver 用于接收系统或者应用发出的广播消息，像是电池电量变化、网络连接状态改变等系统广播，以及应用内自定义的广播，都能被它捕捉到，然后执行相应的逻辑，比如当手机电量过低时，应用可以通过 Broadcast Receiver 接收到这个广播，进而提醒用户及时充电或者自动采取一些节省电量的措施。

Content Provider 用于在不同的应用之间共享数据，它可以将应用内部的数据，如数据库中的数据等，以一种安全且规范的方式提供给其他应用访问，例如联系人应用的数据，就可以通过 Content Provider 让其他需要获取联系人信息的应用来使用，实现了数据的跨应用共享，保障了数据的安全性和一致性。

Service 的启动方法及有什么区别

Service 有两种常见的启动方法，分别是 startService 和 bindService，它们有着明显的区别。

使用 startService 方法启动 Service 时，一旦调用 startService 方法，系统会先创建 Service 实例（如果不存在的话），然后调用其 onCreate 方法进行初始化，接着会调用 onStartCommand 方法，这个方法可以接收 Intent 参数，开发者可以通过这个 Intent 传递一些数据来控制 Service 要执行的具体任务，比如传递一个下载链接让 Service 去后台下载文件等。这种启动方式下的 Service 会独立于启动它的组件运行，即使启动它的 Activity 等组件被销毁了，Service 依然会在后台持续运行，直到它自己内部执行完任务或者调用了 stopSelf 方法来停止，或者被其他组件调用 stopService 方法来强制停止。

而通过 bindService 方法启动 Service，系统同样会先创建 Service 实例（如果不存在的话）并调用 onCreate 方法初始化，随后调用 onBind 方法，这个方法会返回一个 IBinder 对象，通过这个对象，绑定的组件（如 Activity）可以与 Service 进行通信，实现数据交互等操作。采用这种启动方式，Service 的生命周期与绑定它的组件相关联，当所有绑定的组件都解除绑定（调用 unbindService 方法）后，Service 就会被销毁，所以它主要用于需要和其他组件紧密交互的场景，比如音乐播放服务，Activity 可以通过绑定 Service 来控制音乐的播放、暂停、切换歌曲等操作，当 Activity 关闭了，不再需要音乐播放功能时，Service 也就随之停止了。

如何在 Activity 和 Service 进行通信

在 Activity 和 Service 之间进行通信可以通过多种方式来实现。

一种常用的方式是通过使用 bindService 启动 Service 并借助 IBinder 接口来通信。首先在 Service 中创建一个内部类继承自 Binder，在这个内部类里可以定义一些公共的方法用于操作 Service 内部的数据或者执行相关的任务，比如对于一个音乐播放 Service，可以在 Binder 类里定义播放、暂停、获取当前播放进度等方法。然后在 Service 的 onBind 方法中返回这个 Binder 实例。在 Activity 中，通过调用 bindService 方法绑定这个 Service，绑定成功后会得到对应的 IBinder 对象，将其强制转换为之前定义的 Binder 类型，之后就可以通过这个对象调用 Service 里定义的方法，实现 Activity 对 Service 的控制以及数据的获取等操作，比如 Activity 中点击播放按钮，就可以调用 Service 里的播放方法来启动音乐播放。

另一种方式是使用广播机制来通信。Service 可以在需要向 Activity 传递消息时发送广播，比如 Service 完成了某个长时间的后台任务，像文件下载完成了，就可以发送一个自定义广播，并且可以在广播中携带一些相关的数据，比如下载文件的路径等。在 Activity 中则注册对应的广播接收器来接收这个广播，一旦接收到广播，就可以从广播的 Intent 中提取数据，并根据这些数据进行相应的操作，比如弹出提示框告知用户文件下载成功等。

此外，还可以利用 Messenger 来实现通信，在 Service 端创建一个 Handler 来处理消息，然后用这个 Handler 创建一个 Messenger 对象，在 onBind 方法中返回这个 Messenger 对应的 Binder 对象。在 Activity 端同样创建一个 Messenger 对象，并将其与 Service 返回的 Binder 对象关联起来，之后 Activity 就可以通过 Messenger 向 Service 发送消息，Service 的 Handler 接收到消息后进行相应的处理，实现双方的交互。

广播的作用，注册方法

广播在 Android 系统中有着重要的作用。

从系统层面来说，它能够及时告知应用一些系统状态的变化，例如当系统的网络连接状态发生改变，从有网络变为无网络或者切换了不同的网络类型（如从 WiFi 切换到移动数据）时，系统会发送相应的网络状态广播，应用接收到这个广播后，可以根据实际情况做出调整，比如暂停正在进行的网络视频播放，或者提示用户网络连接异常等。再比如当手机的电量发生变化，电量过低或者充满电时，也会有对应的广播发出，应用可以据此采取节能措施或者提醒用户拔下充电器等操作。

从应用自身角度来看，广播可以用于应用内不同组件之间的消息传递以及模块间的协同工作，比如在一个电商应用中，用户在购物车页面修改了商品数量，就可以发送一个自定义广播，让其他相关页面（如商品详情页、结算页等）接收到广播后更新相应的数据显示，保证整个应用数据的一致性。

广播的注册方法主要有两种，即静态注册和动态注册。

静态注册是在 AndroidManifest.xml 文件中进行声明，通过<receiver>标签来定义广播接收器，需要指定广播接收器的类名，并且可以设置接收的广播类型（可以是系统定义的广播类型或者自定义的广播类型），例如要接收开机广播，就可以在<receiver>标签内添加<intent-filter>，设置其 action 为 android.intent.action.BOOT_COMPLETED，这样当手机开机时，对应的广播接收器就会被触发并执行相应的逻辑。不过静态注册的广播接收器在应用安装时就会被系统知晓，会一直处于监听状态，相对比较消耗系统资源。

动态注册则是在代码中进行操作，通常在 Activity 或者 Service 等组件的生命周期方法里实现，比如在 Activity 的 onCreate 方法中，先创建一个 Broadcast Receiver 的实例，然后通过 registerReceiver 方法来注册，在注册时同样需要传入 IntentFilter 来指定要接收的广播类型，与静态注册不同的是，动态注册的广播接收器可以根据组件的运行状态灵活地开启和关闭监听，比如在 Activity 的 onDestroy 方法中，可以调用 unregisterReceiver 方法来取消注册，避免不必要的资源消耗，适用于只在组件运行期间需要监听广播的场景。

Content Provider 的作用

Content Provider 在 Android 系统中起着关键的数据共享作用。

一方面，它能够实现应用内部不同模块之间的数据共享，在一个复杂的大型应用中，往往有着多个功能模块，各个模块可能都需要访问同一份底层数据，比如用户的个人信息数据存储在数据库中，登录模块、个人资料编辑模块、订单模块等都可能需要读取或者修改这些数据，通过 Content Provider，可以以一种统一、规范的方式让这些不同的模块方便地访问数据，保证了数据访问的安全性和一致性，避免了每个模块都直接操作数据库可能带来的混乱和安全隐患。

另一方面，更为重要的是它支持不同应用之间的数据共享，不同的应用开发者可能需要共享某些特定的数据，例如联系人应用会将用户的联系人信息通过 Content Provider 提供出来，那么其他有需求的应用，像短信群发应用就可以获取联系人信息来选择收件人，或者社交应用可以根据联系人信息来推荐好友等。Content Provider 通过定义标准的接口，让外部应用可以在遵循一定权限规则的情况下，使用统一的 ContentResolver 来查询、插入、更新和删除数据，保障了数据在跨应用共享时的合法性和安全性，同时也使得应用间的数据交互更加便捷、有序，提升了整个 Android 生态系统中数据的利用效率和应用的协同性。

Android 中解决滑动冲突的方式

在 Android 开发中，滑动冲突是常见的问题，主要出现在嵌套滑动或者多个可滑动控件并存的场景下，以下是几种常见的解决方式。

外部拦截法

这种方法是在父容器中进行事件拦截处理。父容器重写 onInterceptTouchEvent 方法，通过判断触摸事件的相关条件来决定是否拦截子 View 的触摸事件。比如，根据触摸的坐标范围、滑动方向等来确定。如果父容器判断当前触摸事件应该由自己处理，那就返回 true 拦截，然后在父容器的 onTouchEvent 方法中处理相应的滑动逻辑；要是判断事件该由子 View 处理，就返回 false 放行，让子 View 能接收到触摸事件进行处理。例如，在一个包含可滑动列表的页面布局中，页面本身可以上下滑动，列表也能上下滑动，当手指在页面边缘滑动时，父容器可以判断这是对整个页面的操作，拦截事件进行页面的滑动；而在列表区域滑动时，就放行让列表处理滑动事件。

内部拦截法

与外部拦截法不同，它主要在子 View 层面来控制事件是否被拦截。子 View 需要重写 dispatchTouchEvent 方法，在里面通过 getParent ().requestDisallowInterceptTouchEvent (true) 这样的代码来告知父容器不要拦截事件，也就是子 View 希望自己先处理触摸事件。不过，父容器还是要配合，在其 onInterceptTouchEvent 方法中，要根据子 View 的请求以及触摸的实际情况合理地决定是否拦截。比如在一个可滑动的自定义 View 嵌套在一个能滑动的父布局中的场景，子 View 在特定的触摸动作下（比如水平滑动时）请求父容器不要拦截，父容器收到请求后结合自身逻辑判断确实不拦截，让子 View 处理水平滑动相关的事件，而垂直滑动等情况父容器可以选择拦截进行处理。

利用事件分发机制的规则调整布局结构

合理利用 Android 的事件分发机制以及不同 View 的层级关系来解决冲突。比如将容易产生滑动冲突的两个可滑动 View 设置为兄弟关系，而不是嵌套关系，然后通过外层的父容器（比如 LinearLayout 等布局）来统一协调它们的滑动逻辑，根据触摸点的位置、滑动方向等去决定哪个 View 响应滑动事件。再比如，对于一些嵌套的滑动场景，可以使用 NestedScrollView 等已经内置了良好滑动协调机制的容器来替代普通的布局，减少滑动冲突出现的可能性，让内部的子 View 和外层容器能按照预期合理地分配触摸事件，实现流畅的滑动体验。

利用滑动辅助类或自定义滑动逻辑

可以借助一些已有的滑动辅助类，像 ViewPager2，它内部对于页面切换和内部子 View 的滑动有很好的协调机制，能够避免很多常见的滑动冲突情况。或者开发者根据具体需求自定义滑动逻辑，通过计算触摸点的位移、速度等参数，精确地判断滑动事件应该归属哪个 View 处理。例如在一个有多个可滑动卡片且卡片内还有列表可滑动的复杂界面中，通过自定义逻辑，分析每次触摸滑动的方向、起始点以及滑动的距离变化等，来决定是让卡片整体滑动切换还是让卡片内的列表进行滑动展示内容，以此解决滑动冲突问题。

View 的绘制过程（非常详细地说）

View 的绘制过程主要分为三个阶段，分别是测量（Measure）、布局（Layout）和绘制（Draw）阶段，每个阶段都有着明确的职责和复杂的内部操作。

测量阶段（Measure）

这一阶段的目的是确定 View 的大小。对于一个 View 树（由多个 View 及其子 View 组成的层次结构），从根 View（通常是 DecorView）开始，自上而下地遍历每个 View 进行测量。每个 View 会调用其 measure 方法，measure 方法又会调用 onMeasure 方法，在 onMeasure 方法中，View 会根据自身的布局参数（比如 LayoutParams 中设定的宽度和高度是具体数值、match_parent 还是 wrap_content 等）以及父 View 传递下来的测量要求（通过 MeasureSpec 参数体现）来确定自己的测量宽高。对于简单的 View，比如 TextView，它会根据文本内容的长度、字体大小、设置的内边距等因素来计算出合适的宽高；对于 ViewGroup 类型的 View，它除了要考虑自身的布局需求，还要遍历所有的子 View，分别调用子 View 的 measure 方法，让子 View 进行测量，并且根据子 View 的测量结果以及自身的布局规则（比如 LinearLayout 是水平还是垂直排列，如何分配子 View 之间的空间等）来综合确定自己的测量宽高。这个过程是一个递归的过程，直到所有的 View 都完成了测量，最终确定整个 View 树中每个 View 的测量尺寸。

布局阶段（Layout）

在测量阶段确定了 View 的大小后，就进入布局阶段。同样是从根 View 开始，自上而下地遍历 View 树。每个 View 会调用其 layout 方法，layout 方法内部会调用 onLayout 方法（ViewGroup 类型的 View 需要重写 onLayout 方法来确定子 View 的位置，而普通 View 的 onLayout 方法通常是空实现，因为它没有子 View 需要布局）。在 onLayout 方法中，ViewGroup 会根据自身的布局规则以及子 View 在测量阶段确定的大小，来确定每个子 View 的具体位置（通过设置子 View 的四个顶点坐标，即 left、top、right、bottom 来确定其在父 View 中的位置）。例如，LinearLayout 在水平布局时，会按照子 View 的顺序依次从左到右排列子 View，根据子 View 的宽度以及设置的间距等参数来准确计算出每个子 View 的 left 和 right 坐标，垂直布局时则是从上到下进行类似的操作。通过这个阶段，整个 View 树中的每个 View 都明确了自己在父 View 以及整个界面中的具体位置。

绘制阶段（Draw）

经过前面的测量和布局阶段，每个 View 的大小和位置都确定了，接下来就是绘制阶段，这个阶段主要负责将 View 的内容绘制到屏幕上。绘制过程也是从根 View 开始，自上而下地遍历 View 树，每个 View 会调用其 draw 方法来启动绘制流程。draw 方法内部又包含了多个步骤，首先会调用 drawBackground 方法来绘制 View 的背景，比如设置的纯色背景、渐变背景或者图片背景等都会在这个时候被绘制出来。接着会调用 onDraw 方法，这是每个 View 自定义绘制内容的关键地方，比如 TextView 会在 onDraw 方法中绘制文本内容，ImageView 会绘制图片内容等，开发者可以通过重写 onDraw 方法来实现自己想要的个性化绘制效果。之后会调用 dispatchDraw 方法，这个方法主要是针对 ViewGroup 类型的 View，它会遍历所有的子 View，调用子 View 的 draw 方法，让子 View 进行绘制，从而实现整个 View 树内容的完整绘制。最后还会调用 onDrawForeground 方法来绘制一些前景相关的内容，比如滚动条等装饰性元素，通过这一系列的步骤，整个 View 树的内容就清晰地呈现在屏幕上了。

如何确定一个 View 的 MS？那 DecorView 呢？

确定一个普通 View 的 MS（MeasureSpec）

MeasureSpec 是 View 测量过程中的一个重要概念，它实际上是一个 32 位的 int 值，其中高 2 位代表测量模式，低 30 位代表测量大小。要确定一个 View 的 MeasureSpec，需要考虑它的父 View 以及自身的布局参数。

首先，父 View 在测量子 View 时，会根据自身的布局模式以及剩余可用空间等因素，为子 View 传递一个 MeasureSpec 值。这个传递的过程遵循一定的规则，比如父 View 是 LinearLayout 且为水平布局，如果它的宽度是固定值，那么分给子 View 的总宽度就是父 View 宽度减去子 View 之间的间距以及父 View 的内边距等，然后根据子 View 的布局参数（如宽度是 wrap_content 还是 match_parent 等）来确定传递给子 View 的 MeasureSpec 的测量模式和大小范围。

对于子 View 自身来说，如果它的布局参数中宽度（或高度）设置为具体的数值，比如 100dp，那么它对应的 MeasureSpec 的测量模式就是 EXACTLY，表示精确的尺寸，其大小就是对应的数值转换后的像素值。要是布局参数是 match_parent，那么它的测量模式会根据父 View 的剩余空间情况来确定，通常在父 View 的尺寸确定的情况下也是 EXACTLY 模式，大小和父 View 的对应尺寸相同（减去一些边距等因素）。而如果是 wrap_content，测量模式一般是 AT_MOST，表示子 View 的大小最多不能超过父 View 分配给它的空间范围，子 View 需要根据自身内容等因素来确定具体尺寸，比如 TextView 会根据文本长度、字体大小等来确定 wrap_content 时的宽度。

通过综合考虑父 View 传递的 MeasureSpec 以及自身的布局参数，就能准确地确定一个普通 View 的 MeasureSpec，进而在 onMeasure 方法中依据这个 MeasureSpec 来正确地测量自身的尺寸。

确定 DecorView 的 MS

DecorView 是整个 Activity 界面的根 View，它承载了整个窗口的内容，包括状态栏、标题栏（如果有）以及我们实际开发中设置的内容 View 等。

系统在创建 Activity 时，会对 DecorView 进行测量等操作。对于 DecorView 的 MeasureSpec，它的测量模式和大小与手机屏幕的尺寸以及 Activity 的窗口设置等密切相关。通常情况下，它的宽度的测量模式是 EXACTLY，大小就是手机屏幕的宽度（去除一些系统预留的边距等情况），因为 DecorView 需要填满整个手机屏幕的横向空间；高度的测量模式也是 EXACTLY，大小会根据是否有状态栏、导航栏以及 Activity 的布局模式等来确定，比如如果是全屏模式，高度就是屏幕的总高度，要是有状态栏等，高度就是屏幕高度减去状态栏的高度等相关部分。

在 Activity 的创建过程中，系统会按照窗口管理的相关规则和默认的布局参数，为 DecorView 生成合适的 MeasureSpec，然后通过测量、布局、绘制等流程，将 DecorView 以及其包含的所有子 View 正确地展示在手机屏幕上，使得整个 Activity 的界面呈现出我们预期的效果。

View 的事件分发机制（非常详细地说，要包括事件处理机制，滑动冲突，View 事件分发）

View 的事件分发机制概述

View 的事件分发机制是 Android 中处理用户触摸等交互事件的一套复杂但有序的流程，它涉及到三个重要的方法，分别是 dispatchTouchEvent、onInterceptTouchEvent 和 onTouchEvent 方法，这三个方法在不同层级的 View（主要是 ViewGroup 和普通 View）中有着不同的作用和执行逻辑，共同决定了触摸事件如何在 View 树中传递和处理。

事件分发的起点和流程

当用户在屏幕上进行触摸操作时，触摸事件首先会被传递到 Activity 的 dispatchTouchEvent 方法，Activity 会将事件传递给它内部的顶层 View，也就是 DecorView，然后从 DecorView 开始，沿着 View 树自上而下地进行事件分发。

事件分发在 ViewGroup 中的情况

对于 ViewGroup 来说，它的 dispatchTouchEvent 方法是事件分发的关键入口。在这个方法中，它首先会调用 onInterceptTouchEvent 方法来判断是否要拦截事件。onInterceptTouchEvent 方法返回一个布尔值，如果返回 true，表示 ViewGroup 决定拦截这个触摸事件，那么后续的触摸事件（比如后续的移动、抬起等事件）都将由这个 ViewGroup 自己来处理，不会再传递给子 View 了，此时会调用 ViewGroup 自身的 onTouchEvent 方法来处理事件；如果返回 false，说明 ViewGroup 不拦截事件，会继续将事件分发给子 View，通过遍历子 View，按照一定的顺序（比如子 View 在布局中的顺序等）调用子 View 的 dispatchTouchEvent 方法，让子 View 来处理触摸事件。

在决定是否拦截事件时，ViewGroup 通常会根据触摸的坐标、滑动的方向等因素来判断。比如，一个横向滑动的 ViewGroup，当检测到用户手指是在水平方向滑动时，可能就不拦截事件，让子 View 去处理（假设子 View 可以处理水平滑动相关的事件），但如果检测到是垂直方向滑动，而这个 ViewGroup 自身想要处理垂直滑动的情况，就会拦截事件进行自己的处理。

事件分发在普通 View 中的情况

普通 View 没有 onInterceptTouchEvent 方法，因为它没有子 View，不需要拦截事件分发给其他子 View。对于普通 View，当它的 dispatchTouchEvent 方法被调用时，主要就是看它的 onTouchEvent 方法的返回值。如果 onTouchEvent 方法返回 true，表示这个 View 能够处理该触摸事件，那么这个事件就被这个 View 处理掉了，后续的同一系列触摸事件（比如一次点击操作包含的按下、移动、抬起等事件）都会由它来处理；如果返回 false，说明这个 View 不能处理这个事件，那么事件会沿着 View 树向上回传，也就是会传递给它的父 View 的 onTouchEvent 方法，让父 View 来看看是否能处理，以此类推，直到事件被处理或者传递到 Activity 的 onTouchEvent 方法，如果最终都没有被处理，那这个触摸事件就相当于被忽略了。

事件处理机制中的 onTouch 和 onClickListener 等的关系

除了上述的三个核心方法外，在 View 的事件处理中，还涉及到 onTouch、onClickListener 等回调方法。onTouch 方法是通过设置 View 的 OnTouchListener 来监听触摸事件的，它会在 View 的 onTouchEvent 方法之前被调用，如果 onTouch 方法返回 true，那么 onTouchEvent 方法就不会再被执行了，也就是 onTouch 方法优先处理触摸事件；而 onClickListener 是用于处理点击事件的，只有当触摸事件经过了一系列的分发和处理，最终确定是一次有效的点击操作（比如按下和抬起在同一个位置，且中间没有过长的移动等符合点击条件的情况），并且 onTouchEvent 方法处理了这个点击事件（返回 true）时，才会触发 onClickListener 的回调，执行点击相关的逻辑。

滑动冲突与事件分发机制的关联

滑动冲突本质上就是在事件分发过程中，多个可滑动的 View 对于触摸事件的争夺问题。在前面提到的外部拦截法和内部拦截法解决滑动冲突中，其实就是通过合理地控制 ViewGroup 的 onInterceptTouchEvent 方法的返回值以及子 View 的 dispatchTouchEvent 方法中的相关操作，来调整触摸事件的流向，决定是由父 View 处理滑动事件还是子 View 处理。例如在一个可上下滑动的 ListView 嵌套在一个可上下滑动的父布局中的场景，通过在父布局的 onInterceptTouchEvent 方法中判断滑动方向，如果是垂直方向滑动，父布局要根据 ListView 是否滚动到顶部或底部等情况来决定是否拦截事件，避免两者同时处理垂直滑动而出现冲突，保证触摸事件能按照预期被合理分配和处理，让用户的滑动操作能流畅地实现对应的功能。

ListView 里的 item 有图片，当图片加载成功时可以接收事件，不成功时整个 item 接收事件，实现方式

要实现 ListView 里的 item 在图片加载成功时可接收事件，不成功时整个 item 接收事件，可以通过以下的思路和步骤来达成。

自定义 Adapter

首先，需要自定义一个继承自 BaseAdapter（或者其他合适的 ListView 适配器类）的 Adapter 类，在这个 Adapter 类中，对于每个 item 的视图生成进行定制化处理。

在 getView 方法（这是 Adapter 中用于创建和返回每个 item 视图的关键方法）中，先通过 LayoutInflater 等方式加载 item 的布局文件，获取到对应的 View 对象，然后获取到布局中的图片 View（比如 ImageView）以及其他需要处理事件的子 View 等元素。

图片加载及状态判断

使用合适的图片加载库（比如 Glide、Picasso 等）来加载图片，这些图片加载库通常都有相应的回调机制来知晓图片是否加载成功。以 Glide 为例，在加载图片时，可以使用 listener 参数来设置一个加载监听器，在监听器中有 onResourceReady 方法（当图片加载成功时会调用）和 onLoadFailed 方法（当图片加载失败时会调用）。

事件处理设置

在 onResourceReady 方法中，也就是图片加载成功时，为对应的图片 View 单独设置点击事件等交互逻辑。比如通过图片 View 的 setOnClickListener 方法来设置点击事件，在点击事件的回调中可以执行打开图片详情页、进行图片相关操作等逻辑，让图片 View 能够独立地接收和处理事件。

而在 onLoadFailed 方法中，也就是图片加载失败时，为整个 item 的根 View（可以通过获取 item 布局的最外层 View 来确定）设置点击事件等交互逻辑。例如，在点击事件回调中，可以执行重新加载图片、提示用户图片加载失败等操作，使得整个 item 能够作为一个整体来响应触摸事件，弥补图片加载失败后无法进行交互的情况。

优化与注意事项

为了避免频繁地创建和销毁监听器等对象，导致性能问题，可以考虑采用内部类或者匿名内部类的方式来定义图片加载监听器，并且合理地复用已有的监听器实例。同时，在设置点击事件等交互逻辑时，要注意避免出现事件冲突或者不符合预期的行为，比如确保图片加载成功后，点击图片时不会同时触发整个 item 的点击事件等情况，可以通过适当的条件判断和逻辑调整来解决这些潜在问题。另外，在 ListView 滚动等场景下，要确保图片加载的及时性和准确性，以及事件处理的稳定性，比如当 ListView 快速滚动时，合理地暂停和恢复图片加载等操作，保障整体的用户体验。

通过以上的方式，就能够实现 ListView 里的 item 根据图片加载情况来灵活地分配事件接收和处理的能力，提升应用在展示图片相关内容时的交互性和用户体验。

ListView 怎样复用 item？

ListView 复用 item 主要通过 RecycleBin 机制和 ViewHolder 模式实现。在 AbsListView 中有一个内部类 RecycleBin，用于存储和管理可复用的 View。当 ListView 中的 item 滑出屏幕时，该 item 对应的 View 会被放入 RecycleBin 中的相应缓存集合中，如 mScrapViews。当需要新的 item 时，会先从这些缓存集合中获取可用的 View，而不是重新创建新的 View，从而减少了 View 的创建开销。

ViewHolder 模式则是在 Adapter 的 getView 方法中使用。首先判断传入的 convertView 是否为 null，如果是 null，则表示需要创建新的 View，此时会通过 LayoutInflater 来加载布局文件并创建 View，同时创建一个 ViewHolder 对象，将 View 中的各个子控件通过 findViewById 方法获取并保存到 ViewHolder 中，然后通过 convertView 的 setTag 方法将 ViewHolder 对象设置到 Tag 中。如果 convertView 不为 null，则直接从 Tag 中取出 ViewHolder 对象，这样就可以直接使用 ViewHolder 中保存的子控件引用，而不需要再次通过 findViewById 方法查找子控件，大大提高了性能。

ListView、RecyclerView 源码，怎么进行缓存的，二者的区别在哪？

ListView 缓存机制

在 ListView 的源码中，AbsListView 内部类 RecycleBin 负责缓存管理。当 item 滑出屏幕时，会根据 view 的类型将其放入对应的 mScrapViews 集合中。在获取新的 item 视图时，会优先从这些缓存集合中获取可用的 convertView，如果没有合适的则创建新的。同时，ListView 还可以通过 ViewHolder 模式进一步优化性能，减少子视图的查找开销。

RecyclerView 缓存机制

RecyclerView 的缓存机制相对复杂，主要有四级缓存。第一级是 mAttachedScrap，用于缓存屏幕内的 ViewHolder，在布局时可以直接复用。第二级是 mCachedViews，缓存最近滑出屏幕的 ViewHolder，默认缓存 2 个。第三级是 ViewCacheExtension，是一个自定义缓存扩展接口，开发者可以根据需要自行实现。第四级是 RecycledViewPool，当 ViewHolder 在 mCachedViews 中被移除后，会放入 RecycledViewPool 中，它可以被整个项目中的多个 RecyclerView 公用，默认每个 ViewType 最多缓存 5 个。

二者的区别

缓存级别与复用范围：ListView 的缓存相对简单，主要是针对自身的 View 进行复用；而 RecyclerView 有四级缓存，并且可以在多个 RecyclerView 之间共享 ViewHolder，复用范围更广。
布局灵活性与局部刷新：ListView 的布局相对固定，不支持局部刷新，每次数据变化都可能导致整个列表的重新绘制；RecyclerView 通过 LayoutManager 可以实现线性布局、网格布局、瀑布流布局等多种布局方式，并且支持局部刷新，性能更优。
ViewHolder 的使用：ListView 中 ViewHolder 主要是为了减少子视图的查找开销；RecyclerView 中 ViewHolder 的使用更加灵活，并且与缓存机制紧密结合，在不同的缓存级别中都有重要作用。

如何实现 ListView 的 View 复用？

要实现 ListView 的 View 复用，关键在于合理利用 ListView 的缓存机制和 ViewHolder 模式。首先，在自定义 Adapter 的 getView 方法中，需要对传入的 convertView 进行判断。如果 convertView 为 null，说明没有可复用的 View，此时需要通过 LayoutInflater 加载布局文件创建新的 View，并创建 ViewHolder 对象，将 View 中的子控件通过 findViewById 方法获取并保存到 ViewHolder 中，然后通过 convertView 的 setTag 方法将 ViewHolder 对象设置到 Tag 中。如果 convertView 不为 null，则直接从 Tag 中取出 ViewHolder 对象，使用其中保存的子控件引用，避免再次调用 findViewById 方法查找子控件。

另外，在 Adapter 的构造函数或其他合适的地方，可以对 ListView 的 RecycleBin 机制进行一些优化配置，例如设置 View 的类型数量等。在数据更新时，如果数据量较大且变化频繁，可以考虑采用分页加载等策略，减少一次性创建和复用的 View 数量，提高 ListView 的性能和响应速度。还可以根据具体需求，对 ViewHolder 进行进一步的优化和扩展，例如添加更多的属性和方法，方便在不同的 item 类型和业务逻辑中进行复用和管理。

自定义 View，需要重写哪几个方法？

测量方法

onMeasure：用于测量 View 的大小，需要根据父容器的约束和自身的需求来确定 View 的宽高。在该方法中，通常需要调用 setMeasuredDimension 方法来设置测量后的宽高值。如果自定义 View 的大小是固定的，可以直接设置固定的宽高值；如果是根据内容自适应大小，则需要根据内容的尺寸进行计算和设置。

布局方法

onLayout：在 View 的大小测量完成后，会调用 onLayout 方法进行布局。该方法主要用于确定 View 在父容器中的位置，需要根据父容器的布局方式和自身的大小来进行布局计算。对于简单的自定义 View，如果不需要特殊的布局逻辑，可以直接调用父类的 onLayout 方法；对于复杂的自定义 View，可能需要根据具体的业务需求进行自定义的布局计算和设置。

绘制方法

onDraw：用于绘制 View 的内容，这是自定义 View 中最重要的方法之一。在该方法中，可以使用 Canvas 和 Paint 等绘图工具来绘制各种图形、文本、图片等内容。需要根据 View 的具体功能和业务需求进行自定义的绘制逻辑，例如绘制自定义的图表、加载网络图片等。

事件处理方法

onTouchEvent：用于处理 View 的触摸事件，如点击、滑动、长按等。在该方法中，可以根据触摸事件的类型和坐标等信息进行相应的处理逻辑，例如响应点击事件、实现滑动效果等。如果自定义 View 需要与用户进行交互，就需要重写该方法来处理相应的事件。
onKeyDown、onKeyUp等：用于处理按键事件，如果自定义 View 需要响应物理按键的操作，就需要重写这些方法。例如，在游戏开发中，可能需要重写这些方法来处理方向键、确认键等按键事件。

如果要你实现 WIFI 信号的显示，那么你会怎么做？

获取 WIFI 信号强度

可以使用 Android 系统提供的 WifiManager 类来获取 WIFI 信号强度。首先需要在 AndroidManifest.xml 文件中添加相应的权限：

<uses-permission android:name="android.permission.ACCESS_WIFI_STATE" />
<uses-permission android:name="android.permission.CHANGE_WIFI_STATE" />

然后在代码中通过以下方式获取 WifiManager 实例并获取信号强度：

WifiManager wifiManager = (WifiManager) getSystemService(Context.WIFI_SERVICE);
if (wifiManager!= null) {
    int rssi = wifiManager.getConnectionInfo().getRssi();
    // 根据rssi值计算信号强度等级
}

定义信号强度等级与图标映射

根据获取到的信号强度值，将其划分为不同的等级，例如可以分为强、中、弱、无信号等几个等级。然后为每个等级定义对应的图标资源，可以将这些图标资源放在 res/drawable 目录下。

显示 WIFI 信号图标

可以在布局文件中添加一个 ImageView 用于显示 WIFI 信号图标，然后在代码中根据计算得到的信号强度等级，设置 ImageView 的 src 属性为对应的图标资源。例如：

ImageView wifiSignalImageView = findViewById(R.id.wifi_signal_image_view);
if (rssi > -50) {
    wifiSignalImageView.setImageResource(R.drawable.wifi_signal_strong);
} else if (rssi > -70) {
    wifiSignalImageView.setImageResource(R.drawable.wifi_signal_medium);
} else if (rssi > -90) {
    wifiSignalImageView.setImageResource(R.drawable.wifi_signal_weak);
} else {
    wifiSignalImageView.setImageResource(R.drawable.wifi_signal_none);
}

实时更新信号强度

为了实时显示 WIFI 信号的变化，可以使用广播接收器来监听 WIFI 信号强度的变化。当 WIFI 信号强度发生变化时，会收到相应的广播，在广播接收器的 onReceive 方法中重新获取信号强度并更新 ImageView 显示的图标。

public class WifiSignalReceiver extends BroadcastReceiver {
    @Override
    public void onReceive(Context context, Intent intent) {
        if (WifiManager.RSSI_CHANGED_ACTION.equals(intent.getAction())) {
            // 重新获取信号强度并更新图标
        }
    }
}

在 Activity 或 Service 中注册广播接收器：

WifiSignalReceiver receiver = new WifiSignalReceiver();
IntentFilter filter = new IntentFilter(WifiManager.RSSI_CHANGED_ACTION);
registerReceiver(receiver, filter);

在适当的时候，例如在 Activity 的 onDestroy 方法中注销广播接收器：

unregisterReceiver(receiver);

自定义 View 和 ViewGroup

自定义 View 是指根据应用的特定需求创建全新的视图，比如创建一个圆形的 ImageView 或者带有特殊效果的 TextView 等。通常需要重写 onMeasure、onLayout、onDraw 等方法。例如，创建一个自定义的圆形 ImageView，在 onMeasure 方法中测量视图的大小，在 onDraw 方法中使用 Canvas 绘制圆形的图片。

ViewGroup 则是用于容纳和管理多个子视图的容器，如 LinearLayout、RelativeLayout 等都是 ViewGroup 的子类。自定义 ViewGroup 时，除了重写 onMeasure 和 onLayout 方法外，还可能需要重写 onInterceptTouchEvent 和 dispatchTouchEvent 等方法来处理触摸事件的分发。例如，自定义一个流式布局的 ViewGroup，在 onMeasure 方法中测量子视图的大小并根据布局规则确定自身大小，在 onLayout 方法中对子视图进行布局。

自定义 View 自定义 attr xml 可以定义相同属性吗

在自定义 View 的 attr xml 中可以定义相同属性，但需要注意避免冲突和混淆。通常在定义自定义属性时，会使用自定义的命名空间来确保属性的唯一性。如果定义了相同的属性名，可能会导致在使用时出现属性值覆盖或冲突的情况。例如，如果在不同的自定义 View 中定义了相同的属性名 “textColor”，那么在布局文件中使用该属性时，可能会出现意想不到的结果，因为系统无法确定应该应用哪个自定义 View 中的属性定义。为了避免这种情况，建议在定义自定义属性时，使用具有唯一性的属性名，如在属性名前加上自定义 View 的前缀等。

Android 动画了解吗

Android 提供了多种动画类型，主要有补间动画、帧动画和属性动画。

补间动画包括平移、缩放、旋转、透明度变化等动画效果，通过在起始和结束状态之间进行插值计算来实现动画过渡，使用简单方便，适用于一些简单的视图动画效果，如一个按钮的淡入淡出效果。

帧动画是通过一系列连续的图片帧来实现动画效果，类似于电影的播放原理，适用于制作一些复杂的、需要精细控制每一帧的动画，如游戏中的角色动画。

属性动画则是可以对任何对象的属性进行动画操作，通过改变对象的属性值来实现动画效果，功能更强大、更灵活，能够实现补间动画无法实现的效果，如改变一个自定义 View 的背景颜色渐变等。在 Android 3.0 及以上版本中引入，提供了 AnimatorSet 等类来方便地组合和控制多个动画的执行顺序和时间。

做过的安卓性能优化，内存优化如何做？

安卓内存优化可以从多个方面入手。首先是优化布局资源，减少布局文件的嵌套层级，避免过度绘制。可以使用 Hierarchy Viewer 工具来分析布局的性能，通过将复杂的布局进行扁平化处理，减少不必要的视图层级，从而提高绘制效率。

在对象的创建和使用方面，要避免频繁创建和销毁对象，尽量复用已有的对象。例如，对于一些频繁使用的 Bitmap 对象，可以进行缓存和复用，而不是每次都重新创建。同时，要及时释放不再使用的资源，如在 Activity 或 Fragment 的生命周期方法中，及时注销广播接收器、关闭数据库连接等。

图片资源的优化也很重要，要根据实际需要选择合适的图片格式和压缩比例，避免使用过大的图片导致内存占用过高。可以使用图片压缩工具对图片进行压缩处理，在加载图片时，采用图片加载库如 Glide 或 Picasso 等，它们会自动进行图片的缓存和优化加载。

另外，还可以使用内存分析工具如 Android Profiler 等，定期对应用的内存使用情况进行分析，找出内存泄漏和内存占用过高的地方，及时进行优化和修复。

Android 中发生内存泄漏的原因，如何发现内存泄漏？怎么避免？

Android 中内存泄漏的原因主要有以下几种。一是持有静态引用导致无法释放，例如在 Activity 中定义了静态的 View 对象，当 Activity 被销毁后，由于静态引用的存在，该 View 及其相关资源无法被回收。二是资源未及时关闭，如未关闭的数据库连接、文件流等，导致这些资源一直占用内存。三是内部类持有外部类引用，在内部类的生命周期长于外部类时，可能导致外部类无法被回收。四是注册的广播接收器未及时注销，当不再需要接收广播时，如果没有注销广播接收器，它会一直占用内存。

发现内存泄漏可以使用 Android Profiler 等工具，它可以实时监测应用的内存使用情况，通过查看内存分配的走势图和对象的引用关系，发现内存泄漏的可疑点。还可以使用 LeakCanary 库，它能够在应用发生内存泄漏时自动检测并发出警告，方便开发者及时发现和解决问题。

避免内存泄漏的方法有很多。在使用静态变量时，要谨慎避免持有 Activity 或其他可能导致内存泄漏的对象引用。对于资源的使用，要确保在不再需要时及时关闭，如在 onDestroy 方法中关闭数据库连接、文件流等。在使用内部类时，如果内部类可能会导致外部类的引用无法释放，可以将内部类改为静态内部类。对于广播接收器，要在合适的生命周期方法中及时注销，如在 onDestroy 方法中注销广播接收器等。同时，要养成良好的编程习惯，定期对代码进行内存泄漏的检查和修复。

内存泄露是什么，怎么解决，有没有使用过内存查看工具

内存泄露指的是程序中已动态分配的内存空间，在使用完毕后没有被正确释放，导致这部分内存一直被占用，随着程序的运行，可用内存会越来越少，最终可能引发程序性能下降甚至崩溃等问题。

解决内存泄露的方法有多种。比如对于静态变量引用导致的泄露，要避免让静态变量持有像 Activity、Fragment 这类有生命周期且内存占用较大对象的引用，如果确实需要引用，可以考虑使用弱引用替代强引用，这样在对象可回收时能正常被回收。当使用资源（如数据库连接、文件流等）时，务必在不再需要时及时关闭，像在 Activity 的 onDestroy 方法里关闭数据库连接，防止其一直占用内存。对于内部类，如果它持有外部类引用且生命周期长于外部类，可将其改为静态内部类，切断不合理的引用关系。

我使用过一些内存查看工具，像 Android Profiler，它能实时展示应用内存的使用情况，通过直观的图表看到内存的分配、回收走势，还能深入查看对象的实例数量、大小以及引用关系等，方便定位可能存在内存泄露的地方。还有 LeakCanary 这个工具，它会自动检测内存泄露情况，一旦发现泄露就会给出提示信息，告知是哪个对象发生了泄露以及大致的泄露原因，极大地方便了开发者去排查和修复内存泄露问题。

Handler 中是否有 messagequeue

Handler 内部是关联着 MessageQueue 的。Handler 主要用于在不同线程间发送和处理消息，它的工作机制依赖于 MessageQueue。当通过 Handler 的 post 方法或者 sendMessage 方法等发送消息时，这些消息会被添加到与该 Handler 关联的 MessageQueue 中，然后 MessageQueue 会按照消息添加的先后顺序以及设置的延迟等因素，依次将消息取出，再通过 Looper 将消息分发给对应的 Handler 进行处理。也就是说，MessageQueue 起到了一个消息存储和排队的作用，而 Handler 借助它实现了对消息的有序管理以及在合适的时间点进行处理，确保多线程环境下消息传递和处理的准确性与规范性。

Handler 解决内存泄漏，Handler 可以主动释放吗

Handler 在某些情况下可能引发内存泄漏，比如在 Activity 中定义了匿名内部类形式的 Handler，而该 Handler 在执行一些延迟任务时（如 postDelayed 发送了一个延迟消息），由于其默认持有外部 Activity 的引用，若在 Activity 要被销毁时，延迟任务还未执行完，那么 Activity 就无法被正常回收，从而导致内存泄漏。

要解决这种内存泄漏问题，可以采用多种方式。一种常见的做法是将 Handler 定义为静态内部类，并且通过弱引用的方式持有外部 Activity 的引用，这样当 Activity 可以被回收时，不会因为 Handler 的强引用而无法释放。在静态内部类的 Handler 中，当需要操作 Activity 相关资源时，通过弱引用获取 Activity 实例，判断是否为空后再进行相应操作。

Handler 本身不能主动释放，不过可以通过一些手段间接实现类似效果。比如可以在 Activity 的 onDestroy 方法中，调用 Handler 的 removeCallbacks 方法，将所有未执行的消息（包含延迟消息等）都移除，这样就切断了 Handler 与 Activity 之间因未完成任务而存在的关联，避免因 Handler 的存在导致 Activity 无法正常回收，从而解决因 Handler 引发的内存泄漏问题。

如何分析 ANR，ANR 是什么，怎么解决，ANR 原因，耗时操作几秒会造成 ANR

ANR（Application Not Responding）指的是应用无响应，也就是当用户操作应用时，应用长时间没有做出响应，导致系统弹出相应提示框告知用户应用无响应的一种异常情况。

分析 ANR 时，首先可以查看系统生成的 ANR 日志，这些日志一般会记录发生 ANR 的时间、进程信息、出现问题的线程以及大致的堆栈信息等，通过分析这些内容可以了解是哪个线程执行了耗时操作导致的 ANR，比如是主线程在进行网络请求、文件读取等耗时操作。同时，可以借助 Android Profiler 工具，查看发生 ANR 时段各线程的运行状态、CPU 使用率等情况，辅助判断是资源不足导致的 ANR 还是某个具体业务逻辑中的耗时操作引发的。

ANR 产生的原因有多种，常见的是在主线程执行了耗时操作，像主线程进行大量复杂的计算、长时间的网络请求、读取大文件等。另外，主线程被阻塞，例如在主线程中进行了死循环或者等待某个锁而长时间无法获取到，也会引发 ANR。还有就是应用在启动或者切换 Activity 等关键阶段，如果处理过程耗时过长也可能出现 ANR。

至于耗时操作几秒会造成 ANR 并没有一个固定的标准，不同的设备、系统版本等情况有所差异，不过通常来说，如果主线程的操作耗时超过 5 秒左右（只是大致参考），就很有可能引发 ANR，所以要尽量保证主线程的操作都是轻量级、能快速执行完成的。

解决 ANR 问题，关键在于避免在主线程执行耗时操作，将耗时的任务（如网络请求、文件读取等）移到子线程去执行，通过线程间通信机制（如 Handler 等）将结果反馈回主线程更新 UI。对于可能阻塞主线程的情况，要仔细排查代码逻辑，避免出现死锁等问题，优化启动和界面切换流程，减少不必要的耗时步骤。

ANR 异常如何查找并分析？

查找和分析 ANR 异常可以从以下几个方面入手。

首先，查看系统生成的 ANR 日志文件，这些日志通常存储在设备的特定目录下（不同设备和系统版本可能略有不同），里面包含了丰富的信息，比如 ANR 发生的时间、涉及的进程名称、出现问题的线程名称以及对应的堆栈信息等。通过分析堆栈信息，能够清晰地看到在发生 ANR 时相关线程正在执行的代码位置，进而判断是哪个业务逻辑导致了耗时过长或者阻塞的情况，例如是某个网络请求回调中进行了复杂的处理，还是在主线程中执行了文件读取操作等。

其次，可以利用 Android 自带的工具，如 Android Profiler。在应用运行过程中，它可以实时监测各线程的运行状态、CPU 使用率、内存使用情况等关键指标。当发生 ANR 后，回顾 ANR 发生时段这些指标的变化情况，如果发现某个线程长时间占用 CPU 资源或者主线程在某个时间段内处于停滞状态，就能帮助确定引发 ANR 的大致原因，是因为资源竞争导致主线程无法正常执行，还是因为某个线程执行了过于耗时的操作而影响了主线程响应。

另外，还可以在代码中添加一些日志输出，在关键的业务逻辑处，尤其是涉及到可能耗时的操作，如数据库操作、网络交互等地方，记录操作的开始时间和结束时间，当出现 ANR 时，通过查看这些日志来确定是哪部分代码的执行时间超出了正常范围，辅助进行更精准的分析和问题定位。同时，对一些常用的第三方库也要关注其是否可能引发 ANR，查看其文档或者在相关社区了解是否有其他开发者遇到过类似的 ANR 问题及解决办法，全面地查找和分析 ANR 异常，以便采取有效的措施去解决问题。

Android 设计的六个原则

Android 设计的六个原则分别是单一职责原则、开闭原则、里氏替换原则、依赖倒置原则、接口隔离原则和迪米特法则。

单一职责原则：一个类只负责一个功能领域中的相应职责，或者可以定义为只有一个引起它变化的原因。例如在 Android 中，一个网络请求类就只负责网络请求相关的操作，而不应该包含数据解析等其他功能。

开闭原则：软件实体应该对扩展开放，对修改关闭。比如在 Android 开发中，当需要为一个 ListView 添加新的 item 类型时，应该通过扩展 Adapter 的方式来实现，而不是直接修改原有的 Adapter 代码。

里氏替换原则：所有引用基类的地方必须能透明地使用其子类的对象。在 Android 中，当定义一个基类的 Activity 时，其子类可以在不改变原有代码逻辑的情况下替换基类，并且能够正常运行。

依赖倒置原则：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象。例如在 Android 的 MVP 架构中，View 层和 Model 层都依赖于抽象的 Presenter 接口，而不是具体的实现类。

接口隔离原则：客户端不应该依赖它不需要的接口，一个类对另一个类的依赖应该建立在最小的接口上。在 Android 开发中，当定义一个接口给不同的类使用时，应该只暴露必要的方法，避免不必要的方法暴露给不需要的类。

迪米特法则：一个对象应该对其他对象保持最少的了解，尽量降低类与类之间的耦合。在 Android 中，例如在一个 Activity 中调用另一个类的方法时，应该尽量减少对该类内部实现细节的了解，只通过定义好的接口进行调用。

MVP MVVM 架构，MVP 架构模式的优点，与 MVC 对比，MVVM 架构的思想，项目中用了 MVVM 架构，解释一下 MVVM 架构的思想

MVP 架构模式的优点：分离了视图逻辑和业务逻辑，使得代码结构更加清晰，易于维护和测试。例如在一个登录功能中，View 层只负责显示登录界面和接收用户输入，Presenter 层负责处理登录业务逻辑，Model 层负责与服务器进行交互获取数据，这样不同层次的职责明确，修改某一层的代码不会影响到其他层。
MVP 与 MVC 对比：MVC 中 View 和 Model 直接交互，导致耦合度较高，而 MVP 通过 Presenter 作为中间桥梁，使得 View 和 Model 完全解耦。在 MVC 中，Activity 或 Fragment 既承担了视图展示的功能，又要处理业务逻辑，代码容易变得臃肿和难以维护；而 MVP 将业务逻辑分离到 Presenter 中，使得 View 层更加简洁。
MVVM 架构的思想：MVVM 采用双向数据绑定的方式，将 View 和 Model 进行关联。当 Model 中的数据发生变化时，会自动更新到 View 上；反之，当 View 中的数据发生变化时，也会自动更新到 Model 中。例如在一个购物车应用中，商品的数量和总价等数据在 Model 中进行计算和存储，而在 View 中通过数据绑定直接显示这些数据，当用户在 View 中修改商品数量时，会自动更新到 Model 中重新计算总价，反之亦然。在项目中，使用 MVVM 架构可以大大减少代码中的手动更新 UI 的操作，提高开发效率和代码的可维护性。

Android 多进程通信方式，如何让 Activity 运行在另一个进程中，多进程有几个 Application，Application 中进行初始化操作，如何保证初始化只执行一次，AIDL 使用，AIDL 谁来维护

Android 多进程通信方式：主要有 Bundle 传递数据、文件共享、Messenger、AIDL、ContentProvider 和 Socket 等方式。Bundle 传递数据适用于简单的进程间数据传递；文件共享可以通过共享文件来实现数据交换；Messenger 是一种轻量级的进程间通信方式，基于消息队列实现；AIDL 则用于复杂的接口调用；ContentProvider 可以在不同进程间共享数据；Socket 则适用于网络通信等场景。
如何让 Activity 运行在另一个进程中：在 AndroidManifest.xml 文件中为 Activity 指定 android:process 属性，即可让该 Activity 运行在指定的进程中。例如，这样 MyActivity 就会运行在名为 ":remote" 的进程中。
多进程有几个 Application：每个进程都会有一个独立的 Application 实例。当应用启动多个进程时，每个进程都会创建自己的 Application 对象，并且会执行各自的 onCreate 等生命周期方法。
Application 中进行初始化操作，如何保证初始化只执行一次：可以使用单例模式或者通过一个标志位来判断是否已经执行过初始化操作。例如在 Application 的 onCreate 方法中，定义一个静态的布尔变量，在第一次执行初始化操作后将其设置为 true，后续再进入 onCreate 方法时，通过判断该变量的值来决定是否执行初始化操作。
AIDL 使用：首先定义一个.aidl 文件，在其中定义接口和方法，然后使用 Android Studio 自动生成对应的 Java 接口文件。在服务端实现该接口，并在客户端通过 bindService 方法绑定服务，获取服务端的代理对象，通过代理对象调用服务端的方法来实现进程间通信。
AIDL 谁来维护：AIDL 接口通常由服务端和客户端共同维护。当接口发生变化时，需要同时更新服务端和客户端的代码，以确保双方的接口定义一致，否则可能会导致进程间通信失败。

图片的三级缓存是怎么做的？，图片压缩怎么做？，图片缓存怎么做的？

图片的三级缓存：包括内存缓存、磁盘缓存和网络缓存。内存缓存通常使用 LruCache 等缓存算法，将最近使用的图片缓存在内存中，以便快速获取和显示。磁盘缓存则是将图片缓存在本地磁盘上，当内存缓存中不存在图片时，可以从磁盘缓存中获取。网络缓存则是在图片需要从网络获取时，先检查本地是否有缓存，如果有则直接使用本地缓存，否则从网络下载并缓存到本地。
图片压缩怎么做：可以从质量压缩和尺寸压缩两个方面入手。质量压缩通过设置 Bitmap 的压缩格式和质量参数，减少图片的存储空间，一般用于图片存储和网络传输。尺寸压缩则是根据需要显示的图片大小，对图片进行等比例缩放，减少图片的像素数量，从而降低图片占用的内存空间，常用于图片在内存中的处理。
图片缓存怎么做的：内存缓存可以使用 LruCache 或其他缓存算法实现，将图片以键值对的形式存储在内存中，方便快速访问。磁盘缓存可以使用文件存储的方式，将图片以文件的形式存储在本地磁盘上，并通过文件名或其他唯一标识进行索引。在获取图片时，先从内存缓存中查找，如果不存在则从磁盘缓存中查找，最后再考虑从网络获取。同时，需要设置合理的缓存策略，如缓存大小限制、缓存过期时间等，以确保缓存的有效性和性能。

解释 LruCache 算法，图片占用内存怎么计算

LruCache 算法：LruCache 即最近最少使用缓存算法，它是一种基于内存的缓存策略。它内部维护了一个 LinkedHashMap，按照访问顺序对缓存项进行排序。当缓存空间不足时，会优先淘汰最近最少使用的缓存项。在 Android 中，通常用于缓存图片等占用内存较大的资源，以提高应用的性能和响应速度。例如，当应用频繁地加载和显示图片时，LruCache 会将最近使用过的图片缓存在内存中，当需要加载新的图片而内存不足时，会自动淘汰最久未使用的图片，从而保证内存的有效利用。
图片占用内存怎么计算：图片占用的内存大小主要取决于图片的分辨率和色彩格式。对于 ARGB_8888 格式的图片，每个像素占用 4 个字节，所以图片占用的内存大小为图片的宽度 × 图片的高度 ×4 字节。例如，一张 1000×1000 像素的 ARGB_8888 格式的图片，其占用的内存大小为 1000×1000×4 = 4000000 字节，即约 3.8MB。而对于 RGB_565 格式的图片，每个像素占用 2 个字节，其内存大小计算方式为图片的宽度 × 图片的高度 ×2 字节。在实际应用中，需要根据图片的具体格式和分辨率来准确计算图片占用的内存大小，以便合理地进行图片缓存和内存管理。

xml 格式的图和普通的图有啥区别？

xml 格式的图通常是一种矢量图，它是用 xml 语言来描述图形的形状、颜色、位置等属性，而普通的图可以是多种格式，如 jpg、png 等，这些大多是位图。

xml 格式的图的优点在于它可以无损缩放，无论放大或缩小多少倍，图像都不会出现失真或模糊的情况，因为它是基于数学公式和图形指令来绘制的，而不是像位图那样由像素点组成。它的文件大小相对较小，尤其是对于简单图形，因为只需要记录图形的描述信息，而不是每个像素的颜色值。在进行动画制作和交互设计时，xml 格式的图更方便，因为可以通过修改 xml 中的属性值来实现图形的动态变化和交互效果。

普通的图则具有更广泛的兼容性，几乎所有的图像查看和编辑软件都能支持常见的位图格式。它的色彩表现更加丰富和细腻，能够呈现出非常逼真的视觉效果，适合用于展示照片等对色彩和细节要求较高的场景。但是，位图在放大时会出现锯齿和模糊，并且文件大小通常较大。

图片有哪些类型，区别是什么？

常见的图片类型有 JPEG、PNG、GIF、BMP、SVG 等。

JPEG 是一种有损压缩的图像格式，它通过去除图像中的一些细节和颜色信息来减小文件大小，适用于存储照片等色彩丰富的图像，能够在较小的文件大小下保持较好的视觉效果，但反复编辑和保存可能会导致图像质量下降。

PNG 是一种无损压缩的图像格式，支持透明背景，适用于需要保留图像细节和透明度的场景，如网站图标、UI 设计中的一些元素等，其压缩比相对 JPEG 较低，但图像质量更高。

GIF 是一种支持动画的图像格式，它采用无损压缩，颜色数量有限，通常最多为 256 色，适用于制作简单的动画和图标，文件大小相对较小，但色彩表现不如 JPEG 和 PNG 丰富。

BMP 是一种简单的位图图像格式，未经过压缩或者采用简单的 RLE 压缩，图像质量高，但文件大小较大，通常在 Windows 系统中用于保存图像的原始数据。

SVG 是一种矢量图形格式，基于 xml 描述图形，与分辨率无关，可无限缩放而不失真，适用于图标、图表等需要在不同设备和分辨率下保持清晰的图形，文件大小相对较小，但对于复杂的图像渲染可能会比位图格式消耗更多的计算资源。

图片第三方库用过哪些？

常用的图片第三方库有 Glide、Picasso、Fresco 等。

Glide 是一个功能强大且高效的图片加载和缓存库，它支持多种图片格式，能够自动处理图片的加载、解码、缓存等操作，具有高效的内存管理和缓存策略，能够在滚动列表等场景下很好地处理图片的加载和复用，减少内存占用和卡顿现象，还支持图片的裁剪、转换等操作，并且可以与其他 Android 组件很好地集成。

Picasso 是一个简单易用的图片加载库，它的 API 简洁明了，能够快速地将图片加载到 ImageView 中，支持图片的缓存和自动处理图片的大小调整，以适应 ImageView 的大小，同时也支持加载网络图片和本地图片，并且在图片加载失败时可以方便地设置占位图。

Fresco 是 Facebook 开源的图片库，它的主要特点是在图片的加载和显示方面具有很高的性能和效率，特别是对于大图片和长列表中的图片加载，采用了三级缓存机制，能够有效地减少内存占用和避免 OOM 错误，还支持渐进式加载、图片的缩放和裁剪等功能，并且在图片的解码和显示方面进行了优化，提供了更好的视觉效果。

Android 和 ios 的区别，怎么看待 android 和 ios?

系统架构方面：Android 是基于 Linux 内核的开源操作系统，具有高度的可定制性，不同的厂商可以根据自己的需求进行定制和修改，这使得 Android 系统在不同的设备上可能会有一些差异。iOS 是苹果公司的闭源操作系统，具有统一的系统标准和严格的审核机制，系统的稳定性和一致性相对较高，在不同的苹果设备上的用户体验基本一致。

应用生态方面：Android 的应用市场较为分散，有 Google Play 和众多第三方应用市场，应用的数量和种类繁多，但也存在一些应用质量参差不齐的问题。iOS 的应用只能通过 App Store 下载，应用的审核相对严格，应用的质量和安全性相对较高，但应用的数量可能相对 Android 略少。

用户体验方面：Android 设备的硬件和软件的多样性使得用户可以根据自己的需求和预算选择不同的设备和定制不同的系统，具有更高的个性化。iOS 的用户体验更加简洁和统一，系统的操作逻辑和界面设计相对简洁，对于一些追求简单和稳定的用户来说更具吸引力。

开发方面：Android 开发使用 Java、Kotlin 等语言，开发工具主要是 Android Studio，开发过程相对较为灵活，但由于设备的多样性，需要进行更多的兼容性测试。iOS 开发使用 Swift、Objective-C 等语言，开发工具是 Xcode，开发过程相对规范和严格，由于设备的统一性，兼容性问题相对较少。

安卓中启动一个 APP 一般启动多少个进程，多少线程，进程开启 service？

一般情况下，安卓中启动一个 APP 通常会启动一个主进程，这个主进程负责运行 APP 的主要代码和组件，包括 Activity、Service、Broadcast Receiver 等。

在默认情况下，一个 APP 启动时除了主线程外，可能会根据需要创建一些额外的线程，比如在进行网络请求、文件下载、数据库操作等耗时操作时，通常会在新的线程中进行，以避免阻塞主线程，导致界面卡顿。但具体创建多少个线程并没有一个固定的标准，而是根据 APP 的具体功能和业务需求来决定。

当 APP 中的某个组件需要在后台执行长时间运行的任务或者需要与其他组件进行交互时，可能会开启 Service。一个 APP 可以开启多个 Service，具体数量也取决于 APP 的功能需求，例如，一个音乐播放 APP 可能会开启一个 Service 来在后台播放音乐，同时还可能开启另一个 Service 来进行歌词的下载和更新等。

UI 线程和工作线程的区别

UI 线程主要负责处理用户界面的绘制、更新以及与用户的交互等操作，如响应用户的点击、滑动等事件，更新文本框中的文字、按钮的状态等。它是单线程的，若在 UI 线程中执行耗时操作，会导致界面卡顿甚至无响应，因为 UI 线程被耗时任务阻塞，无法及时处理用户交互和界面更新。

工作线程则主要用于执行耗时的任务，如网络请求、文件下载、复杂的数据处理等。工作线程不会阻塞 UI 线程，使得 UI 界面能够保持流畅的响应。但工作线程不能直接更新 UI，若需要更新 UI，需通过 Handler、AsyncTask 等机制将更新操作切换到 UI 线程中进行。

知道哪些 UI 布局

线性布局（LinearLayout）：按照水平或垂直方向排列子视图，通过设置 orientation 属性来确定排列方向。可以通过设置权重（layout_weight）来按比例分配子视图的空间。
相对布局（RelativeLayout）：通过相对位置来排列子视图，子视图可以相对于父布局或其他子视图进行定位，如在某个视图的上方、下方、左边、右边等，灵活性较高。
帧布局（FrameLayout）：所有子视图都堆叠在左上角，后添加的子视图会覆盖前面的子视图，常用于需要重叠显示的场景，如进度条覆盖在图片上显示加载进度。
表格布局（TableLayout）：以表格的形式排列子视图，通过 TableRow 来表示一行，每个 TableRow 中的子视图作为表格的一列，适用于需要以表格形式展示数据的情况。
约束布局（ConstraintLayout）：通过约束条件来确定子视图的位置和大小，相对灵活且高效，能够减少布局嵌套，适用于复杂的 UI 界面设计。

如何实现一个包含多种不同布局样式的列表

使用 RecyclerView 和多种 ViewHolder：创建不同的 ViewHolder 类来对应不同的布局样式，在 RecyclerView 的 Adapter 中根据数据类型或条件来返回不同的 ViewHolder，在各自的 ViewHolder 中进行不同布局的绑定和数据设置。
使用 ListView 和不同的 Item 布局：与 RecyclerView 类似，在 ListView 的 Adapter 中根据数据的不同情况加载不同的布局文件，在 getView 方法中通过判断条件来实例化不同的布局并进行数据绑定。
使用 ExpandableListView：适用于具有分组和子项且布局样式不同的列表，通过实现 ExpandableListView 的 Adapter，分别处理组布局和子项布局，在相应的方法中进行不同布局的加载和数据设置。

RecyclerView 有哪些类，常用的使用方法

RecyclerView 类：是核心类，用于展示列表或网格等布局的可滚动视图，需要设置布局管理器、适配器等。
LayoutManager 类：负责确定 RecyclerView 中每个 Item 的布局方式，如线性布局管理器（LinearLayoutManager）、网格布局管理器（GridLayoutManager）、瀑布流布局管理器（StaggeredGridLayoutManager）等。
Adapter 类：用于将数据绑定到 RecyclerView 的每个 Item 上，需要实现 onCreateViewHolder、onBindViewHolder 和 getItemCount 等方法。
ViewHolder 类：用于缓存每个 Item 的视图，提高性能，在 onCreateViewHolder 方法中创建并返回 ViewHolder 实例，在 onBindViewHolder 方法中进行数据绑定。

常用的使用方法如下：

在布局文件中添加 RecyclerView。
在代码中获取 RecyclerView 实例，通过 setLayoutManager 方法设置布局管理器，如 new LinearLayoutManager (this)。
创建自定义的 Adapter 类并继承 RecyclerView.Adapter，实现相关方法，在方法中进行视图的创建、数据的绑定等操作。
创建 ViewHolder 类并继承 RecyclerView.ViewHolder，用于缓存视图。
通过 RecyclerView 的 setAdapter 方法设置适配器，将数据传递给适配器并显示在 RecyclerView 中。

Fling 事件监听

在 Android 中，Fling 事件通常是指用户在屏幕上快速滑动后松开手指，视图继续滑动一段距离的操作。要监听 Fling 事件，可以通过实现 GestureDetector.OnGestureListener 接口或继承 SimpleOnGestureListener 类来实现。在 onFling 方法中可以获取到 Fling 事件的相关信息，如起始点坐标、结束点坐标、速度等。可以根据这些信息来进行相应的处理，比如在 ListView 或 RecyclerView 中，根据 Fling 的方向和速度来决定滚动的距离和速度，实现快速滚动到指定位置或加载更多数据等功能。同时，也可以结合其他手势事件如 onScroll、onDown 等来实现更复杂的交互效果，例如在图片浏览应用中，根据 Fling 的方向和速度来切换图片或进行图片缩放等操作。

网盘中有 10 个文件，现在用户可以任意拖动这些文件，改变它们的排序，怎么设计上传的接口，使用什么样的数据结构进行存储

在设计上传接口时，首先要考虑的是能够接收文件相关信息以及其顺序信息。可以设计一个接口，让客户端通过 HTTP POST 请求的方式向服务器发送数据。请求体中可以采用 JSON 格式的数据结构，其中包含两个关键部分，一是文件本身的元数据信息，比如文件名、文件大小、文件类型等，这些可以用对象数组的形式来组织，每个对象对应一个文件；二是文件的顺序信息，可以用一个数组来存储，数组中的元素为文件的唯一标识（比如文件的 ID 或者文件名等），且顺序就是用户拖动后确定的顺序。

对于存储的数据结构，在服务器端可以使用列表（比如 Python 中的 List、Java 中的 ArrayList 等）结合字典（Python 中的 Dict、Java 中的 HashMap 等）的形式。用列表来按照顺序存储文件的相关信息，列表中的每个元素是一个字典，字典里存放具体某个文件的详细信息，包括之前提到的文件名、大小、类型等，同时字典中还可以包含一个用于标识顺序的索引字段，方便后续按照顺序检索和处理文件。这样的结构方便对文件顺序进行调整以及快速查找特定文件的信息，当用户后续再次查看、下载或者对文件进行其他操作时，能够依据这个存储结构准确地按照用户设定的顺序来呈现和处理这些文件。而且，在服务器端对文件进行持久化存储时，无论是存储到数据库还是文件系统中，都可以基于这个数据结构进行相应的转换和存储操作，确保文件顺序的一致性和可维护性。

Android UI 绘制流程？，Android 中每一帧绘制时间在多少 ms 以下算流畅？，电影是 24fps，为什么 Android 需要 60 帧才流畅？

Android UI 绘制流程

Android UI 绘制流程主要分为三个阶段，分别是测量（Measure）、布局（Layout）和绘制（Draw）阶段。

在测量阶段，从根视图（通常是 DecorView）开始，自上而下遍历整个视图树，每个视图会调用自身的 measure 方法，进而调用 onMeasure 方法。父视图会根据自身的布局规则以及剩余空间等因素，传递测量规格（MeasureSpec）给子视图，子视图依据自身的布局参数（如宽高设置是 wrap_content、match_parent 还是具体数值等）以及接收到的 MeasureSpec 来确定自己的测量宽高，这一过程是递归进行的，直到所有视图都完成测量。

接着进入布局阶段，同样是从根视图开始自上而下遍历，每个视图调用 layout 方法并在其中调用 onLayout 方法（ViewGroup 类型的视图需要重写 onLayout 来确定子视图的位置，普通视图通常不需要重写此方法），父视图根据子视图在测量阶段确定的大小以及自身的布局规则（比如 LinearLayout 的排列方向等），通过设置子视图的四个顶点坐标（left、top、right、bottom）来确定子视图在父视图中的具体位置，以此确定整个视图树中每个视图的位置布局。

最后是绘制阶段，还是从根视图开始遍历视图树，视图调用 draw 方法启动绘制流程。draw 方法内部会先调用 drawBackground 方法绘制背景，然后调用 onDraw 方法绘制自身内容（像 TextView 绘制文本、ImageView 绘制图片等，开发者可重写 onDraw 来定制绘制内容），之后如果是 ViewGroup 类型视图会调用 dispatchDraw 方法来让子视图进行绘制，最后调用 onDrawForeground 方法绘制前景相关内容（比如滚动条等），通过这一系列步骤将整个视图树的内容呈现到屏幕上。

Android 中每一帧绘制时间在多少 ms 以下算流畅

一般来说，Android 系统中每一帧的绘制时间在 16ms 以下算比较流畅。因为 Android 设备的屏幕刷新率大多是 60Hz，也就是每秒刷新 60 次，每次刷新间隔就是 1000ms÷60≈16.67ms，要保证屏幕能及时更新画面，每一帧的绘制时间就得小于这个间隔时间，这样才能让用户感觉到界面的切换、动画等操作是流畅顺滑的，不会出现卡顿现象。

电影是 24fps，为什么 Android 需要 60 帧才流畅

电影通常采用 24fps（每秒 24 帧）就能给人流畅的视觉感受，这是因为电影播放时，画面是连续的、固定的，观众坐在相对固定的位置观看，并且电影有一些画面过渡的处理技巧以及人眼视觉暂留效应等因素共同作用，使得 24fps 足以营造出流畅的观影体验。而在 Android 设备上，用户与屏幕的交互是非常频繁的，比如滑动屏幕、点击操作等，并且界面上的元素可能随时在动态变化，有各种动画效果、滚动效果等。较高的 60fps 帧率可以让这些动态交互更加细腻、顺滑，更快地响应用户操作，减少画面的拖影、卡顿等现象，给用户带来更好的操作体验和视觉感受，所以 Android 需要 60 帧才显得流畅。

学习 Android 的方式？为什么选择做安卓，怎么学 android 的，看过哪些书

学习 Android 的方式

学习 Android 有多种途径。首先，可以通过官方文档进行学习，Android 官方提供了非常全面且详细的文档，涵盖了从基础知识到高级功能的各个方面，比如不同组件（Activity、Service 等）的使用方法、各种 API 的介绍等，按照文档的指引可以逐步深入了解 Android 开发体系。

在线课程也是很好的学习方式，如今有众多的在线教育平台提供丰富的 Android 开发课程，这些课程通常由经验丰富的讲师授课，会结合实际案例进行讲解，从搭建开发环境、创建简单的项目开始，逐步深入到复杂的功能实现，并且会对一些常见的问题和难点进行剖析，便于学习者快速掌握知识和技能。

实践项目更是不可或缺，通过自己动手做一些小项目，比如简单的天气应用、待办事项应用等，将所学的知识运用起来，在实践中去理解各个组件如何协同工作、如何处理用户交互、如何进行数据存储等，遇到问题再去查阅资料或者请教他人，这样能够加深对知识的理解和记忆，提高开发能力。

参与开源项目也是一种有效的学习途径，在开源平台上找到一些感兴趣的 Android 开源项目，阅读其代码，学习别人优秀的代码结构、设计模式以及解决问题的思路，还可以尝试参与贡献代码，与其他开发者交流，提升自己的开发水平。

为什么选择做安卓

选择做安卓开发有多方面原因。一方面，Android 系统在全球有着庞大的市场占有率，众多的手机厂商采用 Android 系统，这意味着有大量的用户，开发的应用能够触达广泛的人群，有很大的发挥空间，可以满足不同用户群体的需求，创造出有价值的产品。另一方面，Android 开发具有很强的开放性和灵活性，开发者可以根据自己的创意和想法进行各种定制化开发，无论是功能上还是界面设计上都能自由发挥，而且有丰富的开源资源可供利用，能够快速地搭建项目、实现功能，提升开发效率。

怎么学 Android 的

刚开始学习时，先搭建好 Android 开发环境，熟悉 Android Studio 这个开发工具的基本操作，了解项目的结构和运行机制。然后从学习 Android 的四大组件（Activity、Service、Broadcast Receiver、Content Provider）入手，通过官方文档和简单的示例代码理解它们各自的作用、生命周期以及如何在项目中使用。接着学习 Android 的布局管理，掌握不同布局（LinearLayout、RelativeLayout 等）的特点和使用场景，能够进行简单的界面设计。之后再深入学习如网络请求、数据库操作等功能的实现，通过不断地做一些小项目来巩固知识，逐步积累经验，遇到复杂的问题时查阅资料、参考开源项目或者向其他开发者请教，持续提升自己的能力。

看过哪些书

《第一行代码 ——Android》是一本很不错的入门书籍，它以通俗易懂的语言介绍了 Android 开发的基础知识，从搭建环境到创建简单的应用，逐步引导读者掌握 Android 开发的各个环节，并且书中有很多实际的代码示例，方便读者跟着操作和理解。

《Android 编程权威指南》也是很值得一看的，它涵盖了 Android 开发从基础到进阶的大量内容，对各种组件、布局、线程管理等方面都有详细的讲解，还通过实际的项目案例来帮助读者更好地理解知识如何运用到实际开发中，对于想要系统学习 Android 开发的人来说是一本很好的参考书籍。

《Effective Android UI》这本书聚焦于 Android 的用户界面设计和优化，讲解了如何创建高效、美观且易用的 UI 界面，对于提升应用的用户体验方面有很多实用的建议和技巧，有助于开发者在掌握基本开发技能后，进一步优化应用的界面呈现效果。

你自己觉得做过最好的一个 Android 页面是什么？

我觉得做得比较好的一个 Android 页面是在一个音乐播放应用中打造的音乐播放详情页。这个页面整体布局上，上方是一个自定义的圆形 ImageView 用于展示专辑封面，封面图片的加载采用了合适的图片加载库，能够高效地从网络获取并缓存图片，显示效果清晰且加载速度快。下方通过 LinearLayout 和 RelativeLayout 等布局的组合，划分出了歌曲信息展示区域，包括歌曲名、歌手名等信息，文字的大小、颜色搭配合理，视觉上很协调，并且在不同屏幕尺寸的设备上都能自适应显示良好。

在交互方面，点击专辑封面可以实现图片的放大查看以及旋转动画效果，通过设置 OnClickListener 和动画相关代码实现了流畅的交互体验。页面中还有播放控制区域，包含播放 / 暂停按钮、上一首 / 下一首按钮等，这些按钮通过设置合适的背景图片以及触摸反馈效果（比如按下时颜色变化等），让用户能够清晰地感知操作是否被响应，而且按钮的点击事件处理非常及时，通过与后台 Service 进行通信，能够迅速地执行相应的音乐播放控制操作。

另外，页面还集成了歌词显示功能，采用了 RecyclerView 来展示歌词，每句歌词作为一个 Item，并且通过自定义的 Adapter 和 ViewHolder 实现了歌词的逐行滚动显示效果，与音乐的播放进度精准同步，这一过程中利用了定时器以及对音乐播放状态的监听等机制来确保歌词滚动的准确性和流畅性。同时，在页面的底部还设计了一个透明的 Mini 播放栏，当用户滑动页面时它会半隐藏起来，既不影响页面主体内容的展示，又方便用户随时操作音乐播放，通过监听页面的滚动事件以及动画的配合实现了这样一个简洁又实用的功能。整个页面在功能实现、用户体验以及视觉效果上都达到了较好的平衡，所以我觉得它是做得比较出色的一个 Android 页面。

Android 和 Spring 都用的 Java，你分析一下这两种开发（框架）用的 Java 的区别？

Android 开发中 Java 的特点

在 Android 开发中，Java 主要用于构建运行在移动设备上的应用程序。首先，Android 有其特定的 Android SDK，Java 代码需要依赖这个 SDK 提供的众多类和接口来实现功能，比如通过 Activity、Service 等组件类构建应用的架构，使用 Android 提供的各种 UI 控件类来创建用户界面，所以代码中会大量引入 Android 相关的包和类。

Android 开发要着重考虑移动设备的资源限制，如内存、CPU 性能等，因此在编写 Java 代码时需要更加注重性能优化，像避免在主线程进行耗时操作，合理使用内存缓存（如 LruCache 等）来管理图片等占用内存较大的资源，对代码的效率和资源占用把控较为严格。

并且，Android 开发中 Java 代码要适配多种不同的设备屏幕尺寸、分辨率以及硬件特性，需要使用一些布局管理的技巧和代码逻辑来确保界面在不同设备上的显示效果，比如使用不同的布局方式（LinearLayout、RelativeLayout 等）以及通过代码动态设置视图的大小和位置等，以实现良好的界面适配。

Spring 开发中 Java 的特点

Spring 框架主要用于企业级的后端开发，使用 Java 来构建服务器端的应用程序。Spring 强调的是依赖注入、面向切面编程等设计理念，通过 Java 代码结合 Spring 的各种注解（如 @Component、@Autowired 等）以及配置文件（如 XML 配置或者 JavaConfig 配置）来实现对象之间的依赖管理和功能的模块化，使得代码的耦合度更低，更易于维护和扩展。

在 Spring 开发中，会大量涉及到与数据库的交互，通过 Java 代码使用 Spring 提供的数据访问层框架（如 Spring Data JPA 等）来操作数据库，实现数据的持久化存储和查询，需要遵循数据库相关的规范和最佳实践，比如事务管理、SQL 语句编写等，以确保数据的一致性和完整性。

同时，Spring 开发常常要考虑高并发场景下的性能和稳定性，会运用多线程、线程池等 Java 相关技术以及 Spring 自身的异步处理机制（如 @Async 注解等）来提高系统的响应能力，处理大量的并发请求，保障后端服务的高效运行。

二者的区别

应用场景：Android 中的 Java 用于移动端应用开发，面向的是终端用户，注重用户界面交互和移动设备的资源利用；而 Spring 中的 Java 用于企业级后端开发，主要为前端应用提供数据支持和业务逻辑处理，面向的是网络请求和数据存储等方面的需求。
框架依赖和功能侧重：Android 开发依赖 Android SDK 实现移动应用特有的功能，如 UI 展示、传感器应用等；Spring 开发依赖 Spring 框架实现企业级应用的功能，如依赖注入、事务管理、微服务构建等，二者在功能实现的侧重点上差异明显。
性能优化方向：Android 开发更多关注移动设备上的内存、CPU 性能优化以及界面渲染的流畅性；Spring 开发侧重于服务器端的高并发处理、数据库访问效率以及整体系统的可扩展性等方面的性能优化。
代码结构和设计模式：Android 开发中虽然也会用到一些设计模式，但受限于移动端应用的特点，代码结构相对更偏向于以 Activity 等组件为核心构建；S