CN112965731A - 基于Tinker的Flutter热更新方法、装置、设备及存储介质 - Google Patents

Abstract

本申请涉及研发管理技术领域，揭露一种基于Tinker的Flutter热更新方法、装置、设备及存储介质，其中方法包括通过待更新Flutter对应预设源码，并对预设源码进行编译，以获取目标So文件；若在待更新Flutter中构建了Tinker和存在修补程序加载结果，则根据修补程序加载结果，获取目标路径，使得在后续能够动态加载目标So文件和So文件，便于将So文件进行替换；根据目标路径，获取待更新Flutter对应的So文件；判断目标So文件与So文件是否一致，若目标So文件与So文件不一致，则通过目标So文件替换So文件，得到更新后的Flutter。本申请还涉及区块链技术，预设源码存储于区块链中。本申请实现在对Flutter热更新时，实现动态替换So文件，有利于提高Flutter的热更新效率。

Description

基于Tinker的Flutter热更新方法、装置、设备及存储介质

技术领域

本申请涉及研发管理技术领域，尤其涉及一种基于Tinker的Flutter热更新方法、装置、设备及存储介质。

背景技术

热更新是一种众多App常用的更新方式。简单来说，就是在用户通过下载安装APP之后，打开App时遇到的即时更新。在业内对于Flutter的热更新成为了一个重要领域。

在现有对Flutter的热更新方式中，主要是基于JavaScript的动态化框架，通过引入JavaScript作为逻辑层动态能力的补充，从而实现对Flutter的热更新。但是，由于热更新时通信链路较长，并且Flutter无法在框架层和C++直接建立通信，导致需要借助第三方通信，才能实现Flutter与JS框架建立通信，这样导致对Flutter的热更新效率较为低下。现亟需一种能够提高Flutter的热更新效率的方法。

发明内容

本申请实施例的目的在于提出一种基于Tinker的Flutter热更新方法、装置、设备及存储介质，以提高Flutter的热更新效率。

为了解决上述技术问题，本申请实施例提供一种基于Tinker的Flutter热更新方法，包括：

获取待更新Flutter对应预设源码，并对所述预设源码进行编译，以获取目标So文件；

判断在所述待更新Flutter中是否构建了Tinker和是否存在修补程序加载结果，得到第一判断结果；

若所述第一判断结果为在所述待更新Flutter中构建了所述Tinker和存在所述修补程序加载结果，则根据所述修补程序加载结果，获取目标路径；

根据所述目标路径，获取所述待更新Flutter对应的So文件；

判断所述目标So文件与所述So文件是否一致，得到第二判断结果；

若所述第二判断结果为所述目标So文件与所述So文件不一致，则通过所述目标So文件替换所述So文件，得到更新后的Flutter。

为了解决上述技术问题，本申请实施例提供一种基于Tinker的Flutter热更新装置，包括：

预设源码编译模块，用于获取待更新Flutter对应预设源码，并对所述预设源码进行编译，以获取目标So文件；

第一判断结果获取模块，用于判断在所述待更新Flutter中是否构建了Tinker和是否存在修补程序加载结果，得到第一判断结果；

目标路径获取模块，用于若所述第一判断结果为在所述待更新Flutter中构建了所述Tinker和存在所述修补程序加载结果，则根据所述修补程序加载结果，获取目标路径；

待更新文件获取模块，用于根据所述目标路径，获取所述待更新Flutter对应的So文件；

第二判断结果获取模块，用于判断所述目标So文件与所述So文件是否一致，得到第二判断结果；

更新文件执行模块，用于若所述第二判断结果为所述目标So文件与所述So文件不一致，则通过所述目标So文件替换所述So文件，得到更新后的Flutter。

为解决上述技术问题，本发明采用的一个技术方案是：提供一种计算机设备，包括，一个或多个处理器；存储器，用于存储一个或多个程序，使得一个或多个处理器实现上述任意一项所述的基于Tinker的Flutter热更新方法。

为解决上述技术问题，本发明采用的一个技术方案是：一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现上述任意一项所述的基于Tinker的Flutter热更新方法。

本发明实施例提供了一种基于Tinker的Flutter热更新方法、装置、设备及存储介质。本申请实施例通过获取待更新Flutter对应预设源码，并对预设源码进行编译，以获取目标So文件；判断在待更新Flutter中是否构建了Tinker和是否存在修补程序加载结果，得到第一判断结果；若第一判断结果为在待更新Flutter中构建了Tinker和存在修补程序加载结果，则根据修补程序加载结果，获取目标路径，使得在后续能够动态加载目标So文件和So文件，便于将So文件进行替换；根据目标路径，获取待更新Flutter对应的So文件；判断目标So文件与So文件是否一致，得到第二判断结果；若第二判断结果为目标So文件与So文件不一致，则通过目标So文件替换So文件，得到更新后的Flutter，实现在对Flutter热更新时，修改Tinker加载目标So文件的路径，使得Flutter能够直接加载目标So文件进行替换So文件，不需要借助第三方通信，有利于提高Flutter的热更新效率。

附图说明

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

图1是本申请实施例提供的基于Tinker的Flutter热更新方法的应用环境示意图；

图2根据本申请实施例提供的基于Tinker的Flutter热更新方法的一实现流程图；

图3是本申请实施例提供的基于Tinker的Flutter热更新方法中子流程的一实现流程图；

图4是本申请实施例提供的基于Tinker的Flutter热更新方法中子流程的又一实现流程图；

图5是本申请实施例提供的基于Tinker的Flutter热更新方法中子流程的又一实现流程图；

图6是本申请实施例提供的基于Tinker的Flutter热更新方法中子流程的又一实现流程图；

图7是本申请实施例提供的基于Tinker的Flutter热更新方法中子流程的又一实现流程图；

图8是本申请实施例提供的基于Tinker的Flutter热更新方法中子流程的又一实现流程图；

图9是本申请实施例提供的基于Tinker的Flutter热更新装置示意图；

图10是本申请实施例提供的计算机设备的示意图。

具体实施方式

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同；本文中在申请的说明书中所使用的术语只是为了描述具体的实施例的目的，不是旨在于限制本申请；本申请的说明书和权利要求书及上述附图说明中的术语“包括”和“具有”以及它们的任何变形，意图在于覆盖不排他的包含。本申请的说明书和权利要求书或上述附图中的术语“第一”、“第二”等是用于区别不同对象，而不是用于描述特定顺序。

在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。

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

下面结合附图和实施方式对本发明进行详细说明。

请参阅图1，系统架构100可以包括终端设备101、102、103，网络104和服务器105。网络104用以在终端设备101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备101、102、103通过网络104与服务器105交互，以接收或发送消息等。终端设备101、102、103上可以安装有各种通讯客户端应用，例如网页浏览器应用、搜索类应用、即时通信工具等。

终端设备101、102、103可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。

服务器105可以是提供各种服务的服务器，例如对终端设备101、102、103上显示的页面提供支持的后台服务器。

需要说明的是，本申请实施例所提供的基于Tinker的Flutter热更新方法一般由服务器执行，相应地，基于Tinker的Flutter热更新装置一般配置于服务器中。

应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

请参阅图2，图2示出了基于Tinker的Flutter热更新方法的一种具体实施方式。

需注意的是，若有实质上相同的结果，本发明的方法并不以图2所示的流程顺序为限，该方法包括如下步骤：

S1：获取待更新Flutter对应预设源码，并对预设源码进行编译，以获取目标So文件。

具体的，预设源码是指开发人员需要对Flutter进行更新或者是bug修复时，提前编写的与将要更新或者是bug修复对应的代码，在等待更新时将预设源码发送到服务器，以使得服务器根据预设源码，实现对Flutter的更新。服务器通过获取预设源码，并通过Flutter编译工具对预设源码进行编译，得到编译结果，该编译结果至少包括Native代码、Dart代码的对应文件、资源文件等，再通过对Dart代码的对应文件进行打包，从而得到目标So文件。

其中，So文件是Linux下共享库文件，它的文件格式被称为ELF文件格式。由于Android操作系统的底层基于Linux系统，所以So文件可以运行在Android平台上。Android系统也同样开放了C/C++接口供开发者开发Native程序。由于基于虚拟机的编程语言JAVA更容易被人反编译，因此越来越多的应用将其中的核心代码以C/C++为编程语言，并且以So文件的形式供上层JAVA代码调用，以保证安全性。在本实施例中，目标So文件是用来对待更新Flutter进行更新或者是bug修复的So文件，以实现Flutter的热更新。

其中，Flutter是Google开源的UI工具包，帮助开发者通过一套代码库高效构建多平台精美应用，支持移动、Web、桌面和嵌入式平台。

S2：判断在待更新Flutter中是否构建了Tinker和是否存在修补程序加载结果，得到第一判断结果。

