CN110955415A - 一种投影多平台服务适配的方法 - Google Patents

Abstract

本发明公开了一种投影多平台服务适配的方法，包括将一款机型作为标准并将所述机型的实现放在平台默认基础实现层中，在本地电脑和远程仓库所在的电脑上分别配置两个资源库并使所述本地电脑和所述远程仓库分别依赖所述两个资源库，所述本地代码和所述远程仓库中的其他代码依旧采用原有的方式进行代码同步，依赖资源的部分采用本地仓库路径依赖方式，将所有系统依赖包放到相应仓库中维护并配置Jenkins参数进行加载所述系统依赖包。该方法解决了源码类库依赖问题，实现公用部分只需一个服务进行管理，并且只修改一个服务就能适配所有平台，从而减少了工作量，提升了工作效率。

Description

一种投影多平台服务适配的方法

技术领域

本发明涉及投影多平台适配领域，尤其涉及一种投影多平台服务适配的方法。

背景技术

目前生产投影的平台众多，在遵循着google谷歌大框架的基础上有各种各样的差异，对于一些投影软件开发商来说，很多功能都是类似的，但是平台不一样，如果每种平台都维护开发一套系统并且一个系统里面含有多个应用，那么开发成本特别高，当有一个地方改动的时候就需要同时维护多个平台，如何降低开发以及维护成本，是目前急需解决的问题。

在现有技术中，投影开发都是线性开发，一条流水线对于不同平台都有一套相同的实现方式，这样就会存在一个问题，如果这套方式有问题，那么需要修改很多遍，如果新增一个功能，很有可能这个功能和平台无关，也要实现很多遍，这样就会大大降低效率。

发明内容

本发明提供的一种投影多平台服务适配的方法，旨在解决现有技术中投影开发都是线性开发，存在工作量大、工作效率低的问题，本发明通过树形结构层层继承，解决源码类库依赖问题，实现只修改一个服务就能适配所有平台，从而减少工作量，提升工作效率。

为实现上述目的，本发明采用以下技术方案：

本发明的一种投影多平台服务适配的方法，包括：

将一款机型作为标准并将所述机型的实现放在平台默认基础实现层中，在本地电脑和远程仓库所在的电脑上分别配置两个资源库并使所述本地电脑和所述远程仓库分别依赖所述两个资源库，所述本地代码和所述远程仓库中的其他代码依旧采用原有的方式进行代码同步，依赖资源的部分采用本地仓库路径依赖方式，将所有系统依赖包放到相应仓库中维护并配置Jenkins参数进行加载所述系统依赖包；

其中，所述两个资源库包括两个仓库和两个项目，所述两个仓库为本地仓库和远程仓库，所述两个项目为本地项目和远程项目。

本发明提供的一种投影多平台服务适配的方法，通过配置两个资源库，然后使本地电脑和远程仓库分别去依赖两个资源库，实现不同资源灵活使用不同依赖方式，达到自由组合依赖方式的目的。

作为优选，实现所述方法首先要对整个工程项目进行结构划分，形成支持多平台的系统服务工程，主要分为三个部分包括UI交互层、功能模块注册以及通用接口标准化处理以及事件分发层、具体平台功能实现层，其中所述具体平台功能实现层进行三层划分，包括平台默认基础实现层、平台具体型号实现层、平台具体机型实现层，任何类似的功能均可以在所述UI交互层和所述功能模块注册以及通用接口标准化处理以及事件分发层这两层内完成，而所述具体平台功能实现层是真正实现平台相关代码的层。

作为优选，所述本地项目依赖本地仓库，所述远程项目依赖远程仓库。

作为优选，所述配置Jenkins参数进行加载所述系统依赖包包括：

在项目中根据具体型号生成一份配置表，然后根据所述配置表加载需要依赖的相关系统资源和相关层级代码结构，在Jenkins上面配置需要打包的具体机型型号。

