昨天，有读者私信发我掘金上的一篇文章，说里面提到的 Intellij IDEA 插件真心不错，基本上可以一站式开发了，希望能分享给更多的小伙伴，我在本地装了体验了一下，觉得确实值得推荐，希望小伙伴们有时间也可以尝试一下。

Vuesion Theme

颜值是生产力的第一要素，IDE 整好看了，每天对着它也是神清气爽，有木有？就 Intellij IDEA 提供的暗黑和亮白主色，虽然说已经非常清爽了，但时间久了总觉得需要再来点新鲜感？

Vuesion Theme 这个主题装上后，你会感觉整个 Intellij IDEA 更高级了。

安装完插件就立马生效了，瞧这该死的漂亮，整个代码着色，以及文件的图标，都更炫酷了：

当然了，主题这事，萝卜白菜各有所爱，就像玩 dota，我就喜欢露娜。

lombok

可能提到 lombok，多多少少有些争议，但不得不说，这玩意的确是很能省代码，并且很多开源的第三方 jar 包，以及 Intellij IDEA 2020.3 以后的版本也都默认加了 lombok。

这么多注解可以选择，在写 VO、DO、DTO 的时候是真的省心省力。

如果没有 lombok 的帮助，那整个代码就要炸了呀。对比一下，是不是感受还挺明显的？

当然了，要使用 lombok，你得在 pom.xml 文件中引入 lombok 的依赖包。

xml
复制代码
<dependency>

    <groupId>org.projectlombok</groupId>

    <artifactId>lombok</artifactId>

</dependency>

File Expander

这个插件不仅可以反编译，还可以打开 tar.gz，zip 等压缩文件，

如果有小伙伴反驳说自己不装插件也可以打开 jar 包里的代码，那是因为你的 jar 在 classpath。如果单独打开一个 jar 包，不装插件是看不了的。

GitToolBox

如果你经常使用 Git 提交代码的话，这款插件就非常的爽。

它能直接提示你远程版本库里有多少文件更新，你有多少文件没有提交到版本库，甚至可以显示上一次提交的时间和版本更新者。

Maven Helper

这插件几乎人手一个了吧，Java 后端开发必备啊。

依赖可视化的神器，可以很清楚地知道依赖的关系图谱，假如有冲突的话，也是一目了然。

Translation

对于英文能力差的同学来说，这个翻译插件简直神了，它支持 Google 翻译、有道翻译、百度翻译、Alibaba 翻译。

刚好写这篇内容的时候，发现最新的版本是 3.3.5，趁机升级一波。有了这款翻译插件，看源码绝对是爽歪歪。以前遇到不认识的单词，真的是好烦，还要切到翻译软件那里查，现在可好，单词翻译、文档翻译、注释翻译，都有了。

arthas idea

Arthas 应该大家都很熟悉了，阿里开源的一款强大的 java 在线诊断工具。

但如果每次都要你输入一长串命令的话，相信你也会很崩溃，尤其是很多时候我还记忆模糊，很多记不住。这款插件刚好解决了我这个烦恼，极大地提高了生产力

使用起来也非常方便，直接进入你要诊断的方法和类，右键选择对应的命令，就会自动帮你生成了。

Free Mybatis plugin

Mybatis 基本上是目前最主流的 ORM 框架了，相比于 hibernate 更加灵活，性能也更好。所以我们一般在 Spring Boot 项目中都会写对应的 mapper.java 和 mapper.xml。

那有了这款插件之后，两者就可以轻松关联起来。

比如，我这里要查看 ArticleMapper 的 xml，那么编辑器的行号右侧就会有一个向右的→，直接点击就跳转过去了。

想跳转回来的话，也是同样的道理，所以有了这款产检，mapper 和 xml 之间就可以自由切换了，丝滑。

VisualGC

这里给大家推荐一个 JVM 堆栈可视化工具，可以和 Intellij IDEA 深度集成——VisualGC。

当我们需要监控一个进程的时候，直接打开 VisualGC面板，就可以查看到堆栈和垃圾收集情况，可以说是一目了然。

CheckStyle-IDEA

如果你比较追求代码规范的话，可以安装这个插件，它会提醒你注意无用导入、注释、语法错误❎、代码冗余等等。

在 CheckStyle 面板中，你可以选择 Google 代码规范或者 sun 的代码规范，跑一遍检查，就可以看到所有的修改建议了。

最后

以上这 10 款 Intellij IDEA 插件也是我平常开发中经常用到的，如果大家有更好更效率的插件，也可以评论里留言。

参考链接：juejin.cn/post/702802…

没有什么使我停留——除了目的，纵然岸旁有玫瑰、有绿荫、有宁静的港湾，我是不系之舟。

本文已收录到 GitHub 上星标 4k+ 的开源专栏《Java 程序员进阶之路》，据说每一个优秀的 Java 程序员都喜欢她，风趣幽默、通俗易懂。内容包括 Java 基础、Java 并发编程、Java 虚拟机、Java 企业级开发（Git、Nginx、Maven、Intellij IDEA、Spring、Spring Boot、Redis、MySql 等等）、Java 面试等核心知识点。学 Java，就认准 Java 程序员进阶之路😄。

Github 仓库：github.com/itwanger/to…

star 了这个仓库就等于你拥有了成为了一名优秀 Java 工程师的潜力。

说起FastAPI,我们一开始是不太想尝试的，毕竟是个没尝试过的开发框架，怕踩坑，怕影响项目开发周期。

一直以来我们的主要开发框架是 Django，Django 是个非常方便的 Python 后端框架，一条命令即可生成规范的项目结构，命令创建子应用，健壮的数据库 ORM 支持，功能完善、要素齐全：自带大量常用工具和框架（比如分页，auth，权限管理), 适合快速开发企业级网站。完善的文档：经过多年的发展和完善，Django 有广泛的实践案例和完善的在线文档，可以让开发人员有好的借鉴途径。并且使用众多，能够借鉴的例子也很多。目前 NetDevOps 的平台后端，大多数都是基于 Python 的 Django 来开发的，原因是：python 的确上手快，django 支持完善，能够迅速的建立和设备的联系并生成自带的管理页面。

但是Django太全了太重了，随着开发周期越往后，开发模块越来越多，整个程序就显得异常臃肿，代码逻辑相互耦合十分严重，整个系统需要保持极高的稳定性。所以，我们希望能够有个小而精的框架，可以逐步的将Django项目中的模块慢慢做拆分，做解耦，做程序的可插拔。FastAPI这时候进入到我们的视野。

FastAPI 顾名思义，一个字，就是快。基于（并完全兼容）OPenAPI 的相关开放标准。

• 高性能：FastAPI 采用异步编程模式，基于 Starlette 框架和 pydantic 库进行开发。其性能相比于 Flask 和 Django 均有很大提升。


• 简单易用：FastAPI 提供了自动生成 API 文档的功能，丰富的文档可以让开发人员更快速地了解 API 的使用方法。


• 规范化：FastAPI 默认支持 OpenAPI（前身为 Swagger）和 JSON Schema，从而规范化 API 的设计和发布。


• 类型检查：FastAPI 强制使用类型注解，使得代码更加严谨，同时可以使用 mypy 等类型检查工具来保证代码的质量。


• 整合多种数据库支持：FastAPI 可以无缝进行整合多种数据库的使用，比如 SQLAlchemy、Tortoise ORM 等。

使用 FastAPI 可以提升性能、简化开发、规范 API 设计、增加代码可读性和可维护性，从而促进开发效率的提升。 FastAPI 站在以下巨人的肩膀之上：

Starlette 负责 web 部分。 Pydantic 负责数据部分。

Starlette

Starlette 是一个轻量级的 ASGI 框架和工具包，特别适合用来构建高性能的 asyncio 服务.

Starlette 的主要特性：

1. 性能表现优异


2. WebSocket 支持.


3. GraphQL 支持.


4. 进程内的后台任务执行


5. 启动和关闭服务的事件触发


6. 测试客户端构建于 requests.


7. 支持 CORS, GZip, Static Files, Streaming 响应.


8. 支持会话和 Cookie


9. 100% 测试覆盖率


10. 100% 类型注解


11. 无依赖

Pydantic

pydantic 库是 python 中用于数据接口定义检查与设置管理的库。

pydantic 在运行时强制执行类型提示，并在数据无效时提供友好的错误。

它具有如下优点：

1. 与 IDE/linter 完美搭配，不需要学习新的模式，只是使用类型注解定义类的实例


2. 多用途，BaseSettings 既可以验证请求数据，也可以从环境变量中读取系统设置


3. 快速


4. 可以验证复杂结构


5. 可扩展，可以使用 validator 装饰器装饰的模型上的方法来扩展验证


6. 数据类集成，除了 BaseModel，pydantic 还提供了一个 dataclass 装饰器，它创建带有输入数据解析和验证的普通 Python 数据类。

FastAPI 推荐使用 uvicorn 启动服务

Uvicorn 是基于 uvloop 和 httptools 构建的非常快速的 ASGI 服务器。

uvicorn 是一个基于 asyncio 开发的一个轻量级高效的 web 服务器框架

uvicorn 设计的初衷是想要实现两个目标：

使用 uvloop 和 httptools 实现一个极速的 asyncio 服务器

实现一个基于 ASGI（异步服务器网关接口）的最小应用程序接口。

它目前支持 http, websockets, Pub/Sub 广播，并且可以扩展到其他协议和消息类型。

uvloop 用于替换标准库 asyncio 中的事件循环，使用 Cython 实现，它非常快，可以使 asyncio 的速度提高 2-4 倍。asyncio 不用我介绍吧，写异步代码离不开它。

httptools 是 nodejs HTTP 解析器的 Python 实现。

综述

综上所述，我们推荐使用 FastAPI 来进行快速开发和程序构建，尤其是功能较为简单的应用，它也支持数据结构校验和异步。提高代码执行效率和开发效率。同时具备丰富的数据支持，基于 OpenAPI 的自助交互式文档，让开发过程中的调试也十分方便。快速敏捷开发是我们的追求。

• 快速开发：提供基础框架和默认设置，使开发人员可以快速构建 API，并自动生成文档和测试样例。


• 高性能：基于 Python 3.6+、ASGI 和 asyncio 等技术，提供高性能特性，因此在高流量和低延迟的应用场景下比其他框架有更好的响应速度和性能。


• 文档自动生成：内置文档生成器，自动解析函数参数和返回值来生成规范化的文档，并支持 OpenAPI 和 JSON Schema 的标准格式。


• 强类型支持：采用类型注解，提高代码的质量和可读性，减少出现运行时错误的可能性。


• 多种数据库支持：支持多种数据库，包括 SQLAlchemy、Tortoise ORM 等，可以方便地处理数据库操作。

FastAPI 是一款快速、高性能、安全、易用、规范化的 Web 应用框架，能够极大地提高开发效率，保证应用的高性能和可靠性。

知乎上搜到一个比较有意思的话题：如何理解「进入内核态」，要回答好这个问题需要对内存管理及程序的运行机制有比较深刻的了解，比如你需要了解内存的分段，分页，中断等机制，信息量比较大，本文将会 Intel CPU 的发展历史讲起，循序渐近地帮助大家彻底掌握这一概念，相信大家看了肯定有帮助，本文目录如下

• CPU 运行机制


• Intel CPU 历史发展史
  
  
  
  • 分段
  
  
  • 保护模式
  
  
  
  


• 特权级
  
  
  
  • 系统调用
  
  
  • 中断
  
  
  
  


• 分段内存的优缺点


• 内存分页


• 总结

CPU 运行机制

我们先简单地回顾一下 CPU 的工作机制，重新温习一下一些基本概念，因为我在查阅资料的过程发现一些网友对寻址，CPU 是几位的概念理解得有些模糊，理解了这些概念再去看 CPU 的发展史就不会再困惑

CPU 是如何工作的呢？它是根据一条条的机器指令来执行的，而机器指令= 操作码+操作数，操作数主要有三类：寄存器地址、内存地址或立即数（即常量）。

我们所熟悉的程序就是一堆指令和数据的集合，当打开程序时，装载器把程序中的指令和数据加载到内存中，然后 CPU 到内存中一条条地取指令，然后再译码，执行。

在内存中是以字节为基本单位来读写数据的，我们可以把内存看作是一个个的小格子（一般我们称其为内存单元），而每个小格子是一个字节，那么对于 B8 0123H 这条指令来说，它在内存中占三字节，如下，CPU 该怎么找到这些格子呢，我们需要给这些格子编号，这些编号也就是我们说的内存地址，根据内存地址就是可以定位指令所在位置，从而取出里面的数据

如图示：内存被分成了一个个的格子，每个格子一个字节，20000~20002 分别为对应格子的编号（即内存地址）

CPU 执行指令主要分为以下几个步骤

1. 
   

   取指令，CPU 怎么知道要去取哪条指令呢，它里面有一个 IP 寄存器指向了对应要取的指令的内存地址， 然后这个内存地址会通过地址总线找到对应的格子，我们把这个过程称为寻址，不难发现寻址能力决定于地址总线的位宽，假设地址总线位数为 20 位，那么内存的可寻址空间为 2^20 * 1Byte = 1M，将格子（内存单元）里面的数据（指令）取出来后，再通过数据总线发往 CPU 中的指令缓存区（指令寄存器），那么一次能传多少数据呢，取决于数据总线的位宽，如果数据总线为 16 位，那么一次可以传 16 bit 也就是两个字节。

   
   


2. 
   

   译码：指令缓冲区中的指令经过译码以确定该进行什么操作

   
   


3. 
   

   执行：译码后会由控制单元向运算器发送控制指令进行操作（比如执行加减乘除等），执行是由运算器操纵数据也就是操作数进行计算，而操作数保存在存储单元（即片内的缓存和寄存器组）中，由于操作数有可能是内存地址，所以执行中可能需要到内存中获取数据（这个过程称为访存），执行后的结果保存在寄存器或写回内存中

   
   

   

   
   

   以指令 mov ax, 0123H 为例，它表示将数据 0123H 存到寄存器 AX 中，在此例中 AX 为 16 位寄存器，一次可以操作 16 位也就是 2 Byte 的数据，所以我们将其称为 16 位 CPU，CPU 是多少位取决于它一次执行指令的数据带宽，而数据带宽又取决于通用寄存器的位宽

   
   


4. 
   

   更新 IP：执行完一条指令后,更新 IP 中的值，将其指向下一条指令的起始地址，然后重复步骤 1

   
   

由以上总结可知寻址能力与寄存器位数有关

接下来我们以执行四条指令为例再来仔细看下 CPU 是如何执行指令的，动图如下：

看到上面这个动图，细心地你可能会发现两个问题

1. 前文说指令地址是根据 IP 来获取的吗，但上图显示指令地址却是由「CS 左移四位 + IP」计算而来的，与我们所阐述的指令保存在 IP 寄存器中似乎有些出入，这是怎么回事呢？


2. 动图显示的地址是真实物理地址，这样进程之间可以互相访问/改写对方的物理地址，显然是不安全的，那如何才能做到安全访问或者说进程间内存的隔离呢

以上两点其实只要我们了解一下 CPU 的发展历史就明白解决方案了，有了以上的铺垫，在明白了寻址，16/32/64 位 CPU 等术语的含义后，再去了解 CPU 的发展故事会更容易得多，话不多说，发车

Intel CPU 历史发展史

1971 年世界上第一块 4 位 CPU-4004 微处理器横空出世，1974 年 Intel 研发成功了 8 位 CPU-8080，这两款 CPU 都是使用的绝对物理地址来寻址的，指令地址只存在于 IP 寄存器中（即只使用 IP 寄存器即可确定内存地址）。由于是使用绝对物理地址寻址，也就意味着进程之间的内存数据可能会互相覆盖，很不安全，所以这两者只支持单进程

分段

1978 年英特尔又研究成功了第一款 16 位 CPU - 8086，这款 CPU 可以说是 x86 系列的鼻祖了，设计了 16 位的寄存器和 20 位的地址总线，所以内存地址可以达到 2^20 Byte 即 1M，极大地扩展了地址空间，但是问题来了，由于寄存器只有 16 位，那么 16 位的 IP 寄存器如何能寻址 20 位的地址呢，首先 Intel 工程师设计了一种分段的方法：1M 内存可以分为 16 个大小为 64 K 的段，那么内存地址就可以由「段的起始地址（也叫段基址） + 段内偏移（IP 寄存器中的值）」组成，对于进程说只需要关心 4 个段 ，代码段 ，数据段 ，堆栈段 ，附加段，这几个段的段基址分别保存在 CS，DS，SS，ES 这四个寄存器中

这四个寄存器也是 16 位，那怎么访问 20 位的内存地址呢，实现也很简单，将每个寄存器的值左移四位，然后再加上段内偏移即为寻址地址，CPU 都是取代码段 中的指令来执行的，我们以代码段内的寻址为例来计算内存地址，指令的地址 = CS << 4 + IP ，这种方式做到了 20 位的寻址，只要改变 CS，IP 的值，即可实现在 0 到最大地址 0xFFFFF 全部 20 位地址的寻址

举个例子：假设 CS 存的数据为 0x2000,IP 为 0x0003,那么对应的指令地址为

图示为真实的物理地址计算方式，从中可知， CS 其实保存的是真实物理地址的高 16 位

分段的初衷是为了解决寻址问题，但本质上CS:IP 计算得到的还是真实物理地址，所以它也无法支持多进程，因为使用绝对物理地址寻址意味着进程可以随意修改 CS：IP，将其指向任意地址，很可能会覆盖正在运行的其他进程的内存，造成灾难性后果。

我们把这种使用真实物理地址且未加任何限制的寻址方式称为实模式（real mode，即实际地址模式）

保护模式

实模式上的物理地址由 段寄存器中的段基址:IP 计算而来，而段基址可由用户随意指定，显然非常不安全，于是 Intel 在之后推出了 80286 中启用了保护模式，这个保护是怎么做的呢

首先段寄存器保存的不再是段基址了，而是段选择子（Selector），其结构如下

