Update

blogs/Android/口水话/Gradle.md

@@ -28,9 +28,9 @@ Execution 阶段才真正进行任务的执行。Gradle 会按照 task graph 中
 
 考虑到后面可能还会有一些类似的需求，于是我就写了一个插件。我觉得这是一个非常好的开端，之所以当初组长找到我做这件事是因为我之前在组内分享了 Gradle 的相关知识，包括 Gradle 的构建流程、Gradle 的核心概念 Task 以及利用 Transform API 结合 AspectJ、ASM 进行自动化埋点等。这对我来说呢是一个正向激励，后面我也越来越会做更多的分享。
 
-后面呢，我还在 Plugin 里面添加了自动 TinyPng 资源压缩，考虑到我们的 minApi 19，又做了全量的 png 转 webp 这一步的压缩是包含第三方库里面的图片的，使用的是 Google 开源的 cwebp 工具。通过 png 转 webp，减少了 5.7M，再来做包体积优化时，发现存在不少的重复资源，也就是遍历生成 MD5 值进行比较，减少了 133 kb；通过配置 resConfigs 只保留 zh、en 减少了 1.1M。
+后面呢，我还在 Plugin 里面添加了自动 TinyPng 资源压缩，考虑到我们的 minApi 19，又做了全量的 png 转 webp 这一步的压缩是包含第三方库里面的图片的，使用的是 Google 开源的 cwebp 工具。通过 png 转 webp，减少了 5.7M，再后来做包体积优化时，发现存在不少的重复资源，也就是遍历生成 MD5 值进行比较，减少了 133 kb；通过配置 resConfigs 只保留 zh、en 减少了 1.1M。
 
-再之后，基于做了 MethodTracker，简单使用一个注解就可以查看方法耗时，还有基于 Choreographer 的 FPS 检测。这里当时是遇到一个问题的，我们知道插件里面的类，在外部模块是不能访问到的，然而我这里的注解以及 FPSDetector 都是需要在 app 模块使用的，这时候我就看了 JW 的 Hugo 的实现，它也是基于 AspectJ 做的方法耗时，因为它的注解也是可以在 app 模块使用的，看源码发现它不过是是把这个注解放到外部一个远程库的，然后在插件里面进行依赖的。Hugo 仅仅只有四个类，却有 7k 多的 Star，所以说有时候不能被表面吓着，以为会很麻烦其实很简单。
+再之后，基于 ASM 做了 MethodTracker，简单使用一个注解就可以查看方法耗时，还有基于 Choreographer 的 FPS 检测。这里当时是遇到一个问题的，我们知道插件里面的类，在外部模块是不能访问到的，然而我这里的注解以及 FPSDetector 都是需要在 app 模块使用的，这时候我就看了 JW 的 Hugo 的实现，它也是基于 AspectJ 做的方法耗时，因为它的注解也是可以在 app 模块使用的，看源码发现它不过是是把这个注解放到外部一个远程库的，然后在插件里面进行依赖的。Hugo 仅仅只有四个类，却有 7k 多的 Star，所以说有时候不能被表面吓着，以为会很麻烦其实很简单。
 
 在我写 Plugin 的之后，滴滴开源了 Booster，然后我就按照它的架构方式，使用 SPI 去自动注册 Task，这就不需要每新增一个 Task 都要去 apply 方法进行注册了。当时是用 Java 写的，也都切成了 Kotlin，并且也用的 kts 构建。
 

blogs/Android/口水话/View 体系相关口水话.md

@@ -21,7 +21,7 @@ WMS 是所有 Window 窗口的管理者，它负责 Window 的添加和删除、
 
 接下来就是正式绘制 View 了，从 performTraversals 开始，Measure、Layout、Draw 三步走。
 
-第一步是获取 DecorView 的宽高的 MeasureSpec 然后执行 performMeasure 流程。MeasureSpec 简单来说就是一个 int 值，高 2 位表示测量模式，低 30 位用来表示大小。策略模式有三种，EXACTLY、AT_MOST、UNSPECIFIED。EXACTLY 对应为 match_parent 和具体数值的情况，表示父容器已经确定 View 的大小；AT_MOST 对应 wrap_content，表示父容器规定 View 最大只能是 SpecSize；UNSPECIFIED 表示不限定测量模式，父容器不对 View 做任何限制，这种适用于系统内部。接着说，performMeasure 中会去调用 DecorView 的 measure 方法，这个是 View 里面的方法并且是 final 的，它里面会把参数透传给 onMeasure 方法，这个方法是可以重写的，也就是我们可以干预 View 的测量过程。在 onMeasure 中，会通过 getDefaultSize 获取到宽高的默认值，然后调用 setMeasureDimension 将获取的值进行设置。在 getDefaultSize 中，无论是 EXACTLY 还是 AT_MOST，都会返回 MeasureSpec 中的大小，这个 SpecSize 就是测量后的最终结果。至于 UNSPECIFIED 的情况，则会返回一个建议的最小值，这个值和子元素设置的最小值以及它的背景大小有关。从这个默认实现来看，如果我们自定义一个 View 不重写它的 onMeasure 方法，那么 warp_content 和 match_parent 一样。所以 DecorView 重写了 onMeasure 函数，它本身是一个 FrameLayout，所以最后也会调用到 FrameLayout 的 onMeasure 函数，作为一个 ViewGroup，都会遍历子 View 并调用子 View 的 measure 方法。这样便实现了层层递归调用到了每个子 View 的 onMeasure 方法进行测量。
+第一步是获取 DecorView 的宽高的 MeasureSpec 然后执行 performMeasure 流程。MeasureSpec 简单来说就是一个 int 值，高 2 位表示测量模式，低 30 位用来表示大小。测量模式有三种，EXACTLY、AT_MOST、UNSPECIFIED。EXACTLY 对应为 match_parent 和具体数值的情况，表示父容器已经确定 View 的大小；AT_MOST 对应 wrap_content，表示父容器规定 View 最大只能是 SpecSize；UNSPECIFIED 表示不限定测量模式，父容器不对 View 做任何限制，这种适用于系统内部。接着说，performMeasure 中会去调用 DecorView 的 measure 方法，这个是 View 里面的方法并且是 final 的，它里面会把参数透传给 onMeasure 方法，这个方法是可以重写的，也就是我们可以干预 View 的测量过程。在 onMeasure 中，会通过 getDefaultSize 获取到宽高的默认值，然后调用 setMeasureDimension 将获取的值进行设置。在 getDefaultSize 中，无论是 EXACTLY 还是 AT_MOST，都会返回 MeasureSpec 中的大小，这个 SpecSize 就是测量后的最终结果。至于 UNSPECIFIED 的情况，则会返回一个建议的最小值，这个值和子元素设置的最小值以及它的背景大小有关。从这个默认实现来看，如果我们自定义一个 View 不重写它的 onMeasure 方法，那么 warp_content 和 match_parent 一样。所以 DecorView 重写了 onMeasure 函数，它本身是一个 FrameLayout，所以最后也会调用到 FrameLayout 的 onMeasure 函数，作为一个 ViewGroup，都会遍历子 View 并调用子 View 的 measure 方法。这样便实现了层层递归调用到了每个子 View 的 onMeasure 方法进行测量。
 
 第二步是执行 performLayout 的流程，也就是调用到 DecorView 的 layout 方法，也就是 View 里面的方法，如果 View 大小发生变化，则会回调 onSizeChanged 方法，如果 View 状态发生变化，则会回调 onLayout 方法，这个方法在 View 中是空实现，因此需要看 DecorView 的父容器 FrameLayout 的 onLayout 方法，这个方法就是遍历子 View 调用其 layout 方法进行布局，子 View 的 layout 方法被调用的时候，它的 onLayout 方法又会被调用，这样就布局完了所有的 View。
 

blogs/Android/口水话/四大组件的启动流程口水话.md

@@ -19,7 +19,7 @@ Launcher 组件是如何获取这些信息的呢？其实是在系统启动时
 
 在 Instrumentation 的 execStartActivity 中，通过 ActivityManagerNative 的 getDefault 获取 AMS 的一个代理对象，实际上就是调用 ServiceManager 的 getService，获取的是一个 IActivityManager 接口，这也是一个 Hook 点。然后就调到了它的实现类 ActivityManagerProxy 中的 startActivity 方法，在这个方法中，就会往 AMS tranact 一个 START_ACTIVITY_TRANSACTION 的请求。
 
