tmacfrank

约束布局核心要点摘要 约束布局是Android Studio 2.3后推荐的默认布局方式，相比传统相对布局具有显著优势： 性能优化：通过单层扁平化结构减少嵌套层级，有效提升渲染性能 功能强大：支持角度定位、百分比布局和基线对齐等高级特性 开发效率：2小时掌握即可长期受益，主流应用已验证其可靠性 布局方式： 支持双向约束定位（水平和垂直） 提供权重分配功能（需设置0dp并配置weight属性） 可实现精准的文本基线对齐 兼容建议：简单布局仍可用线性/帧布局，复杂场景优先采用约束布局替代相对布局 核心价值：专为

本文继续解析OkHttp的剩余四个拦截器。桥接拦截器(BridgeInterceptor)自动处理HTTP请求头等繁琐工作，如设置内容长度、编码、Cookie等，并支持gzip压缩。缓存拦截器(CacheInterceptor)基于HTTP缓存头实现缓存机制，通过CacheStrategy决定使用缓存还是发起网络请求。CacheStrategy根据networkRequest和cacheResponse的状态组合来决定请求策略，由CacheStrategy.Factory负责生成具体策略对象。

本文介绍了网络分层架构与TCP/IP协议族。首先对比了OSI七层模型与TCP/IP四层模型，解释了分层设计的优势：降低复杂性、模块化开发、职责明确、标准化和故障隔离。重点分析了TCP/IP协议族的分层结构，包括链路层、网络层、传输层和应用层的数据封装过程。文章对比了TCP与UDP的特性，TCP提供可靠传输而UDP更轻量。最后说明IP地址的作用及其与MAC地址的区别。作为网络基础，该内容为后续理解HTTPS协议奠定了基础。

今天要讲解数据表示与安全处理范畴内的概念：编码、序列化、哈希、加密。它们的核心是如何将信息在不同形式、场景下安全高效地转换与传输，为 HTTPS 加密通信的学习奠定基础。

本文系统介绍了Android应用性能优化中的ANR问题，包括ANR概念、4种类型（Input事件、广播、服务和ContentProvider超时）及产生原因（如主线程IO操作、死锁等）。重点讲解了ANR问题的线下分析方法，包括3种关键日志文件的使用和线程状态分析技巧，并提供了两种线上监控方案：FileObserver监听/data/anr目录变化和WatchDog机制。文章还特别强调了面试时应先讲整体分析思路再展开细节的应对策略。

上一篇我们详解了 OkHttp 的众多配置，本篇来看 OkHttp 是如何通过责任链上的内置拦截器完成 HTTP 请求与响应的，目的是更好地深入理解 HTTP 协议。这仍然是一篇偏向于协议实现向的文章，重点在于 HTTP 协议的实现方法与细节，关于责任链模式这些设计模式相关的内容，由于与 HTTP 协议关联不大，因此只是有所提及但不会着重讲解。

前面两篇文章我们介绍了 HTTP 协议的请求方法、请求码以及常用的请求头/响应头的知识。本篇会从 OkHttp 配置的角度来看这些框架是如何实现 HTTP 协议的，目的是加深对 HTTP 的理解，并学习协议是如何落地的。我们会选取 OkHttp 中与协议实现相关的源码作为切入点，而不是去全面地分析这两个框架的源码。

身份认证本质：确认"你是你"的过程，通过用户名密码验证建立屏幕前用户与账户所有者的关联验证流程：用户输入凭证→服务器验证→确认身份→赋予账户权限权限特点：登录后获得的权限是直接赋予用户自身，不涉及第三方令牌核心概念：将特定权限通过象征性令牌授予第三方令牌形式：可以是授权文件、授权码（token）等数字凭证经典案例：尚方宝剑比喻皇上（授权方）→包青天（持有方）→尚方宝剑（令牌）实现效果：持有令牌者可执行超出原有权限的操作（如斩杀高官）

本文介绍了HTTP协议的基本原理与工作机制、请求方法与状态码、以及Header与Body的结构。HTTP（超文本传输协议）最初用于传输HTML文档，通过URL定位资源，基本工作流程包括客户端发送请求、服务器处理并返回响应。请求报文由请求行、请求头和请求体组成，响应报文包含状态码和响应体。常用的请求方法包括GET、POST、PUT、DELETE和HEAD，状态码分为1xx（临时消息）、2xx（成功）、3xx（重定向）、4xx（客户端错误）和5xx（服务器错误）。Header用于描述核心数据的属性，如Host和

首先，在 LeakCanary 的部分模块的 AndroidManifest.xml 中会声明一些 Provider，这些 Provider 在 apk 打包时会汇入 mergeAndroidManifest.xml，最后体现在 app 的 AndroidManifest.xml 文件中。A~G 每个对象都占 10 个内存单位，它们的浅堆都是 10，但是 B、C 的深堆就要计算上各自分支上的对象总和，即 30，而 A 要计算分支上所有对象的内存总和，即 70。

一款 app 除了要有令人惊叹的功能和令人发指交互之外，在性能上也应该追求丝滑的要求，这样才能更好地提高用户体验，响应速度一项就主要取决于数据结构和算法。

前面我们讲了很多半自动化 API 进行手势识别，那些 API 可以覆盖绝大多数的使用场景。本节我们来介绍，如何通过底层 API 实现完全自定义的触摸算法。

)但是这样的话，在实现 modifyParentData() 的具体内容时，你需要去查阅 Box 的父组件 Row 的内部都用到了哪些 parentData，这是一件很麻烦的事情。因此，这种方式不可行。@Stable。

Compose 发展初期的几年，会是新的模块用 Compose 写，然后逐渐的把老界面从 View 替换成 Compose 组件，直到全部或几乎全部是 Compose 代码的模式。原生的 SurfaceView 与 TextureView 的重点是在它们底层的 Surface API，而不是 View 本身。Compose 并没有给出对等的实现，因此倘若你的项目中用到了它们，就仍需继续使用它们。这也是 View 到 Compose 的迁移到“几乎全部是 Compose 代码”的原因。

这里对以上内容就不再赘述了，直接去讲解更复杂的 Modifier 实现更复杂的触摸反馈效果。在传统的 View 体系中，在自定义触摸反馈的内容时，对于 View 我们通常都是重写它的 onTouchEvent()，对于 ViewGroup 可能还需要重写 onInterceptTouchEvent()，极少数时候会更深入地去重写 dispatchTouchEvent()。

自定义布局在 Compose 中相对于原生的需求已经小了很多，先讲二者在本质上的逻辑，再说它们的使用场景，两相对比就知道为什么 Compose 中的自定义布局的需求较小了。原生是在 xml 布局文件不太方便或者无法满足需求时才会在代码中通过自定义 View 的方式，重写 onMeasure() 或 onLayout()，或添加其他功能方法来实现需求。

不论是在传统的 View 体系下，还是在 Compose 中，“自定义 View” 都包含视图的测量、布局、绘制、触摸反馈以及动画。说到 Compose 的自定义绘制，Compose 提供了更加上层的 API，相比于原生的绘制 API 会更简单、更直接一些。比如原生的 Canvas 和 Paint 在 Compose 中进行正常绘制时是用不到的，只有在使用原生独有的绘制功能（比如多维旋转）时才需要下沉到原生这一层去使用它们。

Google 官方文档对 side effect 有两种翻译，简体中文翻译为附带效应，繁体中文翻译为副作用。本篇文章将全面介绍 Compose 的附带效应 API 的用法以及原理，帮助你区分不同 API 的使用场景。

addBeforeLayoutModifier() 与 addAfterLayoutModifier() 并不是指在 Modifier 链上先处理哪个或者后处理哪个具体的 Modifier，而是指同一个 Modifier 具有多重“身份”时，先/后处理哪个“身份”。

作用：ParentDataModifier 用于给子组件附加一些属性，让父组件可以利用用法：只有在通过 Layout() 写自定义函数时才会用到 ParentDataModifier，在测量与布局的算法中通过 Measurable 的 parentData 属性拿到这个数据后根据具体需求使用即可，最后要提供一个 Modifier 函数实现 ParentDataModifier，在 modifyParentData() 中根据需求提供附加数据。

每个 LayoutNodeWrapper 中的 entities 数组中的 DrawModifier 是伪造的，要不写在 Box() 的示例代码中会很占篇幅。LayoutNode 的 draw() 调用 outerLayoutNodeWrapper，也就是 LayoutNodeWrapper，在上面的层级图中的 ModifiedLayoutNode1 的 draw() 开始绘制。

前面几节讲的 Modifier 都是起辅助作用的，比如 Modifier 的伴生对象、CombinedModifier、 ComposedModifier 以及几乎所有 Modifier 的父接口 Modifier.Element。本篇我们开始讲具有直接功效的 Modifier，分为几个大类：LayoutModifier、DrawModifier 等。

从本篇文章开始我们要讲解 Modifier 修饰符，它是一个很精妙的东西，允许我们通过链式调用的方式为组件应用一系列的样式设置，如边距、字体、位移等。在 Compose 中，每个基础的 Composable 组件都有一个 modifier 参数，通过传入自定义的 Modifier 修改组件的样式。此外，前面我们还提过 Modifier 调用链对顺序敏感，不同的调用顺序会产生不同的 Modifier 链从而影响最终的 UI 效果，这是 Compose 按照 Modifier 链来顺序完成页面布局与绘制的结

本篇是动画的最后一篇，我们先介绍 Transition API，然后再介绍与 Transition 相关的三个上层 API：AnimatedVisibility()、Crossfade()、AnimatedContent()。

介绍 Compose 动画的各种 AnimationSpec。

现在在 Android 开发领域说的动画几乎就是属性动画。这节以 animateDpAsState() 为代表，介绍 animateXxxAsState() 这一系列函数。animateDpAsState() 已经包含了 mutableStateOf() 这种数据改变通知监听者的功能，同时还包含 remember() 防止多次初始化的功能，因此创建动画属性就不用 remember() 和 mutableStateOf() 了。

CompositionLocal 按照字面意思可直译为 Composition 的局部变量。User(name)name 变量只在 setContent() 后的代码块内有效，并且不能穿透到代码块调用的 User 函数之内。User()// 这里会报错的，User 函数的内部访问不到 name 变量Text(name)Compose 提供的 CompositionLocal 可以帮助我们突破这个限制，让通过 CompositionLocal 创建的局部变量具备穿透函数的能力。

Compose 官方称其是无状态的（Stateless），这个状态是指组件属性。比如说 TextView 内保存的文字内容就是一个状态，你可以通过 getText() 与 setText() 获取与设置文字。但在 Compose 中，组件没有状态，也就是其内部不会保存这些数据，在将数据设置到 UI 上之后，它们就被“扔掉了”。但需要注意的是，无状态作为 Compose 的一个特点，它是允许组件无状态，而不是说组件绝对没有状态。

本节主要概括性地介绍 Jetpack Compose 中的关键概念。

首先我们来看如何在 View 体系中集成 Compose。

Jetpack Compose 的主题是基于 Material Design 的，需要先了解一下。使用 Material Theme 就可以获取到 Material Design 的设计元素，如想使用其他设计风格需要自己定义主题。颜色：定义了许多语义命名的颜色，可在整个应用程序中使用。如 Color Scheme、Primary、Secondary 和 On Primary。

在科学技术中，状态指物质系统所处的状况，也指各种聚集态，如物质的固、液、气等态。当系统的温度、压力、体积、物态、物质的量、各种能量等等一定时，我们就说系统处于一个状态（state）。应用中的状态是指可以随时间变化的任何值，这是一个宽泛定义，从 Room 数据库到类的变量，全部涵盖在内。所有 Android 应用都会向用户显示状态。在无法建立网络连接时显示的信息提示控件（Toast 等）博文和相关评论在用户点击按钮时播放的波纹动画用户可以在图片上绘制的贴纸。

自定义版式。在 Compose 中，界面元素由可组合函数表示，此类函数在被调用后会发出一部分界面，这部分界面随后会被添加到呈现在屏幕上的界面树中。每个界面元素都有一个父元素，还可能有多个子元素。此外，每个元素在其父元素中都有一个位置，指定为 (x, y) 位置；也都有一个尺寸，指定为width和height。在界面树中布置每个节点的过程分为三个步骤。测量所有子项确定自己的尺寸放置其子项注意：Compose 界面不允许多遍测量。这意味着，布局元素不能为了尝试不同的测量配置而多次测量任何子元素。

本篇主要是对 Jetpack Compose 有一个宏观上的了解。

使用 WorkManager API 可以轻松地调度那些。通过这些 API，您可以创建任务并提交给 WorkManager，以便在满足工作约束条件时运行。

Sunflower 是 Google 官方提供的 Jetpack 练手项目，起初是用 Java 实现的，并逐步演进为现在的完全由 Kotlin 实现。它的页面如下：图一展示在“我的花园”中已经种植了哪些植物，点击左上角的菜单按钮会弹出图二的抽屉布局，菜单中有“我的花园”和“植物目录”两个选项，点击植物目录会进入图三展示所有植物种类的页面，点击某一种植物后会进入图四的植物详情页面，在该页面点击右下角按钮后会将其添加到图一“我的花园”页面中。本篇文章会介绍 Java 实现该 Demo 的过程。按照 Googl

整个异步执行的调用流程图如下：获取事务并添加操作，通过 FragmentTransaction.addToBackStack() 设置的事务会被加入回退栈，实际上是先设置 mAddToBackStack 标记位为 true事务异步提交后，进入执行阶段时，通过 Handler 在主线程执行 execPendingActions() 以执行 mPendingActions 中事务的操作时，会遍历 mPendingActions 中事务，并执行其 generateOps()

结合源码来看看 Fragment 的内部实现，主要从生命周期、事务机制与状态保存等方面进行分析。一、整体结构我们先来看看 Fragment 整体的代码结构，先说明下，我们看的是 Androidx 包下的 Fragment 源码，具体是 fragment-1.3.6-source.jar，一些实现跟传统版本差别很大，比如说 fragment-1.3.6-source 下的 FragmentManagerImpl 是空实现，将原本实现的代码全都移到了其抽象父类 FragmentManager 中了（注释有说

上一篇文章介绍了 IO 的基础知识，本节我们来举一个 IO 的应用实例——Dex 文件加密。当然，通常情况下我们是使用 Gradle 进行 Dex 加密的，这里使用 IO 权当是练手了。

主要是学习如何设计这样的 IO 系统，学习思想而不是代码本身。