WO2019134286A1 - 一种路径检测方法、电子设备及可读存储介质 - Google Patents

一种路径检测方法、电子设备及可读存储介质 Download PDF

Info

Publication number
WO2019134286A1
WO2019134286A1 PCT/CN2018/082167 CN2018082167W WO2019134286A1 WO 2019134286 A1 WO2019134286 A1 WO 2019134286A1 CN 2018082167 W CN2018082167 W CN 2018082167W WO 2019134286 A1 WO2019134286 A1 WO 2019134286A1
Authority
WO
WIPO (PCT)
Prior art keywords
interface
preset
path
detection
function
Prior art date
Application number
PCT/CN2018/082167
Other languages
English (en)
French (fr)
Inventor
张磊
张文明
陈少杰
Original Assignee
武汉斗鱼网络科技有限公司
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by 武汉斗鱼网络科技有限公司 filed Critical 武汉斗鱼网络科技有限公司
Publication of WO2019134286A1 publication Critical patent/WO2019134286A1/zh

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3668Software testing
    • G06F11/3672Test management
    • G06F11/3684Test management for test design, e.g. generating new test cases
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3668Software testing
    • G06F11/3672Test management
    • G06F11/3688Test management for test execution, e.g. scheduling of test suites
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/40Transformation of program code
    • G06F8/41Compilation

