CN114201178A - 一种批量解决sdk资源冲突的方法 - Google Patents

Abstract

本发明提供了一种批量解决SDK资源冲突的方法，包括步骤S100、输入项目的磁盘路径：步骤S200、解析路径；步骤S300、修改资源文件；步骤S400、读入代码文件；步骤S500、修改代码中的引用关系；步骤S600、覆盖本地文件。本发明可自动解析项目结构，实现全自动为所有资源文件添加前缀名的工作，可更高效率修正资源冲突，降低解决问题所需要的人力成本，解决现阶段必须手工完成资源名称替换的问题。

Description

一种批量解决SDK资源冲突的方法

技术领域

本发明涉及软件开发技术领域，尤其涉及一种批量解决SDK资源冲突的方法。

背景技术

服务提供商将一个或多个功能进行打包，产出一个被称作SDK（SoftwareDevelopment Kit，软件开发工具包）的集成功能开发包，提供给第三方基于SDK进行二次开发。在Android上这一流程会产生一个.arr格式的资源包（以下统称SDK包），区别于标准Java中提供的纯代码相关构成的jar包，.arr包含一些图片，Android中的布局文件，颜色代码等特有的资源文件，并分别存放在各自的目录下，具体存放目录和资源文件类型如下图1所示。

在一个实际的软件开发过程中，则可能会出现项目中需要使用多方提供SDK包的情况。如果出现多个服务供应商使用同一个名字的资源文件，就会导致二次开发人员遇到资源冲突的问题，导柱项目无法通过编译，不能正常进行软件开发。当项目中出现了SDK间资源冲突问题，可以由两方解决问题：

1. 服务提供商：服务提供商对冲突的资源文件进行更名，并且重新出包。如果存在多个资源文件冲突则需要逐一更名，并且需要修改文件名称在代码中的引用关系，非常繁琐。并且即使在完成修改后，依然可能与其他服务提供商的SDK包产生冲突，无法一劳永逸的解决问题。

2. 二次开发人员：通过编译器提供的功能对冲突问题进行强制忽略，同名文件默认使用第一个找到的资源。但是会造成不可预期的错误，例如控件贴图错误，甚至一些场景下会导致软件崩溃。这种问题交由二次开发人员处理是不合理的，简单的忽略冲突可能会引起一些难以预料的问题。所以需要采用对冲突的资源文件及其相关引用逐一更名的方案进行处理。

为了保证资源冲突问题的解决，现在比较合理的方式是给所有资源添加统一前缀的模式来确保不同SDK间命名的存在差异化。现在这一方案目前存在一些问题：

1、需要在项目开发之前制定命名规则：如果项目已经开发完毕，此时项目存在大量资源需要进行添加前缀名，需要消耗大量时间成本；

2、依赖人工进行遵守规则，会增加开发过程中的负担；编译器无法提供对所有资源名称前缀的校验工作，只能进行人工约束，可靠性差；

3、后续维护繁琐：如果涉及到新功能的开发，可能再次需要重复这种添加前缀的工作，需要消耗开发的人力成本。

因此有必要设计一种批量解决SDK资源冲突的方法，以克服上述问题。

发明内容

本发明的目的在于克服现有技术之缺陷，提供了一种批量解决SDK资源冲突的方法。

本发明是这样实现的：

本发明提供一种批量解决SDK资源冲突的方法，包括步骤：

步骤S100、输入项目的磁盘路径：传入项目的绝对路径；

步骤S200、解析路径：对项目的路径下文件夹进行分析，获取到资源文件的存放路径、代码文件的存放路径和使用的版本控制工具类型；

步骤S300、修改资源文件：根据资源文件的存放路径逐个对资源文件添加前缀名，如果当前资源文件已包含需要添加的前缀名则跳过，并将具体的修改记录以Set集合的形式存入内存；

步骤S400、读入代码文件：根据代码文件的存放路径读取代码文件存入内存并创建文件地址表；

步骤S500、修改代码中的引用关系：根据所述Set集合中的修改记录，结合资源文件类型和代码文件类型，生成引用字段；然后根据更名前的引用字段在代码文件中进行遍历，如果存在引用，就将其改为新的名称，循环遍历所有的代码文件；

步骤S600、覆盖本地文件：根据文件地址表，将修改完毕的内容以覆盖的方式重新写回原始文件，完成变更操作。

进一步地，所述步骤S200具体包括：

S201、解析版本控制工具类型：检测项目的根目录下是否存在.svn或者.git文件夹，当仅存在.svn文件夹时，则认定项目托管在SVN，版本控制工具类型为SVN，当仅存在.git文件夹时，则认定项目托管在Git，版本控制工具类型为Git；如果都不存在或者同时存在，则给出异常状态的提示信息，由使用者根据实际情况选择使用Git、SVN版本控制工具或者windows文件修改模式进行重命名操作；

