本文已参与「新人创作礼」活动，一起开启掘金创作之路。
Workflow-kotlin是一个Kotlin库, 用于创建可组合状态机, 及由状态机驱动的UI.
为什么是Workflow?
鼓励编程范式, 尤其是移动领域内最佳实践
移动应用接收和展示了大量数据! 我们Square的应用确实这样. 结果就是, 移动应用日益倾向于响应式编程. 在这种范式下, 应用程序逻辑订阅一个数据流, 然后将其推送到逻辑中, 而不必定期拉取和操作. 这对确保向应用程序用户显示的数据永不过时具有深远的影响. 这种编程风格也清楚地表明, 大多数移动应用程序都是对数据流的一系列映射操作, 这些数据流最终会映射到某些UI中.
另一个移动编程最佳实践(从长久的传统中冉冉升起)是偏爱 声明式编程胜过命令式编程. 有了这种风格选择, 特性代码声明了对于一个特定的状态应该发生什么, 而不是由一系列基本上是如何发生的语句组成. 这是最佳实践, 因为当程序逻辑以这种方式定义的时候, 代码非常容易测试(所以更有可能接受测试!): “对于状态Y, 我们期待渲染Z;” “根据状态Y给定的输入A, 我们期望渲染Z+.” 可能更重要的是, 它比计算机的一系列复杂命令更容易阅读, 快速理解和推理.
Workflow鼓励声明式风格, 因为必须枚举特定组件的每个状态, 然后为该特定状态声明Rendering(传递给UI框架的表示), 并声明在该状态下应该运行哪些子级和副作用. Workflow运行时循环机制本身经过良好测试且可靠, 负责如何启动和停止子Workflow和负责效应, 减少了资源泄露. 通过要求每个状态, 渲染和将更改当前状态的操作的这些正式定义, Workflow天然鼓励声明式编程.
响应式编程和声明式编程可能是当前的最佳实践, 有一条软件工程原则已被反复证明是规模系统中最普遍, 最重要的原则: 关注点分离. 任何规模系统都需要多个独立的组件, 这些组件可以由多个团队独立进行处理, 测试, 改进和重构. 多组件系统需要通信, 任何良好的通信都需要明确的结构和协议.
对于Square的移动应用程序, 我们将模型-视图-视图模型(MVVM)体系结构作为应用程序各层关注点的主题分离结构. MVVM的单向分层通信与Model-View-Presenter(MVP)相同, 却与Model-View-Controller(MVC)的环形通信相反. MVVM在ViewModel和View中间使用严格的绑定, 这与MVC相同, 却与MVP中的Model的强制性解释相反. MVVM提供单向数据流的推理和理解优势, 同时也终止了尽可能来自视图层的业务逻辑, 也鼓励了声明式ViewModel. 在Square, MVVM工作良好, 因为我们拥有不经常变动的UI设计框架(由此保持绑定的最新状态并没有开销太多), 但是业务逻辑却在持续不断的更新(所以强调低耦合真的很重要).
Workflow拥抱MVVM是因为Workflow树生成的Rendering是ViewModel, 它之后能够绑定到任意原生移动UI框架.
对于基于特征的关注点分离, 我们依靠Workflow的功能, 通过强大的父子契约和分层树组织进行大规模合成.
尽管构建 Hello World Workflow 可能看起来过杀了(尽管HelloWorkflow 实际上并没有那么糟!), Workflow要求开发人员的明确性和协议为良好的沟通奠定了基础. Workflow的可组合性鼓励重用, 并鼓励将关注点分离为最合适的可重用组件.
Workflow与更多特定于平台的最佳实践相吻合, 例如结构化并发与Kotlin协程，因为每个Worker或副作用都可以为操作定义特定的协程范围.
接下来的10年会怎么样? Jetpack Compose UI 正在将自身建立为未来的原生移动UI工具箱. Jetpack Compose采用了与Workflow相同的MVVM途径，并鼓励考虑应用程序中独立组件的"可组合性". 有了这种共鸣, Workflow可以帮助您准备好您的心理模型, 以适应这些新的UI工具包, 并以一种便于我们采用的方式塑造我们的代码库. 要想了解更多关于Compose和Workflow的资源, 请查看这篇博客.
