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文件夹下会分成androidios文件夹,分别放置各平台SDK中的类(枚举/接口等)对应的Dart类(枚举/接口等)。android/ios文件夹下还会各自生成:

  • function.g.dart文件:生成的所有顶层函数;
  • type_op.g.dart文件:所有的asis方法,用来判断类型和造型;
  • 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支持mixinmixin正好能够处理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,欢迎各位的反馈。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,271评论 5 476
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,275评论 2 380
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,151评论 0 336
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,550评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,553评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,559评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,924评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,580评论 0 257
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,826评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,578评论 2 320
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,661评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,363评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,940评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,926评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,156评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,872评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,391评论 2 342

推荐阅读更多精彩内容