CN111008009B - 基于Flutter的业务组件化方法及系统 - Google Patents

Abstract

本发明涉及移动端开发技术领域，提供一种基于Flutter的业务组件化方法，包括：创建flutter主工程和flutter业务工程；所述flutter主工程为flutter application工程类型，所述flutter业务工程为flutter package工程类型；增加flutter主工程对flutter业务工程的依赖；编译增加依赖后的flutter主工程，获得flutter产物；将所述flutter产物接入已有的原生工程；所述原生工程包括Android系统工程或iOS系统工程。本发明提供的技术方案，能够实现Flutter功能模块与原生工程之间的解耦、Flutter功能模块内部各业务模块之间的解耦，从而提高移动端的开发效率。

Description

基于Flutter的业务组件化方法及系统

技术领域

本发明涉及移动端开发技术领域，特别涉及一种基于Flutter的业务组件化方法及一种基于Flutter的业务组件化系统。

背景技术

Flutter是谷歌发布的移动UI(User Interface，用户界面)框架，是一个用于构建跨平台手机app的SDK(Software Development Kit，软件开发工具包)，可以快速地在Android和iOS系统上构建高质量的用户界面。Flutter目前是完全免费、开源的。

目前大部分开发者都是在当前已有的原生Android/iOS中扩展Flutter功能来进行用户界面和业务组件化设计，而不是将已有的移动端app完全Flutter化。即我们目前基于Flutter的业务组件化方案大部分都是原生工程和Flutter工程的混合开发模式。

上述混合开发模式的实现方式为，在已有的Android/iOS开发中引入Flutter功能，主要是以原生的Android/iOS系统工程为主工程将Flutter功能模块以子module(子模块)的方式引入，使已有的原生工程具备Flutter功能，从而可基于Flutter对原生工程的各种业务进行组件化开发和设计。

图1为现有的在原生工程中引入Flutter功能模块的系统架构图。现有技术由于采用了源码集成方式，使得原生工程与Flutter功能模块的耦合度较高，所有的项目开发者都需要安装Flutter环境，导致对不开发Flutter功能的原生开发者产生较大的影响。且在Flutter功能模块内部，所有的业务代码也耦合在一起，无法满足当前业务工程之间需要相互分离的开发模式。以上缺点均导致现有的基于Flutter的业务组件化方案的开发效率较低。

发明内容

有鉴于此，本发明旨在提出一种基于Flutter的业务组件化方法及系统，能够实现Flutter功能模块与原生工程之间的解耦、Flutter功能模块内部各业务模块之间的解耦，从而提高移动端的开发效率。

为达到上述目的，本发明的技术方案是这样实现的：

一种基于Flutter的业务组件化方法，该方法包括：创建flutter主工程和flutter业务工程；所述flutter主工程为flutter application工程类型，所述flutter业务工程为flutter package工程类型；增加所述flutter主工程对所述flutter业务工程的依赖；编译增加依赖后的flutter主工程，获得flutter产物；将所述flutter产物接入已有的原生工程；所述原生工程包括Android系统工程或iOS系统工程。

优选的，在所述flutter主工程的配置文件yaml中增加对所述flutter业务工程的依赖。

进一步的，所述编译增加依赖后的flutter主工程之前，上述方法还包括：创建flutter基础组件工程；所述flutter基础组件工程为flutter plugin工程类型或flutterpackage工程类型；增加所述flutter主工程对所述flutter基础组件工程的依赖。

优选的，在所述flutter主工程的配置文件yaml中增加对所述flutter基础组件工程的依赖。

优选的，所述flutter主工程对所述flutter业务工程的依赖，以及所述flutter主工程对所述flutter基础组件工程的依赖均为pub依赖。

进一步的，当所述原生工程为Android系统工程时，将所述flutter产物接入已有的原生工程包括：在所述Android系统工程中增加与所述flutter主工程的引擎的编译模式相同的编译模式；在所述Android系统工程的配置文件gradle中增加对所述flutter产物的依赖。

进一步的，当所述原生工程为iOS系统工程时，将所述flutter产物接入已有的原生工程包括：在所述iOS系统工程中获取并存储所述flutter产物；在所述iOS系统工程的管理文件pod中增加对所述flutter产物的依赖。

本发明的另一目的在于提出一种基于Flutter的业务组件化系统，能够实现Flutter功能模块与原生工程之间的解耦、Flutter功能模块内部各业务模块之间的解耦，从而提高移动端的开发效率。

为达到上述目的，本发明的技术方案是这样实现的：

一种基于Flutter的业务组件化系统，该系统包括：

创建模块，用于创建flutter主工程和flutter业务工程；所述flutter主工程为flutter application工程类型，所述flutter业务工程为flutter package工程类型；

Flutter依赖添加模块，用于增加所述flutter主工程对所述flutter业务工程的依赖；

编译模块，用于编译增加依赖后的flutter主工程，获得flutter产物；

接入模块，用于将所述flutter产物接入已有的原生工程；所述原生工程包括Android系统工程或iOS系统工程。

进一步的，所述创建模块还用于创建flutter基础组件工程；所述flutter基础组件工程为flutter plugin工程类型或flutter package工程类型；所述Flutter依赖添加模块还用于增加所述flutter主工程对所述flutter基础组件工程的依赖。

进一步的，当所述原生工程为Android系统工程时，所述接入模块包括：

编译模式添加模块，用于在所述Android系统工程中增加与所述flutter主工程的引擎的编译模式相同的编译模式；

Android maven依赖添加模块，用于在所述Android系统工程的配置文件gradle中增加对所述flutter产物的依赖。

进一步的，当所述原生工程为iOS系统工程时，将所述flutter产物接入已有的原生工程包括：在所述iOS系统工程中获取并存储所述flutter产物；所述接入模块包括：iOSpod依赖添加模块，用于在所述iOS系统工程的管理文件pod中增加对所述flutter产物的依赖。

本发明还提供一种计算机存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述基于Flutter的业务组件化方法。

本发明还提供一种终端设备，包括处理器，所述处理器用于执行上述基于Flutter的业务组件化方法。

本发明所述的基Flutter的业务组件化方法及系统，创建了flutterapplication工程类型的flutter主工程和flutter package工程类型的flutter业务工程，在flutter主工程中增加对flutter业务工程的依赖后，编译flutter主工程获得flutter产物，将该flutter产物直接接入已有的原生工程中。由于是采用产物集成的方式，因此，Flutter功能模块与原生工程之间并无耦合性，即实现了Flutter功能模块与原生工程之间的解耦。又由于单独创建了flutterpackage工程类型的flutter业务工程，使得每个flutter业务工程均可独立执行，即实现了Flutter功能模块内部各业务模块之间的解耦。而Flutter功能模块与原生工程之间的解耦、Flutter功能模块内部各业务模块之间的解耦使得不开发Flutter功能的原生开发者不会受Flutter功能的影响，原生开发者对flutter功能的存在无感知；不同的业务开发人员能够方便地接入flutter功能，且能够独立地在各自flutter业务工程中进行业务开发，从而极大地提高了移动端的开发效率。

本发明的其它特征和优点将在随后的具体实施方式部分予以详细说明。

附图说明

构成本发明的一部分的附图用来提供对本发明的进一步理解，本发明的示意性实施方式及其说明用于解释本发明，并不构成对本发明的不当限定。

在附图中：

图1为现有的在原生工程中引入Flutter功能模块的系统架构图；

图2为本发明实施例的方法流程图一；

图3为本发明实施例的方法流程图二；

图4为本发明实施例的系统结构图一；

图5为本发明实施例的系统结构图二；

图6为本发明实施例的系统结构图三；

图7为本发明实施例的整体系统架构图。

具体实施方式

以下结合附图对本发明实施例的具体实施方式进行详细说明。应当理解的是，此处所描述的具体实施方式仅用于说明和解释本发明实施例，并不用于限制本发明实施例。

图2为本发明一实施例的基于Flutter的业务组件化方法的流程图，该方法包括：

步骤S101，创建flutter主工程和flutter业务工程；所述flutter主工程为flutter application工程类型，所述flutter业务工程为flutter package工程类型；

flutter功能模块本身一般存在4种工程类型，分别是flutter application工程类型、flutter plugin工程类型、flutter package工程类型和flutter module工程类型。

其中，flutter application工程类型是flutter的标准应用类型，是一个包含flutter完整运行流程的工程类型，本实施例中创建的flutter主工程就采用这种工程类型。

flutter plugin工程类型是flutter的插件类型，主要作用是将原生功能封装给flutter使用，例如，当我们在flutter环境中需要使用一个日志插件时，最简单的方法就是将原生工程中的日志插件功能进行封装，提供给flutter使用。我们很多基础组件都是使用这种类型来封装很多原生工程中已有的工程组件给flutter层使用。

flutter package工程类型默认是flutter层面的基础库，本实施例中创建的flutter业务工程使用的就是这种工程类型，选择这种类型作为业务组件的好处是，flutter业务只关注flutter代码，而无需关注任何平台相关的功能，因为平台相关的功能由我们提供的flutter plugin类型插件来提供，业务开发人员可以更专注于具体的业务逻辑。

flutter module工程类型就是谷歌官方使用的把flutter功能作为原生工程的子module引入原生工程的工程类型，由于其和原生工程的强耦合性，本发明中没有使用到此种工程类型。

本实施例中，可以使用“flutter create--template＝app主工程名”命令来创建一个flutter application工程类型的flutter主工程，一个原生App(原生工程)只能创建一个flutter主工程。同时，在flutter主工程的内部和外部均增加pub仓库，以方便在后续步骤中flutter主工程对flutter业务工程的依赖。

使用“flutter create--template＝package业务工程名”命令来创建一个flutter package工程类型的flutter业务工程，多个业务方需要各自创建自己的flutter业务工程。

本实施例中，如果需要在flutter主工程中使用通用组件功能，则还需创建flutter基础组件工程，该flutter基础组件工程为flutter plugin工程类型或flutterpackage工程类型。若不需要通用组件功能，可跳过此步。具体地，如果需要使用原生工程中已有的功能，就通过“flutter create--template＝plugin组件工程名”命令来对原生app的功能进行封装以创建对应的插件组件；如果需要使用flutter层的通用基础库中提供的功能，就通过“flutter create--template＝package组件工程名”命令来创建flutter层面的通用基础库。

步骤S102，增加所述flutter主工程对所述flutter业务工程的依赖；

通过步骤S101我们创建了所需的工程，本步骤中，我们需要把创建的工程整合在一起，这种整合主要是通过flutter的版本依赖工具pub来实现。

具体地，在创建的flutter主工程的配置文件yaml中增加对创建的flutter业务工程的依赖。yaml配置文件类似于android系统中的gradle配置文件或者iOS系统中的pod配置文件，yaml配置文件以pubspec.yaml文件形式存在，位于flutter项目的根目录下。若在步骤S101中创建了flutter基础组件工程，如图3所示，则本步骤中还需要增加flutter主工程对flutter基础组件工程的依赖，具体地，在flutter主工程的配置文件yaml中增加对flutter基础组件工程的依赖。同时，通过版本依赖工具pub中的dependency_overrides文件来统一管理基础组件的版本。本实施例中，flutter主工程对flutter业务工程的依赖，以及flutter主工程对flutter基础组件工程的依赖均为pub依赖。

本实施例中所述的增加flutter主工程对flutter业务工程的依赖，就是使flutter主工程依赖于flutter业务工程，即在flutter主工程中可以引用flutter业务工程。在编译过程中，flutter业务工程会在flutter主工程之前编译。同样地，增加flutter主工程对flutter基础组件工程的依赖，就是使flutter主工程依赖于flutter基础组件工程，即在flutter主工程中可以引用flutter基础组件工程。在编译过程中，flutter基础组件工程会在flutter主工程之前编译。

步骤S103，编译增加依赖后的flutter主工程，获得flutter产物；

Flutter使用Dart作为开发语言，其编译模式与Dart相关，但由于Android和iOS生态的差异，flutter衍生出了不同的编译模式，且在不同的开发阶段，flutter的编译模式也不尽相同。例如，开发flutter APP的时候，我们需要使用热重载以方便用户界面快速成型，同时也需要比较高的性能来进行视图渲染，所以flutter在调试过程中使用了KernelSnapshot编译模式，并生成相应的flutter产物。在生产阶段，由于应用需要非常快的速度，所以flutter使用了AOT编译模式。本实施例主要涉及flutter在开发过程中的编译。

步骤S104，将所述flutter产物接入已有的原生工程；所述原生工程包括Android系统工程或iOS系统工程。

当所述原生工程为Android系统工程时，通过“flutter build apk”命令生成flutter产物，将该flutter产物接入原生工程包括：

(1)在Android系统工程中增加与flutter主工程的引擎的编译模式相同的编译模式。本实施例中，由于flutter主工程的引擎的编译模式为java8，因此，首先需要在Android系统工程中增加java8编译模式支持。

(2)在Android系统工程的配置文件gradle中增加对flutter产物的依赖。具体地，上述依赖为maven依赖，以方便我们拉取和集成flutter功能。

当所述原生工程为iOS系统工程时，通过“flutter build ios”命令生成flutter产物，将该flutter产物接入原生工程包括：

(1)在iOS系统工程中获取并存储上述flutter产物；

具体地，在iOS系统工程的管理文件pod中执行下载任务，下载生成的flutter产物压缩包，并将该压缩包解压到当前的工程目录下。

(2)在iOS系统工程的管理文件pod中增加对上述flutter产物的依赖。

具体地，遍历解压后的flutter产物，在pod中对解压后的多个flutter产物分别进行依赖关联，从而将flutter功能集成到iOS系统工程中。

如图7所示，flutter portal工程为flutter主工程，在Flutter空间中创建了3个业务工程，分别为二手package、新房package和租赁package。对flutterportal工程进行编译后，获得flutter产物，将flutter产物通过依赖的方式引入原生工程中，则flutter产物中包含的二手、新房和租赁等业务逻辑的flutter实现被集成到原生工程中。flutter基础库与原生基础库相对应。

本实施例通过上述步骤能够基本实现业务组件化，且各业务可以独立地在各自flutter工程中进行业务开发；同时flutter代码和原生的Android/iOS实现了解耦，对原生开发人员基本无影响。

与上述实施方式相对应地，本发明还提供一种基于Flutter的业务组件化系统，如图4所示，该系统包括：

创建模块201，用于创建flutter主工程和flutter业务工程；其中，flutter主工程为flutter application工程类型，flutter业务工程为flutter package工程类型；

Flutter依赖添加模块202，用于增加所述flutter主工程对所述flutter业务工程的依赖；优选地，在所述flutter主工程的配置文件yaml中增加对所述flutter业务工程的依赖；

编译模块203，用于编译增加依赖后的flutter主工程，获得flutter产物；

接入模块204，用于将所述flutter产物接入已有的原生工程；所述原生工程包括Android系统工程或iOS系统工程。

进一步的，当需要在flutter主工程中使用通用组件功能时，上述创建模块201还用于创建flutter基础组件工程，其中，flutter基础组件工程为flutterplugin工程类型或flutter package工程类型。上述Flutter依赖添加模块202还用于增加所述flutter主工程对所述flutter基础组件工程的依赖；优选地，在flutter主工程的配置文件yaml中增加对flutter基础组件工程的依赖。

进一步的，如图5所示，当所述原生工程为Android系统工程时，所述接入模块204包括：

编译模式添加模块2041，用于在所述Android系统工程中增加与所述flutter主工程的引擎的编译模式相同的编译模式；

Android maven依赖添加模块2042，用于在所述Android系统工程的配置文件gradle中增加对所述flutter产物的依赖。

进一步的，如图6所示，当所述原生工程为iOS系统工程时，将所述flutter产物接入已有的原生工程包括：iOS系统工程获取并存储flutter产物；所述接入模块204包括：

iOS pod依赖添加模块2043，用于在所述iOS系统工程的管理文件pod中增加对所述flutter产物的依赖。

上述系统的工作原理、工作流程等涉及具体实施方式的内容可参见本发明所提供的基于Flutter的业务组件化方法的具体实施方式，此处不再对相同的技术内容进行详细描述。

本发明还提供一种计算机存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现如本实施例所述的基于Flutter的业务组件化方法。

本发明还提供一种终端设备，包括处理器，该处理器用于执行如本发明实施例所述的基于Flutter的业务组件化方法。

本发明所述的基于Flutter的业务组件化方法及系统，创建了flutterapplication工程类型的flutter主工程和flutter package工程类型的flutter业务工程，在flutter主工程中增加对flutter业务工程的依赖后，编译flutter主工程获得flutter产物，将该flutter产物直接接入原生工程中。由于是采用产物集成的方式，因此，Flutter功能模块与原生工程之间并无耦合性，即实现了Flutter功能模块与原生工程之间的解耦。又由于单独创建了flutter package工程类型的flutter业务工程，使得每个flutter业务工程均可独立执行，即实现了Flutter功能模块内部各业务模块之间的解耦。而Flutter功能模块与原生工程之间的解耦、Flutter功能模块内部各业务模块之间的解耦使得不开发Flutter功能的原生开发者不会受Flutter功能的影响，原生开发者对flutter功能的存在无感知；不同的业务开发人员能够方便地接入flutter功能，且能够独立地在各自flutter业务工程中进行业务开发，从而极大地提高了移动端的开发效率。

以上结合附图详细描述了本发明实施例的可选实施方式，但是，本发明实施例并不限于上述实施方式中的具体细节，在本发明实施例的技术构思范围内，可以对本发明实施例的技术方案进行多种简单变型，这些简单变型均属于本发明实施例的保护范围。

另外需要说明的是，在上述具体实施方式中所描述的各个具体技术特征，在不矛盾的情况下，可以通过任何合适的方式进行组合。为了避免不必要的重复，本发明实施例对各种可能的组合方式不再另行说明。

本领域技术人员可以理解实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序存储在一个存储介质中，包括若干指令用以使得单片机、芯片或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，RandomAccess Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

此外，本发明实施例的各种不同的实施方式之间也可以进行任意组合，只要其不违背本发明实施例的思想，其同样应当视为本发明实施例所公开的内容。

Claims (13)

1.一种基于Flutter的业务组件化方法，其特征在于，所述方法包括：

创建flutter主工程和flutter业务工程；所述flutter主工程为flutter application工程类型，所述flutter业务工程为flutter package工程类型；

增加所述flutter主工程对所述flutter业务工程的依赖；

编译增加依赖后的flutter主工程，获得flutter产物；

将所述flutter产物接入已有的原生工程；所述原生工程包括Android系统工程或iOS系统工程。

2.根据权利要求1所述的基于Flutter的业务组件化方法，其特征在于，所述增加所述flutter主工程对所述flutter业务工程的依赖，包括：

在所述flutter主工程的配置文件yaml中增加对所述flutter业务工程的依赖。

3.根据权利要求1所述的基于Flutter的业务组件化方法，其特征在于，所述编译增加依赖后的flutter主工程之前，所述方法还包括：

创建flutter基础组件工程；所述flutter基础组件工程为flutter plugin工程类型或flutter package工程类型；

增加所述flutter主工程对所述flutter基础组件工程的依赖。

4.根据权利要求3所述的基于Flutter的业务组件化方法，其特征在于，所述增加所述flutter主工程对所述flutter基础组件工程的依赖，包括：

在所述flutter主工程的配置文件yaml中增加对所述flutter基础组件工程的依赖。

5.根据权利要求3所述的基于Flutter的业务组件化方法，其特征在于，所述flutter主工程对所述flutter业务工程的依赖，以及所述flutter主工程对所述flutter基础组件工程的依赖均为pub依赖。

6.根据权利要求1或3所述的基于Flutter的业务组件化方法，其特征在于，当所述原生工程为Android系统工程时，将所述flutter产物接入已有的原生工程包括：

在所述Android系统工程中增加与所述flutter主工程的引擎的编译模式相同的编译模式；

在所述Android系统工程的配置文件gradle中增加对所述flutter产物的依赖。

7.根据权利要求1或3所述的基于Flutter的业务组件化方法，其特征在于，当所述原生工程为iOS系统工程时，将所述flutter产物接入已有的原生工程包括：

在所述iOS系统工程中获取并存储所述flutter产物；

在所述iOS系统工程的管理文件pod中增加对所述flutter产物的依赖。

8.一种基于Flutter的业务组件化系统，其特征在于，所述系统包括：

创建模块，用于创建flutter主工程和flutter业务工程；所述flutter主工程为flutter application工程类型，所述flutter业务工程为flutter package工程类型；

Flutter依赖添加模块，用于增加所述flutter主工程对所述flutter业务工程的依赖；

编译模块，用于编译增加依赖后的flutter主工程，获得flutter产物；

接入模块，用于将所述flutter产物接入已有的原生工程；所述原生工程包括Android系统工程或iOS系统工程。

9.根据权利要求8所述的基于Flutter的业务组件化系统，其特征在于，

所述创建模块还用于创建flutter基础组件工程；所述flutter基础组件工程为flutter plugin工程类型或flutter package工程类型；

所述Flutter依赖添加模块还用于增加所述flutter主工程对所述flutter基础组件工程的依赖。

10.根据权利要求8或9所述的基于Flutter的业务组件化系统，其特征在于，当所述原生工程为Android系统工程时，所述接入模块包括：

编译模式添加模块，用于在所述Android系统工程中增加与所述flutter主工程的引擎的编译模式相同的编译模式；

Android maven依赖添加模块，用于在所述Android系统工程的配置文件gradle中增加对所述flutter产物的依赖。

11.根据权利要求8或9所述的基于Flutter的业务组件化系统，其特征在于，当所述原生工程为iOS系统工程时，将所述flutter产物接入已有的原生工程包括：在所述iOS系统工程中获取并存储所述flutter产物；

所述接入模块包括：iOS pod依赖添加模块，用于在所述iOS系统工程的管理文件pod中增加对所述flutter产物的依赖。

12.一种计算机存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至7中任意一项所述的基于Flutter的业务组件化方法。

13.一种终端设备，其特征在于，包括处理器，所述处理器用于执行如权利要求1至7中任意一项所述的基于Flutter的业务组件化方法。

Images