传统的 View 和视图模型
我一直支持在移动 UI 开发中使用视图模型。
无论你是在 Android 还是 iOS 上工作,都要考虑自定义的 View
或 UIView
,称为ListItemView
。这个 ListItemView
在左边显示一个图标,然后在图标右边显示字幕上方的标题,最后在右侧显示一个可选附件:
在定义这个自定义 View 的时候,你可以将每个对 View 的描述设为独立属性:
myListItemView.icon = blah;
myListItemView.title = “blah”;
myListItemView.subtitle = “blah”;
myListItemView.accessory = blah;
从技术上来说,这没什么问题,但是带来了架构成本。通过独立定义每个配置,你对其描述的 Object 需要引用你的 View,以便它可以配置每个属性。但是,如果你使用视图模型,那么你的描述 Object 可以在不引用 View 的情况下运行,这意味着描述 Object 可以进行单元测试,并且它避免了对具体 View 的编译时依赖性:
class ListItem {
final Icon icon;
final String title;
final String subtitle;
final Icon accessory;
…
}
// 使用 Presenter 创建一个新的视图模型。
myListItem = myPresenter.present();
// 传递视图模型到 View 来渲染新的视图外观。
myListItemView.update(myListItem);
这种使用视图模型的基本原理,与 Flutter 无关,但与传统的 View 相比,理解视图模型是非常重要的。视图模型是一个不可变的配置,需要应用于生命周期长的,可变的 View。
传统 Android 和 iOS 中的依赖关系如下:
MyAndroidView -> M
《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》
【docs.qq.com/doc/DSkNLaERkbnFoS0ZF】 完整内容开源分享
yAndroidViewModel
MyiOSUIView -> MyiOSViewModel
换句话说,在传统的 Android 和 iOS 中,我们主要使用可变的,生命周期长的 View(和 UIView)。我们通过使用那些生命周期长的 View(和UIView)Object来定义布局 XML,Storyboard 和可编程的布局。然后,我们不定期会传递新的视图模型来改变它们的界面。
现在,让我们来谈谈 Flutter。
Flutter 颠覆了这种依赖关系
与其使用可变的、生命周期长,且会不定期接收新的视图模型的 View,不如我们只使用不可变视图模型,来配置可变的、生命周期长的 View?
以前是:
MyView -> MyViewModel
现在改为:
MyViewModel -> MyView
就像这样,简单来说,我们刚刚发明了 Flutter 的组件系统:
MyWidget -> MyElement
MyWidget -> MyRenderObject
这些组件都是不可变的,其中包含了许多用于配置渲染内容方式的属性:
// 这个组件看起来肯定很像一个视图模型,不是吗?
new Container(
width: 50.0,
height: 50.0,
padding: EdgeInsets.all(16.0),
color: Colors.black,
);
// Flutter 组件和传统视图有一个很大的区别
// 就是这些组件同样可以
// 实例化生命周期长的视图
final mutableSubtree = myContainer.createElement();
final mutableRender = myContainer.createRenderObject();
但为什么这些组件能创建这两样东西呢?我认为,组件应该只能创建一个生命周期长的视图?
在 Flutter 中,父/子的概念独立于渲染而存在。在 iOS 和 Android 中,父/子关系与绘制到屏幕的概念是一致的。
例如,在 Android 中,ViewGroup 需要负责:
// 父/子关系
myViewGroup.addView(…);
myViewGroup.removeView(…);
// 以及
// 布局和绘制
关系
myViewGroup.addView(…);
myViewGroup.removeView(…);
// 以及
// 布局和绘制