1、IoT系統開發痛點
1.1、IoT領域（尤其 RTOS ）系統開發碎片化
IoT 領域，一個避不開的詞就是碎片化。在硬體方面，廠商、架構、晶片、傳感器等等方面的差異，形成了硬體體系的多樣性。
在應用場景方面，面向衆多行業，衆多品類等特性造就了應用場景十分分散。在開發生态方面，又有着不同類型的系統平台，例如 Linux、Android、RTOS 等。
即便是在 RTOS 這一類平台上，也有着衆多不同的選擇，不同 RTOS 間，程式設計規範、接口等難以做到統一，故其碎片化的程度也愈發嚴重。綜合各個方面來看，IoT 領域的系統開發碎片化目前依然較為嚴重。
1.2、多端開發的成本
IoT 場景下，由于運用場景的多樣性，涉及到不同端的開發。例如，在裝置側可以使用輕量級的 RTOS 系統，也可以使用更複雜的Android；而在面向使用者側的移動端，又可以選擇 iOS、Android 、H5。甚至有些情況下，同一款應用需要同時在不同的兩端或三端開發，以适配不同的硬體、系統。
多端開發的選擇會受控于許多方面，其中一部分就是開發成本問題。多端開發成本主要展現為一下幾個方面：應用分發管道不統一、技術棧各不相同、開發人力成本較高。
應用分發管道不統一
許多方案都需要應用分發平台，才能夠保持應用的不斷更新。對于 iOS，應用的分發一般隻有 App Store，在整個應用分發行業中，App Store 算是比較統一、規範的應用分發平台。對于 Android 而言，由于其開放性較高，系統對應用管控也相對較弱，是以 Android 對應的分發平台既多、又雜、還亂。國外分發平台有 Google Play、Amazon AppStore 等；國内分發平台有華為應用市場、小米應用市場、PP 助手安卓商店等。各家分發平台對軟體的要求規範不盡相同，相比 App Store，目前還沒有形成一套完善統一的分發平台。RTOS 一般不使用應用分發平台，而是通過 OTA（Over The Air）等方式更新軟體。Web 端每一次請求頁面，都能擷取最新版本的應用，也就不需要對應的分發平台了。
技術棧各不相同
每一種平台對于的技術棧其實也各不相同，單從開發語言的角度來說，iOS 開發語言一般是 Object-C、swift。Android 開發語言是 Java、Kotlin。Web 前端開發語言是 HTML、CSS、JavaScript，後端則有 PHP、Java、Python 等。RTOS 應用開發語言一般選用 C/C++。
開發人力成本較高
如果同一款應用，需要分發到不同平台，那麼可能需要不同的開發團隊分别完成對應某端的開發，這樣也就帶來了成倍的人力成本。即使是讓同一個團隊完成多端的開發，也需要大量地學習新技術棧的時間，間接的帶來人力成本。
2、Flutter的前世今生
由于多端開發存在着上一節講述的等等問題，跨平台的解決方案和架構近年來一直是多端開發備受關注的點。目前也有不少的跨平台解決方案。
2.1、跨平台解決方案
2.1.1、WebView
在 Android 中，有一個原生控件叫做 WebView，在 iOS，也有一個與之對應的原生控件叫做 UIWebView。這兩個控件可以直接渲染 HTML 和 CSS 的代碼，也可以通過 JavaScript 直接調用原生相關接口。于是，就有了基于 JavaScript 和 WebView 的跨平台方案。隻要将 View 基于 WebView 來實作，那麼同一套代碼就可以在這兩個平台上運作了。WebView 主要是通過 HTML 來建構自己的界面，再将其顯示在各個平台的 WebView 中。但是它預設是不能調用本地的一些服務的（比如相機、 藍牙等），是以需要通過 JavaScript 進行橋接調用Native的一些代碼來完成某些功能。除此之外，它本身的體驗、性能都并不理想。
2.1.2、React Native
在尋求最佳跨平台解決方案的過程中，無疑 React Native 是之前最優秀的一個。React Native (簡稱RN) 是Facebook于2015年4月開源的跨平台移動應用開發架構，是 Facebook 早先開源的JS架構 React 在原生移動應用平台的衍生産物，目前支援 iOS 和 Android 兩大平台。
React Native 使用 JavaScript 語言，類似于 HTML 的 JSX（JSX是一個看起來很像XML 的JavaScript 文法擴充），以及 CSS 來開發移動應用，熟悉 Web 前端開發的技術人員隻需很少的學習就可以進入移動應用開發領域。相對于 WebView 而言，React Native 在保留基本渲染能力的基礎上，用原生自帶的 UI 元件實作核心的渲染引擎，進而保證了良好的渲染性能。但是，由于 React Native 的本質是通過 JavaScript VM 調用原生接口，通信相對比較低效，而且架構本身不負責渲染，而是是間接通過原生進行渲染的。在 React Native 上做出非常多貢獻的 Airbnb 之前就宣布放棄 React Native，而轉向 Native 進行開發。
2.1.3、Flutter
Flutter 是 Google 推出并開源的移動應用開發架構，主打跨平台、高保真、高性能。開發者可以通過 Dart 語言開發 App，一套代碼同時運作在 iOS 和 Android 平台。從Flutter架構上來看，主要分為 Framework、Engine、Embedder：
Flutter Framework：這是一個純 Dart 實作的 SDK，它實作了一套基礎庫，自底向上：底下兩層（Foundation和Animation、Painting、Gestures）在 Google 的一些視訊中被合并為一個Dart UI 層，對應的是 Flutter 中的 dart:ui 包，它是 Flutter 引擎暴露的底層 UI 庫，提供動畫、手勢及繪制能力。Rendering 層，這一層是一個抽象的布局層，它依賴于 Dart UI 層，Rendering 層會建構一個 UI 樹，當 UI 樹有變化時，會計算出有變化的部分，然後更新 UI 樹，最終将 UI 樹繪制到螢幕上，這個過程類似于 React 中的虛拟 DOM 。Rendering 層可以說是 Flutter UI 架構最核心的部分，它除了确定每個 UI 元素的位置、大小之外還要進行坐标變換、繪制(調用底層 dart:ui )。Widgets 層是 Flutter 提供的的一套基礎元件庫，在基礎元件庫之上，Flutter 還提供了 Material 和 Cupertino 兩種視覺風格的元件庫。Flutter 開發的大多數場景，隻是和這兩層打交道。
Flutter Engine：這是一個純 C++ 實作的 SDK，其中包括了 Skia 引擎、Dart 運作時、文字排版引擎等。在代碼調用 dart:ui 庫時，調用最終會走到 Engine 層，然後實作真正的繪制邏輯。
Embedder：嵌入層，即把 Flutter 嵌入到各個平台上去，包括渲染 Surface 設定、線程設定以及插件等。
接下來，可以看看 Flutter 與 Native、React Native 之間的對比。
Android Native App 在繪圖的時候，要先調用 Android 架構的 Java 代碼，然後再調用 Skia（C/C++）繪圖引擎代碼，最後生成的 CPU 或者 GPU 指令，在裝置上完成繪圖。
React Native 首先要調用架構本身的 JavaScript 代碼，然後再調用 Android 架構的 Java 代碼，然後調用 Skia，這比 Native App 嚴格多出了一個步驟，是以它的這個性能肯定是不及原生的，但是在 Flutter App 中并不是這樣。
Flutter APP 在繪圖的時候，是先調用 Flutter 架構的 Dart 代碼，然後直接調用 Skia（C/C++）代碼，從下圖可以看出 Flutter 架構代碼完全取代了 Android 的 Java 代碼，是以隻要 Flutter 架構 Dart 代碼的效率可以媲美原生架構的 Java 代碼的時候，那麼 Flutter 的性能就可以媲美原生 App 。
2.2、Flutter的優勢
談到 Flutter 的優勢之前，可以想想 Flutter 到底解決了什麼問題。總結了兩點：提供一種跨平台方案和提高跨平台性能。
提供一種跨平台方案：目前 Flutter 主要在移動端 Android/iOS 雙端跨端，Flutter 的願景是成為一個多端運作的 UI 架構，能夠支援不僅僅是移動端，還包括 Web、桌面、嵌入式裝置。在2019 Google I/O 開發者大會上推出的使用 Flutter 開發 Web 應用的架構，同年9月釋出Flutter 1.9，并将 Flutter web 合入 Flutter 主倉庫。是以 Flutter 提供一種比 WebView、React Native “更能跨”的跨平台方案。
提高跨平台性能：Flutter 性能優勢最主要方面是其接近于 Native 的架構，上層 App 的布局、資料等由 Dart 直接編寫，沒有 JavaScript VM 及橋接轉換部分帶來性能開銷。渲染也不需要再次調用 Native 那一套渲染方式，而是直接使用Skia進行渲染。除此之外，Flutter 還加入了 AOT （Ahead of time）即 “提前編譯” 來送出運作效率。
2.3、Flutter4IoT
在 Flutter for IoT 場景的可行性方面，從平台的角度來，Flutter 利用 Embedder 嵌入層對下層的适配，能夠降低甚至忽略對下層系統及平台的依賴。
從性能的角度，Flutter 的性能優勢接近原生，也能夠在更多資源受限的裝置上運作起來。
從生态的角度，Flutter 跨多端的能力，也能夠為 IoT 系統開發帶來更加豐富的開發者，進而完善開發生态及軟體生态。
從成本的角度，IoT 面向不同硬體、不同行業、不同開發生态也隻需要同一個研發隊伍，利用 Flutter 就能完成各種場景的開發。
綜合來看，Flutter 是比較适合在 IoT 系統開發領域施行的一種方案。
在 Flutter for IoT 應用場景方面，首先可以分析一下 Google 推出 Flutter 的動機。表面上看，Google 推出 Flutter 是幫助開發者解決多端統一開發的問題。但筆者覺得實際上，Google 更深層次的動機是：為 Fuchsia OS 的開發生态及應用生态做鋪墊！
Apple 在其強大的生态閉環完成了一次又一次的戰役：面向智能手表、智能手機、個人電腦分别推出了watchOS、iOS、MacOS 等系統，每種系統生态都在不斷完善和擴大。Google 其實也推出了與之對應 Android Wear、Android、Chrome OS，但我們都可以看到，好像也隻有 Android 生态是成功的。是以 Google 推出了 Fuchsia OS，下一代微核心、跨平台的作業系統。Google 也明白 Android 的成功并不是它想推就能夠推成功的。Google 需要一套大家都願意進來玩的生态，其實那就是 Flutter 。Flutter 先為開發者提供解決跨端開發的能力，解決人力成本等問題。當開發者都進入 Flutter 的生态以後，Fuchsia OS 的應用生态問題也自然而然地解決了。
筆者認為的 Flutter4IoT 應該是：Flutter Lite + AliOS Things = 面向IoT、弱互動、 窄場景的帶屏裝置。
Flutter Lite 是一個 Flutter 的輕量級版本，基本實作 Flutter 的所有功能，并且友善裁剪。
AliOS Things 又是面向IoT領域的作業系統，并且有輕量級的微核心版本，可快速在不同平台上移植。
這樣的組合能夠完成開發生态、應用生态、硬體生态的更好适配， Flutter Lite + AliOS Things 對硬體性能要求可以大大降低，進而更加适合在較窄應用場景的方案上運作，此外，該方案提供一些相對較弱的人機互動。綜合來看，Flutter Lite + AliOS Things 能夠快速開發地帶屏終端的系統應用，并且通過少量修改即可快速移植到新平台上快速落地新項目。
如需更多技術支援，可加入釘釘開發者群，或者關注微信公衆号
更多技術與解決方案介紹，請通路阿裡雲AIoT首頁
https://iot.aliyun.com/