Question

Flutter教程在每个地方都使用“窗口小部件”一词。在那种情况下什么是小部件？我可以在SO上找到最接近的问题在这里：What is a widget in Android?

但这是关于Android的，而不是Flutter（Flutter既为Android和iOS生成的，因此在两种情况下都定义了小部件），答案有些混乱。一个人说一个小部件就像一个按钮（所以我在想一些Ui包/框架的Ui组件），另一个人说它像一个应用程序，因为它可以在任何地方运行并占据整个屏幕。那么从WebDevelopment来看，我可以假设Widget就像WebComponent吗？

这是一段独立代码，不依赖于其他组件，但需要在环境中引导？这个假设是真的吗？对于Android和iOS？

Answer 1

strict definition of WebComponent随处可见，但有一点不同，但基本上可以归结为“一组标准，这些标准允许以以下形式定义自定义，封装，可重用的元素： html标签”。

Flutter的strict definition of a widget是：

描述元素的配置

和Element is defined as：

小部件在树中特定位置的实例化

但是，当您谈论WebComponents时，您可能会考虑的是“自定义，封装，可重用的元素”，而不是严格的定义。

当您开始以这种方式考虑它们时，flutter的Widget变得非常相似。定义窗口小部件时（通过扩展窗口小部件类之一），可以允许某些输入，并定义其显示方式。只要知道小部件的“接口”，就可以或多或少地使用小部件而不知道其内部工作方式。实例化它时，将创建Flutter选择调用元素的窗口小部件的实例。该小部件听起来与WebComponent元素非常相似！

Futhermore，在Flutter中创建Widget时，您可以封装其他小部件，这样就不必从头开始编写视觉定义（Flutter使用RenderObject表示呈现，而WebComponents模拟将是编写没有其他元素的纯HTML5）。 Flutter包含许多小部件，例如按钮，列表，容器，网格等，这些小部件与您在各种WebComponent库（例如Polymer的铁零件集）中可以找到的类似。

Flutter对Widget的定义还有一些额外的折痕-它们具有多种类型，包括InheritedWidget，StatefulWidget，StatelessWidget（还有一些专门的类型），每种类型都有其各自的特色自己的用法；在某些方面，Flutter的组件实际上比WebComponents更接近React的组件（实际上，flutter的设计基于相同的反应性理想）。这种“相对”性是Flutter Widgets和WebComponent elemnt之间的最大区别-它们主要通过将状态传递到树下而起作用，而WebComponent元素更可能具有您的widget可以在其子元素上调用的方法，并且更改是通过定义窗口小部件的方式传播到树上，而不必调用函数。

并非每个flutter Widget都必须具有视觉定义（也不是所有WebComponent都具有视觉定义）。例如，InheritedWidget实质上用于在小部件的树上跳过状态，而无需实际将信息向下传递到每一层-它用于在整个应用程序中共享ThemeData。而且，无需过多考虑细节，Flutter进行了优化，主要用于在事物发生变化时主要构建不可变的窗口小部件，而不是重复使用和修改现有窗口小部件。

这的TLDR是，是的，杂乱无章的WebComponent元素中的小部件带有一些警告。您将主要以一组小部件的形式编写应用程序，其中一些小部件封装了其他小部件。 Flutter的工作方式是使用自己的跨平台渲染器（Skia），该渲染器位于适用于android或iOS的相应可视容器中（Activity，我相信UIView （controller？））-您永远不会在本机android / iOS端从活动切换到活动，也不会从UIViewController切换到UIViewController。

Answer 2

小部件与WebComponents不相同。它们也不是UI元素。

小部件是用于描述应用程序任何部分的高级对象。它可以是但不限于UI元素，例如按钮；布局（对齐，填充等）；数据（主题，配置）...

小部件可以是所有。在混乱中，几乎所有您要编写的代码都将在Widget内部。甚至诸如“ redux reducers”之类的东西都扑朔迷离。

从某种意义上说，小部件与React组件极为相似。

最后，将小部件视为描述您的应用程序的东西。

但是什么不是小部件？

小部件不执行任何计算。他们将计算委托给其他对象。

例如，小部件不能在屏幕上呈现某些内容。相反，它使用内部方法RenderObject将其委托给createRenderObject。

仅供参考，在网络世界中，RenderObject通常是DOM元素或您的Web组件（因为它们是自定义DOM元素）。

由于它们将所有内容都委托给其他对象，因此我真的需要它们吗？

您不需要它们。但是你应该。您可以直接使用RenderObject来制作一个扑朔迷离的应用程序。您的应用很可能会更快。

但是小部件的设计使您的应用程序更具表现力，模块化和可维护性。

小部件通常在其他对象的顶部引入反应/功能编程模式。与更好的API结合使用以使用这些较低级别的对象。

Answer 3

看起来像扑一样，有一些有关此的文档：flutter docs

从本质上讲，小部件似乎是描述元素配置的一种方式。关于Elements的文档相当多地回到了小部件的概念。

乍一看，对我来说，似乎Element是一般视图的同义词。似乎是使用网络术语。

Answer 4

小部件基本上是Flutter中用Dart语言编写的UI组件

Answer 5

如前所述，Flutter 强调小部件作为一个组合单元。小部件是 Flutter 应用用户界面的构建块，每个小部件都是用户界面一部分的不可变声明。

小部件根据组合形成层次结构。每个小部件都嵌套在其父级中，并且可以从父级接收上下文。这种结构一直延续到根小部件（承载 Flutter 应用的容器，通常是MaterialApp 或 CupertinoApp），如这个简单的例子所示：

import 'package:flutter/material.dart';

void main() => runApp(MyApp());

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      home: Scaffold(
        appBar: AppBar(title: Text('My Home Page')),
        body: Center(
          child: Builder(
            builder: (BuildContext context) {
              return Column(
                children: [
                  Text('Hello World'),
                  SizedBox(height: 20),
                  ElevatedButton(
                    onPressed: () {
                      print('Click!');
                    },
                    child: Text('A button'),
                  ),
                ],
              );
            },
          ),
        ),
      ),
    );
  }
}

在前面的代码中，所有实例化的类都是小部件。

应用通过告诉框架将层次结构中的小部件替换为另一个小部件来响应事件（例如用户交互）更新其用户界面。然后框架会比较新旧小部件，并有效地更新用户界面。

Flutter 对每个 UI 控件都有自己的实现，而不是遵循系统提供的实现：例如，Dart implementation 和 iOS Switch control 都有一个纯 one for Android equivalent。

这种方法有几个好处：

提供无限的可扩展性。需要 Switch 控件变体的开发人员可以以任意方式创建一个变体，而不受操作系统提供的扩展点的限制。
允许 Flutter 一次性合成整个场景，而无需在 Flutter 代码和平台代码之间来回转换，从而避免了重大的性能瓶颈。
将应用行为与任何操作系统依赖项分离。该应用在所有版本的操作系统上的外观和感觉都相同，即使操作系统更改了其控件的实现也是如此。

有关更多信息，请参见：https://flutter.dev/docs/resources/architectural-overview#widgets

什么是Flutter中的小部件？

5 个答案: