川峰的博客

Jetpack Compose 学习汇总Jetpack Compose 学习汇总Jetpack Compose 学习汇总Jetpack Compose 学习汇总Jetpack Compose 学习汇总Jetpack Compose 学习汇总Jetpack Compose 学习汇总Jetpack Compose 学习汇总Jetpack Compose 学习汇总Jetpack Compose 学习汇总Jetpack Compose 学习汇总Jetpack Compose 学习汇总Jetpack Compose

不仅可以接受软键盘中输入的图片，同时它也可以接受你从其他地方复制到剪贴板中的图片内容，可以粘贴到输入框中输入。，通过该修饰符可以支持在输入框中输入输入法软键盘中自带的图片表情等，非常方便。在 Jetpack Compose 1.7.0 中提供了一个新的修饰符，中存在的bug，并且支持许多新特性，在未来我们应该尽量选择使用。集成，以接受由软件键盘或通过剪贴板粘贴操作提供的富媒体内容。是官方正在优化的实验性版本，它修复了许多。要使用 coil 加载gif，还需要在。

正如 UI 层的其他注意事项部分中提到的，如果你的用例需要的话，你可以使用多个流公开屏幕的 UI 状态。我们相信，这种方法可以为你提供更多的交付和处理保证，通常更容易测试，并且可以与应用程序的其他部分一致性的进行集成。如果你很难找到一种方法来减少一次性 ViewModel 事件的状态，请重新考虑该事件对你的 UI 的实际含义。这是一种反模式，因为如果我们从事务的角度考虑， UI 层中建模的支付结果状态不是持久的或原子的。应该公开实际的应用程序数据（在本例中为支付数据），而不是告诉 UI 要采取的操作。

加了它之后，在 Layout Inspector 中就可以看到重组次数为0，跳过重组的次数有很多（本该重组的次数）。，我们在 Layout Inspector 中观察列表快速滑动的时候，会发现列表出现红色闪烁，这说明发生了重组。我们可以使用三方的图片加载库，如coil，因为图片加载库一般会缓存，同一张图片不会重复加载第二次，还可以根据尺寸压缩等。部分，详细的介绍了稳定类型需要满足的准则，以及什么样的类型是稳定类型或者不稳定类型。，可以优化列表的加载性能，避免多余的重组。不是一个稳定的类型，会导致重组。

【代码】Jetpack Compose Text 跑马灯效果。

版本能提升不少性能，因为避免了在高频重组过程中的自动装箱和频繁的GC。其实 Kotlin 编译器会在背后默默的帮你处理拆装箱问题，简单来说，如果你单独使用一个。而第二种写法，就是真实的基本数据类型，是对应的 Java 的。其实要理解它为啥这样做，首先得理解 Kotlin 中的自动装箱问题。由于自动拆装箱有性能损耗，出于性能考虑，在Kotlin中，定义变量，那么背后对应的就是真实的基本数据类型。在一些动画类的场景中，使用基本类型的。，它是对应泛型的，也就是前面说的。中时，是对应的 Java 的。

可见 Jetpack Compose 短短几十行代码就实现了传统 View 体系中动辄需要上千行的代码，简直不要太简洁，不仅清晰易懂，而且还易维护。Compose 实现图片的手势操作比传统 View 简便太多了，在传统 View 体系中，如果要对。其实就是放大后的矩形宽度比原始矩形宽度多出的部分，显然此时左右移动的时候，左边和右边不应该超出。限制了偏移量的移动范围，在往左边拖动的时候，不能超过左边的。的回调函数中所做的事情，为了简化，我们可以先将上面。的一半，往右边拖动的时候，同样不能超过右边的。

但是作为开发者应该有这样的意识，一旦用户有这样的需求，我们就可以立即修改代码来达到需求。如果应用回到后台，随时有可能因为内存不足而被系统杀死，这时用户从最近应用程序列表中返回时，会发现应用界面从头开始，上次看到的状态丢失。当中，然后用户继续浏览，然后用户又切到其他应用，此时当前应用因为某种原因进程被杀死重启（如内存不足），那么这个时候 object。值增加之后，回到后台去做其他事情，此时应用因为内存不足被系统杀死，用户再次返回应用，应用会重启，用户看到的将会是初始值 0。(View system)，以及。

在之前Jetpack Compose中的导航路由一文中，我提到开源库 compose-destination 就是借助 KSP 来生成代码的，如果你去看它的源码，就会发现它是通过纯KSP的方式生成代码的，没有使用KotlinPoet。下面通过 KSP + KotlinPoet 的方式也来自定义实现一个下简单的可以通过注解配置的Compose导航路由框架。当然，实现思路最终还是要通过Compose原生的导航路由API来实现，只不过我们可以对其进行一些封装，隐藏那些烦人又麻烦的配置操作细节。具体的思路是