作为优选，所述将所有系统依赖包放到相应仓库中维护包括：

同步本地仓库和远程仓库中的资源，将所有系统依赖包放到相应仓库中进行维护，统一各个应用的依赖包入口，由于依赖的是本地仓库中的资源文件，可以灵活选择依赖的方式。

一种电子设备，包括存储器和处理器，所述存储器用于存储一条或多条计算机指令，其中，所述一条或多条计算机指令被所述处理器执行以实现如上述中任一项所述的一种投影多平台服务适配的方法。

一种存储有计算机程序的计算机可读存储介质，所述计算机程序使计算机执行时实现如上述中任一项所述的一种投影多平台服务适配的方法。

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

本发明提供的一种投影多平台服务适配的方法，采用树形结构层层继承，通过配置两个资源库，然后使本地电脑和远程仓库分别去依赖两个资源库，实现不同资源灵活使用不同依赖方式，达到自由组合依赖方式的目的，解决了源码类库依赖问题，实现公用部分只需一个服务进行管理，并且只修改一个服务就能适配所有平台，从而减少了工作量，提升了工作效率。

附图说明

图1是本发明实施例实现一种投影多平台服务适配的方法流程图。

具体实施方式

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

在介绍本发明技术方案之前，示例性的介绍一种本发明技术方案可能适用的场景。

示例性的：生产投影的平台众多，在遵循着google谷歌大框架的基础上有各种各样的差异，对于一些投影软件开发商来说，有很多功能是类似的但是平台不一样，如果每种平台都维护开发一套系统并且一个系统里面含有多个应用，那么开发成本特别高，当有一个需要改动的时候要同时维护多个平台。

现有技术主要通过线性开发，一条流水线对于不同平台都有一套相同的实现方式，这样就会存在一个问题，如果这套方式有问题，那么需要修改很多遍，如果新增一个功能，很有可能这个功能和平台无关，也要实现很多遍，这大大提高了工作量，降低了工作效率，本发明提供了一种投影多平台服务适配的方法采用树形结构层层继承，解决了源码类库依赖问题，只需要修改一个服务就能适配所有平台。

实施例1

如图1所示，一种投影多平台服务适配的方法，包括：

S100、将一款机型作为标准并将所述机型的实现放在平台默认基础实现层中，在本地电脑和远程仓库所在的电脑上分别配置两个资源库并使所述本地电脑和所述远程仓库分别依赖所述两个资源库；

S110、所述本地代码和所述远程仓库中的其他代码依旧采用原有的方式进行代码同步，依赖资源的部分采用本地仓库路径依赖方式；

S120、将所有系统依赖包放到相应仓库中维护并配置Jenkins参数进行加载所述系统依赖包；

其中，所述两个资源库包括两个仓库和两个项目，所述两个仓库为本地仓库和远程仓库，所述两个项目为本地项目和远程项目。

示例性的，由于android的包依赖特性，通过远程仓库依赖资源，只能通过一种依赖方式依赖，比如一个仓库中含有资源{a,b,c,d....}，其中a使用implementation，b使用api，c使用compileOnly方式依赖，无法做到自由组合依赖方式，如果想实现这样的目的，传统的解决方案是建立三个仓库，然后分别使用三种方式去依赖，这点是由maven仓库的特性所决定的。

本发明提供的方法解决了这个问题，可以针对一个仓库的资源做到不同的依赖方式，这样就统一了仓库资源的管理，并且本发明在此基础上对仓库资源进行平台的划分，即一个仓库中存放不同的平台系统资源，并且能够正确依赖相应的资源，实现减少仓库数量，统一维护不同平台资源，为后面的关键步骤提供实现的可能性。

实施例2

一种投影多平台服务适配的方法，包括：

