闲鱼对Flutter-Native混合工程解耦的探索-阿里云开发者社区

开发者社区> 闲鱼技术> 正文

闲鱼对Flutter-Native混合工程解耦的探索

简介: 分手快乐,祝你快乐~

作者:祈晴

1. 闲鱼Flutter现状

闲鱼是第一个使用Flutter混合开发的大型应用,但闲鱼客户端开发最深入体会的痛点就是编译时长影响开发体验。在Flutter+Native这种开发模式下,Native编译速度慢,模块开发无法突破。闲鱼集成了集团众多中间件,很多功能无法通过flutter直接调用,需使用各种channel到native去调用对应功能。总而言之,闲鱼目前Flutter开发面临如下几个痛点:

  • Flutter侧混合编译速度慢,Android首次编译10min+,iOS首次编译20min+
  • 混合栈编程中历史包袱导致IOS/Android双端返回给Flutter侧的数据可能存在不一致性
  • 集成模块开发效率相比模块开发较低,单模块页面测试性能数据无法展开;

2.解决方案一

2.1方案概述

此项目从立项至今已经很长一段时间,由于业务迭代快,native插件满天飞情况下,想要做到工程模块化拆分难度可想而知;如下图是项目立项为模块化拆分,业务方需要将各个业务拆分解耦合,拆分集团中间件,业务封装组件,Native业务代码,Flutter桥代码,Flutter组件库,Flutter侧业务代码等多个模块;项目初衷就是整理代码,提供一个Flutter可运行的干净环境,同时需要让flutter可以获取到native几乎所有能力,但是编译开发调试时候有想要速度快,效率高。能想到的最直接解决方案就是拆包,从0-1建立一个最小壳工程,然后拆分集团基本中间件,封装业务组件,Flutter插件等,如下是整个项目架构:
undefined

日常模块化单页面级需要使用最小壳工程,其内部又channel的声明和实现,通过运行最小壳工程运行得到结果,Flutter侧模块开发通过IOC调用到最小壳工程的channel得到返回结果,最后将模块化开发以一种pub或者git依赖方式集成到闲鱼FWN主工程即可;

2.2 阶段性产出

业务模块化拆分从来都是一种吃力不讨好的活,明知道拆出来有收益,但是投入产出比不足,因此历史包袱代码越来越厚重,以至于下一个接收的人都不敢轻易修改代码;在模块化拆分时候,开始项目时候提出过新起一个干净的工程,然后一步步拆分集团中间件,期间拆出了Mtop/Login/FlutterBoost/UI Plugin,耗时3周/2人,得到部分结果就是新业务,新界面开发满足基本快速迭代开发,缺点也很明显如下所示:

  • 拆分梳理Native的中间件繁琐,工作量巨大,最小化壳工程耗时3周/2人
  • 推动业务方拆分基础组件库更难,目前项目进展不顺
  • 维护成本高,拆分壳工程运行结果和主工程可能不一致
  • 业务迫切其结果,但投入产出比不足,比如Flutter单页面性能测试,Flutter侧模块化拆分,Fass工程一体基石

3.解决方案二

3.1 换位思考

(1)若自己是业务方,需要为Flutter侧去拆分包,去构建一个最小化壳工程,其成本是巨大的。
(2)Fass工程一体化依赖一个最小化壳工程的Native运行环境去运行Flutter侧代码,可是并非所有的业务方都会提供一个最小化壳工程去运行Fass,那么Fass工程一体化/模块开发如果在集团其他运行环境下进展?
(3)最小化壳工程运行环境无法紧跟Native侧的各种版本,会导致运行结果不一致情况下也不敢随便使用;

如果解决此问题呢?个人提出过跨进程实现方式,在Android端侧跨进程调用实现方式一直很常见的场景,client访问server得结果,而Flutter侧和Native侧不就是client和server双端么?如下图所示,其实Flutter获取数据就是通过MethodChannel/EventChannel获取,因此可以换一种方式思考?
undefined

3.2 IPC跨进程通信,Android Binder