其中第 3 到 15 位保存的是描述符索引，此索引会根据 TI 的值是 0 还是 1 来选择是到 GDT（全局描述符表，一般也称为段表）还是 LDT 来找段描述符，段描述符保存的是段基址和段长度，找到段基址后再加上保存在 IP 寄存器中的段偏移量即为物理地址，段描述符的长度统一为 8 个字节，而 GDT/LDT 表的基地址保存在 gdtr/ldtr 寄存器中，以 GDT （此时 TI 值为 0）为例来看看此时 CPU 是如何寻址的

可以看到程序中的地址是由段选择子：段内偏移量组成的，也叫逻辑地址，在只有分段内存管理的情况下它也被称为虚拟内存

GDT 及段描述符的分配都是由操作系统管理的，进程也无法更新 CS 等寄存器中值，这样就避免了直接操作其他进程以及自身的物理地址，达到了保护内存的效果，从而为多进程运行提供了可能，我们把这种寻址方式称为保护模式

那么保护模式是如何实现的呢，细心的你可能发现了上图中在段选择子和段描述符中里出现了 RPL 和 DPL 这两个新名词，这两个表示啥意思呢？这就涉及到一个概念：特权级

特权级

我们知道 CPU 是根据机器指令来执行的，但这些指令有些是非常危险的，比如清内存，置时钟，分配系统资源等，这些指令显然不能让普通的进程随意执行，应该始终控制在操作系统中执行，所以要把操作系统和普通的用户进程区分开来

我们把一个进程的虚拟地址划分为两个空间，用户空间和内核空间，用户空间即普通进程所处空间，内核空间即操作系统所处空间

当 CPU 运行于用户空间（执行用户空间的指令）时，它处于用户态，只能执行普通的 CPU 指令 ，当 CPU 运行于内核空间（执行内核空间的指令）时，它处于内核态，可以执行清内存，置时钟，读写文件等特权指令，那怎么区分 CPU 是在用户态还是内核态呢，CPU 定义了四个特权等级，如下，从 0 到 3，特权等级依次递减，当特权级为 0 时，CPU 处于内核态，可以执行任何指令，当特权级为 3 时，CPU 处于用户态，在 Linux 中只用了 Ring 0，Ring 3 两个特权等级

那么问题来了，怎么知道 CPU 处于哪一个特权等级呢，还记得上文中我们提到的段选择子吗

其中的 RPL 表示请求特权（(Requested privilege level)）我们把当前保存于 CS 段寄存器的段选择子中的 RPL 称为 CPL（current priviledge level），即当前特权等级，可以看到 RPL 有两位，刚好对应着 0,1,2,3 四个特权级，而上文提到的 DPL 表示段描述符中的特权等级（Descriptor privilege level）知道了这两个概念也就知道保护模式的实现原理了，CPU 会在两个关键点上对内存进行保护

1. 
   

   目标段选择子被加载时

   
   


2. 
   

   当通过线性地址（在只有段式内存情况下，线性地址为物理地址）访问一个内存页时。由此可见，保护也反映在内存地址转换的过程之中，既包括分段又包括分页（后文分提到分页）

   
   

CPU 是怎么保护内存的呢，它会对 CPL，RPL，DPL 进行如下检查

只有 CPL <= DPL 且 RPL <= DPL（申请特权等级待以及当前特权等级必须比调用的目标代码段的特权级更高，以防普通程序直接调用目标代码段）时，才会加载目标代码段执行，否则会报一般保护异常 （General-protection exception）

那么特权等级（也就是 CPL）是怎么变化的呢，我们之前说了 CPU 运行于用户空间时，处于用户态，特权等级为 3，运行于内核空间时，处于内核态，特权等级为 0，所以也可以换个问法 CPU 是如何从用户空间切换到内核空间或者从内核空间切换到用户空间的，这就涉及到一个概念：系统调用

系统调用

我们知道用户进程虽然不能执行特权指令，但有时候也需要执行一些读写文件，发送网络包等操作，而这些操作又只能让操作系统来执行，那该怎么办呢，可以让操作系统提供接口，让用户进程来调用即可，我们把这种方式叫做系统调用，系统调用可以直接由应用程序调用，或者通过调用一些公用函数库或 shell（这些函数库或 shell 都封装了系统调用接口）等也可以达到间接调用系统调用的目的。通过系统调用，应用程序实现了陷入（trap）内核态的目的，这样就从用户态切换到了内核态中，如下

那么系统调用又是怎么实现的呢，主要是靠中断实现的，接下来我们就来了解一下什么是中断

中断

陷入内核态的系统调用主要是通过一种 trap gate（陷阱门）来实现的，它其实是软件中断的一种，由 CPU 主动触发给自己一个中断向量号，然后 CPU 根据此中断向量号就可以去中断向量表找到对应的门描述符，门描述符与 GDT 中的段描述符相似，也是 8 个字节，门描述符中包含段选择子，段内偏移，DPL 等字段 ，然后再根据段选择子去 GDT（或者 LDT，下图以 GDT 为例） 中查找对应的段描述符，再找到段基地址，然后根据中断描述符表的段内偏移即可找到中断处理例程的入口点,整个中断处理流程如下

画外音：上图中门描述符和段描述符只画出了关键的几个字段，省略了其它次要字段

当然了，不是随便发一个中断向量都能被执行，只有满足一定条件的中断才允许被普通的应用程序调用，从发出软件中断再到执行中断对应的代码段会做如下的检查

一般应用程序发出软件中断对应的向量号是大家熟悉的 int 0x80（int 代表 interrupt），它的门描述符中的 DPL 为 3,所以能被所有的用户程序调用，而它对应的目标代码段描述符中的 DPL 为 0，所以当通过中断门检查后（即 CPL <= 门描述符中的 DPL 成立），CPU 就会将 CS 寄存器中的 RPL（3） 替换为目标代码段描述符的 DPL（0），替换后的 CPL 也就变成了 0，通过这种方式完成了从用户态到内核态的替换，当中断代码执行后执行 iret 指令又会切换回用户态

另外当执行中断程序时，还需要首先把当前用户进程中对应的堆栈，返回地址等信息，以便切回到用户态时能恢复现场

可以看到 int 80h 这种软件中断的执行又是检查特权级，又是从用户态切换到内核态，又是保存寄存器的值，可谓是非常的耗时，光看一下以下图示就知道像 int 0x80 这样的软件中断开销是有多大了

所以后来又开发出了 SYSENTER/SYSCALL 这样快速系统调用的指令，它们取消了权限检查，也不需要在中断描述表（Interrupt Descriptor Table、IDT）中查找系统调用对应的执行过程，也不需要保存堆栈和返回地址等信息，而是直接进入CPL 0，并将新值加载到与代码和堆栈有关的寄存器当中（cs，eip，ss 和 esp），所以极大地提升了性能

分段内存的优缺点

使用了保护模式后，程序员就可以在代码中使用了段选择子：段偏移量的方式来寻址，这不仅让多进程运行成为了可能，而且也解放了程序员的生产力，我们完全可以认为程序拥有所有的内存空间（虚拟空间），因为段选择子是由操作系统分配的，只要操作系统保证不同进程的段的虚拟空间映射到不同的物理空间上，不要重叠即可，也就是说虽然各个程序的虚拟空间是一样的，但由于它们映射的物理地址是不同且不重叠的，所以是能正常工作的，但是为了方便映射，一般要求在物理空间中分配的段是连续的（这样只要维护映射关系的起始地址和对应的空间大小即可）

但段式内存管理缺点也很明显：内存碎片可能很大，举个例子

如上图示，连续加载了三个程序到内存中，如果把 Chrome 关闭了，此时内存中有两段 128 M的空闲内存，但如果此时要加载一个 192 M 的程序 X 却有心无力了 ，因为段式内存需要划分出一块连续的内存空间，此时你可以选择把占 256 M 的 Python 程序先 swap 到磁盘中，然后紧跟着 512 M 内存的后面划分出 256 M 内存，再给 Python 程序 swap 到这块物理内存中，这样就腾出了连续的 256 M 内存，从而可以加载程序 X 了，但这种频繁地将几十上百兆内存与硬盘进行 swap 显然会对性能造成严重的影响，毕竟谁都知道内存和硬盘的读写速度可是一个天上一个地上，如果一定要交换，能否每次 swap 得能少一点，比如只有几 K，这样就能满足我们的需求，分页内存管理就诞生了

内存分页

1985 年 intel 推出了 32 位处理器 80386，也是首款支持分页内存的 CPU

和分段这样连续分配一整段的空间给程序相比，分页是把整个物理空间切成一段段固定尺寸的大小，当然为了映射，虚拟地址也需要切成一段段固定尺寸的大小，这种固定尺寸的大小我们一般称其为页，在 LInux 中一般每页的大小为 4KB，这样虚拟地址和物理地址就通过页来映射起来了

当然了这种映射关系是需要一个映射表来记录的，这样才能把虚拟地址映射到物理内存中，给定一个虚拟地址，它最终肯定在某个物理页内，所以虚拟地址一般由「页号+页内偏移」组成，而映射表项需要包含物理内存的页号，这样只要将页号对应起来，再加上页内偏移，即可获取最终的物理内存

于是问题来了，映射表（也称页表）该怎么设计呢,我们以 32 位虚拟地址位置来看看，假设页大小为 4K（2^12），那么至少需要 2^20 也就是 100 多万个页表项才能完全覆盖所有的虚拟地址，假设每一个页表项 4 个字节，那就意味着为一个进程的虚拟地址就需要准备 2^20 * 4 B = 4 M 的页表大小，如果有 100 个进程，就意味着光是页表就要占用 400M 的空间了，这显然是非常巨大的开销，那该怎么解决这个页表空间占用巨大的问题呢

我们注意到现在的做法是一次性为进程分配了占用其所有虚拟空间的页表项，但实际上一个进程根本用不到这么巨大的虚拟空间，所以这种分配方式无疑导致很多分配的页表白白浪费了，那该怎么办，答案是分级管理，等真正需要分配物理空间的时候再分配，其实大家可以想想我们熟悉的 windows 是怎么分配的，是不是一开始只分配了 C 盘，D盘，E盘，等要存储的时候，先确定是哪个盘，再在这个盘下分配目录，然后再把文件存到这个目录下，并不会一开始就把所有盘的空间给分配完的

同样的道理，以 32 位虚拟地址为例，我们也可以对页表进行分级管理, 页表项 2^20 = 2^10 * 2^10 = 1024 * 1024，我们把一个页表分成两级页表，第一级页表 1024 项，每一项都指向一个包含有 1024 个页表项的二级页表

这样只有在一级页表中的页表项被分配的时候才会分配二级页表，极大的节省了空间，我们简单算下，假设 4G 的虚拟空间进程只用了 20%（已经很大了，大部分用不到这么多），那么由于一级页表空间为 1024 *4 = 4K，总的页表空间为 4K+ 0.2 * 4M = 0.804M，相比于原来的 4M 是个巨大的提升！

那么对于分页保护模式又是如何起作用的呢，同样以 32 位为例，它的二级页表项（也称 page table entry）其实是以下结构

注意第三位（也就是 2 对应的位置）有个 U/S，它其实就是代表特权级，表示的是用户/超级用户标志。为 1 时，允许所有特权级别的程序访问；为 0 时，仅允许特权级为0、1、2（Linux 中没有 1，2）的程序（也就是内核）访问。页目录中的这个位对其所映射的所有页面起作用

既然分页这么好，那么分段是不是可以去掉了呢，理论上确实可以，但 Intel 的 CPU 严格执行了 backward compatibility（回溯兼容），也就是说最新的 CPU 永远可以运行针对早期 CPU 开发的程序，否则早期的程序就得针对新 CPU 架构重新开发了（早期程序针对的是 CPU 的段式管理进行开发），这无论对用户还是开发者都是不能接受的（别忘了安腾死亡的一大原因就是由于不兼容之前版本的指令），兼容性虽然意味着每款新的 CPU 都得兼容老的指令，所背的历史包袱越来越重，但对程序来说能运行肯定比重新开发好，所以既然早期的 CPU 支持段，那么自从 80386 开始的所有 CPU 也都得支持段，而分页反而是可选的，也就意味着这些 CPU 的内存管理都是段页式管理，逻辑地址要先经过段式管理单元转成线性地址（也称虚拟地址），然后再经过页式管理单元转成物理内存，如下

在 Linux 中，虽然也是段页式内存管理，但它统一把 CS，DS，SS，ES 的段基址设置为了 0，段界限也设置为了整个虚拟内存的长度，所有段都分布在同一个地址空间，这种内存模式也叫平坦内存模型（flat memory model）

我们知道逻辑地址由段选择子：段内偏移地址组成，既然段选择子指向的段基地址为 0，那也就意味着段内偏移地址即为即为线性地址（也就是虚拟地址），由此可知 Linux 中所有程序的代码都使用了虚拟地址，通过这种方式巧妙地绕开了分段管理，分段只起到了访问控制和权限的作用（别忘了各种权限检查依赖 DPL，RPL 等特权字段，特权极转移也依赖于段选择子中的 DPL 来切换的）

总结

看完本文相信大家对实模式，保护模式，特权级转换，分段，分页等概念应该有了比较清晰的认识。

我们简单总结一下，CPU 诞生之间，使用的绝对物理内存来寻址（也就是实模式），随后随着 8086 的诞生，由于工艺的原因，虽然地址总线是 20 位，但寄存器却只有 16 位，一个难题出现了，16 位的寄存器该怎么寻址 20 位的内存地址呢，于是段的概念被提出了，段的出现虽然解决了寻址问题，但本质上 CS << 4 + IP 的寻址方式依然还是绝对物理地址，这样的话由于地址会互相覆盖，显然无法做到多进程运行，于是保护模式被提出了，保护就是为了物理内存免受非法访问，于是用户空间，内核空间，特权级也被提出来了，段寄存器里保存的不再是段基址，而是段选择子，由操作系统分配，用户也无法随意修改段选择子，必须通过中断的形式才能从用户态陷入内核态，中断执行的过程也需要经历特权级的检查，检查通过之后特权级从 3 切换到了 0，于是就可以放心合法的执行特权指令了。可以看到，通过操作系统分配段选择子+中断的方式内存得到了有效保护，但是分段可能造成内存碎片过大以倒频繁 swap 会影响性能的问题，于是分页出现了，保护模式+分页终于可以让多进程，高效调度成为了可能

参考

• CPU 是怎么执行指令的 z.itpub.net/article/det…


• 好家伙！原来硬中断就是这样的:(mp.weixin.qq.com/s/OWrw6VNTN…)


• RPL 的故事 string.quest/read/151526…


• RPL,DPL 区别 stackoverflow.com/questions/3…

计算机网络 传输层

传输层服务

传输层在网络层的基础上，实现了进程到进程的服务。

传输层通过引入端口号来区分进程，在 UDP/TCP 的首部中，一个端口占用 2B, 即 16 bit。

复用与分用

一台主机上的多个进程，利用一个传输层实体，将数据发送出去，这就叫复用。而远端主机的传输层实体，收到了很多数据，然后通过识别端口号，将数据交给具体的进程，这就叫分用（或解复用）。

UDP（无连接传输协议 / 用户数据报协议）

面向报文协议，即一个 UDP 数据报就是应用层交下来一个完整报文。

是一种尽力而为的，非有序的、无连接的一种协议，通常用于流媒体应用、事务性应用，如 DNS 等。

UDP 的报文结构

UDP 会使用校验和对数据做差错控制编码。

将数据按每16位一组相加，最高位相加产生的进位，回卷到最低位去，如此，将最后的和取反码就是最终的校验和，在接收端，按同样的方法求校验和，与接收端的校验和相加，如果结果不是 16 个 1，则肯定出错，如果是 16 个 1 ，说明大概率没有出错。

可靠数据传输的基本原理

可靠的传输通常需要实现数据的不丢失、不乱序、无差错等核心功能。

我所看过的传输层相关的书，都是通过递进式的讲解实现可靠的网络传输，这里也已这种方式来记录。但我这里 rdt1.0、rdt2.0、rdt3.0跟书本上的可能不一致，纯粹是按自己理解的来，我觉得这里能够理解其逐渐完善可靠性的过程就OK了。

rdt1.0 停等协议

先假设传输层以下的实现都是可靠的，不会出现数据差错的情况，**那如何实现不乱序呢？**很简单，我们只要保证按顺序传就可以，发送端先发一个，等接收端收到了再发下一个，如此往复直到数据全部发送完。这样的协议叫做停等协议。

rdt2.1 ACK 和 NAK

这里看上去确实实现了按序到达，但这是建立在底层不会出现差错的情况下，一旦出现了一些异常情况，比如**分组在传输过程中出现了比特反转（0被识别为1，1识别为0）**该如何处理？

那需要接收端给发送端一个答复，接收端是否收到了合法的分组。如果收到了正确的分组，接收端回复一个确定（ACK）,发送端识别到时ACK，就可以继续发送下一个分组，若收到了错误的分组，则回复一个否定（NAK），那接收端就需要重发当前分组。

如图这里主要有两种异常情况：

1. 
   

   分组在传输过程中出错：

   
   

   接收端检测到错误之后，回复 NAK , 发送端收到 NAK 后，需要重传上一个分组。

   
   


2. 
   

   ACK 或 NAK 在传输过程中出错：

   
   

   发送端不能识别这到底是 ACK 还是 NAK，于是就统一按照这是 NAK 来处理，于是就重发上一个分组。而这里重发后，会导致接收端收到重复的分组，接收端需要丢弃这个分组，然后回复 ACK。

   
   

当然，如果过程中没有出错，那就一步一步的正常的将数据发送给接收端就OK了。

rdt2.2 序号

在rdt2.2中，我们开始使用序号，给分组进行编号。并且使用上一个分组的编号来替代 NAK ，什么意思呢？如果用户在收到一个分组 P3 时，发现数据出错了，那这时它就不再回复 NAK 了，而是回复 ACK = P2，表示接收端才收到 P2，于是发送端需要重传 P3，这样实现了跟 NAK 一样的效果。这么做为后面的流水协议奠定了基础。

可以看到，这里用分组的序号替代单纯的 ACK/NAK，异常情况跟 rdt 2.1 非常相似。

rdt3.0 超时重传机制

如果分组在传输过程中丢失了，接收端等待下一个分组，发送端等待 ACK，双方如果都这么默默的等待下去，那不就出现死锁了？

我们可以让发送端发送一个分组后，设置一个超时定时器，如果在一段时间后还没有收到 ACK, 触发超时重传机制，重发上一个分组，这里不论是分组丢失还是 ACK 丢失，都可以重发。如果是 ACK 丢失，接收端会收到重复的分组，跟 rdt2.0 的方案类似，将重复的分组丢弃就可以了，并且对当前的分组发送 ACK 。

由于定时器的设置，不可能百分百的确定分组或 ACK 丢失，可能在超时重传后好一段时间，对前面某个分组的 ACK 慢悠悠的过来了，这是发送端可以什么都不做，无视它就可以了，因为前面已经收到过对这个分组的确认。

超时计时器的时间需要根据RTT的时间来动态设置，如果超时时间设置得过短，会引起不必要的重传，如果设置得过长，会使重传效率变低。

到目前为止，停等协议已经实现了可靠传输，但是它的信道利用率很低。

滑动窗口协议（slide window）

停等协议的信道利用率很低，是因为它一次只发一个分组，确认发送完成后才能发另一个，这中间会有很长的等待时间，如何提高信道利用率呢？显然，我们在发完一个分组后，不等 ACK 就在此下一个，看上去就能提高效率。因此，这种连续发送多个未经确认的分组的协议叫做流水线协议。

在发送端会有一段缓冲区，可以存储已经发送出去但还没有收到 ack 的分组，用于后面检错重发、超时重发等。而在接收端，也有一段缓存区，主要是为了适应发送端发送速率和接收端接收速率不一致的情况，当发送端速度过快时，可以用缓冲区暂存一下。

发送端缓冲区的发送窗口长度叫做 sw , 接收端缓冲区接收窗口长度叫做 rw 。窗口是缓冲区的一个子集。

• 当 sw = 1，rw = 1 时，这就是停等协议


• 当 sw > 1，rw = 1 时，这就是 GBN 协议


• 当 sw > 1，rw > 1时，这就是 SR （selective repeat）协议

通常发送窗口的后沿指针指向低位的首个已发送但没有确认的分组，前沿指针指向高位第一个已发送的分组，如果发送的分组数量比最大发送窗口长度小，那表明发送端可以继续发送分组，也就是前沿指针可以向前移动。如果低位的未确认的分组收到了确认，则后沿指针可以向前移动，移动到首个未确认的分组。这时，发送窗口被使用的长度就变小了，发送端就可以继续发送分组。

而接收端收到的分组在接收窗口范围内时，可以接收并对其作出确认，若没有比它序号更低的分组等待被确认，则接收窗口的后沿指针可以向前移动，移动到首个未确认的分组。由于窗口指针的移动，接收端又有了更多的空间来接收后续的分组。如果接收的分组超出接收窗口范围，则将其丢弃，因为接收窗口暂时没有足够空间去保存更多的分组。

GBN

GBN 协议特点：rw = 1, 顺序接收，累积确认。

双方正常的流程：发送方可以按序发送多个分组，这些分组有序的到达接收端，接收端对其一一作出确认，接收端每接收一个分组，窗口就向前移动一位，然后接收到下一个分组，再对下一个分组进行确认，然后再往前移动。

双方的异常流程：

1. 如果接收端收到乱序的分组，比如在等待 P1 的过程中，结果收到一个 P2,那接收端会将其丢弃，并发送其上一个分组，也就是 P0 的确认。发送端收到 P0 的 ACK 后，就会将 P0 之后的所有的分组重发一遍，这也就是 go back N 的意义。总结起来就是，如果低位的分组出错（失序或超时）了，需要从低位开始重传后续所有的分组。

SR

SR 协议特点：rw > 1, 可以乱序接收非累积确认，或者叫单独确认，收到哪个分组，就给哪个确认。窗口向前滑动时，滑到从低位开始第一个未确认的分组

双方的正常流程：发送方依次发送多个分组，每个分组要设置一个独立的超时计时器，由于 SR 的接收窗口长度大于 1，因此只要是在窗口范围内的分组，它都可以接收，并单独对其作出确认。发送方收到确认后，取消超时计时器，如果没有比当前更小的需要被确认的分组，那后沿指针就向前移动，发送端继续发送后续的分组。

双方的异常情况：

1. 
   

   发送方的某个分组丢失了，那接收方就无法对其作出确认，接收窗口的后沿指针无法向前移动，一段时间后，发送端的这个分组的超时计时器会触发重传，然后重新设置超时计时器。接收方收到这个分组后，对其作出确认，然后接收窗口的前沿指针得以向前移动，从而可以接收更多的分组。而发送方收到确认后，发送窗口的后沿指针也会向前移动，发送端就可以发送后续的分组。

   
   


2. 
   

   接收端的某个分组的ACK 丢失了，这里发送端对应的分组超时计时器会进行重发，重发后接收端收到了重复的分组，而接收端发现这个分组已经被确认过，直接将其忽略即可。如果接收端的某个分组的 ACK 是因为网络拥塞导致超时之后才到达发送端，那发送端发现自己已经重发了这个分组，正在等待确认中，那发送端直接忽略这个ACK就可以了，同理，如果某个分组已经通过超时重传后被确认了，而首次发送的 ACK 才缓缓到达，发送端同样可以忽略这次的确认，因为这个分组已经被确认过了。

   
   

GBN & SR 的差别

GBN 使用起来简单，适合在低差错率的网络中使用，使用累积确认（比如，对某个分组进行确认，则表明这个分组及以前所有的分组，都被正确接收了，而之后的分组没有被收到），一旦出错，需要重发之后所有已经发送过的分组，会有比较大的代价。

SR 实现起来复杂些，因为每个分组都有单独的超时计时器，只需要对出现差错的分组单独重传，适合在差错率较高的网络中使用。使用非累积确认。

TCP（面向连接传输协议）

在可靠传输原理中，我们为了方便，是给分组设置了编号，但实际在 TCP 中是对字节流进行编号。

由于我们到了具体的 TCP 协议，通常需要将分组描述为报文段。

TCP 采用了前面可靠传输原理中的流水线协议、累积确认、单超时计时器等特点，是 SR 和 GBN 的混合，同时还支持流量控制，拥塞控制。

段结构

TCP 在载荷部分前，会加上自己的控制信息，也就是 TCP 的首部。如果不包含选项部分，首部的长度为 20个字节。

介绍几个主要的字段。

序号：由发送端设置，表示发送端发送报文段的首字节编号。

确认号：由接收端设置，当 ACK = 1时，确认号才有效，表示接收端期望收到字节编号。同时，在累积确认中表示这个编号之前的分组已经收到。

SYN：表示要建立连接。

FIN：表示要拆除连接。

可靠数据传输

TCP 的可靠传输原理大致可以理解为是 SR + 累积确认 + 快速重传。TCP 的发送端不会为每个发出去的报文段设置超时计时器，而是在发送窗口滑动到首个未确认的报文段时启动一个超时计时器。

TCP 对于乱序到达的分组，没有规定该存储还是丢弃，可以自由实现。

快速重传

低位的分组，在超时计时器触发超时之前，如果收到了连续 3 次重复的对当前报文段的确认，可以认为当前报文段已经出现了差错，发送端就可以提前重发这个报文段，而不用等到超时计时器生效。

TCP 的实际实现中，在收到某个分组后，会短暂的等待一会，等收到下一个分组后，再发送确认，这样就可以只发送 1 次确认，这也是利用了累积确认的优点。当然，它不能等待太久，并且等待的分组只能有 1 个，如果下一个分组到来，立刻发送确认。

流量控制

流量控制时为了解决发送端的发送速率和接收端的读取数据不一致的问题，通常是发送端发送的太快，超出了接收端的缓冲区，超出的这些报文段就会被丢弃，那发送端发这么多也就没有了意义。

接收方在发送确认时，可以将自己可用的缓冲区大小放在 TCP 首部的接收窗口字段中，发送端收到这个 ACK 后，就知道是否还能够继续发送数据，可以根据接收端的窗口，调节自己的窗口大小。

连接管理

TCP 是面向连接的，在正式传送数据前，需要做一些准备工作，如：协商起始序号，设置发送窗口、接收窗口等。

连接建立被称为“三次握手”，TCP 的连接建立过程如下：

连接建立前，客户端处于连接关闭状态，服务端处于监听状态。

1. 客户端发送连接建立请求，SYN=1，同时设置一个随机的初始字节序号x，即 seq=x。


2. 服务端收到了连接建立请求，设置 ACK=1，表示同意建立请求，同时设置请求号 ack=x+1，TCP 规定 SYN 报文段不能携带数据，但需要消耗 1 个序号，因此这里的 ack=x+1。这部分操作表示服务端同意建立请求。同时，第二次握手还有服务端作为发送方希望与客户端建立连接的请求，所以，这里有跟第一次握手相似的数据，SYN=1, seq=y，y 是服务端随机生成的序号。


3. 客户端收到了服务端发来的 ack，那客户端作为发送方与服务端的连接就已经建立，这时客户端就已经可以向服务端发送数据了。同时也收到了服务端发来的连接建立请求，因而这次客户端需要回复 ACK=1，ack=y+1, 表示同意建立请求，然后这次不论是否传送数据 seq都是 x+1。

经过上面三次握手，客户端与服务端的双向的连接就建立起来了。

当双方通信完毕后，TCP 需要拆除连接。连接拆除的过程通常叫做“四次挥手”，过程如下：

1. 客户端发送 FIN=1,表示希望拆除连接。


2. 服务端收到后发送 ACK=1。（客户端收到ACK后，客户端到服务端的连接就拆除了，但服务端到客户端的连接仍然可用，服务端仍然可以向客户端发送数据）


3. 服务端发送 FIN=1，表示希望拆除连接。


4. 客户端收到后发送 ACK=1。服务端收到后确认后，连接即拆除。但站在客户端的角度，作为最后一个发送消息的角色，它还不知道自己发送的确认有没有准确的到达服务器，所以在发送完 ACK 后，会等待一段时间，如果服务端没有重传FIN，那客户端作为接收方到服务端的接收连接也就断开了，那到目前为止，所有的连接就都拆除了。

上面第四步客户端会有一个等待时间来防止 ack 出现差错，但这个方案也不是完美的，如果服务端发现这个ack 有差错，重发了一个连接拆除的请求，但这个请求慢悠悠过了好一会才到达客户端（时间大于客户端的等待时间），可是客户端已经关闭了连接，那服务端短时间内就没法收到拆除连接的 ack 了。

因此，作为拆除连接的最后一环，第四次挥手无论怎样都不会完美，只能尽可能的降低出现问题的概率。

为什么要设置 SequenceNum？

防止滞留在网络中的上一次连接中的一些段，被识别位本次连接中的段。SequenceNum 的长度是 32 位，可以编址 4G 的字节，这么大的范围在两次连接中很难出现相近的序号段，一旦序号段差别很大，这个“野“报文段也就很难出现接收窗口中，就会被接收方丢弃。

为什么2次握手不行？

1. TCP 是全双工的连接，建立连接时，既要有客户端到服务端的连接，也要有服务端到客户端的连接。建立一个方向的连接需要 2 次握手，两个方向就是 4 次，但是在服务端向客户端确认连接时，可以捎带上服务端对客户端的连接建立请求，这样就合并了一次握手，所以有三次。


2. 如果只有 2 次握手，且服务端的确认出现差错的情况下，客户端就收不到建立连接的确认，这个方向的连接就会失败。而服务端不知道自己的连接确认丢失了，导致服务端到客户端的连接建立了，这样就出现了“半连接”的情况。如果服务端有大量的这种“半连接”，会极大的消耗服务端的性能。如果上一个连接滞留在网络中的报文段到达了接收方，还有可能阴差阳错的被服务端接收。

TCP的拥塞控制

拥塞时指过多的分组被注入到网络中，超出了网络的处理能力，导致大量的分组 ”拥挤“ 在网络中间设备队列中等待转发，网络性能显著下降的现象。

拥塞的直接后果：

1. 数据分组通过网络的延时显著增加；


2. 由于中间网络设备的队列满导致大量的分组被丢弃。

拥塞控制就是通过合理调度、规范、调整向网络中发送数据的主机数量、发送速率或数据量，以避免拥塞或尽快消除已发生的拥塞。拥塞控制可以在不同层实现，比较典型的是在网络层和传输层进行拥塞控制。

拥塞控制的基本思想是 AIMD。拥塞窗口的调整主要分为慢启动阶段和拥塞避免阶段。在慢启动阶段，每收到 1 个确认段，拥塞窗口增加 1 个 MSS，每经过 1 个 RTT，拥塞窗口增长 1 倍；在拥塞避免阶段，每经过 1 个 RTT，拥塞窗口才增长 1 个 MSS。

如何检测网络中是否发生了拥塞？

1. 分组发生了超时


2. 连续收到了多个对同一分组的重复确认。

1. 什么是 context？

作为安卓开发工程师，Context是我们经常使用的一个重要概念。

从代码的角度来看，Context是一个抽象类，它代表着应用程序环境和运行时状态的信息。Context具有许多子类，包括Activity和Service等，每个子类都代表着不同的应用程序环境和状态。

从设计的角度来看，Context是一个非常重要的概念，因为它允许我们在应用程序中访问系统资源，例如数据库，共享偏好设置和系统服务等。Context还允许我们在应用程序中创建新的组件，例如Activity和Service等。

实际上，Context在安卓开发中几乎无处不在。例如，我们可以使用Context来启动一个新的Activity，获取应用程序的资源，读取和写入文件，以及访问系统服务和传感器等。Context还可以帮助我们管理应用程序的生命周期，例如在应用程序销毁时释放资源。

总之，Context是安卓开发中不可或缺的概念，它允许我们访问系统资源，管理应用程序的生命周期，并与系统交互。理解Context的概念和使用方法对于成为一名优秀的安卓开发工程师至关重要。

2. context继承关系

Context

├── ContextImpl

├── ContextWrapper

│   ├── Application

│   ├── Service

│   ├── ContextThemeWrapper

│   │   ├── Activity

│   │   │   ├── FragmentActivity

│   │   │   └── ...

│   │   └── ...

│   └── ...

└── ...

Context是一个抽象类，它有多个直接或间接的子类。

ContextImpl是Context的一个实现类，真正实现了Context中的所有函数，所调用的各种Context类的方法，其实现均来自于该类。

ContextWrapper是一个包装类，它可以包装另一个Context对象，并在其基础上添加新的功能。内部包含一个真正的Context引用，调用ContextWrapper的方法都会被转向其所包含的真正的Context对象。

ContextThemeWrapper是一个特殊的包装类，它可以为应用程序的UI组件添加主题样式。主题就是指Activity元素指定的主题。只有Activity需要主题，所以Activity继承自ContextThemeWrapper，而Application和Service直接继承自ContextWrapper。

总之，Context的继承关系非常复杂，但是理解这些关系对于在安卓开发中正确地使用Context非常重要。通过继承关系，我们可以了解每个Context子类的作用和用途，并且可以选择合适的Context对象来访问应用程序的资源和系统服务。

3.Context如何创建

在安卓应用程序中，Activity是通过调用startActivity()方法来启动的。当我们启动一个Activity时，系统会通过调用Activity的生命周期方法来创建、启动和销毁Activity对象。
而其中创建Activity的方法最终是走到ActivityThread.performLaunchActivity()方法。将其中无关方法删除后：
、、、
private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
...
//创建 ContextImpl对象
ContextImpl appContext = createBaseContextForActivity(r);
Activity activity = null;

    //创建Activity对象

    activity = mInstrumentation.newActivity(

            cl, component.getClassName(), r.intent);

    ...

    //Activity初始化

    activity.attach(appContext, this, getInstrumentation(), r.token,

            r.ident, app, r.intent, r.activityInfo, title, r.parent,

            r.embeddedID, r.lastNonConfigurationInstances, config,

            r.referrer, r.voiceInteractor, window, r.configCallback,

            r.assistToken, r.shareableActivityToken);

    //Theme设置

    int theme = r.activityInfo.getThemeResource();

    if (theme != 0) {

        activity.setTheme(theme);

    }

    

    return activity;

}

、、、
可以看到Activity的创建过程十分清楚：

1. 创建ContextImpl对象，方法最终走到静态方法ContextImpl.createActivityContext()创建。


2. 创建Activity对象，最终instantiateActivity()通过调用Class的newInstance()方法，反射创建出来，方法注解到This method is only intended to provide a hook for instantiation. It does not provide earlier access to the Activity object. The returned object will not be initialized as a Context yet and should not be used to interact with other android APIs.，方法只创建了Activity的早期对象，并没有对它做Context的初始化，所以不能调用安卓相关api。简单来说，Activity本身继承自ContextWrapper，这个方法并没有具体实现任何Context的方法，只是将所有方法代理给了内部的baseContext，所以反射创建后，调用任何的系统的方法都是无效的。


3. Activity初始化，调用Activity.attch()，这个方法对Activity做各种所需的初始化，Context、Thread、parent、Window、Token等等，而Context的初始化就是调用ContextWrapper.attachBaseContext()把第一步创建的ContextImpl设置到baseContext。


4. Theme设置，前面说到Activity实现的是ContextThemeWrapper，对ContextWrapper扩展并支持了Theme的替换，调用ContextThemeWrapper.setTheme()完成Theme的初始化。

4.一些思考

1. 
   

   ContextThemeWrapper作为ContextWrapper一个扩展，它是重写了ContextImpl中的一些关于Theme的实现，也就是说ContextImpl本身也是有Theme的实现，它提供的Theme是整个APP的Theme，而这里扩展了之后，支持了Theme的替换之后，在不同的页面支持了不同的Theme设置。

   
   


