CN115051968A

CN115051968A - Method for sending push message, electronic equipment and readable medium

Info

Publication number: CN115051968A
Application number: CN202110220947.3A
Authority: CN
Inventors: 黄文�; 傅志诚
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2021-02-26
Filing date: 2021-02-26
Publication date: 2022-09-13
Also published as: WO2022179283A1

Abstract

The application relates to the field of content distribution and discloses a method for sending a push message, electronic equipment and a readable medium. The method for sending the push message comprises the following steps: the method comprises the steps that under the condition that the type of a push message sent to second electronic equipment is judged to be the first type, whether a first heartbeat packet sent by the second electronic equipment is received or not is determined by first electronic equipment, and the first electronic equipment sends the push message after receiving the first heartbeat packet sent by the second electronic equipment, so that different types of push messages are sent to the second electronic equipment at different times, the extra awakening times of the second electronic equipment can be reduced, and the power consumption of the second electronic equipment is reduced.

Description

Method for sending push message, electronic equipment and readable medium

Technical Field

The present application relates to the field of content distribution, and in particular, to a method for sending a push message, an electronic device, and a readable medium.

Background

With the increasing number of applications installed on the user intelligent terminal, the number of messages pushed to the intelligent terminal by various applications is also increasing, and most of the pushed application messages are messages of content recommendation type, as shown in fig. 1, the content recommendation type messages account for more than 70% of all messages. In addition, because the time and frequency for pushing the application message to the intelligent terminal are not fixed, each push message reaching the intelligent terminal may wake up a processor of the intelligent terminal from a sleep state to perform message processing, which often causes additional interrupt and wake-up of the intelligent terminal, resulting in increased power consumption of the intelligent terminal. According to relevant statistics, the interruption and awakening of the intelligent terminal caused by the push messages accounts for about 45% of the total interruption and awakening, and the intelligent terminal receives about 100 push messages in the daytime on average, so that extra power consumption of the intelligent terminal caused by the push messages is considerable.

Disclosure of Invention

The embodiment of the application provides a method for sending a push message, an electronic device and a readable medium, which can determine to send the push message instantly or in a delayed manner according to the type of the push message, and send the push message to the electronic device after the electronic device receiving the push message is awakened actively, so that the additional awakening times of the electronic device are reduced, and the power consumption of the electronic device is further reduced.

In a first aspect, an embodiment of the present application provides a method for sending a push message, where the method includes:

the method comprises the steps that under the condition that the type of a push message sent to second electronic equipment is judged to be a first type, the first electronic equipment determines whether a first heartbeat packet sent by the second electronic equipment is received or not;

the first electronic equipment sends the push message after receiving the first heartbeat packet sent by the second electronic equipment.

In one possible implementation of the first aspect, the method further includes:

and the first electronic equipment sends the push message to the second electronic equipment under the condition that the type of the push message sent to the second electronic equipment is judged to be the second type.

In a possible implementation of the first aspect, the method further includes:

and sending a push message to the second electronic device under the condition that a third heartbeat packet sent before the first heartbeat packet contains an end side state of the second electronic device and the first electronic device judges that the type of the push message sent by the second electronic device is a second type according to the end side state, wherein the end side state comprises at least one of the following information: a system state; the application state.

In a possible implementation of the first aspect, the method further includes:

the system state includes at least one of: the screen-off time and the system mode, the application state comprises at least one of the following: application usage, application usage settings, and application levels.

In a possible implementation of the first aspect, after receiving a first heartbeat packet sent by a second electronic device, a first electronic device sends a push message, where the push message includes:

after receiving the first heartbeat packet sent by the second electronic device, the first electronic device returns the second heartbeat packet to the second electronic device and simultaneously sends the push message.

In a possible implementation of the first aspect, the returning, by the first electronic device, the second heartbeat packet to the second electronic device and sending the push message at the same time includes:

the first electronic device merges the push message into a second heartbeat packet and sends the second heartbeat packet to the second electronic device.

and the first electronic equipment respectively sends the push message and the second heartbeat packet to the second electronic equipment.

In a possible implementation of the first aspect, the sending, by the first electronic device, the push message after receiving the first heartbeat packet sent by the second electronic device includes:

after receiving a first heartbeat packet sent by second electronic equipment, the first electronic equipment sends a push message to the second electronic equipment within preset time.

In a possible implementation of the first aspect, the method further includes:

the processor of the second electronic device is not in a sleep state for a predetermined time.

In a second aspect, an embodiment of the present application provides an electronic device, where the electronic device includes:

the determining module is used for determining whether a first heartbeat packet sent by second electronic equipment is received or not under the condition that the first electronic equipment judges that the type of the push message sent to the second electronic equipment is a first type;

the sending module is used for sending the push message after the first electronic device receives the first heartbeat packet sent by the second electronic device.

In a third aspect, an embodiment of the present application provides an electronic device-readable medium, where instructions are stored on the electronic device, and when executed on the electronic device, the instructions may cause the electronic device to perform any one of the possible methods of the first aspect.

In a fourth aspect, an embodiment of the present application provides an electronic device, including: a memory for storing instructions for execution by one or more processors of the system, and the processor being one of the processors of the system for performing any one of the possible methods of the first aspect described above.

In a fifth aspect, an embodiment of the present application provides an electronic device, where the electronic device has a function of implementing the sending method of the push message. The functions can be realized by hardware, and the functions can also be realized by executing corresponding software by hardware. The hardware or software includes one or more units corresponding to the above functions.

