CN110750288B - 原生工程配置方法、装置、电子设备及存储介质 - Google Patents

Abstract

本申请公开了一种原生工程配置方法、装置及电子设备。该方法包括：从指定目录中获取Flutter产物，继而将Flutter产物对应的访问路径配置给资源依赖管理器，然后调用资源依赖管理器，以使资源依赖管理器从访问路径获取Flutter产物，并将获取的Flutter产物添加到原生工程，使得原生工程具备Flutter开发功能。实现了可以使原生工程在不安装Flutter框架的情况下具备Flutter开发功能，使得原生开发人员可以无感知使用Flutter进行开发，提升了开发效率。

Description

原生工程配置方法、装置、电子设备及存储介质

技术领域

本申请涉及互联网技术领域，更具体地，涉及一种原生工程配置方法、装置、电子设备及存储介质。

背景技术

Flutter是一套开源的跨平台开发方案，一次开发多端运行。现有的混合工程方案对于原生开发人员不友好，需要先安装几百兆的Flutter环境，当Flutter工程编译不过时，就会造成卡顿或难以继续开发，严重影响开发效率。

发明内容

鉴于上述问题，本申请提出了一种原生工程配置方法、装置、电子设备及存储介质，以改善上述问题。

第一方面，本申请实施例提供了一种原生工程配置方法，该方法包括：从指定目录中获取Flutter产物，Flutter产物为预先在安装有Flutter框架的工程环境中基于Flutter框架编译得到；将Flutter产物对应的访问路径配置给资源依赖管理器，资源依赖管理器用于加载资源给原生工程；调用资源依赖管理器，以使资源依赖管理器从访问路径获取Flutter产物，并将获取的Flutter产物添加到原生工程，使得原生工程具备Flutter开发功能。

第二方面，本申请实施例提供了一种原生工程配置装置，该装置包括：产物获取模块，用于从指定目录中获取Flutter产物，Flutter产物为预先在安装有Flutter框架的工程环境中基于Flutter框架编译得到；资源配置模块，用于将Flutter产物对应的访问路径配置给资源依赖管理器，资源依赖管理器用于加载资源给原生工程；处理模块，用于调用资源依赖管理器，以使资源依赖管理器从访问路径获取Flutter产物，并将获取的Flutter产物添加到原生工程，使得原生工程具备Flutter开发功能。

第三方面，本申请实施例提供了一种电子设备，包括存储器以及一个或多个处理器；一个或多个程序被存储在存储器中并被配置为由一个或多个处理器执行，一个或多个程序配置用于执行上述第一方面所述的方法。

第四方面，本申请实施例提供了一种计算机可读存储介质，计算机可读存储介质中存储有程序代码，其中，在程序代码由处理器运行时执行上述第一方面所述的方法。

本申请实施例提供的一种原生工程配置方法、装置、电子设备及存储介质，涉及互联网技术领域。本方法通过从指定目录中获取Flutter产物，Flutter产物为预先在安装有Flutter框架的工程环境中基于Flutter框架构建；继而将Flutter产物对应的访问路径配置给资源依赖管理器，资源依赖管理器用于加载资源给原生工程；然后调用资源依赖管理器，以使资源依赖管理器从访问路径获取Flutter产物，并将获取的Flutter产物添加到原生工程，使得原生工程具备Flutter开发功能。从而通过预先在安装有Flutter框架的工程环境中基于Flutter框架编译构建Flutter产物，并将Flutter产物存放到指定目录的方式，使得在配置原生工程的过程中，可以通过将从指定目录中获取的Flutter产物对应的访问路径配置给资源依赖管理器，再调用资源依赖管理器，以使资源依赖管理器从访问路径获取Flutter产物，并将获取的Flutter产物添加到原生工程的方式，使原生工程在不安装Flutter框架的情况下也可以具备Flutter开发功能，实现了原生开发人员可以无感知使用Flutter进行开发，提升了开发效率。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。

图1示出了本申请一实施例提供的一种原生工程配置方法的方法流程图。

图2示出了本申请另一实施例提供的一种原生工程配置方法的方法流程图。

图3示出了图2中的步骤S220的方法流程图。

图4示出了图2中的步骤S230的方法流程图。

图5示出了本申请实施例提供的一种原生工程配置装置的结构框图。

图6示出了本申请实施例提供的一种电子设备的结构框图。

图7示出了本申请实施例的用于保存或者携带实现根据本申请实施例的原生工程配置方法的程序代码的存储单元。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。

Flutter是Google推出并开源的一套跨平台移动应用程序(App)开发框架，其采用Dart(官网、中文网)语言作为开发语言，开发者可以通过Dart语言开发Flutter App，一套代码可同时运行在iOS和Android平台上。Flutter可以快速在iOS和Android上构建高质量的原生用户界面，达到原生应用一样的性能。

然而，对于原生开发人员，若想要使用***官方提出的混合(Flutter)工程方案，需要先安装几百兆的Flutter框架来实现布置Flutter环境，当Flutter工程编译不过时，就会卡死原生开发人员，极大的影响了开发效率。

针对上述的问题，发明人经过长期的研究发现，对于原有的iOS和安卓工程都已经相当庞大，若将Flutter工程桥接到这些工程将会使得iOS和安卓工程更加庞大，从而影响开发效率。为了满足原生开发和混合开发(Flutter开发)人员构建不同角色的诉求，使原生开发人员在不安装Flutter环境的情况下也能启动Flutter开发页面的功能，过渡过程完全无感知，发明人发现，可以通过预先在安装有Flutter框架的工程环境中基于Flutter框架编译构建Flutter产物，并将Flutter产物存放到指定目录的方式，使得在配置原生工程的过程中，可以通过将从指定目录中获取的Flutter产物对应的访问路径配置给资源依赖管理器，再调用资源依赖管理器，以使资源依赖管理器从访问路径获取Flutter产物，并将获取的Flutter产物添加到原生工程的方式，使原生工程在不安装Flutter框架的情况下也可以具备Flutter开发功能，实现了原生开发人员可以无感知使用Flutter进行开发，提升了开发效率。因此，提出了本申请实施例提供的一种原生工程配置方法、装置、电子设备及存储介质。

为了便于详细说明本申请方案，下面先对本申请实施例提供的原生工程配置方法所涉及的原生开发以及混合开发进行简要说明。

原生开发(Native App开发)，是针对IOS、Android等不同的手机操作***要采用不同的语言和框架进行开发，是专门针对不同移动设备而开发有针对性的版本，现在我们接触的IOS、Android两个版本，都是被直接安装到设备里，APP应用所有的UI元素、数据内容、逻辑框架均安装在手机终端上，需要在Android、IOS等移动平台上利用官方提供的开发语言、开发类库、开发工具进行App开发。例如，android利用java、eclipse、Android studio进行开发，IOS利用Objective-C和Xcode进行开发。

Web APP(HTML5)开发，是利用Web技术进行的App开发，可以在手机端浏览器里面打开的网站就称之为web app。Web技术本身需要浏览器的支持才能进行展示和用户交互，因此主要用到的技术是HTML、CSS、Java script以及jQuery、Vue、React等JS框架。

混合开发(Hybrid App开发，也可以理解为原生+H5开发)，是结合原生开发和H5开发的技术，取长补短的一种开发模式，原生代码部分利用WebView插件或者其它的框架为H5提供了一个容器，程序主要的业务实现、界面展示是利用H5相关的Web技术进行实现的。比如现在的京东、淘宝、今日头条等都是采用的混合开发模式。

下面将结合附图具体描述本申请的各实施例。

请参阅图1，示出了本申请一实施例提供的一种原生工程配置方法的流程图，本实施例提供一种原生工程配置方法，可应用上述电子设备，该方法包括：

步骤S110：从指定目录中获取Flutter产物。

其中，Flutter产物为预先在安装有Flutter框架的工程环境中基于Flutter框架编译得到。

为了保证iOS工程和安卓工程在混合开发中的开发效率不受影响，可以将Flutter产物无缝桥接到iOS工程和安卓(android)工程。具体的，由于Flutter的工程结构比较特殊，由Flutter目录再分别包含Native工程的目录(即ios和android两个目录)组成。默认情况下，引入了Flutter框架的原生工程无法脱离父目录进行独立构建和运行，因为它会反向依赖于Flutter框架相关的库和资源。

作为一种实现方式，可以通过修改Flutter框架构建流程将Flutter框架所依赖的库文件、源码和资源直接放置到原生工程的子目录中进行引用。然而在这种方式下，原生工程与Flutter框架的依赖内容还是耦合在本地不够独立。

而作为另一种实现方式，可以将Flutter框架的所有依赖内容都放在独立的远端仓库中，通过引用的方式获取远程仓库中的相关资源，源码和库文件。然而，这种方式使得开发流程变得更加复杂，且额外的增加了开发者的接入成本。且上述两种方式并不能解决原生工程耦合和浸入式的问题。

作为一种改善上述问题的方式，为了实现原生开发人员可以无感知使用Flutter框架，并且减少原生工程与Flutter工程的耦合，可以在原生工程中添加混合工程的脚本和工程配置参数。作为一种实施方式，在原生开发人员需要调用Flutter工程的情况下，可以从指定目录中获取Flutter产物。

其中，指定目录为原生工程中用于存放所生成的Flutter产物的文件目录，由于在安装有Flutter框架的环境中，随着开发的调试，编译得到Flutter产物的路径可能会被随时清除，为了保证构建的Flutter产物的稳定性，可以将Flutter产物保存一份到一个指定相对固定的路径(即指定目录)。

通过从指定目录获取Flutter产物的方式，可以避免原生工程与Flutter框架的依赖内容因耦合在本地不够独立的问题。

步骤S120：将所述Flutter产物对应的访问路径配置给资源依赖管理器。

作为一种方式，与Flutter产物对应的访问路径可以理解为原生工程中，用于存储Flutter产物的路径。可选的，资源依赖管理器用于管理第三方库，资源依赖管理器可以用于加载资源给原生工程(即调用与Flutter工程相关的资源配置供开发人员使用)。其中，不同的***架构对应的资源依赖管理器可以不同。可选的，若为iOS***，那么资源依赖管理器可以为pod工具。其中，pod是mac下的第三方类库管理工具，类似于ubuntu的apt-get工具，pod工具可以帮助用户管理工程中引入的第三方类库，非常便捷，当在工程中需要引入比较大型的类库时可能需要不断的编译引入类库的依赖，使用pod可以一步到位，让工具帮助用户做这个事情，需要说明的是，pod工具仅在ios和mac开发里支持。因而，若为Android***，那么资源依赖管理器可以为maven工具。类似的，若为linux***，那么资源依赖管理器可以为apt-get yum等包管理工具。

作为一种方式，可以将用于存放Flutter产物的路径发送给资源依赖管理器，以便于资源依赖管理器可以通过该路径调用Flutter产物并将Flutter产物加载至原生工程。通过将Flutter产物对应的访问路径配置给资源依赖管理器的方式可以减少资源依赖管理器的数据存储，进而加快开发效率。

步骤S130：调用所述资源依赖管理器，以使所述资源依赖管理器从所述访问路径获取所述Flutter产物，并将获取的所述Flutter产物添加到原生工程，使得所述原生工程具备Flutter开发功能。

作为一种实现方式，若原生工程为iOS***工程，那么可以调用pod工具，由pod工具从与Flutter产物对应的访问路径获取Flutter产物，并将获取的Flutter产物添加至原生工程，以使原生工程具备Flutter开发功能。

作为另一种实现方式，若原生工程为Android***工程，那么可以调用maven工具，由maven工具基于与Flutter产物对应的访问路径获取Flutter产物，并将获取的Flutter产物添加至原生工程，以使原生工程具备Flutter开发功能。

需要说明的是，本实施例中的工程环境可以是未安装Flutter框架的工程环境。

本实施例提供的原生工程配置方法，通过从指定目录中获取Flutter产物，Flutter产物为预先在安装有Flutter框架的工程环境中基于Flutter框架构建；继而将Flutter产物对应的访问路径配置给资源依赖管理器，资源依赖管理器用于加载资源给原生工程；然后调用资源依赖管理器，以使资源依赖管理器从访问路径获取Flutter产物，并将获取的Flutter产物添加到原生工程，使得原生工程具备Flutter开发功能。从而通过预先在安装有Flutter框架的工程环境中基于Flutter框架编译构建Flutter产物，并将Flutter产物存放到指定目录的方式，使得在配置原生工程的过程中，可以通过将从指定目录中获取的Flutter产物对应的访问路径配置给资源依赖管理器，再调用资源依赖管理器，以使资源依赖管理器从访问路径获取Flutter产物，并将获取的Flutter产物添加到原生工程的方式，使原生工程在不安装Flutter框架的情况下也可以具备Flutter开发功能，实现了原生开发人员可以无感知使用Flutter进行开发，提升了开发效率。

请参阅图2，示出了本申请另一实施例提供的一种原生工程配置方法的流程图，本实施例提供一种原生工程配置方法，可应用上述电子设备，该方法包括：

步骤S210：判断是否存在Flutter框架。

作为一种方式，可以通过响应命令which Flutter判断是否存在Flutter框架。通过判断是否存在Flutter框架，可以帮助开发人员快速判断当前的开发模式。

作为一种实施方式，若存在，可以执行以下步骤：

步骤S220：基于所述Flutter框架构建Flutter产物。

作为一种方式，若存在Flutter框架，可以判定当前的开发模式为混合(Flutter)开发模式，那么可以基于Flutter框架构建Flutter产物，Flutter产物在编译得到时可以自动配置给原生工程，以便于原生工程可以调用Flutter产物进行混合开发，关于基于Flutter框架构建Flutter产物的具体内容可以参照后续描述。

作为一种方式，请参阅图3，步骤S220具体可以包括：

步骤S2201：创建目标文件。

其中，目标文件用于保存Flutter框架的路径以及版本号。可选的，本实施例中的目标文件可以为ihaveFlutter文件，当工程构建发生问题时，可以根据ihaveFlutter文件的内容判断是否存在Flutter框架以及Flutter框架对应的Flutter的版本号和路径等内容，可选的，或者可以根据是否存在ihaveFlutter文件判断是否存在Flutter框架，进而判断Flutter框架对应的Flutter的版本号和路径等内容。对应的，当存在ihaveFlutter文件则可以判定为存在Flutter框架。

需要说明的是，对于目标文件“ihaveFlutter文件”，其在创建之初将记录Flutter框架的版本信息和路径，为了后续构建过程中排查问题方便，可以将一些目标信息写入该目标文件。可选的，该目标信息可以包括：执行Flutter创建工程命令是否成功，拷贝和解压文件是否成功，拷贝到指定的哪个目录，以及删除签名和缓存的ios、android build目录是否成功等。

步骤S2202：判断是否存在Flutter框架。

为了减小误判带来的误差，本实施例将在混合开发模式中再次判断是否存在Flutter框架。

步骤S2203：基于所述Flutter框架创建Flutter工程，所述Flutter工程包括第一子工程以及第二子工程。

作为一种实施方式，可以通过响应Flutter packages get命令再次判断存在Flutter框架，再基于Flutter框架创建Flutter工程，Flutter工程包括第一子工程以及第二子工程。其中，第一子工程可以理解为新的ios子工程，第二子工程可以理解为新的android子工程。可选的，第一子工程以及第二子工程为临时生成的子工程。

需要说明的是，在基于Flutter框架创建Flutter工程之前，为了防止当前开发Flutter工程的界面和功能受到历史开发的残留文件的影响，可以清除历史构建的环境数据，该环境数据可以包括历史Flutter框架残留数据以及使用历史Flutter框架构建的子工程(包括ios子工程以及android子工程)。可选的，可以使用Flutter clean命令清除历史构建的环境数据，而该命令有时候会执行失败，为了提升开发性能的可靠性，可以再次删除用于存储历史构建生成的ios子工程以及android子工程的目录(即清空“.ios目录”和“.android目录”)。

步骤S2204：更新与所述Flutter工程的Flutter版本对应的升级文件，并修改所述第一子工程以及第二子工程的配置参数。

可选的，本实施例中的升级文件可以包括podfile和podhelper，配置参数可以包括Flutter工程bug等。

由于Flutter是不断升级的，每次升级都和上一次的版本有一定的差异，主要体现在podfile和podhelper上面，为了使Flutter产物和当前的Flutter版本适配以顺利进行原生开发，可以更新与Flutter工程的Flutter版本对应的升级文件，并修改第一子工程以及第二子工程的配置参数。其中，对于原生项目而言，需要用到开发者内部开发的私有库(即Flutter官方默认不支持)，此时需要添加私有库地址到podfile中，并且资源依赖管理器(即前述的pod工具或是maven工具)需要用到的依赖，Flutter官方默认也是不提供的。本实施例可以自动根据不同的Flutter版本找到对应的podfile和podhelper(可选的，每一个Flutter框架都有一个version文件记录当前的版本号，可以通过找到版本号并进行内容读取获得与当前版本对应的podfile和podhelper)，从而完成Flutter版本的更新。

步骤S2205：将库文件添加至所述Flutter工程，对所述Flutter工程进行编译，得到Flutter产物。

其中，库文件可以是FlutterApp.podspec。

在1.7.8和1.9版本中，重复在项目中添加了Flutter.framework导致编译不过，且默认没有指定特定的最小版本依赖以及证书地址。作为一种方式，为了原生工程能够使用资源依赖管理器直接调用依赖构建的产物APP.framework，可以将库文件添加至Flutter工程，进而实现获得第三方依赖(包括第三方开发的登录、统计、音视频库，常用的ui库，常用的工具组件库等)。

进一步的，对Flutter工程进行编译(即编译构建Flutter build ios/apk)后，即可获得Flutter产物。

步骤S230：将所述Flutter产物存放至所述指定目录。

作为一种方式，请参阅图4，步骤S230具体可以包括：

步骤S2301：将所述app.framework以及Flutter.framework进行压缩处理，并删除所述第三方依赖文件夹的.symlink中的.git文件。

其中，Flutter产物可以包括app.framework、Flutter.framework以及与Flutter功能对应的第三方依赖文件夹。可选的，为了控制上传包的体积，可以将Flutter产物中的app.framework以及Flutter.framework进行压缩处理。可选的，为了不影响Flutter工程的git版本管理，可以删除第三方依赖文件夹的.symlink中的.git文件(第三方依赖git工程自带)。

可选的，app.framework随着工程的开发会变得越来越大，在对app.framework进行压缩上传的过程中，可以同时过滤app.framework的版本控制，同时配置Flutter.framework。

步骤S2302：将进行压缩处理后的所述app.framework以及Flutter.framework和删除了.git文件夹的所述第三方依赖文件夹存放至所述指定目录。

为了可以让原生开发直接使用Flutter开发的界面功能，可以将进行压缩处理后的app.framework以及Flutter.framework和删除了.git文件夹的第三方依赖文件夹存放至指定目录。

可选的，本实施例中的指定目录可以为“IOSFlutterConfig/Flutter目录(以iOS***为例)”。

作为另一种实施方式，若不存在，执行以下步骤：

步骤S240：从指定目录中获取Flutter产物。

作为一种方式，Flutter产物可以包括app.framework以及Flutter.framework，若判定不存在Flutter框架，那么可以执行从指定目录中获取Flutter产物的步骤，具体描述可以参照前述实施例中的描述，在此不再赘述。

需要说明的是，指定目录中的Flutter产物是压缩后存储的，在从指定目录中获取Flutter产物的过程中，可以对Flutter产物中的app.framework以及Flutter.framework进行解压处理。

需要说明的是，在从指定目录中获取Flutter产物之前，为了避免历史目标文件带来的误差，可以删除构建的历史目标文件。其中，历史目标文件存储有历史使用过Flutter框架的路径以及版本号。

步骤S250：删除所述Flutter.framework中所配置的签名。

可选的，由于Flutter.framework中含自带的签名，会影响工程构建，因而为了避免误差，可以删除Flutter.framework中所配置的签名(即自带的签名)。

步骤S260：将所述Flutter产物对应的访问路径配置给资源依赖管理器。

步骤S270：调用所述资源依赖管理器，以使所述资源依赖管理器从所述访问路径获取所述Flutter产物，并将获取的所述Flutter产物添加到原生工程，使得所述原生工程具备Flutter开发功能。

作为一种实施方式，对于原生工程中Flutter工程的使用，可以在升级文件podfile中添加以下代码：

可选的，通过执行脚本自动生成的目录，即可实现在原生工程中启动Flutter，进而实现原生工程在不安装Flutter框架的情况下也可以具备Flutter开发功能，实现了原生开发人员可以无感知使用Flutter进行开发。

本实施例提供的原生工程配置方法，通过预先在安装有Flutter框架的工程环境中基于Flutter框架编译构建Flutter产物，并将Flutter产物存放到指定目录的方式，使得在配置原生工程的过程中，可以通过将从指定目录中获取的Flutter产物对应的访问路径配置给资源依赖管理器，再调用资源依赖管理器，以使资源依赖管理器从访问路径获取Flutter产物，并将获取的Flutter产物添加到原生工程的方式，使原生工程在不安装Flutter框架的情况下也可以具备Flutter开发功能，实现了原生开发人员可以无感知使用Flutter进行开发，提升了开发效率。

请参阅图5，为本申请实施例提供的一种原生工程配置装置的结构框图，本实施例提供一种原生工程配置装置300，运行于电子设备，所述装置300包括：产物获取模块310、资源配置模块320以及处理模块330：

产物获取模块310，用于从指定目录中获取Flutter产物，Flutter产物为预先在安装有Flutter框架的工程环境中基于Flutter框架编译得到。

可选的，所述装置300还可以包括第一删除单元，该第一删除单元可以用于在从指定目录中获取Flutter产物之前，删除构建的历史目标文件，所述历史目标文件存储有历史使用过Flutter框架的路径以及版本号。

可选的，所述装置300还可以包括判断单元，该判断单元可以用于在从指定目录中获取Flutter产物之前，判断是否存在Flutter框架。作为一种实现方式，若不存在，那么可以执行从指定目录中获取Flutter产物。作为另一种实现方式，若存在，那么可以基于Flutter框架构建Flutter产物；将Flutter产物存放至指定目录。

其中，基于Flutter框架构建Flutter产物具体可以包括：创建目标文件，目标文件用于保存Flutter框架的路径以及版本号；判断是否存在Flutter框架；若存在，基于Flutter框架创建Flutter工程，Flutter工程包括第一子工程以及第二子工程；更新与Flutter工程的Flutter版本对应的升级文件，并修改第一子工程以及第二子工程的配置参数；将库文件添加至Flutter工程，对Flutter工程进行编译，得到Flutter产物。可选的，目标文件可以是ihaveFlutter文件，第一子工程可以为新的ios子工程，第二子工程可以为新的android子工程。升级文件可以包括podfile和podhelper，库文件可以包括FlutterApp.podspec，对Flutter工程进行编译可以理解为编译构建Flutter build ios/apk。

作为一种方式，在基于所述Flutter框架创建Flutter工程之前，可以清除历史构建的环境数据，环境数据包括历史Flutter框架残留数据以及使用历史Flutter框架构建的子工程(包括历史构建的ios子工程以及android子工程)，从而可以避免历史构建的环境数据带来的误差。

作为一种方式，Flutter产物可以包括app.framework、Flutter.framework以及与Flutter功能对应的第三方依赖文件夹。可选的，将Flutter产物存放至指定目录可以包括：将app.framework以及Flutter.framework进行压缩处理，并删除第三方依赖文件夹的.symlink中的.git文件；将进行压缩处理后的app.framework以及Flutter.framework和删除了.git文件夹的第三方依赖文件夹存放至指定目录。

资源配置模块320，用于将Flutter产物对应的访问路径配置给资源依赖管理器，所述资源依赖管理器用于加载资源给原生工程。