S202、解析资源文件和代码文件路径：对传入项目的路径下文件夹以及其子文件夹路径进行一次遍历，找到所有的/src/main/路径和/src/res/路径，其中代码文件路径为/src/main/路径，资源文件路径为/src/res/路径，但是其中/src/res/layout/下存放的布局文件同时有代码文件和资源文件。

进一步地，所述步骤S300中，所述资源文件有文件型资源文件和xml型资源文件，步骤S300具体包括：

S301、文件型资源文件修改：先进行一次命名检测并添加文件前缀名，对于本身已经添加过前缀名的文件则跳过，只处理没有添加前缀名的文件，修改此类资源文件的模式为重命名文件本身，根据确定的版本控制工具类型，载入对应的功能执行语句；

S302、xml型资源文件修改：将xml型资源文件的内容全部读入内存，依次检查xml型资源文件中的“name”字段，如果不包含所需添加的前缀名，就将“name”字段添加前缀名，如果已经添加则跳过：

S303、根据上述资源文件的资源类型、修改前名称和修改后名称创建一个bean实例，存在Set集合中。

进一步地，所述步骤S400具体包括：

根据找到的代码文件路径和资源文件路径，读入/src/main/路径下的.java代码或.kt代码，以及/src/res/layout/路径下的.xml布局文件，并逐个读入内存，创建以文件名称为键，绝对路径为值的文件地址表。

进一步地，所述步骤S500具体包括：

S501、根据资源类型、修改前后名称和代码文件类型，查找步骤S300得到Set集合中的修改记录，生成引用字段；

S502、根据生成的修改前的引用字段在代码文件中进行遍历查找，如果找到就将旧引用改为新引用，否则就继续寻找下一个资源文件，直到所有资源文件修改和所有代码文件全部遍历完成。

本发明具有以下有益效果：

1、本发明仅需通过配置项目磁盘地址和待添加的资源前缀名即可自动解析项目结构，实现全自动为所有资源文件添加前缀名的工作。

2、本发明可更高效率修正资源冲突，降低解决问题所需要的人力成本，解决现阶段必须手工完成资源名称替换的问题。

附图说明

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

图1为资源文件存放示意图；

图2为本发明的流程框图；

图3为本发明具体实施例的流程图；

图4为本发明具体实施例中修改引用关系的匹配规则示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。

参见图2和图3，本发明实施例提供一种批量解决SDK资源冲突的方法，包括下述步骤：

步骤S100、输入项目的磁盘路径：传入项目的绝对路径。

项目存储在本地磁盘中，本步骤需要获取项目的绝对路径。绝对路径是完整的描述文件位置的路径，绝对路径名的指定是从树型目录结构顶部的根目录开始到某个目录或文件的路径，由一系列连续的目录组成，中间用斜线分隔，直到要指定的目录或文件，路径中的最后一个名称即为要指向的目录或文件。

步骤S200、解析路径：对项目的路径下文件夹进行分析，获取到资源文件的存放路径、代码文件的存放路径和使用的版本控制工具类型。

所有可以从中读取出需要的资源的文件，可以称之为“资源文件”。资源的类型可以是图片、音频、视频、文字资源，或者其他可以在计算机中展示的内容等。代码文件是项目能够被计算机执行且按照一定的程序设计语言规范书写的文本文件。

版本控制是指对软件开发过程中各种程序代码、配置文件及说明文档等文件变更的管理，是软件配置管理的核心思想之一。目前常用的版本控制工具有GIT和SVN。

GIT是一个开源的分布式版本控制系统，可以有效、高速地处理从很小到非常大的项目版本管理。一个开放源码的版本控制软件。Git是目前比较先进的分布式版本控制系统，使用Git和Gitlab搭建版本控制环境是现在互联网公司最流行的版本控制方式。

SVN是subversion的缩写，是一个开放源代码的版本控制系统，通过采用分支管理系统的高效管理，简而言之就是用于多个人共同开发同一个项目，实现共享资源，实现最终集中式的管理。

具体的，本步骤实现过程如下：

S201、解析版本控制工具类型：检测项目的根目录下是否存在.svn或者.git文件夹，当仅存在.svn文件夹时，则认定项目托管在SVN，版本控制工具类型为SVN，当仅存在.git文件夹时，则认定项目托管在Git，版本控制工具类型为Git；如果都不存在或者同时存在，则给出异常状态的提示信息，由使用者根据实际情况选择使用Git、SVN版本控制工具或者windows文件修改模式进行重命名操作。

版本控制工具类型可以直接通过项目的根目录下是否有.svn文件夹或者.git文件夹进行确定。如果只有其中一种文件夹，则版本控制工具对应为SVN或GIT，如果两种文件夹都没有或者同时都有，则抛出提示信息，告诉使用者这一异常状态。使用者根据实际情况进行选择使用SVN或GIT，或者也可以使用单纯的windows文件修改模式进行重命名操作。因为单纯通过windows命令改名不会在版本控制留下记录，需要手工在版本控制工具中移除文件并重新添加。

