声明式UI
M8Test 参考 Jetpack Compose 实现了一套类似 Jetpack Compose 的声明式 UI 框架，您可在脚本中以极为简洁的方式，通过声明式 UI 构建所需界面。
声明式与命令式
命令式 UI (Imperative UI)
命令式UI侧重于“如何做”。在这种模式下，你需要编写详细的指令，一步步地告诉计算机如何去修改UI以达到你想要的状态。这就像是你对UI元素下达一系列命令。
工作方式：你需要手动获取到特定的UI组件实例（例如，通过ID找到一个按钮），然后调用它的方法或设置其属性来改变其外观或行为（例如，button.setText(" 新文本") 或 view.color = "red"）。
现实类比：这就像是你用遥控器控制电视。你想增大音量，就按下“音量+”按钮，电视立即响应这个具体的命令。 你明确地发出了一个指令。 传统的UI框架，如Android的原生XML布局和jQuery，都采用了命令式的编程风格。
声明式 UI (Declarative UI)
声明式UI则侧重于“做什么”。你只需要向框架描述你想要UI在任何特定状态下应该是什么样子，框架则会负责在状态变化时自动更新UI，以匹配你所描述的状态。
工作方式：你将UI视为应用状态的映射或函数。当数据（状态）发生改变时，框架会自动检测变化，并智能地重新渲染UI中需要更新的部分。开发者不需要直接操作UI元素。
现实类比：这更像是设置智能家居的规则。你定义一条规则：“当我离开家时，关闭所有电器”。你声明了最终期望的结果，而智能系统会处理实现的细节，自动执行关闭电器的操作。 现代许多UI框架，如React、Vue、Flutter、Jetpack Compose和SwiftUI，都推崇并采用了声明式UI。
有什么区别？
特性 | 命令式 UI | 声明式 UI |
|---|---|---|
核心焦点 | 如何一步步实现UI的改变 | 什么是UI的最终状态 |
编程方式 | 开发者编写具体步骤来直接操作UI元素 | 开发者描述UI与数据状态的对应关系 |
状态管理 | 需要手动跟踪状态变化，并编写代码更新UI | UI由状态驱动，状态变更时UI自动更新 |
代码风格 | 往往更冗长，包含大量直接的DOM或视图操作代码 | 通常更简洁、可读性更高，只需描述最终结果 |
控制粒度 | 对UI元素有非常精细和直接的控制权 | 将UI的更新逻辑抽象化，由框架管理 |
各有什么优势？
声明式 UI 的优势
简洁性和可读性：代码通常更加简洁易懂，因为它只描述了最终的界面状态，而不是复杂的实现步骤。
可维护性更高：尤其是在复杂的应用中，由于UI和状态紧密绑定，更新和维护UI变得更加简单。你只需要关心业务逻辑和数据状态，而不用操心繁琐的UI操作。
可预测性强：由于界面完全由当前的状态决定，因此UI的行为更加可预测，也更容易进行调试和测试。
开发效率提升：减少了大量模板代码，让开发者可以更专注于应用的核心逻辑，从而加快开发周期。
命令式 UI 的优势
更精细的控制：开发者可以直接访问和操作每一个UI元素，提供了最大程度的灵活性和控制力。
潜在的性能优势：在某些极端或复杂的场景下，手动管理UI更新可能比依赖框架的自动比对和渲染机制更高效，因为你可以进行精确的性能优化。
成熟和熟悉：作为传统的UI编程范式，它拥有更长的历史，许多开发者对其非常熟悉，相关的学习资源和社区支持也十分丰富。
总而言之，随着现代应用复杂度的不断提升，声明式UI因其高效的开发模式和更易于维护的特点，正逐渐成为构建用户界面的主流选择。