2. 
   

   Context作为应用程序环境和运行时状态的信息，设计初衷上它应该是固定的，在创建成功之后就禁止改变，所以在ContextWrapper.attachBaseContext()中设置了拦截，只允许设置一次baseContext，重新设置会抛出异常。但是在一些特殊的场景中，比如跨页面使用View，或者提前创建View的时候，其实会有场景涉及替换Context。另一个坑是ContextWrapper限制baseContext只允许系统调用。不过在SDK31中，官方提供了一个特殊版本的ContextWrapper，也就是MutableContextWrapper，支持了替换baseContext。

   
   


3. 
   

   Context设计是很典型的装饰器模式，Context抽象定义了具体的接口；ContextImpl具体实现了Context定义的所有方法；ContextWrapper继承了Context接口，并包装了具体实现ContextImpl;ContextThemeWrapper继承了ContextWrapper并扩展了替换Theme的功能。

   
   

5. 附录

装饰器模式是一种结构型设计模式，它允许我们在运行时动态地为一个对象添加新的行为，而无需修改其源代码。装饰器模式通过将对象包装在一个装饰器对象中，来增加对象的功能。装饰器模式是一种非常灵活的模式，它可以在不改变原始对象的情况下，动态地添加新的行为和功能。

装饰器模式的核心思想是将对象包装在一个或多个装饰器对象中，这些装饰器对象具有与原始对象相同的接口，可以在不改变原始对象的情况下，为其添加新的行为。装饰器对象可以嵌套在一起，形成一个链式结构，从而实现更复杂的功能。

装饰器模式的结构由四个基本元素组成：

1. 
   

   抽象组件（Component）：定义了一个对象的基本接口，可以是一个抽象类或接口。

   
   


2. 
   

   具体组件（ConcreteComponent）：实现了抽象组件接口，是被装饰的对象。

   
   


3. 
   

   抽象装饰器（Decorator）：继承或实现了抽象组件接口，用于包装具体组件或其他装饰器。

   
   


4. 
   

   具体装饰器（ConcreteDecorator）：继承或实现了抽象装饰器接口，实现了具体的装饰逻辑。

   
   

装饰器模式的优点在于：

1. 
   

   可以动态地为对象添加新的行为，无需修改其源代码。

   
   


2. 
   

   可以嵌套多个装饰器对象，形成一个链式结构，从而实现更复杂的功能。

   
   


3. 
   

   装饰器对象与原始对象具有相同的接口，可以完全替代原始对象。

   
   

装饰器模式的缺点在于：

1. 
   

   可能会导致类的数量增加，增加代码的复杂度。

   
   


2. 
   

   在装饰器链中，有些装饰器可能不被使用，但仍然需要创建和维护，浪费资源。

书客编辑器是一款基于Markdown标记语言的开源的富文本编辑器，它以简易的操作界面和强大的功能深受广大开发者的喜爱。正如官方所说：现在的版本不一定是最好的版本，却是最好的开源版本。官方地址：editor.ibooker.cc。

下面针对书客编辑器安卓Java版，进行详解说明。

效果图

在进行讲解之前，首先看一下书客编辑器安卓版的效果图：

一、引入资源

引入书客编辑器安卓Java版的方式有很多，这里主要提供两种方式：

1、在build.gradle文件中添加以下代码：

allprojects {

	repositories {

		maven { url 'https://jitpack.io' }

	}

}

dependencies {

	compile 'com.github.zrunker:IbookerEditorAndroid:v1.0.1'

}

2、在maven文件中添加以下代码：

<repositories>

	<repository>

		<id>jitpack.io</id>

		<url>https://jitpack.io</url>

	</repository>

</repositories>

<dependency>

	<groupId>com.github.zrunker</groupId>

	<artifactId>IbookerEditorAndroid</artifactId>

	<version>v1.0.1</version>

</dependency>

二、使用

书客编辑器安卓版简易所在就是只需要简单引入资源之后，可以直接进行使用。因为书客编辑器安卓版不仅仅提供了功能实现，还提供了界面。所以使用过程中，连界面绘制都不用了。

界面分析

书客编辑器安卓版界面大致分为三个部分，即编辑器顶部，内容区（编辑区+预览区）和底部（工具栏）。

首先在布局文件中引入书客编辑器安卓版控件，如布局文件为activity_main.xml，只需要在该文件内添加以下代码即可：

<?xml version="1.0" encoding="utf-8"?>

<cc.ibooker.ibookereditorlib.IbookerEditorView

    xmlns:android="http://schemas.android.com/apk/res/android"

    android:id="@+id/ibookereditorview"

    android:layout_width="match_parent"

    android:layout_height="match_parent" />

实际上IbookerEditorView继承LinearLayout，所以它具备LinearLayout的一切功能。

三、功能介绍

根据轮廓图可以看出，书客编辑器安卓版布局只有三个部分，所以关于书客编辑器安卓版功能模块也就分三个部分对外提供使用，即修改哪一个布局模块就是对于哪一个功能模块。

顶部功能模块

书客编辑器安卓版顶部实际上是采用IbookerEditorTopView控件进行呈现，所以要实现顶部相关控件功能首先要获取该控件。

书客编辑器安卓版顶部界面图，从左到右分别对应返回（back），撤销（undo），重做（redo），编辑模式（edit），预览模式（preview），帮助（help），关于（about）。知道每个按钮对应的功能，所以就可以去修改或完善相关实现过程。

例如修改返回按钮一些属性，可以使用一下代码：

// 设置书客编辑器顶部布局相关属性

ibookerEditorView.getIbookerEditorTopView()

        .setBackImgVisibility(View.VISIBLE)

        .setBackImageResource(R.mipmap.ic_launcher);

当然也可以通过IbookerEditorTopView获取相关控件，然后针对该控件进行逐一处理：

ibookerEditorView.getIbookerEditorTopView()

        .getBackImg()

        .setVisibility(View.VISIBLE);

这里只是使用返回按钮进行举例说，其他按钮使用规则更返回按钮一样。

中间功能模块

书客编辑器安卓版中间区域又分为两个部分，分别是编辑部分和预览部分，所以要修改相关功能就要获取到相关部分的控件。其中编辑部分由IbookerEditorEditView控件进行呈现，预览部分由IbookerEditorPreView控件进行呈现。

例如修改编辑部分相关属性，可以使用如下代码：

// 设置书客编辑器中间布局相关属性

ibookerEditorView.getIbookerEditorVpView().getEditView()

        .setIbookerEdHint("书客编辑器")

        .setIbookerBackgroundColor(Color.parseColor("#DDDDDD"));

编辑部分并不是只有一个控件，所以也可以获取相关控件，然后针对特定控件进行逐一操作：

ibookerEditorView.getIbookerEditorVpView()

        .getEditView()

        .getIbookerEd()

        .setText("书客编辑器");

// 执行预览功能

ibookerEditorView.getIbookerEditorVpView()

        .getPreView()

        .ibookerHtmlCompile("预览内容");

底部功能模块

书客编辑器安卓版，底部为工具栏，由IbookerEditorToolView进行呈现。

工具栏一共提供了30多种功能，每一个按钮对应一个功能。各个控件分别为：

boldIBtn, italicIBtn, strikeoutIBtn, underlineIBtn, capitalsIBtn, 

uppercaseIBtn, lowercaseIBtn, h1IBtn, h2IBtn, 

h3IBtn, h4IBtn, h5IBtn, h6IBtn, linkIBtn, quoteIBtn, 

codeIBtn, imguIBtn, olIBtn, ulIBtn, unselectedIBtn, 

selectedIBtn, tableIBtn, htmlIBtn, hrIBtn, emojiIBtn;

所以要修改底部相关属性，首先要获取到IbookerEditorToolView控件，然后对该控件进行操作。

// 设置书客编辑器底部布局相关属性

ibookerEditorView.getIbookerEditorToolView()

        .setEmojiIBtnVisibility(View.GONE);

当然底部一共有30多个控件，也可以直接获取到相关控件，然后该控件进行操作，如：

ibookerEditorView.getIbookerEditorToolView().getEmojiIBtn().setVisibility(View.GONE);

补充功能：按钮点击事件监听

这里的按钮点击事件监听主要是针对顶部布局按钮和底部布局按钮。

顶部部分按钮点击事件监听，需要实现IbookerEditorTopView.OnTopClickListener接口，而每个按钮点击通过对应Tag来判断，具体代码如下：

// 顶部按钮点击事件监听

@Override

public void onTopClick(Object tag) {

    if (tag.equals(IMG_BACK)) {// 返回

    } else if (tag.equals(IBTN_UNDO)) {// 撤销

    } else if (tag.equals(IBTN_REDO)) {// 重做

    } else if (tag.equals(IBTN_EDIT)) {// 编辑

    } else if (tag.equals(IBTN_PREVIEW)) {// 预览

    } else if (tag.equals(IBTN_HELP)) {// 帮助

    } else if (tag.equals(IBTN_ABOUT)) {// 关于

    }

}

其中IMG_BACK、IBTN_UNDO等变量是由IbookerEditorEnum枚举类提供。

底部部分按钮点击事件监听，需要实现IbookerEditorToolView.OnToolClickListener接口，而每个按钮点击通过对应Tag来判断，具体代码如下：

// 工具栏按钮点击事件监听

@Override

public void onToolClick(Object tag) {

    if (tag.equals(IBTN_BOLD)) {// 加粗

    } else if (tag.equals(IBTN_ITALIC)) {// 斜体

    } else if (tag.equals(IBTN_STRIKEOUT)) {// 删除线

    } else if (tag.equals(IBTN_UNDERLINE)) {// 下划线

    } else if (tag.equals(IBTN_CAPITALS)) {// 单词首字母大写

    } else if (tag.equals(IBTN_UPPERCASE)) {// 字母转大写

    } else if (tag.equals(IBTN_LOWERCASE)) {// 字母转小写

    } else if (tag.equals(IBTN_H1)) {// 一级标题

    } else if (tag.equals(IBTN_H2)) {// 二级标题

    } else if (tag.equals(IBTN_H3)) {// 三级标题

    } else if (tag.equals(IBTN_H4)) {// 四级标题

    } else if (tag.equals(IBTN_H5)) {// 五级标题

    } else if (tag.equals(IBTN_H6)) {// 六级标题

    } else if (tag.equals(IBTN_LINK)) {// 超链接

    } else if (tag.equals(IBTN_QUOTE)) {// 引用

    } else if (tag.equals(IBTN_CODE)) {// 代码

    } else if (tag.equals(IBTN_IMG_U)) {// 图片

    } else if (tag.equals(IBTN_OL)) {// 数字列表

    } else if (tag.equals(IBTN_UL)) {// 普通列表

    } else if (tag.equals(IBTN_UNSELECTED)) {// 复选框未选中

    } else if (tag.equals(IBTN_SELECTED)) {// 复选框选中

    } else if (tag.equals(IBTN_TABLE)) {// 表格

    } else if (tag.equals(IBTN_HTML)) {// HTML

    } else if (tag.equals(IBTN_HR)) {// 分割线

    }

}

其中IBTN_BOLD、IBTN_ITALIC等变量是由IbookerEditorEnum枚举类提供。

Github地址
阅读原文

本篇文章主要介绍常用到的几个kotlin开发技巧，能够帮助我们减少对业务层代码的修改，以及减少模板代码的编写。

善用@get/@set: JvmName()注解并搭配setter/getter使用

假设当前存在下面三个类代码：

#Opt1

public class Opt1 {



    private String mContent;



    public String getRealContent() {

        return mContent;

    }



    public void setContent(String mContent) {

        this.mContent = mContent;

    }

}

#Opt2

public class Opt2 {



    public void opt2(Opt1 opt1) {

        System.out.println(opt1.getRealContent());

    }

} 

@Opt3

public class Opt3 {



    public void opt3(Opt1 opt1) {

        System.out.println(opt1.getRealContent());

    }

}

这个时候我想将Opt1类重构成kotlin，我们先看下通过AS的命令Convert Java File to Kotlin File自动转换的结果：

可以看到为了兼容Opt2和Opt3的调用，直接把我的属性名给改成了realContent，kotlin会自动生成getRealContent()和setRealContent()方法，这样Opt2和Opt3就不用进行任何调整了，kotlin这样就显得太过于智能了。

这样看起来没啥问题，但是java重构kotlin，直接把属性名给我改了，并隐式生成了属性的set和get方法，对于java而言不使用的方法会报灰提示或者只有当前类使用AS会警告可以声明成private，但是对于kotlin生成的set、get方法是隐式的，容易忽略。

所以大家在使用Convert Java File to Kotlin File命令将java重构kotlin的结果一定不能抱有百分之百的信任，即使它很智能，但还是一定要细细的看下转换后的代码逻辑，可能还有不少的优化空间。

这个地方就得需要我们手动进行修改了，比如不想对外暴露修改这个字段的set方法，调整如下：

class Opt1 {

    var realContent: String? = null

        private set

}

再比如保持原有的字段名mContent，不能被改为realContent，同时又要保证兼容Opt2和Opt3类的调用不能报错，且尽量避免去修改里面的代码，我们就可以做如下调整：

class Opt1 {

    @get: JvmName("getRealContent")

    var mContent: String? = null

        private set

}  

善用默认参数+@JvmOverloads减少模板代码编写

假设当前Opt1有下面的方法：

public String getSqlCmd(String table) {

    return "select * from " + table;

}

且被Opt2和Opt3进行了调用，这个时候如果有另一个类Opt3想要调用这个函数并只想从数据库查询指定字段，如果用java实现有两种方式：

1. 直接在getSqlCmd()方法中添加一个查询字段参数，如果传入的值为null，就查询所有的字段，否则就查询指定字段：

public String getSqlCmd(String table, String name) {

    if (TextUtils.isEmpty(name)) {

        return "select * from " + table;

    }

    return "select " + name + " from " + table;

}

这样一来，是不是原本Opt2和Opt3对getSqlCmd()方法调用是不是需要改动，多传一个参数给方法，而在日常的项目开发中，有可能这个getSqlCmd()被几十个地方调用，难道你一个个的改过去？不太现实且是一种非常糟糕的实现。

2. 直接在Opt1中新增一个getSqlCmd()的重载方法，传入指定的字段去查询：

public String getSqlCmd(String table，String name) {

    return "select " + name + " from " + table;

}

这样做的好处就是不用调整Opt2和Opt3对getSqlCmd(String table)方法调用逻辑，但是会编写很多模板代码，尤其是getSqlCmd()这个方法体可能七八十行的情况下。

如果Opt1类代码减少即200-400行且不负责的情况下，我们可以将其重构成kotlin，借助于默认参数来实现方法功能增加又不用编写模板代码的效果（如果你的Java类上千行又很复杂，请谨慎转换成kotlin使用下面这种方式）。

@JvmOverloads

fun getSqlCmd(table: String, name: String? = null): String {

    return "select ${if (name.isNullOrEmpty()) "*" else name} from $table"

}

添加默认参数name时还要添加@JvmOverloads注解，这样是为了保证java只传一个table参数也能正常调用。

通过上面这种方式，我们就能保证实现了方法功能增加，又不用改动Opt2、Opt3对于getSqlCmd()方法的调用逻辑，并且还不用编写额外的模板代码，一举多得。

总结

本篇文章主要介绍了在java重构成kotlin过程中比较常用到的两个技巧，最终实现效果是减少对业务逻辑代码的入侵，希望能对你有所帮助。

一. 渲染基本概念

对于渲染来说在开始前我们先了解几个概念：

CPU主要负责包括 Measure，Layout，Record，Execute 的计算操作。

GPU主要负责 Rasterization（栅格化）操作。栅格化是指将向量图形格式表示的图像转换成位图（像素）以用于显示设备输出的过程，简单来说就是将我们要显示的视图，转换成用像素来表示的格式。

帧率代表了GPU在一秒内绘制操作的帧数。

刷新率代表了屏幕在一秒内刷新屏幕的次数，Android手机一般为60HZ。

二. Android黄油计划

涉及到滑动流畅，Android在谷歌4.1版本引入了黄油计划。其中有三个重要的核心元素：VSYNC、缓存区和Choreographer:

2.1 VSYNC信号

在Android4.0的时候，CPU可能会因为在忙其他的事情，导致没来得及处理UI绘制。为了解决这个问题，设计成系统在收到VSYN信号后，才会开始下一帧的渲染。也就是收到VSYN通知，CPU和GPU才开始计算然后把数据写入buffer中。

VSYN信号是由屏幕产生的，并且以60fps的固定频率发送给Android系统，在Android系统中的SurfaceFlinger接收发送的Vsync信号。当屏幕从缓存区扫描完一帧到屏幕上之后，开始扫描下一帧之前，发出的一个同步信号，该信号用来切换前缓冲区和后缓冲区。

在引入了Vsyn信号之后，绘制就变成了：

可以看到渲染的时候从第0帧开始，CPU开始准备第一帧的图形处理，好了才交给GPU进行处理，再上一帧到来之后，CPU就会开始第二帧的处理，基本上跟Vsync的信号保持同步。

有了Vsync机制，可以让CPU/GPU有完整的16ms时间来处理数据，减少了jank。

2.2 三重缓存

在采用双缓冲机制的时候，也意味着有两个缓存区，分别是让绘制和显示器拥有各自的buffer，GPU使用Back Buffer进行一帧图像数据写入，显示器则是用Frame Buffer，一般来说CPU和GPU处理数据的速度视乎都能在16ms内完成，而且还有时间空余。但是一旦界面比较复杂的情况，CPU/GPU的处理时间超过了16ms，双缓冲开始失效了：

在第二个时间段内，因为GPU还是处理B帧，数据没有及时交换，导致继续系那是之前A缓存区中的内容。

在B帧完成之后，又因为缺少了Vusnc信号，只能等待一段时间。

直到下一个Vsync信号出现的时候，CPU/GPU才开始马上执行，由于执行时间仍然超过了16ms，导致下一次应该执行的缓存区交换又被推迟了，反复这种情形，就会出越来越多的jank。

