Swan gap component library as well as construction method and calling method thereof

Abstract

The invention discloses a swan gap component library and a construction method and a calling method thereof. According to the method provided by the invention, the standardized component interfaces are defined for different types of the gap components, so that the problems of calling difference and compatibility among the components can be reduced when a developer uses the components in the gap component library. And the self-adaptive layout engine and the function support detection engine can be automatically triggered when the components in the swan gap component library are called. The availability of the component in the terminal equipment is verified through the function supportability detection engine, the abnormity caused by the fact that the equipment does not support the function of the component is avoided, and the system stability is improved. Through the self-adaptive layout engine, the typesetting and display effects of the component can be automatically adjusted according to parameters such as screen size, resolution and direction of terminal equipment to which the development application belongs, presentation on different equipment is more coordinated, and the problem of layout disorder or poor interface adaptation is reduced.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a HarmonyOS component library and its construction and invocation methods. Background Technology

[0002] With the rapid adoption of the HarmonyOS operating system, development efficiency has become a key challenge for ecosystem prosperity. HarmonyOS continues to iterate, and its ecosystem is becoming increasingly robust. Currently, the number of devices supporting HarmonyOS exceeds 1 billion, and the number of native HarmonyOS applications and meta-services continues to increase. In traditional development models, developers often repeatedly develop similar functional components for different projects, resulting in wasted resources and low development efficiency. The lack of unified component library standards and development frameworks leads to extended development cycles and delayed project delivery.

[0003] Currently, the styles and interaction logic of components in mainstream open-source component libraries differ somewhat from enterprise app design specifications. In order to better adapt to various products, the components in open-source component libraries are highly flexible. Consequently, in the actual development process, a large amount of repetitive code still needs to be written, and the encapsulation is insufficient, resulting in low component library construction efficiency and high difficulty in scheduling on the development side. Summary of the Invention

[0004] In view of this, this application provides a HarmonyOS component library and its construction and calling methods, which can build a component library adapted to the HarmonyOS system, make full use of the characteristics of HarmonyOS, realize more atomic component design, and facilitate developers to quickly build HarmonyOS applications.

[0005] According to the first aspect of this application, a method for constructing a HarmonyOS component library is provided, including: Define standardized component interfaces for different types of HarmonyOS components; Based on the syntax features of the HarmonyOS system, an adaptive layout engine and a functional support detection engine for the HarmonyOS components were developed. The dependencies on the adaptive layout engine and the functional support detection engine are declared in the dependency configuration of the HarmonyOS components; The adaptive layout engine, the functional support detection engine, and the HarmonyOS components are packaged into a HarmonyOS component library. After calling and loading the target component in the HarmonyOS component library, the functional availability of the target component is determined based on the terminal device parameters, and the layout and rendering method of the target component displayed on the terminal device are optimized.

[0006] Optionally, after generating the HarmonyOS component library, the method for building the HarmonyOS component library further includes: Based on the identification information of the HarmonyOS component, obtain the latest version information of the HarmonyOS component from the server; Based on the latest version information and the version information of the HarmonyOS components in the HarmonyOS component library, the components that have new versions and need to be updated are identified. Based on the identification information of the component to be updated, download the upgrade package of the component to be updated from the server; Load the upgrade package to upgrade the HarmonyOS components to the latest version; Update the HarmonyOS components currently stored in the HarmonyOS component library to the latest version of HarmonyOS components.

[0007] Optionally, the definition of standardized component interfaces for different types of HarmonyOS components includes: A bidirectional communication layer is constructed based on the JavaScript Proxy mechanism, wherein the bidirectional communication layer adopts a unified JSBridge interface format; ArkTS is bridged with the development side by calling the .javaScriptProxy({object:nativeObj,name:"JSBridge"}) method.

[0008] Optionally, the development of the adaptive layout engine for the HarmonyOS components based on the syntax features of the HarmonyOS system includes: The dynamic layout function defined by the matchMediaSync interface dynamically matches the layout style based on the screen state variables of the terminal device. The layout style is bound to the Flex layout parameters through a reference passing mechanism. The screen state variables include screen width, landscape / portrait status, and breakpoint markers. The layout styles include single-column layout, double-column grid layout, and flow layout.

[0009] Optionally, the development of the functional support detection engine for the HarmonyOS components based on the syntax features of the HarmonyOS system includes: The functionality support detection engine is created based on the permission verification logic of the AbilityContext.verifyPermission() method. The permission verification is configured to synchronously perform security verification on the permission status of the hardware capabilities that the target component needs to call during the initialization lifecycle phase of the target component. When the security verification result is authorized, the target component is allowed to load and call its hardware driver to execute the full functionality of the target component. When the security verification result is unauthorized, the call to the hardware driver of the target component is canceled, and the target component is displayed in a preset display mode.

[0010] Optionally, the step of packaging the adaptive layout engine, the functional support detection engine, and the HarmonyOS components into a HarmonyOS component library includes: Based on the ohpm specification, each HarmonyOS component is encapsulated as an independent base package, and the adaptive layout engine and the functional support detection engine are encapsulated as functional packages. The base package and the function package are uploaded to a private repository that supports the ohpm protocol to form the HarmonyOS component library; An integration framework for the HarmonyOS component library is built based on the address of the private repository. The integration framework supports loading the HarmonyOS components from the private repository via the ohpm command.

[0011] According to a second aspect of this application, a method for invoking the HarmonyOS component library is provided, including: In response to an application development request that supports the HarmonyOS system, the identification information of the target component matching the application development request is determined; Based on the identification information of the target component, the target component is obtained from the HarmonyOS component library. The HarmonyOS component library is packaged from multiple HarmonyOS components defined by the standardized component interface, an adaptive layout engine, and a functional support detection engine. The HarmonyOS component declares its dependency relationship with the adaptive layout engine and the functional support detection engine in its dependency configuration. In response to the loading instruction of the target component, the adaptive layout engine and the functional support detection engine associated with the target component are triggered through the dependency relationship, so as to determine the functional availability of the target component based on the terminal device parameters and optimize the layout and rendering method of the target component displayed on the terminal device. The target component, after functional availability assessment and layout optimization, is rendered and displayed in the UI interface of the terminal device.

[0012] Optionally, optimizing the layout and rendering method of the target component based on terminal device parameters includes: A media query listener is created using the matchMediaSync interface to obtain the screen state variables of the terminal device; The dynamic layout function is called based on the screen state variables to match the layout style of the terminal device; Filter the Flex layout parameters that are bound to the layout style; The screen state variables include screen width, landscape / portrait status, and breakpoint markers, and the layout styles include single-column layout, double-column grid layout, and flow layout.

[0013] Optionally, determining the functional availability of the target component based on terminal device parameters includes: In response to the target component being in the initialization lifecycle phase, the AbilityContext.verifyPermission() method is called to perform synchronous security verification on the permission status of the hardware capabilities that the target component needs to access; When the security verification result indicates that authorization has been granted, the target component is allowed to load and invoke its hardware driver to perform the full functionality of the target component. When the security check result is unauthorized, cancel the invocation of the hardware driver of the target component and display the target component in the preset display mode.

[0014] According to a third aspect of this application, a HarmonyOS component library is provided, which is created using the aforementioned HarmonyOS component library construction method.

[0015] According to a fourth aspect of this application, an apparatus for building a HarmonyOS component library is provided, the apparatus comprising: The interface standardization module is used to define standardized component interfaces for different types of HarmonyOS components; The development module is used to develop an adaptive layout engine and a functional support detection engine for the HarmonyOS components based on the syntax features of the HarmonyOS system; and, The dependencies on the adaptive layout engine and the functional support detection engine are declared in the dependency configuration of the HarmonyOS components; The construction module is used to package the adaptive layout engine, the functional support detection engine, and the HarmonyOS components to generate the HarmonyOS component library. After calling and loading the target component in the HarmonyOS component library, the module determines the functional availability of the target component based on the terminal device parameters and optimizes the layout and rendering method of the target component displayed on the terminal device.

[0016] Optionally, the apparatus for building the HarmonyOS component library further includes: The update module is configured to: obtain the latest version information of the HarmonyOS component from the server based on the identification information of the HarmonyOS component; determine the component to be updated that has a new version based on the latest version information and the version information of the HarmonyOS component in the HarmonyOS component library; download the upgrade package of the component to be updated from the server based on the identification information of the component to be updated; load the upgrade package to upgrade the HarmonyOS component to the latest version; and update the HarmonyOS components currently stored in the HarmonyOS component library to the latest version of the HarmonyOS component.

[0017] Optionally, the interface standardization module is specifically used to build a bidirectional communication layer based on the JavaScript Proxy mechanism, wherein the bidirectional communication layer adopts a unified JSBridge interface format; and bridges ArkTS and the development side by calling the .javaScriptProxy({object:nativeObj,name:"JSBridge"}) method.

[0018] Optionally, the development module is specifically used to dynamically match layout styles based on the dynamic layout function defined by the matchMediaSync interface, based on the screen state variables of the terminal device. The layout style is bound to the Flex layout parameters through a reference passing mechanism. The screen state variables include screen width, landscape / portrait status, and breakpoint markers. The layout styles include single-column layout, double-column grid layout, and flow layout.

[0019] Optionally, the development module is specifically used to create the functional support detection engine based on the permission verification logic of the AbilityContext.verifyPermission() method. The permission verification is configured to synchronously perform security verification on the permission status of the hardware capabilities required by the target component during the initialization lifecycle phase of the target component. When the security verification result is authorized, the target component is allowed to load and call its hardware driver to execute the full functionality of the target component. When the security verification result is unauthorized, the call to the hardware driver of the target component is canceled, and the target component is displayed in a preset display mode.

[0020] Optionally, the construction module is specifically used to encapsulate each HarmonyOS component into an independent base package based on the ohpm specification, and to encapsulate the adaptive layout engine and the functional support detection engine into functional packages; upload the base packages and the functional packages to a private repository that supports the ohpm protocol to form the HarmonyOS component library; and build an integration framework for the HarmonyOS component library based on the address of the private repository, wherein the integration framework supports loading the HarmonyOS components from the private repository via ohpm commands.

[0021] According to a fifth aspect of this application, a device for invoking the HarmonyOS component library is provided, the device comprising: The component determination module is used to determine the identification information of the target component that matches the application development request in response to the application development request that supports the HarmonyOS system. The calling module is used to retrieve the target component from the HarmonyOS component library based on the identification information of the target component. The HarmonyOS component library is composed of multiple HarmonyOS components defined by standardized component interfaces, an adaptive layout engine, and a functionality support detection engine, packaged together. Furthermore, the HarmonyOS components declare their dependencies on the adaptive layout engine and the functionality support detection engine in their dependency configurations. In response to the loading instruction of the target component, the adaptive layout engine and the functional support detection engine associated with the target component are triggered through the dependency relationship to optimize the layout and rendering method of the target component based on the terminal device parameters, and to determine the functional availability of the target component. The display module is used to render and display the target component, after functional availability assessment and layout optimization, in the UI interface of the terminal device.

[0022] Optionally, the calling module is specifically used to create a media query listener through the matchMediaSync interface to obtain the screen state variables of the terminal device; call a dynamic layout function based on the screen state variables to match the layout style of the terminal device; and filter the Flex layout parameters bound to the layout style; wherein the screen state variables include screen width, landscape / portrait status and breakpoint identifier, and the layout style includes single-column layout, double-column grid layout and flow layout.

[0023] Optionally, the calling module is specifically configured to, in response to the target component being in the initialization lifecycle phase, call the AbilityContext.verifyPermission() method to synchronously perform a security check on the permission status of the hardware capabilities that the target component needs to call; when the security check result is authorized, allow the target component to load and call its hardware driver to execute the full functionality of the target component; when the security check result is unauthorized, cancel the call to the hardware driver of the target component and display the target component in a preset display mode.

[0024] According to the sixth aspect of this application, a readable storage medium is provided on which a program or instructions are stored, and when the program or instructions are executed by a processor, the steps of the above-described method for constructing the HarmonyOS component library and the method for calling the HarmonyOS component library are implemented.

[0025] According to the seventh aspect of this application, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the above-described method for constructing the HarmonyOS component library and the method for calling the HarmonyOS component library.

[0026] By employing the aforementioned technical solutions and defining standardized component interfaces for different types of HarmonyOS components, developers can reduce differences in component calls and compatibility issues when using components in the HarmonyOS component library. Multiple components in the HarmonyOS component library can be quickly invoked without additional adaptation. Furthermore, the HarmonyOS component library encapsulates an adaptive layout engine and a functionality support detection engine. These engines are automatically triggered when a component in the HarmonyOS component library is invoked. The functionality support detection engine verifies the usability of components on terminal devices, avoiding anomalies caused by devices not supporting component functionality and improving system stability. The adaptive layout engine automatically adjusts the layout and display effects of components based on parameters such as screen size, resolution, and orientation of the terminal device to which the application belongs, resulting in a more harmonious presentation across different devices and reducing layout errors or poor interface adaptation. This significantly improves the compatibility, maintainability, and cross-device adaptability of various HarmonyOS components in the HarmonyOS component library. Developers no longer need to invest significant time and manpower in redesigning components; they can directly use components from the HarmonyOS component library to complete HarmonyOS application development tasks with different functions, reducing HarmonyOS application development costs and shortening the development cycle. It addresses the core pain points of existing technologies such as low application development efficiency, low component reuse rate, complex UI adaptation, difficulty in cross-device adaptation, weak distributed capabilities, insufficient performance, and inconsistent design specifications.

[0027] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0028] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments of this application and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 A flowchart illustrating the construction method of the HarmonyOS component library provided in an embodiment of this application is shown; Figure 2 A flowchart illustrating the method for calling the HarmonyOS component library provided in this application embodiment is shown; Figure 3 This paper shows a structural block diagram of the HarmonyOS component library construction device provided in an embodiment of this application; Figure 4 This paper shows a structural block diagram of the device for calling the HarmonyOS component library provided in an embodiment of this application; Figure 5 A schematic diagram of the electronic structure of a computer device provided in an embodiment of this application is shown. Detailed Implementation

[0029] The present application will be described in detail below with reference to the accompanying drawings and embodiments. It should be noted that, unless otherwise specified, the embodiments and features described in the embodiments of the present application can be combined with each other.

[0030] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain this application, and should not be construed as limiting this application.

[0031] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the term “comprising” as used in this application means the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. It should be understood that when we say an element is “connected” or “attached” to another element, it can be directly connected or attached to the other element, or there may be intermediate elements. Furthermore, “connected” or “attached” as used herein can include wireless connections or wireless interconnections. The term “and / or” as used herein includes all or any unit and all combinations of one or more associated listed items.

[0032] Exemplary embodiments according to this application will now be described in more detail with reference to the accompanying drawings. However, these exemplary embodiments may be implemented in many different forms and should not be construed as being limited to the embodiments set forth herein. It should be understood that these embodiments are provided so that the disclosure of this application is thorough and complete, and that the concept of these exemplary embodiments is fully conveyed to those skilled in the art.

[0033] This embodiment provides a method for building a HarmonyOS component library, such as... Figure 1 As shown, the method includes: Step 101: Define standardized component interfaces for different types of HarmonyOS components.

[0034] The HarmonyOS components are various custom components supporting the HarmonyOS system, including basic components (such as input boxes, dropdown lists, dialog boxes, switches, buttons, and custom keyboards), composite components combining multiple basic components (such as business lists and user lists), and business suites (such as network request components, face recognition components, sharing components, and encryption / decryption algorithm components). HarmonyOS components can be pre-created by the development team, and their UI (User Interface) style elements can be customized as needed. Understandably, ensuring consistent code style within a unified component library is beneficial for long-term maintenance.

[0035] In this embodiment, by defining standardized component interfaces for different types of HarmonyOS components, the input and output of different HarmonyOS components are constrained, ensuring consistent behavior and unified APIs for all HarmonyOS components in the HarmonyOS component library. This reduces differences in component calls and compatibility issues when developers use components in the HarmonyOS component library. Developers no longer need to repeatedly learn the calling logic of different components; they can directly use the components in a standard manner, which helps reduce debugging time.

[0036] In practical application scenarios, step 101, which is to define standardized component interfaces for different types of HarmonyOS components, specifically includes: building a bidirectional communication layer based on the JavaScript Proxy mechanism; and bridging ArkTS and the development side by calling the .javaScriptProxy({object:nativeObj,name:"JSBridge"}) method.

[0037] The bidirectional communication layer adopts a unified JSBridge interface format, which can be a fixed request / response structure, error code specification, etc.

[0038] In this embodiment, a unified JSBridge interface format ensures consistency between the interaction logic of the ArkTS native layer and the JS development side. Developers do not need to concern themselves with the underlying communication details; they only need to call according to the standard format, reducing the complexity of cross-layer debugging. Furthermore, with the help of a JavaScript Proxy, access to the properties / methods of objects on the development side can be automatically captured and forwarded to the ArkTS side, and vice versa. This allows developers to call JSBridge using standard JS syntax, without needing to learn ArkTS-specific APIs, fully supporting dynamic parameter passing and asynchronous callbacks, significantly improving communication flexibility, maintainability, and the development experience. It lowers the barrier for front-end developers to integrate into the HarmonyOS ecosystem, ensures the efficiency and compatibility of cross-layer interaction, and provides a stable, simple, and reliable communication foundation for cross-platform collaboration.

[0039] For example, using JavaScriptProxy to inject ArkTS objects into the web frontend, the design supporting bidirectional calls is as follows: .javaScriptProxy({ object: interactiveObj, name: "interactive", methodList: ["postMessage"], / / List of exposed methods controller: webController }).

[0040] Step 102: Based on the syntax features of the HarmonyOS system, develop an adaptive layout engine and a functional support detection engine for HarmonyOS components.

[0041] The adaptive layout engine optimizes the layout and rendering of target components on the terminal device based on terminal device parameters. The functionality support detection engine determines the functionality availability of target components based on terminal device parameters.

[0042] In practical application scenarios, step 102 involves developing an adaptive layout engine for HarmonyOS components. Specifically, this includes: dynamic layout functions defined based on the matchMediaSync interface, which dynamically match layout styles based on the screen state variables of the terminal device. The layout styles are bound to Flex layout parameters through a reference passing mechanism.

[0043] The screen state variables include screen width, landscape / portrait orientation, and breakpoint markers. Layout styles include single-column layout, double-column grid layout, and flow layout. Landscape / portrait orientation includes size, resolution, orientation, and fold status.

[0044] In this embodiment, the matchMediaSync interface synchronously collects the screen state variables of the terminal device's current screen state compared to the preset screen state. The layout function can dynamically adjust the layout style based on the real-time collected screen state variables, achieving precise adaptation between components and the screen, ensuring smooth rendering effects on different screen sizes. Therefore, it eliminates the need to write numerous conditional statements or separate layout files, allowing the same layout function to serve different device environments (e.g., mobile phones, tablets, in-vehicle systems, watches), avoiding the significant cost of developing separate components for each device.

[0045] For example, the design of dynamically adjusting the interface layout at different screen sizes by listening to changes in screen width is as follows: / / 1. Import module import mediaquery from '@ohos.mediaquery'; / / 2. Create a listener ConstlistenerXS:mediaquery.MediaQueryListener=mediaquery.matchMediaSync('(0vp<=width<320vp)'); constlistenerSM:mediaquery.MediaQueryListener=mediaquery.matchMediaSync('(320vp<=width<600vp)'); / / 3. Register the listener aboutToAppear(): void { / / Add callback function listenerXS.on('change', (res: mediaquery.MediaQueryResult) =>{ console.log('changeRes:', JSON.stringify(res)) / / Dynamically adjust layout style }) / / Add callback function listenerSM.on('change', (res: mediaquery.MediaQueryResult) =>{ console.log('changeRes:', JSON.stringify(res)) / / Dynamically adjust layout style }) } / / 4. Remove the listener aboutToDisappear(): void { / / Remove listeners to avoid performance waste listenerXS.off('change') listenerSM.off('change') }

[0046] Flex layout parameters include: 1. Stretch adaptability: Allocate the space created by changes in container size using the flexGrow / flexShrink properties of Flex layout.

[0047] 2. Scale: Use the percentage or layoutWeight property to make child components scale synchronously with the container according to a preset ratio.

[0048] 3. Extend and hide: Combine List or Scroll+Row / Column to enable child components to dynamically display or scroll and extend according to the container size.

[0049] 4. Automatic line wrapping: By setting the Flex wrap property to Wrap, automatic line wrapping will occur when there is insufficient space.

[0050] In practical application scenarios, step 102 involves developing a functional support detection engine for HarmonyOS components, specifically including: creating a functional support detection engine based on the permission verification logic of the AbilityContext.verifyPermission() method.

[0051] AbilityContext.verifyPermission() is a standard permission verification interface provided by the HarmonyOS system. Permission verification is configured to synchronously and securely verify the permission status of the hardware capabilities that the target component needs to access during the initialization lifecycle of the target component. When the security verification result indicates authorization, the target component is allowed to load and invoke its hardware driver to execute its full functionality. When the security verification result indicates unauthorized access, the invocation of the target component's hardware driver is canceled, and the target component is displayed in a preset display mode.

[0052] In this embodiment, the logic that triggers the `AbilityContext.verifyPermission()` method is encapsulated within a functionality support detection engine. This allows for batch verification of required permissions via `verifyPermission()` before component initialization or function invocation. If permissions are missing, the user is prompted in advance to authorize or downgrade the function, preventing function crashes due to insufficient permissions. Developers do not need to repeatedly write permission judgment code in each functional module, reducing online issues caused by missed permission checks. This approach protects user privacy and system security while maintaining functional consistency and the integrity of the user experience.

[0053] Step 103: Declare the dependencies on the adaptive layout engine and the functionality support detection engine in the dependency configuration of the HarmonyOS components.

[0054] In this embodiment, the engine is forcibly packaged into the component library or application. This allows the HarmonyOS development environment to trigger the retrieval and activation of the appropriate layout and detection engines when the component is loaded, using explicit dependency declarations. Developers are not required to manually download and copy the engine code, ensuring that the component only works with compatible engine versions. This reduces runtime risks and improves development efficiency.

[0055] Step 104: Package the adaptive layout engine, the functional support detection engine, and the HarmonyOS components to generate the HarmonyOS component library.

[0056] The HarmonyOS component library construction method provided in this application defines standardized component interfaces for different types of HarmonyOS components. This allows developers to reduce differences in component calls and compatibility issues when using components in the HarmonyOS component library, enabling them to quickly call multiple components in the HarmonyOS component library without additional adaptation. Furthermore, the HarmonyOS component library encapsulates an adaptive layout engine and a functionality support detection engine. These engines are automatically triggered when a component in the HarmonyOS component library is called. The functionality support detection engine verifies the usability of components on terminal devices, avoiding anomalies caused by devices not supporting the component's functionality and improving system stability. The adaptive layout engine automatically adjusts the layout and display effects of components based on parameters such as screen size, resolution, and orientation of the terminal device to which the application belongs, resulting in a more coordinated presentation across different devices and reducing layout errors or poor interface adaptation. This significantly improves the compatibility, maintainability, and cross-device adaptability of various HarmonyOS components in the HarmonyOS component library. Developers do not need to invest significant time and manpower in redesigning components; they can directly use components from the HarmonyOS component library to complete HarmonyOS application development tasks with different functions, reducing HarmonyOS application development costs and shortening the development cycle. It addresses the core pain points of existing technologies such as low application development efficiency, low component reuse rate, complex UI adaptation, difficulty in cross-device adaptation, weak distributed capabilities, insufficient performance, and inconsistent design specifications.

[0057] In practical application scenarios, step 104, which involves packaging the adaptive layout engine, the functional support detection engine, and the HarmonyOS components to generate the HarmonyOS component library, specifically includes: based on the ohpm specification, encapsulating each HarmonyOS component into an independent base package, and encapsulating the adaptive layout engine and the functional support detection engine into functional packages; uploading the base packages and functional packages to a private repository that supports the ohpm protocol to form the HarmonyOS component library; and building an integration framework for the HarmonyOS component library based on the address of the private repository.

[0058] The integration framework supports loading HarmonyOS components from private repositories via the ohpm command. Private repositories can be deployed on the intranet to prevent core component code leaks and are no longer limited by the stability and access speed of public networks.

[0059] In this embodiment, each HarmonyOS component is encapsulated as an independent base package via ohpm, while the adaptive layout engine and functional support detection engine are also independent function packages, which can be shared by all base packages. The base packages and function packages are uploaded to a private repository that supports the ohpm protocol to form the HarmonyOS component library. Users can pull HarmonyOS components from the private repository using the ohpm command, and the engines they depend on are automatically downloaded along with them, eliminating the need to manually download source code or handle dependency conflicts. The entire process is no different from using any mainstream open-source library, providing a lightweight interface that can be called with a single line of code, resulting in a lower learning curve and a seamless integration experience. This achieves "one-click integration, out-of-the-box use" of the component library.

[0060] It is worth mentioning that the base package (HarmonyOS components) and the function package (engine) can isolate code permissions through a private repository to avoid code chaos.

[0061] In one embodiment, the method for constructing the HarmonyOS component library after step 104 further includes: obtaining the latest version information of the HarmonyOS component from the server based on the identification information of the HarmonyOS component; determining the component to be updated that has a new version based on the latest version information and the version information of the HarmonyOS component in the HarmonyOS component library; downloading the upgrade package of the component to be updated from the server based on the identification information of the component to be updated; loading the upgrade package to upgrade the HarmonyOS component to the latest version; and updating the HarmonyOS component currently stored in the HarmonyOS component library to the latest version of the HarmonyOS component.

[0062] In this embodiment, the system can automatically detect, download, and update HarmonyOS components by comparing the latest version on the server with the local version. This eliminates the need to redeploy the entire application or component library; instead, it only downloads and updates HarmonyOS components as needed when new versions are available, significantly reducing network traffic and update time costs. Furthermore, it ensures that all application projects can keep up with the latest stable versions of the component library in near real-time, greatly reducing version fragmentation issues within the team and achieving precise incremental updates and version control.

[0063] like Figure 2 As shown in the embodiment of this application, a method for calling the HarmonyOS component library is provided, the method including: Step 201: In response to the application development request that supports the HarmonyOS system, determine the identification information of the target component that matches the application development request.

[0064] In this embodiment, by matching the component's name, function description, usage scenario, and other identification information based on development requirements, the required corresponding component can be found quickly and accurately, avoiding incorrect integration due to functional incompatibility, ensuring the consistency between the component and the development request, reducing the difficulty of application development, and accelerating the development process.

[0065] Step 202: Based on the identification information of the target component, obtain the target component from the HarmonyOS component library.

[0066] The HarmonyOS component library is created using the construction method described in the above embodiments. This HarmonyOS component library includes multiple HarmonyOS components defined by standardized component interfaces, an adaptive layout engine, and a functionality support detection engine. Furthermore, the HarmonyOS components declare their dependencies on the adaptive layout engine and the functionality support detection engine in their dependency configurations.

[0067] Step 203: In response to the loading instruction of the target component, the adaptive layout engine and functional support detection engine associated with the target component are triggered through dependencies.

[0068] The functional support detection engine is used to determine the functional availability of target components based on terminal device parameters. The adaptive layout engine is used to optimize the layout and rendering of target components on the terminal device based on terminal device parameters.

[0069] Step 204: Render and display the target component, after functional availability assessment and layout optimization, in the UI interface of the terminal device.

[0070] In this embodiment, the component library based on standardized interfaces can quickly respond to development requests, reduce redundant development, and offers high component reusability, allowing for rapid invocation of the target components required for development. Simultaneously, during component loading, the dependency configuration automatically triggers the detection and layout engines, dynamically determining functional availability and optimizing the layout based on device parameters. This not only performs security checks such as permissions before component loading, fundamentally preventing runtime crashes or functional abnormalities due to insufficient permissions, but also greatly improves application robustness. Furthermore, it selects and applies the optimal layout (such as single-column, double-column, etc.) for target components, ensuring that the user interface remains responsive and interactive across different HarmonyOS devices (phones, tablets, watches, etc.), achieving true cross-platform consistency so that components can correctly display data and respond to user actions. Ultimately, this achieves a consistent user experience across devices while reducing maintenance costs and supporting efficient and large-scale development of HarmonyOS applications.

[0071] Understandably, leveraging the high-performance IPC mechanism of the ArkUI rendering engine, component event handling functions should strictly adhere to the async / await asynchronous call specification to avoid blocking the main thread and ensure smooth and stable UI interactions. For example, in high-frequency interaction scenarios such as list scrolling, LazyForEach can be used to delay loading of components in non-visible areas, further improving rendering performance and user experience.

[0072] In practical application scenarios, after triggering the adaptive layout engine associated with the target component, the optimization of the target component's layout and rendering method based on the terminal device parameters includes: creating a media query listener through the matchMediaSync interface to obtain the terminal device's screen state variables; calling the dynamic layout function based on the screen state variables to match the terminal device's layout style; and filtering the Flex layout parameters bound to the layout style.

[0073] Among them, screen state variables include screen width, landscape / portrait status, and breakpoint markers, and layout styles include single-column layout, double-column grid layout, and flow layout.

[0074] In this embodiment, the screen state is captured in real time using the matchMediaSync interface. A dynamic layout function automatically matches the layout style with the device state and filters the bound Flex parameters. The flexible layout feature adapts to different screen spaces, ensuring UI consistency. The entire process eliminates the need for manually writing numerous conditional statements, reducing code redundancy and improving development efficiency. Simultaneously, it enables the target component to achieve smooth and adaptive interface rendering on multiple terminals such as mobile phones and tablets, enhancing cross-device compatibility of the application.

[0075] In practical application scenarios, after triggering the functional support detection engine associated with the target component, the functional availability of the target component is determined based on the terminal device parameters. This includes: in response to the target component being in the initialization lifecycle phase, calling the AbilityContext.verifyPermission() method to synchronously and securely verify the permission status of the hardware capabilities that the target component needs to call; when the security verification result is authorized, the target component is allowed to load and call its hardware driver to execute the full functionality of the target component; when the security verification result is unauthorized, the call to the hardware driver of the target component is canceled, and the target component is displayed in a preset display mode.

[0076] In this embodiment, `verifyPermission()` is synchronously called during component initialization to accurately verify hardware permissions using native system capabilities, and differentiated processing is performed based on the verification results. Specifically, if authorization is successful, the hardware driver is loaded normally to ensure full functionality; if authorization is unsuccessful, the driver call is canceled and a preset mode is switched to avoid functional crashes while ensuring a consistent user experience. The overall mechanism not only complies with HarmonyOS permission management specifications but also enhances the stability of components in multi-device environments through proactive interception and fault tolerance, helping developers to avoid runtime errors caused by unauthorized access.

[0077] It should be noted that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0078] Furthermore, such as Figure 3 As shown, as a specific implementation of the above-mentioned HarmonyOS component library construction method, this application embodiment provides a HarmonyOS component library construction device 300, which includes: an interface standardization module 301, a development module 302, and a construction module 303.

[0079] Among them, the interface standardization module 301 is used to define standardized component interfaces for different types of HarmonyOS components; Development module 302 is used to develop an adaptive layout engine and a functionality support detection engine for HarmonyOS components based on the syntax features of the HarmonyOS system; and to declare the dependencies on the adaptive layout engine and the functionality support detection engine in the dependency configuration of HarmonyOS components. Module 303 is used to package the adaptive layout engine, the functional support detection engine, and the HarmonyOS components to generate the HarmonyOS component library. This allows the system to determine the functional availability of the target component based on terminal device parameters after calling and loading the target component in the HarmonyOS component library, and to optimize the layout and rendering of the target component on the terminal device.

[0080] Furthermore, the HarmonyOS component library building device 300 also includes: The update module (not shown in the figure) is used to obtain the latest version information of HarmonyOS components from the server based on the identification information of the HarmonyOS components; determine the components to be updated that have new versions based on the latest version information and the version information of HarmonyOS components in the HarmonyOS component library; download the upgrade package of the component to be updated from the server based on the identification information of the component to be updated; load the upgrade package to upgrade the HarmonyOS component to the latest version; and update the HarmonyOS components currently stored in the HarmonyOS component library to the latest version of the HarmonyOS components.

[0081] Furthermore, the interface standardization module 301 is specifically used to build a bidirectional communication layer based on the JavaScript Proxy mechanism. The bidirectional communication layer adopts a unified JSBridge interface format and bridges ArkTS and the development side by calling the .javaScriptProxy({object:nativeObj,name:"JSBridge"}) method.

[0082] Furthermore, module 302 is specifically used for dynamic layout functions defined based on the matchMediaSync interface to dynamically match layout styles based on the screen state variables of the terminal device. The layout style is bound to the Flex layout parameters through a reference passing mechanism. The screen state variables include screen width, landscape / portrait status, and breakpoint markers. The layout styles include single-column layout, double-column grid layout, and flow layout.

[0083] Furthermore, module 302 is specifically used to create a functionality support detection engine based on the permission verification logic of the AbilityContext.verifyPermission() method. The permission verification is configured to synchronously and securely verify the permission status of the hardware capabilities that the target component needs to call during the initialization lifecycle phase of the target component. When the security verification result is authorized, the target component is allowed to load and call its hardware driver to execute the full functionality of the target component. When the security verification result is unauthorized, the call to the hardware driver of the target component is canceled, and the target component is displayed in a preset display mode.

[0084] Furthermore, module 304 is specifically used to encapsulate each HarmonyOS component into an independent base package based on the ohpm specification, and to encapsulate the adaptive layout engine and the functional support detection engine into function packages; upload the base packages and function packages to a private repository that supports the ohpm protocol to form the HarmonyOS component library; and build an integration framework for the HarmonyOS component library based on the address of the private repository, wherein the integration framework supports loading HarmonyOS components from the private repository via ohpm commands.

[0085] Furthermore, such as Figure 4 As shown, as a specific implementation of the above-mentioned HarmonyOS component library invocation method, this application embodiment provides a HarmonyOS component library invocation device 400, which includes: a component determination module 401, an invocation module 402, and a display module 403.

[0086] Among them, the component determination module 401 is used to determine the identification information of the target component matched by the application development request in response to the application development request supporting the HarmonyOS system. Module 402 is invoked to retrieve the target component from the HarmonyOS component library based on the target component's identification information. The HarmonyOS component library is packaged from multiple HarmonyOS components defined by standardized component interfaces, an adaptive layout engine, and a functionality support detection engine. The HarmonyOS components declare their dependencies on the adaptive layout engine and the functionality support detection engine in their dependency configurations. In response to the target component's loading instruction, the adaptive layout engine and the functionality support detection engine associated with the target component are triggered through the dependency relationship to optimize the layout and rendering method of the target component based on the terminal device parameters and to determine the functionality availability of the target component. Display module 403 is used to render and display the target component, after functional availability judgment and layout optimization, in the UI interface of the terminal device.

[0087] Furthermore, module 402 is invoked, specifically to create a media query listener through the matchMediaSync interface to obtain the screen state variables of the terminal device; to call the dynamic layout function based on the screen state variables to match the layout style of the terminal device; and to filter the Flex layout parameters bound to the layout style. Among them, the screen state variables include screen width, landscape / portrait status and breakpoint marker, and the layout styles include single-column layout, double-column grid layout and flow layout.

[0088] Furthermore, module 402 is invoked specifically to respond to the target component being in the initialization lifecycle phase by calling the AbilityContext.verifyPermission() method to perform synchronous security verification on the permission status of the hardware capabilities that the target component needs to access; when the security verification result is authorized, the target component is allowed to load and invoke its hardware driver to execute the full functionality of the target component; when the security verification result is unauthorized, the invocation of the target component's hardware driver is canceled. The display module 403 is also used to display the target component in a preset display mode when the security verification result is unauthorized.

[0089] Specific limitations regarding the construction and invocation mechanisms of the HarmonyOS component library can be found in the above descriptions of the construction and invocation methods for the HarmonyOS component library, and will not be repeated here. Each module in the aforementioned construction and invocation mechanisms of the HarmonyOS component library can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device in software form, so that the processor can invoke and execute the corresponding operations of each module.

[0090] Based on the above, Figure 1Accordingly, embodiments of this application also provide a readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described method. Figure 1 and Figure 2 The diagram shows the construction method and calling method of the HarmonyOS component library.

[0091] Based on this understanding, the technical solution of this application can be embodied in the form of a software product. The software product can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, or portable hard drive), and includes several instructions to cause a computer device (such as a personal computer, server, or network device) to execute the methods described in the various implementation scenarios of this application.

[0092] Based on the above, Figure 1 and Figure 2 The method shown, and Figure 3 and Figure 4 The virtual device embodiment shown is designed to achieve the above objectives, such as... Figure 5 As shown in the illustration, this application also provides a computer device 500, which includes a processor 501 and a memory 502. The memory 502 stores a program or instructions that can run on the processor 501. When the program or instructions are executed by the processor 501, they implement the above-described... Figure 1 The diagram shows the construction method and calling method of the HarmonyOS component library.

[0093] The memory 502 can be used to store software programs and various data. The memory 502 may primarily include a first storage area for storing programs or instructions and a second storage area for storing data. The first storage area may store the operating system, application programs or instructions required for at least one function (such as sound playback, image playback, etc.). Furthermore, the memory 502 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct memory bus RAM (DRRAM). The memory 502 in this embodiment includes, but is not limited to, these and any other suitable types of memory.

[0094] Processor 501 may include one or more processing units; optionally, processor 501 integrates an application processor and a modem processor, wherein the application processor mainly handles operations involving the operating system, user interface, and applications, and the modem processor mainly handles wireless communication signals, such as a baseband processor. It is understood that the aforementioned modem processor may also not be integrated into processor 501.

[0095] Computer equipment can specifically include personal computers, servers, network devices, etc.

[0096] Optionally, the computer device may also include a user interface, a network interface, a camera, radio frequency (RF) circuitry, sensors, audio circuitry, a Wi-Fi module, etc. The user interface may include a display screen, input units such as a keyboard, etc., and optional user interfaces may also include USB ports, card reader ports, etc. The network interface may optionally include standard wired interfaces, wireless interfaces (such as Bluetooth interfaces, Wi-Fi interfaces), etc.

[0097] Those skilled in the art will understand that the computer device structure provided in this embodiment does not constitute a limitation on the computer device, and may include more or fewer components, or combine certain components, or have different component arrangements.

[0098] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented using software plus necessary general-purpose hardware platforms, or it can be implemented in hardware to define standardized component interfaces for different types of HarmonyOS components; based on the syntax characteristics of the HarmonyOS system, an adaptive layout engine and a function support detection engine for HarmonyOS components are developed; the dependency relationship on the adaptive layout engine and the function support detection engine is declared in the dependency configuration of the HarmonyOS components; the adaptive layout engine, the function support detection engine, and the HarmonyOS components are packaged to generate a HarmonyOS component library, so that after calling and loading the target component in the HarmonyOS component library, the functional availability of the target component is determined based on the terminal device parameters, and the layout and rendering method of the target component displayed on the terminal device are optimized. In this embodiment of the application, by defining standardized component interfaces for different types of HarmonyOS components, developers can reduce the differences in calling and compatibility issues between components when using components in the HarmonyOS component library, and can quickly call multiple components in the HarmonyOS component library without additional adaptation. Furthermore, the adaptive layout engine and the function support detection engine are encapsulated in the HarmonyOS component library. The adaptive layout engine and the function support detection engine are automatically triggered when a component in the HarmonyOS component library is called. The functional support testing engine verifies the usability of components on terminal devices, avoiding anomalies caused by devices not supporting component functionality and improving system stability. The adaptive layout engine automatically adjusts the layout and display of components based on parameters such as screen size, resolution, and orientation of the terminal device to which the application is developed, resulting in a more consistent presentation across different devices and reducing layout errors or poor interface adaptation. This significantly improves the compatibility, maintainability, and cross-device adaptability of various HarmonyOS components in the HarmonyOS component library. Developers no longer need to invest significant time and manpower in redesigning components; they can directly use components from the HarmonyOS component library to complete HarmonyOS application development tasks with different functions, reducing HarmonyOS application development costs and shortening the development cycle. It addresses the core pain points of existing HarmonyOS application development technologies, such as low efficiency, low component reusability, complex UI adaptation, difficulty in cross-device adaptation, weak distributed capabilities, insufficient performance, and inconsistent design specifications.

[0099] Those skilled in the art will understand that the accompanying drawings are merely schematic diagrams of a preferred embodiment, and the modules or processes shown in the drawings are not necessarily essential for implementing this application. Those skilled in the art will understand that the modules in the apparatus of the embodiment can be distributed within the apparatus of the embodiment as described, or can be modified to be located in one or more apparatuses different from this embodiment. The modules of the above-described embodiment can be combined into one module, or further divided into multiple sub-modules.

[0100] The serial numbers in this application are for descriptive purposes only and do not represent the superiority or inferiority of any particular implementation scenario. The above disclosures are merely a few specific implementation scenarios of this application; however, this application is not limited thereto, and any variations conceived by those skilled in the art should fall within the protection scope of this application.

Claims

1. A method for constructing a HarmonyOS component library, characterized in that, The method includes: Define standardized component interfaces for different types of HarmonyOS components; Based on the syntax features of the HarmonyOS system, an adaptive layout engine and a functional support detection engine for the HarmonyOS components were developed. The dependencies on the adaptive layout engine and the functional support detection engine are declared in the dependency configuration of the HarmonyOS components; The adaptive layout engine, the functional support detection engine, and the HarmonyOS components are packaged into a HarmonyOS component library. After calling and loading the target component in the HarmonyOS component library, the functional availability of the target component is determined based on the terminal device parameters, and the layout and rendering method of the target component displayed on the terminal device are optimized.

2. The method for constructing the HarmonyOS component library according to claim 1, characterized in that, After generating the HarmonyOS component library, the method further includes: Based on the identification information of the HarmonyOS component, obtain the latest version information of the HarmonyOS component from the server; Based on the latest version information and the version information of the HarmonyOS components in the HarmonyOS component library, the components that have new versions and need to be updated are identified. Based on the identification information of the component to be updated, download the upgrade package of the component to be updated from the server; Load the upgrade package to upgrade the HarmonyOS components to the latest version; Update the HarmonyOS components currently stored in the HarmonyOS component library to the latest version of HarmonyOS components.

3. The method for constructing the HarmonyOS component library according to claim 1, characterized in that, The definition of standardized component interfaces for different types of HarmonyOS components includes: A bidirectional communication layer is constructed based on the JavaScript Proxy mechanism, wherein the bidirectional communication layer adopts a unified JSBridge interface format; ArkTS is bridged with the development side by calling the .javaScriptProxy({object:nativeObj,name:"JSBridge"}) method.

4. The method for constructing the HarmonyOS component library according to claim 1, characterized in that, The development of the adaptive layout engine for the HarmonyOS components based on the syntax features of the HarmonyOS system includes: The dynamic layout function defined by the matchMediaSync interface dynamically matches the layout style based on the screen state variables of the terminal device. The layout style is bound to the Flex layout parameters through a reference passing mechanism. The screen state variables include screen width, landscape / portrait status, and breakpoint markers. The layout styles include single-column layout, double-column grid layout, and flow layout.

5. The method for constructing the HarmonyOS component library according to claim 1, characterized in that, The development of the functional support detection engine for HarmonyOS components based on the syntax features of the HarmonyOS system includes: The functionality support detection engine is created based on the permission verification logic of the AbilityContext.verifyPermission() method. The permission verification is configured to synchronously perform security verification on the permission status of the hardware capabilities that the target component needs to call during the initialization lifecycle phase of the target component. When the security verification result is authorized, the target component is allowed to load and call its hardware driver to execute the full functionality of the target component. When the security verification result is unauthorized, the call to the hardware driver of the target component is canceled, and the target component is displayed in a preset display mode.

6. The method for constructing the HarmonyOS component library according to claim 1, characterized in that, The step of packaging the adaptive layout engine, the functional support detection engine, and the HarmonyOS components into a HarmonyOS component library includes: Based on the ohpm specification, each HarmonyOS component is encapsulated as an independent base package, and the adaptive layout engine and the functional support detection engine are encapsulated as functional packages. The base package and the function package are uploaded to a private repository that supports the ohpm protocol to form the HarmonyOS component library; An integration framework for the HarmonyOS component library is built based on the address of the private repository. The integration framework supports loading the HarmonyOS components from the private repository via the ohpm command.

7. A method for calling the HarmonyOS component library, characterized in that, The method includes: In response to an application development request that supports the HarmonyOS system, the identification information of the target component matching the application development request is determined; Based on the identification information of the target component, the target component is obtained from the HarmonyOS component library. The HarmonyOS component library is packaged from multiple HarmonyOS components defined by the standardized component interface, an adaptive layout engine, and a functional support detection engine. The HarmonyOS component declares its dependency relationship with the adaptive layout engine and the functional support detection engine in its dependency configuration. In response to the loading instruction of the target component, the adaptive layout engine and the functional support detection engine associated with the target component are triggered through the dependency relationship, so as to determine the functional availability of the target component based on the terminal device parameters and optimize the layout and rendering method of the target component displayed on the terminal device. The target component, after functional availability assessment and layout optimization, is rendered and displayed in the UI interface of the terminal device.

8. The method for calling the HarmonyOS component library according to claim 7, characterized in that, The optimization of the layout and rendering method of the target component based on terminal device parameters includes: A media query listener is created using the matchMediaSync interface to obtain the screen state variables of the terminal device; The dynamic layout function is called based on the screen state variables to match the layout style of the terminal device; Filter the Flex layout parameters that are bound to the layout style; The screen state variables include screen width, landscape / portrait status, and breakpoint markers, and the layout styles include single-column layout, double-column grid layout, and flow layout.

9. The method for calling the HarmonyOS component library according to claim 7, characterized in that, The step of determining the functional availability of the target component based on terminal device parameters includes: In response to the target component being in the initialization lifecycle phase, the AbilityContext.verifyPermission() method is called to perform synchronous security verification on the permission status of the hardware capabilities that the target component needs to access; When the security verification result indicates that authorization has been granted, the target component is allowed to load and invoke its hardware driver to perform the full functionality of the target component. When the security check result is unauthorized, cancel the invocation of the hardware driver of the target component and display the target component in the preset display mode.

10. A HarmonyOS component library, characterized in that, It is created using the construction method of the HarmonyOS component library as described in claims 1 to 6.

Images