Google目前在Android端主推的Jetpack Compose声明式UI框架正是基于单向数据流的架构模型的一种具体实现，在这种架构中，只有两种角色UI和数据，但影响UI更新的只能是状态，普通的数据是不能直接影响UI的，必须变成mutableState（可被观察的可变状态）才行。

现在的跨平台框架真是跟打了鸡血似的，跟生产队的驴一样玩命的更新啊，一会儿功夫就遍地开花，开发者尤其是Androiders们还能学得过来吗？

在 Android 开发的历史中，Camera 的 API 是一直受人诟病的，直观的感觉就是配置复杂、臃肿、难用、不易理解，官方也在尝试着不断改进开发者关于Camera的使用体验，Camera 的 API 截止目前经历了 Camera（已废弃）、Camera2、CameraX 三个版本。初代 Camera API从 5.0 开始已经宣布废弃，而 Camera2 的 API 特别难用，所以就有了 CameraX ，本文主要探索如何在 Jetpack Compose 中使用 CameraX。

Jetpack Compose 中在屏幕间共享数据的 5 种方案，Jetpack Compose 中在屏幕间共享数据的 5 种方案，Jetpack Compose 中在屏幕间共享数据的 5 种方案，Jetpack Compose 中在屏幕间共享数据的 5 种方案，Jetpack Compose 中在屏幕间共享数据的 5 种方案，Jetpack Compose 中在屏幕间共享数据的 5 种方案，Jetpack Compose 中在屏幕间共享数据的 5 种方案，Jetpack Compose 中在屏幕间共享数据

Jetpack Compose 中的基础组件，Jetpack Compose 中的基础组件，Jetpack Compose 中的基础组件，Jetpack Compose 中的基础组件，Jetpack Compose 中的基础组件，Jetpack Compose 中的基础组件，Jetpack Compose 中的基础组件，Jetpack Compose 中的基础组件，Jetpack Compose 中的基础组件，Jetpack Compose 中的基础组件，Jetpack Compose 中的基础组件，Jet

发送通知相关的主要有两个关键的类 NotificationCompat.Builder 和NotificationManagerCompat发送通知后通过NotificationManagerCompat.notify(id, notification)对相同的通知id进行再次调用，就会更新通知中对应的属性

从本质上讲，副作用是任何超出函数控制和作用域的东西。副作用会使函数变得不确定，因此它们使开发人员难以推理代码。这对于React、Compose这类的声明式UI框架至关重要，因为它们都是通过函数（组件）的反复执行来渲染UI的，函数执行的时机和次数都不可控，但是函数的执行结果必须可控，因此，我们要求这些函数组件必须用纯函数实现。

要在可组合函数之间共享数据时，可以通过参数传递显式地调用，这通常是最简单和最好的方式。但随着参数越来越多，组件也越来越多，并且有些数据还需要保持私有性，这时这种方式就会显得很繁琐臃肿，难以维护。 对于这些情况，Compose 提供了CompositionLocals来作为一种隐式方式在组合函数之间传递数据。说白了就是在 Composable 树中提供的一种共享数据的方式（例如主题配置）。CompositionLocals本质上是分层的。当CompositionLocal的值需要被限定于组合的特定子层次结

Compose UI 是一个 Kotlin 多平台框架。它提供了通过可组合函数发出 UI 的构建块和机制。除此之外，这个库还包括 Android 和 Desktop 源代码，为 Android 和 Desktop 提供集成层。当使用 Compose runtime 集成 UI 时，目标是构建用户可以在屏幕上体验的布局树。这个树是通过执行发出 UI 的 Composable 函数来创建和更新的。用于树的节点类型只有 Compose UI 知道，所以 Compose runtime 可以不知道它。即使 Comp

Jetpack Compose由一系列的库组成，但我们需要重点关注三个特定的库：Compose compiler、Compose runtime 和 Compose UI。其中 Compose编译器 和 Compose runtime 是Jetpack Compose的支柱。从技术上讲，Compose UI 不是Compose体系结构的一部分，因为运行时和编译器被设计为通用的，并由符合其需求的任何客户端库使用。Compose UI 只是其中一个可用的客户端。还有其他的客户端库正在开发中，比如JetBra

slot table（插槽表）是一个优化的内存结构，runtime 使用它来存储组合的当前状态。它在初始组合时填充数据，并在每次重新组合时更新。我们可以把它看作是所有Composable函数调用的跟踪，包括它们在源码中的位置、参数、记住的值、CompositionLocals等等。它包含了在合成过程中发生的一切内容。所有这些信息将被 Composer 稍后用于生成下一个更改列表，因为对树的任何更改总是依赖于当前状态。slot table 记录Composable的状态，而 change list 则是对

一般来说，只有当运行时对需要运行的代码有一定的确定性时，才可能进行运行时优化，因此它可以从中假设特定的条件和行为。它可以将重组安排到不同的线程中，以利用多核心提升性能，或者它可以根据自己的需要或优先级以任意顺序运行可组合函数 (例如：没有显示在屏幕上的组合可以被分配一个较低的优先级)为何不能很好地组合在一起，因为你不能从同步函数中调用异步函数，除非你使同步也成为异步的，或者提供一种等待机制，允许调用异步函数并等待它们的结果。Compose会选择重新启动树中的哪些节点，以保持其内存中的表示状态始终是最新的。

Jetpack Compose相比传统View开发真的是太香了，能以更少、可读性更好、维护性更好的代码来实现以前更复杂的业务需求。如果你是一个Android开发老鸟，相信会对本文所表达的二者之间的天差地别有更深刻的体会。所以，是时候该将鸟枪换炮了！请转发给你的团队开发决策者。

标准版本 offset() 在每次偏移量发生改变时，会重新创建 Modifier 实例（hashCode不停变化证实了这一点），当 Modifier 实例发生变化时，组合树会先删除旧的，然后再添加一个新的 Modifier 实例。组合树的变化会导致重组的发生，因此如果偏移量频繁变化，重组就会频繁的发生，而每次重组都有可能触发组合->布局->绘制这三个阶段，这非常要命。而 lambda 版本 offset{} 的优势是， Modifier 实例不会改变（hashCode保持不变证实了这一点），Compose

通常，延迟列表包含许多项，并且这些项所占空间大于滚动容器的大小。不过，如果列表中填充的项很少，那么在设计中，您可以对这些项在视口中的位置做出更具体的要求。

编辑accompanist是Jetpack Compose官方提供的一个辅助工具库，以提供那些在Jetpack Compose sdk中目前还没有的功能API。

Jetpack Compose中直接提供了一个叫 Canvas 的 Composable 组件，可以在任何 Composable 组件中直接使用，在 Canvas 的DrawScope作用域中就可以使用其提供的各种绘制Api进行绘制了。这比传统View要方便的多，传统View中，你只能继承一个View控件，才有机会覆写其onDraw()方法。Canvas Api使用相比比传统View中的要简单一些，不需要画笔Paint和画布分开来，大多数直接就是一个函数搞定，当然也有一些限制。

在深入讨论之前，非常重要的一点是要区分 Compose UI 和 Compose runtime。Compose UI 是 Android 的新 UI 工具包，具有 LayoutNodes 的树形结构，它们稍后在画布上绘制其内容。Compose runtime 提供底层机制和许多状态/组合相关的原语。 随着 Compose 编译器 支持完整的 Kotlin 平台谱系，现在可以在几乎任何地方（只要它运行Kotlin）使用 runtime来管理 UI 或任何其他树形结构。注意“其他树形结构”部分：Compose

应用的“状态”是指可以随时间变化的任何值。这是一个非常宽泛的定义，从 Room 数据库到类的变量，全部涵盖在内。所有 Android 应用都会向用户显示状态。状态决定界面在任何特定时间的显示内容。Compose 应用通过调用可组合函数将数据转换为界面。组合是指 Compose 在执行可组合项时构建的界面描述。如果发生状态更改，Compose 会使用新状态重新执行受影响的可组合函数，从而创建更新后的界面。这一过程称为重组。Compose 还会查看各个可组合项需要哪些数据，以便仅重组数据发生了变化的组件...

如果应用打算使用 Jetpack Compose 来开发，那么就可以跟以前的MVC、MVP、MVVM等乱七八糟的架构全部说拜拜，这些名词也将在Android开发当中永远地成为历史。因为 Jetpack Compose 的架构思想非常简单，只有UI层和数据层两层，即上图所示（其中 Domain Layer 是可选的层）。它的核心思想是单向数据流，以数据模型驱动界面，遵循关注点分离的原则。在前面的架构图中可以看到，UI 层其实细分又包含了两层：UI 元素和状态容器（StateHolder）。其中 UI 元素

Jetpack Compose 有一种特殊的方式来表示状态和传播状态变化，从而驱动最终的响应式体验：状态快照系统（State snapshot system）。这种响应式模型使我们的代码更加强大和简洁，因为它允许组件根据它们的输入自动重组，并且只在必要时重组，避免了我们过去在Android View 系统中手动通知这些更改所需的所有样板文件。Snapshot state（快照状态）是指可以被记录并观察其变化的隔离状态。当我们调用像mutableStateOf、mutableStateListOf、mutab