为了解决这个问题，Android 4.1才引入了三缓冲机制：在双缓冲机制的基础上增加了一个Graohic Buffer缓冲区，这样就可以最大限度的利用空闲的时间。

可以看到在第二个时间段里有了区别，在第一次Vsync发生之后，CPU不用再等待了，它会使用第三个bufferC来进行下一帧的准备工作。整个过程就开始的时候卡顿了一下，后面还是很流畅的。但是GPU需要跨越两个Vsync信号才能显示，这样就还是会有一个延迟的现象。

总的来说三缓冲有效利用了等待vysnc的时间,减少了jank，但是带来了lag。

2.3 Choreographer

在了解了Vsync机制后，上层又是如何接受这个Vsync信号的？

Google为上层设计了一个Choreographer类，翻译成中文是“编舞者”，是希望通过它来控制上层的绘制（舞蹈）节奏。

可以直接从其构造函数开始看起：

private Choreographer(Looper looper, int vsyncSource) {

  //创建Looper对象

        mLooper = looper;

  //接受处理消息

        mHandler = new FrameHandler(looper);

  //用来接受垂直同步脉冲，也就是Vsync信号

        mDisplayEventReceiver = USE_VSYNC

                ? new FrameDisplayEventReceiver(looper, vsyncSource)

                : null;

        mLastFrameTimeNanos = Long.MIN_VALUE;

//计算下一帧的时间，Androoid手机屏幕是60Hz的刷新频率

        mFrameIntervalNanos = (long)(1000000000 / getRefreshRate());

//初始化CallbackQueue，将在下一帧开始渲染时回调

        mCallbackQueues = new CallbackQueue[CALLBACK_LAST + 1];

        for (int i = 0; i <= CALLBACK_LAST; i++) {

            mCallbackQueues[i] = new CallbackQueue();

        }

        // b/68769804: For low FPS experiments.

        setFPSDivisor(SystemProperties.getInt(ThreadedRenderer.DEBUG_FPS_DIVISOR, 1));

    }

主要来看下FrameHandler和FrameDisplayEventReceiver的数据结构：

private final class FrameHandler extends Handler {

        public FrameHandler(Looper looper) {

            super(looper);

        }



        @Override

        public void handleMessage(Message msg) {

            switch (msg.what) {

                //开始渲染下一帧的操作

                case MSG_DO_FRAME:

                    doFrame(System.nanoTime(), 0);

                    break;

                //请求Vsync信号

                case MSG_DO_SCHEDULE_VSYNC:

                    doScheduleVsync();

                    break;

                //请求执行Callback

                case MSG_DO_SCHEDULE_CALLBACK:

                    doScheduleCallback(msg.arg1);

                    break;

            }

        }

    }

在FrameHandler可以看到对三种消息进行了处理，对其具体实现一会分析。

private final class FrameDisplayEventReceiver extends DisplayEventReceiver

            implements Runnable {

        private boolean mHavePendingVsync;

        private long mTimestampNanos;

        private int mFrame;



        public FrameDisplayEventReceiver(Looper looper, int vsyncSource) {

            super(looper, vsyncSource, CONFIG_CHANGED_EVENT_SUPPRESS);

        }

  

        @Override

        public void onVsync(long timestampNanos, long physicalDisplayId, int frame) {

            

            ......

            mTimestampNanos = timestampNanos;

            mFrame = frame;

          //将本身作为runnable传入msg， 发消息后 会走run()，即doFrame()，也是异步消息

            Message msg = Message.obtain(mHandler, this);

            msg.setAsynchronous(true);

            mHandler.sendMessageAtTime(msg, timestampNanos / TimeUtils.NANOS_PER_MS);

        }



        @Override

        public void run() {

            mHavePendingVsync = false;

            doFrame(mTimestampNanos, mFrame);

        }

    }

可以看出来这个类主要是用来接收底层的VSync信号开始处理UI过程。而Vsync信号是由SurfaceFlinger实现并定时发送，接收到之后就会调用onVsync方法，在里面进行处理消息发送到主线程处理，另外在run()方法里面执行了doFrame()，这也是接下来要关注的重点方法。

2.3.1 Choreographer执行过程

ViewRootImpl 中调用 Choreographer 的 postCallback 方法请求 Vsync 并传递一个任务（事件类型是 Choreographer.CALLBACK_TRAVERSAL）

最开始执行的是postCallBack发起回调，这个FrameCallback将会在下一帧渲染时执行。而其内部又调用了postCallbackDelayed方法，在其中又调用了postCallbackDelayedInternal方法：

private void postCallbackDelayedInternal(int callbackType,

            Object action, Object token, long delayMillis) {

        ......

        synchronized (mLock) {

            final long now = SystemClock.uptimeMillis();

            final long dueTime = now + delayMillis;

            mCallbackQueues[callbackType].addCallbackLocked(dueTime, action, token);



            if (dueTime <= now) {

                scheduleFrameLocked(now);

            } else {

                Message msg = mHandler.obtainMessage(MSG_DO_SCHEDULE_CALLBACK, action);

                msg.arg1 = callbackType;

                msg.setAsynchronous(true);

                mHandler.sendMessageAtTime(msg, dueTime);

            }

        }

    }

在这里执行了时间的计算，如果立即就会调用scheduleFrameLocked方法，不然就会延迟发送一个MSG_DO_SCHEDULE_CALLBACK消息，并且在这里使用msg.setAsynchronous(true)讲消息设置成异步。、

而所对应的mHandle也就是之前的FrameHandler，根据消息类型MSG_DO_SCHEDULE_CALLBACK,最终会调用到doScheduleCallback方法：

void doScheduleCallback(int callbackType) {

        synchronized (mLock) {

            if (!mFrameScheduled) {

                final long now = SystemClock.uptimeMillis();

                if (mCallbackQueues[callbackType].hasDueCallbacksLocked(now)) {

                    scheduleFrameLocked(now);

                }

            }

        }

    }

到了这一步看到还是会调用到scheduleFrameLocked方法。

private void scheduleFrameLocked(long now) {

        if (!mFrameScheduled) {

            mFrameScheduled = true;

            if (USE_VSYNC) {

              //开启了Vsync

                if (DEBUG_FRAMES) {

                    Log.d(TAG, "Scheduling next frame on vsync.");

                }



                

                if (isRunningOnLooperThreadLocked()) {

                  //申请Vsync信号

                    scheduleVsyncLocked();

                } else {

                  //最终还是会调用到scheduleVsyncLocked方法

                    Message msg = mHandler.obtainMessage(MSG_DO_SCHEDULE_VSYNC);

                    msg.setAsynchronous(true);

                    mHandler.sendMessageAtFrontOfQueue(msg);

                }

            } else {

              //如果没有直接使用Vsync的话，则直接通过该消息执行doFrame

                final long nextFrameTime = Math.max(

                        mLastFrameTimeNanos / TimeUtils.NANOS_PER_MS + sFrameDelay, now);

                if (DEBUG_FRAMES) {

                    Log.d(TAG, "Scheduling next frame in " + (nextFrameTime - now) + " ms.");

                }

                Message msg = mHandler.obtainMessage(MSG_DO_FRAME);

                msg.setAsynchronous(true);

                mHandler.sendMessageAtTime(msg, nextFrameTime);

            }

        }

    }

在这里对是否使用Vsync信号进行处理，如果没有使用则直接通过消息执行doFrame。如果使用的就会先判断是否在当前Looper线程中运行，如果在的话就会请求Vsync信号,否则发送消息到 FrameHandler。直接来看下scheduleVsyncLocked方法：

 private void scheduleVsyncLocked() {

        mDisplayEventReceiver.scheduleVsync();

    }

可以看到调用了FrameDisplayEventReceiver的scheduleVsync方法，通过查找在其父类DisplayEventReceiver中找到了scheduleVsync方法:

public void scheduleVsync() {

        if (mReceiverPtr == 0) {

            Log.w(TAG, "Attempted to schedule a vertical sync pulse but the display event "

                    + "receiver has already been disposed.");

        } else {

          //申请VSYNC信号，会回调onVsunc方法

            nativeScheduleVsync(mReceiverPtr);

        }

    }

scheduleVsync()就是使用native方法nativeScheduleVsync()去申请VSYNC信号。等下一次信号接收后会调用dispatchVsync 方法:

private void dispatchVsync(long timestampNanos, long physicalDisplayId, int frame) {

        onVsync(timestampNanos, physicalDisplayId, frame);

    }

这个onVsync方法最终实现也就是在FrameDisplayEventReceiver里。可以知道最终还是走到了doFrame方法里。

void doFrame(long frameTimeNanos, int frame) {

        final long startNanos;

        synchronized (mLock) {

            if (!mFrameScheduled) {

                return; // no work to do

            }

           ......

					//设置当前frame的Vsync信号到来时间     

            long intendedFrameTimeNanos = frameTimeNanos;

            startNanos = System.nanoTime();

            final long jitterNanos = startNanos - frameTimeNanos;

            if (jitterNanos >= mFrameIntervalNanos) {

              //时间差大于一个时钟周期，认为跳frame    

                final long skippedFrames = jitterNanos / mFrameIntervalNanos;

              //跳frame数大于默认值，打印警告信息，默认值为30   

                if (skippedFrames >= SKIPPED_FRAME_WARNING_LIMIT) {

                    Log.i(TAG, "Skipped " + skippedFrames + " frames!  "

                            + "The application may be doing too much work on its main thread.");

                }

              //计算实际开始当前frame与时钟信号的偏差值  

                final long lastFrameOffset = jitterNanos % mFrameIntervalNanos;

                if (DEBUG_JANK) {

                    Log.d(TAG, "Missed vsync by " + (jitterNanos * 0.000001f) + " ms "

                            + "which is more than the frame interval of "

                            + (mFrameIntervalNanos * 0.000001f) + " ms!  "

                            + "Skipping " + skippedFrames + " frames and setting frame "

                            + "time to " + (lastFrameOffset * 0.000001f) + " ms in the past.");

                }

              

              //修正偏差值，忽略偏差，为了后续更好地同步工作 

                frameTimeNanos = startNanos - lastFrameOffset;

            }



          //若时间回溯，则不进行任何工作，等待下一个时钟信号的到来

            if (frameTimeNanos < mLastFrameTimeNanos) {

                if (DEBUG_JANK) {

                    Log.d(TAG, "Frame time appears to be going backwards.  May be due to a "

                            + "previously skipped frame.  Waiting for next vsync.");

                }

              //请求下一次时钟信号  

                scheduleVsyncLocked();

                return;

            }



            ......



           //记录当前frame信息    

            mFrameInfo.setVsync(intendedFrameTimeNanos, frameTimeNanos);

            mFrameScheduled = false;

           //记录上一次frame开始时间，修正后的  

            mLastFrameTimeNanos = frameTimeNanos;

        }



        try {

          //执行相关callBack   

            Trace.traceBegin(Trace.TRACE_TAG_VIEW, "Choreographer#doFrame");

            AnimationUtils.lockAnimationClock(frameTimeNanos / TimeUtils.NANOS_PER_MS);



            mFrameInfo.markInputHandlingStart();

            doCallbacks(Choreographer.CALLBACK_INPUT, frameTimeNanos);



            mFrameInfo.markAnimationsStart();

            doCallbacks(Choreographer.CALLBACK_ANIMATION, frameTimeNanos);

            doCallbacks(Choreographer.CALLBACK_INSETS_ANIMATION, frameTimeNanos);



            mFrameInfo.markPerformTraversalsStart();

            doCallbacks(Choreographer.CALLBACK_TRAVERSAL, frameTimeNanos);



            doCallbacks(Choreographer.CALLBACK_COMMIT, frameTimeNanos);

        } finally {

            AnimationUtils.unlockAnimationClock();

            Trace.traceEnd(Trace.TRACE_TAG_VIEW);

        }

    }

doFrame方法对当前帧的运行时间进行了一系列判断和修正，最终顺序执行了五种事件回调。

1. CALLBACK_INPUT：输入


2. CALLBACK_ANIMATION:动画


3. CALLBACK_INSETS_ANIMATION：插入更新的动画


4. CALLBACK_TRAVERSAL:遍历，执行measure、layout、draw


5. CALLBACK_COMMIT：遍历完成的提交操作，用来修正动画启动时间

接着就会执行doCallbacks方法：

void doCallbacks(int callbackType, long frameTimeNanos) {

    CallbackRecord callbacks;

    ......

    try {

        Trace.traceBegin(Trace.TRACE_TAG_VIEW, CALLBACK_TRACE_TITLES[callbackType]);

      //迭代执行所有队列任务

        for (CallbackRecord c = callbacks; c != null; c = c.next) {

            .....

          //调用CallbackRecord内的run方法

            c.run(frameTimeNanos);

        }

    } finally {

        synchronized (mLock) {

            mCallbacksRunning = false;

            do {

                final CallbackRecord next = callbacks.next;

                recycleCallbackLocked(callbacks);

                callbacks = next;

            } while (callbacks != null);

        }

        Trace.traceEnd(Trace.TRACE_TAG_VIEW);

    }

}

主要是去遍历CallbackRecrd，执行所有任务：

private static final class CallbackRecord {

        public CallbackRecord next;

        public long dueTime;

        public Object action; // Runnable or FrameCallback

        public Object token;



        @UnsupportedAppUsage

        public void run(long frameTimeNanos) {

            if (token == FRAME_CALLBACK_TOKEN) {

                ((FrameCallback)action).doFrame(frameTimeNanos);

            } else {

                ((Runnable)action).run();

            }

        }

    }

最终action的run方法会被执行，这里的action也就是我们在前面调用psetCallback传进来的，也就是 ViewRootImpl 发起的绘制任务mTraversalRunnable了。

然后这里又一次调用了doFrame方法，在啥时候token会是FRAME_CALLBACK_TOKEN呢？ 可以发现在我们调用postFrameCallback内部会调用postCallbackDelayedInternal进行赋值：

 public void postFrameCallbackDelayed(FrameCallback callback, long delayMillis) {

        if (callback == null) {

            throw new IllegalArgumentException("callback must not be null");

        }



        postCallbackDelayedInternal(CALLBACK_ANIMATION,

                callback, FRAME_CALLBACK_TOKEN, delayMillis);

    }

而Choreographer的postFrameCallback()通常用来计算丢帧情况。

知道了Choreographer是上层用来接收VSync的角色之后，我们需要进一步了解VSync信号是如何控制上层的绘制的。而绘制UI的起点是View的requestLayout或者是invalidate方法被调用触发，好了时间不早了，这些就放在下一篇Android的屏幕刷新机制里解释吧。（刷新流程和同步屏障）

三. 小结

Android在黄油计划中引入了三个核心元素：VSYNC、Triple Buffer 和 Choreographer。

VSYNC 信号是由屏幕（显示设备）产生的，并且以 60fps 的固定频率发送给 Android 系统，Android 系统中的 SurfaceFlinger 接收发送的 VSYNC 信号。VSYNC 信号表明可对屏幕进行刷新而不会产生撕裂。

三重缓存机制（Triple Buffer） 利用 CPU/GPU 的空闲等待时间提前准备好数据，有效的提升了渲染性能。

又介绍了 Choreographer ，它实现了协调动画(animations)、输入(input)、绘制(drawing)三个UI相关的操作。

参考

Android 显示刷新机制、VSYNC和三重缓存机制

Android图形显示系统（一）

Android屏幕刷新机制

Android Choreographer 源码分析

“终于懂了” 系列：Android屏幕刷新机制—VSync、Choreographer 全面理解！

1 代码重构

定义

对软件代码做任何改动以增加可读性或者简化结构而不影响输出结果。

目的

增加可读性、增加可维护性、可扩展性

3 关键点

• 不影响输出


• 不修正错误


• 不增加新的功能性

代码重构时，发现有个功能实现逻辑不合理，可直接修改吗？

当然不可！

2 架构重构

定义

通过整系统结构(4R)来修复系统质量问题而不影响整体系统能力。

目的

修复质量问题（性能、可用性、可扩展......）

关键点

• 修复质量（架构，而非代码层面的质量）问题，提升架构质量


• 不影响整体系统功能


• 架构本质没有发生变化

把某个子系统的实现方式从硬编码改为规则引擎，是代码重构还是架构重构？

属于架构重构，架构设计方案了，实现系统可扩展性。

3 代码重构 V.S 架构重构

4 架构重构技巧

4.0 手段

架构重构是否可以修改 4R 中的 Rank？

不能！修改 rank 就不是重构，而是演进了。拆微服务不属于改 rank。外部系统协作方式都得修改了。比如将淘宝的支付方式支付宝拆出来，成为支付宝公司了。

4.1 先局部优化后架构重构

局部优化

定义：对部分业务或者功能进行优化，不影响系统架构。

常见手段：

• 数据库添加索引，优化索引


• 某个数据缓存更新策略采用后台更新


• 增加负载均衡服务数量


• 优化代码里面并发的逻辑


• 修改Innodb buffer pool 配置，分配更多内存


• 服务间的某个接口增加1个参数

架构重构

定义：优化系统架构，整体提升质量，架构重构会影响架构的4R定义。

常见手段：

• 引入消息队列(增加 Role )


• 去掉 ZooKeeper，改为内置 Raft 算法实现(删除 Role)


• 将 Memcached 改为 Redis( 改变 Role)


• 按照稳定性拆分微服务( 拆分 Role )


• 将粒度太细的微服务合并(合并 Role)


• 将服务间的通信方式由 HTTP 改为 gRPC(修改 Relation )


• SDK从读本地配置文件改为从管理系统读取配置(修改Rule )

4.2 有的放矢

案例

• 开发效率很慢，P业务和M系统互相影响


• 线上问题很多，尤其是数据类问题


• M系统性能很低

有的放矢：

重构只解决第1个问题（开发效率很慢，P业务和M系统互相影响）。其他问题咋办，架构师你不解决了吗？架构重构后了，各个业务部门再解决各自的问题，如 P业务后台优化自己的问题，M 系统优化自己的性能问题，因为这些问题本身靠重构是解决不了的，而是要靠重构拆分之后，各自再继续优化。

4.3 合纵连横

合纵

说服业务方和老板

0. 
   

   以数据说话

   
   

   把“可扩展性”转换为“版本开发速度很慢然后给出对应的项目数据（平时注意搜集数据）。

   
   


1. 
   

   以案例说话（其实更有效，给人的冲击力更明显） 若没有数据，就举极端案例，如某个小功能，开发测试只要5天，但是等了1个月才上线。

   
   

连横

说服其它团队。

0. 换位思考 思考对其它团队的好处，才能让人配合。


1. 合作双赢 汇报和总结的时候，把其它团队也带上。

案例

合纵：告诉PM和项目经理极端案例，设计2周、开发2天、一个月才上线。

连横：P业务线上问题大大减少，P业务不会被其它业务影响

4.4 运筹帷幄

① 问题分类

将问题分类，一段时间集中处理类问题。 避免对照 Excel表格，一条条解决。

② 问题排序

分类后排序，按照优先级顺序来落地。

避免见缝插针式的安排重构任务，不要搭业务的顺风车重构：

• 避免背锅


• 效果不明显


• 无法安排工作量大的重构

③ 逐一攻破

每类问题里面先易后难。

把容易的问题解决掉，增强信心。

④ 案例

Before：

• 1个100多行的Excel问题表格，一个一个的解决


• 专挑软柿子捏


• 见缝插针

After：

0. 分类：性能、组件、架构、代码


1. 分阶段: 优化-> 架构重构 -> 架构演进


2. 专项落地: 明确时间、目标、版本

5 架构重构FAQ

架构重构是否可以引入新技术？

可以，但尽量少，架构重构要求快准。

业务不给时间重构怎么办 ?

会哭的孩了有奶吃。收集数据和案例，事实说话。

其它团队不配合怎么办 ?

学会利用上级力量。上级都不支持，说明你做的这个没意义，所以领导也不在乎。那就别做了。

业务进度很紧，人力不够怎么办 ?

收集需要重构的证据，技术汇报的时候有理有据

6 测试

6.1 判断

0. 代码重构、架构重构、架构演进都不需要去修复问题 ×


1. 微服务拆分既可以是架构重构的手段，也可以是架构演进的手段 √


2. 架构重构应该搭业务版本的便车，可以避免对业务版本有影响 ×


3. 架构重构是为修复问题，因此应该将系统遗留的问题都在架构重构的时候修复 ×


4. 架构重构应该分门别类，按照优先级逐步落地 √

6.2 思考

架构重构的时候是否可以顺手将代码重构也做了 ? 因为反正都安排版本了。No！

局部优化不属于代码/架构重构。

视频先行

这是一篇视频形式的分享，如果你方便看，可以直接去看视频：

• 哔哩哔哩：这里


• 抖音：这里


• YouTube：这里

下面是视频内容的脚本文案原稿分享。

视频文案原稿

很多从 Java 转到 Kotlin 的人都会有一个疑惑：为什么 Kotlin 没有沿用 Java 的 void 关键字，而要引入这个叫 Unit 的新东西？

// Java

public void sayHello() {

  System.out.println("Hello!");

}

// Kotlin

fun sayHello(): Unit {

  println("Hello!")

}

不过这个问题一般也不会维持很久，因为就算你不明白，好像……也不影响写代码。

直到这两年，大家发现 Compose 的官方示例代码里竟然有把 Unit 填到函数参数里的情况：

LaunchedEffect(Unit) {

  xxxx

  xxxxxx

  xxx

}

我们才觉得：「啊？还能这么写？」

Unit 的本质

大家好，我是扔物线朱凯。

今天来讲一讲 Unit 这个特殊的类型。

我们在刚学 Kotlin 的时候，就知道 Java 的 void 关键字在 Kotlin 里没有了，取而代之的是一个叫做 Unit 的东西：

// Java

public void sayHello() {

  System.out.println("Hello!")

}

// Kotlin

fun sayHello(): Unit {

  println("Hello!")

}

而这个 Unit，和 Java 的 void 其实是不一样的。比如 Unit 的返回值类型，我们是可以省略掉不写的：

// Kotlin

fun sayHello() {

  println("Hello!")

}

不过省略只是语法上的便利，实际上 Kotlin 还是会把它理解成 Unit。

Unit 和 Java 的 void 真正的区别在于，void 是真的表示什么都不返回，而 Kotlin 的 Unit 却是一个真实存在的类型：

public object Unit {

    override fun toString() = "kotlin.Unit"

}

它是一个 object，也就是 Kotlin 里的单例类型或者说单例对象。当一个函数的返回值类型是 Unit 的时候，它是需要返回一个 Unit 类型的对象的：

// Kotlin

fun sayHello() {

  println("Hello!")

  return Unit

}

只不过因为它是个 object ，所以唯一能返回的值就是 Unit 本身。

另外，这一行 return 我们也可以省略不写：

// Kotlin

fun sayHello() {

  println("Hello!")

}

因为就像返回值类型一样，这一行 return，Kotlin 也会帮我们自动加上：

// Kotlin

fun sayHello(): Unit {

  println("Hello!")

  return Unit

}

这两个 Unit 是不一样的，上面的是 Unit 这个类型，下面的是 Unit 这个单例对象，它俩长得一样但是是不同的东西。注意了，这个并不是 Kotlin 给 Unit 的特权，而是 object 本来就有的语法特性。你如果有需要，也可以用同样的格式来使用别的单例对象，是不会报错的：

object Rengwuxian



fun getRengwuxian(): Rengwuxian {

  return Rengwuxian

}

包括你也可以这样写：

val unit: Unit = Unit

也是一样的道理，等号左边是类型，等号右边是对象——当然这么写没什么实际作用啊，单例你就直接用就行了。

所以在结构上，Unit 并没有任何的特别之处，它就只是一个 Kotlin 的 object 而已。除了对于函数返回值类型和返回值的自动补充之外，Kotlin 对它没有再施加任何的魔法了。它的特殊之处，更多的是在于语义和用途的角度：它是个由官方规定出来的、用于「什么也不返回」的场景的返回值类型。但这只是它被规定的用法而已，而本质上它真就是个实实在在的类型。也就是在 Kotlin 里，并不存在真正没有返回值的函数，所有「没有返回值」的函数实质上的返回值类型都是 Unit，而返回值也都是 Unit 这个单例对象，这是 Unit 和 Java 的 void 在本质上的不同。

Unit 的价值所在

那么接下来的问题就是：这么做的意义在哪？

意义就在于，Unit 去掉了无返回值的函数的特殊性，消除了有返回值和无返回值的函数的本质区别，这样很多事做起来就会更简单了。

例：有返回值的函数在重写时没有返回值

比如？

比如在 Java 里面，由于 void 并不是一种真正的类型，所以任何有返回值的方法在子类里的重写方法也都必须有返回值，而不能写成 void，不管你用不用泛型都是一样的：

public abstract class Maker {

  public abstract Object make();

}



public class AppleMaker extends Maker {

  // 合法

  @Override

  public Apple make() {

    return new Apple();

  }

}



public class NewWorldMaker extends Maker {

  // 非法

  @Override

  public void make() {

    world.refresh();

  }

}

public abstract class Maker<T> {

  public abstract T make();

}



public class AppleMaker extends Maker<Apple> {

  // 合法

  Override

  public Apple make() {

    return new Apple();

  }

}



public class NewWorldMaker extends Maker<void> {

  // 非法

  Override

  public void make() {

    world.refresh();

  }

}

你只能去写一行 return null 来手动实现接近于「什么都不返回」的效果：

public class NewWorldMaker extends Maker {

  @Override

  public Object make() {

    world.refresh();

    return null;

  }

}

而且如果你用的是泛型，可能还需要用一个专门的虚假类型来让效果达到完美：

public class NewWorldMaker extends Maker<Void> {

  @Override

  public Void make() {

    world.refresh();

    return null;

  }

}

而在 Kotlin 里，Unit 是一种真实存在的类型，所以直接写就行了：

abstract class Maker {

  abstract fun make(): Any

}



class AppleMaker : Maker() {

  override fun make(): Apple {

    return Apple()

  }

}



class NewWorldMaker : Maker() {

  override fun make() {

    world.refresh()

  }

}

abstract class Maker<T> {

  abstract fun make(): T

}



class AppleMaker : Maker<Apple>() {

  override fun make(): Apple {

    return Apple()

  }

}



class NewWorldMaker : Maker<Unit>() {

  override fun make() {

    world.refresh()

  }

}

这就是 Unit 的去特殊性——或者说通用性——所给我们带来的便利。

例：函数类型的函数参数

同样的，这种去特殊性对于 Kotlin 的函数式编程也提供了方便。一个函数的函数类型的参数，在函数调用的时候填入的实参，只要符合声明里面的返回值类型，它是可以有返回值，也可以没有返回值的：

fun runTask(task: () -> Any) {

  when (val result = task()) {

    Unit -> println("result is Unit")

    String -> println("result is a String: $result")

    else -> println("result is an unknown type")

  }

}



...



runTask { } // () -> Unit

runTask { "完成！" } // () -> String

runTask { 1 } // () -> Int

Java 不支持把方法当做对象来传递，所以我们没法跟 Java 做对比；但如果 Kotlin 不是像现在这样用了 Unit，而是照抄了 Java 的 void 关键字，我们就肯定没办法这样写。

小结：去特殊化

这就是我刚才所说的，对于无返回值的函数的「去特殊化」，是 Unit 最核心的价值。它相当于是对 Java 的 void 进行了缺陷的修复，让本来有的问题现在没有了。而对于实际开发，它的作用是属于润物细无声的，你不需要懂我说的这一大堆东西，也不影响你享受 Unit 的这些好处。

…………

那我出这期视频干嘛？

——开个玩笑。了解各种魔法背后的实质，对于我们掌握和正确地使用一门语言是很有必要的。

延伸：当做纯粹的单例对象来使用

比如，知道 Unit 是什么之后，你就能理解为什么它能作为函数的参数去被使用。

Compose 里的协程函数 LaunchedEffect() 要求我们填入至少一个 key 参数，来让协程在界面状态变化时可以自动重启：

LaunchedEffect(key) {

  xxxx

  xxxxxx

  xxx

}

而如果我们没有自动重启的需求，就可以在参数里填上一个 Unit：

LaunchedEffect(Unit) {

  xxxx

  xxxxxx

  xxx

}

因为 Unit 是不变的，所以把它填进参数里，这个协程就不会自动重启了。这招用着非常方便，Compose 的官方示例里也有这样的代码。不过这个和 Unit 自身的定位已经无关了，而仅仅是在使用它「单例」的性质。实际上，你在括号里把它换成任何的常量，效果都是完全一样的，比如 true、比如 false、比如 1、比如 0、比如 你好，都是可以的。所以如果你什么时候想「随便拿个对象过来」，或者「随便拿个单例对象过来」，也可以使用 Unit，它和你自己创建一个 object 然后去使用，效果是一样的。

总结

好，这就是 Kotlin 的 Unit，希望这个视频可以帮助你更好地了解和使用它。下期我会讲 Kotlin 里另一个特殊的类型：Nothing。关注我，了解更多 Android 开发的知识和技能。我是扔物线，我不和你比高低，我只助你成长。我们下期见！

背景

笔者在使用 EventBus 的过程中发现有时只能收到最后一次的粘性 Event ，导致业务逻辑出现混乱，下面是笔者的使用示例：

// Event.java

public final class Event {



    private final int code;



    public Event(int code) {

        this.code = code;

    }



    public int getCode() {

        return code;

    }

}

// Example.java

public class Example {



    // 调用多次

    public void test(int code) {

        EventBus.getDefault().postSticky(new Event(code));

    }

    

    // 调用多次 `test(int code)` 后再注册订阅者

    public void register() {

        EventBus.getDefault().register(this);

    }



    @Subscribe(threadMode = ThreadMode.MAIN, sticky = true)

    public void receiveEvent(Event event) {

        // 发现只能收到最后一次的粘性事件

        System.out.println(event.getCode());

    }

}

所以去查看了 EventBus 的源码，接下来我们分析下 EventBus 发送粘性事件的流程。

分析

粘性事件

以下源码基于 EventBus 3.3.1 版本

下面是发送粘性事件的源码：

private final Map, Object> stickyEvents;



public void postSticky(Object event) {

    synchronized (stickyEvents) {

        stickyEvents.put(event.getClass(), event);

    }

    // Should be posted after it is putted, in case the subscriber wants to remove immediately

    post(event);

}

postSticky 代码比较简单，首先对 stickyEvents 进行加锁，接下来把 event 事件的 Class 对象作为 Key，event 事件本身作为 value 放进 Map 中，其中stickyEvents 是 Map 对象，实例是 ConcurrentHashMap, 其 Key 和 Value 的泛型形参分别是 Class 和 Object, 它的作用就是用来存储粘性事件；然后调用 post(event) 把粘性事件当作普通事件发送一下。

首先我们看下最后为什么要调用下 post(event)？

虽然 post(evnet) 上面有注释，简单翻译下："在放进 Map 后应该再发送一次，以防止订阅者想立即删除此事件"，读完注释后，可能还是不太明白，这里笔者认为：在前面存储完粘性事件后，这里调用 post 把粘性事件当作普通事件发送出去，或许是因为现在已经有注册的粘性事件订阅者，此时把已经注册的粘性事件订阅者当作普通事件的订阅者，这样已经注册的粘性事件订阅者可以立即收到相应的事件，只是此时事件不再是粘性的。

在 postSticky 中我们并没有看到粘性事件是在哪里发送的，想一想我们使用粘性事件的目的是什么？当注册订阅者时可以收到之前发送的事件，这样来看，粘性事件的发送是在注册订阅者时，下面是注册订阅者的源码，删除了一些无关代码：

public void register(Object subscriber) {

    

    // 省略无关代码

    

    Class subscriberClass = subscriber.getClass();

    

    // 查找订阅者所有的Event接收方法

    List subscriberMethods = subscriberMethodFinder.findSubscriberMethods(subscriberClass);

    synchronized (this) {

        for (SubscriberMethod subscriberMethod : subscriberMethods) {

            subscribe(subscriber, subscriberMethod);

        }

    }

}

register 代码也比较简单，首先通过订阅者的 Class 对象查找订阅者所有的Event事件接收方法，然后对 EventBus 对象加锁，遍历所有的Event事件接收方法 subscriberMethods 调用 subscribe 方法，以下是 subscribe 方法源码：

// Key 为 Event Class 对象，Value 为存储 Event 的订阅者和接收 Event 方法对象的集合 

private final Map, CopyOnWriteArrayList> subscriptionsByEventType;



// Key 为订阅者对象，Value 为订阅者中的 Event Class对象集合

private final Map>> typesBySubscriber;



// Must be called in synchronized block

private void subscribe(Object subscriber, SubscriberMethod subscriberMethod) {

    // Event Class对象

    Class eventType = subscriberMethod.eventType;

    

    // 订阅者和接收 Event 方法对象

    Subscription newSubscription = new Subscription(subscriber, subscriberMethod);

    

    // 根据 Event Class对象，获取订阅者和接收 Event 方法对象的集合

    CopyOnWriteArrayList subscriptions = subscriptionsByEventType.get(eventType);

    

    // 判断订阅者和接收 Event 方法对象是否为空

    if (subscriptions == null) {

        subscriptions = new CopyOnWriteArrayList<>();

        subscriptionsByEventType.put(eventType, subscriptions);

    } else {

        // 判断是否已经包含了新的订阅者和接收 Event 方法对象，若是包含则认为是重复注册

        if (subscriptions.contains(newSubscription)) {

            throw new EventBusException("Subscriber " + subscriber.getClass() + " already registered to event "

                                        + eventType);

        }

    }



    // 这里是按优先级排序插入到集合中

    int size = subscriptions.size();

    for (int i = 0; i <= size; i++) {

        if (i == size || subscriberMethod.priority > subscriptions.get(i).subscriberMethod.priority) {

            subscriptions.add(i, newSubscription);

            break;

        }

    }



    // 这里是把 Event Class对象添加进对应订阅者的 Event Class对象集合中

    List> subscribedEvents = typesBySubscriber.get(subscriber);

    if (subscribedEvents == null) {

        subscribedEvents = new ArrayList<>();

        typesBySubscriber.put(subscriber, subscribedEvents);

    }

    

    // 上面已经判断了是否重复注册，所以这里直接添加

    subscribedEvents.add(eventType);



    // 接下来就是粘性事件的发送逻辑了

    // 判断 Event 接收方法是否可以处理粘性事件

    if (subscriberMethod.sticky) {

        // 这里判断是否考虑 Event 事件类的继承关系，默认为 Ture

        if (eventInheritance) {

            Set, Object>> entries = stickyEvents.entrySet();

            for (Map.Entry, Object> entry : entries) {

                Class candidateEventType = entry.getKey();

                if (eventType.isAssignableFrom(candidateEventType)) {

                    Object stickyEvent = entry.getValue();

                    checkPostStickyEventToSubscription(newSubscription, stickyEvent);

                }

            }

        } else {

            Object stickyEvent = stickyEvents.get(eventType);

            checkPostStickyEventToSubscription(newSubscription, stickyEvent);

        }

    }

}

在上面的源码中，增加了不少注释有助于我们读懂源码，在源码的最后就是粘性事件的发送逻辑了，其中有两个分支，其中一个分支根据 Event 事件的继承关系发送事件，另外一个分支根据接收 Event 方法中的 Event Class 对象从 stickyEvents 中直接查找粘性事件，最后两个分支殊途同归，都调用了 checkPostStickyEventToSubscription 方法：

private void checkPostStickyEventToSubscription(Subscription newSubscription, Object stickyEvent) {

    if (stickyEvent != null) {

        // If the subscriber is trying to abort the event, it will fail (event is not tracked in posting state)

        // --> Strange corner case, which we don't take care of here.

        postToSubscription(newSubscription, stickyEvent, isMainThread());

    }

}

checkPostStickyEventToSubscription 方法很简单，对粘性事件做下判空处理，继续调用 postToSubscription 方法，传入订阅者与接收 Event 方法对象，粘性事件和是否是主线程布尔值：