其中，Flutter产物可以包括app.framework以及Flutter.framework。可选的，所述装置300还可以包括第二删除单元，该第二删除单元可以用于在将Flutter产物对应的访问路径配置给资源依赖管理器之前，删除Flutter.framework中所配置的签名。

处理模块330，用于调用所述资源依赖管理器，以使所述资源依赖管理器从所述访问路径获取所述Flutter产物，并将获取的所述Flutter产物添加到原生工程，使得所述原生工程具备Flutter开发功能。

本实施例提供的一种原生工程配置装置，通过从指定目录中获取Flutter产物，Flutter产物为预先在安装有Flutter框架的工程环境中基于Flutter框架构建；继而将Flutter产物对应的访问路径配置给资源依赖管理器；然后调用资源依赖管理器，以使资源依赖管理器从访问路径获取Flutter产物，并将获取的Flutter产物添加到原生工程，使得原生工程具备Flutter开发功能。从而通过预先在安装有Flutter框架的工程环境中基于Flutter框架编译构建Flutter产物，并将Flutter产物存放到指定目录的方式，使得在配置原生工程的过程中，可以通过将从指定目录中获取的Flutter产物对应的访问路径配置给资源依赖管理器，再调用资源依赖管理器，以使资源依赖管理器从访问路径获取Flutter产物，并将获取的Flutter产物添加到原生工程的方式，使原生工程在不安装Flutter框架的情况下也可以具备Flutter开发功能，实现了原生开发人员可以无感知使用Flutter进行开发，提升了开发效率。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述装置和模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，所显示或讨论的模块相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。

另外，在本申请各个实施例中的各功能模块可以集成在一个处理模块中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。

请参阅图6，基于上述的原生工程配置方法及装置，本申请实施例还提供了一种可以执行前述原生工程配置方法的电子设备12。电子设备12包括存储器122以及相互耦合的一个或多个(图中仅示出一个)处理器124，存储器122以及处理器124之间通信线路连接。存储器122中存储有可以执行前述实施例中内容的程序，而处理器124可以执行存储器122中存储的程序。

其中，处理器124可以包括一个或者多个处理核。处理器124利用各种接口和线路连接整个电子设备12内的各个部分，通过运行或执行存储在存储器122内的指令、程序、代码集或指令集，以及调用存储在存储器122内的数据，执行电子设备12的各种功能和处理数据。可选地，处理器124可以采用数字信号处理(Digital Signal Processing，DSP)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)、可编程逻辑阵列(ProgrammableLogic Array，PLA)中的至少一种硬件形式来实现。处理器124可集成中央处理器(CentralProcessing Unit，CPU)、图像处理器(Graphics Processing Unit，GPU)和调制解调器等中的一种或几种的组合。其中，CPU主要处理操作***、用户界面和应用程序等；GPU用于负责显示内容的渲染和绘制；调制解调器用于处理无线通信。可以理解的是，上述调制解调器也可以不集成到处理器124中，单独通过一块通信芯片进行实现。

存储器122可以包括随机存储器(Random Access Memory，RAM)，也可以包括只读存储器(Read-Only Memory)。存储器122可用于存储指令、程序、代码、代码集或指令集。存储器122可包括存储程序区和存储数据区，其中，存储程序区可存储用于实现操作***的指令、用于实现至少一个功能的指令(比如触控功能、声音播放功能、图像播放功能等)、用于实现前述各个实施例的指令等。存储数据区还可以存储电子设备12在使用中所创建的数据(比如电话本、音视频数据、聊天记录数据)等。

请参考图7，其示出了本申请实施例提供的一种计算机可读存储介质的结构框图。该计算机可读存储介质400中存储有程序代码，所述程序代码可被处理器调用执行上述方法实施例中所描述的方法。

计算机可读存储介质400可以是诸如闪存、EEPROM(电可擦除可编程只读存储器)、EPROM、硬盘或者ROM之类的电子存储器。可选地，计算机可读存储介质400包括非瞬时性计算机可读介质(non-transitory computer-readable storage medium)。计算机可读存储介质400具有执行上述方法中的任何方法步骤的程序代码410的存储空间。这些程序代码可以从一个或者多个计算机程序产品中读出或者写入到这一个或者多个计算机程序产品中。程序代码410可以例如以适当形式进行压缩。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

最后应说明的是：以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不驱使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (11)

1.一种原生工程配置方法，其特征在于，所述方法包括：

从指定目录中获取Flutter产物，所述Flutter产物为预先在安装有Flutter框架的工程环境中基于所述Flutter框架编译得到；

将所述Flutter产物对应的访问路径配置给资源依赖管理器，所述资源依赖管理器用于加载资源给原生工程；

调用所述资源依赖管理器，以使所述资源依赖管理器从所述访问路径获取所述Flutter产物，并将获取的所述Flutter产物添加到原生工程，使得所述原生工程具备Flutter开发功能。

2.根据权利要求1所述的方法，其特征在于，所述Flutter产物包括app.framework以及Flutter.framework，所述将所述Flutter产物对应的访问路径配置给资源依赖管理器的步骤之前，还包括：

删除所述Flutter.framework中所配置的签名。

3.根据权利要求1所述的方法，其特征在于，所述从指定目录中获取Flutter产物的步骤之前，还包括：

判断是否存在Flutter框架；

若不存在，执行所述从指定目录中获取Flutter产物的步骤。

4.根据权利要求3所述的方法，其特征在于，所述方法还包括：

若存在，基于所述Flutter框架构建Flutter产物；

将所述Flutter产物存放至所述指定目录。

5.根据权利要求4所述的方法，其特征在于，所述基于所述Flutter框架构建Flutter产物的步骤包括：

创建目标文件，所述目标文件用于保存所述Flutter框架的路径以及版本号；

判断是否存在Flutter框架；

若存在，基于所述Flutter框架创建Flutter工程，所述Flutter工程包括第一子工程以及第二子工程；

更新与所述Flutter工程的Flutter版本对应的升级文件，并修改所述第一子工程以及第二子工程的配置参数；

将库文件添加至所述Flutter工程，对所述Flutter工程进行编译，得到Flutter产物。

6.根据权利要求5所述的方法，其特征在于，所述基于所述Flutter框架创建Flutter工程的步骤之前，还包括：

清除历史构建的环境数据，所述环境数据包括历史Flutter框架残留数据以及使用历史Flutter框架构建的子工程。

7.根据权利要求4所述的方法，其特征在于，所述Flutter产物包括app.framework、Flutter.framework以及与Flutter功能对应的第三方依赖文件夹，所述将所述Flutter产物存放至所述指定目录的步骤包括：

将所述app.framework以及Flutter.framework进行压缩处理，并删除所述第三方依赖文件夹的.symlink中的.git文件；

将进行压缩处理后的所述app.framework以及Flutter.framework和删除了.git文件夹的所述第三方依赖文件夹存放至所述指定目录。

8.根据权利要求5所述的方法，其特征在于，所述从指定目录中获取Flutter产物的步骤之前，还包括：

删除构建的历史目标文件，所述历史目标文件存储有历史使用过Flutter框架的路径以及版本号。

9.一种原生工程配置装置，其特征在于，所述装置包括：

产物获取模块，用于从指定目录中获取Flutter产物，所述Flutter产物为预先在安装有Flutter框架的工程环境中基于所述Flutter框架编译得到；

资源配置模块，用于将所述Flutter产物对应的访问路径配置给资源依赖管理器，所述资源依赖管理器用于加载资源给原生工程；

处理模块，用于调用所述资源依赖管理器，以使所述资源依赖管理器从所述访问路径获取所述Flutter产物，并将获取的所述Flutter产物添加到原生工程，使得所述原生工程具备Flutter开发功能。

10.一种电子设备，其特征在于，包括存储器；

一个或多个处理器；

一个或多个程序被存储在所述存储器中并被配置为由所述一个或多个处理器执行，所述一个或多个程序配置用于执行权利要求1-8任一所述的方法。

11.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有程序代码，其中，在所述程序代码由处理器运行时执行权利要求1-8任一所述的方法。

Images