CN114911497A - 一种sdk升级方法、装置以及计算机设备 - Google Patents

Abstract

本公开提供了一种SDK升级方法、装置以及计算机设备，其中，该方法包括：确定软件工具开发包SDK的待升级插件依赖的第三方的资源文件，并将所述资源文件进行重命名处理，得到重命名后的资源文件；将所述SDK的宿主工程的资源合并编译任务的资源合并结果中的所述资源文件替换为所述重命名后的资源文件；调用所述资源合并结果中所述重命名后的资源文件，并对所述待升级插件中依赖所述重命名后的资源文件的代码包进行重命名；基于所述重命名后的资源文件和所述重命名后的代码包编译得到插件APK；所述插件APK用于对所述SDK进行升级处理。

Description

一种SDK升级方法、装置以及计算机设备

技术领域

本公开涉及计算机的技术领域，具体而言，涉及一种SDK升级方法、装置以及计算机设备。

背景技术

软件开发工具包(Software Development Kit，简称SDK)一般都是一些软件工程师为特定的软件包、软件框架、硬件平台、操作系统等建立应用软件时的开发工具的集合。目前，常见的SDK(例如，游戏SDK)自升级方案中，宿主基本是一个空壳，所有的功能均在插件中，同时由于插件逻辑简单，因此，插件的页面功能较为简单，此时，为了实现较为简单的页面功能，基本无需使用很复杂的库，例如，插件中只使用了安卓Android原生提供的应用程序接口(Application Program Interface，简称API)。如果插件的页面功能较为复杂，则需要增加更多的资源库，从而使得插件依赖更多的资源库。针对现有技术中为了实现更加复杂的页面功能从而增加更多资源库的技术方案存在以下缺陷：

(1)、如果插件的页面功能较为复杂，例如使用Support库添加多种页面效果、ConstraintLayout库进行布局管理、Navigation库进行跳转逻辑管理等等，此时只用原生的API而不使用上述依赖库会大大增加开发成本；

(2)、如果插件中依赖这些库，宿主中不引入这些库，此时，如果接入方接入SDK时使用了这些库，同样会造成宿主和插件中存在相同的依赖库，从而导致出现类转换错误的问题。

发明内容

本公开实施例至少提供一种SDK升级方法、装置以及计算机设备。

第一方面，本公开实施例提供了一种SDK升级方法，包括：确定软件工具开发包SDK的待升级插件依赖的第三方的资源文件，并将所述资源文件进行重命名处理，得到重命名后的资源文件；将所述SDK的宿主工程的资源合并编译任务的资源合并结果中的所述资源文件替换为所述重命名后的资源文件；调用所述资源合并结果中所述重命名后的资源文件，并对所述待升级插件中依赖所述重命名后的资源文件的代码包进行重命名；基于所述重命名后的资源文件和所述重命名后的代码包编译得到插件APK；所述插件APK用于对所述SDK进行升级处理。

结合第一方面，本公开实施例提供了第一方面的第一种可能的实施方式，其中：在将所述资源合并结果中的所述资源文件替换为重命名后的资源文件之前，所述方法还包括：遍历所述资源合并结果中第一指定目录下的资源布局文件；根据所述资源布局文件中包含的资源标识信息在所述资源合并结果中确定所述待升级插件依赖的所述资源文件。

结合第一方面和第一方面的第一种可能的实施方式，本公开实施例提供了第一方面的第二种可能的实施方式，其中：所述方法还包括：在将所述SDK的宿主工程的资源合并编译任务的资源合并结果中的所述资源文件替换为所述重命名后的资源文件之后，将所述重命名后的资源文件保存至第一XML文件中，其中，所述第一XML文件与第二XML文件位于不同的存储目录中，所述第二XML文件为所述资源合并结果中存储所述资源文件的XML文件；对所述第一XML文件进行编译，得到所述临时文件，其中，所述临时文件的文件名为所述重命名后的资源文件的文件名；将所述临时文件存放在所述资源合并编译任务的第二指定目录下。

结合第一方面第一种可能的实施方式，本公开实施例提供了第一方面的第三种可能的实施方式，其中：所述将所述资源文件进行重命名处理，得到重命名后的资源文件，包括：确定所述资源合并结果中存储所述资源文件的第二XML文件；将所述第二XML文件的文件参数的参数值替换为重命名后的资源文件的文件名，得到所述重命名后的资源文件；所述文件参数包括：标签值value和/或对象属性名name。

结合第一方面第一种可能的实施方式，本公开实施例提供了第一方面的第四种可能的实施方式，其中：通过以下步骤确定所述XML文件的文件参数的参数值，包括：将所述第二XML文件转换为文档对象；在所述文档对象中获取所述文件参数的参数值。

结合第一方面，本公开实施例提供了第一方面的第五种可能的实施方式，其中：所述方法还包括：在所述宿主工程中添加所述待升级插件依赖的所述资源文件；建立所述待升级插件和所述宿主工程中的资源文件之间的依赖关系。

结合第一方面，本公开实施例提供了第一方面的第六种可能的实施方式，其中：调用所述资源合并结果中重命名后的资源文件，包括：通过所述SDK的宿主工程的资源链接任务在所述资源合并结果中调用所述重命名后的资源文件。

第二方面，本公开实施例还提供一种SDK升级装置，包括：确定单元，用于确定软件工具开发包SDK的待升级插件依赖的第三方的资源文件；第一重命名单元，用于将所述资源文件进行重命名处理，得到重命名后的资源文件；替换单元，用于将所述SDK的宿主工程的资源合并编译任务的资源合并结果中的所述资源文件替换为所述重命名后的资源文件；第二重命名单元，用于调用所述资源合并结果中所述重命名后的资源文件，并对所述待升级插件中依赖所述重命名后的资源文件的代码包进行重命名；编译单元，用于基于所述重命名后的资源文件和所述重命名后的代码包编译得到插件APK；所述插件APK用于对所述SDK进行升级处理。

第三方面，本公开实施例还提供一种计算机设备，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当计算机设备运行时，所述处理器与所述存储器之间通过总线通信，所述机器可读指令被所述处理器执行时执行上述第一方面，或第一方面中任一种可能的实施方式中的步骤。

第四方面，本公开实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述第一方面，或第一方面中任一种可能的实施方式中的步骤。

本公开实施例提供的SDK升级方法、装置以及计算机设备。在本公开技术方案中，可以将待升级插件所依赖的第三方的资源文件替换为重命名之后的资源文件，并对待升级插件中依赖重命名后的资源文件的代码包进行重命名，以基于重命名后的资源文件和代码包编译得到插件APK。通过该处理方式，可以将待升级插件所使用的资源文件进行重命名，并在不改变现有编译方式的前提下，将待升级插件的代码所依赖的资源文件替换为重命名后的资源文件。在接入方接入SDK并使用该资源文件时，由于插件和宿主中所依赖的资源文件不相同，因此，就不会出现类转换错误的问题，进一步地通过上述处理方式能够保证在不增加开发成本的情况下，不会出现类转换错误，以及页面布局错乱的问题。

为使本公开的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本公开实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，此处的附图被并入说明书中并构成本说明书中的一部分，这些附图示出了符合本公开的实施例，并与说明书一起用于说明本公开的技术方案。应当理解，以下附图仅示出了本公开的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了本公开实施例所提供的一种SDK升级方法的流程图；

图2示出了本公开实施例所提供的SDK升级方法中，对待升级插件依赖的原始用户界面UI库进行重命名处理的具体方法的流程图；

图3示出了本公开实施例所提供的SDK升级方法中，另一种对待升级插件依赖的原始用户界面UI库进行重命名的具体方法的流程图；

图4示出了本公开实施例所提供的SDK升级方法中，将待升级插件所依赖的原始用户界面UI库替换为重命名之后的UI库的具体方法的流程图；

图5示出了本公开实施例所提供的另一种SDK升级方法的流程图；

图6示出了本公开实施例所提供的一种SDK升级装置的示意图；

图7示出了本公开实施例所提供的一种计算机设备的示意图。

具体实施方式

为使本公开实施例的目的、技术方案和优点更加清楚，下面将结合本公开实施例中附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本公开一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本公开实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本公开的实施例的详细描述并非旨在限制要求保护的本公开的范围，而是仅仅表示本公开的选定实施例。基于本公开的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本公开保护的范围。

软件开发工具包(Software Development Kit，简称SDK)一般都是一些软件工程师为特定的软件包、软件框架、硬件平台、操作系统等建立应用软件时的开发工具的集合。现有开发技术中，可以采用插件化的技术来实现客户端的开发过程。其中，插件化的技术可以理解为将一个客户端按照宿主和插件的方式进行开发。也即，在插件化技术方案中，包含一个宿主工程和多个插件工程。

在现有的开发环境下，可以对宿主工程进行编译，编译得到宿主应用APK；之后，可以在该开发环境下对插件功能进行编译，生成插件APK。其中，宿主应用又可以理解为主APP，宿主应用可以加载插件APK，宿主应用还可以为插件APK提供基本的类库和功能；每个插件APK可以对应客户端中的一个功能，该插件APK可以由宿主应用进行加载。

经研究发现，在现有的SDK自升级方法中，所有的功能都放在插件中。如果插件的页面功能较为复杂，则需要使用很复杂的库，此时会增加开发成本。如果在插件开发的过程中，在插件中依赖这些复杂的库，但是在宿主中不引入这些库，那么在接入方接入SDK时使用了这些库，同样会造成宿主和插件中存在相同的依赖库，从而导致出现类转换错误的问题。

基于上述研究，本公开提供了一种SDK升级方法、装置以及计算机设备。在本公开技术方案中，可以将待升级插件所依赖的第三方的资源文件替换为重命名之后的资源文件，并对待升级插件中依赖重命名后的资源文件的代码包进行重命名，以基于重命名后的资源文件和代码包编译得到插件APK。通过该处理方式，可以将待升级插件所使用的资源文件进行重命名，并在不改变现有编译方式的前提下，将待升级插件的代码所依赖的资源文件替换为重命名后的资源文件。在接入方接入SDK并使用该资源文件时，由于插件和宿主中所依赖的资源文件不相同，因此，就不会出现类转换错误的问题，进一步地通过上述处理方式能够保证在不增加开发成本的情况下，不会出现类转换错误，以及页面布局错乱的问题。

针对以上方案所存在的缺陷，均是发明人在经过实践并仔细研究后得出的结果，因此，上述问题的发现过程以及下文中本公开针对上述问题所提出的解决方案，都应该是发明人在本公开过程中对本公开做出的贡献。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

为便于对本实施例进行理解，首先对本公开实施例所公开的一种SDK升级方法进行详细介绍，本公开实施例所提供的SDK升级方法的执行主体一般为具有一定计算能力的计算机设备，该计算机设备例如包括：终端设备或服务器或其它处理设备，终端设备可以为用户设备(User Equipment，UE)、移动设备、用户终端、终端、蜂窝电话、无绳电话、个人数字处理(Personal Digital Assistant，PDA)、手持设备、计算设备、车载设备、可穿戴设备等。在一些可能的实现方式中，该SDK升级方法可以通过处理器调用存储器中存储的计算机可读指令的方式来实现。

下面以执行主体为移动终端为例对本公开实施例提供的SDK升级方法加以说明。

实施例一

参见图1所示，为本公开实施例提供的SDK升级方法的流程图，所述方法包括步骤S102～S108，其中：

S102：确定软件工具开发包SDK的待升级插件依赖的第三方的资源文件，并将所述资源文件进行重命名处理，得到重命名后的资源文件。

在本公开实施例中，SDK是向指定客户端APP提供的相应接入功能的集合，在插件化的技术方案中，会将SDK中的功能打包成插件的形式，并对这些插件进行下发。插件所依赖的资源文件中所包含的资源可以是字符串、图片、颜色、控件等资源，插件中的代码在运行时会用到上述描述的资源。

在本公开实施例中，可以先确定SDK中的待升级功能，其中，待升级功能可以为一个或多个。然后，确定待升级功能所对应的成插件，并将该插件确定为待升级插件。之后，可以在资源支持库中确定待升级插件依赖的第三方的资源文件。其中，该第三方的资源文件可以为待升级插件所依赖的原始用户界面UI(User Interface)库，或者，可以为待升级插件所依赖的其他资源库，本公开对此不作具体限定。

在确定出第三方的资源文件之后，可以对该资源文件进行重命名处理。具体实施时，可以通过修改该资源文件所对应的文件参数的参数值方式对该资源文件进行重命名处理。

S104：将所述SDK的宿主工程的资源合并编译任务的资源合并结果中的所述资源文件替换为所述重命名后的资源文件。

在对SDK的宿主工程进行编译的过程中，包含资源合并编译任务(mergeResources)，其中，资源合并编译任务是指将各插件所依赖的资源合并为对应的文件(即，上述资源合并结果)，然后，将该文件存放在指定资源目录(例如，build/intermediates/mergednot-compiled-resources目录)中。

在获取到资源合并结果之后，可以在资源合并结果中查找待升级插件所依赖的资源文件，并将该资源文件替换为重命名后的资源文件。具体实施时，可以将该资源文件中待升级插件依赖的原始用户界面UI库替换为重命名后的UI库。在将原始用户界面UI库进行替换之后，可以得到使用重命名后UI库的新资源文件。

S106：调用所述资源合并结果中所述重命名后的资源文件，并对所述待升级插件中依赖所述重命名后的资源文件的代码包进行重命名。

为了将待升级插件的代码所依赖的资源文件替换为重命名rename后的资源文件，这里，还需要在对资源合并结果中的资源文件进行重命名后，对待升级插件中依赖该重命名后的资源文件的代码也进行重命名处理，从而实现待升级插件的代码能够依赖该重命名rename后的资源文件，也即，能够实现待升级插件的代码在运行的过程中能够成功调用重命名rename后的资源文件中的资源。

具体实施时，可以先获取资源合并结果中待升级插件所依赖的资源文件，并确定资源文件中待升级插件所依赖的原始用户界面UI(User Interface)库；然后，将资源合并结果中原始用户界面UI库替换为重命名后的原始用户界面UI库，从而得到使用重命名之后的UI库的新资源文件。在资源合并结果中对原始用户界面UI库进行替换的过程中，还可以将待升级插件中依赖该原始用户界面UI库的相关代码的包名改成重命名后的包名。在修改完成之后，就可以对外发布(例如，向服务器发布)对应的产物，例如，aar格式的数据包或者jar格式的数据包。在发布对应的产物之后，就可以执行对插件工程的编译过程，从而得到对应的插件APK文件。

S108：基于所述重命名后的资源文件和所述重命名后的代码包编译得到插件APK；所述插件APK用于对所述SDK进行升级处理。

本公开实施例提供的SDK升级方法、装置以及计算机设备。在本公开技术方案中，可以将待升级插件所依赖的第三方的资源文件替换为重命名之后的资源文件，并对待升级插件中依赖重命名后的资源文件的代码包进行重命名，以基于重命名后的资源文件和代码包编译得到插件APK。通过该处理方式，可以将待升级插件所使用的资源文件进行重命名，并在不改变现有编译方式的前提下，将待升级插件的代码所依赖的资源文件替换为重命名后的资源文件。在接入方接入SDK并使用该资源文件时，由于插件和宿主中所依赖的资源文件不相同，因此，就不会出现类转换错误的问题，进一步地通过上述处理方式能够保证在不增加开发成本的情况下，不会出现类转换错误，以及页面布局错乱的问题。

