导出jar插件_Fluttify输出的Flutter插件工程详解

系列文章：

yohom：Fluttify输出的Flutter插件工程详解zhuanlan.zhihu.com

yohom：开发Flutter插件必备原生SDK->Dart接口生成引擎`Fluttify`介绍zhuanlan.zhihu.com

yohom：如何使用Fluttify开发一个新的Flutter插件zhuanlan.zhihu.com

注：目前Fluttify本身并不对外开放，但是内测阶段可以免费为你生成插件，只要提供android端的jar/aar和ios端的framework/.h+.a，或者maven坐标和cocoapods名称即可，联系方法请看文末

工程结构

Fluttify的输出工程是标准的Flutter插件工程，其中输出的原生语言是java(android)和objc(ios)。

android端使用java是因为从字节码反编译到java的时候，如果字节码来自kotlin，那么会有一些特殊的标记，导致一些情况下（比如基础类型和对应包装类的混淆）需要多余的工作去适配，为了加强兼容性，所以后期选择了java作为生成的原生语言。

ios端选择objc也是类似的原因，objc的方法转为swift的方法时，方法名会自动转换，一些涉及到介词的方法名都会被转换为swift风格，这也导致了一些额外的工作去转换objc方法名到swift，所以最终选择了objc作为输出语言。

dart端结构

引用自上一篇文章：

Fluttify的产物是一个标准的Flutter的插件工程，所以lib文件夹之上的结构都和普通插件一样。lib文件夹下会分成android和ios文件夹，分别放置各平台SDK中的类(枚举/接口等)对应的Dart类(枚举/接口等)。android/ios文件夹下还会各自生成：

function.g.dart文件：生成的所有顶层函数；
type_op.g.dart文件：所有的as和is方法，用来判断类型和造型；
ios/android.export.g.dart文件：导出所有的ios/android类型；
platformview文件夹：生成的所有PlatformView；

习惯上会在lib文件夹下再加一个dart文件夹，放置对各平台进行抽象的代码，并且最后对外export的时候，只export这个文件夹下的文件。lib文件夹结构概览：
.
├── janalytics_fluttify.dart
└── src
├── android
│ ├── android.export.g.dart
│ ├── cn ... android端对应的dart接口
│ └── type_op.g.dart
├── dart
│ └── janalytics_service.dart
└── ios
├── JANALYTICSBrowseEvent.g.dart
├── ...其他生成文件
├── functions.g.dart
├── ios.export.g.dart
└── type_op.g.dart

原生端结构

原生端生成的文件分成两种。

第一种是PlatformViewFactory类，负责PlatformView的创建，Fluttify会扫描到SDK内所有的View类并为其生成PlatformViewFactory类。第二种是主Plugin类，负责所有的MethodChannel的调用处理。

示例的android端的文件夹结构，ios端类似：

.
└── me└── yohom└── amap_map_fluttify├── AmapMapFluttifyPlugin.java // 主Plugin├── DownloadProgressViewFactory.java // 以下都是PlatformViewFactory├── MapViewFactory.java├── TextureMapViewFactory.java└── WearMapViewFactory.java

语言元素的映射

类

java中的类一般都会有作为命名空间使用的包名，平时使用的时候都会先import，再使用简称来引用。Fluttify实现初期，生成的dart类也是直接使用java类的简称，但这很容易就会出现类名冲突，所以最终决定使用全类名来生成java对应的dart类。其规则为：
java:

package com.test;
class A {}

转换为dart:

class com_test_A {}

在这点上objc就直接了很多，因为objc类本身就没有命名空间，类名就是它的全名，所以objc这边的类名不需要转换直接用到dart类名上即可，规则为：

@interface TestClassA
@end

转换为：

class TestClassA {}

接口

所谓接口在java和objc的语境下都是代表可以多重继承的类型。虽然dart也有隐式接口，但是objc的接口(protocol)可以有实现且子类可以不实现所有的方法，而dart一旦implements了一个隐式接口，就必须实现所有的方法，所以dart的隐式接口不能作为objc的protocol的等价角色。

万幸的是dart支持mixin，mixin正好能够处理objc的protocol特性。

示例
java：

package com.test;interface InterfaceA {}
class ClassA implements InterfaceA {}

转换为dart:

class com_test_ClassA extends java_lang_Object with com_test_Interface {}

objc：

@protocol TestInterfaceA
@end@interface TestClassA
@end

转换为dart:

class TestClassA extends NSObject with TestInterfaceA {}

方法

java，objc以及dart的方法在概念上基本一致，除了objc端的一些指针类型和值类型的区分，其他的都差不多。这里给一个例子阐述一下：
java:

package com.test;
class TestClassA {public String testMethod(int arg) { /* 方法内容 */ }
}

转换为dart:

class com_test_TestClassA {String testMethod(int arg) { /* 调用原生代码 */ }
}

objc:

@interface TestClassA
- (NSString*) testMethod: (NSInteger) arg;
@end

转换为dart:

class TestClassA {String testMethod(int arg) { /* 调用原生代码 */}
}

函数

java没有顶层函数，所以没有需要处理的。

objc的函数实际上就是c函数，而dart也支持顶层函数，且与objc的函数语义上没有太大的出入。

常量

目前支持转换java的类常量到dart的类常量。

回调

回调分为lambda和delegate，不过在Fluttify的生成代码中的角色差不多。

回调的实现主要通过双向的MethodChannel调用来实现，比如说java端有一个方法：

void setCallback(Callback callback) { /* 代码 */ }

生成的dart代码会是这样的：

Future<void> setCallback(Callback callback) async {await MethodChannel('some channel').invokeMethod('some method');// 这里会接收到native端的调用MethodChannel('some channel callback').setMethodHandler((methodResult) {// 处理原生的回调callback.onXXX();});
}