Compatibility detection method, electronic device, and storage medium

Abstract

This application provides a compatibility detection method, an electronic device, and a storage medium. The method includes: acquiring query information with a preset statement structure, the statement structure being determined according to a capability layering architecture, the capability layering architecture including a type configuration module associated with a capability type; parsing the query information to obtain a target capability type and target attribute information; and in the type configuration module associated with the target capability type, matching the target attribute information to determine a detection result. Based on the separate configuration of modules for each type of application, the management, addition, deletion, and adjustment of configuration modules are flexible, highly scalable, and facilitate version management. When there is an actual query task, the target capability type is automatically identified and layered queries are performed based on the query information, reducing unnecessary cross-layer queries and optimizing the query path.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to compatibility testing methods, electronic devices, and storage media. Background Technology

[0002] With the rapid development of the mobile internet, lightweight applications, as a form of lightweight application, are widely used due to their characteristics of being installation-free and ready to use immediately. The operation of lightweight applications depends on the host environment (such as operating system, host application version, hardware device, etc.), and different host environments have significantly different levels of support for the application programming interfaces, components, objects, methods, and parameters provided by lightweight applications. If developers directly call functions not supported by the current environment in a lightweight application, it may lead to program errors, functional failures, or even crashes, severely impacting the user experience. Therefore, it is necessary to perform compatibility checks on corresponding interface calls to help developers quickly determine whether the target function is available in the current environment at runtime, thereby enabling targeted degradation processing or functional adaptation to ensure the stability and compatibility of lightweight applications.

[0003] In related technologies, compatibility verification of lightweight programs is based on centralized configuration. However, managing the configuration version of a configuration module used for centralized configuration is complex, and querying compatibility verification within the configuration module is inefficient. Summary of the Invention

[0004] This application provides a compatibility testing method, an electronic device, and a storage medium, which solve the problems of complex configuration version management for a configuration module used for centralized configuration and low query efficiency for compatibility verification in the configuration module in related technologies. The method allows for flexible addition, deletion, and adjustment of the configuration module, strong scalability, and convenient version management. When there is an actual query task, the method automatically identifies the target capability type based on the query information and performs hierarchical queries, reducing unnecessary cross-level queries and optimizing the query path.

[0005] In a first aspect, embodiments of this application provide a compatibility testing method, the method comprising:

[0006] Obtain query information with a preset statement structure, wherein the statement structure is determined according to a capability layering architecture, and the capability layering architecture includes a type configuration module associated with the capability type; The query information is parsed to obtain the target capability type and target attribute information; In the type configuration module associated with the target capability type, the detection result is determined by matching the target attribute information.

[0007] Secondly, embodiments of this application also provide an electronic device, which includes: One or more processors; Storage device, configured to store one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors implement the compatibility detection method described in the embodiments of this application.

[0008] Thirdly, embodiments of this application also provide a non-volatile storage medium for storing computer-executable instructions, which, when executed by a computer processor, are configured to perform the compatibility detection method described in embodiments of this application.

[0009] In this embodiment, query information with a preset statement structure is obtained. The statement structure is determined according to a capability layering architecture, which includes a type configuration module associated with the capability type. The query information is parsed to obtain the target capability type and target attribute information. In the type configuration module associated with the target capability type, the detection result is determined by matching the target attribute information. Based on the separate configuration of modules for each type of application, the management of configuration modules is flexible, allowing for addition, deletion, and adjustment. This provides strong scalability and facilitates version management. When there is an actual query task, the target capability type is automatically identified and layered queries are performed based on the query information, reducing unnecessary cross-layer queries and optimizing the query path. Attached Figure Description

[0010] Figure 1 This is a flowchart of a compatibility detection method provided in an embodiment of this application.

[0011] Figure 2 A flowchart of another compatibility detection method provided in this application embodiment.

[0012] Figure 3 This is a framework diagram of a type configuration module provided in an embodiment of this application.

[0013] Figure 4 This is a schematic diagram illustrating a compatibility testing process provided in an embodiment of this application.

[0014] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0015] The embodiments of this application will be further described in detail below with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are merely illustrative of the embodiments of this application and are not intended to limit the scope of the embodiments. Furthermore, it should be noted that, for ease of description, only the parts relevant to the embodiments of this application are shown in the accompanying drawings, not the entire structure.

[0016] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0017] With the rapid development of the mobile internet, lightweight applications, as a form of lightweight application, are widely used due to their characteristics of being installation-free and ready to use immediately. During the development of lightweight applications, it is necessary to perform compatibility checks on corresponding interface calls. This helps developers quickly determine whether the target functionality is available in the current environment at runtime, thereby enabling targeted degradation handling or functional adaptation to ensure the stability and compatibility of the lightweight application.

[0018] In related technologies, compatibility verification of lightweight programs is based on centralized configuration. However, managing the configuration version of a configuration module used for centralized configuration is complex, and querying compatibility verification within the configuration module is inefficient.

[0019] The inventors, through in-depth analysis of the configuration module in related technologies, discovered that the information required for compatibility verification is highly coupled within the configuration module. When there are changes in functional support on the lightweight application platform, the configuration rules in the configuration module need to be adjusted accordingly so that developers using the lightweight application platform can perform verification and development based on the latest functional support. However, the centralized setting of all configuration rules in the configuration module leads to over-coupling and an ever-growing volume of recorded content. Over time, adjusting the content in the configuration module becomes increasingly difficult, and managing the configuration versions of the module becomes increasingly complex. Each compatibility verification requires querying all configuration rules based on the input key information, resulting in low query efficiency for compatibility verification.

[0020] Based on the above analysis of the problem's manifestations and corresponding underlying causes, the inventors propose a compatibility detection method in this application. This method obtains query information with a preset statement structure, determined according to a capability layering architecture, which includes a type configuration module associated with each capability type. The query information is parsed to obtain the target capability type and target attribute information. The type configuration module associated with the target capability type matches the target attribute information to determine the detection result. With modules configured separately for each type of application, the management of configuration modules allows for flexible addition, deletion, and adjustment, providing strong scalability and facilitating version management. When there is an actual query task, the method automatically identifies the target capability type based on the query information and performs layered queries, reducing unnecessary cross-layer queries and optimizing the query path.

[0021] The compatibility testing method provided in this application can be applied to a multi-platform compatibility judgment process. The execution subject of each step can be a computer device. The computer device refers to any electronic device with data computing, processing and storage capabilities, such as a PC (Personal Computer), tablet computer and other terminal devices. This application does not limit this.