通过上述描述可知，在本公开实施例中，首先目标软件工具开发包SDK中待升级功能所对应的待升级插件，然后，在资源合并结果中确定待升级插件所依赖的第三方的资源文件，并在该资源文件中确定待升级插件所依赖的原始用户界面UI(User Interface)库之后，将该原始用户界面UI库替换为重命名后的UI库，从而得到使用重命名之后的UI库的新资源文件，在重命名之后，向服务器发布对应的产物。

在本公开的一个可选实施方式中，在图1所示实施例的基础上，还包括如下步骤：

步骤S11：在所述宿主工程中添加所述待升级插件依赖的所述资源文件；

步骤S12：建立所述待升级插件和所述宿主工程中的资源文件之间的依赖关系。

在本公开实施例中，在编译得到插件APK之后，还可以在目标软件工具开发包SDK所属宿主工程中添加待升级插件依赖的所述资源文件，例如，可以在宿主工程中添加该资源文件中的原始用户界面UI库。之后，可以建立待升级插件和宿主工程中所添加的资源文件之间的依赖关系。

具体实施时，可以在将原始用户界面UI库添加至宿主工程之后，在宿主工程中添加指示标识，以通过该指示标识确定依赖于该原始用户界面UI库的插件为待升级插件。

在插件开发的过程中，对待升级插件所依赖的资源文件进行重命名之后，使得待升级插件能够依赖使用重命名之后的资源文件。但是，由于重命名之后的资源文件可能还会依赖重命名前的资源文件。因此，还需要在宿主工程中添加该重命名前的资源文件，以使该待升级插件能够依赖该重命名前的资源文件。通过上述操作，在插件运行过程中，不会因为缺少资源而导致出现运行错误，或者运行失败等问题。

也就是说，待升级插件除了依赖原本要使用的资源文件(例如，原始用户界面UI库)以外，还需要依赖一份刚刚重命名之后的资源文件。此时，就需要将重命名前的资源文件添加至宿主工程中。

通过上述描述可知，通过将待升级插件中依赖的资源文件替换为重命名后的资源文件，并在宿主工程中添加原始的资源文件的方式，能够解决由于宿主和插件中包含相同资源库导致的类转换错误的问题，同时，在插件运行过程中也不会因为缺少原始用户界面UI库中的资源而导致出现运行错误，或者运行失败等问题。

在本公开的一个可选实施方式中，在所述目标软件工具开发包SDK所属宿主工程中添加待升级插件依赖的所述资源文件之后，且在对所述待升级插件所对应的插件工程进行编译之前，还可以将目标插件属性参数设置为预设数值，其中，设置为所述预设数值的目标属性参数表示在待升级插件所对应的插件工程编译之前将原始的资源文件保存至指定资源目录中。

具体地，在本公开实施例中，目标插件属性参数可以为isShinkResources属性。也就是说，可以将待升级插件的isShinkResources属性参数的参数值设置为true(即，上述预设数值)。采用该设置方式，能够保证在待升级插件的资源编译(compile)过程中，会保留一份编译前的资源文件在资源合并编译任务的指定资源目录下，其中，该指定资源目录可以为以下资源目录：(build/intermediates/mergednot-compiled-resources)目录。其中，该资源目录为用于存储该资源合并编译任务的编译产物的目录。

在一个可选实施方式中，在图1所示实施例的基础上，如图2所示，在将所述资源合并结果中的所述资源文件替换为重命名后的资源文件之前，本公开实施例所提供的方法还包括如下步骤：

步骤S201，遍历所述资源合并结果中第一指定目录下的资源布局文件；

步骤S202，根据所述资源布局文件中包含的资源标识信息在所述资源合并结果中确定所述待升级插件依赖的所述资源文件。

在确定出待升级插件依赖的第三方的资源文件，以及对该资源文件进行重命名处理，得到重命名后的资源文件之后，可以获取资源合并编译任务的资源合并结果。并在该资源合并结果中查找待升级插件所依赖的资源文件。这里，可以通过上述步骤S201和步骤S202所描述的方式在资源合并结果中查找待升级插件所依赖的资源文件。在查找到该资源文件之后，就可以将该资源文件替换为重命名后的资源文件。

在本公开实施例中，如果待升级插件所依赖的资源文件中包含多个资源库，则可以对该资源文件中的全部资源库进行替换，还可以选择对该资源文件中的部分资源库进行替换。

举例来说，如果选择对该资源文件中的部分资源库进行替换，假设该部分资源库为待升级插件所依赖的原始用户界面UI库(以下简称UI库)。此时，就可以通过上述步骤S201和步骤S202所描述的方式在资源合并结果中查找待升级插件所依赖的资源文件，并在该资源文件中查找上述UI库，并将该资源文件中的UI库替换为重命名后的UI库，从而得到使用重命名之后的UI库的资源文件。

在宿主工程和插件工程的编译的过程中，包含资源合并编译任务(mergeResources)和资源链接任务(processResources)。这里，资源合并编译任务是指在宿主工程的编译阶段将待升级插件所依赖的资源合并为一个文件(即，上述资源合并结果)，其中，该资源合并结果存放在第一指定目录(build/intermediates/mergednot-compiled-resources目录)中。资源链接任务表示在插件工程的编译过程中链接资源合并编译任务的资源合并结果的任务。其中，资源链接任务(processResources)将在下述实施方式中进行介绍。

通过上述描述可知，在本公开实施例中，由于将待升级插件的isShinkResources属性参数的参数值设置为true。因此，在执行资源合并编译任务之后，编译之前的资源文件就会保存在第一指定目录中。此时，在待升级插件依赖的资源文件进行重命名处理时，就可以获取资源合并编译任务的资源合并结果，并在第一指定目录中遍历所述资源合并处理结果中的资源文件。

例如，可以从存储资源合并编译任务(mergeResources)的产物的第一指定目录(build/intermediates/merged-not-compiled-resources)中，遍历layout资源文件，从而找到需要替换的资源文件。在得到需要替换的资源文件之后，就可以对待替换的资源文件执行替换操作，从而使得替换之后的资源文件为重命名后资源文件，从而得到重命名后资源文件。例如，可以对资源文件中待替换的UI库执行替换操作，从得到使用重命名之后的UI库的资源文件。

在本公开的一个可选实施方式中，在图1所描述技术方案，以及图2所描述技术方案的基础上，如图3所示，将所述资源文件进行重命名处理，得到重命名后的资源文件，还包括如下过程：

步骤S301，确定所述资源合并结果中存储所述资源文件的第二XML文件；

步骤S302，将所述第二XML文件的文件参数的参数值替换为重命名后的资源文件的文件名，得到所述重命名后的资源文件；所述文件参数包括：标签值value和/或对象属性名name。

在本公开实施例中，可以获取包含该待替换的资源文件的可扩展标记语言XML文件，也即第二XML文件。之后，确定第二XML文件的文件参数，其中，所述文件参数包括：标签值value和/或对象属性名name。接下来，可以将文件参数中的目标文件参数的名称修改为重命名后资源文件的名称。例如，可以将文件参数中的目标文件参数的名称修改为重命名后UI库的名称，从而得到使用重命名后UI库的资源文件，其中，目标文件参数为文件参数中名称与修改前资源文件的名称相同的参数。

在一个可选的实施方式中，可以通过以下步骤确定所述XML文件的文件参数的参数值，具体包括：

首先，将所述第二XML文件转换为文档对象；

然后，在所述文档对象中获取所述文件参数的参数值。

在本公开实施例中，可以将需要替换的资源文件对应的第二XML文件转换为文档对象(即，document对象)，然后，在文档对象中获取第二XML文件的文件参数，即标签值value和/或对象属性名name；并按照替换规则，通过DOM库对标签值value和/或对象属性名name进行替换。其中，替换规则可以表示为将文件参数中名称为修改前资源文件的名称的目标文件参数均修改为重命名后资源文件的名称。例如，可以将文件参数中名称为原始UI库的包名的目标文件参数均修改为重命名之后的UI库的包名，从而实现将原始用户界面UI库的包名修改为重命名之后的包名，得到重命名之后的UI库。

在本公开实施例中，在得到重命名后的资源文件之后，可以获取资源合并编译任务的资源合并结果，并将该资源合并结果中的资源文件替换为重命名后的资源文件。

具体实施时，可以在第一指定目录中遍历layout资源文件，从而找到待替换的资源文件，并将该待替换的资源文件替换为重命名后的资源文件，第一指定目录可以为(build/intermediates/merged-not-compiled-resources)目录。

在本申请中，对待升级插件依赖的资源文件进行重命名可以理解为对资源文件所在XML文件中涉及资源文件的名称的参数的进行修改，从而实现将资源文件的名称修改为预先设定的名称。此时，在将原始的资源文件依赖到宿主中之后，就可以实现宿主和插件不存在相同的依赖库，也就不会出现类转换错误的问题。

在本公开实施例中，在按照上述所描述的方式对待升级插件依赖的资源文件进行重命名处理，可以得到重命名后的资源文件；之后，可以实现将待升级插件所依赖的资源文件替换为重命名之后的资源文件。在对待升级插件中依赖该资源文件的代码包进行重命名处理之后，就可以基于重命名后的资源文件和重命名后的代码包编译得到插件APK。

在本公开的一个可选实施方式中，在图1至图3所描述技术方案的基础上，如图4所示，该方法还包括如下过程：

步骤S401，在将所述SDK的宿主工程的资源合并编译任务的资源合并结果中的所述资源文件替换为所述重命名后的资源文件之后，将所述重命名后的资源文件保存至第一XML文件中，其中，所述第一XML文件与第二XML文件位于不同的存储目录中，所述第二XML文件为所述资源合并结果中存储所述资源文件的XML文件；

步骤S402，对所述第一XML文件进行编译，得到所述临时文件，其中，所述临时文件的文件名为所述重命名后的资源文件的文件名；

步骤S403，将所述临时文件存放在所述资源合并编译任务的第二指定目录下。

在本公开实施例中，在将所述SDK的宿主工程的资源合并编译任务的资源合并结果中的所述资源文件替换为所述重命名后的资源文件之后，可以将重命名之后的资源文件保存为另一个目录下的同名XML文件(即，上述第一XML文件)。