期间在Android侧我使用过Android Binder去实现,新起一个APP做为壳工程,其内部实现了各种插件去访问主工程服务,获取结果然后返回给壳工程的Flutter调用,但是维护成本依然在;同时iOS侧没有对应的实现机制,因此此方式被抛弃;

3.3 具体方案:Hook代理+Socket服务

Android开发应该都熟悉hook和插件化技术,其实从之前的Flutter到Native的Chanel架构就可以想到一种思路,既然解决不了Native问题,那就解决Channel的问题吧,Native端侧的IPC方式无法实现,换到Flutter侧和Native侧的Channel通信侧去实现IPC吧。参考业务对于插件化hook机制/IPC机制的理解,结合自身对于flutter channel的理解,可以实现一种利用socket服务去hook method channel和event channel实现方式,去代理客户端的method channel和event channel,将处理结果通过socket交给服务端去处理拿到服务端真正的method channel和event channel数据即可,这才是我心中想要的实现方式就是如此,整个架构图如下:

undefined

客户端是一台手机,服务端也是一台手机,服务端跑闲鱼FWN主工程,客户端跑一个干净的Flutter工程;客户端先通过Flutter侧代码去找使用本端有对应的Channel,如果有则使用返回结果,如果没有则通过Socket请求结果到服务端主工程上,主工程根据Socket定义的协议字段去解析然后发起一个channel拿结果,之后通过socket将解决返回给客户端,客户端拿到了socket结果数据后执行想要的渲染方式即可;

或许你有质疑点:比如为什么要用2台手机,使用一台不可以么?
这里我推荐使用2台手机有如下2个原因:
(1)一台手机运行2个APP,如果server在后台可能会导致进程资源被回收,Socket通信中断;
(2)使用2台手机有一个极大好处是,你运行Android的Flutter侧Client代码,但是往往你需要验证Native侧双端Server代码数据,如果客户端手机/服务端手机是2台,只需要改下客户端的IP地址去请求Android手机的Server还是IOS手机的Server就可以验证结果;

3.4 尝试验证

比如如下的method channel代码如下:

Future<T> invokeMethod<T>(String method, [ dynamic arguments ]) async {
    assert(method != null);
    final ByteData result = await binaryMessenger.send(
      name,
      codec.encodeMethodCall(MethodCall(method, arguments)),
    );
    if (result == null) {
      throw MissingPluginException('No implementation found for method $method on channel $name');
    }
    final T typedResult = codec.decodeEnvelope(result);
    return typedResult;
  }

修复result == null的场景,如果是我们指定的客户端,则通过socket去拿server数据,重点理解Fish MOD:START到Fish MOD:END代码思想就理解了;

Future<T> invokeMethod<T>(String method, [dynamic arguments]) async {
    assert(method != null);
    final ByteData result = await binaryMessenger.send(
      name,
      codec.encodeMethodCall(MethodCall(method, arguments)),
    );
    if (result == null) {
      //Fish MOD:START
      //throw MissingPluginException(
      //      'No implementation found for method $method on channel $name');
      //socket从服务端手机获取值
      final dynamic serverData =
            await SocketClient.methodDataForClient(clientParams);
      //Fish MOD:END
    }
    final T typedResult = codec.decodeEnvelope(result);
    return typedResult;
  }

最后通过此中方式验证了MethodChannel/EventChannel数据正常收发的可行性,后续还需要在业务场景具体实验耕田;

4.结果对比和展望

结果对比:
undefined

无法方案1和方案2最终都可以解决编译运行时长的问题,但方案1在拆分模块和维护模块时候都有很高的成本,运行时长虽然降低了,但是模块化工作量却加大很多,方案2可以完美解决拆分成本和维护成本,但是不足之处就是运行环境苛刻,可操作性不足,其需要2部手机作为运行环境,另针对于一些页面跳转逻辑,可能客户端手机A触发到服务端手机B上,操作性不在同一台手机上;当然方案二虽然有一定缺陷,却可以解决很多问题,因此后续在闲鱼模块化拆分落地项目中,在思考是否有更加完美的解决方法。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
+ 订阅

阿里巴巴集团-闲鱼技术团队官方账号 简历投递:guicai.gxy@alibaba-inc.com

官方博客
开源工具
English