[Flutter翻译]谷歌隐藏了哪些Flutter最佳实践?

959 阅读5分钟

本文由 简悦SimpRead 转码,原文地址 itnext.io

现在,我不是在谈论表面的东西,比如你用Lifecycle包作为你的导航仪Ob......。

image.png

现在,我说的不是表面的东西,比如如果你使用Lifecycle包作为你的Navigator Observer,你也可以在你的应用日志中获得应用生命周期事件。我说的是更大的 "房间里的大象 "

我可能会与谷歌、Very Good Ventures、GSkinner等公司的一些人对立。

背景

我们都在某些时候看到过这种情况。

image.png

好吧,让我以你没有看到的方式来解释这个图形基准。

MVVM的核心,有时我们在Flutter ASVM中的核心是视图模型。而且,这通常在UI方面意味着一个列表视图,这意味着一个列表,甚至在模型方面也是一个列表而不是一个MAP。

那么,为什么我要求注意它不是一个MAP呢?

从计算机科学的角度来看,MAP是最精简的内存性能的OOP结构。猜猜看,与MAPs相比,什么东西占用的内存最多?是的,列表。

想象一下,如果我们实现一个View-Model,忽略Flutter框架本身,我们有多少个Lists?至少有两个。

现在,在我们选择依赖注入解决方案时,选择一个使用MAP的解决方案,在我们应用的一个屏幕上,在前两个清单上,至少再增加一组内存大的东西,这有意义吗?

那为什么谷歌和其他公司要推动Widget DI呢?

为什么Widget依赖注入

你会注意到,谷歌和其他知名的Flutter社区成员从来没有把Bloc或其他形式的Flutter MVVM称为真正的MVVM。在微软第二次运行ASP-NET的时候,他们发明了MVVM架构。发明的一部分是使其成为Martin Fowler的演示模型的变体。另外,他们的变化的一部分是,视图模型与视图的绑定是由代码生成处理的。

因此,继承的MVVM架构定义的一部分是,如果要称为真正的MVVM,MVVM绑定必须是自动的,而不是由开发者处理。

这就给我们带来了谷歌和其他Flutter社区成员推崇Provider和基于Widget-DI的Bloc的原因。也就是说,因为在当时,没有混合结构的实现可以轻松地将View-Model方法绑定到View上。

事实上,mixins并不是将View-Model方法绑定到Widget的唯一方法,因为我们还可以使用扩展。

Flutter的两个MAP实现的服务定位器DI解决方案实际上采取了这两条路。Get_IT使用mixins将View-Model方法绑定到Widget,而GETX使用扩展来实现同样的绑定。

pub.dev/packages/ge…

pub.dev/packages/ge…

pub.dev/packages/ge…

但是没有非Widget基础的Bloc实现

你表现得好像这有多难。Bloc的核心是一些简单的方法,将Stream和Sink绑定到视图模型上。我们已经可以做到这一点了。诚然,你必须在分叉的Reactive Components Package中做一些工作,并修复null-safety的实现。

反应式组件空安全分支

但是,这并不是火箭科学。我已经在几个小时内完成了这项工作。

但是如果我想要Redux

你知道有一个非Widget-DI的Redux吗?它已经实现了ASVM架构,因为它与Streams和Sinks集成。它被称为Async Redux。

pub.dev/packages/as…

它很强大,但并不复杂,因为它没有中间件,不像其他复杂的Redux实现。对我们的内存性能讨论很重要的是,你可以把redux存储分离成一个,用于超越父应用的每个视图模型。

这有一个移动方面的问题,因为在安卓系统上,我们可以在应用关闭时存储恢复的内容有限,只有2GB到3GB。这个概念是,你将存储视图模型的冗余存储,因为它将低于2GB到3Gb,如果应用程序由于内存压力而关闭,只需重新创建其余的应用程序模型存储。

有什么理由继续做传统的Widget DI?

是否有任何理由继续做传统的Widget DI,比如Provider和RiverPod?没有,除非你真的重视在应用关闭时增加更多的内存压力来虐待用户,更不用说由于使用基于列表的DI解决方案在内存方面的额外惩罚而导致应用运行速度变慢。

什么是ASVM(RXVAMS)

什么是ASVM?它是Async-Stream-View-Model架构。我不是第一个提出这个概念的人,当然也不是最后一个。

还有人称它为RxVAMS,即Reactive-View-AppModel-Service。具体内容请看这篇文章。

让Flutter更有反应性

结论

将Flutter骨架模板应用进行修改,并对其进行打磨,包括对最佳实践的深入研究,其中一个原因是我可以质疑每一个选择,并深入了解每个开发人员和设计师在创建Flutter应用时应该使用哪些Flutter最佳实践的核心。

如果有更好的方法可以改善Flutter应用的用户体验,那么坚持使用传统的方法就没有意义了。

关于我,Fred Grott

从Android Java-Kotlin开发转到Flutter App开发。

我目前在flutter上的免费资料以及代码和创意资产都在我的代码与我的GitHub存储库中,地址是:。

您可以在以下网址关注我


www.deepl.com 翻译