与大多数其他界面工具包一样，Compose 会通过几个不同的“阶段”来渲染帧。如果我们观察一下 Android View 系统，就会发现它有 3 个主要阶段：测量、布局和绘制。Compose 和它非常相似，但开头多了一个叫做“组合”的重要阶段。Compose 有 3 个主要阶段：组合：要显示什么样的界面。Compose 运行Composable可组合函数并创建LayoutNode视图树。布局：要放置界面的位置。该阶段包含两个步骤：测量和放置。对于视图树中的每个LayoutNode节点进行宽高尺寸测

Jetpack Compose中没有沿用Android原有的View动画和属性动画，而是新创建了一套全新的动画系统API，这是理所当然的，因为旧的动画系统主要是基于View体系的，而Compose中需要针对的是Composable可组合函数进行处理，那么势必要创造一套新的玩具出来，同时，这也无疑增加了开发者的学习成本。乍一看Jetpack Compose中的动画Api，尼玛是真的多呀，我C了，简直令人眼花缭乱、云里雾里、天马行空、小兔乱撞、手脚慌乱、头冒虚汗、四肢抓狂、不知所措呀 。。。😭

之前在里简单的提到了从Compose导航到其他Activity页面的方式，对于不带返回结果的则就是跟以前一样简单的启动Activity的代码，而如果是方式的，需要使用带回调的方式去启动，那么在以前，我们要么是使用三方库，要么是自己封装一个简单的库来使用 (至于背后原理也不是什么新鲜事了)。后来研究了一下，在Compose中也有了新的姿势，要理解Compose中的姿势，这还得从androidx的的姿势说起，因为Compose就是在androidx的基础上利用其API简单封装了一下而已。

要判断和监听网络连接状态，要使用的系统服务是 ConnectivityManager 对象，可以通过 context.getSystemService(Context.CONNECTIVITY_SERVICE) 来获得。所以首先可以定义一个Context的扩展属性来方便的获取该对象

在 Compose 中，可以通过 `FocusRequester` 与 `FocusManager` 这两个对象可以主动在代码中控制焦点获取和取消焦点，其中`FocusRequester`可以用来获取焦点，通过调用它的`requestFocus()`方法来实现，而 `FocusManager`可以用来取消焦点（以及移动焦点），通过调用它的`clearFocus()` 方法来实现。

Compose 将 Android 设备的屏幕尺寸分为三类： Compact、Medium、Expanded。它是以某个维度来划分的。应避免根据物理硬件值来确定布局。实体设备不能保证特定的窗口大小类别。应用可用的屏幕空间可能会与设备的屏幕尺寸不同，这有很多原因。在移动设备上，分屏模式可以在多个应用之间拆分屏幕。在 Chrome 操作系统中，Android 应用可以呈现在可任意调整大小的自由式窗口中。可折叠设备可以有两个大小不同的屏幕，分别可通过折叠或展开设备使用。

Jetpack Compose中的导航库是由Jetpack库中的Navigation组件库的基础上添加的对Compose的扩展支持，Jetpack Compose中的Navigation在功能上跟jetpack组件库中对Fragment的导航使用方式很类似，但是使用Compose的好处是，它是纯kotlin的代码控制，不需要在xml再去配置，一切都是在kotlin代码中进行控制，更加方便灵活了。

Modifier修饰符是Jetpack Compose中用来修饰组件的，提供常用的属性，写布局时几乎所有Composable组件的大部分属性都可以用Modifier 来修饰。官方在开发Compose UI时，最初尝试过将所有属性全部以函数参数的形式提供，但是那样太多了，他们也尝试过像Flutter那样的方式，将属性也作为一个组件进行嵌套，但这样又很容易让人感到困惑，所以才诞生了Modifier，将大部分组件常用属性封装成Modifier的形式来提供，哪个组件需要就在哪个组件上应用。

Jetpack Compose中为手势操作如点击、拖动、滑动、缩放、旋转等都提供了十分方便的Modifier修饰符满足日常开发使用，并且还提供了非常丰富的低级别的Gesture Api，通过这些API我们可以定制更加复杂的交互手势。

在传统的 Android 开发模式中，由于界面过分依赖于 Activity、Fragment这样的组件，一个业务模块中往往会存在着大量的 Activity 类，因此诞生了很多的插件化框架，这些插件化框架基本都是想方设法的使用各种Hook/反射手段来解决使用未注册的组件问题。在进入 Jetpack Compose 的世界以后，Activity 的角色被淡化了，由于一个 Composable 组件就可以承担一个屏幕级的显示，因此我们的应用中不再需要那么多的 Activity 类，只要你喜欢，你甚至可以打造一个单