Message pushing method, device and equipment based on swan ecology and medium

Abstract

The invention provides a message pushing method, device and equipment based on the Qingmong ecology and a medium, and the method comprises the steps: generating a unique registration identifier through receiving an equipment registration request, and associating and storing a push token of a Qingmong system; establishing a bidirectional mapping relationship between the registration identifier and the tag and the alias; generating a push task according to the external task request and distributing a unique identifier; determining a target user set from the mapping relation based on the screening parameters; different gap service interface structures are adapted, and push messages are submitted; and finally recording whole-process data and carrying out statistical analysis. The method has the beneficial effects that through unified process management, the problems of complex interface, difficulty in multi-channel adaptation and weak push effect analysis of a docking gap system in the prior art are solved, the development and maintenance cost is remarkably reduced, and meanwhile, a reliable basis is provided for push effect evaluation and operation optimization through full-process data tracking.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of message pushing, in particular to a message pushing method and device based on a Hongmeng ecology, equipment and medium. BACKGROUND

[0002] With the rapid development and popularity of the Hongmeng operating system, its application ecology is growing, and the industry's demand for message pushing based on the Hongmeng system is becoming increasingly strong. As an important channel for application programs and users to maintain interaction and deliver key information, the convenience of its implementation and the completeness of its functions directly affect the development efficiency and user experience. Therefore, providing a set of efficient and reliable message pushing solutions for the Hongmeng system has become an urgent technical need in the field.

[0003] However, in the practice of pushing the Hongmeng system, developers face many technical challenges. First, the Hongmeng system itself is still in the rapid iteration stage of development, and the function definition and interface specification of its pushing service may change, which forces developers to continuously invest a lot of effort in interface adaptation and system maintenance, with high development costs. Second, in addition to the pushing service of the Hongmeng system, there are also other pushing channels provided by multiple manufacturers in the market. These channels have different interfaces and functions, and lack a relatively unified calling standard, making it extremely difficult for developers to implement multi-channel adaptation for extensive coverage, and it is difficult to achieve coordinated work and unified management between multiple channels.

[0004] In addition, existing pushing solutions, including the services provided by the Hongmeng system and other manufacturers, generally have weak statistical analysis capabilities. Their analysis logic is relatively simple, and they can usually only provide basic delivery rate statistics, but cannot perform in-depth analysis of the complete life cycle of message pushing (such as user clicks and conversion paths), and it is also difficult to locate the loss in each link of the pushing process. This makes it difficult for operators to accurately assess the actual effect of pushing activities, so they cannot provide effective data support for optimizing operational strategies, ultimately affecting the overall operational effect. Therefore, there is an urgent need in the field for a message pushing solution that can uniformly interface with the Hongmeng ecology, simplify the development process, and provide deep analysis capabilities. SUMMARY

[0005] The technical problem to be solved by the present application is how to provide a unified, efficient and analyzable pushing solution to reduce the technical complexity and cost of developers interfacing and adapting to the Hongmeng system and its multiple pushing channels.

[0006] To solve the above technical problems, the technical solution adopted by the present application is: a message pushing method based on a Hongmeng ecology, comprising: Receive a registration request from a terminal device, parse the registration request to obtain the device's unique identifier information, and generate a unique registration identifier within the system; Receive and associate the HarmonyOS push token reported by the terminal device with the unique registration identifier within the system, and persistently store it; Provide an interface to receive tag and / or alias information set for the unique registration identifier, and establish a bidirectional mapping relationship between the unique registration identifier and the tag and / or alias; Receive push task requests from external input, generate push tasks containing message content and target filtering parameters according to the requests, assign a unique task identifier to the push task, and then distribute it to the message queue. The push task is obtained from the message queue, and a set of target registration identifiers that meet the conditions is selected based on the target filtering parameters, combined with the bidirectional mapping relationship and the stored registration identifier information. Based on the target registration identifier set, obtain the associated HarmonyOS push token, construct a message that conforms to the HarmonyOS push service interface specification, and submit the message to the HarmonyOS push service to complete the final delivery to the terminal device; The system records the unique task identifier, the set of target registration identifiers, and the status and result of submitting the request to the HarmonyOS push service. It also performs statistical analysis on the recorded information to generate a push effect report.