-在 AMS 收到这个请求时，就会让 ActivityStack 去处理。它首先根据上面传递过来的 ApplicationThread 去通知 Launcher 所在的应用程序进程去暂停 Launcher 组件，也就是回调到 ActivityThread 的内部类 ApplicationThread 的 schedulePauseActivity，往主线程发送一个 PAUSE_ACTIVITY 消息，mH 进行处理执行 handlePauseActivity。这个方法先调用 Activity 的 onPause 函数，然后执行 QueuedWork 里面的一些数据写入操作，SharedPreferences 的 apply 就会丢在这执行，如果数据量毕竟大的话可能会造成 ANR 的。最后就是通知 AMS Launcher 组件已经暂停完成了。
+在 AMS 收到这个请求时，就会让 ActivityStack 去处理。它首先根据上面传递过来的 ApplicationThread 去通知 Launcher 所在的应用程序进程去暂停 Launcher 组件，也就是回调到 ActivityThread 的内部类 ApplicationThread 的 schedulePauseActivity，往主线程发送一个 PAUSE_ACTIVITY 消息，mH 进行处理执行 handlePauseActivity。这个方法先调用 Activity 的 onPause 函数，然后执行 QueuedWork 里面的一些数据写入操作，SharedPreferences 的 apply 就会丢在这执行，如果数据量比较大的话可能会造成 ANR 的。最后就是通知 AMS Launcher 组件已经暂停完成了。
 
 再回到 AMS 中，就开始真正的去启动 MainActivity 了，首先检查这个 Activity 对应的 ActivityRecord 对象所在的应用程序进程是否已经存在，如果存在就直接执行 realStartActivityLocked，如果不存在就先 startProcessLocked 去创建一个应用程序进程。创建应用程序进程即调用 Porcess start 函数，并指定该进程的入口函数为 ActivityThread，这一步其实是请求 Zygote fork 出一个应用程序进程。在 ActivityThread 的 main 函数中，创建消息循环，并且调用 attachApplication 把当前的 ApplicationThread 对象传递给 AMS，AMS 有了它就可以去通知应用程序去执行 MainActivity 的 onCreate 方法了。同上述执行 Launcher 的 onPause 函数一样，也是发一个消息给主线程，调用 handleLauncherActivity。
 

blogs/Java/口水话/集合源码.md

@@ -6,7 +6,7 @@
 
 起初想看集合源码是因为，一次偶然的机会，一位同事跟我说 ArrayList 的初始容量为空，第一次 add 时才会扩容至 10。我当时就觉得我的知识体系有点落后了，就决定去看一遍集合源码。在看的过程中呢，可以用惊喜+收获满满来形容了。惊喜是指对于 Stack、HashSet、LinkedHashMap 等等的实现方式感觉很震惊，看完这些集合源码有种那种你感觉很难但是其实很简单的感觉，不仅如此，熟悉集合源码对实际开发也是有帮助的，主要体现在 ArrayList remove 时可能抛出的 ConcurrentModificationException、Collections 使用不当造成的 UnsupportedOperationException、ArrayMap 的缓存机制等等。
 
-在看集合源码时，Debug 源码有时并不直接，可以使用 OpenJDK 开源的 JOI 工具查看对象的内存布局，这对分析集合扩容、HashMap 树化非常有用。
+在看集合源码时，Debug 源码有时并不直接，可以使用 OpenJDK 开源的 JOL 工具查看对象的内存布局，这对分析集合扩容、HashMap 树化非常有用。
 
 #### 目录
 

blogs/computer_network/口水话/HTTP、HTTPS、HTTP2.md

@@ -46,5 +46,5 @@ TLS1.3 在 2018 年正式发布，它移除了很多已证明不安全的套件
 
 HTTP2 有三个核心概念，Strem 流、Message 消息、Frame 帧。在一个 TCP 连接上可以有多个流，也就是并发多请求，实现多路复用；以前浏览器是只能对一个域名开启 6 个并发链接；同时流还可以设置优先级，让服务器优先处理；一条流上可以有多个 Message 消息，每个 Message 都可以携带多个 Frame 帧，帧类型包括 HEADER 帧和 DATA 帧，也就对应于 HTTP/1.1 中的 header 和 data。在 HTTP/1.1 中，服务端是没法主动向客户端推送信息的，客户端只能以轮询的方式去请求，在 HTTP2 中有了服务器推送，也就是服务端可以提前将资源推送至浏览器缓存。
 
-HTTP2 只在应用层解决了队头阻塞问题，并未在 TCP 层解决队头阻塞问题。TCP 的报文传输时无序，接收时组装。如果队头包没有到达，即使后序数据包已经接受到了也是没办法交给上层应用程序处理的，只能等待重发。而在 HTTP3 采用了 UDP，UDP 先天没有队列的概念，自然就解决了队头阻塞的问题，但是它仍然保留了 TCP 的可靠性，这也需要 QUIC 协议自己去实现重传机制、拥塞控制等机制。
+HTTP2 只在应用层解决了队头阻塞问题，并未在 TCP 层解决队头阻塞问题。TCP 的报文传输时无序，接收时组装。如果队头包没有到达，即使后序数据包已经接收到了也是没办法交给上层应用程序处理的，只能等待重发。而在 HTTP3 采用了 UDP，UDP 先天没有队列的概念，自然就解决了队头阻塞的问题，但是它仍然保留了 TCP 的可靠性，这也需要 QUIC 协议自己去实现重传机制、拥塞控制等机制。