Drawings

Fig. 1 illustrates a type scale diagram of a push message, according to some embodiments of the present application.

Fig. 2 illustrates a push message transmission scenario 10, according to some embodiments of the present application.

FIG. 3 shows a schematic diagram of power consumption of electronic device 100 over time, according to some embodiments of the present application.

Fig. 4 illustrates a block diagram of a hardware configuration of an electronic device 200, according to some embodiments of the present application.

Fig. 5 illustrates an interactive flow diagram of a method of sending a push message, according to some embodiments of the present application.

Fig. 6 illustrates a scenario of sending a heartbeat packet and a push message in a method for sending a push message according to some embodiments of the present application.

Fig. 7 illustrates a scenario in which a heartbeat packet and a push message are respectively transmitted in a method for transmitting a push message according to some embodiments of the present application.

Fig. 8 illustrates a schematic structural diagram of an electronic device, according to some embodiments of the present application.

FIG. 9 illustrates a schematic structural diagram of another electronic device, according to some embodiments of the present application.

FIG. 10 illustrates a block diagram of a software architecture of an electronic device, according to some embodiments of the present application.

Detailed Description

The illustrative embodiments of the present application include, but are not limited to, a method for sending a push message, an electronic device, and a readable medium, so as to solve the problems of excessive additional wake-up times and high power consumption of the electronic device caused by the push message. It will be understood that, as used herein, the terms "first," "second," and the like may be used herein to describe various elements, but these elements are not limited by these terms unless otherwise specified. These terms are only used to distinguish one element from another.

Embodiments of the present application will be described in further detail below with reference to the accompanying drawings.

Fig. 2 illustrates a push message transmission scenario 10, according to some embodiments of the present application. Specifically, as shown in fig. 2, the scene 10 includes an electronic device 100 and an electronic device 200. The electronic device 200 may receive a push message of an application, and determine to send the push message to the electronic device 100 immediately or in a delayed manner according to a type of the push message or a side state of the electronic device 100, where the push message of the application may be a push message from an external third-party application, or a push message from an application on the electronic device 200. The push message sent instantly is sent by the electronic device 200 to the electronic device 100 in real time, and the push message sent with delay is cached by the electronic device 200. The electronic device 100 wakes up actively at regular intervals and sends a heartbeat packet to the electronic device 200, the electronic device 200 sends a cached push message sent in a delayed manner to the electronic device 100 after receiving the heartbeat packet from the electronic device 100, and the electronic device 100 displays the message to a user after receiving the push message.

Fig. 3 shows a process in which the power consumption of the electronic device 100 varies according to time. As shown in fig. 3, the electronic device 100 wakes up actively periodically and sends a Real Time Clock (RTC) heartbeat packet to the electronic device 200, and the active wake-up and the sending of the heartbeat packet of the electronic device 100 generate higher power consumption, i.e. a power consumption peak corresponding to the RTC heartbeat packet in the figure, which is necessarily generated by the electronic device 100. In addition, in the existing solutions, directly pushing the push message to the electronic device 100 may cause additional wake-up of the electronic device 100, and the news notification message, the video notification message, and the social notification message shown in fig. 3 cause additional power consumption of the electronic device 100, so that the power consumption of the electronic device 100 is higher. In the technical solution of the present application, the electronic device 200 caches the notification messages, and after the electronic device 100 actively wakes up and sends the heartbeat packet to the electronic device 200, the electronic device 200 sends the cached push message to the electronic device 100. By changing the push time of the notification message, the electronic device 200 pushes the message in the active wake-up phase of the electronic device 100, thereby avoiding additional wake-up of the electronic device 100. Here, the active wake-up phase of the electronic device 100 is a period of time during which the electronic device 100 actively wakes up and transmits a heartbeat packet to the electronic device 200 and receives a heartbeat reply packet from the electronic device 200. For example, the news notification message in fig. 3 may be pushed in the active wakeup phase when the electronic device 100 sends the second RTC heartbeat packet, and the video notification message and the social notification message may be pushed in the active wakeup phase when the electronic device 100 sends the third RTC heartbeat packet.

In the embodiment of the present application, a mode that the electronic device 100 wakes up actively and then receives and processes the push message sent by the electronic device 200 is adopted, and in this mode, power consumption generated by the electronic device 100 is much less than power consumption generated by waking up the electronic device 100 from sleep and then receiving and processing the push message. Therefore, the power consumption of the electronic device 100 for transmitting and receiving the heartbeat packet and receiving and processing the push message in the active wake-up phase is much less than the sum of the power consumption for transmitting and receiving the heartbeat packet and receiving and processing the push message respectively. Due to the fact that the electronic device 100 receives a large number of push messages every day, the power consumption of the electronic device 100 can be reduced to a large extent by using the technical scheme of the application.

It is understood that in embodiments of the present application,

electronic devices

100 and 200 may include, but are not limited to, laptop computers, desktop computers, tablet computers, cell phones, wearable devices, head mounted displays, servers, mobile email devices, portable game consoles, portable music players, reader devices, televisions with one or more processors embedded or coupled therein, or other electronic devices capable of accessing a network.

Fig. 4 illustrates a block diagram of a hardware configuration of an electronic device 200, according to some embodiments of the present application. Some embodiments in the embodiment shown in fig. 4, the electronic device 200 may include one or more processors 201, a system control logic 202 connected to at least one of the processors 201, a system Memory 203 connected to the system control logic 202, a Non-Volatile Memory (NVM) 204 connected to the system control logic 202, and a network interface 206 connected to the system control logic 202.

