Flutter 中的 Widget 是什么？

Question

Flutter 教程到處都使用“Widget”這個詞。 在這種情況下什么是小部件？ 我能在 SO 上找到的最接近的問題在這里： 什么是 Android 中的小部件？

但它是關於 Android 而不是 Flutter（它為 Android 和 iOS 構建，因此在兩種上下文中都定義了小部件）並且答案有點令人困惑。 一個人說 Widget 就像一個按鈕（所以我想到了一些 Ui 包/框架的 Ui 組件），另一個人說它就像一個應用程序，因為它可以在任何地方運行並占據整個屏幕。 那么來自 WebDevelopment，我可以假設 Widget 類似於 WebComponent 嗎？

它是一段獨立的代碼，不依賴於其他組件，但需要在環境中引導？ 這個假設是真的嗎？ 安卓和iOS都可以嗎？

Answer 1

小部件並不等同於 WebComponents。 它們也不是 UI 元素。

小部件是用於描述應用程序任何部分的高級對象。 它可以是但不限於按鈕等 UI 元素； 布局（對齊，填充，...）； 數據（主題、配置）...

小部件可以是一切。 在 flutter 中，幾乎所有你要編寫的代碼都在一個 Widget 中。 甚至像“redux reducers”這樣的東西也是flutter中的小部件。

從某種意義上說，小部件與 React 組件極為相似。

最后，將小部件視為描述您的應用程序的東西。

---

但是什么小部件不是呢？

小部件不做任何計算。 他們將該計算委托給其他對象。

例如，小部件無法在屏幕上呈現某些內容。 相反，它通過使用其內部方法createRenderObject其委托給RenderObject 。

僅供參考，在 Web 世界中， RenderObject通常是 DOM 元素或您的 Web 組件（因為它們是自定義 DOM 元素）。

---

既然他們將所有東西都委托給其他對象，我真的需要他們嗎？

你不需要它們。 但你應該他們。 您可以直接使用RenderObject制作顫振應用程序。 您的應用程序很可能會更快。

但是小部件的設計方式使您的應用程序更具表現力、模塊化和可維護性。

小部件通常在其他對象的頂部引入反應式/函數式編程模式。 結合更好的 API 來使用這些較低級別的對象。

Answer 2

WebComponent的嚴格定義在任何地方都略有不同，但基本上它歸結為（用我自己的話）“一組標准，允許以 html 標簽的形式定義自定義的、封裝的、可重用的元素”。

Flutter對 widget的嚴格定義是：

描述元素的配置

元素定義為：

在樹中特定位置的 Widget 實例

然而，當您談到 WebComponents 時，您可能會想到“自定義的、封裝的、可重用的元素”而不是嚴格的定義。

當您開始以這種方式考慮它們時，flutter 的 Widget 變得非常相似。 當您定義小部件（通過擴展小部件類之一）時，您可以允許某些輸入，並定義它的顯示方式。 您可以或多或少地使用一個小部件，而無需知道它的內部工作原理，只要您知道已為其提供的“界面”。 當你實例化它時，你會創建一個 Flutter 選擇調用 Element 的小部件實例。 Widget 聽起來與 WebComponent 元素非常相似！

此外，當你在 Flutter 中創建一個Widget時，你可以封裝其他小部件，這樣你就不必從頭開始編寫視覺定義（Flutter 使用 RenderObject 來表示渲染，而 WebComponents 模擬將編寫沒有其他元素的純 html5） . Flutter 包括許多小部件，例如按鈕、列表、容器、網格等，它們與您在各種 WebComponent 庫（例如 Polymer 的鐵組件）中找到的相似。

Flutter 對 Widget 的定義有一些額外的皺紋 - 它們有各種類型，包括InheritedWidget 、 StatefulWidget 、 StatelessWidget （以及一些更專業的），每一種都有自己的用法； 在某些方面，Flutter 的組件實際上比 WebComponents 更接近於 React 的組件（實際上 Flutter 的設計基於相同的反應式理想）。 這種“反應性”是 flutter Widgets 和 WebComponent 元素之間的最大區別——它們主要通過將狀態向下傳遞到樹來工作，而 WebComponent 元素更有可能具有您的小部件可以在其子元素上調用的方法，並且更改是通過定義小部件的方式沿樹向下傳播，而不必調用函數。

不是每個 flutter Widget 都必須有一個可視化定義（也不是所有的 WebComponents 都有一個可視化定義）。 例如，InheritedWidget 基本上用於在小部件樹中向下跳躍狀態，而不必實際將信息向下傳遞到每一層 - 它用於在整個應用程序中共享 ThemeData。 並且沒有過多涉及血腥的細節，flutter 被優化用於在事情發生變化時主要構建不可變的小部件，而不是重新使用和修改現有的小部件。

不過，這個 TLDR 是，是的，flutter 中的小部件類似於“WebComponent 元素”，但有一些警告。 您將主要以一組小部件的形式編寫應用程序，其中一些小部件封裝了其他小部件。 Flutter 的工作方式是它使用自己的跨平台渲染器 (Skia)，該渲染器位於 android 或 iOS 的相應視覺容器中（Activity，我相信 UIView (controller?) ） - 所以你永遠不會從 Activity 切換到 Activity或 UIViewController 到 UIViewController 在原生 android/iOS 端。

Answer 3

看起來 flutter 有一些關於這個的文檔： flutter docs

本質上，小部件似乎是一種描述元素配置的方式。 Elements 上的文檔又回到了小部件的概念。

粗略一看，對我來說，元素似乎是一般視圖的同義詞。 似乎它正在使用網絡術語。

Answer 4

Widgets 基本上是 Flutter 中的 UI 組件，用 Dart 語言編寫

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'),
                  ),
                ],
              );
            },
          ),
        ),
      ),
    );
  }
}

在前面的代碼中，所有實例化的類都是小部件。

應用程序通過告訴框架用另一個小部件替換層次結構中的小部件來響應事件（例如用戶交互）更新其用戶界面。 然后框架會比較新舊小部件，並有效地更新用戶界面。

撲有它自己的每個UI控制的實現，而不是延遲到由該系統提供的那些：例如，有一個純Dart implementation兩者的iOS Switch control和one for所述Android equivalent 。

這種方法提供了幾個好處：

• 提供無限的可擴展性。 需要 Switch 控件變體的開發人員可以以任意方式創建一個變體，而不受操作系統提供的擴展點的限制。
• 通過允許 Flutter 一次合成整個場景，而無需在 Flutter 代碼和平台代碼之間來回轉換，避免了顯着的性能瓶頸。
• 將應用程序行為與任何操作系統依賴項分離。 該應用程序在所有版本的操作系統上的外觀和感覺都相同，即使操作系統更改了其控件的實現。

有關更多信息，請參見： https : //flutter.dev/docs/resources/architectural-overview#widgets