[0022] It should be noted that lightweight applications, as a form of lightweight application, are highly dependent on their host environment for operation. This host environment can be specifically defined as the set of basic conditions that provide support for the operation of lightweight applications. These include, but are not limited to, the operating system (such as Android, iOS, or other different types and versions of operating systems) of the terminal device running the lightweight application, the host application running the lightweight application, and the hardware configuration of the terminal device itself (such as processor model, memory capacity, graphics card performance, sensor type, and other hardware-related parameters). However, due to inherent differences in system architecture, development standards, hardware performance, and feature iteration progress among different host environments, their support for the core technical elements required for the operation of lightweight applications exhibits significant inconsistencies. These core technical elements include APIs (Application Programming Interfaces, hereinafter referred to as interfaces), reusable components during lightweight application development (such as view components, interactive components, etc.), objects within the lightweight application used to implement specific functions and their associated methods (such as method call logic and execution flow), and parameters required during interface calls (such as parameter data type, value range, and required fields).

[0023] If developers fail to anticipate the functional support of the target host environment during the development of lightweight applications, and directly call functional modules corresponding to the aforementioned technical elements that are not supported by the current runtime environment in the code logic of the lightweight application, then during the actual operation of the lightweight application, it is very easy to trigger program runtime exceptions. Specifically, this may manifest as the program throwing runtime error messages, the target functional module failing to execute normally and causing functional failure, or even causing the entire lightweight application process to terminate, i.e., the program crashes. All of the above situations will disrupt the normal usage flow of the lightweight application, have a serious negative impact on the user experience, and thus reduce user stickiness to the lightweight application. Based on this, in order to solve the aforementioned compatibility issues of lightweight programs caused by differences in host environments, embodiments of this application provide a compatibility detection method, electronic device, and storage medium for performing compatibility verification and judgment on the application programming interfaces to be called during the operation of lightweight programs and related technical elements such as components, objects, methods, and parameters. This allows for subsequent targeted execution of downgrade processing strategies (e.g., calling alternative modules with equivalent basic functions) or functional adaptation optimization (e.g., adjusting the functional implementation logic according to the characteristics of the host environment) based on the judgment results, ultimately ensuring the stability and compatibility of lightweight programs in different host environments.

[0024] Figure 1 A flowchart of a compatibility detection method provided in this application embodiment is shown below. Figure 1 As shown, the compatibility testing method includes the following steps: Step S110: Obtain query information with a preset statement structure. The statement structure is determined according to the capability layering architecture, which includes a type configuration module associated with the capability type.

[0025] The capability layering architecture in this embodiment refers to classifying the various capabilities of the lightweight application platform by type to serve compatibility testing. Each capability type has an associated type configuration module, which can record various information and parameters of all associated capability types and provide corresponding queries. Capability types include, for example, interfaces, components, methods, and parameters required during interface calls, as described above.

[0026] In this embodiment of the application, the query information refers to the information directly used for querying based on the key information input by the developer for compatibility testing. When the developer inputs the key information, it can be input according to the rules of any lightweight program platform. When performing compatibility testing based on this embodiment of the application, the key information can be converted according to a preset statement structure to obtain the query information. The preset statement structure is determined according to the capability layering architecture and is adapted to the structure of the configuration data recorded in the type configuration module.