In some embodiments, processor 201 may include one or more single-core or multi-core processors. In some embodiments, the processor 201 may include any combination of general-purpose processors and special-purpose processors (e.g., graphics processors, application processors, baseband processors, etc.). In embodiments where the electronic device 200 employs an enhanced Node B (eNB) or a Radio Access Network (RAN) controller, the processor 201 may be configured to perform various consistent embodiments. For example, the processor 201 may be configured to execute a push message sending method as shown in fig. 5.

In some embodiments, system control logic 202 may include any suitable interface controllers to provide any suitable interface to at least one of processors 201 and/or to any suitable device or component in communication with system control logic 202.

In some embodiments, system control logic 202 may include one or more memory controllers to provide an interface to system memory 203. System memory 203 may be used to load and store data and/or instructions. For example, the system memory 203 may load an application program instruction for performing type determination on the push message in the embodiment of the present application, may also load an application program instruction for sending the push message to the electronic device 100, and may also load an application program instruction for caching the push message, and the like. In some embodiments, Memory 203 of system 200 may include any suitable volatile Memory, such as suitable Dynamic Random Access Memory (DRAM).

NVM/memory 204 may include one or more tangible, non-transitory computer-readable media for storing data and/or instructions. In some embodiments, NVM/memory 204 may include any suitable non-volatile memory, such as flash memory, and/or any suitable non-volatile storage device, such as at least one of a Hard Disk Drive (HDD), Compact Disc (CD) Drive, and Digital Versatile Disc (DVD) Drive. In an embodiment of the present application, NVM/memory 204 may be used to store received application push messages and cache delayed sent push messages.

NVM/memory 204 may comprise a portion of a storage resource on the device on which electronic device 200 is installed, or it may be accessible by, but not necessarily a part of, the device. For example, NVM/storage 204 may be accessed over a network via network interface 206.

In particular, system memory 203 and NVM/storage 204 may each include: a temporary copy and a permanent copy of instructions 205. The instructions 205 may include: instructions that when executed by at least one of the processors 201 cause the system 200 to implement the method shown in fig. 7. In some embodiments, the instructions 205, hardware, firmware, and/or software components thereof may additionally/alternatively be disposed in the system control logic 202, the network interface 206, and/or the processor 201.

The network interface 206 may include a transceiver to provide a radio interface for the electronic device 200 to communicate with any other suitable device (e.g., front end module, antenna, etc.) over one or more networks. In some embodiments, the network interface 206 may be integrated with other components of the electronic device 200. For example, the network interface 206 may be integrated with at least one of the processor 201, the system memory 203, the NVM/storage 204, and a firmware device (not shown) having instructions that, when executed by at least one of the processor 201, the electronic device 200 implements the method as shown in the method embodiments. In this embodiment, the network interface 206 may be configured to receive the push message and send the received push message to the electronic device 100, and may also receive a heartbeat packet sent by the electronic device 100 and return a heartbeat reply packet to the electronic device 100.

The network interface 206 may further include any suitable hardware and/or firmware to provide a multiple-input multiple-output radio interface. For example, network interface 206 may be a network adapter, a wireless network adapter, a telephone modem, and/or a wireless modem.

In some embodiments, at least one of the processors 201 may be packaged together with logic for one or more controllers of the System control logic 202 to form a System In a Package (SiP). In some embodiments, at least one of the processors 201 may be integrated on the same die with logic for one or more controllers of the System control logic 202 to form a System on Chip (SoC).

The electronic device 200 may further include: input/output (I/O) devices 207. The I/O device 207 may include a user interface to enable a user to interact with the electronic device 200; the design of the peripheral component interface enables peripheral components to also interact with the electronic device 200.

The following describes the technical solution of the present application with reference to fig. 5 to 7, taking the electronic device 100 as a mobile phone and the electronic device 200 as a server as an example.

As described above, in some embodiments of the present application, the server 200 receives a push message of an application, where the application may be an external application or an application running on the server 200, and determines whether the push message is a first type message or a second type message according to a type of the push message. If the push message is determined to be the first type message, the push message may be cached, and after receiving the heartbeat packet sent by the mobile phone 100, the cached first type push message is sent to the mobile phone 100. In case that it is determined that the push message is the second type message, the server 200 directly transmits the push message to the handset 100.

Fig. 5 shows a technical solution for caching a push message by the server 200 and pushing the cached push message to the mobile phone 100 after receiving a heartbeat packet sent by the mobile phone 100 according to some embodiments of the present application. The following takes the first type message as a non-urgent message, and the second type message as an urgent message as an example to explain a specific technical scheme. Specifically, as shown in fig. 5:

in step S501, the mobile phone 100 sends a heartbeat packet to the server 200, where the heartbeat packet includes the end-side status of the mobile phone 100. The time when the handset 100 sends the heartbeat packet may be when the user uses the handset 100 or when the user does not use the handset 100. Typically, to reduce power consumption, the handset 100 is normally in a sleep state when the handset 100 is not being used by a user. For example, after a certain period of time, for example, 30 seconds, has elapsed since the user stopped using the cellular phone 100, the cellular phone 100 automatically turns off the screen, stops the running of unnecessary applications, and the like, thereby entering a sleep state.