[0007] Furthermore, the step of receiving a registration request from a terminal device, parsing the registration request to obtain the device's unique identifier information, and generating a unique registration identifier within the system specifically includes: Receive registration requests from terminal devices via a TCP interface based on a custom encryption protocol; Parse the device unique identifier information in the registration request; A unique registration identifier is generated within the system based on the parsed information; The correspondence between the unique registration identifier and the unique device identifier is stored in a relational database.

[0008] Furthermore, the step of receiving and associating the HarmonyOS push token reported by the terminal device with the unique registration identifier within the system, and persistently storing it, specifically includes: Receive HarmonyOS push tokens reported by the terminal device via TCP interface; Associate the HarmonyOS push token with the unique registration identifier within the system; The relationships are persisted to both a relational database and an in-memory database.

[0009] Furthermore, establishing a bidirectional mapping relationship between the unique registration identifier and the tag and / or alias specifically includes: Establish a one-way, one-to-one mapping relationship from the unique registration identifier to the tag and / or alias; Establish a one-way one-to-many mapping relationship from the tags and / or aliases to the unique registration identifiers, wherein for each tag or alias, maintain a set containing all unique registration identifiers associated with it.

[0010] Furthermore, based on the target filtering parameters, combined with the bidirectional mapping relationship and the stored registration identifier information, a set of target registration identifiers that meet the conditions is filtered out. The target filtering parameters include at least one of the following: a specified list of specific registration identifiers, a logical combination condition based on tags, or a condition based on aliases.

[0011] Furthermore, constructing a message that conforms to the HarmonyOS push service interface specification and submitting the message to the HarmonyOS push service specifically includes: Identify the HarmonyOS push service provider or version corresponding to the target terminal device; After converting the unified message content into the specific message format required by the manufacturer or version, it is then submitted to the corresponding HarmonyOS push service interface.

[0012] Furthermore, the statistical analysis of the recorded information to generate a push notification performance report specifically includes: Based on the number of the target registration identifier set and the number of registration identifiers associated with successfully submitting a request to the HarmonyOS push service, the delivery rate at each stage is calculated, and the message push loss path is analyzed to locate user churn at each stage from task creation to final delivery.

[0013] This invention also provides a message push device based on the HarmonyOS ecosystem, comprising: The registration service module is used to receive registration requests from terminal devices, parse the registration requests to obtain the device's unique identifier information, and generate a unique registration identifier within the system. The token management module is used to receive and associate the HarmonyOS push token reported by the terminal device with the unique registration identifier inside the system, and to persistently store it. The tag and alias management module is used to provide an interface to receive tag and / or alias information set for the unique registration identifier, and to establish a bidirectional mapping relationship between the unique registration identifier and the tag and / or alias; The push task creation module is used to receive push task requests from external input, generate push tasks containing message content and target filtering parameters according to the request, assign a unique task identifier to the push task, and then distribute it to the message queue. The target user filtering module is used to obtain the push task from the message queue, and based on the target filtering parameters, combined with the bidirectional mapping relationship and the stored registration identifier information, filter out a set of target registration identifiers that meet the conditions. The message delivery module is used to obtain the HarmonyOS push token associated with the target registration identifier set, construct a message that conforms to the HarmonyOS push service interface specification, and submit the message to the HarmonyOS push service to complete the final delivery to the terminal device. The push result analysis module is used to record the unique task identifier, the target registration identifier set, and the status and result of the request submitted to the HarmonyOS push service, and to perform statistical analysis on the recorded information to generate a push effect report.

[0014] The present invention also provides a computer device, the computer device including a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the message push method based on the HarmonyOS ecosystem as described above.

[0015] The present invention also provides a storage medium storing a computer program, which, when executed by a processor, can implement the message push method based on the HarmonyOS ecosystem as described above.

[0016] The beneficial effects of this invention are as follows: By integrating device registration, token association, user tagging management, task scheduling, precise target filtering, multi-channel adaptation and delivery, and result analysis into a coherent method, developers do not need to worry about the differences in underlying interfaces and adaptation details. They can complete all operations from push creation to effect analysis simply by calling a unified service, which significantly reduces development complexity and maintenance costs. At the same time, by establishing a data association and recording mechanism throughout the process, a quantifiable and traceable analytical basis is provided for key indicators such as message push delivery rate and user attrition path, thereby effectively improving the accuracy and sustainable optimization capabilities of push operations. Attached Figure Description

[0017] The specific structure of the present invention will now be described in detail with reference to the accompanying drawings.

[0018] Figure 1 This is a flowchart of a message push method based on the HarmonyOS ecosystem according to an embodiment of the present invention; Figure 2 This is a diagram of a message push system according to an embodiment of the present invention; Figure 3This is a flowchart illustrating the registration service process according to an embodiment of the present invention; Figure 4 This is a flowchart illustrating the token management process according to an embodiment of the present invention; Figure 5 This is a flowchart illustrating the label and alias management process according to an embodiment of the present invention. Figure 6 This is a flowchart illustrating the message delivery process according to an embodiment of the present invention. Figure 7 This is a block diagram of a message push device based on the HarmonyOS ecosystem according to an embodiment of the present invention; Figure 8 This is a schematic block diagram of a computer device according to an embodiment of the present invention. Detailed Implementation

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

[0020] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0021] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0022] It should also be further understood that the term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0023] like Figure 1 , Figure 2 As shown, an embodiment of the present invention is: a message push method based on the HarmonyOS ecosystem, comprising the following steps: S1. Receive a registration request from a terminal device, parse the registration request to obtain the device's unique identifier information, and generate a unique registration identifier within the system; like Figure 3As shown, further, receiving a registration request from a terminal device, parsing the registration request to obtain the device's unique identifier information, and generating a unique registration identifier within the system specifically includes: S11. Receive a registration request from the terminal device through a TCP interface based on a custom encryption protocol; S12. Parse the device unique identifier information in the registration request; S13. Generate a unique registration identifier within the system based on the parsed information; S14. Store the correspondence between the unique registration identifier and the unique device identifier information in a relational database.

[0024] In this embodiment, the application installed on the terminal device, which integrates the SDK of this invention, automatically initiates a registration request to the JPush server upon startup. This request is transmitted through a long-lived TCP connection channel based on custom encryption using TLS 1.3, ensuring the security of the communication process. The request message contains a hardware serial number or system-level UDID generated by the HarmonyOS system that uniquely identifies the device. Upon receiving the request, the server-side registration service first decrypts and parses the protocol to extract the unique identifier of the device. Subsequently, it generates a globally unique 64-bit integer as the system's internal RegID, which, along with the parsed device identifier, is persistently stored in the device_registration table of the MySQL database. This step establishes a basic device mapping relationship for the core push service, enabling all subsequent push operations to be performed based on a unified internal identifier, shielding the differences and potential changes in the underlying device identifiers of the HarmonyOS system.

[0025] S2. Receive and associate the HarmonyOS push token reported by the terminal device with the unique registration identifier within the system, and store them persistently. like Figure 4 As shown, further, the step of receiving and associating the HarmonyOS push token reported by the terminal device with the unique registration identifier within the system, and persistently storing it, specifically includes: S21. Receive the HarmonyOS push token reported by the terminal device through the TCP interface; S22. Associate the HarmonyOS push token with the unique registration identifier within the system; S23. The relationship is simultaneously persisted to both a relational database and an in-memory database.

[0026] In this embodiment, after the application successfully obtains the push token representing the application-device combination from the HarmonyOS push service, it immediately reports this token to the JPush server via a secure TCP connection. Upon receiving the token, the token management system strongly associates it with the RegID generated in step S1. To achieve high-concurrency read / write and data persistence, this association is stored in two locations simultaneously: one is written to the `device_tokens` table in the MySQL database as a permanent record, and the other is cached in a Redis cluster with the key designed as `harmony_token:{RegID}`. This dual-storage strategy leverages the advantages of each database: MySQL ensures data reliability and transaction consistency, facilitating historical queries and auditing; Redis provides millisecond-level read speeds, greatly optimizing the performance of real-time token queries during large-scale pushes and avoiding single-point-of-failure bottlenecks in the database.

[0027] S3. Provide an interface to receive tag and / or alias information set for the unique registration identifier, and establish a bidirectional mapping relationship between the unique registration identifier and the tag and / or alias; like Figure 5 As shown, further, establishing a bidirectional mapping relationship between the unique registration identifier and the tag and / or alias specifically includes: S31. Establish a one-way one-to-one mapping relationship from the unique registration identifier to the tag and / or alias; S32. Establish a one-way one-to-many mapping relationship from the tags and / or aliases to the unique registration identifiers, wherein a set containing all unique registration identifiers associated with each tag or alias is maintained.

[0028] In this embodiment, the server provides developers with an encrypted TCP interface for setting tags and aliases. Developers can call this interface to set a business-level user identifier for a RegID, such as using the user ID "user123" as its alias and tagging it with labels such as VIP user and Shanghai region. Tag and alias management maintains two mapping relationships: one is a forward mapping from RegID to its alias and tag set, which is a one-to-one relationship, meaning that a device typically corresponds to one alias and a set of tags in the current application; the other is a reverse mapping from tags or aliases to a set of RegIDs, which is a one-to-many relationship, for example, the tag VIP user is associated with a set containing tens of thousands of RegIDs. Both mapping relationships are persisted in the database and cached through Redis. This flexible two-way mapping mechanism is the foundation for achieving accurate user segmentation and personalized push notifications, allowing operators to push notifications directly to specific users through aliases or broadcast to specific user groups through tag combinations.

[0029] S4. Receive a push task request from an external input, generate a push task containing message content and target filtering parameters according to the request, assign a unique task identifier to the push task, and then distribute it to the message queue. In this embodiment, the developer submits push tasks through a highly available HTTPS RESTful API. The request body includes the message title, content, redirect link, and target filtering parameters. For example, pushing to the alias list [user123], or pushing to all users in the Shanghai region who have the VIP tag. After verifying the request's legitimacy, the push task creation generates a globally unique task ID and constructs a complete push task object. Subsequently, this task object is serialized into JSON format and sent to a high-throughput message queue such as Apache Kafka or RocketMQ. Introducing a message queue for asynchronous decoupling separates the receipt of push requests from the subsequent heavy target filtering and message delivery processes, effectively handling instantaneous traffic spikes and ensuring the overall system response speed and stability.

[0030] S5. Obtain the push task from the message queue, and based on the target filtering parameters, combined with the bidirectional mapping relationship and the stored registration identifier information, filter out a set of target registration identifiers that meet the conditions; Furthermore, based on the target filtering parameters, combined with the bidirectional mapping relationship and the stored registration identifier information, a set of target registration identifiers that meet the conditions is filtered out. The target filtering parameters include at least one of the following: a specified list of specific registration identifiers, a logical combination condition based on tags, or a condition based on aliases.

[0031] In this embodiment, target user screening is the core decision-making step in the push process, consuming push task messages from the Kafka message queue. The system parses the target screening parameters in the task. These parameters may be complex combinations of multiple conditions, such as: the tag contains VIP users but does not belong to test users, or the alias exists in a specified list [user1, user2]. First, it accesses the Redis cache to query the reverse mapping relationship between tags and aliases to the RegID set. For simple tag conditions, it directly performs union and intersection operations using Redis Set operations; for complex logical combinations, it gradually narrows down the candidate set through multiple rounds of set operations. When the cache misses or precise verification is required, the system falls back to the MySQL database for a joint query. Finally, it outputs a precise, deduplicated RegID set, which represents all target devices that need to be covered in this push. This screening mechanism based on cache and database collaboration ensures the accuracy of screening and supports real-time screening needs under massive user conditions through efficient set operations, laying a solid foundation for achieving accurate push.

[0032] S6. Based on the target registration identifier set, obtain the associated HarmonyOS push token, construct a message that conforms to the HarmonyOS push service interface specification, and submit the message to the HarmonyOS push service to complete the final delivery to the terminal device. like Figure 6 As shown, further, constructing a message that conforms to the HarmonyOS push service interface specification and submitting the message to the HarmonyOS push service specifically includes: S61. Identify the HarmonyOS push service provider or version corresponding to the target terminal device; S62. After converting the unified format message content into the specific message format required by the manufacturer or version, submit it to the corresponding HarmonyOS push service interface.

[0033] In this embodiment, message delivery is the core of achieving unified push and multi-channel adaptation. Message delivery maintains a set of adapters for HarmonyOS vendor push service interfaces. For each device in the target RegID list, the system first quickly retrieves its corresponding HarmonyOS Token from the Redis cache. Next, the adapter identifies which vendor or version of HarmonyOS push service the device should use based on the Token's characteristics or preset routing rules. Then, the system converts the unified internal message format into the specific JSON or Protocol Buffers format required by the target HarmonyOS push service. For example, for Huawei HarmonyOS push, it may be necessary to fill in a specific hms_options field; for Honor devices, the message structure may be different. Finally, the formatted messages are submitted in batches to the corresponding vendor push gateway via HTTPS calls. This design encapsulates the interface differences between different channels within the system, making it completely transparent to upstream business logic. Developers do not need to worry about the underlying complexity, achieving true one-point access and full-channel coverage.

[0034] S7. Record the unique task identifier, the target registration identifier set, and the status and result of submitting the request to the HarmonyOS push service, and perform statistical analysis on the recorded information to generate a push effect report.

[0035] Furthermore, the statistical analysis of the recorded information to generate a push notification performance report specifically includes: Based on the number of the target registration identifier set and the number of registration identifiers associated with successfully submitting a request to the HarmonyOS push service, the delivery rate at each stage is calculated, and the message push loss path is analyzed to locate user churn at each stage from task creation to final delivery.

[0036] In this embodiment, the system establishes multiple key data collection points throughout the entire push chain. When a push task is created, the task ID and the total number of target users are recorded; after target filtering, the actual number of filtered RegIDs is recorded; after calling the vendor's interface, regardless of success or failure, detailed information such as the HTTP status code, the vendor's returned RequestID, and error codes for each request is recorded. All this process data is associated with the task ID and is fed into streaming platforms such as Apache Flink or Spark Streaming in real time. The big data analytics platform aggregates and calculates this data to generate multi-dimensional push performance reports. For example, the system automatically calculates the conversion rate from task creation to target filtering and successful delivery to the vendor, forming a push failure path diagram. Operators can clearly see that a push task targeting 1 million users, after filtering, actually targets 950,000 users, while 920,000 are successfully submitted to the HarmonyOS push service, thus identifying 30,000 users who may have lost out in the delivery stage due to token expiration. This in-depth post-event analysis capability helps developers quantify operational effectiveness, accurately locate problem areas, and provide reliable data support for subsequent strategy optimization.

[0037] like Figure 7 As shown, embodiments of the present invention also provide A message push device based on the HarmonyOS ecosystem includes: The registration service module 10 is used to receive registration requests from terminal devices, parse the registration requests to obtain unique device identification information, and generate a unique registration identifier within the system. The token management module 20 is used to receive and associate the HarmonyOS push token reported by the terminal device with the unique registration identifier inside the system, and to persistently store it. The tag and alias management module 30 is used to provide an interface to receive tag and / or alias information set for the unique registration identifier, and to establish a bidirectional mapping relationship between the unique registration identifier and the tag and / or alias; The push task creation module 40 is used to receive push task requests from external input, generate push tasks containing message content and target filtering parameters according to the request, assign a unique task identifier to the push task, and then distribute it to the message queue. The target user filtering module 50 is used to obtain the push task from the message queue, and based on the target filtering parameters, combined with the bidirectional mapping relationship and the stored registration identifier information, filter out a set of target registration identifiers that meet the conditions. The message delivery module 60 is used to obtain the HarmonyOS push token associated with the target registration identifier set, construct a message that conforms to the HarmonyOS push service interface specification, and submit the message to the HarmonyOS push service to complete the final delivery to the terminal device. The push result analysis module 70 is used to record the unique task identifier, the target registration identifier set, and the status and result of submitting the request to the HarmonyOS push service, and to perform statistical analysis on the recorded information to generate a push effect report.

[0038] Furthermore, the registration service module 10 is specifically used for: Receive registration requests from terminal devices via a TCP interface based on a custom encryption protocol; Parse the device unique identifier information in the registration request; A unique registration identifier is generated within the system based on the parsed information; The correspondence between the unique registration identifier and the unique device identifier is stored in a relational database.

[0039] Furthermore, the token management module 20 is specifically used for: Receive HarmonyOS push tokens reported by the terminal device via TCP interface; Associate the HarmonyOS push token with the unique registration identifier within the system; The relationships are persisted to both a relational database and an in-memory database.

[0040] Furthermore, the tag and alias management module 30 is specifically used for: Establish a one-way, one-to-one mapping relationship from the unique registration identifier to the tag and / or alias; Establish a one-way one-to-many mapping relationship from the tags and / or aliases to the unique registration identifiers, wherein for each tag or alias, maintain a set containing all unique registration identifiers associated with it.

[0041] Furthermore, in the target user filtering module 50, based on the target filtering parameters, combined with the bidirectional mapping relationship and the stored registration identifier information, a set of target registration identifiers that meet the conditions is filtered out. The target filtering parameters include at least one of the following: a specified list of specific registration identifiers, a logical combination condition based on tags, or a condition based on aliases.

[0042] Furthermore, in the message delivery module 60, constructing a message conforming to the HarmonyOS push service interface specification and submitting the message to the HarmonyOS push service specifically includes: Identify the HarmonyOS push service provider or version corresponding to the target terminal device; After converting the unified message content into the specific message format required by the manufacturer or version, it is then submitted to the corresponding HarmonyOS push service interface.

[0043] Furthermore, in the push result analysis module 70, the statistical analysis of the recorded information to generate a push effect report specifically includes: Based on the number of the target registration identifier set and the number of registration identifiers associated with successfully submitting a request to the HarmonyOS push service, the delivery rate at each stage is calculated, and the message push loss path is analyzed to locate user churn at each stage from task creation to final delivery.

[0044] It should be noted that those skilled in the art can clearly understand that the specific implementation process of the above-mentioned message push device based on the HarmonyOS ecosystem and its various units can be referred to the corresponding descriptions in the aforementioned method embodiments. For the sake of convenience and brevity, these details will not be repeated here.

[0045] The aforementioned message push device based on the HarmonyOS ecosystem can be implemented as a computer program, which can, for example... Figure 8 It runs on the computer device shown.

[0046] Please see Figure 8 , Figure 8 This is a schematic block diagram of a computer device provided in an embodiment of this application. The computer device 500 can be a terminal or a server. The terminal can be an electronic device with communication functions, such as a smartphone, tablet, laptop, desktop computer, personal digital assistant, or wearable device. The server can be a standalone server or a server cluster composed of multiple servers.

[0047] See Figure 8 The computer device 500 includes a processor 502, a memory, and a network interface 505 connected via a system bus 501. The memory may include a non-volatile storage medium 503 and internal memory 504.

[0048] The non-volatile storage medium 503 can store an operating system 5031 and a computer program 5032. The computer program 5032 includes program instructions that, when executed, cause the processor 502 to execute a message push method based on the HarmonyOS ecosystem.

[0049] The processor 502 provides computing and control capabilities to support the operation of the entire computer device 500.

[0050] The internal memory 504 provides an environment for the execution of the computer program 5032 in the non-volatile storage medium 503. When the computer program 5032 is executed by the processor 502, the processor 502 can execute a message push method based on the HarmonyOS ecosystem.

[0051] This network interface 505 is used for network communication with other devices. Those skilled in the art will understand that... Figure 8 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device 500 to which the present application is applied. The specific computer device 500 may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0052] The processor 502 is used to run the computer program 5032 stored in the memory to implement the message push method based on the HarmonyOS ecosystem as described above.

[0053] It should be understood that in the embodiments of this application, the processor 502 may be a central processing unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0054] It will be understood by those skilled in the art that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program includes program instructions and can be stored in a storage medium, which is a computer-readable storage medium. The program instructions are executed by at least one processor in the computer system to implement the process steps of the embodiments of the above methods.

[0055] Therefore, the present invention also provides a storage medium. This storage medium can be a computer-readable storage medium. The storage medium stores a computer program, wherein the computer program includes program instructions. When executed by a processor, the program instructions cause the processor to execute the message push method based on the HarmonyOS ecosystem as described above.

[0056] The storage medium can be any computer-readable storage medium capable of storing program code, such as a USB flash drive, portable hard drive, read-only memory (ROM), magnetic disk, or optical disk.

[0057] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0058] In the several embodiments provided by this invention, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For example, the division of each unit is merely a logical functional division, and there may be other division methods in actual implementation. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0059] The steps in the method of this invention can be adjusted, merged, or reduced in order according to actual needs. The units in the device of this invention can be merged, divided, or reduced according to actual needs. Furthermore, the functional units in the various embodiments of this invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0060] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a terminal, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.

[0061] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A message push method based on the HarmonyOS ecosystem, characterized in that, include: Receive a registration request from a terminal device, parse the registration request to obtain the device's unique identifier information, and generate a unique registration identifier within the system; Receive and associate the HarmonyOS push token reported by the terminal device with the unique registration identifier within the system, and persistently store it; Provide an interface to receive tag and / or alias information set for the unique registration identifier, and establish a bidirectional mapping relationship between the unique registration identifier and the tag and / or alias; Receive push task requests from external input, generate push tasks containing message content and target filtering parameters according to the requests, assign a unique task identifier to the push task, and then distribute it to the message queue. The push task is obtained from the message queue, and a set of target registration identifiers that meet the conditions is selected based on the target filtering parameters, combined with the bidirectional mapping relationship and the stored registration identifier information. Based on the target registration identifier set, obtain the associated HarmonyOS push token, construct a message that conforms to the HarmonyOS push service interface specification, and submit the message to the HarmonyOS push service to complete the final delivery to the terminal device; The system records the unique task identifier, the set of target registration identifiers, and the status and result of submitting the request to the HarmonyOS push service. It also performs statistical analysis on the recorded information to generate a push effect report.

2. The message push method based on the HarmonyOS ecosystem according to claim 1, characterized in that, The process of receiving a registration request from a terminal device, parsing the registration request to obtain the device's unique identifier information, and generating a unique registration identifier within the system specifically includes: Receive registration requests from terminal devices via a TCP interface based on a custom encryption protocol; Parse the device unique identifier information in the registration request; A unique registration identifier is generated within the system based on the parsed information; The correspondence between the unique registration identifier and the unique device identifier is stored in a relational database.

3. The message push method based on the HarmonyOS ecosystem according to claim 1, characterized in that, The process of receiving and associating the HarmonyOS push token reported by the terminal device with the unique registration identifier within the system, and persistently storing it, specifically includes: Receive HarmonyOS push tokens reported by the terminal device via TCP interface; Associate the HarmonyOS push token with the unique registration identifier within the system; The relationships are persisted to both a relational database and an in-memory database.

4. The message push method based on the HarmonyOS ecosystem according to claim 1, characterized in that, The establishment of a bidirectional mapping relationship between the unique registration identifier and the tag and / or alias specifically includes: Establish a one-way, one-to-one mapping relationship from the unique registration identifier to the tag and / or alias; Establish a one-way one-to-many mapping relationship from the tags and / or aliases to the unique registration identifiers, wherein for each tag or alias, maintain a set containing all unique registration identifiers associated with it.

5. The message push method based on the HarmonyOS ecosystem according to claim 1, characterized in that, The method involves filtering out a set of target registration identifiers that meet the conditions based on the target filtering parameters, the bidirectional mapping relationship, and the stored registration identifier information. The target filtering parameters include at least one of the following: a specified list of specific registration identifiers, a logical combination condition based on tags, or a condition based on aliases.

6. The message push method based on the HarmonyOS ecosystem according to claim 1, characterized in that, The construction of a message conforming to the HarmonyOS push service interface specification and the submission of the message to the HarmonyOS push service specifically includes: Identify the HarmonyOS push service provider or version corresponding to the target terminal device; After converting the unified message content into the specific message format required by the manufacturer or version, it is then submitted to the corresponding HarmonyOS push service interface.

7. The message push method based on the HarmonyOS ecosystem according to claim 1, characterized in that, The statistical analysis of the recorded information to generate a push notification performance report specifically includes: Based on the number of the target registration identifier set and the number of registration identifiers associated with successfully submitting a request to the HarmonyOS push service, the delivery rate at each stage is calculated, and the message push loss path is analyzed to locate user churn at each stage from task creation to final delivery.

8. A message push device based on the HarmonyOS ecosystem, characterized in that, include: The registration service module is used to receive registration requests from terminal devices, parse the registration requests to obtain the device's unique identifier information, and generate a unique registration identifier within the system. The token management module is used to receive and associate the HarmonyOS push token reported by the terminal device with the unique registration identifier inside the system, and to persistently store it. The tag and alias management module is used to provide an interface to receive tag and / or alias information set for the unique registration identifier, and to establish a bidirectional mapping relationship between the unique registration identifier and the tag and / or alias; The push task creation module is used to receive push task requests from external input, generate push tasks containing message content and target filtering parameters according to the request, assign a unique task identifier to the push task, and then distribute it to the message queue. The target user filtering module is used to obtain the push task from the message queue, and based on the target filtering parameters, combined with the bidirectional mapping relationship and the stored registration identifier information, filter out a set of target registration identifiers that meet the conditions. The message delivery module is used to obtain the HarmonyOS push token associated with the target registration identifier set, construct a message that conforms to the HarmonyOS push service interface specification, and submit the message to the HarmonyOS push service to complete the final delivery to the terminal device. The push result analysis module is used to record the unique task identifier, the target registration identifier set, and the status and result of the request submitted to the HarmonyOS push service, and to perform statistical analysis on the recorded information to generate a push effect report.

9. A computer device, characterized in that, The computer device includes a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, it implements the message push method based on the HarmonyOS ecosystem as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, can implement the message push method based on the HarmonyOS ecosystem as described in any one of claims 1 to 7.

Images