为何Live Edit刷新速度远快于Compose Preview？

1. 运行环境的本质区别 #

• Compose Preview：运行在Android Studio进程内部的本地预览沙箱，本质是一个轻量的Android环境模拟器。它需要在本地模拟Android的UI运行时，包括Compose的重组引擎、布局系统和渲染管线。你的Intel i7-4790是四代酷睿，算力和内存调度能力有限，本地模拟Android环境的额外开销会被显著放大。
• Live Edit：直接运行在物理设备/真实模拟器的Android系统进程中，完全复用设备本身的ART虚拟机、GPU渲染能力和系统资源，不需要在IDE本地模拟任何Android环境。

2. 编译与代码更新流程的差异 #

• Compose Preview的刷新链路：
  1. 代码修改后，执行局部编译生成Compose Kotlin字节码
  2. 将字节码转换为Preview沙箱兼容的渲染指令
  3. 重启或更新本地沙箱的UI上下文
  4. 重新执行Compose重组、布局、绘制的全流程
     整个流程依赖IDE本地资源，沙箱的启动、指令转换环节在旧CPU上会产生明显延迟。
• Live Edit的刷新链路：
  1. 检测到代码变更后，编译生成极小的增量代码补丁（仅包含修改的颜色/文本对应的字节码片段）
  2. 通过ADB（无线调试为TCP/IP通道）将补丁推送到设备
  3. 设备上的App进程利用ART的即时代码替换机制，直接在运行时替换目标方法/变量
  4. 触发Compose的局部重组（仅修改的UI节点）
     这个流程几乎没有本地模拟开销，补丁体积极小，设备端的ART执行效率远高于本地沙箱。

3. 渲染路径的长短差异 #

• Compose Preview的渲染结果需要通过IDE本地的渲染桥接层（OpenGL/软件渲染转换），将Android UI渲染结果转换成Studio窗口可显示的内容，多了一层跨环境的转换开销。
• Live Edit的渲染直接在设备的GPU/CPU上完成，输出到设备屏幕，渲染路径短，无额外转换环节。

4. 资源调度优先级差异 #

• Android Studio对Preview的资源调度优先级较低，当IDE有后台编译、代码索引等任务时，Preview的刷新进程会被抢占资源，在旧CPU上这种抢占导致的延迟会更明显。
• Live Edit的代码同步和运行时替换完全独立于IDE本地资源，设备端的资源调度不受IDE影响，能保证更新流程的高效执行。

内容的提问来源于stack exchange，提问作者0xBADABA55