In some embodiments of the present application, the handset 100 periodically sends the heartbeat packet to the server 200, and the time interval for sending the heartbeat packet is preset, for example, set at the time of factory shipment or set by the user as needed. The set time interval may be, for example, 3 minutes, 5 minutes, 10 minutes, or the like, and is generally set to 5 minutes. When the time for sending the heartbeat packet arrives, if the mobile phone 100 is in the sleep state, the mobile phone first actively wakes up, so that the processor of the mobile phone 100 enters the working state, and then sends the heartbeat packet.

In some embodiments of the present application, the end-side state of the handset 100 may include, but is not limited to, a system state and an application state. The system state of the mobile phone 100 refers to some information currently related to the mobile phone system, which may include but is not limited to: screen-off time, system mode, etc. The screen-off time is a time that lasts after the screen of the mobile phone 100 is automatically turned off. The system mode refers to a current mode of the mobile phone 100, and the system mode may correspond to some system parameters of the mobile phone 100, such as the power of the mobile phone 100, the current time of the mobile phone 100, and the like. The system mode may be automatically entered according to system parameters, for example, automatically enter the low power mode when the power of the mobile phone 100 is less than the power threshold, or enter according to user settings, for example, when the user is in a meeting, the mobile phone 100 is set to the mute mode. The system modes may include, but are not limited to: low battery mode, power saving mode, night mode, default mode, silent mode, etc.

The application state of the mobile phone 100 refers to the relevant usage information of the installed application in the mobile phone 100, and may include but is not limited to: application usage, application usage settings, application level, and the like. Application usage, which describes how frequently a user uses an application, may be described using different levels, for example: frequently used, commonly used, rarely used, etc., and may also be described using numbers such as: not used for more than 1 day, not used for more than 3 days, not used for more than 7 days, etc. Application usage settings are used to describe the relevant settings when using the application, for example: application a is set by the user to disallow activity, application B is set by the user to notify on mute, etc. The application level is used to describe the corresponding priority of the user, for example: application a corresponds to a high priority, application B corresponds to a low priority, application C corresponds to a medium priority, and the like.

The heartbeat packet is a network data packet sent by the handset 100 to the server 200 to inform the server 200 that the handset 100 is currently in an online state. In some embodiments of the present application, the heartbeat packet is a network data packet using a Transmission Control Protocol (TCP), and the TCP is a reliable network Transmission Protocol, which can ensure that the heartbeat packet sent by the mobile phone 100 reaches the server 200.

It can be understood that the end-side state data of the mobile phone 100 may be sent together with the heartbeat packet as a part of the heartbeat packet, and after the end-side state data of the mobile phone 100 is large and exceeds the carrying capacity of the heartbeat packet, the end-side state data of the mobile phone 100 and the heartbeat packet may also be sent separately, and the specific sending manner of the end-side state of the mobile phone 100 is not limited in the embodiment of the present application.

In step S502, the server 200 receives and stores the end-side status transmitted from the mobile phone 100. The server 200 stores the end-side state sent by the mobile phone 100 in the database of the server 200, so that whether to delay sending of the message to be sent to the mobile phone 100 can be determined according to the end-side state corresponding to the mobile phone 100, thereby reducing the number of additional awakenings of the mobile phone 100 and further reducing the power consumption of the mobile phone 100.

In step S503, the server 200 sends a heartbeat reply packet to the handset 100. After receiving the heartbeat packet sent by the mobile phone 100, the server 200 returns a heartbeat reply packet to the mobile phone 100 to inform the mobile phone 100 that the server 200 is currently in an online state, so that interaction between the two parties can be performed normally.

In some embodiments of the present application, the heartbeat reply packet is a network data packet that also uses the transmission control protocol, so as to ensure that the heartbeat packet reply packet returned by the server 200 can reliably reach the handset 100.

In step S504, the server 200 receives a push message from an application. In some embodiments of the present application, the applications installed on the handset 100 may be applications originated by a third party responsible for developing and operating third party applications that may be run on the handset 100. The application installed on the mobile phone 100 is a client version of the application, a server version of the application runs in the cloud, and the server version of the application generates a message to be pushed and pushes the generated push message to the client version of the application. In some embodiments, the server-side version of the application does not directly push the generated push message to the client-side version of the application on the mobile phone 100, but pushes the push message to the server 200, and then the server 200 sends the push message to the mobile phone 100, so that the server-side version of the application can realize the push of the application message only by using less computing resources.

The applications installed on the cell phone 100 may be various types of applications, such as news-like applications through which the user reads daily news; a video-class application, which is used by a user to watch videos; and the social application is used for carrying out social communication by the user. Push messages generated by different types of applications may be pushed to the server 200 before being sent to the mobile phone 100 by the server 200.

The push messages received by the server 200 come from different types of third-party applications, and the types of the push messages of the third-party applications are different, for example, the types of the push messages may include content recommendation, instant messages, financial dynamics, subscription messages, logistics information, and the like.

In step S505, the server 200 determines whether the push message is an urgent message according to the type of the push message. If it is determined that the push message is an urgent message, performing step S506; if the push message is a non-urgent message, step S507 is performed.

The application push message received by the server 200 includes the type of the message, and the server 200 can learn the type of the push message by analyzing the third party push message.

In some embodiments of the present application, the server 200 may determine that the received push message of different types is an urgent message or a non-urgent message according to the preset settings for the push message of different types. For example, in some embodiments, a push message type that is closely related to the life of the user may be set as an urgent message, and a push message type that is not as relevant to the life of the user may be set as a non-urgent message. For example, a push message with type a is manually set to be an emergency message, a push message with type B is manually set to be a non-emergency message, and the like, the manually set corresponding information is stored in the server 200, and after receiving the push message, the server 200 queries the manually set corresponding information according to the type of the push message to determine whether the push message is an emergency message or a non-emergency message.

In some embodiments of the present application, the server 200 may further determine the push message as an urgent message or a non-urgent message according to timeliness requirements of different types of push messages. The timeliness requirements of different types of push messages are different, e.g. a content recommendation type push message has lower timeliness requirements, whereas an instant message type and a financial dynamic type push message have higher timeliness requirements. Therefore, the push message type with high timeliness requirement can be judged as the emergency message, and the push message type with low timeliness requirement can be judged as the non-emergency message, so that the timely push of the message with high timeliness requirement can be realized.

In step S506, the server 200 directly transmits the push message when the push message is an urgent message. The urgent message is usually a push message that is important for the user and needs to be sent to the mobile phone 100 in time to be displayed to the user, so the server 200 does not delay sending the urgent message, and sends the push message in real time when judging that the received push message is the urgent message.

In step S507, the server 200 determines whether the push message is an emergency message according to the stored end-side status of the mobile phone 100. The part of the push messages which are judged to be urgent messages according to the message types in the push messages are sent by the server 200 in real time, in the step, the server 200 judges in the rest push messages according to the end side state of the mobile phone 100 to determine the push messages which are possibly urgent messages, and if the urgent messages exist in the rest push messages, the server 200 sends the urgent messages in real time.

In some embodiments of the present application, the server 200 determines whether the push message is an urgent message according to a preset urgent message determination rule. The emergency message judgment rule is set according to the system state and the application state, and the push message meeting the emergency message judgment rule is an emergency message. For example, if the urgent message determination rule is "screen-off time is less than 5 minutes and the system mode is the default mode", the server 200 determines that the system state of the mobile phone 100 received in advance is "screen-off time: 3 minutes, system mode: default mode ", the received push message is determined to be an urgent message.

For another example, the message type of the push message a received by the server 200 is content recommendation, the corresponding application is application a, the push message of the content recommendation type is determined as a non-urgent message in step S505, and in step S507, the server 200 continues to perform urgent message determination on the push message a according to the urgent message determination rule. The application state on the mobile phone 100 acquired by the server 200 is, for example, "application name: application a, application use case: if the application a is frequently used, that is, the user of the mobile phone 100 uses the application a frequently, the attention degree of the message pushed by the application a is high, and the push message corresponding to the application a is an emergency message, so that the emergency message determination rule can be set to "the application use condition is frequently used", and the server 200 determines the push message a as the emergency message under the above condition, and pushes the push message a in real time, so as to meet the attention degree requirement of the user of the mobile phone 100 on the application a.

In addition, after determining a new urgent message among the remaining push messages according to the end-side state of the mobile phone 100, the server 200 finally transmits the remaining push messages as non-urgent messages.

In step S508, the server 200 caches the push message determined as the non-urgent message if the aggregation condition is satisfied. Push messages determined to be non-urgent messages are typically less important messages for the user of the handset 100, so the server 200 may cache a plurality of non-urgent messages if the aggregation condition is met, including but not limited to the following: caching using files, caching using databases, caching in memory, and the like. The cached one or more non-urgent messages constitute an aggregated push message corresponding to the handset 100.

In some embodiments of the present application, if the aggregation condition is not satisfied, the server 200 may also directly push a push message serving as a non-emergency message, for example, when the aggregation condition is not satisfied, the user is using the mobile phone 100, and at this time, because the mobile phone 100 is in an awake state, additional awake power consumption is not generated when pushing the non-emergency message.

In some embodiments of the present application, the aggregation condition is determined according to the end-side status of the handset 100 sent to the server 200. For example, the aggregation condition may be determined according to the system state of the mobile phone 100, or may be determined according to the application state of the mobile phone 100.

A plurality of aggregation conditions determined according to the system state of the cellular phone 100 are shown in the following table 1:

	time of screen extinguishing	System mode
			Polymerization conditions 1	>5 minutes	Low battery mode
Polymerization conditions 2	>5 minutes	Power saving mode
			Polymerization conditions 3	>5 minutes	Night mode
Polymerization conditions 4	>30 minutes or 10 minutes	Default mode
			Polymerization conditions 5	>5 minutes	Mute mode

TABLE 1

The aggregation condition 1 indicates that, when the system mode of the mobile phone 100 is the low battery mode and the screen-off time is longer than 5 minutes, the push message serving as the non-urgent message is cached. The aggregation condition 4 indicates that the push message serving as the non-urgent message is cached when the system mode of the mobile phone 100 is the default mode and the screen-off time is greater than 30 minutes or greater than 10 minutes. And so on.

In addition, a plurality of polymerization conditions determined according to the application state of the mobile phone 100 are shown in the following table 2:

	application use case	Application usage settings	Application level
				Using polymerisation 1	Is rarely used
Using polymerisation 2		Not allow forLicensing activities
				Using polymerisation 3		Low priority
Using polymerisation 4		Notification mute

TABLE 2

The application aggregation condition 1 indicates that, when the application use condition is rarely used, the push message of the corresponding application is cached. The application aggregation condition 2 indicates that, in the case where the application use is set not to allow an activity, the push message of the corresponding application is cached. The application aggregation condition 3 indicates that, in the case where the application level is a low-priority application, the push message of the corresponding application is cached. The application aggregation condition 4 indicates that, in the case where the application use is set to notification mute, the push message of the corresponding application is cached.

It is to be understood that the aggregation condition is only an example made according to the end-side state of the mobile phone 100, and does not constitute a limitation to the aggregation condition in the embodiment of the present application, and the aggregation condition may be combined according to different state parameters in the end-side state of the mobile phone 100, and the embodiment of the present application does not specifically limit the composition of the aggregation condition.

In step S509, the handset 100 transmits the heartbeat packet to the server 200. The heartbeat packet of the mobile phone 100 may or may not include the end-side status of the mobile phone 100. If the transmitted heartbeat packet includes an end-side status, the server 200 may replace the previous end-side status of the handset 100 with the currently received end-side status of the handset 100.

In step S510, the server 200 obtains the cached aggregated push message. Since the server 200 has received the heartbeat packet sent by the handset 100, the server 200 already knows that the handset 100 has actively woken up, and sending the aggregated push message to the handset 100 at this time does not cause the handset 100 to wake up additionally.

In some embodiments of the present application, the server 200 obtains the aggregated push message corresponding to the handset 100 from the cached database of aggregated push messages. By caching the aggregated push message corresponding to the mobile phone 100 by using the database, the aggregated push message corresponding to the mobile phone 100 can be conveniently queried and acquired.

Step S511, the server 200 determines whether to merge the aggregated push message corresponding to the mobile phone 100 into the heartbeat reply packet for pushing, if yes, execute step S512; otherwise, step S513 is executed.

In some embodiments of the present application, the server 200 sends the aggregated push message and the heartbeat reply packet to the handset 100 in two ways: the method comprises a merging mode of integrating the aggregation push message into the heartbeat reply packet for sending and a separating mode of respectively sending the aggregation push message and the heartbeat reply packet. The server 200 may determine which method to transmit according to a preset transmission method, or may determine the transmission method according to the data size of the aggregated push message.

Step S512, in case that it is determined that the merging manner is used, the server 200 merges the aggregated push message into the heartbeat reply packet for transmission.

In some embodiments of the present application, the server 200 may send the aggregated push message as the bearer data of the heartbeat reply packet when the data volume of the aggregated push message is less than the data volume that can be borne by the heartbeat reply packet, so as to reduce the number of the sent data packets.

Fig. 6 illustrates a scenario of push incorporating an aggregated push message into a heartbeat reply packet. As shown in fig. 6, the mobile phone 100 sends the end-side state and the heartbeat packet to the server 200, the server 200 receives the push message 2 from the news application and the push message 3 from the financial application, and if the server 200 determines that the push message 2 and the push message 3 are non-urgent messages, the server 200 caches the push message 2 and the push message 3 as aggregated push messages, and after the mobile phone 100 sends the heartbeat packet to the server 200 for the second time, the server 200 obtains the cached aggregated push messages corresponding to the mobile phone 100, combines the aggregated push messages, that is, the push message 2 and the push message 3, with the heartbeat reply packet to form an aggregated data packet, and the server 200 sends the aggregated data packet to the mobile phone 100, and the mobile phone 100 receives and displays the push message 2 and the push message 3.

In step S513, if it is determined that the split manner is used, the server 200 pushes the aggregated push message and the heartbeat reply packet respectively.

In some embodiments of the present application, the server 200 may send the aggregated push message and the heartbeat reply packet respectively when the data volume of the aggregated push message is greater than the data volume that can be borne by the heartbeat reply packet, so that more push messages may be sent.

Fig. 7 shows a scenario in which an aggregated push message is pushed separately from a heartbeat reply packet. As shown in fig. 7, the mobile phone 100 sends the end-side status and the heartbeat packet to the server 200, the server 200 receives the push message 2 from the news application and the push message 3 from the financial application, and if the server 200 determines that the push message 2 and the push message 3 are non-urgent messages, the server 200 caches the push message 2 and the push message 3 as an aggregated push message, and after the mobile phone 100 sends the heartbeat packet to the server 200 for the second time, the server 200 obtains the cached aggregated push message corresponding to the mobile phone 100, and sends the aggregated push message, that is, the push message 2, the push message 3, and the heartbeat reply packet to the mobile phone 100, and the mobile phone 100 receives and displays the push message 2 and the push message 3, respectively.

In step S514, after receiving the aggregated push message, the mobile phone 100 sends the push message to the corresponding application and displays the push message. The aggregated push message may include push messages of server sides of multiple applications, and the mobile phone 100 parses multiple push messages from the aggregated push message, and sends the multiple push messages to the client sides of the corresponding applications for display.

In addition, fig. 8 shows a schematic structural diagram of an electronic device 800 corresponding to the sending method of the push message, and it can be understood that specific technical details in the sending method of the push message are also applicable to the electronic device 800, and are not described again to avoid repetition.

As shown in fig. 8, the electronic apparatus includes:

a determining module 801, in which a first electronic device determines whether a first heartbeat packet sent by a second electronic device is received when determining that a type of a push message sent to the second electronic device is a first type;

a sending module 802, where the first electronic device sends the push message after receiving the first heartbeat packet sent by the second electronic device.

Fig. 9 shows a schematic structural diagram of the mobile phone 100 according to an embodiment of the present application. As shown in fig. 9, the mobile phone 100 may include a processor 910, a power module 940, a memory 980, a mobile communication module 930, a wireless communication module 920, a sensor module 990, an audio module 950, a camera 970, an interface module 960, keys 901, a display 902, and the like.

It is to be understood that the illustrated structure of the embodiment of the present invention does not specifically limit the mobile phone 100. In other embodiments of the present application, the handset 100 may include more or fewer components than shown, or some components may be combined, some components may be separated, or a different arrangement of components may be used. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

The mobile phone 100 is configured to send a heartbeat packet including an end-side state to the server 200, receive a heartbeat reply packet and an aggregated push message returned by the server 200, and display the aggregated push message.

The processor 910 may include one or more Processing units, for example, Processing modules or Processing circuits that may include a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), a Digital Signal Processor (DSP), a Microprocessor (MCU), an Artificial Intelligence (AI) processor, or a Programmable logic device (FPGA), among others. The different processing units may be separate devices or may be integrated into one or more processors. A memory unit may be provided in the processor 910 for storing instructions and data. In some embodiments, the storage unit in the processor 910 is a cache 980.

The power module 940 may include a power supply, power management components, and the like. The power source may be a battery. The power management component is used for managing the charging of the power supply and the power supply of the power supply to other modules.

The mobile communication module 930 may include, but is not limited to, an antenna, a power amplifier, a filter, a Low Noise Amplifier (LNA), and the like. The mobile communication module 930 may provide a solution for wireless communication including 2G/3G/4G/5G, etc. applied to the handset 100. The mobile communication module 930 may receive electromagnetic waves from the antenna, filter, amplify, etc. the received electromagnetic waves, and transmit the processed electromagnetic waves to the modem processor for demodulation. The mobile communication module 930 may also amplify the signal modulated by the modem processor, and convert the signal into electromagnetic wave through the antenna to radiate the electromagnetic wave. In some embodiments, at least some of the functional modules of the mobile communication module 930 may be disposed in the processor 910. In some embodiments, at least some of the functional modules of the mobile communication module 930 may be disposed in the same device as at least some of the modules of the processor 910.

The wireless communication module 920 may include an antenna, and implement transceiving of electromagnetic waves via the antenna. The wireless communication module 920 may provide solutions for wireless communication applied to the mobile phone 100, including Wireless Local Area Networks (WLANs), wireless fidelity (Wi-Fi) networks, Bluetooth (BT), Global Navigation Satellite Systems (GNSS), Frequency Modulation (FM), Near Field Communication (NFC), Infrared (IR), and the like. The handset 100 may communicate with a network and other devices via wireless communication techniques. In addition, the wireless communication module is used for receiving and checking the network data packets with the marks, aggregating the network data packets from the applications with high network delay requirements and belonging to the same data segment, and sending the aggregated network data packets as the same batch of sending data packets.

In some embodiments, the mobile communication module 930 and the wireless communication module 920 of the handset 100 may also be located in the same module.

The display screen 902 is used for displaying human-computer interaction interfaces, images, videos and the like. The display screen 902 includes a display panel.

The sensor module 990 may include a proximity light sensor, a pressure sensor, a gyroscope sensor, an air pressure sensor, a magnetic sensor, an acceleration sensor, a distance sensor, a fingerprint sensor, a temperature sensor, a touch sensor, an ambient light sensor, a bone conduction sensor, and the like.

The audio module 950 is used to convert digital audio information into an analog audio signal for output, or convert an analog audio input into a digital audio signal. The audio module 950 may also be used to encode and decode audio signals. In some embodiments, audio module 950 may include speakers, an earpiece, a microphone, and a headphone interface.

The camera 970 is used to capture still images or video. The object generates an optical image through the lens and projects the optical image to the photosensitive element. The photosensitive element converts the optical Signal into an electrical Signal, and then transmits the electrical Signal to an Image Signal Processing (ISP) to be converted into a digital Image Signal.

The interface module 960 includes an external memory interface, a Universal Serial Bus (USB) interface, a Subscriber Identity Module (SIM) card interface, and the like. The external memory interface may be used to connect an external memory card, such as a Micro SD card, to extend the storage capability of the mobile phone 100. The external memory card communicates with the processor 910 through an external memory interface to implement a data storage function. The usb interface is used for communication between the mobile phone 100 and other electronic devices. The SIM card interface is used to communicate with a SIM card mounted to the handset 100.

In some embodiments, the handset 100 also includes keys 901, motors, indicators, and the like. The keys 901 may include a volume key, an on/off key, and the like. The motor is used to generate a vibration effect to the mobile phone 100, for example, when the mobile phone 100 is called, to prompt the user to answer the call of the mobile phone 100. The indicators may include laser indicators, radio frequency indicators, LED indicators, and the like.

Referring now to fig. 10, a block diagram of a software structure of a mobile phone 100 in an embodiment of the present application is shown. The mobile phone can be used for sending a heartbeat packet containing an end-side state to the server, receiving a heartbeat reply packet and an aggregated push message returned by the server, and displaying the aggregated push message.

Fig. 10 shows that the software system of the mobile phone 100 may adopt a layered architecture, an event-driven architecture, a micro-core architecture, a micro-service architecture, or a cloud architecture. The embodiment of the present invention uses an Android system with a layered architecture as an example to exemplarily illustrate a software structure of the mobile phone 100.

The layered architecture divides the software into several layers, each layer having a clear role and division of labor. The layers communicate with each other through a software interface. In some embodiments, the Android system is divided into four layers, an application layer, an application framework layer, an Android runtime (Android runtime) and system library, and a kernel layer from top to bottom.

The application layer may include a series of application packages.