private void postToSubscription(Subscription subscription, Object event, boolean isMainThread) {

    switch (subscription.subscriberMethod.threadMode) {

        case POSTING:

            invokeSubscriber(subscription, event);

            break;

        case MAIN:

            if (isMainThread) {

                invokeSubscriber(subscription, event);

            } else {

                mainThreadPoster.enqueue(subscription, event);

            }

            break;

        case MAIN_ORDERED:

            if (mainThreadPoster != null) {

                mainThreadPoster.enqueue(subscription, event);

            } else {

                // temporary: technically not correct as poster not decoupled from subscriber

                invokeSubscriber(subscription, event);

            }

            break;A

                case BACKGROUND:

            if (isMainThread) {

                backgroundPoster.enqueue(subscription, event);

            } else {

                invokeSubscriber(subscription, event);

            }

            break;

        case ASYNC:

            asyncPoster.enqueue(subscription, event);

            break;

        default:

            throw new IllegalStateException("Unknown thread mode: " + subscription.subscriberMethod.threadMode);

    }

}

postToSubscription 方法比较长，但是比较好理解，就是根据接收 Event 方法上的 @Subscribe 注解中传入的线程模型进行事件的分发，具体的事件分发流程，有空再分析，本文就先不分析了，现在我们只需知道最后都会调用 invokeSubscriber(Subscription subscription, Object event) 方法即可：

void invokeSubscriber(Subscription subscription, Object event) {

    try {

        // 反射调用 Event 接收方法传入 Event 事件

        subscription.subscriberMethod.method.invoke(subscription.subscriber, event);

    } catch (InvocationTargetException e) {

        handleSubscriberException(subscription, event, e.getCause());

    } catch (IllegalAccessException e) {

        throw new IllegalStateException("Unexpected exception", e);

    }

}

终于在 invokeSubscriber 方法中找到调用 Event 接收方法的地方了，原来 EventBus 最后是通过反射调用 Event 接收方法并传入相应 Event 事件的。

分析完 Event 事件的发送流程，好像没有发现为什么有时收不到粘性事件。

我们回过头来再看下笔者的使用示例，为了方便查看，下面贴出使用示例代码：

// Example.java

public class Example {



    // 调用多次

    public void test(int code) {

        EventBus.getDefault().postSticky(new Event(code));

    }

    

    // 调用多次 `test(int code)` 后再注册订阅者

    public void register() {

        EventBus.getDefault().register(this);

    }



    @Subscribe(threadMode = ThreadMode.MAIN, sticky = true)

    public void receiveEvent(Event event) {

        // 发现只能收到最后一次的粘性事件

        System.out.println(event.getCode());

    }

}

可能细心的读者已经发现 test 方法调用了，问题应该出在 postSticky 方法中，让我们再次查看 postSticky 方法：

private final Map, Object> stickyEvents;



public void postSticky(Object event) {

    synchronized (stickyEvents) {

        stickyEvents.put(event.getClass(), event);

    }

    // Should be posted after it is putted, in case the subscriber wants to remove immediately

    post(event);

}

根据前面分析 postSticky 方法的结果，stickyEvents 用于存储粘性事件，它是个 Map 结构，而 stickyEvents 的 Key 正是 Event 的 Class 对象，根据 Map 结构的存储原理：如果存在相同的 Key，则覆盖 Value 的值，而 stickyEvents 的 Value 正是 Event 本身。

终于真相大白，多次调用 test 方法发送粘性事件，EventBus 只会存储最后一次的粘性事件。

小结

EventBus 针对同一个粘性 Event 事件只会存储最后一次发送的粘性事件。

EventBus 的上述实现可能是因为多次发送同一个粘性事件，则认为之前的事件是过期事件应该抛弃，因此只传递最新的粘性事件。

EventBus 的这种实现无法满足笔者的业务逻辑需求，笔者希望多次发送的粘性事件，订阅者都能接收到，而不是只接收最新的粘性事件，可以理解为粘性事件必达订阅者，下面让我们修改 EventBus 的源码来满足需求吧。

修改

上一节我们分析了粘性事件的发送流程，为了满足粘性事件必达的需求，基于现有粘性事件流程，我们可以仿照粘性事件的发送来提供一个发送必达消息的方法。

Subscribe

首先我们定义 Event 接收方法可以接收粘性事件是在 @Subscribe 中 sticky = true , 所以我们可以修改 Subscribe 注解，增加粘性事件必达的方法：

@Documented

@Retention(RetentionPolicy.RUNTIME)

@Target({ElementType.METHOD})

public @interface Subscribe {

    ThreadMode threadMode() default ThreadMode.POSTING;



    /**

     * If true, delivers the most recent sticky event (posted with

     * {@link EventBus#postSticky(Object)}) to this subscriber (if event available).

     */

    boolean sticky() default false;



    // 增加消息必达的方法

    boolean rendezvous() default false;



    /** Subscriber priority to influence the order of event delivery.

     * Within the same delivery thread ({@link ThreadMode}), higher priority subscribers will receive events before

     * others with a lower priority. The default priority is 0. Note: the priority does *NOT* affect the order of

     * delivery among subscribers with different {@link ThreadMode}s! */

    int priority() default 0;

}

rendezvous 以为约会、约定的意思，可以理解为不见不散，在这里它有两层作用，其一是标记方法可以接收粘性事件，其二是标记方法接收的事件是必达的。

findSubscriberMethods

接下来就需要解析 rendezvous 了，我们先看看 sticky 是如何解析的，在上一节我们分析了 register 方法，方便查看，下面再贴出 register 方法源码：

public void register(Object subscriber) {

    

    // 省略无关代码

    

    Class subscriberClass = subscriber.getClass();

    

    // 查找订阅者所有的Event接收方法

    List subscriberMethods = subscriberMethodFinder.findSubscriberMethods(subscriberClass);

    synchronized (this) {

        for (SubscriberMethod subscriberMethod : subscriberMethods) {

            subscribe(subscriber, subscriberMethod);

        }

    }

}

上一节分析中，我们没有分析查找订阅者中所有的 Event 接收方法 findSubscriberMethods ，接下来我们分析下在 findSubscriberMethods 方法是如何查找 Event 接收方法的：

List findSubscriberMethods(Class subscriberClass) {

    // 先从缓存中查找

    List subscriberMethods = METHOD_CACHE.get(subscriberClass);

    if (subscriberMethods != null) {

        return subscriberMethods;

    }



    // 是否忽略生成索引，默认为False，所以这里走else分支

    if (ignoreGeneratedIndex) {

        subscriberMethods = findUsingReflection(subscriberClass);

    } else {

        // 查找Event接收方法

        subscriberMethods = findUsingInfo(subscriberClass);

    }

    

    // 如果订阅者和订阅者父类中没有Event接收方法则抛出异常

    if (subscriberMethods.isEmpty()) {

        throw new EventBusException("Subscriber " + subscriberClass

                                    + " and its super classes have no public methods with the @Subscribe annotation");

    } else {

        // 添加进缓存中

        METHOD_CACHE.put(subscriberClass, subscriberMethods);

        return subscriberMethods;

    }

}

调用 findSubscriberMethods 方法需要传入订阅者 Class 对象，通过笔者在源码中增加的注释分析发现默认调用 findUsingInfo 方法查找 Event 接收方法，我们继续跟踪 findUsingInfo 方法：

private List findUsingInfo(Class subscriberClass) {

    // FindState对订阅者Class对象和Event接收方法进行了一层封装

    FindState findState = prepareFindState();

    findState.initForSubscriber(subscriberClass); // ①

    while (findState.clazz != null) {

        

        // 查找订阅者信息，包含订阅者Class对象、 订阅者父类、Event接收方法等

        findState.subscriberInfo = getSubscriberInfo(findState); // ②

        

        // 在 ① initForSubscriber中会把subscriberInfo置为null，

        // 在 ② getSubscriberInfo中没有Index对象，

        // 所以第一次时这里会走else分支

        if (findState.subscriberInfo != null) {

            SubscriberMethod[] array = findState.subscriberInfo.getSubscriberMethods();

            for (SubscriberMethod subscriberMethod : array) {

                if (findState.checkAdd(subscriberMethod.method, subscriberMethod.eventType)) {

                    findState.subscriberMethods.add(subscriberMethod);

                }

            }

        } else {

            // 查找Event接收方法

            findUsingReflectionInSingleClass(findState);

        }

        

        // 查找父类的Event接收方法

        findState.moveToSuperclass();

    }

    

    // 通过findState返回Event接收方法，并回收findState

    return getMethodsAndRelease(findState);

}

根据笔者在源码中的注释分析，在 findUsingInfo 方法中使用「享元模式」对 FindState 进行回收利用，避免创建大量临时的 FindState 对象占用内存，最后再次调用 findUsingReflectionInSingleClass 方法查找 Event 接收方法，看方法名字应该是使用反射查找，findUsingReflectionInSingleClass 源码较长，删减一些不关心的代码：

private void findUsingReflectionInSingleClass(FindState findState) {

    Method[] methods;

    try {

        // This is faster than getMethods, especially when subscribers are fat classes like Activities

        // 通过反射获取当前类中声明的所有方法

        methods = findState.clazz.getDeclaredMethods();

    } catch (Throwable th) {

        // 删减不关心的代码

    }

    

    // 遍历所有方法

    for (Method method : methods) {

        

        // 获取方法的修饰符

        int modifiers = method.getModifiers();

        

        // 判断方法是否是public的；是否是抽象方法，是否是静态方法，是否是桥接方法，是否是合成方法

        if ((modifiers & Modifier.PUBLIC) != 0 && (modifiers & MODIFIERS_IGNORE) == 0) {

            

            // 获取方法的形参Class对象数组

            Class[] parameterTypes = method.getParameterTypes();

            if (parameterTypes.length == 1) {

                

                // 获取方法上的Subscribe注解

                Subscribe subscribeAnnotation = method.getAnnotation(Subscribe.class);

                if (subscribeAnnotation != null) {

                    Class eventType = parameterTypes[0];

                    

                    // 检测是否已经添加了相同签名的方法，考虑子类复写父类方法的情况

                    if (findState.checkAdd(method, eventType)) {

                        

                        // 获取注解的参数

                        ThreadMode threadMode = subscribeAnnotation.threadMode();

                        findState.subscriberMethods.add(new SubscriberMethod(method, eventType, threadMode,

								subscribeAnnotation.priority(), subscribeAnnotation.sticky(),

								

								// 这里我们添加rendezvous参数 ①

								subscribeAnnotation.rendezvous()));

                    }

                }

            }

            // 删减不关心的代码

        }

        // 删减不关心的代码

    }

}

在 findUsingReflectionInSingleClass 方法中通过反射获取订阅者中声明的所有方法，然后遍历所有方法：

1. 首先判断方法的修饰符是否符合，


2. 其次判断方法是否只有一个形参，


3. 再次判断方法是否有 Subscribe 注解，


4. 然后检测是否已经添加了相同签名的方法，主要是考虑子类复写父类方法这种情况，


5. 最后获取 Subscribe 注解的参数，在这里我们解析 rendezvous，封装进 SubscriberMethod 中。

在 SubscriberMethod 中增加 rendezvous 字段，删除不关心的代码：

public class SubscriberMethod {

    final Method method;

    final ThreadMode threadMode;

    final Class eventType;

    final int priority;

    final boolean sticky;



    // 增加 `rendezvous` 字段

    final boolean rendezvous;

    /** Used for efficient comparison */

    String methodString;



    public SubscriberMethod(Method method, Class eventType, ThreadMode threadMode, 

                            int priority, boolean sticky,

                            

                            // 增加 `rendezvous` 形参

                            boolean rendezvous) {

        this.method = method;

        this.threadMode = threadMode;

        this.eventType = eventType;

        this.priority = priority;

        this.sticky = sticky;

        this.rendezvous = rendezvous;

    }

}

postRendezvous

好的，rendezvous 已经解析出来了，接下来我们对外提供发送必达事件的接口：

// 选择List存储必达事件，使用Pair封装必达事件的Key和Value

private final List, Object>> rendezvousEvents;



public void postRendezvous(Object event) {

    synchronized (rendezvousEvents) {

        rendezvousEvents.add(Pair.create(event.getClass(), event));

    }

    // Should be posted after it is putted, in case the subscriber wants to remove immediately

    post(event);

}

上面的源码，我们通过仿照 postSticky 方法实现了 postRendezvous 方法，在 postSticky 方法中使用 Map 存储粘性事件，不过我们在 postRendezvous 方法中使用 List 存储必达事件，保证必达事件不会因为 Key 相同而被覆盖丢失，最后也是调用 post 方法尝试先发送一次必达事件。

register

在上一节中我们分析了粘性事件是在 register 中调用 subscribe 方法进行发送的，这里我们仿照粘性事件的发送逻辑，实现必达事件的发送逻辑，我们可以在 subscribe 方法最后增加发送必达事件的逻辑，以下源码省略了一些不关心的代码：

private final List, Object>> rendezvousEvents;



private void subscribe(Object subscriber, SubscriberMethod subscriberMethod) {

    // 省略不关心的代码



    // 粘性事件发送逻辑

    if (subscriberMethod.sticky) {

        if (eventInheritance) {

            Set, Object>> entries = stickyEvents.entrySet();

            for (Map.Entry, Object> entry : entries) {

                Class candidateEventType = entry.getKey();

                if (eventType.isAssignableFrom(candidateEventType)) {

                    Object stickyEvent = entry.getValue();

                    checkPostStickyEventToSubscription(newSubscription, stickyEvent);

                }

            }

        } else {

            Object stickyEvent = stickyEvents.get(eventType);

            checkPostStickyEventToSubscription(newSubscription, stickyEvent);

        }

    }



    // 新增必达事件发送逻辑

    // 判断方法是否可以接收必达事件

    if (subscriberMethod.rendezvous) {

        if (eventInheritance) {

            for (Pair, Object> next : rendezvousEvents) {

                Class candidateEventType = next.first;

                if (eventType.isAssignableFrom(candidateEventType)) {

                    Object stickyEvent = next.second;

                    checkPostStickyEventToSubscription(newSubscription, stickyEvent);

                }

            }

        } else {

            Object rendezvousEvent = getRendezvousEvent(eventType);

            if (rendezvousEvent != null) {

                checkPostStickyEventToSubscription(newSubscription, rendezvousEvent);

            }

        }

    }

}

在 subscribe 方法中，我们通过仿照粘性事件的发送逻辑增加了必达事件的发送：

1. 首先判断 Event 接收方法是否可以接收必达事件


2. 其次考虑 Event 必达事件的继承关系，


3. 最后两个分支都调用 checkPostStickyEventToSubscription 方法发送必达事件

happy~

总结

使用第三方库时，发现问题不要慌张，带着问题去查看源码总有一番收获，这也告诫我们在使用第三库时最好先搞明白它的实现原理，遇到问题时不至于束手无策。

通过分析 EventBus 的源码，我们有以下收获：

1. 明白了我们注册订阅者时 EventBus 做了哪些事情


2. 知晓了我们发送粘性事件时，EventBus 是如何处理及何时发送粘性事件的


3. 了解到 EventBus 是通过反射调用 Event 事件的接收方法


4. 学习了 EventBus 中的一些优化点，比如对 FindState 使用「享元模式」避免创建大量临时对象占用内存


5. 进一步了解到对并发的处理

通过以上收获，我们成功修改 EventBus 源码实现了我们必达事件的需求。

到这里我们已经完成了必达事件的发送，不过我们还剩下获取必达事件，移除必达事件没有实现，最后 EventBus 中还有单元测试 module，我们还没有针对 rendezvous 编写单元测试，读者有兴趣的话，可以自己试着实现。

希望可以帮到你~

工作环境

我新入职的公司是哈尔滨的一家国企下的二级子公司，新成立的研发公司，目前还处于蓬勃发展的阶段，业务水准也算的上是不错了。

人

目前人数100多个，但是却五脏俱全。单说研发部门，从产品，UI，研发，测试，运维，甚至运营人员都很完善，人员只需要根据自己的职责去负责自己的事情就好。

办公环境可以分为两个环境，分别是“职能部门”和“研发部门”：

* 职能部门比较正式，工位、装修以及员工着装都比较正规。

* 研发部门较为随意一些，无论是工位还是桌椅什么的，有些东拼西凑的感觉，但是整体还是可以接受。

另外可能是因为国企的原因，所有的工位都是大隔断那种，如果换成现在公司常见的大通桌，估计人数还能多做十好几个，毕竟我刚来的时候还没有正式工位坐呢。

吃

相比于在其他公司上班，可能在这最大的体会就是不用考虑吃什么。公司有食堂，提供午饭，菜不能选，但是每天四菜一汤，加水果或酸奶。相比于每天纠结的选择外卖，我对这个很满意。

晚上如果加班的话，公司会统一订餐，大概一餐的费用也在20至30块之间吧，当然也没法选择吃什么，有啥吃啥被。

早餐为什么最后说，因为公司的早餐在早上八点之前供应，八点半上班。。。有点难受啊。

幸好公司提供简单的零食，面包、火腿肠、泡面等等，虽然偶尔会被大家抢空，但是总比没有强吧。

行

上家公司离我家只有1公里的距离，所以从回到哈尔滨也没有买车，每天不行上班，还挺惬意的。

现在不行了，新公司距离家里有十好几公里，当然我也暂时没有选择买车，地铁出行，快捷方便，还省心，唯一的缺点就是要走个1.5公里吧。

在晚上八点之后打车可以报销的，但是只能是网约车，可能是出租车的票，粘贴太过麻烦了吧。反正我是不打车，因为我嫌报销麻烦。

工具

啥是工具呢，对程序员来说就是电脑了，公司提供电脑，也可以自己买电脑进行报销，还是很人性化地。

公司的会议室设施还是不错的，各种投屏等等，比较先进，完全摒弃了传统的投影仪等等，这还让我对公司有种另眼相看的感觉。

还提供显示器什么的，自己申请就好了。

入职感受

我面试的岗位是java开发，常规的java框架使用起来都没有问题。面试过程还是比较简单的，主要是常用的一些组件，简单的实现原理等等，所以顺利通过了。

但是比较遗憾的公司给我砍了一些，定位的职级也不是很高。说实话我还是有点难受的，毕竟整个面试过程，和我对个人的能力认知还是比较清楚地。

但是当我入职后我明白了，这里毕竟是哈尔滨，收入和年龄还是有很大的关系的。部门内有好几位大哥，想想也就释然了，在其位谋其政吧，他们的工作确实我我接下来要做的繁琐。希望日后能够慢慢的升职加薪吧。

总体来说，东北人还是敞亮，有事直接提，工作也没啥拐弯抹角的，干就完了。我才刚来公司第一天，就给我把工作安排上了，一点不拿我当外人啊。

工作感受

既然谈到工作了，就展开说说。

我第一天到公司，找了个临时工位，领导们各种git账号、禅道账号就给我创建好，一个项目扔给我，本月中期要求做完。。我当时内心的想法真的是：东北人果然是好相处啊，整的跟老同事似的。我能怎么办，干就完了啊。

项目还是很简单的，常规的springboot + mybatis + vue2的小项目，大概也没到月中期，一个礼拜就完事了。

比较让我惊喜的是部署的环节。居然使用的是devops工具KubeSphere。我只说这一句你们可能不理解，这是我在哈尔滨的第三家公司，从来没有一家公司说使用过k8s，甚至相关的devops工具。只能说是哈尔滨软件行业的云化程度还是太低了。唯一在上家公司的jenkins还是因为我想偷懒搭建的。

不过运维相关的内容都把握在运维人员手里，所以想要料及并且掌握先关的知识还是要自己私下去学习的。

项目其实都是小项目，以web端和app为主，基本都是前后端分离的单体架构。唯一我接触到的微服务架构应该就是公司的中台，提供统一的权限配置和登录认证，整体还是很不错的。

虽然公司的项目很多，工作看起来很忙碌，但实际还是比较轻松愉快的，我还能应付自如。每天晚上为了蹭一顿晚饭，通常会加班到七点半。用晚上这个时间更更文，也挺好的。

从体来说，是我比较喜欢的工作节奏。

个人分析

我是一个不太安定的人，长期干一件事会让我比较容易失去兴趣，还是挺享受刚换工作时，这段适应环境的感觉。也有可能更喜欢这种有一定挑战的感觉。

和上一家公司相比，这家公司在公司的时间明显多出很多，也没有那么悠闲了，但是我却觉得这更适合我，毕竟我是一个闲不住的人，安逸的环境让我感到格外的焦虑，忙碌的生活会让自己感到生活很充实。

记得之前的文章说过自己的身体健健的不太好，但是最近不知道是上班的路程变远，导致运动量的增加，之前不适的症状似乎都小时了。真闲出病来了！

既来之，则安之，时刻提醒自己再努力点，阳光总在风雨后。

在本文中，我们将介绍 10 多个最好的 IntelliJ IDEA 插件，以提高工作效率并在更短的时间内完成更多工作。如果将这些插件合并到您的工作流程中，您将能够更有效地应对开发挑战。

1、TabNine

TabNine 是一个 IntelliJ IDEA 插件，可以为 Java 和 JavaScript 开发人员的代码提供 AI 建议。它分析来自数百万个开源项目的代码，并提供相关且准确的代码片段，以帮助开发人员更快、更准确地编写代码。

使用 TabNine 的众多优势包括：

1. 有效的代码提示。


2. 支持大量编程语言。


3. 为主流编辑器和IDE提供帮助。


4. 使用机器学习，记住你经常写的代码，并提供极其详细的提示。

地址：plugins.jetbrains.com/plugin/1279…

2、RestfulToolkit

RestfulToolkit 提供了与 RESTful API 交互的有用工具。开发人员可以使用此插件直接从 IDE 轻松测试、调试和管理 RESTful API 请求，从而提高他们的整体效率和生产力。

该插件与 HTTP Client、REST Assured 等流行工具集成，使其成为 RESTful API 开发的完整解决方案。

地址：plugins.jetbrains.com/plugin/1029…

3、MyBatisCodeHelperPro

MyBatisCodeHelperPro 在使用 MyBatis 框架时提高了开发人员的工作效率。它包括代码生成和实时模板，使编写和管理 MyBatis 代码更加容易，节省时间和精力。

此外，该插件支持数据库架构同步和 SQL 文件生成，提高开发效率。

地址：plugins.jetbrains.com/plugin/9837…
dehelperpro

4、CodeGlance

CodeGlance 为开发人员提供了代码右侧添加了简明概览，使他们更容易浏览和理解代码。

地址：plugins.jetbrains.com/plugin/7275…

可以看到在上图右侧区域有一个代码概览区域，并且可以上下滑动。

5、GenerateAllSetter

GenerateAllSetter 有助于为类中的所有属性生成 setter 方法。这可以在编写代码时节省时间和精力，同时也降低了出错的可能性。

地址：plugins.jetbrains.com/plugin/9360…

6、Lombok

Lombok：一个自动生成样板代码的 Java 库。

Project Lombok 是一个 java 库，可自动插入您的编辑器和构建工具，为您的 java 增添趣味。永远不要再写另一个 getter 或 equals 方法，通过一个注解，您的类就有一个功能齐全的构建器，自动化您的日志变量，等等。

地址：projectlombok.org/

需要注意的就是在使用了在 IDEA 中使用 Lombok 插件记得启用 Enable annotation processing

7、Rainbow Brackets

该插件为代码的方括号和圆括号着色，从而更容易区分不同级别的代码块。

地址：plugins.jetbrains.com/plugin/1008…


可以看到添加彩色方括号后，代码可读性有所提高。

8、GitToolBox

它包括许多额外的功能和快捷方式，使开发人员更容易使用 Git。使用 GitToolBox 的众多优点包括：

1. GitToolBox 在 IntelliJ IDEA 上下文菜单中添加了几个快速操作，允许您在不离开 IDE 的情况下执行常见的 Git 任务。


2. Git 控制台：该插件向 IntelliJ IDEA 添加了一个 Git 控制台，允许您在 IDE 中使用 Git。


3. GitToolBox包含了几个解决合并冲突的工具，可以更容易地解决冲突并保持你的代码库是最新的。


4. Git stash management：该插件添加了几个用于管理Git stashes的工具，使保存和重新应用代码更改变得更加容易。

地址：plugins.jetbrains.com/plugin/7499…

9、Maven Helper

Maven Helper 提供了一种更方便的方式来处理 Maven 项目。

Maven Helper 是一个帮助开发人员完成 Maven 构建过程的工具。该插件包括用于管理依赖项、插件和配置文件的功能，例如查看、分析和解决冲突以及运行和调试特定 Maven 目标的能力。

这可以通过减少花在手动配置和故障排除任务上的时间，使开发人员有时间进行编码和创新，从而提高生产力。

地址：plugins.jetbrains.com/plugin/7179…

10、Sonarlint

Sonarlint 是一个代码质量检测工具，集成了 SonarQube 以动态检测和修复代码质量问题。

Sonarlint 提供实时反馈和建议，帮助开发人员提高代码质量。它集成了 SonarQube 代码分析平台，允许开发人员直接在他们的 IDE 中查看代码质量问题。

这通过在潜在问题到达构建和测试阶段之前检测它们来节省时间并提高效率。 Sonarlint 还可以帮助开发人员遵守最佳实践和编码标准，从而生成更易于维护和更健壮的代码。

地址：plugins.jetbrains.com/plugin/7973…

在Flutter中创建单例可以使用Dart语言中的静态变量和工厂方法的组合来实现。下面是一个示例代码：

class MySingleton {

  // 静态变量

  static final MySingleton _singleton = MySingleton._internal();

  

  // 工厂方法

  factory MySingleton() {

    return _singleton;

  }



  // 私有构造函数

  MySingleton._internal();

  

  // 其他方法

  void doSomething() {

    print("Doing something...");

  }

}

在上面的代码中，MySingleton类有一个私有的构造函数，这意味着它不能直接实例化。

相反，它使用一个静态变量 _singleton 来存储唯一的实例，并使用一个工厂方法来获取该实例。因此，当您需要引用该单例时，您只需调用 MySingleton() 方法，就可以得到唯一的实例。

要使用该单例，只需调用 MySingleton() 方法，并调用其公共方法，如 doSomething() ：

MySingleton mySingleton = MySingleton();

mySingleton.doSomething();

Flutter单例模式可以在以下场景中使用：

1. 网络请求：在网络请求过程中，您可能只需要一个单例来管理所有的HTTP客户端和连接。使用单例模式可以确保只有一个实例在整个应用程序中被创建和使用，这样可以节约系统资源并避免重复创建相同的实例。


2. 数据库操作：在应用程序中，您可能需要与数据库进行交互。使用单例模式，您可以确保只需要一个单例来管理数据库连接并执行所有数据库操作。


3. 状态管理：在Flutter中，您可以使用单例模式来管理应用程序状态。您可以创建一个具有全局作用域的单例，以存储和管理应用程序中的状态，并确保在整个应用程序中只有一个实例在使用。


4. 全局管理：在某些情况下，您可能需要在整个应用程序中共享某些对象或数据。使用单例模式，您可以创建一个具有全局作用域的单例来存储这些对象和数据，并确保在整个应用程序中只有一个实例在使用。 在这些场景中，使用单例模式可以简化代码并提高应用程序性能，避免了创建多个重复的对象的开销。

之前我们讲过因为事件没有得到及时处理，引起的ANR问题。但这只是Input Dispatching Timeout中的一种情况，还有一种情况，在我们应用中出现的也很常见，就是No Focused Window ANR，这个又是在哪些情况下产生的呢？

由之前的文章，我们知道，点击事件都是由InputDispatcher来分发的，我们直接来看InputDispatcher的源码。

No Focused Window ANR如何产生

如果是Key事件，或Motion事件，都需要找到焦点窗口取处理，都会调用到findFocusedWindowTargetsLocked()。

// frameworks/native/services/inputflinger/dispatcher/InputDispatcher.cpp

int32_t InputDispatcher::findFocusedWindowTargetsLocked(nsecs_t currentTime,

                                                        const EventEntry& entry,

                                                        std::vector<InputTarget>& inputTargets,

                                                        nsecs_t* nextWakeupTime) {

    std::string reason;



    int32_t displayId = getTargetDisplayId(entry);

    // mFocusedWindowHandlesByDisplay在setInputWindowsLocked()里赋值

    sp<InputWindowHandle> focusedWindowHandle =

            getValueByKey(mFocusedWindowHandlesByDisplay, displayId);

    // mFocusedApplicationHandlesByDisplay在setFocusedApplication()里赋值

    sp<InputApplicationHandle> focusedApplicationHandle =

            getValueByKey(mFocusedApplicationHandlesByDisplay, displayId);



    // focusedWindowHandle和focusedApplicationHandle都为空时表示当前无窗口，该事件会被丢弃，不会执行dispatchEventLocked

    // 一般出现两个都为空的场景，是在窗口切换的过程，此时不处理事件注入

    if (focusedWindowHandle == nullptr && focusedApplicationHandle == nullptr) {

        return INPUT_EVENT_INJECTION_FAILED;

    }



    // focusedWindowHandle为空但focusedApplicationHandle不为空时开始ANR检查

    if (focusedWindowHandle == nullptr && focusedApplicationHandle != nullptr) {

        // 默认mNoFocusedWindowTimeoutTime没有值，第一次检查ANR会走下面这个流程

        if (!mNoFocusedWindowTimeoutTime.has_value()) {

            // DEFAULT_INPUT_DISPATCHING_TIMEOUT = 5s * HwTimeoutMultiplier();

            // 默认input dispatch timeout时间时5s

            const nsecs_t timeout = focusedApplicationHandle->getDispatchingTimeout(

                    DEFAULT_INPUT_DISPATCHING_TIMEOUT.count());

            // 给mNoFocusedWindowTimeoutTime赋值，触发ANR时会检查这个值是否为空，不为空才触发ANR

            mNoFocusedWindowTimeoutTime = currentTime + timeout;

            // 把当前的focusedApplicationHandle赋值给mAwaitedFocusedApplication，触发ANR时会检查这个值是否为空，不为空才触发ANR

            mAwaitedFocusedApplication = focusedApplicationHandle;

            mAwaitedApplicationDisplayId = displayId;

            *nextWakeupTime = *mNoFocusedWindowTimeoutTime;

            // 返回INPUT_EVENT_INJECTION_PENDING表示dispatchKeyLocked()或者dispatchMotionLocked()为false

            return INPUT_EVENT_INJECTION_PENDING;

        } else if (currentTime > *mNoFocusedWindowTimeoutTime) {

            // Already raised ANR. Drop the event

            return INPUT_EVENT_INJECTION_FAILED;

        } else {

            // Still waiting for the focused window

            return INPUT_EVENT_INJECTION_PENDING;

        }

    }



    // 如果走到这个流程，说明没有ANR，清空mNoFocusedWindowTimeoutTime和mAwaitedFocusedApplication

    resetNoFocusedWindowTimeoutLocked();

    return INPUT_EVENT_INJECTION_SUCCEEDED;

}

主要逻辑：

• 如果focusedWindowHandle和focusedApplicationHandle都为null，一般发生在窗口切换的时候，返回INPUT_EVENT_INJECTION_FAILED，直接drop事件，不做处理


• 如果focusedWindowHandle为null，focusedApplicationHandle不为null，返回INPUT_EVENT_INJECTION_PENDING，在nextWakeupTime之后唤醒，检查是否发生ANR
  
  
  
  • mNoFocusedWindowTimeoutTime：记录no focused window timeout的时间
  
  
  • mAwaitedFocusedApplication：记录focusedApplicationHandle
  
  
  • nextWakeupTime: 下次唤醒pollInner的时间
  
  
  
  

接下来看看检查ANR的逻辑：

// frameworks/native/services/inputflinger/dispatcher/InputDispatcher.cpp

nsecs_t InputDispatcher::processAnrsLocked() {

    const nsecs_t currentTime = now();

    nsecs_t nextAnrCheck = LONG_LONG_MAX;

    // 在findFocusedWindowTargetsLocked()中，如果focusedWindowHandle为空，focusedApplicationHandle不为空，以下条件就会满足

    if (mNoFocusedWindowTimeoutTime.has_value() && mAwaitedFocusedApplication != nullptr) {

        // mNoFocusedWindowTimeoutTime为检查时间+5s，如果currentTime大于等于mNoFocusedWindowTimeoutTime，表示超时

        if (currentTime >= *mNoFocusedWindowTimeoutTime) {

            // 触发ANR流程，此处触发的ANR类型是xxx does not have a focused window

            processNoFocusedWindowAnrLocked();

            // 清空mAwaitedFocusedApplication，下次就不会再走ANR流程

            mAwaitedFocusedApplication.clear();

            mNoFocusedWindowTimeoutTime = std::nullopt;

            return LONG_LONG_MIN;

        } else {

            // Keep waiting

            const nsecs_t millisRemaining = ns2ms(*mNoFocusedWindowTimeoutTime - currentTime);

            ALOGW("Still no focused window. Will drop the event in %" PRId64 "ms", millisRemaining);

            // 还没有超时，更新检查时间

            nextAnrCheck = *mNoFocusedWindowTimeoutTime;

        }

    }

    ....

    // 如果走到这个流程，ANR类型是xxx is not responding. Waited xxx ms for xxx

    // 这个地方，focusedWindowHandle和focusedApplicationHandle都是不为空的场景

    onAnrLocked(*connection);

    return LONG_LONG_MIN;

}

主要流程:

• 如果mNoFocusedWindowTimeoutTime有值，且mAwaitedFocusedApplication不为空
  
  
  
  • 超时：调用processNoFocusedWindowAnrLocked触发ANR
  
  
  • 未超时：更新检查时间
  
  
  
  


• 继续检查input事件是否超时，如果超时，则调用onAnrLocked触发ANR

接下来，我们看看processNoFocusedAnrLocked的流程：

// frameworks/native/services/inputflinger/dispatcher/InputDispatcher.cpp

void InputDispatcher::processNoFocusedWindowAnrLocked() {

    // 在触发ANR前，再获取一次当前的focusedApplication

    sp<InputApplicationHandle> focusedApplication =

            getValueByKey(mFocusedApplicationHandlesByDisplay, mAwaitedApplicationDisplayId);

    // 检查触发ANR时的条件是focusedApplication不为空

    // 如果此时focusedApplication为空，或者focusedApplication不等于前一个mAwaitedFocusedApplication表示已经切换application focus，取消触发ANR

    if (focusedApplication == nullptr ||

        focusedApplication->getApplicationToken() !=

                mAwaitedFocusedApplication->getApplicationToken()) {

        return; // The focused application has changed.

    }

    // 在触发ANR前，再获取一次当前的focusedWindowHandle 

    const sp<InputWindowHandle>& focusedWindowHandle =

            getFocusedWindowHandleLocked(mAwaitedApplicationDisplayId);

    // 检查触发ANR时focusedWindowHandle为空，如果此时focusedWindowHandle不为空，取消触发ANR

    if (focusedWindowHandle != nullptr) {

        return; // We now have a focused window. No need for ANR.

    }

    // 通过前面的判断，还是无法拦截，说明该ANR无可避免，最终触发ANR

    // 早期代码没有前面一系列的判断，是直接触发的ANR，会在性能较差的场景下出现误判

    onAnrLocked(mAwaitedFocusedApplication);

}

主要流程：

• 在这个方法里面，再次检查focusedApplication
  
  
  
  • 如果当前focusedApplication为空，或者和之前记录的mAwaitedFocusedApplication不一致，则说明窗口已经切换，不需要报ANR
  
  
  
  


• 再次检查focusedWindow是否未空
  
  
  
  • 如果不为空，则不需要报ANR
  
  
  
  


• 检查都通过之后，才会调用onAnrLocked，报no Focused Window ANR

focusedApplication设置流程