[0027] In one alternative implementation, the structure for recording configuration data can be in JSON object format, as is the case with related technologies. For example, the configuration file corresponding to the "request" interface is recorded in JSON object format as follows: { "request": { "platforms": ["ios", "android", "windows", "mac", "devtools"], "methods": { "object": { "params": ["url", "data", "header", "timeout"], "method": { "values": ["GET", "POST", "OPTIONS", "HEAD", "PUT", "DELETE"] } }, "success": { "returns": ["data", "statusCode", "header", "cookies"] } } } Configuration data recorded in JSON object format has a good foundation of popularity, allowing developers to quickly understand the specific content of the configuration data when needed.

[0028] In another optional implementation, the configuration data can be recorded in string format. This means the configuration file content is stored in a compact string format, reducing file size and parsing complexity. The string-formatted configuration data can be pre-written according to a defined, unified string encoding format, uniquely bound to the target interface name, based on the actual capabilities supported by the target interface. This concise, standardized string format integrates various support capability parameters of the target interface, facilitating storage and management while ensuring efficiency and accuracy in the parsing process. To more clearly illustrate the implementation of this step, specific application examples are provided below. Taking the configuration file corresponding to the "request" interface as an example, its configuration information, represented in string format, is as follows: 'request':' |o:url,data,header,method.GET.POST.OPTIONS.HEAD.PUT.DELETE,timeout;s:data,statusCode,header,cookies'.

[0029] The configuration information represented in string format contains approximately 100 characters, and its size is reduced by 66% compared to the aforementioned JSON object format configuration file, thus achieving the goal of reducing memory usage and enabling fast loading.

[0030] Specifically, the following is an example of encoding rules for representing configuration information using a compact string format: "Platform Identifier|Method Type:Parameter List". This configuration format uses separators to clearly divide configuration information into different dimensions, ensuring readability and efficient parsing. The platform identifier specifies the host environment platform to which the current interface configuration applies; the method type identifies the supported functionalities of the interface; and the parameter configuration defines the parameters required during the interface call. The platform identifier and method type are separated by the specific symbol "|", and the method type and parameter list are separated by the specific symbol ":". The specific definitions and value rules for each component are as follows: For platform identifiers, wildcards can be used. The "" indicates that the interface configuration is applicable to all types of host environment platforms, with no platform limitations. The identifier string "mobile" indicates that the interface configuration is only applicable to mobile host environment platforms, including but not limited to host environments corresponding to terminal devices such as mobile phones and tablets running mobile operating systems. The identifier string "pc" indicates that the interface configuration is only applicable to desktop host environment platforms, i.e., host environments corresponding to computer terminals running desktop operating systems. Alternatively, a preset numerical code can be used to represent a specific platform combination. Different numbers correspond to different platform combination schemes. A preset code mapping table is used to look up the corresponding specific platform set represented by the number. Specific platforms can include, but are not limited to, iOS, Android, Windows, Mac, DevTools, etc.

[0031] For method types, different functional implementations can be identified using single characters. Specifically, the character "r" indicates that the interface supports the return method, meaning that the execution result is returned to the caller after the interface is called. The character "s" indicates that the interface supports the success callback mechanism, meaning that the result is returned by triggering a preset success callback function after the interface is executed successfully. The character "o" indicates that the interface supports the object parameter type, meaning that an object type parameter needs to be passed during the call. The character "c" indicates that the interface supports the callback method, meaning that the relevant logic and results during the interface execution process are handled through a callback function.

[0032] For the parameter list, as an optional configuration item, it is used to define the parameter information required during the interface call. Depending on the number of methods in the interface, there are several configuration methods: For a single method scenario, it can be "method name: parameter1, parameter2, ..., parametern"; for multiple methods, it can be "method1 name: parameter1, parameter2, ..., parametern; method2 name: parameter1, parameter2, ..., parameterm"; for nested attribute representation scenarios, when the parameter is an object and contains nested attributes, the symbol "." is used to represent the nesting relationship of the attributes, such as "object name.nested attribute1.nested attribute2", to accurately describe the hierarchical structure of the parameters. In an optional implementation, a maximum depth can be set as the termination condition for recursive parsing, for example, setting the maximum nesting depth of parameters to 5 levels or other levels. When the nesting depth exceeds the maximum, the query is considered invalid and returns false. For example, if `request.object.header.content-type.charset.utf8` has 5 levels of nesting, it is a valid query if the maximum depth is above 5, allowing the entire compatibility check to be completed. If the maximum depth is less than 5, it is an invalid query and returns false, avoiding performance degradation due to excessive recursive parsing. Furthermore, during layer-by-layer matching, if a parameter at a certain level is missing, the recursion is immediately terminated and a failure is returned. For example, when querying `request.object.header.token`, if there is no `token` configuration under the `header` parameter, there is no need to continue matching subsequent levels; it is directly determined as unsupported. This rule further improves the matching efficiency of multi-level nested parameters.

[0033] The following are some examples of configuration information represented in the aforementioned string format: |o:timeout,url” |o:count;s:tempFilePaths" and " |o:data;s:data;r:data". Where, " |o:timeout,url” "" indicates universal platform compatibility, "o" indicates support for object parameter types, and "timeout, url" indicates that in all host environments, the target interface supports passing object type parameters containing both "timeout" and "url" attributes. |o:count;s:tempFilePaths” The "" indicates that it is applicable to all platforms. The method supports two types: "o" and "s". "o:count" means that an object parameter containing the "count" attribute is passed in, and "s:tempFilePaths" means that a success callback mechanism is supported and the callback function will return the "tempFilePaths" parameter, realizing centralized configuration for multiple method support scenarios. |o:data;s:data;r:data” in “ The "" indicates that it is applicable to all platforms. The method supports three types: "o", "s", and "r", which correspond to "passing in an object parameter with a data attribute", "returning a data parameter via a success callback", and "returning a data parameter via the return method", respectively, enabling a combination of various functional configurations.

[0034] When developers perform compatibility testing, the key information they input may have different structures. In this embodiment, query information with a preset statement structure can be obtained through a preset unified query interface. That is, the preset unified query interface is compatible with various structures and can convert query information with different structures to obtain query information with the preset statement structure, facilitating subsequent queries in the corresponding structure's type configuration module. The initial query information directly input by the developer is used as the obtained initial query information. This initial query information is then aligned and converted according to the preset statement structure through the preset unified query interface to obtain the final query information.

[0035] For example, this application provides a `canIUse` function as an entity implementing a unified query interface. It is used to accurately determine whether key technical components to be called during the lightweight program's operation have usable attributes in the current lightweight program's runtime environment. These key technical components specifically cover interfaces involved in the development and operation of the lightweight program, reusable functional components, objects used to encapsulate specific functional logic, methods bound to these objects for implementing specific operations, and parameters passed during method and interface calls. The `canIUse` function introduces a structured query string as a query identifier for technical elements. This structured query string uses standardized syntax rules to describe key information such as the type, name, and relationships of the target technical components, ensuring the accuracy and uniqueness of the query process. Simultaneously, a clear configuration file is used to manage the technical element support list for different host environments. The configuration file contains core data such as the identification information of each host environment, the corresponding technical element support status, and the supported version range. For example, calling `canIUse('request.object.abc')` specifically determines whether the "request" interface supports calling the "object" method with the "abc" parameter.

[0036] In one optional implementation, platform adaptation can be performed directly at the unified query interface. That is, if the platform identifier parsed from the initial query information does not match the supported platforms, subsequent processing can be stopped, and a verification failure result will be returned. In other words, query information with a preset statement structure is only generated when the platform identifier matches the supported platforms.

[0037] Step S120: Parse the query information to obtain the target capability type and target attribute information.

[0038] As described above, the content recorded in the type configuration module follows a unified recording rule. Given a structured record configuration data, the query information is split according to the structural identifier of the statement structure to obtain the target capability type and target attribute information with hierarchical relationships. The hierarchical relationship is associated with the layering method of the target capability type in the capability layering architecture. The information identified from the query information based on the structural identifier of the statement structure at the corresponding position of the type is the target capability type, and the information identified from the corresponding positions of various attribute information is the target attribute information. For example, if the core structural identifier of the preset statement structure is ".", taking the query information button.open-type.contact as an example: it is split into three parts: button, open-type, and contact; the top-level button is extracted to determine the target capability type as "component"; the remaining open-type (first-level attribute) and contact (second-level attribute) are integrated into multi-level target attribute information; if the query information is a single-level attribute (such as request), only the target capability type is extracted as "interface," and the target attribute information is empty.

[0039] Step S130: In the type configuration module associated with the target capability type, the detection result is determined by matching the target attribute information.

[0040] With the target capability types already determined and each type corresponding to a separate type configuration module, the matching process is performed directly within the type configuration module associated with the target capability type. This avoids matching in impossible ranges and focuses on a relatively focused range of likely successful matches. The detection result is determined based on the target attribute information, thereby improving matching efficiency. It should be understood that if all target attribute information matches, the detection result is considered passed.

[0041] Taking compatibility validation with the target interface "request" as an example, for instance, the configuration content corresponding to "request" is " The code snippet `|o:url,method.GET.POST;s:data` is used to check if the `object` parameter of the request contains the `url` attribute. Since the configuration explicitly defines the `object` parameter as containing `url`, the check returns `true`, indicating that the current environment supports this parameter. Similarly, `canIUse('request.success.data')` checks if the success callback of the request returns the `data` parameter. Based on the definition of `s:data` in the configuration, the check returns `true`, indicating that the current environment supports this callback parameter. Finally, `canIUse('request.object.abc')` checks if the `object` parameter of the request contains the `abc` attribute. Since this parameter is not defined in the configuration, the check returns `false`, indicating that the current environment does not support this parameter.

[0042] In an optional implementation, the compact string format may also include a checksum to ensure the integrity of the configuration data during storage and transmission. The checksum is located at the end of the string and is generated through a hash operation on the preceding content. For example, " In the string "|o:url,method.GET;r:data#f", "#f" is the checksum. During parsing, the checksum is first verified. If it does not match, the configuration file is considered corrupted, and a backup configuration is automatically loaded or an error is reported. This avoids misjudgments in compatibility testing due to configuration tampering, packet loss, or other reasons, further improving the reliability of configuration data and compatibility testing.

[0043] Overall, by acquiring query information with a preset statement structure, determined according to a capability layering architecture, which includes a type configuration module associated with the capability type, the system parses the query information to obtain the target capability type and target attribute information. The type configuration module associated with the target capability type then matches and determines the detection result based on the target attribute information. Based on the separate configuration of modules for each type of application, the system offers flexible management, addition, deletion, and adjustment of configuration modules, strong scalability, and ease of version management. When there is an actual query task, the system automatically identifies the target capability type based on the query information and performs layered queries, reducing unnecessary cross-layer queries and optimizing the query path.

[0044] Please refer to Figure 2 This is a flowchart of another compatibility detection method provided in the embodiments of this application, such as... Figure 2 As shown, the compatibility testing method includes: Step S210: Obtain initial query information, and align and transform the initial query information according to the preset statement structure through the preset unified query interface to obtain the query information.

[0045] On the unified query interface, building upon the initial query information retrieval and transformation described above, preliminary platform-level compatibility testing can also be performed. This preliminary platform-level compatibility testing can be completed based on the platform identifier. The platform identifier corresponding to the current runtime environment serves as the current platform identifier, used for accurate differentiation of different runtime host environments, avoiding compatibility verification errors caused by platform confusion. When testing platform compatibility, the corresponding compact string configuration can be retrieved from the type configuration module associated with the target capability type, and the platform identifier (e.g., ...) can be parsed. (For all platforms, mobile corresponds to iOS + Android); the system obtains the current lightweight application's running platform (such as Windows) through the underlying system interface, and determines whether the current platform is within the configured platform range. If not, the detection result is directly determined as "failed"; if it is, the subsequent attribute matching process begins.

[0046] Step S220: Segment the query information according to the structure identifier of the statement structure to obtain the target capability type and the target attribute information with hierarchical relationship.

[0047] Taking the previously defined statement structure "Platform Identifier | Method Type: Parameter List" as an example, all interfaces' preset configuration strings follow the same format standard to avoid parsing failures or errors due to inconsistent configuration formats. The preset configuration string corresponding to the "request" interface can be " The string "|o:url,method.GET.POST;s:data" is stored in the corresponding configuration file as baseline data for the interface's supported capabilities. Following the encoding rules corresponding to this preset configuration string, the interface configuration information can be parsed. This configuration information can be a structured data set describing the target interface's supported capabilities. Specific data dimensions may include the platform range supported by the interface, the set of supported method types, and the parameter list for each method, serving as reference information for subsequent comparison logic.

[0048] To ensure the speed of compatibility testing, the query information is also split according to the statement structure to obtain the target capability type and the target attribute information with hierarchical relationship. The target capability type is used to determine the associated type configuration module, and the target attribute information is used to complete the specific parameter matching.

[0049] Step S230: Confirm the type configuration module from at least one pre-stored type configuration module according to the target capability type.

[0050] Each module corresponding to a function records its configuration parameters through a corresponding type configuration module. As described above, by querying the corresponding record location based on the target capability type, it can be determined whether there is an associated type configuration module. If not, it means that the compatibility test result is unsuccessful; otherwise, the subsequent specific attribute information test can continue.

[0051] Step S240: Based on the target attribute information, perform information matching in the type configuration module to determine the detection result.

[0052] Based on the hierarchical relationship of the target attribute information, matching can be performed layer by layer sequentially according to the specifically determined number of layers. If any layer does not match, the detection result is determined to be a mismatch. That is, when the target attribute information includes multiple layers, the type configuration module associated with the target capability type determines the detection result by matching layer by layer according to the target attribute information.

[0053] In an optional embodiment, when the target attribute information includes multiple layers, the type configuration module associated with the target capability type performs matching layer by layer according to the target attribute information; if each layer of the target attribute information is successfully matched, the detection result is determined to be passed; if any layer of the target attribute information fails to match, the detection result is determined to be failed.

[0054] The following is a further exemplary description of the embodiments of this application, starting from the preparation of preliminary data, in conjunction with the compatibility testing process in a specific application scenario. This description can be combined with... Figure 3 The diagram shows a framework of one type of configuration module and Figure 4 The diagram shown is a schematic representation of a compatibility testing process to aid understanding. Figure 3 The static structure of the type configuration modules is presented, clearly defining the responsibilities and positions of each type configuration module; Figure 4 The dynamic compatibility detection process based on the type configuration module clearly defines the processing steps when a single query request is received. The combination of these two aspects fully demonstrates the static design and dynamic operation logic of the layered architecture.

[0055] exist Figure 3 In this embodiment, a unified query interface is used to coordinate and implement query-based compatibility testing. The compatibility configuration is broken down into three levels—interface, component, and object—and completed during the pre-processing data phase, forming the data foundation for compatibility testing in this application. For example... Figure 3As shown, interfaces, components, and objects are stored in three independent type configuration modules: InterfaceConfig, ComponentConfig, and ObjectConfig. The configuration items within each type configuration module are encoded and stored using the compact string format described earlier, and each type configuration module contains multiple configuration entries. For example, the request configuration for the 196 interfaces in the interface layer is... |o:url,data,header,method.GET.POST,timeout;s:data,statusCode; The button configuration in the 23 components of the component is as follows |o:open-type.contact; The FileSystemManager configuration in the 134 object methods of the object is as follows |r:fileContent;c:onFileRead.

[0056] It should be noted that the preliminary data preparation phase is not necessarily completed sequentially, but can be continuously modified, added, or updated. With each level set independently, when the compatibility configuration of a certain level is updated, only the configuration module and cache of that level need to be updated, without affecting the normal operation of other levels, thus achieving modular iteration and maintenance of configurations.

[0057] In addition, the compatibility detection method in this application embodiment may further include: receiving a newly added type configuration module and saving the newly added type configuration module and the pre-stored type configuration module independently.

[0058] With the development of the lightweight application ecosystem, developers may need to integrate third-party plugins (such as map plugins and payment plugins). However, different platforms (iOS / Android / Windows) have different support for plugins (e.g., a map plugin only supports mobile devices and not desktop devices). In this case, a new "plugin configuration layer (pluginConfig)" needs to be added in addition to the existing "interface-component-object" three layers to achieve independent management and detection of plugin compatibility. After this addition, it is necessary to support the "plugin name-property / method-parameter" hierarchical detection of plugins (e.g., checking if mapPlugin.getLocation.object.latitude is supported); and it is also necessary to ensure that the new configuration layer is maintained independently and does not affect the original interfaces Config / componentConfig / objectConfig. When performing relevant compatibility queries, to maintain a consistent user experience for developers, queries should still be initiated through the unified query interface, without the need to add new interfaces.

[0059] In the existing configuration modules, a new independent `pluginConfig` configuration module has been added. This module uses the compact string format described earlier to store plugin compatibility configurations, and the configuration rules remain consistent with the original hierarchy (platform identifier + method type + parameter list). Only the coding logic for "plugin properties / methods" needs to be supplemented for plugin characteristics. The configuration method within the `pluginConfig` module is consistent with the original hierarchical configuration modules; for example, "platform identifier" (mobile / / pc) + "|" + "method type: parameter list" (o / s / r / c) to ensure that the parsing algorithm is reusable.

[0060] Considering that the existing parsing module may only be able to recognize three hierarchical identifiers: "interface, component, and object," after adding the plugin type, it is necessary to supplement the recognition rules for "plugin hierarchical identifiers" to determine whether it is a plugin query. For example, if the top-level name determined in the query information contains the suffix "Plugin" (such as mapPlugin, payPlugin), then the hierarchical identifier is extracted as "plugin," and the pluginConfig configuration module is used as the type configuration module accordingly. During this addition process, there is no need to modify the original identifier (interface / component / object) recognition logic; only the branch judgment is added to ensure compatibility.

[0061] To ensure the smart router can complete the corresponding data transmission and reception after adding a new configuration module, the "identifier-module" mapping table of the smart router also needs to be updated. In other words, the core of the smart router is the directional mapping of "layer identifier → configuration module". After adding a configuration module corresponding to the plugin layer, only one line of mapping relationship needs to be added to the existing mapping table. There is no need to modify the original routing logic. That is, the existing mapping relationships of layer identifier = interface → route to interface Config, layer identifier = component → route to componentConfig, and layer identifier = object → route to objectConfig remain unchanged. The newly added mapping relationship is layer identifier = plugin → route to pluginConfig.

[0062] Because `pluginConfig` uses a "compact string format" consistent with the original hierarchy, the entire processing can be completely reused without modifying the code. For example, the result feedback module reuses the original logic: returning `true` to the `xz.canIUse()` interface and storing `mapPlugin.getLocation.object.latitude-true` in the global cache. When there is a compatibility query for the plugin, the compatibility detection method in this embodiment can quickly obtain the detection results. After adding a configuration module, a test query can be automatically initiated, i.e., selecting a new function for compatibility testing to verify the effectiveness of routing and matching logic, ensuring seamless integration of the new configuration module.

[0063] After adding the plugin layer, developers do not need to learn new interfaces; they can still initiate queries through the unified query interface, and the calling experience is completely consistent with the original type. The entire update process does not intrude on existing configuration modules, only adding the `pluginConfig` module and a small number of mapping rules and parsing logic. The configuration, parsing, and routing code of the original interface / component / object three layers remain unchanged. Due to the loosely coupled configuration module, the risk of affecting the whole system by changing one part is avoided. Plugin configurations are centrally stored in `pluginConfig`. Subsequent additions to type configuration modules or modifications to plugins within type configuration modules (such as adding `videoPlugin`) only require updating this module, without needing to modify other configuration files, thus maintaining the independence of each configuration module. Existing compact string parsing algorithms and original matching logic can be directly reused, eliminating the need for redevelopment and reducing expansion costs. For developers, when compatibility testing is required, there is no need to adapt to new logic; they can continue their original development habits, reducing the learning curve.

[0064] Building upon the aforementioned preliminary data preparation phase, during system startup, the compact string configurations at each level can be pre-parsed, and the parsed structured data (platform adaptation rules, method-parameter mapping relationships) can be stored in the corresponding level's cache. This avoids repeated parsing at runtime and improves subsequent query performance. Of course, parsing can also be performed only when there is a query requirement.

[0065] When developers have query needs during development, they can initiate a compatibility query through the unified query interface. The unified query interface can convert the keyword information passed by the developer into the structured information to be detected (such as request.success.data, button.open-type.contact, FileSystemManager.readFile). The unified query interface serves as the sole entry point to handle all types of compatibility detection requests.

[0066] The system performs word segmentation and hierarchical extraction on the incoming structured information, and identifies the basic level and subdivision of the query. The first step is to identify the top-level type: determine whether the query target is an interface (such as request), a component (such as button), or an object (such as FileSystemManager). The second step is to break down the subdivision: further extract the sub-level information under the top-level type, such as the object parameter type configuration module / success callback of the interface, the open-type attribute of the component, the readFile method of the object, etc.

[0067] After determining the target capability type, the process involves intelligent routing to enter the query scope, i.e. Figure 3 As shown, the system uses an intelligent router to route query requests to the corresponding configuration modules (interface requests are routed to interfaceConfig, component requests to componentConfig, and object requests to objectConfig) based on the parsed top-level type, enabling the type configuration module to "query on demand" and avoiding invalid cross-level traversal.

[0068] The configuration module at the target level retrieves the corresponding compact string configuration from the cache and performs matching and validation layer by layer based on the target attribute information. For example, for interface queries, it can match and validate whether the target method type (such as success) contains the target parameter (such as data); for component queries, it can match and validate whether the target attribute (such as open-type) contains the target option value (such as contact); for object queries, it can match and validate whether the target member method (such as readFile) supports the return parameters of the specified callback type configuration module / type configuration module.

[0069] After the matching and verification are completed, the system returns a boolean result to the unified query interface (returns true if supported, and false if not supported). At the same time, the query information and results of this query can be stored in the global query cache for subsequent repeated queries to be called directly.

[0070] The following Figure 4 The process of implementing compatibility detection is described exemplarily based on this.

[0071] The macroscopic compatibility testing process is described below; Figure 4 This can be viewed as a visual breakdown of the compatibility testing process for a single query request, with the core demonstration showing the progressive flow of query information parsing, layered matching, and dimensional validation. For example... Figure 4As shown, the query access and query information parsing process starts with the user query. Developers pass in the query statement through a unified query interface (such as button.open-type.contact). The system first parses the query statement and extracts key hierarchical information to lay the foundation for subsequent hierarchical matching.

[0072] After parsing the top-level type, the system first determines the top-level type of the query, distinguishing whether the target is an interface, component, or object. If it is an interface, it matches "request" and proceeds to the interface configuration module; if it is a component, it matches "button" and proceeds to the component configuration module; if it is an object, it matches "FileSystemManager" and proceeds to the object configuration module. This step is completed by the intelligent router, achieving precise routing of query requests.

[0073] The method type configuration module / type configuration module and the attribute type configuration module / type configuration module match members within the configuration layer corresponding to the top-level type, further matching specific dimensions. If it's an interface layer, it matches the specific method type, such as success callback, object parameters, return value, etc.; if it's a component layer, it matches the specific component attribute, such as button's open-type, text's selectable, etc.; if it's an object layer, it matches the specific member method, such as FileSystemManager's readFile, CameraContext's onCameraFrame, etc.

[0074] After the parameter type configuration module / type configuration module completes the second-level matching of option values, it performs more precise underlying validation for subdivided dimensions. For example, the third level matches specific parameter or attribute values, such as the data parameter in the interface layer, the mini size in the component layer, and the filePath parameter in the object layer; the fourth level (nested dimension) matches nested option values ​​of parameters, such as the GET / POST options of request.object.method and the contact option of button.open-type.

[0075] The matching result is determined only if every level of the top-level type - subdivision dimension - parameter type configuration module / type configuration module option value matches successfully, and the current running platform meets the configured platform identifier requirements. Only then will the final detection result be returned as pass (i.e., compatible). If any level fails to match or the platform is incompatible, the detection result will be returned as fail (i.e., incompatible).

[0076] A more detailed description of the compatibility testing process is as follows: When the system starts, the configurations of the three modules, namely Interface Config (interface layer), componentConfig (component layer), and objectConfig (object layer), are pre-parsed using the compact string format described above, and the parsed structured data is stored in the independent cache of the corresponding layer.

[0077] The parsed data structure is taken as an example of the request configuration at the interface layer: javascript run { platformSpec: ['ios', 'android', 'windows', 'mac', 'devtools'], / / Platform compatibility range methodConfig: { o: ['url', 'data', 'header', 'method.GET', 'method.POST', 'timeout'], / / object parameter s: ['data', 'statusCode', 'header', 'cookies'] / / Success callback parameters } } When developers have compatibility testing needs, they can obtain query information through a unified query interface (such as button.open-type.contact, FileSystemManager.readFile.object.filePath). The system's parsing tool will then perform standardized decomposition to extract the three elements of "hierarchical identifier - subdivision dimension - verification target", providing a basis for the subsequent distribution of smart routers.

[0078] For example: if the query information is button.open-type.contact, the extracted hierarchical identifier, subdivision dimension, and validation target are component, open-type (attribute), and contact (option value), respectively; if the query information is FileSystemManager.readFile.object.filePath, the extracted hierarchical identifier, subdivision dimension, and validation target are object, readFile (member method) → object (parameter type), and filePath (parameter name), respectively; if the query information is request.success.data, the extracted hierarchical identifier, subdivision dimension, and validation target are interface, success (callback type), and data (return parameter), respectively.

[0079] After determining the hierarchical identifier, i.e. the type configuration module, the system distributes query requests to the associated type configuration module through the intelligent router. The type configuration module at each level can use differentiated matching logic to ensure the accuracy of rule verification.

[0080] For example, the interface layer mainly targets the methods, parameters, and callbacks of the interface. That is, the interface layer matching focuses on the three-layer verification of interface-method type-parameter. The core is to determine whether the specified method type of the interface under the current platform supports the target parameter. When the intelligent router recognizes the layer identifier as "interface", it routes the query request to the interface Config module and retrieves the structured configuration of the corresponding interface in the cache of the configuration module for matching.

[0081] For example, the component layer mainly targets the component's attributes and option values. That is, the component layer matching focuses on the hierarchical verification of component-attribute-option value. The core is to determine whether the specified attribute of the component supports the target option value. When the smart router recognizes the hierarchical identifier as "component", it routes the query request to the componentConfig module and retrieves the structured configuration of the corresponding component for matching.

[0082] For example, the object layer mainly targets the member methods of objects and the return parameters of callback type configuration modules / type configuration modules. That is, the object layer matching focuses on the validation of object-member method-method parameter. The core is to determine whether the specified member method of the object supports the return parameters of the target callback type configuration module / type configuration module. When the intelligent router recognizes the layer identifier as "object", it routes the query request to the objectConfig module and retrieves the structured configuration of the corresponding object for matching.

[0083] In summary, structured data configured at each level is cached independently, and data generated during queries (query information + boolean values) is stored in a global cache. Subsequent queries retrieve data directly from the cache, avoiding repeated parsing and validation, thus improving matching speed. For example, if the same developer queries request.success.data multiple times, the result of the first match is stored in the cache, and subsequent queries directly return the cached results.

[0084] During implementation, the smart router can verify the validity of the "hierarchical identifier" before distribution (only interfaces, components, and objects are allowed). If the identifier is invalid, it will directly return false, avoiding invalid hierarchical matching processes. For example, if the query information is invalidType.test, its top-level identifier "invalidType" does not belong to the preset valid hierarchical identifiers of "interface, component, object, and plugin". The smart router will directly intercept it and return the detection result as false.

[0085] The workflow of a smart router can be broadly divided into three stages: route determination, request distribution, and result return preparation. Each stage aims for accuracy and efficiency.

[0086] During the routing decision phase, based on the validity verification and direction determination of the hierarchical identifier, the system first receives the "hierarchical identifier" of the type configuration module output from the parsing module. It then checks whether this identifier falls under one of the three preset valid identifiers for "interface, component, or object" to ensure basic query identifier validity. If it is an invalid identifier (such as invalidType in invalidType.test), it is directly identified as an invalid path and intercepted, without further distribution. The result feedback module is simultaneously notified to return false to avoid invalid configuration layer queries. If it is a valid identifier, the system proceeds to the routing direction determination phase of the type configuration module. In the direction determination phase, a preset mapping table is used to determine the type configuration module associated with the current query request. For example, if the identifier is "interface," it maps to `interfaceConfig`; if the identifier is "component," it maps to `componentConfig`; and if the identifier is "object," it maps to `objectConfig`. This mapping table is statically configured (loaded during architecture initialization) and does not require dynamic calculation, ensuring low latency in routing decisions.

[0087] During the request distribution phase, the query context is passed to the type configuration module. The complete three elements output by the parsing module (hierarchical identifier, subdivision dimension, and validation target) are encapsulated as key query information, ensuring the type configuration module obtains all the information needed for matching. A targeted call is made to the type configuration module, passing the key query information to its matching interface. This achieves a different approach from traditional full configuration traversal; the intelligent router only calls a single target module, avoiding cross-module resource consumption.

[0088] During the result feedback preparation phase, the intelligent router assigns a unique request ID to each query request during request distribution, and internally establishes a mapping relationship between the request ID and the callback interface of the result feedback module. This ensures that the matching result (true / false) returned by the type configuration module is accurately associated with the original query request. This mechanism solves the result confusion problem in multi-concurrent query scenarios. For example, when processing two queries simultaneously, button.open-type.contact and FileSystemManager.readFile, the result attribution can be distinguished by the request ID. After the type configuration module completes the matching and returns the result, the intelligent router finds the corresponding callback interface based on the request ID and passes the matching result to the result feedback module. The latter then handles the caching and storage and returns the result to the developer interface. The entire transmission process requires no additional data processing; it only acts as a transmission channel, ensuring the high efficiency of result feedback.

[0089] Based on the foregoing descriptions of specific details and reasoning about the technical effects, it can be seen that the embodiments of this application are designed to meet the core requirement of "cross-platform operation" of lightweight programs, covering a variety of scenarios that require determining whether "interface / component / object supports the current platform".

[0090] The first exemplary scenario is cross-platform functionality adaptation. Because lightweight applications need to run on multiple systems (mobile (iOS / Android) and desktop (Windows / Mac / Devtools)), different systems have different support for interfaces / components. This architecture allows for precise judgment. For example, when a developer wants to call the `onUserCaptureScreen` interface (to listen for user screenshots), they can use `xz.canIUse('onUserCaptureScreen')` to retrieve the compact configuration of the interface from the interface's Config (mobile, only supporting mobile devices). If the current platform is Windows (desktop), it returns false, allowing the developer to hide the functionality. Another example is when a developer wants to use the `live-player` component; they can use `xz.canIUse('live-player')` to query if the configuration is... (Supports all platforms) will return true across the entire system, ensuring that the component renders correctly.

[0091] The second exemplary scenario is the fine-grained capability assessment of lightweight application interfaces / components. Because some interface / component sub-capabilities (such as parameters, callbacks, and option values) differ across platforms, layered testing of compatibility across specific dimensions is necessary. For example, in fine-grained interface-level assessment, when a developer wants to call the request interface, they need to confirm whether the method.POST parameter is supported. This can be done by querying `xz.canIUse('request.object.method.POST')` and checking the interface-level configuration (...). In the `|o:url,method.GET.POST)` method, validation is performed. If `true` is returned, the POST request using the type configuration module is allowed. For example, to fine-tune the type configuration module at the component level, when using the `button` component, developers need to confirm whether the `open-type.contact` (contact customer service) option is supported. This can be done by querying `xz.canIUse('button.open-type.contact')`, which checks the component layer configuration accordingly. If `true` is returned, the customer service button will be displayed.

[0092] The third exemplary scenario involves adapting lightweight application objects and their member methods. Because built-in objects in lightweight applications (such as the FileSystemManager file management object and the CameraContext camera object) and their member methods (such as readFile and onCameraFrame) have platform support differences, compatibility testing at the object level is necessary. For example, if a developer wants to use the FileSystemManager.readFile method to read a file in a lightweight application, they need to confirm whether the filePath parameter is supported. This can be done by querying `xz.canIUse('FileSystemManager.readFile.object.filePath')` and checking the corresponding configuration at the object level. If the validation in |o:readFile.object.filePath returns true, then the file reading logic will be executed.

[0093] Beyond the direct effects at the technical level, its impact on the lifecycle of lightweight applications extends across the developer, runtime system, and business experience sides.

[0094] From the developer's perspective, it can guide code writing and adaptation, reducing cross-platform development costs. The test results directly provide developers with clear evidence of whether a function is usable, helping them avoid compatibility issues in advance during the coding phase and reducing debugging costs and code rework.

[0095] First, developers can write conditional logic in their code based on the test results. This allows the functionality to work correctly on supported platforms and automatically hide or degrade on unsupported platforms, preventing lightweight programs from throwing errors due to calling unsupported interfaces / components. This is equivalent to dynamically adjusting the code logic to achieve conditional feature development. For example, if `xz.canIUse('onUserCaptureScreen')` returns false (the current platform is Windows, and the screenshot listening interface is not supported), developers can hide the logic in the code that triggers sharing after a screenshot, avoiding runtime errors such as "interface not found." Similarly, if `xz.canIUse('button.open-type.contact')` returns true (the current platform supports the customer service button), then the button with customer service functionality will be rendered; if it returns false, it will be replaced with a regular button with a message indicating that customer service functionality is not currently supported, ensuring normal interface interaction.

[0096] Secondly, the upper-level calling syntax of this architecture is fully aligned with other lightweight application platforms. Developers do not need to learn new interface calling methods and can directly reuse the compatibility judgment logic of the lightweight application they are already familiar with. The boolean value format of the detection results is also fully compatible with other ecosystems, which greatly reduces the learning cost and code transformation cost when migrating from lightweight applications to different lightweight application ecosystems (such as iOS / Android / Windows), unifies the code style, and reduces the cost of ecosystem migration and learning.

[0097] Furthermore, the test results can help developers define the scope of available functionality, clarify adaptation boundaries, reduce unnecessary debugging, and prevent developers from wasting time debugging on unsupported platforms. For example, if xz.canIUse('FileSystemManager.readFile.object.filePath') returns false, developers can clearly indicate that the current platform does not support the filePath parameter of the readFile method, eliminating the need to repeatedly check for parameter errors or method call order issues. They can directly switch to using alternative interfaces or platform-specific adaptation solutions, improving development efficiency.

[0098] From the perspective of the runtime system, the test results not only serve the developers' coding needs, but also serve as the decision-making basis for the lightweight program's runtime system, helping the system to dynamically adjust resource allocation, avoid operational risks, ensure the stable operation of the lightweight program, and optimize cross-platform resource scheduling.

[0099] First, during the runtime of the lightweight application, the system relies on the detection results in real time to intercept the interfaces / components called by the developer using the type configuration module. That is, if the detection result is false (feature not supported), the system will directly block the call to that interface or return a pre-defined unsupported message. This prevents the lightweight application from crashing, displaying a blank screen, or reporting console errors due to calling non-existent functions. By intercepting invalid interface calls, runtime crashes or exceptions are avoided. If a developer mistakenly calls CameraContext.onCameraFrame (the camera frame listening interface), and xz.canIUse('CameraContext.onCameraFrame') returns false (the current platform is Mac Devtools, which does not support camera functionality), the system will intercept the call and throw a friendly "feature not supported" message from the type configuration module, rather than crashing directly.

[0100] Secondly, the system stores the query information and detection results in a global cache. For example, it saves the query result `request.object.url` as `true`. When developers repeatedly call the same query, they don't need to re-trigger the complete compatibility check process of the type configuration module; instead, they can directly read the result from the cache. This layered caching improves the performance of repeated queries. This mechanism is based on the stability of the type configuration module in the detection results—meaning that the functionality support status won't change frequently on the same platform. This significantly reduces runtime computational resource consumption and improves the response speed of lightweight programs. The performance optimization effect of caching is even more pronounced when developers frequently check multiple functions.

[0101] Furthermore, the detection results indirectly guide the system to load resources on demand. That is, for functions that return false, the system can avoid loading resource files that the function depends on (such as component styles and underlying interface implementation code), supporting differentiated resource loading examples across multiple platforms. This reduces the overall resource loading size during lightweight program startup and improves loading speed. For example, if xz.canIUse('live-player') returns false (the current platform does not support live streaming components), the system can skip loading the live-player component's style files (.wxss) and logic code (.js), reducing the lightweight program package size and shortening startup time.

[0102] From the perspective of business experience, the test results ultimately affect the user's actual experience through whether the function is available. The lightweight program ensures the consistency of user experience across multiple platforms and reduces the risk of business failure.

[0103] Firstly, without compatibility testing, developers calling unsupported functions can lead to issues on the user's end, such as unresponsive buttons, malfunctioning UI elements, and errors after operations, severely impacting the user experience. This solution effectively prevents users from encountering function failures or UI anomalies while using lightweight applications. For example, if `button.open-type.contact` is not supported on a certain platform but wasn't tested, clicking the customer service button might result in no response, leading users to mistakenly believe the function is faulty. By dynamically hiding this button or replacing it with a regular button based on the test results, invalid operations can be avoided, ensuring a smooth user experience.

[0104] Secondly, for the core business functions of lightweight applications (such as payment, sharing, and customer service), the test results help developers ensure that core functions are available on all target platforms, or provide equivalent alternatives, avoiding business gaps caused by platform differences and minimizing differences in business functions across platforms. For example, if the request.object.method.POST method that the payment function depends on is supported on a certain platform (test result: true), then the payment request will be initiated normally; if a certain platform only supports the GET method (POST test result: false), the developer can adjust the request parameters to GET based on the result, ensuring that the payment business can still be completed normally on that platform, achieving seamless business functionality.

[0105] Furthermore, when compatibility issues arise in the lightweight application's online environment, the test results can serve as a basis for troubleshooting. Developers can check the logs for the results of `xz.canIUse()` on the user's end to quickly determine if the problem is due to unsupported functionality, rather than investigating complex factors like code logic or API calls. This shortens troubleshooting time and reduces the difficulty of online troubleshooting. For example, if a user reports being unable to upload images, and the developer checks the logs and finds that `xz.canIUse('chooseImage.object.count')` returns false (the current platform does not support the `count` parameter), the problem can be directly identified as parameter incompatibility, rather than checking if the image upload interface is abnormal, thus improving troubleshooting efficiency.

[0106] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 5 As shown, the electronic device includes a processor 510 and a memory 520. In one possible form of the electronic device, it may also include an input device 530, an output device 540, and a communication device 550. The number of processors 510 in the electronic device can be one or more. Figure 5 Taking a processor 510 as an example; the processor 510, memory 520, input device 530, output device 540, and communication device 550 in the electronic device can be connected via a bus or other means. Figure 5Taking the example of a connection between China and Israel via a bus.

[0107] The memory 520, as a computer-readable storage medium, can be used to store software programs, computer-executable programs, and modules, such as the program instructions / modules corresponding to the compatibility detection method in this embodiment. The processor 510 executes various functional applications and data processing of the electronic device by running the software programs, instructions, and modules stored in the memory 520, thereby implementing the aforementioned compatibility detection method.

[0108] The memory 520 may primarily include a program storage area and a data storage area. The program storage area may store the operating system and at least one application program required for a given function; the data storage area may store data created based on the use of the electronic device. Furthermore, the memory 520 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some instances, the memory 520 may further include memory remotely located relative to the processor 510, which can be connected to the electronic device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0109] Input device 530 can be used to receive network configuration information. Output device 540 may include electronic devices such as a display screen.

[0110] The aforementioned electronic device can be used to perform any compatibility testing method, and has the corresponding functions and beneficial effects.

[0111] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the above-described apparatus and equipment can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0112] Furthermore, embodiments of this application also provide a storage medium containing computer-executable instructions. When executed by a computer processor, the computer-executable instructions are used to perform relevant operations in the compatibility detection method provided in any embodiment of this application, and have corresponding functions and beneficial effects.

[0113] Those skilled in the art will understand that embodiments of this application may be provided as methods, systems, or computer program products.

[0114] Therefore, this application may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, produce implementations of the flowchart... Figure 1 One or more processes and / or boxes Figure 1 The computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0115] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory. Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0116] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0117] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0118] The above specific embodiments have further detailed the purpose, technical solution, and beneficial effects of this application. It should be understood that the above are merely specific embodiments of this application and are not intended to limit the scope of protection of this application. In particular, it should be noted that any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application for those skilled in the art.

Claims

1. A compatibility testing method, characterized in that, include: Obtain query information with a preset statement structure, wherein the statement structure is determined according to a capability layering architecture, and the capability layering architecture includes a type configuration module associated with the capability type; The query information is parsed to obtain the target capability type and target attribute information; In the type configuration module associated with the target capability type, the detection result is determined by matching the target attribute information.

