Update articles

Author: Tan Minghui

android/Android O 后台限制.md

@@ -0,0 +1,28 @@
+# Android O 后台限制
+
+## 后台服务限制
+
+### 前台应用
+
+满足以下任意条件的应用被视为处于前台：
+
+- 具有可见的 Activity
+- 具有前台服务
+- 另一个前台应用关联到该应用，如输入法、壁纸服务、语音服务等
+
+如果以上条件均不满足，应用将被视为处于后台。
+
+### 后台服务
+
+应用在后台期间保留其后台服务的能力将受到限制。如果应用处于后台时调用了 `startService()` 将会抛出 `IllegalStateException`，除非：
+
+- **应用已经处于前台，则可以调用 startService()，不会抛出 IllegalStateException**，但一旦进入后台，后台应用将被置于一个临时白名单中，位于白名单中时，应用可以无限制地启动服务，其后台服务也可以运行。但这个时间窗一过，应用进入空闲状态，后台服务就会被销毁（Nexus 5X 8.0 系统上测试不到1分钟）
+- **启动前台服务**
+- **绑定服务，即使应用处于后台也不受影响**
+
+## 隐式广播限制
+
+### 定义
+
+应用无法在 `AndroidManifest.xml` 中声明隐式广播接收器，以获得绝大部分响应系统事件的后台能力。
+

android/Android 广播.md

@@ -27,7 +27,7 @@
 
 - 静态注册
 
-静态注册是常驻型 ，也就是说当应用程序关闭后，如果有信息广播来，程序也会被系统调用自动运行。
+静态注册是常驻型 ，不能销毁广播接收器。也就是说当应用程序关闭后，如果有信息广播来，程序也会被系统调用自动运行。
 
 - 动态注册
 

android/Android 进程保活.md

@@ -0,0 +1,43 @@
+# Android 进程保活
+
+## 背景
+
+### 进程等级
+
+**前台进程**
+
+- 与用户正在交互的Activity
+- 前台Activity以bind方式启动的Service
+- Service调用了startForground，绑定了Notification
+- 正在执行生命周期的Service，例如在执行onCreate、onStart、onDestory
+- 正在执行onReceive方法的BroadcastReceiver
+
+**可见进程**
+
+- 托管不在前台、但仍对用户可见的 Activity（已调用其 onPause() 方法）。例如，如果前台 Activity 启动了一个对话框，允许在其后显示上一 Activity，则有可能会发生这种情况。
+- 托管绑定到可见（或前台）Activity 的 Service。
+
+**服务进程**
+ 正在运行已使用 startService() 方法启动的服务且不属于上述两个更高类别进程的进程。尽管服务进程与用户所见内容没有直接关联，但是它们通常在执行一些用户关心的操作（例如，在后台播放音乐或从网络下载数据）。因此，除非内存不足以维持所有前台进程和可见进程同时运行，否则系统会让服务进程保持运行状态。
+
+**后台进程**
+ 包含目前对用户不可见的 Activity 的进程（已调用 Activity 的 onStop() 方法）。这些进程对用户体验没有直接影响，系统可能随时终止它们，以回收内存供前台进程、可见进程或服务进程使用。 通常会有很多后台进程在运行，因此它们会保存在 LRU （最近最少使用）列表中，以确保包含用户最近查看的 Activity 的进程最后一个被终止。如果某个 Activity 正确实现了生命周期方法，并保存了其当前状态，则终止其进程不会对用户体验产生明显影响，因为当用户导航回该 Activity 时，Activity 会恢复其所有可见状态。
+
+**空进程**
+ 不含任何活动应用组件的进程。保留这种进程的的唯一目的是用作缓存，以缩短下次在其中运行组件所需的启动时间。 为使总体系统资源在进程缓存和底层内核缓存之间保持平衡，系统往往会终止这些进程。
+
+## 总结
+
+**提升进程优先级**的方式
+
+- Activity提权，监听屏幕的息屏和解锁，使用一个1个像素的Activity
+- Service提权，Service通过startForground方法来开启一个Notification
+
+**进程拉活**
+
+- 通过广播的方式
+- 通过Service在onStartCommand的返回值，START_STICKY，由系统拉活，在短时间内如果多次被杀死可能就再也启动不了了
+- 通过账户同步拉活
+- 通过JobScheduler拉活
+- 通过Service的bind启动的方式，双进程守护拉活
+- 推送拉活

android/Fragment 总结.md

@@ -0,0 +1,5 @@
+# Fragment 总结
+
+## 生命周期
+
+![img](https://images2015.cnblogs.com/blog/462303/201510/462303-20151013221141007-1433074538.jpg)

android/Service 总结.md

@@ -0,0 +1,5 @@
+# Service 总结
+
+## 生命周期
+
+![img](https://upload-images.jianshu.io/upload_images/4625401-756d89b600d55081.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/404/format/webp)

other/HTTP 原理.md renamed to 网络/HTTP 原理.md

@@ -29,7 +29,7 @@ Connection: keep-alive
 
 #### HTTP/1.1
 
-1997 年，HTTP/1.1 版本发布，它进一步完善了 HTTP 协议，直到现在还是最流行的版本。
+1997 年，HTTP/1.1 版本发布，它进一步完善了 HTTP 协议，直到现在还是**最流行的版本**。
 
 **相比于 1.0 版：**
 

other/HTTPS 原理.md renamed to 网络/HTTPS 原理.md

@@ -137,40 +137,20 @@ SSL 的数字签名和上面说到的数字签名基本一致。就是先通过
 
 ## 一次完整的 HTTPS 的通信步骤
 
-步骤 1：客户端向服务器发送 ClientHello 报文，请求建立 SSL 连接。
-
-ClientHello 报文：
-
-- 客户端支持的 SSL 版本
-- 客户端支持的加密算法
-- 客户端支持的密钥长度
-
-步骤 2：服务器收到客户端的请求后，向客户端发送 ServerHello 报文。
-
-ServerHello 报文：
-
-- 决定使用的 SSL 版本
-- 决定使用的加密算法
-
-步骤 3：服务器继续发送 Certificate 报文，即服务器的数字证书，其中包含服务器的公开密钥。
-
-步骤 4：服务器发送 ServerHelloDone 报文，通知客户端进最初阶段的 SSL 握手协商部分结束。
-
-步骤 5：客户端收到以上所有信息后，发送 ClientKeyExchange 报文作为回应。该报文已使用步骤 3 中的公开密钥加密。其中包含一种称为 Pre-master secret 的随机密码串，用于之后的对称秘钥加密通信。
-
-步骤 6：客户端继续发送 ChangeCipherSpec 报文，该报文告诉服务器，在此之后的通信都会采用步骤 5 中的 Pre-master secret 秘钥加密。
-
-步骤 7：客户端发送 Finished 报文。改报文包含连接至今全部报文的整体校验值。
-
-步骤 8：服务端对客户端报文校验后，同样发送 ChangeCipherSpec 报文，含义与步骤 6 中的相同。
-
-步骤 9：服务端发送 Finished 报文。
-
-步骤 10：服务端和客户端的 Finished 报文交换完毕后，SSL 连接建立完成。从此后开始进行应用层协议的通信，即 HTTP 通信。
-
-步骤 11：HTTP 通信。
-
-步骤 12：客户端发送 close_notify 报文请求断开连接。之后再发送 TCP FIN 报文来关闭 TCP 通信。
+![img](http://img.blog.csdn.net/20160818103824711?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
+
+- 步骤 1： 客户端通过发送 Client Hello 报文开始 SSL 通信。报文中包含客户端支持的 SSL 的指定版本、加密组件（Cipher Suite）列表（所使用的*加密算法*及*密钥长度*等）。
+- 步骤 2： 服务器可进行 SSL 通信时，会以 Server Hello 报文作为应答。和客户端一样，在报文中包含 SSL 版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。
+- 步骤 3： 之后服务器发送 Certificate 报文。报文中包含***公开密钥证书***。
+- 步骤 4： 最后服务器发送 Server Hello Done **报文通知客户端**，最初阶段的*SSL握手协商*部分结束。
+- 步骤 5： SSL 第一次握手结束之后，客户端以 Client Key Exchange 报文作为回应。报文中包含通信加密中使用的一种被称为 Pre-master secret 的随机密码串。该报文已用步骤 3 中的公开密钥进行加密。
+- 步骤 6： 接着客户端继续发送 Change Cipher Spec 报文。该报文会提示服务器，在此报文之后的通信会采用 Pre-master secret 密钥加密。
+- 步骤 7： 客户端发送 Finished 报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为判定标准。
+- 步骤 8： 服务器同样发送 Change Cipher Spec 报文。
+- 步骤 9： 服务器同样发送 Finished 报文。
+- 步骤 10： 服务器和客户端的 Finished 报文交换完毕之后，SSL 连接就算建立完成。当然，通信会受到 SSL 的保护。从此处开始进行应用层协议的通信，即发送 HTTP请求。
+- 步骤 11： 应用层协议通信，即发送 HTTP 响应。
+- 步骤 12： 最后由客户端断开连接。断开连接时，发送 close_notify 报文。上图做了一些省略，这步之后再发送 TCP FIN 报文来关闭与 TCP 的通信。在以上流程中，应用层发送数据时会附加一种叫做 MAC（Message Authentication Code）的报文摘要。MAC 能够查知报文是否遭到篡改，从而保护报文的完整性。
 
 ## HTTPS 性能考虑
 

网络/IP 协议.md

@@ -0,0 +1,95 @@
+# TCP 和 UDP
+
+## TCP 报文包
+
+![img](https://skminhaj.files.wordpress.com/2016/02/92926-tcp_udp_headers.jpg?w=640&h=358)
+
+TCP报文由首部和数据两部分组成。首部一般由20-60 Byte 构成，长度可变。其中前20 Byte 格式固定，后40 Byte 为可选。
+
+因为，TCP报文还得传给下层网络层，封装成IP包，而一个IP包最大长度为65535，同时IP包首部也包含最少20 Byte ，所以一个IP包或TCP包可以包含的数据部分最大长度为65535-20-20=65495 Byte 。
+
+TCP报文中数据部分是可选的，即**TCP报文可以不包含数据**（同理IP包也可以不包含数据）。不含数据的TCP报文通常是一些确认和控制信息类的报文，如TCP建立连接时的三次握手和TCP终止时的四次挥手等。
+
+- **Source Port**和 **Destination Port**: 分别占用16位，表示源端口号和目的端口号；用于区别主机中的不同进程，而IP地址是用来区分不同的主机的，源端口号和目的端口号配合上IP首部中的源IP地址和目的IP地址就能唯一的确定一个TCP连接；
+
+- **Sequence Number**: 用来标识从TCP发端向TCP收端发送的数据字节流，它表示在这个报文段中的的第一个数据字节在数据流中的序号；主要用来**解决网络报乱序的问题**；
+
+- **Acknowledgment Number**: 32位确认序列号包含发送确认的一端所期望收到的下一个序号，因此，确认序号应当是上次已成功收到数据字节序号加1。不过，只有当标志位中的ACK标志（下面介绍）为1时该确认序列号的字段才有效。**主要用来解决不丢包的问题**；
+
+- Data Offset: 给出首部中32 bit字的数目，需要这个值是因为任选字段的长度是可变的。这个字段占4bit（最多能表示15个32bit的的字，即4*15=60个字节的首部长度），因此TCP最多有60字节的首部。然而，没有任选字段，正常的长度是20字节；
+
+- TCP Flags: TCP首部中有6个标志比特，它们中的多个可同时被设置为1，主要是用于操控TCP的状态机的，依次为URG，ACK，PSH，RST，SYN，FIN。每个标志位的意思如下：
+
+- - URG：此标志表示TCP包的紧急指针域（后面马上就要说到）有效，用来保证TCP连接不被中断，并且督促中间层设备要尽快处理这些数据；
+  - ACK：此标志表示应答域有效，就是说前面所说的TCP应答号将会包含在TCP数据包中；有两个取值：0和1，为1的时候表示应答域有效，反之为0；
+  - PSH：这个标志位表示Push操作。所谓Push操作就是指在数据包到达接收端以后，立即传送给应用程序，而不是在缓冲区中排队；
+  - RST：这个标志表示连接复位请求。用来复位那些产生错误的连接，也被用来拒绝错误和非法的数据包；
+  - SYN：表示同步序号，用来**建立连接**。SYN标志位和ACK标志位搭配使用，当连接请求的时候，SYN=1，ACK=0；连接被响应的时候，SYN=1，ACK=1；这个标志的数据包经常被用来进行端口扫描。扫描者发送一个只有SYN的数据包，如果对方主机响应了一个数据包回来 ，就表明这台主机存在这个端口；但是由于这种扫描方式只是进行TCP三次握手的第一次握手，因此这种扫描的成功表示被扫描的机器不很安全，一台安全的主机将会强制要求一个连接严格的进行TCP的三次握手；
+  - FIN： 表示发送端已经达到数据末尾，也就是说双方的数据传送完成，没有数据可以传送了，发送FIN标志位的TCP数据包后，连接将被断开。这个标志的数据包也经常被用于进行端口扫描。
+
+- Window: 窗口大小，也就是有名的滑动窗口，用来进行流量控制；
+
+- CheckSum: 包含TCP首部和TCP数据段，这是一个强制性的字段，一定是由发送端计算和存储，由接收端进行验证。
+
+- Urgent Pointer: 长度为16 ，指向数据中优先部分的最后一个字节，通知接收方紧急数据的长度，该字段在URG标志置位时有效。
+
+- Options: 长度为0-40B（字节），必须以4B为单位变化，必要时可以填充0。通常包含：最长报文大小（MaximumSegment Size，MSS）、窗口扩大选项、时间戳选项、选择性确认（Selective ACKnowlegement，SACK）等。
+
+## UDP 报文包
+
+![img](https://skminhaj.files.wordpress.com/2016/02/92926-tcp_udp_headers.jpg?w=640&h=358)
+
+UDP数据报由首部和数据两部分组成，其中首部只有8 Byte。
+
+- Source Port: 长度为16位，指明发送数据的进程。
+- Destination Port：长度为16位，指明目的主机接收数据的进程。
+- Length：长度为16位，该字段值为报头和数据两部分的总字节数。
+- Checksum：长度为16位，UDP检验和作用于UDP报头和UDP数据的所有位。由发送端计算和存储，由接收端校验。
+- 数据
+
+## TCP 与 UDP 的区别
+- TCP**面向连接**（如打电话要先拨号建立连接）；UDP是**无连接的**，即发送数据之前不需要建立连接
+- TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，**无差错，不丢失，不重复**，且按序到达；UDP尽最大努力交付，即不保证可靠交付
+- TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流；UDP是面向报文的，UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）
+- 每一条TCP连接只能是点到点的；UDP支持一对一，一对多，多对一和多对多的交互通信
+- TCP首部开销20字节；UDP的首部开销小，只有8个字节
+- TCP的逻辑通信信道是**全双工**的可靠信道，UDP则是不可靠信道
+
+## 三次握手
+
+![img](https://images0.cnblogs.com/blog2015/545411/201505/231506144997010.png)
+
+第一次握手：主机A发送位码为syn＝1,随机产生seq number=x的数据包到服务器，客户端进入`SYN_SEND`状态，等待服务器的确认；主机B由SYN=1知道，A要求建立联机；
+
+第二次握手：主机B收到请求后要确认联机信息，向A发送ack number(主机A的seq+1),syn=1,ack=1,随机产生seq=y的包,此时服务器进入`SYN_RECV`状态;
+
+第三次握手：主机A收到后检查ack number是否正确，即第一次发送的seq number+1,以及位码ack是否为1，若正确，主机A会再发送ack number(主机B的seq+1),ack=1，主机B收到后确认seq值与ack=1则连接建立成功。客户端和服务器端都进入`ESTABLISHED`状态，完成TCP三次握手。
+
+### 为什么需要三次握手
+
+防止了服务器端的一直等待而浪费资源。
+
+## 四次分手
+
+![img](https://images0.cnblogs.com/blog2015/545411/201505/231512425935841.png)
+
+第一次挥手：主机1（可以使客户端，也可以是服务器端），设置`Sequence Number`和`Acknowledgment Number`，向主机2发送一个`FIN`报文段；此时，主机1进入`FIN_WAIT_1`状态；这表示主机1没有数据要发送给主机2了；
+
+第二次挥手：主机2收到了主机1发送的`FIN`报文段，向主机1回一个`ACK`报文段，`Acknowledgment Number`为`Sequence Number`加1；主机1进入`FIN_WAIT_2`状态；主机2告诉主机1，我也没 有数据要发送了，可以进行关闭连接了；
+
+第三次挥手：主机2向主机1发送`FIN`报文段，请求关闭连接，同时主机2进入`CLOSE_WAIT`状态；
+
+第四次挥手：主机1收到主机2发送的`FIN`报文段，向主机2发送`ACK`报文段，然后主机1进入`TIME_WAIT`状态；主机2收到主机1的`ACK`报文段以后，就关闭连接；此时，主机1等待2MSL后依然没有收到回复，则证明Server端已正常关闭，那好，主机1也可以关闭连接了。
+
+### 状态机变化
+
+- FIN_WAIT_1: 这个状态要好好解释一下，其实FIN_WAIT_1和FIN_WAIT_2状态的真正含义都是**表示等待对方的FIN报文**。而这两种状态的区别是：FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时，它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET即进入到FIN_WAIT_1状态。而当对方回应ACK报文后，则进入到FIN_WAIT_2状态，当然在实际的正常情况下，无论对方何种情况下，都应该马上回应ACK报文，所以FIN_WAIT_1状态一般是比较难见到的，而FIN_WAIT_2状态还有时常常可以用netstat看到。（主动方）
+- FIN_WAIT_2：上面已经详细解释了这种状态，实际上FIN_WAIT_2状态下的SOCKET，表示半连接，也即有一方要求close连接，但另外还告诉对方，我暂时还有点数据需要传送给你(ACK信息)，稍后再关闭连接。（主动方）
+- CLOSE_WAIT：这种状态的含义其实是表示在等待关闭。怎么理解呢？当对方close一个SOCKET后发送FIN报文给自己，你系统毫无疑问地会回应一个ACK报文给对方，此时则进入到CLOSE_WAIT状态。接下来呢，实际上你真正需要考虑的事情是察看你是否还有数据发送给对方，如果没有的话，那么你也就可以 close这个SOCKET，发送FIN报文给对方，也即关闭连接。所以你在CLOSE_WAIT状态下，需要完成的事情是等待你去关闭连接。（被动方）
+- LAST_ACK: 这个状态还是比较容易好理解的，它是被动关闭一方在发送FIN报文后，最后等待对方的ACK报文。当收到ACK报文后，也即可以进入到CLOSED可用状态了。（被动方）
+- TIME_WAIT: 表示收到了对方的FIN报文，并发送出了ACK报文，就等2MSL后即可回到CLOSED可用状态了。如果FIN*WAIT*1状态下，收到了对方同时带FIN标志和ACK标志的报文时，可以直接进入到TIME_WAIT状态，而无须经过FIN_WAIT_2状态。（主动方）
+- CLOSED: 表示连接中断。
+
+### 为什么需要四次分手
+
+那四次分手又是为何呢？TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。TCP是全双工模式，这就意味着，当主机1发出FIN报文段时，只是表示主机1已经没有数据要发送了，主机1告诉主机2，它的数据已经全部发送完毕了；但是，这个时候主机1还是可以接受来自主机2的数据；当主机2返回ACK报文段时，表示它已经知道主机1没有数据发送了，但是主机2还是可以发送数据到主机1的；当主机2也发送了FIN报文段时，这个时候就表示主机2也没有数据要发送了，就会告诉主机1，我也没有数据要发送了，之后彼此就会愉快的中断这次TCP连接。