Cross-platform request response method and system

Abstract

The invention discloses a cross-platform request response method and system, and the method comprises the steps: receiving request information through a preset interface, and carrying out the analysis of the request information, so as to recognize the target type of a platform which transmits the request information; a link library file is called based on the target type and the type of the request information so that an application of a platform of the target type can load and call the called link library file, and the link library file is compiled based on a specified interface function and a specified function code of a Rust engine. Core logic is realized through a Rust language and is compiled into native library files of different platforms for being called by platforms such as Android, iOS and Gawan, so that multi-terminal logic unification and intelligent resource management are realized.

Description

Technical Field

[0001] This invention relates to the field of information processing technology, and specifically to a cross-platform request-response method and system. Background Technology

[0002] In mobile application development, especially in scenarios that require support for multiple platforms (Android, iOS, HarmonyOS, etc.), the updating and matching of resource packages faces the following technical challenges: 1) Inconsistent logic across platforms: Existing resource update solutions typically require implementing update logic separately for each platform. This results in: Android using Java / Kotlin to implement one set of logic; iOS using Objective-C / Swift to implement another set; and HarmonyOS using ArkTS to implement a third set. This approach of developing separately for each platform easily leads to inconsistencies in logic, strategies, and behaviors across platforms, increasing maintenance costs and the risk of errors.

[0003] Repetitive development is inefficient. The same resource update and matching functions need to be developed repeatedly on different platforms, which not only wastes development resources, but also increases code maintenance costs, prolongs the launch cycle of new functions, and increases the complexity of bug fixing (it needs to be fixed on multiple platforms separately).

[0004] The issue of resource matching efficiency is that when resources are needed, how to quickly and accurately locate locally downloaded resource files to avoid duplicate downloads and improve loading speed is a problem. Existing solutions lack a unified intelligent matching mechanism.

[0005] Version management presents complex challenges. Resource packages exist in multiple versions. How to manage resources of different versions, how to smoothly transition during updates, and how to ensure resource integrity and security all require a comprehensive solution. Summary of the Invention

[0006] The main objective of this invention is to provide a cross-platform request-response method and system to address the shortcomings of related technologies.

[0007] To achieve the above objectives, according to a first aspect of the present invention, a cross-platform request-response method is provided, comprising: receiving request information through a preset interface; parsing the request information to identify the target type of the platform issuing the request information; and invoking a link library file based on the target type and the type of the request information, so that an application of the target type platform can load and invoke the link library file, wherein the link library file is compiled based on specified interface functions and specified functional code of the Rust engine.

[0008] Optionally, calling the link library file based on the target type and the type of the request information includes: if the application request of the target type platform is of the first type, then calling the first type function to receive the specified parameters passed in through the first type function; calling the first type function based on the specified parameters to execute the resource update process; and returning the update result to the target type platform through a callback function.

[0009] Optionally, based on the target type and the type of the request information, calling different interface functions includes: if the application request of the target type platform is of the second type, then calling the second type function to receive the URL string passed in by the target type platform; after converting the URL string into a new format, calling the resource matching process to obtain the local resource path; and after converting the local resource path into different forms of data, returning it to the target type platform.

[0010] Optionally, when executing the resource update process, the method includes: reading a locally stored version information file, wherein the version information file includes the currently downloaded resource package version and update time; sending a request to the server for the server to detect whether there is a new version of the resource package; if a new version is detected, downloading the resource compressed package, wherein temporary files are stored in the temp folder of the sandbox directory during the download process; calling the file verification module to perform MD5 verification, and decompressing the resource compressed package after the verification passes; after decompression, updating the local patch information file, and cleaning up the old version resource package.

[0011] Optionally, the method during the resource matching process includes: reading the latest resource version number from a locally stored version information file; constructing the complete path of the local file based on the URL string and the resource version number; validating the local file under the complete path, and returning the complete path of the local file if the local file exists and is valid; and returning an empty string if the local file does not exist or is invalid.

[0012] According to a second aspect of the present invention, a cross-platform request-response system is provided, characterized in that it includes: a request acquisition unit, configured to receive request information through a preset interface, parse the request information to identify the target type of the platform that issued the request information; and a processing unit, configured to call a link library file based on the target type and the type of the request information, so that an application of the target type platform can load and call the link library file, wherein the link library file is compiled based on specified interface functions and specified functional code of the Rust engine.