Definitions

  • the present invention relates to the field of electronic technologies, and in particular, to a path detection method, an electronic device, and a readable storage medium.
  • the page routing architecture ARouter is introduced as an event bridge for information exchange between components.
  • ARouter's event bridge is designed to be very similar to web design, with components communicating through a single path.
  • the path in ARouter is not standardized and communication between components fails.
  • the legality of the path in the ARouter is usually detected manually. Each path needs to manually detect whether the path conforms to the naming convention, which results in high time cost and manpower for path detection. cost.
  • once communication between components fails due to non-standard path it will take a lot of time to troubleshoot and locate errors, which is a great waste of human resources.
  • the embodiment of the invention provides a path detection method, an electronic device and a readable storage medium, which are used for providing an automatic detection method for path legality in an Arouter, which saves labor cost and time cost, and effectively reduces the path in the ARouter. Irregularities that cause communication to fail.
  • the present invention provides a path detection method, including:
  • a preset interface object corresponding to the preset interface is created in the detection manager, and the preset interface object is instantiated by using a preset implementation object corresponding to the preset interface, to obtain a preset instantiation object;
  • the preset interface includes one or more interfaces in the interface library, and each interface in the interface library is provided with a detection method function corresponding to the interface, and each detection method function corresponds to a preset rule, and different detection method functions Corresponding to different preset rules;
  • the method further includes:
  • the interface library includes one or more interfaces, and defines a detection method function for each interface.
  • Each detection method function corresponds to a preset rule, and different detection method functions correspond to different preset rules.
  • the interface library includes a first interface
  • the first detection method function corresponding to the first interface is a function for detecting whether a path starts with a first preset character, if a routing path between the components is The path detection is successful when the first preset character begins.
  • the interface library includes a second interface
  • the second detection method function corresponding to the second interface is a function for detecting whether the second preset character is included in the path, if the routing path between the components is not Including the second preset character, the path detection is successful.
  • the method further includes:
  • the preset compilation script is compiled
  • the method further includes:
  • Adding a third interface to the interface library defining a third detection method function of the third interface, where the third detection method function corresponds to a third preset rule
  • an embodiment of the present invention provides an electronic device, where the electronic device includes:
  • An instantiation unit is configured to create a preset interface object corresponding to the preset interface in the detection manager, and instantiate the preset interface object by using a preset implementation class corresponding to the preset interface, to obtain a preset instantiation
  • the preset interface includes one or more interfaces in the interface library, and each interface in the interface library is provided with a detection method function corresponding to the interface, and each detection method function corresponds to a preset rule. Different detection method functions correspond to different preset rules;
  • a first creating unit configured to create a path detection function in the detection manager
  • the path detecting unit is configured to detect, by using the path detection function, a detection method function corresponding to the preset instantiation object to detect a routing path between components.
  • the electronic device further includes:
  • a second creating unit before creating the path detecting function in the detecting manager, creating an interface library, where the interface library includes one or more interfaces, and defining a detecting method function of each interface, and each detecting method function corresponds to a preset rule, different detection method functions corresponding to different preset rules;
  • a third creating unit configured to create one or more implementation classes corresponding to the one or more interfaces, each implementation class inheriting one of the one or more interfaces, and different implementation classes inherit The interface is different, and each of the implementation classes is overwritten with a detection method function in the inherited interface.
  • the interface library includes a first interface
  • the first detection method function corresponding to the first interface is a function for detecting whether a path starts with a first preset character, if a routing path between the components is The path detection is successful when the first preset character begins.
  • the interface library includes a second interface
  • the second detection method function corresponding to the second interface is a function for detecting whether the second preset character is included in the path, if the routing path between the components is not Including the second preset character, the path detection is successful.
  • the electronic device further includes:
  • a compiling unit configured to: after detecting the routing path between the components by using the detection function function corresponding to the preset instantiation object by the path detection function, if the path detection is successful, compiling the preset compiling script; If the path detection fails, the result of the compilation failure is returned.
  • the electronic device further includes:
  • Adding a unit for adding a third interface to the interface library defining a third detection method function of the third interface, where the third detection method function corresponds to a third preset rule; creating a corresponding interface with the third interface
  • the third implementation class, the third implementation class inherits the third interface, and the third implementation class rewrites the third detection method function in the third interface.
  • an embodiment of the present invention provides an electronic device, where the electronic device includes a processor, where the processor is configured to implement a path detection method as described in the foregoing first embodiment when executing a computer program stored in a memory. A step of.
  • an embodiment of the present invention provides a readable storage medium, where a computer program is stored thereon, and when the computer program is executed by a processor, the steps of the path detecting method according to the foregoing first embodiment are implemented. .
  • a plurality of interfaces are pre-created in the interface library of the electronic device, and each of the interfaces defines a detection method function, and each detection method function corresponds to a preset rule, and further, is detected during compilation.
  • the path of the ARouter satisfies one or more preset rules, only the interface object corresponding to the rule needs to be instantiated in the detection manager, and then a path detection function is created, and the detection method function in the instantiated object is called by the path detection function. The legality of the routing path between components can be detected.
  • an automatic detection method for path legitimacy in the ARouter which reduces the communication failure caused by the non-standardization of the path in the ARouter during the software to run, and thus takes a lot of time to check the problem, greatly improving the development efficiency and reducing the labor. cost.
  • FIG. 1 is a flowchart of a path detecting method in a first embodiment of the present invention
  • FIG. 2 is a schematic diagram of an electronic device in a second embodiment of the present invention.
  • FIG. 3 is a schematic diagram of an electronic device in a third embodiment of the present invention.
  • the embodiment of the invention provides a path detection method, an electronic device and a readable storage medium, which are used for providing an automatic detection method for path legality in an Arouter, which saves labor cost and time cost, and effectively reduces the path in the ARouter. Irregularities that cause communication to fail.
  • the path detection method includes: creating a preset interface object corresponding to the preset interface in the detection manager, instantiating the preset interface object by using a preset implementation class corresponding to the preset interface, and obtaining a preset instantiation
  • the preset interface includes one or more interfaces in the interface library, and each interface in the interface library is provided with a detection method function corresponding to the interface, and each detection method function corresponds to a preset rule.
  • the different detection method functions correspond to different preset rules; a path detection function is created in the detection manager; and the detection path function corresponding to the preset instantiation object is called by the path detection function Test.
  • a first embodiment of the present invention provides a path detection method, where the path detection method includes the following steps:
  • S101 Create a preset interface object corresponding to the preset interface in the detection manager, and instantiate the preset interface object by using a preset implementation object corresponding to the preset interface, and obtain a preset instantiation object;
  • the preset interface includes one or more interfaces in the interface library, and each interface in the interface library is provided with a detection method function corresponding to the interface, and each detection method function corresponds to a preset rule, and different detections are performed.
  • the method function corresponds to different preset rules;
  • S103 Calling, by the path detection function, a detection method function corresponding to the preset instantiation object to detect a routing path between components.
  • the method further includes: before the creating a path detection function in the detection manager, the method further includes:
  • the interface library includes one or more interfaces, and defines a detection method function of each interface.
  • Each detection method function corresponds to a preset rule, and different detection method functions correspond to different preset rules.
  • the interface library includes a first interface, and the first detection method function corresponding to the first interface is a function for detecting whether the path starts with a first preset character, if the routing path between the components is the first pre- Set the beginning of the character, the path detection is successful.
  • the interface library includes a second interface
  • the second detection method function corresponding to the second interface is a function for detecting whether a second preset character is included in the path, if the routing path between the components does not include the The second preset character, the path detection is successful.
  • the path detection method is applied to a software development platform, and the software development platform adopts a componentization technology in Android, and each component communicates through the ARouter. Since the compiler does not detect the path in the ARouter during the software compilation in the prior art, it may happen that the communication fails between the components due to the non-standard path in the ARouter when the software is running. The problem. Therefore, the method in this embodiment performs legality detection on the path in the ARouter during software compilation, avoids the problem that the software can be found during the running, and then spends a lot of time troubleshooting the problem.
  • the path detection rule is customized first.
  • the path detection rule and the path detection logic in the ARouter are separated, and the separation design can facilitate the detection of the routing path between the components later. Dynamic configuration of the process greatly improves the flexibility and scalability of path detection.
  • the path detection method in this embodiment there are two preset rules for routing paths between components in the ARouter.
  • the first preset rule is that the path must start with a "/" character, if not "/" Characters at the beginning can cause distribution errors.
  • the second preset rule is that the path cannot contain any ".” characters. Once the ".” character is included, the grouping error occurs inside the ARouter.
  • the first interface ICheck1 and the second interface ICheck2 are created by the method in this embodiment.
  • the first interface ICheck1 corresponds to the first preset rule
  • the second interface ICheck2 corresponds to the second preset rule.
  • the first detection method function checkStart is defined in the first interface ICheck1, and the function is used to detect the beginning of the path in the ARouter.
  • the second interface ICheck2 defines a second detection method function checkContent, which is used to detect the path content in the ARouter and determine whether the path contains a ".” character.
  • the two interfaces, ICheck1 and ICheck2 are designed, and the corresponding detection method function is defined to customize the path detection rule.
  • the interface library in this embodiment includes the first interface and the second interface.
  • the preset rule for the path detection may be set according to actual needs, and the present application does not limit the application.
  • the rules for routing path detection between components are separately designed, and each interface in the interface library corresponds to a preset rule and a detection method function. If you need to add a new detection rule, you only need to add a new interface and define the detection method function corresponding to the interface. The original interface in the interface library and the detection method function corresponding to the original interface will not cause any influences.
  • the method in this embodiment defines the implementation logic of the path detection. According to the above description, the method in this embodiment has already established a path detection rule, and then the specific business implementation of the service logic of the above rule is mainly implemented. .
  • a corresponding implementation class is defined for each interface in the interface library.
  • the first interface ICheck1 corresponds to the first implementation class Check1Imp
  • the first implementation class Check1Imp inherits the first interface ICheck1
  • the first implementation class Check1Imp rewrites the checkStart function in ICheck1.
  • the second interface ICheck2 corresponds to the second implementation class Check2Imp
  • the second implementation class Check2Imp inherits the second interface ICheck2
  • the second implementation class Check2Imp overwrites the checkContent function in ICheck2.
  • the startWitth("/) function is used to determine whether the path starts with “/”. If it starts with “/”, returning true indicates that the path is detected. If it does not start with "/”, it returns false. Path detection failed.
  • the contains(.” function is used to determine whether the path contains a ".” character. If the ".” character is included, returning false indicates that the path detection failed. Otherwise, returning true indicates that the path detection succeeds.
  • this step gives a corresponding detection service implementation according to the detection rule. If the detection function is extended later, it only needs to redefine an implementation class and inherit the corresponding interface and implement the corresponding detection method function to realize the extension of the detection function.
  • the detection manager CheckManager designed for path detection in this embodiment needs to be assembled in the CheckManager to implement real detection. Business logic.
  • the first interface object corresponding to the first interface needs to be created in the CheckManager, and the implementation class corresponding to the first interface is adopted.
  • the first interface object is instantiated to obtain the first instantiated object, so that the first interface object points to the interface implementation business function.
  • the second interface object corresponding to the second interface needs to be created in the CheckManager, and the second interface is corresponding to the second interface.
  • the implementation class instantiates the second interface object to obtain the second instantiated object, so that the second interface object points to the interface implementation business function.
  • the CheckManager when it is necessary to check whether the path meets the first preset rule and the second preset rule by using the CheckManager, it is necessary to detect whether the path starts with "/" and whether the path contains a ".” character, and needs to be created in the CheckManager.
  • the first interface object corresponding to the interface is instantiated by the implementation class corresponding to the first interface to obtain the first instantiated object, so that the first interface object points to the interface implementation business function.
  • the second interface object corresponding to the second interface is created, and the second interface object is instantiated by using the implementation class corresponding to the second interface to obtain the second instantiated object, so that the second interface object points to the interface.
  • Implement the business function when it is necessary to check whether the path meets the first preset rule and the second preset rule by using the CheckManager.
  • a path detection check function in CheckManger.
  • the real detection logic is implemented by calling the checkStrart function in the first instantiated object to detect whether the path starts with "/". Also, you need to call the checkContent function in the second instantiated object in the check function.
  • the path detection is passed. If the checkStrart function and any function in the checkContent function return a result of false, the path detection fails.
  • the user can select a preset rule for path detection according to requirements (such as including only the first preset rule, or only the second preset rule, or include the first preset rule and the second preset rule). Then, select the corresponding interface from the interface library to create an interface object in the detection manager. After instantiating the interface object, the path detection function can call the method function in the instantiated object to perform path detection.
  • requirements such as including only the first preset rule, or only the second preset rule, or include the first preset rule and the second preset rule.
  • the method further includes:
  • the preset compilation script is compiled
  • the detection path of the detection manager is run before the software is compiled.
  • the Android project is compiled by the Gradle script, which is a task-oriented script, and the build script is compiled.
  • a dobefore method is defined in the gradle file. This method will be executed before the compilation starts. If the method returns true, the entire compilation will continue to execute, otherwise the compilation will stop.
  • the path detection method in CheckManger is called in the dobefor method to detect the routing path between the components. After the path detection succeeds, the Gradle script is compiled, and after the path detection fails, the result of the compilation failure is directly returned. Thereby achieving the goal of implementing path detection in the software compilation phase.
  • the method further includes the following steps:
  • Adding a third interface to the interface library defining a third detection method function of the third interface, where the third detection method function corresponds to a third preset rule
  • the method in this embodiment has a very powerful extension function, and the detection rule can be extended, and the interface corresponding to the new rule can be added to the interface library.
  • the foregoing example only describes the first preset rule and the second preset rule.
  • the new detection logic can be quickly accessed without modifying the original detection logic.
  • the method of accessing the third preset rule is similar to the foregoing manner.
  • a third interface ICheck3 is defined, and then a third detection method function check3 corresponding to the third interface is defined, and a third implementation class Check3Imp corresponding to the third interface ICheck3 is defined.
  • the third implementation class Check3Imp inherits the interface ICheck3 and implements the third detection method function check3, and implements the specific detection logic of the third rule in the third detection method function check3.
  • the detector needs to determine whether the path meets the third preset rule, only the third interface object corresponding to the third interface is defined in the detection manager, and the third interface object is instantiated by using the third implementation class Check3Imp to obtain the third instance. Object. Then, the third detection method function check3 of the third instantiated object is called in the detection path function in CheckManger to detect the routing path between the components. That is to say, CheckManger can dynamically manage all the detection rules. If the rule 2 needs to be removed at some time, it is not necessary to modify the detection service logic of rule 2, and only the protocol defined by rule 2 can be removed from CheckManger. The specific detection logic of Rule 2 is still stored in the code and will not be modified. In this way, CheckManger can be used to make various detection and adjustment of the rules, thus improving the scalability of the entire program detection and greatly improving the Dynamic detection capability for automatic detection.
  • the path detection method in this embodiment is mainly used to detect the path in the ARouter. Of course, it can also be applied to other platforms that use path communication between components in the componentized architecture.
  • a third embodiment of the present invention provides an electronic device, where the electronic device includes:
  • the instantiation unit 201 is configured to create a preset interface object corresponding to the preset interface in the detection manager, and instantiate the preset interface object by using a preset implementation class corresponding to the preset interface, to obtain a preset instance.
  • the preset interface includes one or more interfaces in the interface library, each interface in the interface library is provided with a detection method function corresponding to the interface, and each detection method function corresponds to a preset Rules, different detection method functions correspond to different preset rules;
  • a first creating unit 202 configured to create a path detection function in the detection manager
  • the path detecting unit 203 is configured to detect, by using the path detection function, a detection method function corresponding to the preset instantiation object to detect a routing path between components.
  • the electronic device further includes:
  • a second creating unit before creating the path detecting function in the detecting manager, creating an interface library, where the interface library includes one or more interfaces, and defining a detecting method function of each interface, and each detecting method function corresponds to a preset rule, different detection method functions corresponding to different preset rules;
  • a third creating unit configured to create one or more implementation classes corresponding to the one or more interfaces, each implementation class inheriting one of the one or more interfaces, and different implementation classes inherit The interface is different, and each of the implementation classes is overwritten with a detection method function in the inherited interface.
  • the interface library includes a first interface, and the first detection method function corresponding to the first interface is a function for detecting whether the path starts with a first preset character, if the routing path between the components is the The path detection succeeds when a preset character begins.
  • the interface library includes a second interface
  • the second detection method function corresponding to the second interface is a function for detecting whether the second preset character is included in the path, if the routing path between the components does not include the The second preset character is described, and the path detection is successful.
  • the electronic device is installed with a software development platform, and the software development platform adopts a componentization technology in Android, and each component communicates through the ARouter.
  • the compiler does not detect the path in the ARouter during the software compilation in the prior art, it may happen that the communication fails between the components due to the non-standard path in the ARouter when the software is running. The problem. Therefore, the method in this embodiment performs legality detection on the path in the ARouter during software compilation, avoids the problem that the software can be found during the running, and then spends a lot of time troubleshooting the problem.
  • the electronic device in this embodiment first performs customization of the path detection rule.
  • the path detection rule and the path detection logic in the ARouter are separately designed. This separation design can facilitate the later inter-components.
  • the routing path detection process is dynamically configured, which greatly improves the flexibility and scalability of path detection.
  • the path detection method in this embodiment there are two preset rules for routing paths between components in the ARouter.
  • the first preset rule is that the path must start with a "/" character, if not "/" Characters at the beginning can cause distribution errors.
  • the second preset rule is that the path cannot contain any ".” characters. Once the ".” character is included, the grouping error occurs inside the ARouter.
  • the second creating unit creates the first interface ICheck1 and the second interface ICheck2, the first interface ICheck1 corresponds to the first preset rule, and the second interface ICheck2 corresponds to the second pre- Set rules.
  • the first detection method function checkStart is defined in the first interface ICheck1, and the function is used to detect the beginning of the path in the ARouter.
  • the second interface ICheck2 defines a second detection method function checkContent, which is used to detect the path content in the ARouter and determine whether the path contains a ".” character.
  • the two interfaces, ICheck1 and ICheck2 are designed, and the corresponding detection method function is defined to customize the path detection rule.
  • the interface library in this embodiment includes the first interface and the second interface.
  • the rules for routing path detection between components are separately designed, and each interface in the interface library corresponds to a preset rule and a detection method function. If you need to add a new detection rule, you only need to add a new interface and define the detection method function corresponding to the interface. The original interface in the interface library and the detection method function corresponding to the original interface will not cause any influences.
  • the implementation logic of the path detection is defined.
  • the path detection rule has been established in the embodiment, and then the second creation unit mainly performs the specific service on the service logic of the rule. achieve.
  • a corresponding implementation class is defined for each interface in the interface library by using the second creation unit.
  • the first interface ICheck1 corresponds to the first implementation class Check1Imp
  • the first implementation class Check1Imp inherits the first interface ICheck1
  • the first implementation class Check1Imp rewrites the checkStart function in ICheck1.
  • the second interface ICheck2 corresponds to the second implementation class Check2Imp
  • the second implementation class Check2Imp inherits the second interface ICheck2
  • the second implementation class Check2Imp overwrites the checkContent function in ICheck2.
  • the startWitth("/) function is used to determine whether the path starts with “/”. If it starts with “/”, returning true indicates that the path is detected. If it does not start with "/”, it returns false. Path detection failed.
  • the contains(".) function is called to determine whether the path contains a ".” character. If the ".” character is included, returning false indicates that the path detection failed, otherwise returning true indicates that the path detection is successful.
  • the corresponding detection service implementation is given according to the detection rule. If the detection function is extended later, it only needs to redefine an implementation class and inherit the corresponding interface and implement the corresponding detection method function to realize the extension of the detection function.
  • the detection manager CheckManager designed for path detection in this embodiment needs to be assembled in the CheckManager to implement real detection. Business logic.
  • the first interface object corresponding to the first interface needs to be created in the CheckManager by the instantiation unit 201, and the first interface object is adopted.
  • the implementation class corresponding to the interface instantiates the first interface object, and obtains the first instantiated object, so that the first interface object points to the interface implementation business function.
  • a path detection check function is defined in the CheckManger by the first creating unit 202, and then the real detection logic is implemented by the path detecting unit 203 in the check function by calling the checkStrart function in the first instantiated object to detect whether the path is At the beginning of "/”, if the function returns true, the path detection succeeds, the path is compiled, and if the function returns false, the path detection fails.
  • the instantiation unit 201 needs to create a second interface object corresponding to the second interface in the CheckManager, and adopts The implementation class corresponding to the second interface instantiates the second interface object, and obtains the second instantiated object, so that the second interface object points to the interface implementation business function.
  • a path detection check function is defined in the CheckManger by the first creation unit 202, and the path detection unit 203 implements the real detection logic by calling the checkContent function in the second instantiation object in the check function, and detects whether the path contains ".” character, if the function returns true, indicating that the path detection is successful, the path is compiled. If the function returns false, the path detection fails.
  • the first interface object corresponding to the first interface is created in the CheckManager, and the first interface object is instantiated by using an implementation class corresponding to the first interface, so that the first instantiated object is obtained, so that the first interface object points to the interface implementation.
  • Business function At the same time, the second interface object corresponding to the second interface is created, and the second interface object is instantiated by using the implementation class corresponding to the second interface to obtain the second instantiated object, so that the second interface object points to the interface. Implement the business function.
  • a path detection check function is defined in the CheckManger by the first creating unit 202, and the real detection logic is implemented by the path detecting unit 203 in the check function by calling the checkStrart function in the first instantiated object to detect whether the path is " /"beginning. Also, you need to call the checkContent function in the second instantiated object in the check function.
  • the path detection is passed. If the checkStrart function and any function in the checkContent function return a result of false, the path detection fails.
  • the user can select a preset rule for path detection according to requirements (such as including only the first preset rule, or only the second preset rule, or include the first preset rule and the second preset rule). Then, select the corresponding interface from the interface library to create an interface object in the detection manager. After instantiating the interface object, the path detection function can call the method function in the instantiated object to perform path detection.
  • requirements such as including only the first preset rule, or only the second preset rule, or include the first preset rule and the second preset rule.
  • the electronic device further includes:
  • a compiling unit configured to: after detecting the routing path between the components by using the detection function function corresponding to the preset instantiation object by the path detection function, if the path detection is successful, compiling the preset compiling script; If the path detection fails, the result of the compilation failure is returned.
  • the detection path of the detection manager is run before the software is compiled.
  • the Android project is compiled by the Gradle script, which is a task-oriented script, and the build script is compiled.
  • a dobefore method is defined in the gradle file. This method will be executed before the compilation starts. If the method returns true, the entire compilation will continue to execute, otherwise the compilation will stop.
  • the path detection method in CheckManger is called in the dobefor method to detect the routing path between components. After the path detection succeeds, the compiling unit compiles the Gradle script. After the path detection fails, the compiling unit directly returns the result of the compilation failure. Thereby achieving the goal of implementing path detection in the software compilation phase.
  • the electronic device further includes:
  • Adding a unit for adding a third interface to the interface library defining a third detection method function of the third interface, where the third detection method function corresponds to a third preset rule; creating a corresponding interface with the third interface
  • the third implementation class, the third implementation class inherits the third interface, and the third implementation class rewrites the third detection method function in the third interface.
  • Adding a third interface to the interface library defining a third detection method function of the third interface, where the third detection method function corresponds to a third preset rule;
  • the method in this embodiment has a very powerful extension function, and the detection rule can be extended, and the interface corresponding to the new rule can be added to the interface library by adding the unit.
  • the foregoing example only describes the first preset rule and the second preset rule.
  • the new detection logic can be quickly accessed without modifying the original detection logic.
  • the manner in which the adding unit accesses the third preset rule is similar to the above manner.
  • a third interface ICheck3 is defined, and then the third detecting method function check3 corresponding to the third interface is defined, and the third implementation class corresponding to the third interface ICheck3 is defined.
  • Check3Imp, the third implementation class Check3Imp inherits the interface ICheck3 and implements the third detection method function check3, and implements the specific detection logic of the third rule in the third detection method function check3.
  • the detector needs to determine whether the path meets the third preset rule, only the third interface object corresponding to the third interface is defined in the detection manager, and the third interface object is instantiated by using the third implementation class Check3Imp to obtain the third instance. Object. Then, the third detection method function check3 of the third instantiated object is called in the detection path function in CheckManger to detect the routing path between the components. That is to say, CheckManger can dynamically manage all the detection rules. If the rule 2 needs to be removed at some time, it is not necessary to modify the detection service logic of rule 2, and only the protocol defined by rule 2 can be removed from CheckManger. The specific detection logic of Rule 2 is still stored in the code and will not be modified. In this way, CheckManger can be used to make various detection and adjustment of the rules, thus improving the scalability of the entire program detection and greatly improving the Dynamic detection capability for automatic detection.
  • a third embodiment of the present invention provides an electronic device, where the electronic device includes: a processor 301, a memory 302, and is stored in the memory and operable on the processor.
  • a computer program such as a program corresponding to the path detection method in the first embodiment. The steps in the path detection in the first embodiment described above are implemented when the processor executes the computer program. Alternatively, the processor implements the functions of the modules/units in the electronic device of the second embodiment described above when the computer program is executed.
  • the computer program can be partitioned into one or more modules/units that are stored in the memory and executed by the processor to perform the present invention.
  • the one or more modules/units may be a series of computer program instruction segments capable of performing a particular function, the instruction segments being used to describe the execution of the computer program in the computer device.
  • the computer program can be divided into functions of an instantiation unit, a first creation unit, and a path detection unit, and the specific functions of each unit are as follows:
  • An instantiation unit is configured to create a preset interface object corresponding to the preset interface in the detection manager, and instantiate the preset interface object by using a preset implementation class corresponding to the preset interface, to obtain a preset instantiation
  • the preset interface includes one or more interfaces in the interface library, and each interface in the interface library is provided with a detection method function corresponding to the interface, and each detection method function corresponds to a preset rule. Different detection method functions correspond to different preset rules;
  • a first creating unit configured to create a path detection function in the detection manager
  • the path detecting unit is configured to detect, by using the path detection function, a detection method function corresponding to the preset instantiation object to detect a routing path between components.
  • the electronic device can include, but is not limited to, a processor, a memory. It will be understood by those skilled in the art that the schematic diagram 3 is merely an example of a computer device and does not constitute a limitation on an electronic device, and may include more or less components than those illustrated, or may combine certain components or different components.
  • the electronic device may further include an input and output device, a network access device, a bus, and the like.
  • the processor 301 may be a central processing unit (CPU), or may be other general-purpose processors, a digital signal processor (DSP), an application specific integrated circuit (ASIC), Field-Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, etc.
  • the general purpose processor may be a microprocessor or the processor or any conventional processor or the like, which is the control center of the computer device, which is connected to various parts of the entire computer device using various interfaces and lines.
  • the memory 302 can be used to store the computer program and/or module, the processor implementing the method by running or executing a computer program and/or module stored in the memory, and invoking data stored in the memory Various functions of a computer device.
  • the memory may mainly include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application required for at least one function (such as a sound playing function, an image playing function, etc.), and the like; the storage data area may be stored. Data created according to the use of the mobile phone (such as audio data, video data, etc.).
  • the memory may include a high-speed random access memory, and may also include non-volatile memory such as a hard disk, a memory, a plug-in hard disk, a smart memory card (SMC), and a Secure Digital (SD) card.
  • non-volatile memory such as a hard disk, a memory, a plug-in hard disk, a smart memory card (SMC), and a Secure Digital (SD) card.
  • F1ash Card at least one disk storage device, flash memory device, or other volatile solid-state storage device.
  • processor 301 included in the electronic device further has the following functions:
  • the interface library includes one or more interfaces, and defines a detection method function of each interface.
  • Each detection method function corresponds to a preset rule, and different detection method functions correspond to different preset rules.
  • the interface library includes a first interface
  • the first detection method function corresponding to the first interface is a function for detecting whether the path starts with a first preset character, if the routing path between the components is the The path detection succeeds when a preset character begins.
  • the interface library includes a second interface
  • the second detection method function corresponding to the second interface is a function for detecting whether the second preset character is included in the path, if the routing path between the components does not include the The second preset character is described, and the path detection is successful.
  • processor 301 included in the electronic device further has the following functions:
  • the path detection function is used to detect the routing path between the components by using the detection function function corresponding to the preset instantiation object, if the path detection is successful, the preset compilation script is compiled; if the path detection fails, Returns the result of the compilation failure.
  • processor 301 included in the electronic device further has the following functions:
  • Adding a third interface to the interface library defining a third detection method function of the third interface, where the third detection method function corresponds to a third preset rule
  • a fourth embodiment of the present invention provides a computer readable storage medium having stored thereon a computer program, and the functional unit integrated by the electronic device in the second embodiment of the present invention is implemented in the form of a software functional unit and is independent When the product is sold or used, it can be stored in a computer readable storage medium.
  • the present invention implements all or part of the flow in the path detecting method of the first embodiment described above, and may also be completed by a computer program to instruct related hardware, and the computer program may be stored in a computer readable storage.
  • the computer program when executed by the processor, implements the steps of the various method embodiments described above.
  • the computer program comprises computer program code, which may be in the form of source code, object code form, executable file or some intermediate form.
  • the computer readable medium may include any entity or device capable of carrying the computer program code, a recording medium, a USB flash drive, a removable hard disk, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM). , random access memory (RAM, Random Access Memory), electrical carrier signals, telecommunications signals, and software distribution media.
  • RAM random access memory
  • computer readable media Does not include electrical carrier signals and telecommunication signals.
  • a plurality of interfaces are pre-created in the interface library of the electronic device, and each of the interfaces defines a detection method function, and each detection method function corresponds to a preset rule, and further, is detected during compilation.
  • the path of the ARouter satisfies one or more preset rules, only the interface object corresponding to the rule needs to be instantiated in the detection manager, and then a path detection function is created, and the detection method function in the instantiated object is called by the path detection function. The legality of the routing path between components can be detected.
  • An automatic detection method for path legitimacy in the ARouter which reduces the communication failure caused by the non-standard path in the ARouter during the software to run, and then spends a lot of time to troubleshoot the problem, greatly improving the development efficiency and reducing the labor cost.

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)卡,闪存卡(F1ash Card)、至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。
进一步,该电子设备所包括的处理器301还具有以下功能:
创建接口库,所述接口库中包括一个或多个接口,定义每个接口的检测方法函数,每个检测方法函数对应一个预设规则,不同的检测方法函数对应不同的预设规则;
创建与所述一个或多个接口一一对应的一个或多个实现类,每个实现类继承所述一个或多个接口中的一个接口,不同的实现类继承的接口不同,所述每个实现类中复写有继承的接口中的检测方法函数。
进一步,所述接口库中包括第一接口,所述第一接口对应的第一检测方法 函数为检测路径是否以第一预设字符开头的函数,如果所述组件间的路由路径以所述第一预设字符开头,则路径检测成功。
进一步,所述接口库中包括第二接口,所述第二接口对应的第二检测方法函数为检测路径中是否包括第二预设字符的函数,如果所述组件间的路由路径中不包括所述第二预设字符,则路径检测成功。
进一步,该电子设备所包括的处理器301还具有以下功能:
在所述通过所述路径检测函数调用所述预设实例化对象对应的检测方法函数对组件间的路由路径进行检测之后,如果路径检测成功,则编译预设编译脚本;如果路径检测失败,则返回编译失败结果。
进一步,该电子设备所包括的处理器301还具有以下功能:
添加第三接口至所述接口库,定义所述第三接口的第三检测方法函数,所述第三检测方法函数对应第三预设规则;
创建与所述第三接口对应的第三实现类,所述第三实现类继承所述第三接口,所述第三实现类中复写有所述第三接口中的所述第三检测方法函数。
本发明第四实施例提供了一种计算机可读存储介质,其上存储有计算机程序,本发明第二实施例中的所述电子设备集成的功能单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本发明实现上述第一实施例的路径检测方法中的全部或部分流程,也可以通过计算机程序来指令相关的硬件来完成,所述的计算机程序可存储于一计算机可读存储介质中,该计算机程序在被处理器执行时,可实现上述各个方法实施例的步骤。其中,所述计算机程序包括计算机程序代码,所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括:能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是,所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减,例如在某些司法管辖区,根据立法和专利实践,计算机可读介质不包括电载波信号和电信信号。
在本发明实施例的技术方案中,电子设备的接口库中预先创建有多个接口,每个接口中定义有检测方法函数,每个检测方法函数对应一个预设规则,进而,在编译期间检测ARouter的路径是否满足一个或多个预设规则时,在检测管理器中仅需要实例化该规则对应的接口对象,然后创建路径检测函数,通过该路径检测函数调用实例化对象中的检测方法函数即可对组件间的路由路 径的合法性进行检测。提供一种ARouter中路径合法性的自动检测方法,减少了软件到运行期间因ARouter中路径不规范导致通信失败,进而花费大量的时间排查问题,极大的提高了开发效率,降低了人工成本。
尽管已描述了本发明的优选实施例,但本领域内的技术人员一旦得知了基本创造性概念,则可对这些实施例作出另外的变更和修改。所以,所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。
显然,本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样,倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内,则本发明也意图包含这些改动和变型在内。

Claims (10)

  1. 一种路径检测方法,其特征在于,包括:
    在检测管理器中创建与预设接口对应的预设接口对象,采用与所述预设接口对应的预设实现类实例化所述预设接口对象,获得预设实例化对象;其中,所述预设接口包括接口库中的一个或多个接口,所述接口库中的每个接口设置有与该接口对应的检测方法函数,每个检测方法函数对应一个预设规则,不同的检测方法函数对应不同的预设规则;
    在所述检测管理器中创建路径检测函数;
    通过所述路径检测函数调用所述预设实例化对象对应的检测方法函数对组件间的路由路径进行检测。
  2. 如权利要求1所述的方法,其特征在于,在所述在检测管理器中创建路径检测函数之前,所述方法还包括:
    创建接口库,所述接口库中包括一个或多个接口,定义每个接口的检测方法函数,每个检测方法函数对应一个预设规则,不同的检测方法函数对应不同的预设规则;
    创建与所述一个或多个接口一一对应的一个或多个实现类,每个实现类继承所述一个或多个接口中的一个接口,不同的实现类继承的接口不同,所述每个实现类中复写有继承的接口中的检测方法函数。
  3. 如权利要求2所述的方法,其特征在于,所述接口库中包括第一接口,所述第一接口对应的第一检测方法函数为检测所述组件间的路由路径是否以第一预设字符开头的函数,如果所述组件间的路由路径以所述第一预设字符开头,则路径检测成功。
  4. 如权利要求2所述的方法,其特征在于,所述接口库中包括第二接口,所述第二接口对应的第二检测方法函数为检测所述组件间的路由路径中是否包括第二预设字符的函数,如果所述组件间的路由路径中不包括所述第二预设字符,则路径检测成功。
  5. 如权利要求1所述的方法,其特征在于,在所述通过所述路径检测函数调用所述预设实例化对象对应的检测方法函数对所述组件间的路由路径进行检测之后,所述方法还包括:
    如果路径检测成功,则编译预设编译脚本;
    如果路径检测失败,则返回编译失败结果。
  6. 如权利要求2所述的方法,其特征在于,所述方法还包括:
    添加第三接口至所述接口库,定义所述第三接口的第三检测方法函数,所述第三检测方法函数对应第三预设规则;
    创建与所述第三接口对应的第三实现类,所述第三实现类继承所述第三接口,所述第三实现类中复写有所述第三接口中的所述第三检测方法函数。
  7. 一种电子设备,其特征在于,包括:
    实例化单元,用于在检测管理器中创建与预设接口对应的预设接口对象,采用与所述预设接口对应的预设实现类实例化所述预设接口对象,获得预设实例化对象;其中,所述预设接口包括接口库中的一个或多个接口,所述接口库中的每个接口设置有与该接口对应的检测方法函数,每个检测方法函数对应一个预设规则,不同的检测方法函数对应不同的预设规则;
    第一创建单元,用于在所述检测管理器中创建路径检测函数;
    路径检测单元,用于通过所述路径检测函数调用所述预设实例化对象对应的检测方法函数对组件间的路由路径进行检测。
  8. 如权利要求7所述的电子设备,其特征在于,所述电子设备还包括:
    第二创建单元,在所述在检测管理器中创建路径检测函数之前,创建接口库,所述接口库中包括一个或多个接口,定义每个接口的检测方法函数,每个检测方法函数对应一个预设规则,不同的检测方法函数对应不同的预设规则;
    第三创建单元,用于创建与所述一个或多个接口一一对应的一个或多个实现类,每个实现类继承所述一个或多个接口中的一个接口,不同的实现类继承的接口不同,所述每个实现类中复写有继承的接口中的检测方法函数。
  9. 一种电子设备,其特征在于,所述电子设备包括处理器,所述处理器用于执行存储器中存储的计算机程序时实现如权利要求1-6中任一项所述的路径检测方法的步骤。
  10. 一种可读存储介质,其上存储有计算机程序,其特征在于,所述计算机程序被处理器执行时实现如权利要求1-6中任一项所述的路径检测方法的步骤。
PCT/CN2018/082167 2018-01-04 2018-04-08 一种路径检测方法、电子设备及可读存储介质 WO2019134286A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201810008841.5 2018-01-04
CN201810008841.5A CN108089989B (zh) 2018-01-04 2018-01-04 一种路径检测方法、电子设备及可读存储介质

Publications (1)

Publication Number Publication Date
WO2019134286A1 true WO2019134286A1 (zh) 2019-07-11

Family

ID=62181601

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/082167 WO2019134286A1 (zh) 2018-01-04 2018-04-08 一种路径检测方法、电子设备及可读存储介质

Country Status (2)

Country Link
CN (1) CN108089989B (zh)
WO (1) WO2019134286A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109413452B (zh) * 2018-09-30 2021-02-02 武汉斗鱼网络科技有限公司 基于不同方式的弹幕校验方法、装置、终端及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090132861A1 (en) * 2007-11-16 2009-05-21 Microsoft Corporation Privacy Enhanced Error Reports
CN105765528A (zh) * 2013-11-13 2016-07-13 微软技术许可有限责任公司 具有可配置原点定义的应用执行路径跟踪
CN106354632A (zh) * 2016-08-24 2017-01-25 北京奇虎测腾科技有限公司 一种基于静态分析技术的源代码检测系统及方法
CN107247668A (zh) * 2017-06-07 2017-10-13 成都四象联创科技有限公司 代码自动检测和校正方法

Family Cites Families (3)

* Cited by examiner, † Cited by third party
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
CN102789417B (zh) * 2012-04-27 2015-05-13 北京大学 一种移动智能终端上的定向符号执行程序检测系统及方法
CN103440196B (zh) * 2013-07-11 2016-03-09 大连交通大学 一种操作系统资源问题检测方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090132861A1 (en) * 2007-11-16 2009-05-21 Microsoft Corporation Privacy Enhanced Error Reports
CN105765528A (zh) * 2013-11-13 2016-07-13 微软技术许可有限责任公司 具有可配置原点定义的应用执行路径跟踪
CN106354632A (zh) * 2016-08-24 2017-01-25 北京奇虎测腾科技有限公司 一种基于静态分析技术的源代码检测系统及方法
CN107247668A (zh) * 2017-06-07 2017-10-13 成都四象联创科技有限公司 代码自动检测和校正方法

Also Published As

Publication number Publication date
CN108089989A (zh) 2018-05-29
CN108089989B (zh) 2020-10-16

Similar Documents

Publication Publication Date Title
US10862982B2 (en) Cloud-scale heterogeneous datacenter management infrastructure
CA2439729C (en) System architecture and related methods for dynamically adding software components to extend functionality of system processes
CN109918055B (zh) 一种应用程序的生成方法及设备
WO2017185606A1 (zh) 基于overlay机制的APK开发方法及系统
WO2019134287A1 (zh) 一种版本信息管理方法、电子设备及可读存储介质
EP3516847B1 (en) Deployment of applications conforming to application data sharing and decision service platform schema
US9804952B1 (en) Application debugging in a restricted container environment
US20240054366A1 (en) AI Application Deployment Method and Related Platform, Cluster, Medium, and Program Product
US20120240116A1 (en) Performance In A Virtualization Architecture With A Processor Abstraction Layer
WO2022017242A1 (zh) 在第一系统运行第二系统应用的方法、装置、设备及介质
US7805711B2 (en) Redirection interface system and method for CIM object manager provider
CN109739487B (zh) 一种业务逻辑处理方法、设备及计算机可读存储介质
WO2022105492A1 (zh) 修复弱内存序问题的方法及装置
WO2019134286A1 (zh) 一种路径检测方法、电子设备及可读存储介质
WO2024055757A1 (zh) 驱动程序的硬件资源自动配置方法、装置、系统及介质
WO2019223095A1 (zh) 监控进程运行的方法、终端设备及计算机可读存储介质
WO2021097683A1 (zh) 安卓系统启动的方法、装置、设备及存储介质
CN110908767A (zh) 一种参数自动部署方法和装置
CN112068895B (zh) 代码配置方法、装置、视频播放设备及存储介质
WO2022093666A1 (en) Architectural design for universal software automation pipelines
CN112000950A (zh) 一种防拦截的程序运行与交互控制方法及装置
CN113127103B (zh) 一种信令系统及电子设备
WO2022222809A1 (zh) 功能组件处理方法、介质、设备和操作系统
CN110401554B (zh) Vnf纳管的方法、装置、系统、电子设备及存储介质
TW202110175A (zh) 影像測試方法、裝置、電腦裝置及可讀存儲介質

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18898167

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18898167

Country of ref document: EP

Kind code of ref document: A1