在将重命名之后的资源文件保存为另一个目录(即，上述第二指定目录)下的同名XML文件之后，得到新的XML资源文件(即，上述第一XML文件)，其中，在实现页面功能时，若需要使用资源文件中的原始用户界面UI库，此时，通过新的XML资源文件可以将使用原始用户界面UI库替换成对重命名之后的UI库的使用。此时，就可以将该新的XML资源文件，通过aapt2进行编译(compile)，从而生成编译后的.flat文件(资源编译后产生的临时文件)；然后将这些临时文件复制替换到原本mergeResources任务的产物目录build/intermediates/res/merged(即，第二指定目录)中。最终，在资源链接任务(processResources)进行链接资源(link)的时候就会用新资源文件进行资源链接link，从而欺骗了资源链接任务(processResources)，插件中最终使用的资源已经被重命名了。

在将临时文件存放在资源合并编译任务的第二指定目录下之后，就可以调用所述资源合并结果中所述重命名后的资源文件。

具体实施时，可以通过所述SDK的宿主工程的资源链接任务在所述资源合并结果中调用所述重命名后的资源文件，并对所述待升级插件中依赖所述重命名后的资源文件的代码包进行重命名。

需要说明的是，在本公开实施方式中，在宿主工程和插件工程的编译的过程中，包含资源合并编译任务(mergeResources)和资源链接任务(processResources)，其中，资源链接任务表示在插件编译过程中链接资源编译任务结果的任务。也即，资源合并编译任务表示在插件编译过程中对待升级插件所依赖资源库进行合并的任务，资源链接任务表示在进行链接link资源时链接资源编译任务结果。

通过上述实施方式中，在本公开实施例中，可以通过gradle插件，在资源合并编译任务(mergeResources)和资源链接任务(processResources)之间插入一个任务task，从而通过该任务task在资源合并编译任务执行结束之后，确定资源合并编译任务的资源合并结果，并在第一指定目录中遍历所述资源合并结果中的资源文件；接下来，将第一指定目录中的资源文件替换为所述重命名后的资源文件。在此情况下，在资源链接任务(processResources)进行链接资源(link)的时候就会用重命名后的资源文件进行资源链接link，从而欺骗了资源链接任务(processResources)，插件中最终使用的资源已经被重命名了。通过该方式能够保证在不增加开发成本的情况下，不会出现类转换错误，以及页面布局错乱的问题。

在本公开实施方式中，在调用所述资源合并结果中所述重命名后的资源文件之后，可以对所述待升级插件中依赖所述重命名后的资源文件的代码包进行重命名，具体包括如下过程：

将所述待升级插件中的目标代码包的名称替换为所述重命名后资源文件的名称，其中，所述目标代码包中所包含的代码为用于调用资源文件的代码。

在本公开实施例中，不仅要修改资源文件中的文件参数，还需要修改待升级插件中用来调用资源文件的代码(即目标代码包)的名称，从而实现目标代码包的名称和重命名后的资源文件的包名是相同的，此时，就可以通过重命名后的代码对重命名后的资源文件中的资源进行调用。

具体地，在本公开实施例中，可以通过Java字节码操控框架ASM修改待升级插件中的类，从而将使用了资源文件中的代码全部进行重命名。上述对目标代码包的重命名过程包括自研代码和更底层的依赖代码。本申请中按照上述操作最终生成的APK中其实使用的就是重命名后的资源文件，但开发过程中还是正常按照依赖原资源文件的方式进行开发，不会对开发过程造成任何侵入。

综上，本公开所描述的技术方案在插件化方案的基础上，解决了页面复杂SDK自升级插件开发过程中可以正常使用第三方UI依赖库来简化开发工作量的问题；同时通过重命名rename的方式，由gradle插件将插件中对原资源文件的引用换成对rename后的资源文件引用，从而避免了可能的class类转换错误，页面布局错乱的问题。

实施例二

参见图5所示，为本公开实施例提供的另一种SDK升级方法的流程图，所述方法包括如下过程，具体描述为：

步骤S501，确定软件工具开发包SDK的待升级插件依赖的第三方的资源文件，与步骤S102相同，此处不再详细赘述。

步骤S502，将资源文件进行重命名处理，得到重命名后的资源文件，其中，在修改完成之后，就可以对外发布(例如，向服务器发布)对应的产物，例如，aar格式的数据包或者jar格式的数据包。

步骤S503，在目标软件工具开发包SDK所属宿主工程添加原始的资源文件。其中，在添加之后，在对待升级插件进行编译时，就会将待升级插件中所依赖的原始的资源文件删除，例如，将原始用户界面UI库删除。

步骤S504，将待升级插件的isShinkResources属性参数的参数值设置为true。

步骤S505，执行资源合并编译任务，并得到资源合并处理结果。

步骤S506，执行ModifyResForRulesTask任务，从资源合并编译任务的产物的第一指定目录(build/intermediates/merged-not-compiled-resources)中，遍历layout资源文件，从而找到待替换的资源文件。其中，ModifyResForRulesTask任务即为上述任务task。

步骤S507，将需要替换的资源文件转换重命名后的资源文件。

这里，可以通过以下方式对资源文件进行重命名处理，得到重命名后的资源文件，具体包括：

将需要替换的资源文件对应的第二XML文件转换为文档对象(即，document对象)，然后，在文档对象中获取第二XML文件的文件参数，即标签值value和/或对象属性名name；并按照替换规则，通过DOM库对标签值value和/或对象属性名name进行替换。其中，替换规则可以表示为将文件参数中名称为修改前资源文件的名称的目标文件参数均修改为重命名后资源文件的名称。