具体的，Tinker是安卓(Android)平台上一个的热更新框架；Tinker支持Java代码加上XML布局和So文件替换的热更新；修补程序加载结果是在通过Tinker对Flutter修复或更新后产生的结果。在本申请实施例中，由于需要Flutter进行热更新，需要在对Flutter热更新之前，需要确保在待更新Flutter中，以及构建好了Tinker，并且已经生成了对应的修改程序加载结果，这样才能够在后续步骤通过替换So文件，从而实现对Flutter的热更新。

S3：若第一判断结果为在待更新Flutter中构建了Tinker和存在修补程序加载结果，则根据修补程序加载结果，获取目标路径。

具体的，若是在待更新Flutter中构建了Tinker和存在修补程序加载结果，说明该待更新Flutter具备热更新的条件，所以需要获取到待更新Flutter的So文件对应的路径，便于后续的目标So文件将其替换，以实现对Flutter的热更新。由于修补程序加载结果为通过Tinker对Flutter修复或更新后产生的结果，其记录着So文件对应的相对路径，通过该相对路径的匹配项，从而构建出目标路径。其中，目标路径为Tinker能够将目标So文件加载给待更新Flutter，使得待更新Flutter能够加载到目标So文件的路径。

S4：根据目标路径，获取待更新Flutter对应的So文件。

具体的，在待更新Flutter中So文件会进行打包存储于So库中。服务器根据目标路径指向，加载待更新Flutter对应的So库，并根据MD5校验的方式，并通过Java load的方式，也即调用system.load()函数，以获取到待更新Flutter对应的So文件。其中，system.load()函数是Tinker框架下的一个函数，用于调用文件。

S5：判断目标So文件与So文件是否一致，得到第二判断结果。

具体的，由于本申请实施例是通过将不同的So文件对待更新Flutter对应的So文件实现替换，从而实现Flutter的热更新，若是目标So文件和待更新Flutter对应的So文件相同，则实现不了Flutter的热更新，故需要先判断目标So文件和待更新Flutter对应的So文件是否一致。

进一步的，判断目标So文件和待更新Flutter对应的So文件的方法包括但不限于字符串判断；该字符串判断是指将更新文件和So文件进行字符串长度或者字符串的每个字符进行匹配，当两者的字符串长度或者符串的每个字符不能够一一匹配，则第二判断结果为目标So文件和So文件不一致。

S6：若第二判断结果为目标So文件与So文件不一致，则通过目标So文件替换So文件，得到更新后的Flutter。

具体的，若第二判断结果为目标So文件与So文件不一致，则需要将目标So文件替换So文件，实现Flutter的热更新。对Flutter之所以无法直接用Tinker进行热更新，这是因为Flutter和Tinker加载目标So文件的路径不同，导致Flutter无法动态加载目标So文件，所以本申请实施例是通过获取Flutter的So文件对应的相对路径，并根据相对路径构建出目标路径，使得Tinker能够目标路径将目标So文件发送到Flutter之中，Flutter接收到目标So文件，将其替换在Flutter之前的So文件，以实现Flutter的热更新。

本实施例中，通过获取待更新Flutter对应预设源码，并对预设源码进行编译，以获取目标So文件；判断在待更新Flutter中是否构建了Tinker和是否存在修补程序加载结果，得到第一判断结果；若第一判断结果为在待更新Flutter中构建了Tinker和存在修补程序加载结果，则根据修补程序加载结果，获取目标路径，使得在后续能够动态加载目标So文件和So文件，便于将So文件进行替换；根据目标路径，获取待更新Flutter对应的So文件；判断目标So文件与So文件是否一致，得到第二判断结果；若第二判断结果为目标So文件与So文件不一致，则通过目标So文件替换So文件，得到更新后的Flutter，实现在对Flutter热更新时，修改Tinker加载目标So文件的路径，使得Flutter能够直接加载目标So文件进行替换So文件，不需要借助第三方通信，有利于提高Flutter的热更新效率。

请参阅图3，图3示出了步骤S6的一种具体实施方式，步骤S6中若第二判断结果为目标So文件与So文件不一致，则通过目标So文件替换So文件，得到更新后的Flutter的具体实现过程，详叙如下：

S61：若第二判断结果为目标So文件与So文件不一致，则更改目标So文件对应的路径和名称，以使目标So文件加载于Tinker中。

具体的，通过在java层更改更新文件对应的路径以及名称，从而达到动态加载目标So文件的目的。如果不对目标So文件对应的名称进行更改，通过Tinker加载目标So文件对应名称的时候，会直接映射到lib目录下的对应文件，使得无法将目标So文件加载到待更新Flutter中，这样会导致动态加载目标So文件失效，从而使得待更新Flutter热更新失败。