[0013] Optionally, calling the link library file based on the target type and the type of the request information includes: if the application request of the target type platform is of the first type, then calling the first type function to receive the specified parameters passed in through the first type function; calling the first type function based on the specified parameters to execute the resource update process; and returning the update result to the target type platform through a callback function.

[0014] Optionally, calling the link library file based on the target type and the type of the request information includes: if the application request of the target type platform is of the first type, then calling the first type function to receive the specified parameters passed in through the first type function; calling the first type function based on the specified parameters to execute the resource update process; and returning the update result to the target type platform through a callback function.

[0015] According to a third aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing the computer to perform the method described in any one of the first aspects.

[0016] According to a fourth aspect of the present invention, a computer program product is provided, which, when executed by a processor, implements the method described in any implementation of the first aspect.

[0017] This embodiment presents a cross-platform request-response method and system. The method includes receiving request information through a preset interface, parsing the request information to identify the target type of the platform issuing the request information, and calling a link library file based on the target type and the type of the request information, so that applications on the target type platform can load and call the link library file. The link library file is compiled based on specified interface functions and specified functional code of the Rust engine. The core logic is implemented using the Rust language and compiled into native library files for different platforms, allowing calls from platforms such as Android, iOS, and HarmonyOS, thereby achieving unified logic across multiple platforms and intelligent resource management. Attached Figure Description

[0018] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0019] Figure 1 This is a flowchart of a cross-platform request-response method according to an embodiment of the present invention; Detailed Implementation

[0020] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0021] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate for the embodiments of the invention described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

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

[0023] According to embodiments of the present invention, a cross-platform request-response method is provided, such as... Figure 1 As shown, steps 101 to 103 are included below: Step 101: Receive request information through a preset interface, parse the request information to identify the target type of the platform that issued the request information.

[0024] Step 102: Based on the target type and the type of the request information, call the link library file so that the application of the target type platform can load and call the link library file, wherein the link library file is compiled based on the specified interface functions and the specified functional code of the Rust engine.

[0025] In this embodiment, requests from different platform applications, such as Android App, iOS App, and HarmonyOS App, can be obtained through interfaces. To enable the Rust core engine to be called by different platforms, an FFI (Foreign Function Interface) encapsulation is required. This encapsulation allows the Rust core engine to be called by different platforms. The core logic remains completely consistent; only the FFI interface layer is adapted for different platforms.

[0026] This embodiment addresses platform requests that can be resource update requests or resource matching requests. The interface functions are those that initiate the resource update process and those that retrieve the local resource path. After compilation, these two functions generate a link library file (either a dynamic link library file or a static link library file) for use by applications on different platforms.

[0027] As an optional implementation of this embodiment, calling the link library file based on the target type and the type of the request information includes: if the application request of the target type platform is of the first type, then calling the first type function, and receiving the specified parameters passed in through the first type function; calling the first type function based on the specified parameters to execute the resource update process; and returning the update result to the target type platform through a callback function.

[0028] In this optional implementation, the Android platform's interface encapsulation uses JNI technology. Specifically, two publicly exposed C-style interface functions are defined. The resource update process function initiates the resource update process. This function receives environment parameters, class references, and a callback object from the Java layer as input parameters. Internally, it calls the update logic of the Rust core engine. After execution, the result is returned to the Java layer via the callback object, with the return value being an integer status code.

[0029] The iOS platform's interface encapsulation uses standard C language interfaces. Specifically, it defines two publicly accessible C language interface functions. The resource update process function initiates the resource update, accepting a function pointer as a callback parameter. This callback function accepts an integer status code and a string pointer as parameters. Internally, the function calls the Rust core update logic. After execution, it passes the result to the iOS layer via the callback function, returning an integer execution status.

[0030] The HarmonyOS platform's interface encapsulation is implemented using NAPI (Native API) technology. Specifically, it defines two interface functions that conform to the NAPI specification. The resource update process function is used to initiate resource updates, receiving a NAPI environment object and a callback function object as parameters. Internally, the function calls the Rust core update logic, and after execution, it encapsulates the result into a NAPI value type and returns it to the ArkTS layer.

[0031] As an optional implementation of this embodiment, calling different interface functions based on the target type and the type of the request information includes: if the application request of the target type platform is of the second type, then calling the second type function to receive the URL string passed in by the target type platform; after converting the URL string into a different format, calling the resource matching process to obtain the local resource path; and after converting the local resource path into different forms of data, returning it to the target type platform. In this optional implementation, the function for obtaining the local resource path on the Android platform receives the URL string parameter passed from the Java layer, first converts the Java string into a Rust-processable string format, then calls the resource matching logic to obtain the corresponding local file path, and finally converts the path back into a Java string format and returns it to the caller.