将一款机型作为标准并将所述机型的实现放在平台默认基础实现层中，在本地电脑和远程仓库所在的电脑上分别配置两个资源库并使所述本地电脑和所述远程仓库分别依赖所述两个资源库，所述本地代码和所述远程仓库中的其他代码依旧采用原有的方式进行代码同步，依赖资源的部分采用本地仓库路径依赖方式，将所有系统依赖包放到相应仓库中维护并配置Jenkins参数进行加载所述系统依赖包；

其中，所述两个资源库包括两个仓库和两个项目，所述两个仓库为本地仓库和远程仓库，所述两个项目为本地项目和远程项目。

上述的一种投影多平台服务适配的方法，通过配置两个资源库，然后使本地电脑和远程仓库分别去依赖两个资源库，实现不同资源灵活使用不同依赖方式，达到自由组合依赖方式的目的。

实施例3

一种投影多平台服务适配的方法，实现所述方法首先要对整个工程项目进行结构划分，形成支持多平台的系统服务工程，主要分为三个部分，包括UI交互层、功能模块注册以及通用接口标准化处理以及事件分发层、具体平台功能实现层，其中所述具体平台功能实现层进行三层划分，包括平台默认基础实现层、平台具体型号实现层、平台具体机型实现层，任何类似的功能均可以在所述UI交互层和所述功能模块注册以及通用接口标准化处理以及事件分发层这两层内完成，而所述具体平台功能实现层是真正实现平台相关代码的层。

以往的软件结构划分只是简单的mvc或者mvp架构思想，都是针对于某个产品，本发明站在更高的角度提出平台化、型号化的概念，对于一些平台特性的功能放到平台层去实现，对于型号特性的功能放在型号层去实现，并且根据编程思维的抽象概念对外保持接口统一，使外部调用没有区别进行解耦，对于一样的功能使用继承，对于有区别的功能，在相应的层级下进行重写即可。

实施例4

一种投影多平台服务适配的方法，包括：

将一款机型作为标准并将所述机型的实现放在平台默认基础实现层中，在本地电脑和远程仓库所在的电脑上分别配置两个资源库并使所述本地电脑和所述远程仓库分别依赖所述两个资源库，所述本地代码和所述远程仓库中的其他代码依旧采用原有的方式进行代码同步，依赖资源的部分采用本地仓库路径依赖方式，将所有系统依赖包放到相应仓库中维护并配置Jenkins参数进行加载所述系统依赖包；

其中，所述两个资源库包括两个仓库和两个项目，所述两个仓库为本地仓库和远程仓库，所述两个项目为本地项目和远程项目；

所述本地项目依赖本地仓库，所述远程项目依赖远程仓库。

传统的方案是：各个应用分别使用compileOnly依赖系统依赖包，各个应用使用implementation或者compileOnly的方式依赖系统依赖包，这种方案存在缺陷，第一点：如果系统依赖包有所替换，需要更新所有应用，很容易造成遗漏，导致不同应用之间使用的系统依赖包不一样而出现各种问题；第二点：第二点是为了解决第一点而存在的，然而它存在另一个弊端，就是仓库中的包只能使用一种依赖方式，compileOnly或者implementation，但是在实际开发中，往往会存在很多系统依赖包，而依赖的方式是未知的。

示例性的，本发明提供的一种可选择的实施方式，首先有两个仓库：本地仓库和远程仓库，这两个仓库都是用来存放系统相关的依赖包，且根据平台、型号等信息做了更加细致的维度划分，即一个仓库存放着多平台多型号的系统依赖包，同时项目分成两个部分：本地项目和远程项目，本地项目是供各个开发人员进行功能开发，远程项目是供各个开发人员进行代码整合和统一包输出，本地项目依赖本地仓库，远程项目依赖远程仓库。

所有系统依赖包放到相应仓库中进行维护，统一了各个应用的依赖包入口，由于依赖的是本地仓库中的资源文件，可以灵活的选择依赖的方式，只需要同步好本地仓库和远程仓库中的资源即可。

实施例5

一种投影多平台服务适配的方法，包括：