2. The compatibility testing method according to claim 1, characterized in that, The type configuration module associated with the target capability type determines the detection result by matching the target attribute information, including: Based on the target capability type, confirm the target type configuration module from at least one pre-stored type configuration module; The detection result is determined by information matching in the target type configuration module based on the target attribute information.

3. The compatibility testing method according to claim 1 or 2, characterized in that, The process of parsing the query information to obtain the target capability type and target attribute information includes: The query information is split according to the structure identifier of the statement structure to obtain the target capability type and the target attribute information with hierarchical relationship. The hierarchical relationship is associated with the hierarchical method of the target capability type in the capability hierarchical architecture.

4. The compatibility testing method according to claim 3, characterized in that, The type configuration module associated with the target capability type determines the detection result by matching the target attribute information, including: When the target attribute information includes multiple layers, the type configuration module associated with the target capability type determines the detection result by matching layer by layer according to the target attribute information.

5. The compatibility testing method according to claim 4, characterized in that, When the target attribute information includes multiple layers, the type configuration module associated with the target capability type determines the detection result by matching layer by layer according to the target attribute information, including: When the target attribute information includes multiple layers, the type configuration module associated with the target capability type matches layer by layer according to the target attribute information; If each layer of the target attribute information is successfully matched, the detection result is determined to be passed; If any layer of the target attribute information fails to match, the detection result is determined to be unsuccessful.

