环境配置
欲练此功,必先仔细阅读此项目的README文件十遍以上。
flutter_flutter项目,这是我们整个工程的核心,但是很多人都倒在了第一步,其原因,就是——需要使用Dev分支!!! https://gitee.com/openharmony-sig/flutter_flutter/tree/dev/
当前项目已经支持Linux、Mac、Windows环境下使用。首先,按照README的指引,配置好鸿蒙相关的SDK和环境变量,主要是ohpm与sdkmanager,参考README中给出的地址配置即可,需要注意的是版本要对应。目前该项目对应的官方Flutter版本是3.7。
接下来,配置命令行签名工具,同样是按照指引,需要注意的是签名工具这个项目,需要使用gradle7.1和Java11进行编译,在Mac下,可以很方便的使用brew来安装Java环境,在编译签名工具的时候,将环境变量中的Java11的注释放开即可。
shell
export PATH="/opt/homebrew/opt/openjdk@11/bin:$PATH"
编译成功后,会生成./hapsigntool/hap_sign_tool/build/libs/hap-sign-tool.jar文件。
最后,在本地运行鸿蒙Flutter项目的话,需要使用定制化的Flutter Engine,项目如下: https://gitee.com/openharmony-sig/flutter_engine 按照README中的编译方式来进行编译,最后获取产物即可,当然,文档中也提供了鸿蒙编译好的产物,可以直接进行使用,这也是最方便的方法。 https://docs.qq.com/sheet/DUnljRVBYUWZKZEtF?tab=BB08J2
不过还是建议大家去编译下engine,享受下定制engine的快感。
一起准备就绪后,通过flutter doctor -v查看环境配置是否ok,得到下面的内容,就算完成了配置。
shell
flutter doctor
[✓] OpenHarmony toolchain - develop for OpenHarmony devices
• OpenHarmony Sdk location: /Users/xxx/Downloads/harmony_flutter/M1SDK/openharmony, available api versions has [10]
• hdc version 1.3.0
• ohpm version 1.4.0
• signTool location:/Users/xxx/Downloads/harmony_flutter/developtools_hapsigner/autosign
使用下面的指令来创建我们第一个鸿蒙Flutter工程:
shell
flutter create --platforms ohos flutter_test_project
进入创建好的工程,执行下面的指令:
shell
flutter build hap --target-platform ohos-arm64 --debug --local-engine=~/flutter_engine/src/out/ohos_debug_unopt_arm64 -v
local-engine就是前面下载的定制化引擎产物,鸿蒙的产物编译,大多都需要指定引擎地址,编译成功后,会自动进行签名,并生成相应的signed包,执行install指令进行安装。
shell
flutter install ohos/entry/build/default/outputs/default/entry-default-signed.hap
恭喜你,跑不起来,因为4.0系统还不支持模拟器运行,所以,你必须有一台鸿蒙4.0+系统的真机才能运行,如果你的公司和华为有合作,那么现在肯定已经收到鸿蒙的测试机了,连上设备,直接运行就好了。
好了,Flutter的一小步,却是鸿蒙的一大步。
我们来看下现在鸿蒙Flutter工程的结构:
是不是熟悉的味道,纯Flutter工程,整体结构是和官方基本一直的,只是将Android、iOS换成了ohos,这里就是鸿蒙的Native工程,你可以直接使用鸿蒙Dev-ECO Studio来打开这个工程,在它的entry-src-main-ets中,就是对应的插件代码,看到熟悉的GeneratedPluginRegistrant.ets吗,换汤不换药,整体结构改动不大,熟悉下鸿蒙Native代码,很快就可以开发了。
鸿蒙Flutter开发有两种模式,一种是以纯Flutter工程为主,即上面的这种模式,鸿蒙代码写在Flutter工程中,另一种是和Android、iOS开发类似,通过依赖鸿蒙Flutter的编译产物har来进行开发。
从技术的角度来看,第一种方案会更加简单,因为鸿蒙的Native代码已经是申明式了,类似Compose了,所以在鸿蒙Native代码中使用Flutter页面是非常简单的一件事,甚至可以直接将FlutterPage()当作一个View直接使用,所以鸿蒙Flutter混编会比Android、iOS方便很多。
而另一种方式,通过产物进行依赖,这种方式更加符合三端统一的目标,也更适合团队进行解耦和协作。不过这种方式也有一些问题,那就是Flutter依赖的一些第三方库,同样是需要适配鸿蒙版的,所以在yaml中,相对正常的Flutter项目来说同样需要进行区分。
截止目前,flutter_flutter的build har指令还有bug,会编译失败,还在等待社区解决中。
对于Flutter的第三方库来说,鸿蒙Flutter社区也给出了适配的计划表 https://docs.qq.com/sheet/DVVJDWWt1V09zUFN2?tab=BB08J2 表中的第三方库都是待验证的,有些不需要Native支持的,验证的版本可以直接使用,有些需要Native支持的插件功能,有计划完成时间的,都是已经处理过的。由此可见,鸿蒙Flutter社区的支持还是很快的。
所以大部分的Flutter库,都是可以直接适配的,只有那些依赖Native的插件,才需要适配。
好了,到目前为止,鸿蒙Flutter工程已经初具雏形,整体的适配效果还是不错的,本篇文章是鸿蒙Flutter的第一篇,后续还会对鸿蒙Flutter的混编方案、桥接方法继续讲解。