flutter主要是為了google自己的新系統Fuchsia OS打造的。現在Fuchsia OS還沒有ready，為了提前推廣，就搞了一把跨平台的營銷而已。

總體來說Widget層設計的不錯，但是最近寫RenderObject屬實覺得設計的不完善。Flutter自帶的Widget涵蓋的布局情景還算廣，但覆蓋不到的地方要實現自己的布局演算法肯定要去動RenderObject，然後體驗就斷崖式下跌。

RenderObject過重，如果用戶要實現自定義布局演算法，哪怕只是微微修改一點，都要跑去擴展RenderBox並且重複大量的的無意義boiler-plate（把boiler-plate實現一遍都兩三百行了，我就只是給Baseline加個偏移，一行代碼的事情，至於嗎）。而且RenderBox（外加各種mixin全家桶）一次性暴露出大量可覆寫方法，有些不能隨便覆寫，有些是肯定會被覆寫（因為基類的方法完全沒法用），由於Dart沒有具體到單個方法的abstract/mustOverride標記，所有這些東西是一股腦暴露在用戶面前的，需要用戶跟著文檔或者抄官方代碼解決。

（比安卓擴寫View的體驗肯定要好，但好不到哪裡去）

同時在RenderObject的演算法內存在大量隱式的代碼約定。代碼約定這玩意沒問題，因為Flutter的性能就靠著這些，但是全是隱式的就有點噁心人了，至少目前的API設計、API命名、Dart類型系統沒有試圖解決這些問題的跡象。大到performLayout不應該被手動調用，小到computeXXXActualBaseline里不允許調用getXXXBaseline，這些都需要使用者自己摸索和遵守編寫規範。寫代碼前要要查看文檔是沒錯，但問題RenderObject是要麼全懂要麼踩雷。

再配合上Dart的null問題+泛型協變問題，導致布局演算法充斥著空檢查和類型強轉。使用ParentDataWidget就會讓代碼充斥無可避免的類型強轉（以及子節點泛型參數是父節點，父節點泛型參數又是子節點這種魔幻場景），甚至有時候都得搬出來covariant關鍵字（這種投降主義關鍵字的出現真的是個謎，八成是Flutter團隊強迫Dart團隊實現的），因為Dart處理泛型協變逆變屬實不行，Flutter框架團隊設計API也只能設計到這裡了。

（這一條比Java還差勁，Java的類型系統好歹努力了）

而且各種組件官方布局演算法里喜聞樂見的遍地null unsafe寫法（switch不能作為expression這一條居功甚偉），等Dart的Null Safety出來之後，要麼漫天打問號感嘆號，要麼祈禱Dart團隊配套的類型推導強大無比吧。

綜上，結合我個人的體驗，我不覺得有多少人有獨立閱讀文檔然後從零擴寫RenderObject的實力。有的話都是專家。Flutter安全區內很不錯，安全區外就有點丑了。

最後說一句，Flutter的布局我個人隱約感覺是完備的，但完備的前提是你得接受某些複雜度O(N^2)的組件再加上各種複雜嵌套和trick，有些情況你自己寫布局演算法輕易就能O(N)還附加一堆常數級時間優化。所以我覺得Flutter最大的意義是把布局計算的過程完全開放了出來。

先評價問題描述。簡單一句話就是你說了兩個不存在的問題。

對ios支持還不是最完善的，有些在ios ui上面呈現的效果還不是跟原生的有些不一樣

無論是 SDK 提供的 Cupertino 還是 Material Design 跟原生呈現效果都不是完全等同的，Flutter 也沒有說過這兩組小部件跟平台對應的原生控制項 100% 等同。

Cupertino 只是 iOS-style，符合 iOS 界面設計語言標準。哪怕是對比 Android 平台的 MD 小部件的設計兩邊都有相當大的區別。Flutter 並不是照搬已存在的東西並重新實現，實際上 Flutter 已提供的部分普遍比原生使用起來方便很多，也存在細微 UI 差異。

如果你的應用需要調用原生的功能就比較麻煩，需要通過插件的方式調用，比如通知，或者需要繼承高德地圖等，可能有些功能還沒有相應的插件或者還不完善。

Flutter 僅僅是 UI（* 3），對於你操作系統的功能 Flutter 並不關心。你如果認為調用原生 API 麻煩是「不完善」，那麼它會永久的不完善下去。因為 Flutter 根本不認為這是個問題。

Flutter 將系統相關的部分交給用戶去實現，提供了實現的途徑。你說的插件是已包裝好的東西，實現插件利用和是原生代碼通信的方式。

如果把一個平台無關的東西沒有支持平台相關的部分當作不完善的話，那等同於在說 C 語言能在 Windows 上跑，但是標準庫沒有內置 Windows 系統 API 是缺陷。

所以你講了兩個壓根不存在的點。至於我認為 Flutter 不完善的部分，待更……

你說的這些都不是問題，真正的問題我覺得目前有兩點。

1.flutter engine佔用的內存太大了。嵌入native頁面時，相當於同一個頁面用兩套引擎在繪製，難以接受。

2.flutter engine的包體積佔用太大。

你說的那些問題，只是麻煩，但是可解。上面兩個問題，短時間不好解。

但如果用Flutter開發全新的App，上面兩個問題都不存在了。所以，用Flutter開發創新類、探索類的App，是目前的一大趨勢。

第一個問題 我不覺得是問題，大概沒有啥商用app雙端顯示差異很大吧，我沒開發過

第二個問題 官方在做pigeon庫，做channel封裝，但是思路太理想化，一般

我覺得問題：

  • 事件傳遞太弱
  • 線程模型太弱，同類型操作都在一個線程里排隊，坑的很
  • widget分類和定位混亂，後期可能出現功能發現困難
  • 不支持3d
  • 據同事說 iOS相關代碼太差

不能熱更新，不能熱更新，不能熱更新。

安卓原生工程師確實可以通過一些思路實現flutter的熱更新，但是純flutter開發的app，肯定沒錢請兩個原生工程師。

這應該是目前最迫切解決的問題了

謝謝邀請，如果單純從業務層來說，或者單純從我們APP來說，我認為 flutter 最大的問題是視頻與圖片的繪製問題

flutter 的視頻模塊非常雞肋，同樣的播放器，碼率會存在降低的情況，這個目前來看，幾乎是無解的……

另外同樣受限於渲染引擎，3d幾乎是無解的

圖片的繪製存在同樣的問題，性能差碼率低，對於大圖壁紙超級絕望

以上，是c站APP很難解決的問題

c站 APP 地址：https://app.clicli.me

其實最大的問題，就是dart，如果換成TS，我相信一堆人會立馬選flutter。

flutter圖片繪製性能極差，尤其大圖與大量圖片同時繪製，內存開銷極大，非常容易crash.

低端機怎麼保持60幀？

推薦閱讀：
相关文章