Fluttify输出Flutter插件工程详解

[TOC]

系列文章：

（一）Flutter插件开发必备 原生SDK->Dart接口生成引擎Fluttify介绍

（二）如何利用Fluttify开发一个新的Flutter插件

（三）Fluttify输出Flutter插件工程详解

注：目前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();
  });
}
复制代码

内存管理

dart端

Dart端的全部SDK类都会间接继承foundation_fluttify中定义的Ref类，这个类表明是一个引用类，内部含有一个refId字段，保存的是原生端对应对象的id。

目前这个id的实现使用的是对象的hashCode。android端全部的对象都会有hashCode()方法，而ios端只有继承NSObject的类才有hash字段，若是碰到有处理结构体的须要，则用NSValue包装结构体后再调用其hash字段。

当调用SDK类的方法时，会把refId传递给原生，而后原生从全局HEAP中获取到目标对象，而后再在目标对象上进行调用。

dart端还提供了一个kNativeObjectPool全局集合对象，这个集合对象保存了全部的原生对象的引用（即refId），在须要释放对象时，能够对这个集合进行操做。

原生端

foundation_fluttify的原生端提供了一个HEAP全局集合，用来存放插件调用过程当中产生的原生对象。当dart端开始一个方法调用时，原生端便会先从HEAP中获取到目标对象，再调用对应方法。

若是须要把释放一个对象须要把它从HEAP中删除，否则HEAP会一直强引用对象致使一直占用内存。从HEAP中删除后，后续的内存管理就交给系统来处理了。

结语

本文对Fluttify输出的插件工程的结构做了大体的介绍。这些其实也包含了不少我在实现Fluttify过程当中遇到的困难，包括java/objc/dart这些语言在语法上的统一，如何实现回调等等，还有不少不少细节的问题，更有甚者还要给SDK做者的一些骚操做骚写法擦屁股。

最后仍是推荐一波，若是有想要生成插件的老铁也能够联系我(382146139@qq.com)，目前Fluttify还处于内测阶段，不会收取任何费用，有任何反馈均可以往fluttify-feedback提issue，欢迎各位的反馈。