鸿蒙Flutter实战：18-组合而非替换，现有插件快速鸿蒙化

引言

在对插件鸿蒙化时，除了往期文章现有Flutter项目支持鸿蒙II中讲到的使用 dependency_overrides 来配置鸿蒙适配库的两种方式以外，如果三方插件本身使用了联合插件的形式，也可以通过下面这种方式来添加鸿蒙平台的实现：

dependencies:image_picker: ^1.1.2image_picker_ohos:git:url: "https://gitcode.com/openharmony-sig/flutter_packages.git"path: "packages/image_picker/image_picker_ohos"

这也是一种非常优雅的方式，不用修改插件的代码，直接在项目配置中增加鸿蒙适配库即可。

什么是联合插件？

Federated plugins (联合插件) 是一种将对不同平台的支持分为单独的软件包。所以，联合插件能够使用针对 iOS、Android、Web 甚至是针对汽车 (例如在 IoT 设备上)分别使用对应的 package。除了这些好处之外，它还能够让领域专家在他们最了解的平台上扩展现有平台插件。

联合插件需要以下 package：

面向应用的 package

该 package 是用户使用插件的的直接依赖。它指定了 Flutter 应用使用的 API。

平台 package

一个或多个包含特定平台代码的 package。面向应用的 package 会调用这些平台 package—— 除非它们带有一些终端用户需要的特殊平台功能，否则它们不会包含在应用中。

平台接口 package

将面向应用的 package 与平台 package 进行整合的 package。该 package 会声明平台 package 需要实现的接口，供面向应用的 package 使用。使用单一的平台接口 package 可以确保所有平台 package 都按照各自的方法实现了统一要求的功能。

什么是未整合的联合插件？

相对的，整合的联合插件，也就是说插件在某个平台的实现，被整合进了主package，也就是"面向应用的 package"。如果插件已经整合了ohos实现，如 fluwx，则直接使用即可，无需再添加鸿蒙平台的实现。

如果插件没有整合ohos实现，如 image_picker, 则需要添加鸿蒙平台的实现。：

这种方式称作 “未整合的联合插件”, 在上面的配置中，
image_picker 是一个联合插件, 这里直接使用官方社区的最新版本，观察该插件的 pubspec.yaml 的文件，通过其结构可以发现联合插件的特点, 该插件的依赖项为：

dependencies:image_picker_platform_interface: ^2.10.0...image_picker_android: ^0.8.7image_picker_ios: ^0.8.8

image_picker_platform_interface 是一个抽象层，它定义了平台相关的接口，下面是各个平台的实现，通过拆分成包，以依赖的方式加载，那同样的原理，就可以再添加一条鸿蒙平台的实现包，就可以完成鸿蒙化适配, 也就是上面案例中的 image_picker_ohos：

  image_picker_ohos:git:url: "https://gitcode.com/openharmony-sig/flutter_packages.git"path: "packages/image_picker/image_picker_ohos"

注意事项

需要注意，并非所有的插件都适合这种方式，有两种情况并不适合：

1.插件并非联合插件，也就是将所有平台的实现聚合在一个 package 中，这种建议使用 dependence_override 来覆写插件依赖

2.插件虽然是联合插件，但是鸿蒙化需要修改抽象层代码，典型的如用了 Platform.ohos 这种只有鸿蒙 Flutter SDK 才有的 API，这种也建议使用 dependence_override