[0032] For the Android platform, the function is compiled to generate a dynamic link library file libresource_engine.so for Android applications to call.

[0033] For the iOS platform, the function to retrieve the resource path accepts a C pointer to a URL string as an argument. The function first converts the C string pointer to a Rust string type, then calls the resource matching logic to obtain the local path, and finally converts the result back to a C string pointer.

[0034] These two functions are compiled for the iOS platform to generate a static link library file libresource_engine.a, which can be used by iOS applications for linking.

[0035] For the HarmonyOS platform, the function to obtain the resource path receives a NAPI environment object and a URL value object as parameters. The function first parses the URL parameter passed from ArkTS, then calls the Rust core matching logic to obtain the local path, and finally encapsulates the path as a NAPI value type and returns it. For the HarmonyOS platform, these two functions are compiled to generate a dynamic link library file libresource_engine.so for HarmonyOS applications to call.

[0036] As an optional implementation of this embodiment, the method for executing the resource update process includes: reading a locally stored version information file, wherein the version information file includes the currently downloaded resource package version and update time; sending a request to the server for the server to detect whether there is a new version of the resource package; if a new version is detected, downloading the resource compressed package, wherein temporary files are stored in the temp folder of the sandbox directory during the download process; calling the file verification module to perform MD5 verification, and decompressing the resource compressed package after the verification passes; after decompression, updating the local patch information file and cleaning up the old version resource package.

[0037] In this optional implementation, when the application starts, each platform performs intelligent detection and download updates by calling the start interface provided by Rust artifacts.

[0038] For example, resource updates include: Step 1.1: Version Check. The Rust core engine first reads the locally stored version information file (version.json), which records information such as the version number and update time of the currently downloaded resource packages. Example file structure: { "version":"1.0.5", "update_time":"2025-10-20T10:30:00Z", "md5":"a1b2c3d4e5f6..." } Step 1.2: Server Request The engine sends an HTTP / HTTPS request to the server, carrying parameters such as the current version number, platform information, and device ID.

[0039] Step 1.3: Download Management If a new version is detected, the engine begins downloading the resource archive. During the download process, temporary files are stored in the temp folder in the sandbox directory, with the filename {version number}.zip.tmp.

[0040] Step 1.4: File Verification After downloading, immediately perform an MD5 checksum to ensure file integrity and security.

[0041] The MD5 verification function is implemented as follows: A file verification function is defined, which accepts two parameters: the file path and the expected MD5 value. When the function executes, it first calculates the actual MD5 value of the downloaded file, and then compares the calculated MD5 value with the expected MD5 value provided by the server. If the two values ​​match exactly, the verification passes and a true value is returned; otherwise, the verification fails, a false value is returned, and the system deletes the file and decides whether to re-download it based on the retry policy. If the verification fails, the downloaded file is deleted, and the retry policy determines whether to re-download it.

[0042] Step 1.5: Intelligent decompression After the MD5 checksum passes, begin decompressing the file. The decompression strategy is as follows: Extract the compressed files according to their directory structure and categorize them by domain name. Target directory structure: sandbox directory / {version number} / {domain name} / resource files Retain the old version resources until the new version is completely decompressed.

[0043] Step 1.6: Version Management After decompression, update the local version information file and clean up old version resources. The strategy is to keep the resources of the two most recent versions and delete the version.json file of earlier versions.

[0044] As an optional implementation of this embodiment, the method for executing the resource matching process includes: reading the latest resource version number from the locally stored version information file; constructing the complete path of the local file based on the URL string and the resource version number; validating the local file under the complete path, and if the local file exists and is valid, returning the complete path of the local file; if the local file does not exist or is invalid, returning an empty string.

[0045] In this optional implementation, regarding the intelligent resource matching process, when resources need to be loaded, each platform performs intelligent matching by calling the get interface provided by Rust artifacts.

[0046] For example, step 2.1 is included: URL parsing. When retrieving a resource, the complete URL is passed in, such as: https: / / cdn.example.com / images / banner / home.png. The Rust engine parses the URL and extracts key information: domain name: cdn.example.com, resource path: / images / banner / home.png, file name: home.png.

[0047] Step 2.2: Version location. The engine reads the version.json file and obtains the latest resource version number, such as 1.0.6.

[0048] Step 2.3: Path Construction. Based on the version number, domain name, and resource path, construct the complete path to the local file, for example: / sandbox / resources / 1.0.6 / cdn.example.com / images / banner / home.png Step 2.4: File verification. Before returning the path, perform file validity verification to check if the file exists and if the file size is greater than 0.

[0049] Step 2.5: Return the result. If the file exists and is valid, return the local file path, for example: file: / / / sandbox / resources / 1.0.6 / cdn.example.com / images / banner / home.png. If the file does not exist or is invalid, return an empty string.

[0050] In the above implementation, the core module involves an update detection module, which implements the function of checking for updates. The execution process consists of four steps: first, constructing an HTTP request based on parameters such as the current version number and platform information; second, sending the request to the server; third, receiving and parsing the response data returned by the server; and finally, encapsulating the parsed update information into a result object and returning it. If any step fails, the error information is passed to the upper layer through an error handling mechanism.

[0051] The download management module implements a download function with a retry mechanism, accepting two parameters: the resource URL and the expected MD5 value. The execution flow employs a loop-based retry mechanism: in each loop, it first attempts to download the file to a temporary directory; upon successful download, it immediately performs an MD5 checksum verification; if the verification passes, it returns the file path; if the download or verification fails, it increments the retry count; when the maximum number of retries is reached, it returns an error message; otherwise, it continues to the next retry. The specific implementation of the download attempt involves: creating an HTTP connection, setting a timeout parameter, receiving the data stream and writing it to a temporary file, and returning the file path upon completion of the download.

[0052] The resource matching module implements resource matching methods. It receives the complete resource URL as a parameter and returns the local file path or an empty value. The execution flow consists of five steps: parsing the input URL to extract the domain name and resource path; obtaining the latest resource version number through the version manager; constructing the complete local file path based on the version number, domain name, and resource path according to predetermined rules; verifying that the file corresponding to the path exists and is valid (file size greater than zero); if the file is valid, adding the "file: / / " protocol header to the path and returning the result; otherwise, returning an empty value, indicating that the resource does not exist locally.

[0053] The version management module implements two core functional methods: The first method retrieves the latest version number. Its execution flow is as follows: it reads and parses the version configuration file, extracts the latest version number string, and returns it; if the read fails, it returns an empty value. The second method updates version information, receiving the new version number as a parameter. Its execution flow consists of two steps: first, it writes the new version number to the configuration file, updating the version record; then, it calls the internal method for cleaning up old versions, deleting expired resources. The specific implementation of cleaning up old versions is as follows: it lists all version folders in the resource directory, sorts them by time, retains the most recent specified number of versions (e.g., retain the most recent 2 versions), and completely deletes the earlier version folders and all their contained files, freeing up storage space.

[0054] The advantages of this embodiment are as follows: (1) Completely unified logic across multiple platforms: Traditional solutions require implementing resource update logic separately on each platform, which can easily lead to inconsistencies. This invention implements the core engine using Rust and compiles it into native libraries for different platforms, ensuring that the logic and behavior are completely consistent across platforms such as Android, iOS, and HarmonyOS. The advantage lies in eliminating bugs caused by differences in behavior across multiple platforms, and strategy adjustments only require modifying one piece of code, reducing testing costs and requiring only one set of logic to be tested.

[0055] (2) Significantly reduces redundant development: In traditional solutions, the same functionality needs to be implemented three times each in Java / Kotlin, Objective-C / Swift, and ArkTS. This invention only requires implementing Rust code once, which can then be used on all platforms. The advantages are reflected in an approximately 60% increase in development efficiency, an approximately 70% reduction in code maintenance costs, and an approximately 50% shortening of the new feature launch cycle. (3) Higher security and reliability: Rust's memory safety features and strong typing system greatly reduce the risk of crashes.

[0056] (4) Enhanced scalability: Based on modular design, it is easy to expand with new functions. The advantages are reflected in the ease of adding support for new platforms (such as Web and desktop); scalable support for more resource types; and integration of more download strategies (such as P2P download). (5) Significant performance advantages: Rust is compiled into native machine code, and its performance is close to that of C / C++.