6. The compatibility testing method according to claim 1 or 2, characterized in that, The process of obtaining query information with a preset statement structure includes: Query information with a preset statement structure can be obtained through a preset unified query interface.

7. The compatibility testing method according to claim 6, characterized in that, The step of obtaining query information with a preset statement structure through a preset unified query interface includes: Obtain initial query information, and then align and transform the initial query information according to the preset statement structure through the preset unified query interface to obtain the query information.

8. The compatibility testing method according to claim 1 or 2, characterized in that, Also includes: Receive newly added type configuration modules and save the newly added type configuration modules and pre-stored type configuration modules independently.

9. The compatibility testing method according to claim 1, characterized in that, The query information is a structured string.

10. The compatibility testing method according to claim 9, characterized in that, The structured string records attribute information for each capability type in segments based on delimiters and according to preset encoding rules.

11. The compatibility testing method according to claim 10, characterized in that, The separators include separators for separating capability types and separators for separating nested relationships of attribute information.

12. The compatibility testing method according to claim 9 or 10, characterized in that, The process of parsing the query information to obtain the target capability type and target attribute information includes: Extract the checksum from the string and verify the integrity of the query information based on the checksum; If the integrity verification passes, the string is parsed according to the preset encoding rules to extract the target capability type and target attribute information determined by the delimiter.

13. An electronic device, characterized in that, The electronic device includes: One or more processors; A storage device configured to store one or more programs, which, when executed by one or more processors, cause the one or more processors to implement the compatibility detection method according to any one of claims 1-12.

14. A non-volatile storage medium for storing computer-executable instructions, characterized in that, The computer-executable instructions, when executed by a processor, are configured to perform the compatibility detection method according to any one of claims 1-12.

Images