As shown in fig. 10, the application package may include phone, camera, gallery, calendar, call, map, navigation, WLAN, bluetooth, music, video, short message, etc. applications.

The application framework layer provides an Application Programming Interface (API) and a programming framework for the application program of the application layer. The application framework layer includes a number of predefined functions.

As shown in FIG. 10, the application framework layers may include a window manager, content provider, view system, phone manager, resource manager, notification manager, and the like.

The window manager is used for managing window programs. The window manager can obtain the size of the display screen, judge whether a status bar exists, lock the screen, intercept the screen and the like.

The content provider is used to store and retrieve data and make it accessible to applications. The data may include video, images, audio, calls made and received, browsing history and bookmarks, phone books, etc.

The view system includes visual controls such as controls to display text, controls to display pictures, and the like. The view system may be used to build applications. The display interface may be composed of one or more views. For example, the display interface including the short message notification icon may include a view for displaying text and a view for displaying pictures.

The telephone manager is used for providing a communication function of the terminal equipment. Such as management of call status (including on, off, etc.).

The resource manager provides various resources for the application, such as localized strings, icons, pictures, layout files, video files, and the like.

The notification manager enables the application to display notification information in the status bar, can be used to convey notification-type messages, can disappear automatically after a short dwell, and does not require user interaction. Such as a notification manager used to notify download completion, message alerts, etc. The notification manager may also be a notification that appears in the form of a chart or scroll bar text at the top status bar of the system, such as a notification of a background running application, or a notification that appears on the screen in the form of a dialog window. For example, text information is prompted in the status bar, a prompt tone is given, the terminal device vibrates, an indicator light flickers, and the like.

The Android Runtime comprises a core library and a virtual machine. The Android runtime is responsible for scheduling and managing an Android system.

The core library comprises two parts: one part is a function which needs to be called by java language, and the other part is a core library of android.

The application layer and the application framework layer run in a virtual machine. And executing java files of the application program layer and the application program framework layer into a binary file by the virtual machine. The virtual machine is used for performing the functions of object life cycle management, stack management, thread management, safety and exception management, garbage collection and the like.

The system library may include a plurality of functional modules. For example: surface managers (surface managers), Media Libraries (Media Libraries), three-dimensional graphics processing Libraries (e.g., OpenGL ES), 2D graphics engines (e.g., SGL), and the like.

The surface manager is used to manage the display subsystem and provide fusion of 2D and 3D layers for multiple applications.

The media library supports a variety of commonly used audio, video format playback and recording, and still image files, among others. The media library may support a variety of audio-video encoding formats, such as: MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, etc.

The three-dimensional graphic processing library is used for realizing three-dimensional graphic drawing, image rendering, composition, layer processing and the like.

The 2D graphics engine is a drawing engine for 2D drawing.

The kernel layer is a layer between hardware and software. The inner core layer at least comprises a display driver, a camera driver, an audio driver and a sensor driver.

While the present application has been shown and described with reference to certain preferred embodiments thereof, it will be understood by those of ordinary skill in the art that various changes in form and details may be made therein without departing from the spirit and scope of the present application.

Claims

1. A method for sending a push message, comprising:

and the first electronic equipment sends the push message after receiving the first heartbeat packet sent by the second electronic equipment.

2. The method of claim 1, further comprising:

the first electronic equipment sends the push message to the second electronic equipment under the condition that the type of the push message sent to the second electronic equipment is judged to be the second type.

3. The method according to claim 1 or 2, characterized in that the method further comprises:

and sending, by the first electronic device, a push message to the second electronic device when a third heartbeat packet sent before the first heartbeat packet includes an end-side state of the second electronic device and the first electronic device determines, according to the end-side state, that a type of the push message sent by the second electronic device is a second type, where the end-side state includes at least one of the following information: a system state; the application state.

4. The method of claim 3, wherein the system state comprises at least one of: screen-off time and system mode, the application state includes at least one of the following: application usage, application usage settings, and application levels.

5. The method of claim 1, wherein the first electronic device sends the push message after receiving the first heartbeat packet sent by the second electronic device, and wherein the sending comprises:

and after receiving the first heartbeat packet sent by the second electronic equipment, the first electronic equipment returns a second heartbeat packet to the second electronic equipment and simultaneously sends the push message.

6. The method of claim 5, wherein the first electronic device returning a second heartbeat packet to the second electronic device and simultaneously sending the push message comprises:

the first electronic device merges the push message into a second heartbeat package and sends the second heartbeat package to the second electronic device.

7. The method of claim 5, wherein the first electronic device returning a second heartbeat packet to the second electronic device and simultaneously sending the push message comprises:

8. The method of claim 1, wherein the first electronic device sends the push message after receiving the first heartbeat packet sent by the second electronic device, and wherein the sending comprises:

and after receiving the first heartbeat packet sent by the second electronic equipment, the first electronic equipment sends the push message to the second electronic equipment within preset time.

9. The method of claim 8, further comprising:

the processor of the second electronic device is not in a sleep state for the predetermined time.

10. An electronic device, comprising:

and the sending module is used for sending the push message after the first electronic equipment receives the first heartbeat packet sent by the second electronic equipment.

11. A readable medium having stored thereon instructions that, when executed on an electronic device, cause the electronic device to perform the method of any one of claims 1 to 9.

12. An electronic device, comprising: a memory for storing instructions for execution by one or more processors of a system, and the processor, being one of the processors of the system, for performing the method of any one of claims 1 to 9.