[0057] a) Resource matching time is less than 1ms b. Low memory usage, approximately 50% of that of Java implementations. c. Low CPU usage, does not affect main thread performance (6) Significantly reduced maintenance costs: A unified codebase and logic reduce overall costs. The advantages are as follows: a. Bug fixes only need to be done once, and changes are synchronized to all platforms. b. Reduced training costs for new employees; only one set of code needs to be learned. c. Reduced document maintenance costs; only one document needs to be maintained. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0058] According to an embodiment of the present invention, a cross-platform request-response system is also provided, including a request acquisition unit, configured to receive request information through a preset interface, parse the request information to identify the target type of the platform that issued the request information; and a processing unit, configured to call a link library file based on the target type and the type of the request information, so that the application of the target type platform can load and call the link library file, wherein the link library file is compiled based on specified interface functions and specified functional code of the Rust engine.

[0059] According to embodiments of the present invention, the present invention also provides an electronic device, the electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to implement the methods described in any of the above embodiments.

[0060] According to embodiments of the present invention, the present invention also provides a readable storage medium storing computer instructions that enable a computer to perform the methods described in any of the above embodiments when executed.

[0061] According to embodiments of the present invention, the present invention also provides a computer program product that, when executed by a processor, can implement the methods described in any of the above embodiments.

[0062] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0063] The program code used to implement the methods of the present invention can be written in any combination of one or more programming languages. This program code can be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code can be executed entirely on the machine, partially on the machine, as a standalone software package partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0064] In the context of this invention, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can include, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

Claims

1. A cross-platform request-response method, characterized in that, include: The system receives request information through a preset interface and parses the request information to identify the target type of the platform that issued the request information. The link library file is invoked based on the target type and the type of the request information, so that the application of the target type platform can load and invoke the link library file. The link library file is compiled based on the specified interface functions and the specified functional code of the Rust engine.

2. The cross-platform request-response method according to claim 1, characterized in that, The library file invoked based on the target type and the type of the request information includes: If the application request on the target platform is of type 1, then the type 1 function is called to receive the specified parameters passed in; based on the specified parameters, the type 1 function is called to execute the resource update process; and the update result is returned to the target platform through a callback function.

3. The cross-platform request-response method according to claim 2, characterized in that, Based on the target type and the type of the request information, calling different interface functions includes: If the application request of the target type platform is of the second type, then calling the second type function to receive the URL string passed in by the target type platform; after converting the URL string into a new format, calling the resource matching process to obtain the local resource path; and after converting the local resource path into different forms of data, returning it to the target type platform.

4. The cross-platform request-response method according to claim 2, characterized in that, When executing the resource update process, the methods include: Read the version information file stored locally, wherein the version information file includes the version of the currently downloaded resource package and the update time; send a request to the server so that the server can detect whether there is a new version of the resource package; if a new version is detected, download the resource package, wherein temporary files are stored in the temp folder of the sandbox directory during the download process; The file verification module is invoked to perform MD5 verification, and the resource package is decompressed after the verification is successful. After decompression, the local blog information file is updated and the old version of the resource package is cleaned up.

5. The cross-platform request-response method according to claim 3, characterized in that, The methods used when executing the resource matching process include: Read the latest resource version number from the locally stored version information file; Construct the complete path of the local file based on the URL string and the resource version number; This function validates the local file at the full path. If the local file exists and is valid, it returns the full path of the local file; otherwise, it returns an empty string.

6. A cross-platform request-response system, characterized in that, include: The request acquisition unit is used to receive request information through a preset interface, parse the request information to identify the target type of the platform that issued the request information; The processing unit is configured to invoke a link library file based on the target type and the type of the request information, so that the application of the target type platform can load and invoke the link library file, wherein the link library file is compiled based on specified interface functions and specified functional code of the Rust engine.

7. The cross-platform request-response system according to claim 6, characterized in that, The library file invoked based on the target type and the type of the request information includes: If the application request on the target platform is of type 1, then the type 1 function is called to receive the specified parameters passed in; based on the specified parameters, the type 1 function is called to execute the resource update process; and the update result is returned to the target platform through a callback function.

8. The cross-platform request-response system according to claim 7, characterized in that, The library file invoked based on the target type and the type of the request information includes: If the application request on the target platform is of type 1, then the type 1 function is called to receive the specified parameters passed in; based on the specified parameters, the type 1 function is called to execute the resource update process; and the update result is returned to the target platform through a callback function.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to perform the method according to any one of claims 1-5.

10. A computer program product, characterized in that, When executed by a processor, the computer program implements the method described in any one of claims 1-5.

Images