CN108089989B - 一种路径检测方法、电子设备及可读存储介质 - Google Patents
一种路径检测方法、电子设备及可读存储介质 Download PDFInfo
- Publication number
- CN108089989B CN108089989B CN201810008841.5A CN201810008841A CN108089989B CN 108089989 B CN108089989 B CN 108089989B CN 201810008841 A CN201810008841 A CN 201810008841A CN 108089989 B CN108089989 B CN 108089989B
- Authority
- CN
- China
- Prior art keywords
- interface
- preset
- path
- detection
- function
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3684—Test management for test design, e.g. generating new test cases
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3688—Test management for test execution, e.g. scheduling of test suites
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/40—Transformation of program code
- G06F8/41—Compilation
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Abstract
本发明实施例提供了一种路径检测方法、电子设备及可读存储介质，用于提供一种路径合法性的自动检测方法，节约了人工成本和时间成本，有效减少了因路径不规范导致组件间通信失败的问题。该路径检测方法包括：在检测管理器中创建与预设接口对应的预设接口对象，采用与所述预设接口对应的预设实现类实例化所述预设接口对象，获得预设实例化对象；其中，所述预设接口包括接口库中的一个或多个接口，所述接口库中的每个接口设置有与该接口对应的检测方法函数，每个检测方法函数对应一个预设规则；在所述检测管理器中创建路径检测函数；通过所述路径检测函数调用所述预设实例化对象对应的检测方法函数对组件间的路由路径进行检测。
Description
技术领域
本发明涉及电子技术领域，尤其涉及一种路径检测方法、电子设备及可读存储介质。
背景技术
在安卓平台的应用程序开发过程中，会使用组件化相关的技术来对应用程序进行改造。在组件化过程中，为了方便各个组件之间进行，引入页面路由构架ARouter作为组件之间进行信息交流的事件桥接器。
ARouter的事件桥接器的设计非常类似于网页设计，组件之间通过一个唯一的路径进行通信。在ARouter内部对组件间的路由路径的命名有着严格的要求，但是目前在编译期间由于编译器不会对组件间的路由路径进行检测，所以可能会出现编译成功后，当软件在运行的时候导致ARouter中的路径不规范而导致组件之间通信失败。现有技术中通常依靠人工的方式对ARouter中的路径进行合法性检测，每次条路径均需要人工检测该路径是否合乎命名规范，这样就会导致在路径检测上耗费较高的时间成本和人力成本。并且，一旦因为路径不规范导致组件间通信失败，会需要大量的时间去排查和定位错误，对人力资源是一种极大的浪费。
发明内容
本发明实施例提供了一种路径检测方法、电子设备及可读存储介质，用于提供一种ARouter中路径合法性的自动检测方法，节约了人工成本和时间成本，有效减少了因ARouter中路径不规范导致通信失败的问题。
第一方面，本发明提供了一种路径检测方法，包括：
在检测管理器中创建与预设接口对应的预设接口对象，采用与所述预设接口对应的预设实现类实例化所述预设接口对象，获得预设实例化对象；其中，所述预设接口包括接口库中的一个或多个接口，所述接口库中的每个接口设置有与该接口对应的检测方法函数，每个检测方法函数对应一个预设规则，不同的检测方法函数对应不同的预设规则；
在所述检测管理器中创建路径检测函数；
通过所述路径检测函数调用所述预设实例化对象对应的检测方法函数对组件间的路由路径进行检测。
可选的，在所述在检测管理器中创建路径检测函数之前，所述方法还包括：
创建接口库，所述接口库中包括一个或多个接口，定义每个接口的检测方法函数，每个检测方法函数对应一个预设规则，不同的检测方法函数对应不同的预设规则；
创建与所述一个或多个接口一一对应的一个或多个实现类，每个实现类继承所述一个或多个接口中的一个接口，不同的实现类继承的接口不同，所述每个实现类中复写有继承的接口中的检测方法函数。
可选的，所述接口库中包括第一接口，所述第一接口对应的第一检测方法函数为检测路径是否以第一预设字符开头的函数，如果所述组件间的路由路径以所述第一预设字符开头，则路径检测成功。
可选的，所述接口库中包括第二接口，所述第二接口对应的第二检测方法函数为检测路径中是否包括第二预设字符的函数，如果所述组件间的路由路径中不包括所述第二预设字符，则路径检测成功。
可选的，在所述通过所述路径检测函数调用所述预设实例化对象对应的检测方法函数对组件间的路由路径进行检测之后，所述方法还包括：
如果路径检测成功，则编译预设编译脚本；
如果路径检测失败，则返回编译失败结果。
可选的，所述方法还包括：
添加第三接口至所述接口库，定义所述第三接口的第三检测方法函数，所述第三检测方法函数对应第三预设规则；
创建与所述第三接口对应的第三实现类，所述第三实现类继承所述第三接口，所述第三实现类中复写有所述第三接口中的所述第三检测方法函数。
第二方面，本发明实施例提供一种电子设备，所述电子设备包括：
实例化单元，用于在检测管理器中创建与预设接口对应的预设接口对象，采用与所述预设接口对应的预设实现类实例化所述预设接口对象，获得预设实例化对象；其中，所述预设接口包括接口库中的一个或多个接口，所述接口库中的每个接口设置有与该接口对应的检测方法函数，每个检测方法函数对应一个预设规则，不同的检测方法函数对应不同的预设规则；
第一创建单元，用于在所述检测管理器中创建路径检测函数；
路径检测单元，用于通过所述路径检测函数调用所述预设实例化对象对应的检测方法函数对组件间的路由路径进行检测。
可选的，所述电子设备还包括：
第二创建单元，在所述在检测管理器中创建路径检测函数之前，创建接口库，所述接口库中包括一个或多个接口，定义每个接口的检测方法函数，每个检测方法函数对应一个预设规则，不同的检测方法函数对应不同的预设规则；
第三创建单元，用于创建与所述一个或多个接口一一对应的一个或多个实现类，每个实现类继承所述一个或多个接口中的一个接口，不同的实现类继承的接口不同，所述每个实现类中复写有继承的接口中的检测方法函数。
可选的，所述接口库中包括第一接口，所述第一接口对应的第一检测方法函数为检测路径是否以第一预设字符开头的函数，如果所述组件间的路由路径以所述第一预设字符开头，则路径检测成功。
可选的，所述接口库中包括第二接口，所述第二接口对应的第二检测方法函数为检测路径中是否包括第二预设字符的函数，如果所述组件间的路由路径中不包括所述第二预设字符，则路径检测成功。
可选的，所述电子设备还包括：
编译单元，用于在所述通过所述路径检测函数调用所述预设实例化对象对应的检测方法函数对组件间的路由路径进行检测之后，如果路径检测成功，则编译预设编译脚本；如果路径检测失败，则返回编译失败结果。
可选的，所述电子设备还包括：
添加单元，用于添加第三接口至所述接口库，定义所述第三接口的第三检测方法函数，所述第三检测方法函数对应第三预设规则；创建与所述第三接口对应的第三实现类，所述第三实现类继承所述第三接口，所述第三实现类中复写有所述第三接口中的所述第三检测方法函数。
第三方面，本发明实施例提供一种电子设备，所述电子设备包括处理器，所述处理器用于执行存储器中存储的计算机程序时实现如前述第一方面实施例中所述的路径检测方法的步骤。
第四方面，本发明实施例提供了一种可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如前述第一方面实施例中所述的路径检测方法的步骤。
本申请实施例中的上述一个或多个技术方案，至少具有如下一种或多种技术效果：
在本发明实施例的技术方案中，电子设备的接口库中预先创建有多个接口，每个接口中定义有检测方法函数，每个检测方法函数对应一个预设规则，进而，在编译期间检测ARouter的路径是否满足一个或多个预设规则时，在检测管理器中仅需要实例化该规则对应的接口对象，然后创建路径检测函数，通过该路径检测函数调用实例化对象中的检测方法函数即可对组件间的路由路径的合法性进行检测。因此，提供一种ARouter中路径合法性的自动检测方法，减少了软件到运行期间因ARouter中路径不规范导致通信失败，进而花费大量的时间排查问题，极大的提高了开发效率，降低了人工成本。
附图说明
图1为本发明第一实施例中的一种路径检测方法的流程图；
图2为本发明第二实施例中的电子设备的示意图；
图3为本发明第三实施例中电子设备的示意图。
具体实施方式
本发明实施例提供了一种路径检测方法、电子设备及可读存储介质，用于提供一种ARouter中路径合法性的自动检测方法，节约了人工成本和时间成本，有效减少了因ARouter中路径不规范导致通信失败的问题。该路径检测方法包括：在检测管理器中创建与预设接口对应的预设接口对象，采用与所述预设接口对应的预设实现类实例化所述预设接口对象，获得预设实例化对象；其中，所述预设接口包括接口库中的一个或多个接口，所述接口库中的每个接口设置有与该接口对应的检测方法函数，每个检测方法函数对应一个预设规则，不同的检测方法函数对应不同的预设规则；在所述检测管理器中创建路径检测函数；通过所述路径检测函数调用所述预设实例化对象对应的检测方法函数对组件间的路由路径进行检测。
下面通过附图以及具体实施例对本发明技术方案做详细的说明，应当理解本申请实施例以及实施例中的具体特征是对本申请技术方案的详细的说明，而不是对本申请技术方案的限定，在不冲突的情况下，本申请实施例以及实施例中的技术特征可以相互组合。
本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。
实施例
请参考图1，本发明第一实施例提供一种路径检测方法，该路径检测方法包括如下步骤：
S101：在检测管理器中创建与预设接口对应的预设接口对象，采用与所述预设接口对应的预设实现类实例化所述预设接口对象，获得预设实例化对象；其中，所述预设接口包括接口库中的一个或多个接口，所述接口库中的每个接口设置有与该接口对应的检测方法函数，每个检测方法函数对应一个预设规则，不同的检测方法函数对应不同的预设规则；
S102：在所述检测管理器中创建路径检测函数；
S103：通过所述路径检测函数调用所述预设实例化对象对应的检测方法函数对组件间的路由路径进行检测。
其中，在所述在检测管理器中创建路径检测函数之前，所述方法还包括：
创建接口库，所述接口库中包括一个或多个接口，定义每个接口的检测方法函数，每个检测方法函数对应一个预设规则，不同的检测方法函数对应不同的预设规则；
创建与所述一个或多个接口一一对应的一个或多个实现类，每个实现类继承所述一个或多个接口中的一个接口，不同的实现类继承的接口不同，所述每个实现类中复写有继承的接口中的检测方法函数。
所述接口库中包括第一接口，所述第一接口对应的第一检测方法函数为检测路径是否以第一预设字符开头的函数，如果所述组件间的路由路径以所述第一预设字符开头，则路径检测成功。
所述接口库中包括第二接口，所述第二接口对应的第二检测方法函数为检测路径中是否包括第二预设字符的函数，如果所述组件间的路由路径中不包括所述第二预设字符，则路径检测成功。
具体的，在本实施例中，该路径检测方法应用于软件开发平台，该软件开发平台采用安卓中的组件化技术，各组件间通过ARouter进行通信。由于现有技术中在软件编译期间，编译器不会对ARouter中的路径进行检测，所以可能会出现编译成功后，当软件在运行的时候因ARouter中的路径不规范而导致组件之间通信失败的问题。因此，本实施例中的方法，在软件编译期间对ARouter中的路径进行合法性检测，避免软件到运行期间才能够发现问题，然后花费大量的时间排查问题。
首先，本实施例首先进行路径检测规则的定制，在本实施例中，将ARouter中的路径检测规则和路径检测逻辑进行了分离设计，这种分离设计能够方便后期对组件间的路由路径的检测流程进行动态的配置，极大的提高了路径检测的灵活性和扩展性。
由此，本实施例中的路径检测方法，在ARouter中对组件间的路由路径有这样两个预设规则，第一预设规则为路径必须以“/”字符开头，如果不是以“/”字符开头会导致分发错误。第二预设规则为路径中不能包含任意的“.”字符，一旦包含了“.”字符会导致ARouter内部出现分组错误的问题。
针对上述两个预设规则，本实施例中的方法，创建了第一接口ICheck1和第二接口ICheck2，第一接口ICheck1对应第一预设规则，第二接口ICheck2对应第二预设规则。其中，第一接口ICheck1中定义了第一检测方法函数checkStart，该函数用于对ARouter中的路径的开头进行检测。同理，第二接口ICheck2中定义第二检测方法函数checkContent，该函数用于对ARouter中的路径内容进行检测，判定路径中是否包含“.”字符。通过设计了两个接口ICheck1和ICheck2，并制定了对应的检测方法函数的方式来定制了路径检测的规则，本实施例中的接口库中包括上述第一接口和第二接口。在具体实施过程中，用于路径检测的预设规则可根据实际需要进行设定，在此，本申请不做限制。
本实施例中，对组件间的路由路径检测的规则都是进行分离设计的，接口库中的每个接口对应一个预设规则及一个检测方法函数。如果需要增加新的检测规则，仅仅需要增加一个新的接口并定义与该接口对应的检测方法函数即可，对接口库中原有的接口以及与原有接口对应的检测方法函数不会造成任何的影响。
然后，本实施例中的方法定义路径检测的实现业务逻辑，通过上述描述可知，本实施例中的方法已经制定了路径检测的规则，接下来主要是对上述规则的业务逻辑进行具体的业务实现。
为了实现上述接口的业务逻辑，本实施例中针对接口库中每个接口定义对应的实现类。比如：第一接口ICheck1对应第一实现类Check1Imp，第一实现类Check1Imp继承第一接口ICheck1，第一实现类Check1Imp中复写有ICheck1中的checkStart函数。同理，第二接口ICheck2对应第二实现类Check2Imp，第二实现类Check2Imp继承第二接口ICheck2，第二实现类Check2Imp中复写有ICheck2中的checkContent函数。
其中，在checkStrart函数中通过startWitth(“/”)函数来判定路径是否以“/”开头，如果是以“/”开头，返回true表示路径检测通过，如果不是以“/”开头，返回false表示路径检测失败。同理，在checkContent函数中通过调用contains(“.”)函数来判定路径中是否含有“.”字符，如果包含“.”字符，返回false表示路径检测失败，否则返回true表示路径检测成功。
由此，本步骤根据检测规则给出了相应的检测业务实现。如果后期对检测功能进行扩展的时候仅仅需要重新定义一个实现类并继承相应的接口和实现对应的检测方法函数即可实现检测功能的扩展。
进而，在创建好接口库以及接口库中每个接口对应的实现类后，本实施例中设计用于进行路径检测的检测管理器CheckManager，需要在CheckManager中将上述业务进行组装来实现真实的检测业务逻辑。
比如：在需要通过CheckManager检测路径是否满足第一预设规则时，即路径是否以“/”开头，需要在CheckManager中创建第一接口对应的第一接口对象，采用与第一接口对应的实现类对第一接口对象实例化，获得第一实例化对象，这样，第一接口对象指向的就是其接口实现业务函数了。
然后，在CheckManger中定义一个路径检测check函数，在check函数中通过调用第一实例化对象中的checkStrart函数来实现真实的检测逻辑，检测路径是否以“/”开头，如果该函数返回true，表明路径检测成功，路径编译通过，如果该函数返回false，表明路径检测失败。
又如：在需要通过CheckManager检测路径是否满足第二预设规则时，即路径中是否含有“.”字符，需要在CheckManager中创建第二接口对应的第二接口对象，采用与第二接口对应的实现类对第二接口对象实例化，获得第二实例化对象，这样，第二接口对象指向的就是其接口实现业务函数了。
然后，在CheckManger中定义一个路径检测check函数，在check函数中通过调用第二实例化对象中的checkContent函数来实现真实的检测逻辑，检测路径中是否含有“.”字符，如果该函数返回true，表明路径检测成功，路径编译通过，如果该函数返回false，表明路径检测失败。
又如：在需要通过CheckManager检测路径是否满足第一预设规则以及第二预设规则时，即需要检测路径是否以“/”开头以及路径中是否含有“.”字符，需要在CheckManager中创建第一接口对应的第一接口对象，采用与第一接口对应的实现类对第一接口对象实例化，获得第一实例化对象，这样，第一接口对象指向的就是其接口实现业务函数了。同时，还需要创建第二接口对应的第二接口对象，采用与第二接口对应的实现类对第二接口对象实例化，获得第二实例化对象，这样，第二接口对象指向的就是其接口实现业务函数了。
然后，在CheckManger中定义一个路径检测check函数，在check函数中通过调用第一实例化对象中的checkStrart函数来实现真实的检测逻辑，检测路径是否以“/”开头。并且，还需要在check函数中通过调用第二实例化对象中的checkContent函数，当checkStrart函数和checkContent函数返回的结果均为true时，表示路径检测通过。如果checkStrart函数和checkContent函数中任意一个函数返回结果为false，表明路径检测失败。
通过这样的方式，用户可以根据需要选择用于路径检测的预设规则(如仅包括第一预设规则，或者仅包括第二预设规则，或者包括第一预设规则和第二预设规则)，进而从接口库中选择对应的接口在检测管理器中创建接口对象，实例化接口对象后即可通过路径检测函数调用实例化对象中的方法函数进行路径检测。
进一步，在本实施例中，在所述通过所述路径检测函数调用所述预设实例化对象对应的检测方法函数对组件间的路由路径进行检测之后，所述方法还包括：
如果路径检测成功，则编译预设编译脚本；
如果路径检测失败，则返回编译失败结果。
具体的，在本实施例中，检测管理器的检测路径在软件编译之前运行，在安卓平台中，安卓项目是由Gradle脚本来进行编译的，Gradle脚本是面向任务的脚本，在编译脚本build.gradle文件中定义一个dobefore方法，该方法会在编译开始之前就会执行，如果该方法成功返回true整个编译才会继续执行，否则编译会停止。进而，在dobefor方法中调用CheckManger中的路径检测方法来对组件间的路由路径进行检测，路径检测成功后才会对Gradle脚本进行编译，路径检测失败后直接返回编译失败的结果。从而达到了在软件编译阶段就实现路径检测的目标。
进一步，在本实施例中，还包括如下步骤：
添加第三接口至所述接口库，定义所述第三接口的第三检测方法函数，所述第三检测方法函数对应第三预设规则；
创建与所述第三接口对应的第三实现类，所述第三实现类继承所述第三接口，所述第三实现类中复写有所述第三接口中的所述第三检测方法函数。
具体的，本实施例中的方法具有非常强大的扩展功能，可以对检测规则进行扩展，可添加新的规则对应的接口至接口库。前述示例仅描述了第一预设规则和第二预设规则，当需要判断路径是否满足第三预设规则时，可在不修改原始检测逻辑的情况下快速的接入新的检测逻辑。
接入第三预设规则的方式和上述方式类似，首先定义一个第三接口ICheck3，然后定义第三接口对应的第三检测方法函数check3，定义与第三接口ICheck3对应的第三实现类Check3Imp，第三实现类Check3Imp继承接口ICheck3并实现第三检测方法函数check3，在第三检测方法函数check3中实现第三条规则的具体检测逻辑。
如果检测器需要判断路径是否满足第三预设规则，仅需要在检测管理器内部定义第三接口对应的第三接口对象，利用第三实现类Check3Imp实例化该第三接口对象，得到第三实例化对象。然后在CheckManger中的检测路径函数中调用第三实例化对象的第三检测方法函数check3对组件间的路由路径进行检测即可。也就是说CheckManger可以动态的管理所有的检测规则，如果某些时候需要将规则2去除掉，不需要修改规则2的检测业务逻辑，仅仅将规则2定义的协议从CheckManger中移除掉即可，规则2的具体检测逻辑还是保存在代码中并且不会做任何的修改，这样后期可以通过CheckManger来对规则进行多样化的检测调整，因此就提高了整个程序检测的扩展性，极大的提高了自动检测的动态扩展能力。
本实施例的路径检测方法主要用于对ARouter中的路径进行检测，当然，还可以应用于采用组件化构架中各组件间采用路径通信的其他平台，在此，本申请不做限制。
请参见图2，本发明的第三实施例提供了一种电子设备，所述电子设备包括：
实例化单元201，用于在检测管理器中创建与预设接口对应的预设接口对象，采用与所述预设接口对应的预设实现类实例化所述预设接口对象，获得预设实例化对象；其中，所述预设接口包括接口库中的一个或多个接口，所述接口库中的每个接口设置有与该接口对应的检测方法函数，每个检测方法函数对应一个预设规则，不同的检测方法函数对应不同的预设规则；
第一创建单元202，用于在所述检测管理器中创建路径检测函数；
路径检测单元203，用于通过所述路径检测函数调用所述预设实例化对象对应的检测方法函数对组件间的路由路径进行检测。
进一步，所述电子设备还包括：
第二创建单元，在所述在检测管理器中创建路径检测函数之前，创建接口库，所述接口库中包括一个或多个接口，定义每个接口的检测方法函数，每个检测方法函数对应一个预设规则，不同的检测方法函数对应不同的预设规则；
第三创建单元，用于创建与所述一个或多个接口一一对应的一个或多个实现类，每个实现类继承所述一个或多个接口中的一个接口，不同的实现类继承的接口不同，所述每个实现类中复写有继承的接口中的检测方法函数。
其中，所述接口库中包括第一接口，所述第一接口对应的第一检测方法函数为检测路径是否以第一预设字符开头的函数，如果所述组件间的路由路径以所述第一预设字符开头，则路径检测成功。
其中，所述接口库中包括第二接口，所述第二接口对应的第二检测方法函数为检测路径中是否包括第二预设字符的函数，如果所述组件间的路由路径中不包括所述第二预设字符，则路径检测成功。
具体的，在本实施例中，该电子设备安装有软件开发平台，该软件开发平台采用安卓中的组件化技术，各组件间通过ARouter进行通信。由于现有技术中在软件编译期间，编译器不会对ARouter中的路径进行检测，所以可能会出现编译成功后，当软件在运行的时候因ARouter中的路径不规范而导致组件之间通信失败的问题。因此，本实施例中的方法，在软件编译期间对ARouter中的路径进行合法性检测，避免软件到运行期间才能够发现问题，然后花费大量的时间排查问题。
首先，本实施例中的电子设备首先进行路径检测规则的定制，在本实施例中，将ARouter中的路径检测规则和路径检测逻辑进行了分离设计，这种分离设计能够方便后期对组件间的路由路径的检测流程进行动态的配置，极大的提高了路径检测的灵活性和扩展性。
由此，本实施例中的路径检测方法，在ARouter中对组件间的路由路径有这样两个预设规则，第一预设规则为路径必须以“/”字符开头，如果不是以“/”字符开头会导致分发错误。第二预设规则为路径中不能包含任意的“.”字符，一旦包含了“.”字符会导致ARouter内部出现分组错误的问题。
针对上述两个预设规则，本实施例中的方法，第二创建单元创建了第一接口ICheck1和第二接口ICheck2，第一接口ICheck1对应第一预设规则，第二接口ICheck2对应第二预设规则。其中，第一接口ICheck1中定义了第一检测方法函数checkStart，该函数用于对ARouter中的路径的开头进行检测。同理，第二接口ICheck2中定义第二检测方法函数checkContent，该函数用于对ARouter中的路径内容进行检测，判定路径中是否包含“.”字符。通过设计了两个接口ICheck1和ICheck2，并制定了对应的检测方法函数的方式来定制了路径检测的规则，本实施例中的接口库中包括上述第一接口和第二接口。
本实施例中，对组件间的路由路径检测的规则都是进行分离设计的，接口库中的每个接口对应一个预设规则及一个检测方法函数。如果需要增加新的检测规则，仅仅需要增加一个新的接口并定义与该接口对应的检测方法函数即可，对接口库中原有的接口以及与原有接口对应的检测方法函数不会造成任何的影响。
然后，本实施例中定义路径检测的实现业务逻辑，通过上述描述可知，本实施例中已经制定了路径检测的规则，接下来通过第二创建单元主要是对上述规则的业务逻辑进行具体的业务实现。
为了实现上述接口的业务逻辑，本实施例中通过第二创建单元针对接口库中每个接口定义对应的实现类。比如：第一接口ICheck1对应第一实现类Check1Imp，第一实现类Check1Imp继承第一接口ICheck1，第一实现类Check1Imp中复写有ICheck1中的checkStart函数。同理，第二接口ICheck2对应第二实现类Check2Imp，第二实现类Check2Imp继承第二接口ICheck2，第二实现类Check2Imp中复写有ICheck2中的checkContent函数。
其中，在checkStrart函数中通过startWitth(“/”)函数来判定路径是否以“/”开头，如果是以“/”开头，返回true表示路径检测通过，如果不是以“/”开头，返回false表示路径检测失败。同理，在checkContent函数中通过调用contains(“.”)函数来判定路径中是否含有“.”字符，如果包含“.”字符，返回false表示路径检测失败，否则返回true表示路径检测成功。
由此，根据检测规则给出了相应的检测业务实现。如果后期对检测功能进行扩展的时候仅仅需要重新定义一个实现类并继承相应的接口和实现对应的检测方法函数即可实现检测功能的扩展。
进而，在创建好接口库以及接口库中每个接口对应的实现类后，本实施例中设计用于进行路径检测的检测管理器CheckManager，需要在CheckManager中将上述业务进行组装来实现真实的检测业务逻辑。
比如：在需要通过CheckManager检测路径是否满足第一预设规则时，即路径是否以“/”开头，需要通过实例化单元201在CheckManager中创建第一接口对应的第一接口对象，采用与第一接口对应的实现类对第一接口对象实例化，获得第一实例化对象，这样，第一接口对象指向的就是其接口实现业务函数了。
然后，通过第一创建单元202在CheckManger中定义一个路径检测check函数，然后通过路径检测单元203在check函数中通过调用第一实例化对象中的checkStrart函数来实现真实的检测逻辑，检测路径是否以“/”开头，如果该函数返回true，表明路径检测成功，路径编译通过，如果该函数返回false，表明路径检测失败。
又如：在需要通过CheckManager检测路径是否满足第二预设规则时，即路径中是否含有“.”字符，需要通过实例化单元201在CheckManager中创建第二接口对应的第二接口对象，采用与第二接口对应的实现类对第二接口对象实例化，获得第二实例化对象，这样，第二接口对象指向的就是其接口实现业务函数了。
然后，通过第一创建单元202在CheckManger中定义一个路径检测check函数，通过路径检测单元203在check函数中通过调用第二实例化对象中的checkContent函数来实现真实的检测逻辑，检测路径中是否含有“.”字符，如果该函数返回true，表明路径检测成功，路径编译通过，如果该函数返回false，表明路径检测失败。
又如：在需要通过CheckManager检测路径是否满足第一预设规则以及第二预设规则时，即需要检测路径是否以“/”开头以及路径中是否含有“.”字符，需要通过实例化单元201在CheckManager中创建第一接口对应的第一接口对象，采用与第一接口对应的实现类对第一接口对象实例化，获得第一实例化对象，这样，第一接口对象指向的就是其接口实现业务函数了。同时，还需要创建第二接口对应的第二接口对象，采用与第二接口对应的实现类对第二接口对象实例化，获得第二实例化对象，这样，第二接口对象指向的就是其接口实现业务函数了。
然后，通过第一创建单元202在CheckManger中定义一个路径检测check函数，通过路径检测单元203在check函数中通过调用第一实例化对象中的checkStrart函数来实现真实的检测逻辑，检测路径是否以“/”开头。并且，还需要在check函数中通过调用第二实例化对象中的checkContent函数，当checkStrart函数和checkContent函数返回的结果均为true时，表示路径检测通过。如果checkStrart函数和checkContent函数中任意一个函数返回结果为false，表明路径检测失败。
通过这样的方式，用户可以根据需要选择用于路径检测的预设规则(如仅包括第一预设规则，或者仅包括第二预设规则，或者包括第一预设规则和第二预设规则)，进而从接口库中选择对应的接口在检测管理器中创建接口对象，实例化接口对象后即可通过路径检测函数调用实例化对象中的方法函数进行路径检测。
进一步，在本实施例中，所述电子设备还包括：
编译单元，用于在所述通过所述路径检测函数调用所述预设实例化对象对应的检测方法函数对组件间的路由路径进行检测之后，如果路径检测成功，则编译预设编译脚本；如果路径检测失败，则返回编译失败结果。
具体的，在本实施例中，检测管理器的检测路径在软件编译之前运行，在安卓平台中，安卓项目是由Gradle脚本来进行编译的，Gradle脚本是面向任务的脚本，在编译脚本build.gradle文件中定义一个dobefore方法，该方法会在编译开始之前就会执行，如果该方法成功返回true整个编译才会继续执行，否则编译会停止。进而，在dobefor方法中调用CheckManger中的路径检测方法来对组件间的路由路径进行检测，路径检测成功后编译单元才会对Gradle脚本进行编译，路径检测失败后编译单元直接返回编译失败的结果。从而达到了在软件编译阶段就实现路径检测的目标。
进一步，在本实施例中，所述电子设备还包括：
添加单元，用于添加第三接口至所述接口库，定义所述第三接口的第三检测方法函数，所述第三检测方法函数对应第三预设规则；创建与所述第三接口对应的第三实现类，所述第三实现类继承所述第三接口，所述第三实现类中复写有所述第三接口中的所述第三检测方法函数。添加第三接口至所述接口库，定义所述第三接口的第三检测方法函数，所述第三检测方法函数对应第三预设规则；
创建与所述第三接口对应的第三实现类，所述第三实现类继承所述第三接口，所述第三实现类中复写有所述第三接口中的所述第三检测方法函数。
具体的，本实施例中的方法具有非常强大的扩展功能，可以对检测规则进行扩展，可通过添加单元添加新的规则对应的接口至接口库。前述示例仅描述了第一预设规则和第二预设规则，当需要判断路径是否满足第三预设规则时，可在不修改原始检测逻辑的情况下快速的接入新的检测逻辑。
添加单元接入第三预设规则的方式和上述方式类似，首先定义一个第三接口ICheck3，然后定义第三接口对应的第三检测方法函数check3，定义与第三接口ICheck3对应的第三实现类Check3Imp，第三实现类Check3Imp继承接口ICheck3并实现第三检测方法函数check3，在第三检测方法函数check3中实现第三条规则的具体检测逻辑。
如果检测器需要判断路径是否满足第三预设规则，仅需要在检测管理器内部定义第三接口对应的第三接口对象，利用第三实现类Check3Imp实例化该第三接口对象，得到第三实例化对象。然后在CheckManger中的检测路径函数中调用第三实例化对象的第三检测方法函数check3对组件间的路由路径进行检测即可。也就是说CheckManger可以动态的管理所有的检测规则，如果某些时候需要将规则2去除掉，不需要修改规则2的检测业务逻辑，仅仅将规则2定义的协议从CheckManger中移除掉即可，规则2的具体检测逻辑还是保存在代码中并且不会做任何的修改，这样后期可以通过CheckManger来对规则进行多样化的检测调整，因此就提高了整个程序检测的扩展性，极大的提高了自动检测的动态扩展能力。
请参见图3，本发明的第三实施例提供了一种电子设备，该实施例的电子设备包括：处理器301、存储器302以及存储在所述存储器中并可在所述处理器上运行的计算机程序，例如第一实施例中路径检测方法对应的程序。所述处理器执行所述计算机程序时实现上述第一实施例中各路径检测中的步骤。或者，所述处理器执行所述计算机程序时实现上述第二实施例的电子设备中各模块/单元的功能。
示例性的，所述计算机程序可以被分割成一个或多个模块/单元，所述一个或者多个模块/单元被存储在所述存储器中，并由所述处理器执行，以完成本发明。所述一个或多个模块/单元可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述所述计算机程序在所述计算机装置中的执行过程。例如，所述计算机程序可以被分割成实例化单元、第一创建单元、路径检测单元的功能，各单元具体功能如下：
实例化单元，用于在检测管理器中创建与预设接口对应的预设接口对象，采用与所述预设接口对应的预设实现类实例化所述预设接口对象，获得预设实例化对象；其中，所述预设接口包括接口库中的一个或多个接口，所述接口库中的每个接口设置有与该接口对应的检测方法函数，每个检测方法函数对应一个预设规则，不同的检测方法函数对应不同的预设规则；
第一创建单元，用于在所述检测管理器中创建路径检测函数；
路径检测单元，用于通过所述路径检测函数调用所述预设实例化对象对应的检测方法函数对组件间的路由路径进行检测。
所述电子设备可包括，但不仅限于，处理器、存储器。本领域技术人员可以理解，所述示意图3仅仅是计算机装置的示例，并不构成对电子设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如所述电子设备还可以包括输入输出设备、网络接入设备、总线等。
所称处理器301可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等，所述处理器是所述计算机装置的控制中心，利用各种接口和线路连接整个计算机装置的各个部分。
所述存储器302可用于存储所述计算机程序和/或模块，所述处理器通过运行或执行存储在所述存储器内的计算机程序和/或模块，以及调用存储在存储器内的数据，实现所述计算机装置的各种功能。所述存储器可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据手机的使用所创建的数据(比如音频数据、视频数据等)等。此外，存储器可以包括高速随机存取存储器，还可以包括非易失性存储器，例如硬盘、内存、插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(Flash Card)、至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。
进一步，该电子设备所包括的处理器301还具有以下功能：
创建接口库，所述接口库中包括一个或多个接口，定义每个接口的检测方法函数，每个检测方法函数对应一个预设规则，不同的检测方法函数对应不同的预设规则；
创建与所述一个或多个接口一一对应的一个或多个实现类，每个实现类继承所述一个或多个接口中的一个接口，不同的实现类继承的接口不同，所述每个实现类中复写有继承的接口中的检测方法函数。
进一步，所述接口库中包括第一接口，所述第一接口对应的第一检测方法函数为检测路径是否以第一预设字符开头的函数，如果所述组件间的路由路径以所述第一预设字符开头，则路径检测成功。
进一步，所述接口库中包括第二接口，所述第二接口对应的第二检测方法函数为检测路径中是否包括第二预设字符的函数，如果所述组件间的路由路径中不包括所述第二预设字符，则路径检测成功。
进一步，该电子设备所包括的处理器301还具有以下功能：
在所述通过所述路径检测函数调用所述预设实例化对象对应的检测方法函数对组件间的路由路径进行检测之后，如果路径检测成功，则编译预设编译脚本；如果路径检测失败，则返回编译失败结果。
进一步，该电子设备所包括的处理器301还具有以下功能：
添加第三接口至所述接口库，定义所述第三接口的第三检测方法函数，所述第三检测方法函数对应第三预设规则；
创建与所述第三接口对应的第三实现类，所述第三实现类继承所述第三接口，所述第三实现类中复写有所述第三接口中的所述第三检测方法函数。
本发明第四实施例提供了一种计算机可读存储介质，其上存储有计算机程序，本发明第二实施例中的所述电子设备集成的功能单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实现上述第一实施例的路径检测方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，Random Access Memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。
在本发明实施例的技术方案中，电子设备的接口库中预先创建有多个接口，每个接口中定义有检测方法函数，每个检测方法函数对应一个预设规则，进而，在编译期间检测ARouter的路径是否满足一个或多个预设规则时，在检测管理器中仅需要实例化该规则对应的接口对象，然后创建路径检测函数，通过该路径检测函数调用实例化对象中的检测方法函数即可对组件间的路由路径的合法性进行检测。提供一种ARouter中路径合法性的自动检测方法，减少了软件到运行期间因ARouter中路径不规范导致通信失败，进而花费大量的时间排查问题，极大的提高了开发效率，降低了人工成本。
尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。
显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。
Claims (8)
1.一种路径检测方法，其特征在于，包括：
在检测管理器中创建与预设接口对应的预设接口对象，采用与所述预设接口对应的预设实现类实例化所述预设接口对象，获得预设实例化对象；其中，所述预设接口包括接口库中的一个或多个接口，所述接口库中的每个接口设置有与该接口对应的检测方法函数，每个检测方法函数对应一个预设规则，不同的检测方法函数对应不同的预设规则；
其中，所述接口库中包括第一接口，所述第一接口对应的第一检测方法函数为检测组件间的路由路径是否以第一预设字符开头的函数，如果所述组件间的路由路径以所述第一预设字符开头，则路径检测成功，所述第一预设字符为“/”；和/或
所述接口库中包括第二接口，所述第二接口对应的第二检测方法函数为检测组件间的路由路径中是否包括第二预设字符的函数，如果组件间的路由路径中不包括所述第二预设字符，则路径检测成功，所述第二预设字符为“.”；
在所述检测管理器中创建路径检测函数；
通过所述路径检测函数调用所述预设实例化对象对应的检测方法函数对组件间的路由路径进行检测。
2.如权利要求1所述的方法，其特征在于，在所述在检测管理器中创建路径检测函数之前，所述方法还包括：
创建接口库，所述接口库中包括一个或多个接口，定义每个接口的检测方法函数，每个检测方法函数对应一个预设规则，不同的检测方法函数对应不同的预设规则；
创建与所述一个或多个接口一一对应的一个或多个实现类，每个实现类继承所述一个或多个接口中的一个接口，不同的实现类继承的接口不同，所述每个实现类中复写有继承的接口中的检测方法函数。
3.如权利要求1所述的方法，其特征在于，在所述通过所述路径检测函数调用所述预设实例化对象对应的检测方法函数对所述组件间的路由路径进行检测之后，所述方法还包括：
如果路径检测成功，则编译预设编译脚本；
如果路径检测失败，则返回编译失败结果。
4.如权利要求2所述的方法，其特征在于，所述方法还包括：
添加第三接口至所述接口库，定义所述第三接口的第三检测方法函数，所述第三检测方法函数对应第三预设规则；
创建与所述第三接口对应的第三实现类，所述第三实现类继承所述第三接口，所述第三实现类中复写有所述第三接口中的所述第三检测方法函数。
5.一种电子设备，其特征在于，包括：
实例化单元，用于在检测管理器中创建与预设接口对应的预设接口对象，采用与所述预设接口对应的预设实现类实例化所述预设接口对象，获得预设实例化对象；其中，所述预设接口包括接口库中的一个或多个接口，所述接口库中的每个接口设置有与该接口对应的检测方法函数，每个检测方法函数对应一个预设规则，不同的检测方法函数对应不同的预设规则；
其中，所述接口库中包括第一接口，所述第一接口对应的第一检测方法函数为检测组件间的路由路径是否以第一预设字符开头的函数，如果所述组件间的路由路径以所述第一预设字符开头，则路径检测成功，所述第一预设字符为“/”；和/或
所述接口库中包括第二接口，所述第二接口对应的第二检测方法函数为检测组件间的路由路径中是否包括第二预设字符的函数，如果组件间的路由路径中不包括所述第二预设字符，则路径检测成功，所述第二预设字符为“.”；
第一创建单元，用于在所述检测管理器中创建路径检测函数；
路径检测单元，用于通过所述路径检测函数调用所述预设实例化对象对应的检测方法函数对组件间的路由路径进行检测。
6.如权利要求5所述的电子设备，其特征在于，所述电子设备还包括：
第二创建单元，在所述在检测管理器中创建路径检测函数之前，创建接口库，所述接口库中包括一个或多个接口，定义每个接口的检测方法函数，每个检测方法函数对应一个预设规则，不同的检测方法函数对应不同的预设规则；
第三创建单元，用于创建与所述一个或多个接口一一对应的一个或多个实现类，每个实现类继承所述一个或多个接口中的一个接口，不同的实现类继承的接口不同，所述每个实现类中复写有继承的接口中的检测方法函数。
7.一种电子设备，其特征在于，所述电子设备包括处理器，所述处理器用于执行存储器中存储的计算机程序时实现如权利要求1-4中任一项所述的路径检测方法的步骤。
8.一种可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1-4中任一项所述的路径检测方法的步骤。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810008841.5A CN108089989B (zh) | 2018-01-04 | 2018-01-04 | 一种路径检测方法、电子设备及可读存储介质 |
| PCT/CN2018/082167 WO2019134286A1 (zh) | 2018-01-04 | 2018-04-08 | 一种路径检测方法、电子设备及可读存储介质 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810008841.5A CN108089989B (zh) | 2018-01-04 | 2018-01-04 | 一种路径检测方法、电子设备及可读存储介质 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN108089989A CN108089989A (zh) | 2018-05-29 |
| CN108089989B true CN108089989B (zh) | 2020-10-16 |
Family
ID=62181601
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201810008841.5A Active CN108089989B (zh) | 2018-01-04 | 2018-01-04 | 一种路径检测方法、电子设备及可读存储介质 |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN108089989B (zh) |
| WO (1) | WO2019134286A1 (zh) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109413452B (zh) * | 2018-09-30 | 2021-02-02 | 武汉斗鱼网络科技有限公司 | 基于不同方式的弹幕校验方法、装置、终端及存储介质 |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8255851B1 (en) * | 2008-06-24 | 2012-08-28 | Marvell Israel (M.I.S.L) Ltd. | Method and system for timing design |
| CN102789417A (zh) * | 2012-04-27 | 2012-11-21 | 北京大学 | 一种移动智能终端上的定向符号执行程序检测系统及方法 |
| CN103440196A (zh) * | 2013-07-11 | 2013-12-11 | 大连交通大学 | 一种新型操作系统资源问题检测方法 |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8122436B2 (en) * | 2007-11-16 | 2012-02-21 | Microsoft Corporation | Privacy enhanced error reports |
| CN105765528B (zh) * | 2013-11-13 | 2019-09-24 | 微软技术许可有限责任公司 | 具有可配置原点定义的应用执行路径跟踪的方法、系统和介质 |
| CN106354632B (zh) * | 2016-08-24 | 2019-03-12 | 北京奇虎测腾安全技术有限公司 | 一种基于静态分析技术的源代码检测系统及方法 |
| CN107247668A (zh) * | 2017-06-07 | 2017-10-13 | 成都四象联创科技有限公司 | 代码自动检测和校正方法 |
-
2018
- 2018-01-04 CN CN201810008841.5A patent/CN108089989B/zh active Active
- 2018-04-08 WO PCT/CN2018/082167 patent/WO2019134286A1/zh active Application Filing
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8255851B1 (en) * | 2008-06-24 | 2012-08-28 | Marvell Israel (M.I.S.L) Ltd. | Method and system for timing design |
| CN102789417A (zh) * | 2012-04-27 | 2012-11-21 | 北京大学 | 一种移动智能终端上的定向符号执行程序检测系统及方法 |
| CN103440196A (zh) * | 2013-07-11 | 2013-12-11 | 大连交通大学 | 一种新型操作系统资源问题检测方法 |
Non-Patent Citations (1)
| Title |
|---|
| DCT电控单元嵌入式软件编程接口库设计;文韶 等;《重庆工学院学报》;20090628;第23卷(第6期);第14-18页 * |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2019134286A1 (zh) | 2019-07-11 |
| CN108089989A (zh) | 2018-05-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20190324772A1 (en) | Method and device for processing smart contracts | |
| CN109325195B (zh) | 浏览器的渲染方法和系统、计算机设备、计算机存储介质 | |
| US20220317997A1 (en) | Online Upgrade Method for Household Appliance Multi-MCU System, Electronic Device and Medium | |
| CN111796860B (zh) | 微前端方案实现方法及装置 | |
| CN108170465B (zh) | 一种版本信息管理方法、电子设备及可读存储介质 | |
| WO2017185606A1 (zh) | 基于overlay机制的APK开发方法及系统 | |
| CN110673924B (zh) | 一种多架构容器云镜像选择方法、装置、设备及存储介质 | |
| CN109495584B (zh) | 物联网设备接入方法、装置、设备及介质 | |
| US9158521B2 (en) | Automatic provisioning of a software platform to a device ecosystem | |
| US20180309824A1 (en) | Dormant vdus in vnfd | |
| CN111399840A (zh) | 一种模块开发方法及装置 | |
| CN106201850A (zh) | 一种兼容性测试方法及装置 | |
| US8959485B2 (en) | Security protection domain-based testing framework | |
| CN115658042A (zh) | 混合应用组件式开发方法、系统、设备及存储介质 | |
| CN115391228A (zh) | 精准测试方法、装置、设备及介质 | |
| CN108089989B (zh) | 一种路径检测方法、电子设备及可读存储介质 | |
| CN110688320B (zh) | 全局变量的检测方法、装置及终端设备 | |
| CN115776515A (zh) | 一种软件服务提供方法、装置及设备 | |
| KR102324259B1 (ko) | 복수의 플랫폼을 단일 소스코드로 개발 가능한 플랫폼 통합 sdk 제공 방법 및 장치 | |
| CN113778451B (zh) | 文件加载方法、装置、计算机系统和计算机可读存储介质 | |
| CN114092590A (zh) | 电子设备及其图像渲染性能的评估方法、介质 | |
| CN110990278A (zh) | 一种测试方法及装置 | |
| CN113127103B (zh) | 一种信令系统及电子设备 | |
| CN112947897A (zh) | 跨平台的api共享方法、装置、系统及存储介质 | |
| CN112988339A (zh) | 一种数据管理方法及装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |