Android端flutter开发上手体会:
- 调试效率有了质的提升。
flutter上面很多东西比较新,按道理来说从接触dart,到开发出一个flutter页面比Android原生开发要慢很多的,但是很重要一点,flutter支持热重载,dart在debug与release模式下分别是JIT,AOT。开发模式下通过JIT模式,修改代码后,ctrl+s 保存一下,自动刷新到Android手机,1s完成编译部署,效率极高。相比之下,目前标准版的Android原生开发,页面调几个像素,需要几分钟编译时间,每天编译个上十次,要个四五十分钟或者一个多小时。
调试时间 | Android | Flutter |
修改UI | >15s | 1s |
修改Java代码 | 常常>1分钟,甚至3到5分钟 | 1s |
一人一天run 20-30次代码 | 1个多小时 | 20秒 |
10人移动团队每人每天run20-30次 | 10多个小时(相当于多招了1-2个开发) | 3分钟多一点 |
- 第三方库支持:
Android中有些库,有线程的gradle支持,用起来比较方便,一行gradle代码可以集成进行,flutter也有pub方式集成,目前开源库虽然没有Android原生的丰富,但增长迅猛,pub库目前上传的方式配置过程比发布gradle插件流程要简单,按照目前的发展势头,相信很快回赶上来。
- bug调试
报错会直接抛在当前页面,而且变红。一般不会立即crash。
下面是一个list没有初始化的bug。
自带的日志,目前没有Android logcat那么丰富,debug稍微费力一点。
- 开发者社区支持
开发过程中碰到问题google比较正常,大量的问题,stackOverFlow上已经有不少答案了,而且还比较活跃。由于flutter在快速的迭代。我搜一个Flutter路由是否支持传参的问题,如果看的文章比较旧写的静态路由不支持传参,就相信了。你可能信以为真,但是最新的API可能已经支持了。
- 协作开发
pull了一下代码,发现代码跑步起来了,方法飘红了。死活编译不通过。最后发现两个人用的不同的flutter sdk。Flutter sdk又更新了!!!所以需要一个像gradle wrapper一样的工具保证多人在开发工程中使用相同的flutter sdk。Github已经看到了flutterw这样开源工程了。
- 集成中碰到的一些问题
问题一:
作为flutter plugin集成进来启动崩溃。给出得日志信息,很难判断出问题出在什么地方。
解决方案:
给flutter plugin配置了flavor。
问题二:
Ios编译正常,Android一直报错。
Flutter插件的包名不支持中间”-”,Android上必须改为:
问题三:
在Android端第一次打开flutterActivity会黑屏
解决方案:
打release包,因为开发调试环境是JIT解释执行,性能比较低,切换到release,打的AOT 机器码执行,性能提升,白屏消失。
- UI布局开发:
Android端原生代码都写在xml里,flutter直接写在类里。
| Android | Flutter |
创建公司 | 154line | 167 line |
选择公司规模 | 22line | 23 line |
Android的一些控件有很多优化,比如recyclerView,对不同类型ViewHolder有做缓存,无限下滑List也没有什么压力。Flutter中这块会不断绘制,list item的复用情况尚未深入探究。
- Flutter与原生通信:
需要自己写对应的解析方法
如果存在很多互相调用的地方,那么这块的代码会膨胀得非常厉害。
MethodChannel并非一种高效的通信方式。会先把native层数据转换成二进制数据,然后再传给dart。
这里面涉及到线程切换,数据拷贝等大量复杂操作。我的理解是,不适合对时间非常sensitive的操作。因为相比之下Android原生的跨进程通信机制Binder,使用mmap内存映射,只需要一次拷贝,所以非常高效。所以微信小程序重写了一个通信模块dart2cpp。
大量实时的群消息从网易的Java sdk走这种通信方式,可能会有一些性能问题。
- 组件化:
目前还没有类似ARouter一样的框架,非常方便地实现flutter plugin之间的方法互调,
Android端调研验证通过的:
- 使用Flutter写UI页面,调用Android原生网络请求代码,返回json数据,在flutter端用dart解析成bean,并展示在UI上。
- Android调用flutter插件,使用dart完成一个页面的UI、网络请求、数据解析等完整流程。
- Flutter工程做flutter package模块化拆分。