一种基于多渠道的软件工程源代码管理方法技术

本发明专利技术公开了一种基于多渠道的软件工程源代码管理方法，包括如下步骤：S1：根据设计需求，整理软件功能属性，获取满足设计需要的数据并对其进行处理和定义；S2：根据S1中数据的定义，统一所有业务接口并形成基础层，提供基础业务；S3：根据不同的芯片代码，在基础层相同父类结构中，对不同的芯片代码构建多渠道目录标识；S4：根据终端环境的不同采取不同的源代码打包方式形成打包文件；S5：对S4中的打包文件进行打包。本发明专利技术针对已有技术适应性不强不利于版本控制与快速迭代等问题，提供了一种基于多渠道的软件工程源代码管理方法。于多渠道的软件工程源代码管理方法。于多渠道的软件工程源代码管理方法。

【技术实现步骤摘要】
一种基于多渠道的软件工程源代码管理方法


[0001]本专利技术涉及计算机
，具体涉及一种基于多渠道的软件工程源代码管理方法。

技术介绍

[0002]针对软件工程源代码管理方法，经常采用事件驱动型架构，具体的做法是将系统分成三层架构，包括UI层、业务逻辑层和数据层。当事件状态发生变化时，如用户触发了当前界面，系统发送消息到事件队列，根据具体的业务不同分发到不同的事件处理器。事件驱动型架构便于扩展分布式的异步架构，各种类型的业务都能驱动。但是根据具体的业务，需要固定一套代码来针对这一具体业务进行实现。而面对频繁的需求变动，当芯片厂商更改方案等等变化时，仅用一套固定代码会导致其适应性不强，程序员需要重新构建底层基础代码，这就导致对公共需求拷贝代码时充斥着大量重复业务代码，容易产生bug，并且不利于版本控制与快速迭代。

技术实现思路

[0003]针对现有技术存在的上述不足，本专利技术的目的在于提供一种基于多渠道的软件工程源代码管理方法，以解决现有技术中固定一套代码适应性不强、不利于版本控制与快速迭代的问题。
[0004]为了解决上述技术问题，本专利技术提供一种基于多渠道的软件工程源代码管理方法，包括如下步骤：S1：根据设计需求，整理软件功能属性，获取满足设计需要的数据并对其进行处理和定义；S2：根据S1中数据的定义，统一所有业务接口并形成基础层，提供基础业务；S3：根据不同的芯片代码，在基础层相同父类结构中，对不同的芯片代码构建多渠道目录标识；S4：根据终端环境的不同采取不同的源代码打包方式形成打包文件；S5：对S4中的打包文件进行打包。
[0005]与现有技术相比，本专利技术具有如下有益效果：本专利技术针对芯片厂商换取方案的不同场景，实现了利用一套代码进行多种不同场景的实现，极大的加强了适应性，也极大的提高了可扩展性，针对不同芯片厂商构建的多渠道目录，能够配合版本管理工具极大的满足了版本的可读性，很好的解决了版本控制以及快速迭代的问题。
附图说明
[0006]图1为本专利技术整体流程图。
[0007]图2为本专利技术Apk整体打包流程图。
[0008]图3为本专利技术多渠道配置目录示意图。
具体实施方式
[0009]为了使本专利技术的实施例的目的、技术方案和优点更加清楚，下面将结合附图对本专利技术作进一步地详细描述，所描述的实施例不应视为对本专利技术的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本专利技术保护的范围。
[0010]本专利技术提供一种基于多渠道的软件工程源代码管理方法，如图1所示，包括如下步骤：S1：根据设计需求，整理软件功能属性，获取满足设计需要的数据并对其进行处理和定义。其中，在获取满足设计需要的数据并对其进行处理和定义后，得到完整的数据需求文档。在实际操作一步时，需要提前与芯片厂商进行交涉，获取一份完整的需求文档，后续的接口定义操作依赖于此。
[0011]S2：根据S1中数据的定义，统一所有业务接口并形成基础层，为图2中的base层，提供基础业务。在S2中，抽出完整的接口定义列表，以此作为基础层中多渠道目录的公共依赖项。在具体操作时，新建src/main目录，建立各个接口定义，作为业务统一暴露的API接口，后续所有业务均需要实现base层中的接口。
[0012]S3：根据不同的芯片代码，在基础层相同父类结构中，对不同的芯片代码构建多渠道目录标识。在S3中，根据不同芯片中不同的版本标识号，同时基于多渠道软件工程源代码的结构，在基础层相同父类结构中，根据不同芯片的版本标识号构建多渠道目录标识，在引用时依赖基础层实现核心业务逻辑。
[0013]不同的终端环境，会导致打包文件的配置方式也存在差异，这一操作需要基于多渠道软件工程源代码的结构。
[0014]如果在Android开发环境下，通过多渠道打包技术，在根标签文件中配置用于定义产品特性的文件，并根据不同的芯片对多渠道的名称自行定义。在具体实施时，需要依赖S2中的base层，通过Gradle多渠道打包技术先生成打包所需的文件。具体为需要在build.grale中配置productFlavors，定义的多渠道名称根据芯片厂商可自行定义，如图3中所示的目录，需要在flavorDimensions定义module1，module2。这种方式能够极大的提高软件工程领域关于扩展性的需求，如果需要新增业务，只需要扩展productFlavors定义module3即可，以此类推，亦能满足版本控制可读性的需求，同时，针对不同的芯片厂商进行定义，可根据不同的module查看对应版本的提交历史，也便于管理与维护。
[0015]如果在Android源代码环境下，在服务器中对不同的芯片定义不同的版本识别号。在具体实施时，需要在Linux服务器中定义不同芯片厂商的版本识别号。
[0016]S4：根据终端环境的不同采取不同的源代码打包方式形成打包文件。
[0017]其中，如果终端环境为Android开发环境，根据S3配置好的文件，生成不同芯片的源代码集打包文件。在具体实施时，通过Gradle多渠道打包技术实现不同芯片厂商适配的源代码集成打包apk文件。这样的操作，依赖S3中Gradle构建的框架，采用主要面向Java为主的一款基于JVM的构建工具，使用SDL配置项目结构，拒绝了其它XML配置的繁琐性。
[0018]其中，如果终端环境为Android源代码环境，在当前源代码环境下新建脚本文件，通过脚本文件读取不同芯片的标识号，以此配置不同的多渠道文件目录，集成Android源代
码编译打包镜像文件。在具体实施时，依赖build/core/Makefile主要的编译规则，需要在Linux服务器中定义不同芯片厂商的版本标识号，在当前源码环境下，新建Android.mk文件，根据读取到的芯片厂商的版本表示号，配置不同的多渠道文件目录，集成Android源码编译打包镜像文件。
[0019]S5：对S4中的打包文件进行打包。
[0020]其中，如图2所示，如果在Android开发环境下，通过打包工具软件将S4中生成的打包文件进行统一打包，具体操作为：通过AAPT工具对相关资源文件进行编译，生成R文件，再通过Javac工具编译项目源码，生成class文件，然后走到Dx工具将class文件转成字节码文件。
[0021]如果在Android源代码环境下，通过工具程序将S4所生成的文件进行打包，并通过签名工具进行签名后输出至最终目录，具体操作为：利用ApkBuilder工具将步骤S5之前所需生成的文件统一打包，生成Apk文件，通过KeyStore对该Apk文件进行签名，发布正式版之前需要构建release版本再进一步进行优化。
[0022]本专利技术针对芯片厂商换取方案的不同场景，实现了利用一套代码进行多种不同场景的实现，极大的加强了适应性，也极大的提高了可扩展性，针对不同芯片厂商构建的多渠道目录，能够配合版本管理工具极大的满足了版本的可读性，很好的解决了版本控制本文档来自技高网...

【技术保护点】

【技术特征摘要】
1.一种基于多渠道的软件工程源代码管理方法，其特征在于，包括如下步骤：S1：根据设计需求，整理软件功能属性，获取满足设计需要的数据并对其进行处理和定义；S2：根据S1中数据的定义，统一所有业务接口并形成基础层，提供基础业务；S3：根据不同的芯片代码，构建不同的多渠道目录，并放置在基础层里面相同父目录中；S4：根据终端环境的不同，对不同的源代码结构，采用不同的打包方式形成对应的打包文件；S5：对S4中的打包文件进行打包。2.根据权利要求1所述基于多渠道的软件工程源代码管理方法，其特征在于，在S1中，在获取满足设计需要的数据并对其进行处理和定义后，得到完整的数据需求文档。3.根据权利要求1所述基于多渠道的软件工程源代码管理方法，其特征在于，在S2中，抽出完整的接口定义列表，以此作为基础层中多渠道目录的公共依赖项。4.根据权利要求1所述基于多渠道的软件工程源代码管理方法，其特征在于，在S3中，根据不同芯片中不同的版本标识号，同时基于多渠道软件工程源代码的结构，在基础层相同父类结构中，根据不同芯片的版本标识号构建多渠道目录标识，在引用时依赖基础层实现核心业务逻辑。5.根据权利要求4所述基于多渠...

【专利技术属性】
技术研发人员：谭龙，张磊，张英鹏，
申请(专利权)人：重庆长安汽车股份有限公司，
类型：发明
国别省市：