最近一段时间被Flutter刷屏了，不管是google对Flutter的支持力度，还是国内闲鱼团队对Flutter的热衷程度，都强势捧热了Flutter。但是，Flutter真的是目前最合适的跨平台方案吗？不见得。为什么这么说，这里我们从几个方面来分析。先阐述一下，那什么RN，WEEX之类的就不讨论了，事实证明，这些都是伪命题，连昙花一现的资格都没有，本文不做任何详述，如果你们CTO或者领导让你使用RN或者WEEX直接怼回去，这货绝壁没有资格坐在技术领导人的位子上。

首先我们来看看Flutter的优势：

1、抛开所有原生控件，使用全新的类似游戏开发的引擎来进行页面渲染，流畅性不错

2、可全部使用Flutter也可Native+Flutter结合，比较灵活

3、动态编译运行速度快，几乎是秒级的，远远快于Android原生开发，因为AS Studio的动态编译还需要进行包的传输与安装，当然也是有人开发了AS的控件，借助Java的动态语言特性来实现秒级运行的（AS自带的不太好用）。

除了这几点，我也想不出什么优势了，相比于cocos与unity，Flutter也就算是比较省电吧，其他的可能还不如cocos等（我瞎猜的，毫无任何根据，不过至少生态肯定是不如的）。

Flutter的缺点：

1、万年长谈，兼容性不好，虽然抛开了原生控件，自研引擎绘制UI，但还是有很多原生的功能不得不使用，例如传感器，例如WebView内核，所以就会有各种兼容问题，不单单需要解决Android的兼容，还需要解决Android与iOS之间的兼容，这是一个永远的大坑，只要Android与iOS系统在更新迭代，这个坑就永远填不完。

2、生态不行，Flutter1.12到1.17解决了6000多个bug，官方就没做稳定，如何让别人来做后续生态，典型的例子，视频播放的控件只支持Android5.0以后的系统，之前的全都放弃了，这块要用只能与原生结合。更何况，Flutter官方解决了6000多个bug，你们相信不会产生新的bug吗？

3、风格与原生迥异，目前各移动端团队很少会有完全使用Flutter的情况，因为一旦使用了就表明毫无回转的余地。然后风格要做到完全一致需要花费很多精力（例如下拉刷新的控件），得不偿失。

4、内存占用过多，虽然可以使用闲鱼的FlutterBoost引擎来解决部分内存问题，但是据我所知，目前闲鱼的引擎还是基于Flutter1.12.13版本，后续版本并不支持，我估计是Flutter官方改动太大，导致闲鱼内部推进速度缓慢。

5、耗电大，号称是局部渲染而不是60FPS的全局渲染，但是就算做的再好耗电肯定还是比原生高

6、UI绘制相当吃力，Android有xml，iOS有故事版，目前Flutter望尘莫及

以上就是我个人对Flutter的一些见解，可能不全对，欢迎指正。

总得来说虽然Flutter有这么多问题，但是光跨平台这个属性就能让很多团队铤而走险了，因为他们没得选，总不能走RN的老路吧，那是会死人死团队的。

好了，这篇文章看到这里我就要开始放大招了，我要明确告诉各位，Flutter并不是最后的唯一解，我们还有更牛逼的。其实这个方案在很早很早之前就已经存在，但是由于入手难度较大被大部分人忽略甚至放弃，那就是C++，当然我们今天的主角不是C++，而是Go。什么Go能作为移动端开发语言？画风这么清奇？这里我们要感谢GoMobile团队，是这个团队的不懈努力才成就了如今移动端+Go的完美组合。为什么说完美呢？这个就要和Go与移动端的结合来讲了，熟知Android JNI开发的都会了解，这个JNI配置与对接简直就是反人类，配置复杂，还各种编译环境依赖。但是你如果使用Go的话，gomobile提供打包成aar与framework库的方法，然后移动端正常对接这个依赖库就行，使用起来原生依赖库一模一样。

看到这里，大部分人都应该明白我说的跨平台方案了，没错，原生负责UI绘制，Go负责业务逻辑实现，专业的事情就要交给专业的人来做，生态、跨平台、性能等等都兼顾到了而且都能做到极致，然后这也是妥妥的MVP开发模式，比起Flutter这个方案香不香，诱不诱惑，心动不如行动，赶紧去实践起来吧。

附上github demo地址，学习起来更方便：https://github.com/zerochl/FlutterGo