S62：根据目标路径，通过Tinker中将目标So文件发送到待更新Flutter中。

具体的，通过上述步骤服务器已经获取到了目标So文件的路径，能够对其进行动态加载，所以再根据目标路径，通过Tinker中将目标So文件发送到待更新Flutter中，能够实现将目标So文件动态加载到待更新Flutter中，解决了因为加载目标So文件的路径不同，导致Flutter无法动态加载新的目标So文件的问题。

S63：在待更新Flutter中，通过目标So文件对So文件进行覆盖，得到更新后的Flutter。

具体的，本申请实施例对待更新Flutter主要是通过动态加载目标So文件，将目标So文件将待更新Flutter原来的So文件进行覆盖，以实现将目标So文件对待更新Flutter原来的So文件的替换，最终实现对待更新Flutter的热更新。

在本实施中，若第二判断结果为目标So文件与So文件不一致，则更改目标So文件对应的路径和名称，以使目标So文件加载于Tinker中，并根据目标路径，通过Tinker中将目标So文件发送到待更新Flutter中，最后在待更新Flutter中，通过目标So文件对So文件进行覆盖，得到更新后的Flutter，解决了因为加载目标So文件的路径不同，导致Flutter无法动态加载新的目标So文件的问题，实现动态加载目标So文件，将目标So文件将待更新Flutter原来的So文件进行替换，实现对待更新Flutter的热更新。

请参阅图4，图4示出了步骤S1的一种具体实施方式，步骤S1中获取待更新Flutter对应预设源码，并对预设源码进行编译，以获取目标So文件的具体实现过程，详叙如下：

S11：获取待更新Flutter对应预设源码。

具体的，在需要对待更新Flutter进行热更新时，服务器获取编辑好的预设源码，从而开始对待更新Flutter进行热更新。

S12：通过Flutter编译工具对预设源码进行编译，得到编译结果。

具体的，Flutter编译工具为Flutter提供用于编译Flutter代码的工具箱，可以用于检验Flutter代码的编写错误，当代码没有编写错误时自动生成可执行文件。由于Flutter的在Android端能够构建产物，纯Flutter开发的话，编译结果为Android应用程序包，对Flutter混合开发的话，将Flutter作为组件，编译结果生成了AAR包。

S13：对编译结果中的Dart代码进行打包，生成目标So文件。

具体的，由于编译结果在生成Android应用程序包和AAR包中，其都包含So库，并且由于Flutter模块中业务代码基本由Dart代码实现，因此实际中热更新基本是更新Dart代码，所以需要将Dart代码进行打包，生成目标So文件，在后续步骤中服务器支持替换So文件，从而实现Flutter的热更新。

本实施例中，通过获取待更新Flutter对应预设源码，再通过Flutter编译工具对预设源码进行编译，得到编译结果，并对编译结果中的Dart代码进行打包，生成目标So文件，实现获取目标So文件，便于后续对待更新Flutter进行替换So文件，实现待更新Flutter的热更新，有利于提高Flutter的热更新效率。

请参阅图5，图5示出了步骤S3的一种具体实施方式，步骤S3中若第一判断结果为在待更新Flutter中构建了Tinker和存在修补程序加载结果，则根据修补程序加载结果，获取目标路径的具体实现过程，详叙如下：

S31：若第一判断结果为在待更新Flutter中构建了Tinker和存在修补程序加载结果，则获取修补程序加载结果对应的文件，作为基础文件。

具体的，若是第一判断结果为在待更新Flutter中构建了Tinker和存在修补程序加载结果，则说明待更新Flutter具体本申请实施例的更新条件，则根据修补程序加载结果对应的文件标识，获取其对应的文件，并将其作为基础文件，便于后续获取相对路径。

S32：遍历基础文件，以获取So文件对应的相对路径。

具体的，通过遍历修补程序加载结果对应的文件，以获取待更新Flutter的So文件对应的相对路径。其中，相对路径是指由文件所在的路径引起的跟其它文件(或文件夹)的路径关系。在本申请中，通过获取So文件对应的相对路径，便于后续匹配和构建出目标路径。

S33：根据相对路径对应的匹配项，构建出目标路径。

具体的，由于相对路径是指由So文件所在的路径引起的跟其它文件(或文件夹)的路径关系，所以根据相对路径的这个特性，也即根据相对路径对应的匹配项，从而构建出目标路径。

本实施例中，若第一判断结果为在待更新Flutter中构建了Tinker和存在修补程序加载结果，则获取修补程序加载结果对应的文件，作为基础文件，再遍历基础文件，以获取So文件对应的相对路径，最后根据相对路径对应的匹配项，构建出目标路径，实现对目标路径的构建，有利于后续将目标So文件动态根据该路径加载于待更新Flutter，以实现待更新Flutter的热更新，有利于提高对Flutter的热更新效率。

请参阅图6，图6示出了步骤S4的一种具体实施方式，步骤S4中根据目标路径，获取待更新Flutter对应的So文件的具体实现过程，详叙如下：

S41：根据目标路径，从待更新Flutter中加载对应的So库。

具体的，由于目标路径可以指向待更新Flutter的So库，所以通过加载So库，便于获取待更新Flutter中的So文件。

S42：通过预设的调用方式，从So库中调用So文件。

具体的，预设的调用方式包括但不限于Java load和loadlibrary等，Java load和loadlibrary都是用来装载库文件。在本申请实施例中，预设的调用方式是通过Java load的方式，从So库中调用So文件。其中，Java load调用方式是通过system.load()函数来实现的；其system.load()函数是Tinker框架下的一个函数，要来调用文件。

S43：通过MD5校验的方式，对So文件进行校验。

具体的，MD5校验的方式(checksum)通过对接收的传输数据执行散列运算来检查数据的正确性。计算出的散列值拿来和随数据传输的散列值比较。如果两个值相同，说明传输的数据完整无误、没有被窜改过，从而可以放心使用。在本申请实施例中，通过MD5校验的方式，判断So文件的完整性，从而从So库中获取So文件。

本实施例中，根据目标路径，从待更新Flutter中加载对应的So库，再通过预设的调用方式，从So库中调用So文件，通过MD5校验的方式，对So文件进行校验,实现对So文件的调用和验证，从而便于后续将其与目标So文件进行对比和替换，从而有利于提高对Flutter的热更新效率。

请参阅图7，图7示出了在步骤S4之前的一种具体实施方式，该实施例包括：

S4A：判断待更新Flutter是否集成了FlutterBoost，得到第三判断结果。

具体的，若是待更新Flutter集成FlutterBoost后，由于待更新Flutter的初始化封装在FlutterBoost对应类里，而FlutterBoost新建了一个引擎类，并且对其传入一个空字符数组，这样导致无法对目标路径的调用，从而使得无法待更新Flutter集成了FlutterBoost，导致待更新Flutter的热更新失败。所以需要判断待更新Flutter是否集成了FlutterBoost。其中，FlutterBoost是对Flutter集成后，生成的可复用的插件。

S4B：若第三判断结果为待更新Flutter集成了FlutterBoost，则根据目标路径构建反射路径。

具体的，若第三判断结果为待更新Flutter集成了FlutterBoost，所以要构建目标路径的反射路径，以使得服务器能够动态加载目标So文件。其中，反射路径是指分别在目标路径和待更新Flutter中获取其对应类别，并根据该对应类别，生成的路径，能够实现将目标路径添加到待更新Flutter中。

S4C：根据反射路径，将目标路径添加到待更新Flutter中。

具体的，将目标路径添加到待更新Flutter中，实现即使待更新Flutter集成了FlutterBoost，服务器也能对目标路径进行调用，从而实现对目标So文件的动态加载。

本实施例中，判断待更新Flutter是否集成了FlutterBoost，得到第三判断结果，若第三判断结果为待更新Flutter集成了FlutterBoost，则根据目标路径构建反射路径，再根据反射路径，将目标路径添加到待更新Flutter中，实现在待更新Flutter集成了FlutterBoost后，服务器构建反射路径，实现服务器能够对目标路径的调用，从而能够完成对待更新Flutter的热更新。

请参阅图8，图8示出了步骤S4B的一种具体实施方式，步骤S4B中若第三判断结果为待更新Flutter集成了FlutterBoost，则根据目标路径构建反射路径的具体实现过程，详叙如下：

S4B1：若第三判断结果为待更新Flutter集成了FlutterBoost，则通过执行Gradle配置的Maven组件，以获取目标路径对应类别。

具体的，Gradle是一个基于Apache Ant和Apache Maven概念的项目自动化构建开源工具，它使用一种基于Groovy的特定领域语言(DSL)来声明项目设置，目前也增加了基于Kotlin语言的kotlin-based DSL，抛弃了基于XML的各种繁琐配置。Maven组件也即maven项目对象模型(POM)，可以通过一小段描述信息来管理项目的构建，报告和文档的项目管理工具软件。在本申请实施例中，通过新建Groovy的模块，将其发布到Maven组件中，再通过Gradle添加此Maven组件，并执行Gradle配置的Maven组件，从而获取到目标路径对应类别。

S4B2：通过执行程序插桩，获取待更新Flutter对应类别。

具体的，程序插桩是在保证被测程序原有逻辑完整性的基础上在程序中插入一些探针(又称为“探测仪”，本质上就是进行信息采集的代码段，可以是赋值语句或采集覆盖信息的函数调用)，通过探针的执行并抛出程序运行的特征数据，通过对这些数据的分析，可以获得程序的控制流和数据流信息，进而得到逻辑覆盖等动态信息，从而实现测试目的的方法。在本申请实施例中，通过执行程序插桩，获取待更新Flutter对应类别，也即获取到待更新Flutter对应的FlutterMain类。

S4B3：通过目标路径对应类别和待更新Flutter对应类别，生成反射路径。

具体的，由于上述步骤获取到了目标路径对应类别和待更新Flutter对应类别，再通过两者的对应类别，构建生成反射路径。

本实施例中，若第三判断结果为待更新Flutter集成了FlutterBoost，则通过执行Gradle配置的Maven组件，以获取目标路径对应类别，通过执行程序插桩，获取待更新Flutter对应类别，通过目标路径对应类别和待更新Flutter对应类别，生成反射路径，实现构建反射路径，便于后续将目标路径加载到待更新Flutter，从而有利于提高对Flutter的热更新效率。

需要强调的是，为进一步保证上述预设源码的私密和安全性，上述预设源码还可以存储于一区块链的节点中。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，该计算机程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，前述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)等非易失性存储介质，或随机存储记忆体(Random Access Memory，RAM)等。

请参考图9，作为对上述图2所示方法的实现，本申请提供了一种基于Tinker的Flutter热更新装置的一个实施例，该装置实施例与图2所示的方法实施例相对应，该装置具体可以应用于各种电子设备中。

如图9所示，本实施例的基于Tinker的Flutter热更新装置包括：预设源码编译模块71、第一判断结果获取模块72、目标路径获取模块73、待更新文件获取模块74、第二判断结果获取模块75及更新文件执行模块76，其中：

预设源码编译模块71，用于获取待更新Flutter对应预设源码，并对预设源码进行编译，以获取目标So文件；

第一判断结果获取模块72，用于判断在待更新Flutter中是否构建了Tinker和是否存在修补程序加载结果，得到第一判断结果；

目标路径获取模块73，用于若第一判断结果为在待更新Flutter中构建了Tinker和存在修补程序加载结果，则根据修补程序加载结果，获取目标路径；

待更新文件获取模块74，用于根据目标路径，获取待更新Flutter对应的So文件；

第二判断结果获取模块75，用于判断目标So文件与So文件是否一致，得到第二判断结果；

更新文件执行模块76，用于若第二判断结果为目标So文件与So文件不一致，则通过目标So文件替换So文件，得到更新后的Flutter。

进一步的，更新文件执行模块76包括：

目标So文件加载单元，用于若第二判断结果为目标So文件与So文件不一致，则更改目标So文件对应的路径和名称，以使目标So文件加载于Tinker中；

目标So文件发送单元，用于根据目标路径，通过Tinker中将目标So文件发送到待更新Flutter中；

目标So文件覆盖单元，用于在待更新Flutter中，通过目标So文件对So文件进行覆盖，得到更新后的Flutter。

进一步的，预设源码编译模块71包括：

预设源码获取单元，用于获取待更新Flutter对应预设源码；

编辑结果获取单元，用于通过Flutter编译工具对预设源码进行编译，得到编译结果；

目标So文件生成单元，用于对编译结果中的Dart代码进行打包，生成目标So文件。

进一步的，目标路径获取模块73包括：

基础文件获取单元，用于若第一判断结果为在待更新Flutter中构建了Tinker和存在修补程序加载结果，则获取修补程序加载结果对应的文件，作为基础文件；

相对路径获取单元，用于遍历基础文件，以获取So文件对应的相对路径；

目标路劲构建单元，用于根据相对路径对应的匹配项，构建出目标路径。

进一步的，待更新文件获取模块74包括：

So库加载单元，用于根据目标路径，从待更新Flutter中加载对应的So库；

So文件调用单元，用于通过预设的调用方式，从So库中调用So文件；

So文件校验单元，用于通过MD5校验的方式，对So文件进行校验。

进一步的，在待更新文件获取模块74之前，该基于Tinker的Flutter热更新装置还包括：

第三判断结果获取模块，用于判断待更新Flutter是否集成了FlutterBoost，得到第三判断结果；

反射路径构建模块，用于若第三判断结果为待更新Flutter集成了FlutterBoost，则根据目标路径构建反射路径；

目标路径添加模块，用于根据反射路径，将目标路径添加到待更新Flutter中。

进一步的，反射路径构建模块包括：

第一类别获取单元，用于若第三判断结果为待更新Flutter集成了FlutterBoost，则通过执行Gradle配置的Maven组件，以获取目标路径对应类别；

第二类别获取单元，用于通过执行程序插桩，获取待更新Flutter对应类别；

发射路径生成单元，用于通过目标路径对应类别和待更新Flutter对应类别，生成反射路径。

需要强调的是，为进一步保证上述预设源码的私密和安全性，上述预设源码还可以存储于一区块链的节点中。

为解决上述技术问题，本申请实施例还提供计算机设备。具体请参阅图10，图10为本实施例计算机设备基本结构框图。

计算机设备8包括通过系统总线相互通信连接存储器81、处理器82、网络接口83。需要指出的是，图中仅示出了具有三种组件存储器81、处理器82、网络接口83的计算机设备8，但是应理解的是，并不要求实施所有示出的组件，可以替代的实施更多或者更少的组件。其中，本技术领域技术人员可以理解，这里的计算机设备是一种能够按照事先设定或存储的指令，自动进行数值计算和/或信息处理的设备，其硬件包括但不限于微处理器、专用集成电路(Appl ication Specific Integrated Circuit，ASIC)、可编程门阵列(Field－Programmable Gate Array，FPGA)、数字处理器(Digital Signal Processor，DSP)、嵌入式设备等。

计算机设备可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。计算机设备可以与用户通过键盘、鼠标、遥控器、触摸板或声控设备等方式进行人机交互。