将一款机型作为标准并将所述机型的实现放在平台默认基础实现层中，在本地电脑和远程仓库所在的电脑上分别配置两个资源库并使所述本地电脑和所述远程仓库分别依赖所述两个资源库，所述本地代码和所述远程仓库中的其他代码依旧采用原有的方式进行代码同步，依赖资源的部分采用本地仓库路径依赖方式，将所有系统依赖包放到相应仓库中维护并配置Jenkins参数进行加载所述系统依赖包；

其中，所述两个资源库包括两个仓库和两个项目，所述两个仓库为本地仓库和远程仓库，所述两个项目为本地项目和远程项目；

所述配置Jenkins参数进行加载所述系统依赖包包括：

在项目中根据具体型号生成一份配置表，然后根据所述配置表加载需要依赖的相关系统资源和相关层级代码结构，在Jenkins上面配置需要打包的具体机型型号。

示例性的，传统方案是在Jenkins上面进行相关的配置，然后进行统一包的输出，该方案存在的缺陷是：流水线的方式比如mstar配置mstar launcher App，launcher App使用多个仓库进行管理，同一个功能需要实现很多遍。

现在的方案是：由于现在进行功能划分，将多平台的一个应用比如launcher合并到一个工程中去开发维护，因而原来那套单平台打包配置，就显的不那么合适，因为再打的时候，不能确定需要打的是那种平台或者型号的包，现在的解决方案是会在项目中根据具体型号，生成一份配置表，然后根据该配置表，去加载需要依赖相关系统资源和相关层级代码结构，这样就达到了通过一个配置进行相关正确的信息资源的加载，从而实现打出正确的包。

而在Jenkins上面的配置也很简单，只需要在上面配置一下需要打的具体的机型型号即可。

只需要维护一个工程项目，这个工程项目是同时适配支持mstar平台和amlogic平台，这种适配不同于传统的适配，传统的适配方案会同时引入mstar平台和amlogic两个平台的jar包，不同平台的jar包含有的是不同平台的功能接口，假如同时引入两个平台的jar包则可以满足同时运行在两个平台上，但是这样会带来很多问题，比如：整个的apk大小变大；代码内部需要在运行时根据不同平台来选择执行不同的方法；假如增加一个新的平台，需要继续引入新的jar包，导致apk继续变大。

在工程的结构上，我们把与平台相关的部分抽离成单独的模块，这些模块就类似于不同的零件，所有的模块我们封装了统一的接口，也就是说在调用平台功能的时候，我们只调用我们自己封装的接口，接口实现在不同模块的内部，模块不支持这个功能，接口依然可以调用，只是不会返回正确的结果。

经过这样的改造，我们在工程里就包含了不同平台的很多可以自定义的零件，这些零件可以动态的装载到工程上，需要装载哪个模块到工程中去，可通过本地的配置文件来完成，这样就实现了不同的工程只加载自己工程的模块，而不会引入自己不需要的模块代码。

最后借助Jenkins平台，通过Jenkins的可视化界面传入需要的平台参数，然后Grdle脚本会获取这些参数，构建apk包时就会根据这些配置选择相应平台的模块打出具体平台的包。

实施例6

一种电子设备，包括存储器和处理器，所述存储器用于存储一条或多条计算机指令，其中，所述一条或多条计算机指令被所述处理器执行以实现上述的一种投影多平台服务适配的方法。

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

一种存储有计算机程序的计算机可读存储介质，所述计算机程序使计算机执行时实现如上述的一种投影多平台服务适配的方法。

示例性的，计算机程序可以被分割成一个或多个模块/单元，一个或者多个模块/单元被存储在存储器中，并由处理器执行，以完成本发明。一个或多个模块/单元可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述计算机程序在计算机设备中的执行过程。

计算机设备可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。计算机设备可包括，但不仅限于，存储器、处理器。本领域技术人员可以理解，本实施例仅仅是计算机设备的示例，并不构成对计算机设备的限定，可以包括更多或更少的部件，或者组合某些部件，或者不同的部件，例如计算机设备还可以包括输入输出设备、网络接入设备、总线等。

处理器可以是中央处理单元(CentralProcessingUnit，CPU)，还可以是其他通用处理器、数字信号处理器(DigitalSignalProcessor，DSP)、专用集成电路(ApplicationSpecificIntegratedCircuit，ASIC)、现成可编程门阵列(Field-ProgRAM503mableGateArray，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

存储器可以是计算机设备的内部存储单元，例如计算机设备的硬盘或内存。存储器也可以是计算机设备的外部存储设备，例如计算机设备上配备的插接式硬盘，智能存储卡(SmartMediaCard,SMC)，安全数字(SecureDigital,SD)卡，闪存卡(FlashCard)等。进一步地，存储器还可以既包括计算机设备的内部存储单元也包括外部存储设备。存储器用于存储计算机程序以及计算机设备所需的其他程序和数据。存储器还可以用于暂时地存储已经输出或者将要输出的数据。

以上所述仅为本发明的具体实施例，但本发明的技术特征并不局限于此，任何本领域的技术人员在本发明的领域内，所作的变化或修饰皆涵盖在本发明的专利范围之中。

Claims (7)

1.一种投影多平台服务适配的方法，其特征在于，包括：

将一款机型作为标准并将所述机型的实现放在平台默认基础实现层中，在本地电脑和远程仓库所在的电脑上分别配置两个资源库并使所述本地电脑和所述远程仓库分别依赖所述两个资源库，所述本地代码和所述远程仓库中的其他代码依旧采用原有的方式进行代码同步，依赖资源的部分采用本地仓库路径依赖方式，将所有系统依赖包放到相应仓库中维护并配置Jenkins参数进行加载所述系统依赖包；

其中，所述两个资源库包括两个仓库和两个项目，所述两个仓库为本地仓库和远程仓库，所述两个项目为本地项目和远程项目。

2.根据权利要求1所述的一种投影多平台服务适配的方法，其特征在于，实现所述方法首先要对整个工程项目进行结构划分，形成支持多平台的系统服务工程，主要分为三个部分包括UI交互层、功能模块注册以及通用接口标准化处理以及事件分发层、具体平台功能实现层，其中所述具体平台功能实现层进行三层划分，包括平台默认基础实现层、平台具体型号实现层、平台具体机型实现层，任何类似的功能均可以在所述UI交互层和所述功能模块注册以及通用接口标准化处理以及事件分发层这两层内完成，而所述具体平台功能实现层是真正实现平台相关代码的层。

3.根据权利要求1所述的一种投影多平台服务适配的方法，其特征在于，所述本地项目依赖本地仓库，所述远程项目依赖远程仓库。

4.根据权利要求1所述的一种投影多平台服务适配的方法，其特征在于，所述配置Jenkins参数进行加载所述系统依赖包包括：

在项目中根据具体型号生成一份配置表，然后根据所述配置表加载需要依赖的相关系统资源和相关层级代码结构，在Jenkins上面配置需要打包的具体机型型号。

5.根据权利要求书1所述的一种投影多平台服务适配的方法，其特征在于，所述将所有系统依赖包放到相应仓库中维护包括：

同步本地仓库和远程仓库中的资源，将所有系统依赖包放到相应仓库中进行维护，统一各个应用的依赖包入口，由于依赖的是本地仓库中的资源文件，可以灵活选择依赖的方式。

6.一种电子设备，其特征在于，包括存储器和处理器，所述存储器用于存储一条或多条计算机指令，其中，所述一条或多条计算机指令被所述处理器执行以实现如权利要求1～5中任一项所述的一种投影多平台服务适配的方法。

7.一种存储有计算机程序的计算机可读存储介质，其特征在于，所述计算机程序使计算机执行时实现如权利要求1～5中任一项所述的一种投影多平台服务适配的方法。

Images