步骤S508，在替换之后，将重命名后的资源文件库保存为另一个目录下的同名xml文件得到使用重命名后的资源文件。

步骤S509，通过aapt2对新的重命名后的资源文件进行编译(compile)，生成编译后的.flat文件(即，上述临时文件)。

步骤S510，将临时文件复制替换到原本mergeResources任务的产物目录build/intermediates/res/merged中(即，上述第二指定目录)。

步骤S511，在资源链接任务(processResources)进行链接资源(link)的时候就会用重命名后的资源文件进行资源链接link。

步骤S512，将待升级插件中的目标代码包的名称替换为重命名后的资源文件的名称，从而得到完整的重命名之后的待升级插件的APK。

本领域技术人员可以理解，在具体实施方式的上述方法中，各步骤的撰写顺序并不意味着严格的执行顺序而对实施过程构成任何限定，各步骤的具体执行顺序应当以其功能和可能的内在逻辑确定。

基于同一发明构思，本公开实施例中还提供了与SDK升级方法对应的SDK升级装置，由于本公开实施例中的装置解决问题的原理与本公开实施例上述SDK升级方法相似，因此装置的实施可以参见方法的实施，重复之处不再赘述。

实施例五

参照图6所示，为本公开实施例提供的一种SDK升级装置的架构示意图，所述装置包括：确定单元61、第一重命名单元62、替换单元63、第二重命名单元64和编译单元65；其中，

确定单元61，用于确定软件工具开发包SDK的待升级插件依赖的第三方的资源文件；

第一重命名单元62，用于将所述资源文件进行重命名处理，得到重命名后的资源文件；

替换单元63，用于将所述SDK的宿主工程的资源合并编译任务的资源合并结果中的所述资源文件替换为所述重命名后的资源文件；

第二重命名单元64，用于调用所述资源合并结果中所述重命名后的资源文件，并对所述待升级插件中依赖所述重命名后的资源文件的代码包进行重命名；

编译单元65，用于基于所述重命名后的资源文件和所述重命名后的代码包编译得到插件APK；所述插件APK用于对所述SDK进行升级处理。

在本公开技术方案中，可以将待升级插件所依赖的第三方的资源文件替换为重命名之后的资源文件，并对待升级插件中依赖重命名后的资源文件的代码包进行重命名，以基于重命名后的资源文件和代码包编译得到插件APK。通过该处理方式，可以将待升级插件所使用的资源文件进行重命名，并在不改变现有编译方式的前提下，将待升级插件的代码所依赖的资源文件替换为重命名后的资源文件。在接入方接入SDK并使用该资源文件时，由于插件和宿主中所依赖的资源文件不相同，因此，就不会出现类转换错误的问题，进一步地通过上述处理方式能够保证在不增加开发成本的情况下，不会出现类转换错误，以及页面布局错乱的问题。

一种可能的实施方式中，该装置还用于：在将所述资源合并结果中的所述资源文件替换为重命名后的资源文件之前，遍历所述资源合并结果中第一指定目录下的资源布局文件；根据所述资源布局文件中包含的资源标识信息在所述资源合并结果中确定所述待升级插件依赖的所述资源文件。

一种可能的实施方式中，该装置还用于：在将所述SDK的宿主工程的资源合并编译任务的资源合并结果中的所述资源文件替换为所述重命名后的资源文件之后，将所述重命名后的资源文件保存至第一XML文件中，其中，所述第一XML文件与第二XML文件位于不同的存储目录中，所述第二XML文件为所述资源合并结果中存储所述资源文件的XML文件；对所述第一XML文件进行编译，得到所述临时文件，其中，所述临时文件的文件名为所述重命名后的资源文件的文件名；将所述临时文件存放在所述资源合并编译任务的第二指定目录下。

一种可能的实施方式中，第一重命名单元，用于确定所述资源合并结果中存储所述资源文件的第二XML文件；将所述第二XML文件的文件参数的参数值替换为重命名后的资源文件的文件名，得到所述重命名后的资源文件；所述文件参数包括：标签值value和/或对象属性名name。

一种可能的实施方式中，第一重命名单元，用于：将所述第二XML文件转换为文档对象；在所述文档对象中获取所述文件参数的参数值。

一种可能的实施方式中，该装置还用于：在所述宿主工程中添加所述待升级插件依赖的所述资源文件；建立所述待升级插件和所述宿主工程中的资源文件之间的依赖关系。

一种可能的实施方式中，第二重命名单元，用于：通过所述SDK的宿主工程的资源链接任务在所述资源合并结果中调用所述重命名后的资源文件。

实施例六

基于同一技术构思，本公开实施例还提供了一种计算机设备。参照图7所示，为本公开实施例提供的计算机设备700的结构示意图，包括处理器701、存储器702、和总线703。其中，存储器702用于存储执行指令，包括内存7021和外部存储器7022；这里的内存7021也称内存储器，用于暂时存放处理器701中的运算数据，以及与硬盘等外部存储器7022交换的数据，处理器701通过内存7021与外部存储器7022进行数据交换，当计算机设备700运行时，处理器701与存储器702之间通过总线703通信，使得处理器701在执行以下指令：