存储器81至少包括一种类型的可读存储介质，可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等。在一些实施例中，存储器81可以是计算机设备8的内部存储单元，例如该计算机设备8的硬盘或内存。在另一些实施例中，存储器81也可以是计算机设备8的外部存储设备，例如该计算机设备8上配备的插接式硬盘，智能存储卡(SmartMedia Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(Flash Card)等。当然，存储器81还可以既包括计算机设备8的内部存储单元也包括其外部存储设备。本实施例中，存储器81通常用于存储安装于计算机设备8的操作系统和各类应用软件，例如基于Tinker的Flutter热更新方法的程序代码等。此外，存储器81还可以用于暂时地存储已经输出或者将要输出的各类数据。

处理器82在一些实施例中可以是中央处理器(Central Processing Unit，CPU)、控制器、微控制器、微处理器、或其他数据处理芯片。该处理器82通常用于控制计算机设备8的总体操作。本实施例中，处理器82用于运行存储器81中存储的程序代码或者处理数据，例如运行上述基于Tinker的Flutter热更新方法的程序代码，以实现基于Tinker的Flutter热更新方法的各种实施例。

网络接口83可包括无线网络接口或有线网络接口，该网络接口83通常用于在计算机设备8与其他电子设备之间建立通信连接。

本申请还提供了另一种实施方式，即提供一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，计算机程序可被至少一个处理器执行，以使至少一个处理器执行如上述的一种基于Tinker的Flutter热更新方法的步骤。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本申请各个实施例的方法。

本发明所指区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链(Blockchain)，本质上是一个去中心化的数据库，是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了一批次网络交易的信息，用于验证其信息的有效性(防伪)和生成下一个区块。区块链可以包括区块链底层平台、平台产品服务层以及应用服务层等。

显然，以上所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例，附图中给出了本申请的较佳实施例，但并不限制本申请的专利范围。本申请可以以许多不同的形式来实现，相反地，提供这些实施例的目的是使对本申请的公开内容的理解更加透彻全面。尽管参照前述实施例对本申请进行了详细的说明，对于本领域的技术人员来而言，其依然可以对前述各具体实施方式所记载的技术方案进行修改，或者对其中部分技术特征进行等效替换。凡是利用本申请说明书及附图内容所做的等效结构，直接或间接运用在其他相关的技术领域，均同理在本申请专利保护范围之内。

Claims (10)

1.一种基于Tinker的Flutter热更新方法，其特征在于，包括：

获取待更新Flutter对应预设源码，并对所述预设源码进行编译，以获取目标So文件；

判断在所述待更新Flutter中是否构建了Tinker和是否存在修补程序加载结果，得到第一判断结果；

若所述第一判断结果为在所述待更新Flutter中构建了所述Tinker和存在所述修补程序加载结果，则根据所述修补程序加载结果，获取目标路径；

根据所述目标路径，获取所述待更新Flutter对应的So文件；

判断所述目标So文件与所述So文件是否一致，得到第二判断结果；

若所述第二判断结果为所述目标So文件与所述So文件不一致，则通过所述目标So文件替换所述So文件，得到更新后的Flutter。

2.根据权利要求1所述的基于Tinker的Flutter热更新方法，其特征在于，所述若所述第二判断结果为所述目标So文件与所述So文件不一致，则通过所述目标So文件替换所述So文件，得到更新后的Flutter，包括：

若所述第二判断结果为所述目标So文件与所述So文件不一致，则更改所述目标So文件对应的路径和名称，以使所述目标So文件加载于所述Tinker中；

根据所述目标路径，通过所述Tinker中将所述目标So文件发送到所述待更新Flutter中；

在所述待更新Flutter中，通过所述目标So文件对所述So文件进行覆盖，得到所述更新后的Flutter。

3.根据权利要求1所述的基于Tinker的Flutter热更新方法，其特征在于，所述获取待更新Flutter对应预设源码，并对所述预设源码进行编译，以获取目标So文件，包括：

获取所述待更新Flutter对应所述预设源码；

通过Flutter编译工具对所述预设源码进行编译，得到编译结果；

对所述编译结果中的Dart代码进行打包，生成所述目标So文件。

4.根据权利要求1所述的基于Tinker的Flutter热更新方法，其特征在于，所述若所述第一判断结果为在所述待更新Flutter中构建了所述Tinker和存在所述修补程序加载结果，则根据所述修补程序加载结果，获取目标路径，包括：

若所述第一判断结果为在所述待更新Flutter中构建了所述Tinker和存在所述修补程序加载结果，则获取所述修补程序加载结果对应的文件，作为基础文件；

遍历所述基础文件，以获取所述So文件对应的相对路径；

根据所述相对路径对应的匹配项，构建出所述目标路径。

5.根据权利要求1所述的基于Tinker的Flutter热更新方法，其特征在于，所述根据所述目标路径，获取所述待更新Flutter对应的So文件，包括：

根据所述目标路径，从所述待更新Flutter中加载对应的So库；

通过预设的调用方式，从所述So库中调用所述So文件；

通过MD5校验的方式，对所述So文件进行校验。

6.根据权利要求1至5任一项所述的基于Tinker的Flutter热更新方法，其特征在于，在根据所述目标路径，获取所述待更新Flutter对应的So文件之前，所述方法还包括：

判断所述待更新Flutter是否集成了FlutterBoost，得到第三判断结果；

若所述第三判断结果为所述待更新Flutter集成了FlutterBoost，则根据所述目标路径构建反射路径；

根据所述反射路径，将所述目标路径添加到所述待更新Flutter中。

7.根据权利要求6所述的基于Tinker的Flutter热更新方法，其特征在于，所述若所述第三判断结果为所述待更新Flutter集成了FlutterBoost，则对所述目标路径构建反射路径，包括：

若所述第三判断结果为所述待更新Flutter集成了FlutterBoost，则通过执行Gradle配置的Maven组件，以获取所述目标路径对应类别；

通过执行程序插桩，获取所述待更新Flutter对应类别；

通过所述目标路径对应类别和所述待更新Flutter对应类别，生成所述反射路径。

8.一种基于Tinker的Flutter热更新装置，其特征在于，包括：

预设源码编译模块，用于获取待更新Flutter对应预设源码，并对所述预设源码进行编译，以获取目标So文件；

第一判断结果获取模块，用于判断在所述待更新Flutter中是否构建了Tinker和是否存在修补程序加载结果，得到第一判断结果；

目标路径获取模块，用于若所述第一判断结果为在所述待更新Flutter中构建了所述Tinker和存在所述修补程序加载结果，则根据所述修补程序加载结果，获取目标路径；

待更新文件获取模块，用于根据所述目标路径，获取所述待更新Flutter对应的So文件；

第二判断结果获取模块，用于判断所述目标So文件与所述So文件是否一致，得到第二判断结果；

更新文件执行模块，用于若所述第二判断结果为所述目标So文件与所述So文件不一致，则通过所述目标So文件替换所述So文件，得到更新后的Flutter。

9.一种计算机设备，其特征在于，包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器执行所述计算机程序时实现如权利要求1至7中任一项所述的基于Tinker的Flutter热更新方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至7中任一项所述的基于Tinker的Flutter热更新方法。

Images