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帧？

推荐阅读：
相关文章