Network communication efficient processing scheme for open-source wide-gap application
By using a queue data structure to process network data, the compatibility and efficiency issues of network communication in the open-source HarmonyOS system were resolved, enabling efficient processing on different versions of the system and improving system performance and stability.
Patent Information
- Application Number
- CN202510998542.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-07-21
- Publication Date
- 2025-11-21
AI Technical Summary
The open-source HarmonyOS system suffers from poor compatibility and high development difficulty in network communication, especially on different versions of the system, which leads to increased development costs and time.
A queue data structure is used to process network data. By defining data processing flags and time variables, data is processed in categories to ensure that data is processed sequentially, avoiding system lag and improving processing efficiency and compatibility.
It enables efficient network communication processing on different versions of the open-source HarmonyOS system, reduces system lag, improves system performance and stability, and lowers development and maintenance costs.
Smart Images

Figure CN120994418A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of data processing, and in particular relates to an efficient network communication processing solution for open-source HarmonyOS applications. Background Technology
[0002] In today's mobile application development field, the open-source HarmonyOS system, with its unique distributed architecture and the concept of the Internet of Things, has demonstrated enormous development potential. However, in the process of developing applications using open-source HarmonyOS, there are many challenges that urgently need to be addressed, especially when applications communicate with the platform over the network, making the design of an efficient and highly compatible solution particularly crucial.
[0003] From the perspective of ecosystem and system performance, the open-source HarmonyOS ecosystem is still in its development stage and lags behind the mature Android ecosystem. In terms of system smoothness, open-source HarmonyOS currently falls short of Android, which has undergone long-term optimization and widespread application validation. This situation, to some extent, affects the user experience of open-source HarmonyOS applications and places higher demands on application development.
[0004] From the perspective of development language and API system, open-source HarmonyOS application development is largely based on TypeScript (TS). Unlike mature Android development languages such as Java and Kotlin, the application of TS in open-source HarmonyOS development faces the problem of an unstable API system. The HarmonyOS API is in a state of continuous iteration and has not yet formed a complete and stable API system like Android development languages. This makes it difficult for developers to rely on stable interfaces for efficient development when developing network communication functions, increasing the difficulty and uncertainty of development.
[0005] Regarding compatibility, although the open-source HarmonyOS system is constantly being updated and evolved, it is worth noting that its basic APIs possess relative stability. Based on this characteristic, using basic data structures to process network communication data can effectively reduce the impact of system version updates on communication functions. By leveraging the universality and stability of basic data structures, it is possible to ensure that network communication functions maintain a relatively stable operating state across different versions of the open-source HarmonyOS system.
[0006] Furthermore, there are multiple solutions for the open-source HarmonyOS, and these solutions use different versions of the open-source software. This version inconsistency poses a significant challenge to the compatibility of the core code. If the network communication solutions are not compatible, developers may need to perform a large amount of redevelopment work when dealing with different versions of the open-source HarmonyOS system, which will undoubtedly increase development costs and time.
[0007] In summary, the diversity of open-source HarmonyOS versions and the continuous evolution of its APIs make the network communication solution between open-source HarmonyOS applications and the platform crucial to the entire application process. The compatibility and efficiency of this solution directly affect the application's performance, stability, and development and maintenance costs. Based on these considerations, this invention employs a queue data structure to implement the network communication solution between open-source HarmonyOS applications and the platform, aiming to effectively solve the aforementioned compatibility and efficiency issues and provide a practical solution for open-source HarmonyOS application development. Summary of the Invention
[0008] The purpose of this invention is to provide an efficient network communication processing solution for open-source HarmonyOS applications, aiming to solve the problems mentioned in the background art.
[0009] This invention is implemented as follows: a high-efficiency network communication processing solution for open-source HarmonyOS applications, the solution comprising the following steps:
[0010] S1. Define a data processing flag to determine if processing is in progress; define a processing time variable.
[0011] S2. Define the network data reception method;
[0012] S3. Add the received data to the Queue using the add method;
[0013] S4. Determine the flag bit; if it indicates that no data is being processed or the processing timeout has occurred, proceed with data processing.
[0014] S5. Determine the queue length. If the queue is not empty, proceed with data processing; otherwise, processing is complete.
[0015] S6. Data Processing: Call the pop method of Queue to retrieve and remove the data at the head of the queue, and record the start time of processing;
[0016] S7. Report the processing results and define the data processing flag as unprocessed;
[0017] S8. Switch to S5.
[0018] As a further aspect of the present invention, the definition of a data processing flag bit to determine whether processing is in progress; the definition of a processing time variable specifically includes:
[0019] Define a Boolean data processing flag to explicitly indicate whether the system is currently performing data processing operations; at the same time, define an integer processing time variable to record the specific time when data processing started.
[0020] As a further aspect of the present invention, the step of adding the received data to the Queue using the add method specifically includes:
[0021] The received network data is categorized and processed according to its processing time. For relatively time-consuming data, the add method is called to add it to the Queue data structure; while for relatively time-efficient data, it is not added to the queue.
[0022] As a further aspect of the present invention, the determination flag bit, which initiates data processing when it is not processing data or when processing times out, specifically includes:
[0023] The data processing flag is checked in real time. If the flag indicates that the data is not currently being processed, the process proceeds directly to step S5. If the flag indicates that data processing is in progress and the processing has not been completed within the specified time since the start of data processing, the process is deemed to be abnormal and the process proceeds to step S5.
[0024] As a further aspect of the present invention, the step of determining the queue length, and proceeding to data processing if the queue is not empty, and completing processing if the queue is empty, specifically includes:
[0025] The length of the queue is checked. If the queue is not empty, it means that there is still data to be processed in the queue, so proceed to step S6; if the queue is empty, it means that all data has been processed and the entire data processing process ends.
[0026] As a further aspect of the present invention, the data processing includes: calling the pop method of Queue to retrieve and remove the data at the head of the queue, and recording the start time of processing.
[0027] The system retrieves data from the queue for actual processing. Specifically, it calls the `pop` method of the `Queue` to retrieve the data at the head of the queue. After retrieving the data, it records the time when the data processing started and marks the data processing flag as being processed, indicating that the system is currently processing the data.
[0028] As a further aspect of the present invention, the reporting of the processing result, specifically defining the data processing flag as unprocessed, includes:
[0029] After completing the data processing operation, the processing result is reported to the platform, and the data processing flag is redefined as the unprocessed state.
[0030] As a further aspect of the present invention, step S5 specifically includes:
[0031] After processing the current data, the program proceeds to step S5 to continue checking the status of the queue. If there is still data in the queue, the process continues as described above until the queue is empty, thus achieving cyclic processing of all data in the queue.
[0032] The present invention provides a high-efficiency network communication processing solution for open-source HarmonyOS applications. After the above process, even if the amount of data communicating with the platform is large and the device takes a long time to process the data, it can be processed efficiently and has good compatibility, and can be adapted to most versions of the open-source HarmonyOS system. Attached Figure Description
[0033] Figure 1 This is the main flowchart of a high-efficiency network communication processing solution for open-source HarmonyOS applications.
[0034] Figure 2 This is a schematic diagram of a high-efficiency network communication processing solution for open-source HarmonyOS applications. Detailed Implementation
[0035] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.
[0036] The specific implementation of the present invention will be described in detail below with reference to specific embodiments.
[0037] This invention provides an efficient network communication processing solution for open-source HarmonyOS applications, which solves the technical problems in the background.
[0038] like Figure 1 and Figure 2 The diagram shown is a main flowchart and structural schematic of an efficient network communication processing solution for open-source HarmonyOS applications, provided by an embodiment of the present invention. The efficient network communication processing solution for open-source HarmonyOS applications includes:
[0039] Step S1. Define a Boolean data processing flag to explicitly indicate whether the system is currently performing data processing. Simultaneously, define an integer processing time variable to record the specific time data processing began. The definitions of these two variables provide crucial status indicators and time references for subsequent data processing flows.
[0040] Step S2. Define a dedicated network data receiving method, which has the function of receiving network data. Through this method, the system can obtain network data from the platform in a timely and accurate manner, preparing for subsequent data processing.
[0041] Step S3. Classify the received network data according to its processing time. For relatively time-consuming data, call the add method to put it into a Queue data structure; while for data that is basically instantaneous, it can be left out of the queue to improve processing efficiency. This classification method can reasonably arrange the data according to its actual characteristics and optimize the data processing flow.
[0042] Step S4. Real-time judgment of the data processing flag. If the flag indicates that data processing is not currently in progress, proceed directly to step S5; if the flag indicates that data processing is in progress, and the processing operation has not been completed within 2 seconds (this time interval can be flexibly defined according to specific business needs) from the start time of data processing, it is determined that an anomaly has occurred in this processing process, and the process also proceeds to step S5. Through this judgment mechanism, anomalies in the data processing process can be detected in a timely manner, and corresponding handling measures can be taken.
[0043] Step S5. Check the length of the queue. If the queue is not empty, it means there is still data to be processed in the queue, then proceed to step S6; if the queue is empty, it means that all data has been processed and the entire data processing flow ends.
[0044] Step S6. Retrieve the data to be processed from the queue for actual processing. Specifically, call the `pop` method of `Queue` (in this invention, only this method is allowed because it not only retrieves the data at the head of the queue but also removes it from the queue, ensuring the consistency of data processing order and queue state) to retrieve the data at the head of the queue. After retrieving the data, record the time when data processing begins and mark the data processing flag as being processed, indicating that the system is currently processing the data.
[0045] Step S7. After completing the data processing operation, report the processing results to the platform. At the same time, redefine the data processing flag as an unprocessed state to prepare for the next round of data processing.
[0046] Step S8. After processing the current data, the program proceeds to step S5 to continue checking the queue's status. If there is still data in the queue, the process continues as described above until the queue is empty, thus achieving cyclic processing of all data in the queue.
[0047] This invention processes data acquired from the platform by adding it to a queue, strictly adhering to the order in which the data arrives. During processing, one data item is processed before the next, and the platform is promptly notified of the processing result. This ordered, cyclical processing method effectively avoids system lag and slow data communication caused by processing too much data simultaneously during communication with the platform, ensuring smooth and efficient data processing. Furthermore, processing data sequentially better guarantees data integrity, reduces the need for platform data retransmission, and further improves the overall performance and stability of the system.
[0048] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.
[0049] The embodiments described above are merely illustrative of several implementations of the present invention, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these modifications and improvements all fall within the scope of protection of the present invention. Therefore, the scope of protection of this patent should be determined by the appended claims.
[0050] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.
Claims
1. An efficient network communication processing scheme for open-source HOMER applications, characterized in that, It comprises the following steps: S1. defining a data processing flag to determine whether it is being processed; defining a processing time variable; S2. defining a network data receiving method; S3. placing the received data into Queue through the add method; S4. judging the flag, and entering data processing when it is not processing data or processing timeout; S5. judging the queue length, and entering data processing when the queue is not empty, or finishing processing when the queue is empty; S6. data processing: calling the pop method of Queue to take out and remove the head data, and recording the start processing time; S7. reporting the processing result, and defining the data processing flag as not processed; S8. returning to S5.
2. The network communication efficient processing scheme for open source HOMER application according to claim 1, characterized in that, The definition of the data processing flag to determine whether it is being processed; The definition of the processing time variable specifically comprises: Defining a Boolean type data processing flag, which is used to clearly indicate whether the current system is performing data processing operation; at the same time, defining an integer type processing time variable to record the specific time when data processing starts.
3. The network communication efficient processing scheme for open source micro-mesh application according to claim 1, characterized in that, The placing of the received data into Queue through the add method specifically comprises: Classifying the received network data according to its processing time consumption; for relatively time-consuming data, calling the add method to place it into the Queue queue data structure; while for relatively low time-consuming data, it is selected not to be placed into the queue.
4. The network communication efficient processing scheme for open source micro-mesh applications according to claim 1, characterized in that, The judgment of the flag, when it is not processing data or processing timeout, entering data processing specifically comprises: Real-time judgment of the data processing flag; if the flag shows that the current is not in the data processing state, directly enter step S5; if the flag shows that the data processing is being performed, and from the data processing start time, it is calculated that the processing operation has not been completed for more than the specified time, it is determined that the processing process is abnormal, and step S5 is also entered.
5. The network communication efficient processing scheme for open source micro-mesh application according to claim 1, characterized in that, The judgment of the queue length, if the queue is not empty, entering data processing, or empty, finishing processing specifically comprises: Checking the length of the queue, if the queue is not empty, indicating that there is still data to be processed in the queue, then enter step S6; if the queue is empty, it means that all data has been processed, and the whole data processing process is ended.
6. The network communication efficient processing scheme for open source micro-mesh application according to claim 1, characterized in that, The data processing: calling the pop method of Queue to take out and remove the head data, and recording the start processing time specifically comprises: Taking out the data to be processed from the queue for actual processing, the specific operation is to call the pop method of Queue to take out the head data; after taking out the data, record the start processing time of the data, and mark the data processing flag as being processed, to indicate that the system is currently processing the data.
7. The network communication efficient processing scheme for open source The reporting of the processing result, and defining the data processing flag as not processed specifically comprises: After completing the data processing operation, report the processing result to the platform, and redefine the data processing flag as not processed state.
8. The network communication efficient processing scheme for open source The returning to S5 specifically comprises: After processing the current data, the program returns to step S5 to continue checking the state of the queue; if there is still data in the queue, continue processing according to the above process until the queue is empty, so as to realize the circular processing of all data in the queue.