确定软件工具开发包SDK的待升级插件依赖的第三方的资源文件，并将所述资源文件进行重命名处理，得到重命名后的资源文件；将所述SDK的宿主工程的资源合并编译任务的资源合并结果中的所述资源文件替换为所述重命名后的资源文件；调用所述资源合并结果中所述重命名后的资源文件，并对所述待升级插件中依赖所述重命名后的资源文件的代码包进行重命名；基于所述重命名后的资源文件和所述重命名后的代码包编译得到插件APK；所述插件APK用于对所述SDK进行升级处理。

本公开实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述方法实施例中所述的SDK升级方法的步骤。其中，该存储介质可以是易失性或非易失的计算机可读取存储介质。

本公开实施例所提供的SDK升级方法的计算机程序产品，包括存储了程序代码的计算机可读存储介质，所述程序代码包括的指令可用于执行上述方法实施例中所述的SDK升级方法的步骤，具体可参见上述方法实施例，在此不再赘述。

本公开实施例还提供一种计算机程序，该计算机程序被处理器执行时实现前述实施例的任意一种方法。该计算机程序产品可以具体通过硬件、软件或其结合的方式实现。在一个可选实施例中，所述计算机程序产品具体体现为计算机存储介质，在另一个可选实施例中，计算机程序产品具体体现为软件产品，例如软件开发包(Software DevelopmentKit，SDK)等等。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统和装置的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。在本公开所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本公开各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解，本公开的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本公开各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-OnlyMemory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上所述实施例，仅为本公开的具体实施方式，用以说明本公开的技术方案，而非对其限制，本公开的保护范围并不局限于此，尽管参照前述实施例对本公开进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本公开揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本公开实施例技术方案的精神和范围，都应涵盖在本公开的保护范围之内。因此，本公开的保护范围应所述以权利要求的保护范围为准。

Claims (10)

1.一种SDK自升级方法，其特征在于，包括：

确定软件工具开发包SDK的待升级插件依赖的第三方的资源文件，并将所述资源文件进行重命名处理，得到重命名后的资源文件；

将所述SDK的宿主工程的资源合并编译任务的资源合并结果中的所述资源文件替换为所述重命名后的资源文件；

调用所述资源合并结果中所述重命名后的资源文件，并对所述待升级插件中依赖所述重命名后的资源文件的代码包进行重命名；

基于所述重命名后的资源文件和所述重命名后的代码包编译得到插件APK；所述插件APK用于对所述SDK进行升级处理。

2.根据权利要求1所述的方法，其特征在于，在将所述资源合并结果中的所述资源文件替换为重命名后的资源文件之前，所述方法还包括：

遍历所述资源合并结果中第一指定目录下的资源布局文件；

根据所述资源布局文件中包含的资源标识信息在所述资源合并结果中确定所述待升级插件依赖的所述资源文件。

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

在将所述SDK的宿主工程的资源合并编译任务的资源合并结果中的所述资源文件替换为所述重命名后的资源文件之后，将所述重命名后的资源文件保存至第一XML文件中，其中，所述第一XML文件与第二XML文件位于不同的存储目录中，所述第二XML文件为所述资源合并结果中存储所述资源文件的XML文件；

对所述第一XML文件进行编译，得到临时文件，其中，所述临时文件的文件名为所述重命名后的资源文件的文件名；

将所述临时文件存放在所述资源合并编译任务的第二指定目录下。

4.根据权利要求1所述的方法，其特征在于，所述将所述资源文件进行重命名处理，得到重命名后的资源文件，包括：

确定所述资源合并结果中存储所述资源文件的第二XML文件；

将所述第二XML文件的文件参数的参数值替换为重命名后的资源文件的文件名，得到所述重命名后的资源文件；所述文件参数包括：标签值value和/或对象属性名name。

5.根据权利要求4所述的方法，其特征在于，通过以下步骤确定所述XML文件的文件参数的参数值，包括：

将所述第二XML文件转换为文档对象；

在所述文档对象中获取所述文件参数的参数值。

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

在所述宿主工程中添加所述待升级插件依赖的所述资源文件；

建立所述待升级插件和所述宿主工程中的资源文件之间的依赖关系。

7.根据权利要求1所述的方法，其特征在于，调用所述资源合并结果中重命名后的资源文件，包括：

通过所述SDK的宿主工程的资源链接任务在所述资源合并结果中调用所述重命名后的资源文件。

8.一种SDK升级装置，其特征在于，包括：

确定单元，用于确定软件工具开发包SDK的待升级插件依赖的第三方的资源文件；

第一重命名单元，用于将所述资源文件进行重命名处理，得到重命名后的资源文件；

替换单元，用于将所述SDK的宿主工程的资源合并编译任务的资源合并结果中的所述资源文件替换为所述重命名后的资源文件；

第二重命名单元，用于调用所述资源合并结果中所述重命名后的资源文件，并对所述待升级插件中依赖所述重命名后的资源文件的代码包进行重命名；

编译单元，用于基于所述重命名后的资源文件和所述重命名后的代码包编译得到插件APK；所述插件APK用于对所述SDK进行升级处理。

9.一种计算机设备，其特征在于，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当计算机设备运行时，所述处理器与所述存储器之间通过总线通信，所述机器可读指令被所述处理器执行时执行如权利要求1至7任一项所述的SDK升级方法的步骤。

10.一种计算机可读存储介质，其特征在于，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行如权利要求1至7任一项所述的SDK升级方法的步骤。

Images