S202、解析资源文件和代码文件路径：对传入项目的路径下文件夹以及其子文件夹路径进行一次遍历，找到所有的/src/main/路径和/src/res/路径，其中代码文件路径为/src/main/路径，资源文件路径为/src/res/路径，但是其中/src/res/layout/下存放的布局文件同时有代码文件和资源文件。

这里，找到项目路径文件夹和子文件夹中所有的/src/main/路径和/src/res/路径，/src/main/路径主要是代码文件的存放地址，/src/res/路径主要是资源文件的存放地址。其中/src/res/layout/路径下存放的布局文件，同时是代码文件和资源文件，会进行特殊处理。

步骤S300、修改资源文件：根据资源文件的存放路径逐个对资源文件添加前缀名，如果当前资源文件已包含需要添加的前缀名则跳过，并将具体的修改记录以Set集合的形式存入内存。

根据步骤S200得到的资源文件路径，即/src/res/路径，同时/src/res/layout/下也有资源文件的布局文件。并逐个对资源文件添加前缀名，该前缀名一般供应商名称或者其名称缩写。如果资源文件本身已存在该前缀名，则不再重复添加。所述资源文件有文件型资源文件和xml型资源文件。

具体的，步骤S300具体包括：

S301、文件型资源文件修改：先进行一次命名检测并添加文件前缀名，对于本身已经添加过前缀名的文件则跳过，只处理没有添加前缀名的文件，修改此类资源文件的模式为重命名文件本身，根据确定的版本控制工具类型，载入对应的功能执行语句。

这里文件型资源文件主要是图片资源和/src/res/layout/路径下的资源文件布局文件。首先对文件型资源文件的名称进行命名检测，对于没有相应前缀名的添加前缀名。对于不同版本控制工具类型，载入对应的功能执行语句，在版本控制系统中留下操作记录。

S302、xml型资源文件修改：将xml型资源文件的内容全部读入内存，依次检查xml型资源文件中的“name”字段，如果不包含所需添加的前缀名，就将“name”字段添加前缀名，如果已经添加则跳过。

这里xml型资源文件主要是Android中定义的颜色、组件样式、主题、动画效果等。这种资源本身都一个或复合字段的模式存放在xml文件中，这里需要修改的并非xml文件本身的文件名，而是其中的“name”字段，xml型资源的实际取值都是以“name”+实际内容的键值对模式存放。所以这类资源文件，需要先将其内容全部读入内存，然后依次检查其中的“name”字段，如果不包含所需添加的前缀名，就将“name”字段添加前缀名，如果已经添加则跳过。

S303、根据上述资源文件的资源类型、修改前名称和修改后名称创建一个bean实例，存在Set集合中。

其中资源类型是指这个资源文件所属的文件夹或是文件级别，即为Drawable、MipMap、Layout、String、StringArray、StringPlurals、Dimension、Style、Animation、Menu、Color等。

步骤S400、读入代码文件：根据代码文件的存放路径读取代码文件存入内存并创建文件地址表。

根据找到的代码文件路径和资源文件路径，读入/src/main/路径下的.java代码或.kt代码，以及/src/res/layout/路径下的.xml布局文件，并逐个读入内存，创建以文件名称为键，绝对路径为值的文件地址表。

步骤S500、修改代码中的引用关系：根据所述Set集合中的修改记录，结合资源文件类型和代码文件类型，生成引用字段；然后根据更名前的引用字段在代码文件中进行遍历，如果存在引用，就将其改为新的名称，循环遍历所有的代码文件。

所述步骤S500具体包括：

S501、根据资源类型、修改前后名称和代码文件类型，查找步骤S300得到Set集合中的修改记录，生成引用字段。

对于该引用字段，在Android中同一个资源的引用在.xml和.java/.kt中字段不同。会根据字段存放和引用位置发生变化，例如同一个白色在.java/.kt代码中表达为R.color.white，在xml.中表达为@color/white。对于具体的引用字段详细的匹配规则如图4所示。

S502、根据生成的修改前的引用字段在代码文件中进行遍历查找，如果找到就将旧引用改为新引用，否则就继续寻找下一个资源文件，直到所有资源文件修改和所有代码文件全部遍历完成。其中需要单独过滤以andoird.R.开头的代码引用，避免与系统冲突。

步骤S600、覆盖本地文件：根据文件地址表，将修改完毕的内容以覆盖的方式重新写回原始文件，完成变更操作。

本发明使用kotlin语言编写的一键完成资源添加前缀名的工具，通过保存资源文件修改记录，对资源文件类型生成完整引用的字符串在代码中进行匹配检测并且规避Android系统资源前缀，然后根据修改记录逐个读入代码文件，自动逐一替换代码中的引用关系。

相比于现有普通依赖手工修改的模式，本发明存在如下优点：

1、可以在项目开发的任意阶段使用：因为本发明是直接代替人工对所有文件进行操作，所有不必关注项目的开发进度，在任意时间点使用本发明完成对所有资源添加前缀都可以，并且本发明校验了前缀名称，无需担心同一个资源被反复添加前缀的问题。

2、无需开发人员在编码阶段关注：理论上本发明最合适的使用时机是在项目开发完毕后，可以一次性对所有的资源文件进行添加前缀操作。开发人员在编码过程中无需刻意手工为资源文件添加命名规范。

3、兼容SVN和GIT版本控制工具，本发明提供了自动解析版本控制工具，并根据项目使用的版本控制工具来实现在文件级重命名操作，可以在版本控制工具中留存记录，无需开发人员再逐一添加新文件删除旧文件。

综上，本发明可更高效率修正资源冲突，降低解决问题所需要的人力成本，解决现阶段必须手工完成资源名称替换的问题。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (5)

1.一种批量解决SDK资源冲突的方法，其特征在于，所述方法包括下述步骤：

步骤S100、输入项目的磁盘路径：传入项目的绝对路径；

步骤S200、解析路径：对项目的路径下文件夹进行分析，获取到资源文件的存放路径、代码文件的存放路径和使用的版本控制工具类型；

步骤S300、修改资源文件：根据资源文件的存放路径逐个对资源文件添加前缀名，如果当前资源文件已包含需要添加的前缀名则跳过，并将具体的修改记录以Set集合的形式存入内存；

步骤S400、读入代码文件：根据代码文件的存放路径读取代码文件存入内存并创建文件地址表；

步骤S500、修改代码中的引用关系：根据所述Set集合中的修改记录，结合资源文件类型和代码文件类型，生成引用字段；然后根据更名前的引用字段在代码文件中进行遍历，如果存在引用，就将其改为新的名称，循环遍历所有的代码文件；

步骤S600、覆盖本地文件：根据文件地址表，将修改完毕的内容以覆盖的方式重新写回原始文件，完成变更操作。

2.如权利要求1所述的批量解决SDK资源冲突的方法，其特征在于，所述步骤S200具体包括：

S201、解析版本控制工具类型：检测项目的根目录下是否存在.svn或者.git文件夹，当仅存在.svn文件夹时，则认定项目托管在SVN，版本控制工具类型为SVN，当仅存在.git文件夹时，则认定项目托管在Git，版本控制工具类型为Git；如果都不存在或者同时存在，则给出异常状态的提示信息，由使用者根据实际情况选择使用Git、SVN版本控制工具或者windows文件修改模式进行重命名操作；

S202、解析资源文件和代码文件路径：对传入项目的路径下文件夹以及其子文件夹路径进行一次遍历，找到所有的/src/main/路径和/src/res/路径，其中代码文件路径为/src/main/路径，资源文件路径为/src/res/路径，但是其中/src/res/layout/下存放的布局文件同时有代码文件和资源文件。

3.如权利要求2所述的批量解决SDK资源冲突的方法，其特征在于：所述步骤S300中，所述资源文件有文件型资源文件和xml型资源文件，步骤S300具体包括：

S301、文件型资源文件修改：先进行一次命名检测并添加文件前缀名，对于本身已经添加过前缀名的文件则跳过，只处理没有添加前缀名的文件，修改此类资源文件的模式为重命名文件本身，根据确定的版本控制工具类型，载入对应的功能执行语句；

S302、xml型资源文件修改：将xml型资源文件的内容全部读入内存，依次检查xml型资源文件中的“name”字段，如果不包含所需添加的前缀名，就将“name”字段添加前缀名，如果已经添加则跳过：

S303、根据上述资源文件的资源类型、修改前名称和修改后名称创建一个bean实例，存在Set集合中。

4.如权利要求3所述的批量解决SDK资源冲突的方法，其特征在于：所述步骤S400具体包括：

根据找到的代码文件路径和资源文件路径，读入/src/main/路径下的.java代码或.kt代码，以及/src/res/layout/路径下的.xml布局文件，并逐个读入内存，创建以文件名称为键，绝对路径为值的文件地址表。

5.如权利要求4所述的批量解决SDK资源冲突的方法，其特征在于：所述步骤S500具体包括：

S501、根据资源类型、修改前后名称和代码文件类型，查找步骤S300得到Set集合中的修改记录，生成引用字段；

S502、根据生成的修改前的引用字段在代码文件中进行遍历查找，如果找到就将旧引用改为新引用，否则就继续寻找下一个资源文件，直到所有资源文件修改和所有代码文件全部遍历完成。

Images