WO2017181709A1 - 推送消息获取、消息推送方法及装置 - Google Patents

推送消息获取、消息推送方法及装置 Download PDF

Info

Publication number
WO2017181709A1
WO2017181709A1 PCT/CN2016/111303 CN2016111303W WO2017181709A1 WO 2017181709 A1 WO2017181709 A1 WO 2017181709A1 CN 2016111303 W CN2016111303 W CN 2016111303W WO 2017181709 A1 WO2017181709 A1 WO 2017181709A1
Authority
WO
WIPO (PCT)
Prior art keywords
message
request
client
version
pushed
Prior art date
Application number
PCT/CN2016/111303
Other languages
English (en)
French (fr)
Inventor
周杨
张科峰
Original Assignee
北京金山安全软件有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 北京金山安全软件有限公司 filed Critical 北京金山安全软件有限公司
Publication of WO2017181709A1 publication Critical patent/WO2017181709A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/55—Push-based network services

Definitions

  • the present application relates to the field of message push technology, and in particular, to a push message acquisition, a message push method, and an apparatus.
  • client developers attract users' attention, stimulate users' desire to use their clients, and at the same time wake up sleeping users, increase user stickiness, and enable clients to gain long-term vitality and stronger market competitiveness. Avoid pushing messages from the server to the client.
  • the server After the client sends a message push request to its corresponding developer server, the server obtains the register ID of the client from its locally stored registerID database, and determines the message to be pushed, and then the obtained registerID and the above-mentioned
  • the pushed message is subjected to data encapsulation processing, and the encapsulated data is sent to the GCM server, and the GCM server pushes the to-be-pushed message to the client according to the encapsulated data.
  • the registerID is generated by the client requesting the GCM server, and after the client obtains the registerID fed back by the GCM server, it sends the registerID to the developer server, and the developer server stores the registerID in the local registerID database for subsequent messages. Used when pushing.
  • the client can generally obtain the push message by using the above method, but when the message is pushed to the client through the GCM server, the encapsulated data must include the client's registerID, and the GCM server can successfully perform message push, so only the above registerID database is used.
  • the above manner can be applied to implement message push.
  • the above registerID database cannot guarantee that all client's registerID can be stored, and then the above method is successfully applied. The probability of getting a push message is low.
  • the purpose of the embodiment of the present application is to provide a push message acquisition, message push method and device, so as to solve the technical problem that the probability of the client successfully obtaining the push message is low.
  • the embodiment of the present application discloses a method for obtaining a push message, which is applied to a client, and the method includes:
  • the request result carries version information of the to-be-push message
  • the sending, by the target server, the second request for acquiring the new version of the to-be-push message includes:
  • the method further includes:
  • the method further includes:
  • the method further includes:
  • the sending, by the target server, the first request for the version of the message to be pushed includes:
  • the first request for the version of the message to be pushed is sent to the target server according to the preset time interval, wherein the preset time interval is: a time interval determined according to the usage habit of the user.
  • the method further includes:
  • the embodiment of the present application discloses a message pushing method, which is applied to a server, and the method includes:
  • the first request carries first version information of the to-be-push message stored by the client;
  • the obtaining the information of the version of the message to be pushed according to the first request, and generating the request result includes:
  • the result of the request is generated based on the judgment result.
  • the obtaining the second version information of the to-be-push message stored locally includes:
  • the basic information includes: language information used by the client, and a geographical location of the client Location information, version information of an operating system of the terminal where the client is located, and version information of the client.
  • the pushing the new version of the to-be-sent message to the client according to the second request includes:
  • the basic information includes: language information used by the client, a geographical location of the client, version information of an operating system of the terminal where the client is located, and version information of the client.
  • the embodiment of the present application further discloses a push message acquiring device, which is applied to a client, where the device includes: a first request sending module, a first receiving module, a second request sending module, and a first to-be-pushed message.
  • Receiving module includes: a first request sending module, a first receiving module, a second request sending module, and a first to-be-pushed message.
  • the first request sending module is configured to send, to the target server, a first request for a version of the message to be pushed;
  • the first receiving module is configured to receive a request result that is fed back by the target server according to the first request;
  • the second request sending module configured to send, to the target server, a new version of the to-be-push message when the new version of the to-be-push message exists in the target server is confirmed according to the request result Two requests;
  • the first to-be-polished message receiving module is configured to receive the to-be-push message of the new version that the target server pushes according to the second request.
  • the request result received by the first receiving module carries version information of the to-be-push message
  • the second request sending module includes: a first determining submodule, a determining result determining submodule, and a second request sending submodule,
  • the first determining sub-module is configured to determine whether the version information carried in the request result is higher than the version information of the to-be-push message stored locally;
  • the determination result determining submodule is configured to determine that a new version of the to-be-push message exists in the target server when the determination result obtained by the first determining sub-module is YES;
  • the second request sending submodule is configured to send, to the target server, a new version of the location A second request to push the message.
  • the device further includes:
  • a first message receiving module configured to receive a first message pushed by a third-party server
  • a first determining module configured to determine, according to the message identifier carried in the first message, whether the first message has been received
  • a first discarding module configured to discard the first message when the judgment result obtained by the first judging module is YES;
  • the first display module is configured to display the first message when the determination result obtained by the first determining module is negative.
  • the device further includes:
  • a first instruction receiving module configured to receive a first instruction sent by a third-party server to obtain a second message to be pushed
  • a third request sending module configured to send, according to the first instruction, a third request for acquiring the second message to the target server
  • a second message receiving module configured to receive the second message that is sent by the target server according to the third request
  • a second determining module configured to determine, according to the message identifier carried in the second message, whether the second message has been received
  • a second discarding module configured to discard the second message when the judgment result obtained by the second judging module is YES;
  • the second display module is configured to display the second message when the determination result obtained by the second determining module is negative.
  • the device further includes:
  • a second instruction receiving module configured to receive a second instruction that is sent by a third-party server to obtain a third message to be pushed, where the second instruction carries a message identifier of the third message;
  • a third determining module configured to determine, according to the message identifier of the third message, whether the third message has been received
  • a fourth request sending module configured to send, according to the second instruction, a fourth request for acquiring the third message according to the second instruction, when the determining result obtained by the third determining module is negative;
  • a third message receiving module configured to receive the third message that is sent by the target server according to the fourth request.
  • the first request sending module is specifically configured to target to the target according to a preset time interval.
  • the server sends a first request for a version of the message to be pushed, wherein the preset time interval is: a time interval determined according to a usage habit of the user.
  • the device further includes:
  • the basic information detecting module is configured to detect whether the basic information of the user changes
  • a fifth request sending module configured to send, when the detection result obtained by the basic information detecting module is YES, a fifth request for acquiring the to-be-push message to the target server;
  • the second to-be-polished message receiving module is configured to receive the to-be-push message pushed by the target server according to the fifth request.
  • the embodiment of the present application further discloses a message pushing apparatus, which is applied to a server, where the apparatus includes: a first request receiving module, a request result sending module, a second request receiving module, and a pushing module;
  • the first request receiving module is configured to receive a first request sent by a client for a version of a message to be pushed;
  • the request result sending module is configured to obtain information about a version of the to-be-push message according to the first request, generate a request result, and send the request result to the client;
  • the second request receiving module is configured to receive a second request for acquiring a new version of the to-be-sent message sent by the client, where the second request is: the client confirms according to the request result Sent when the server has a new version of the message to be pushed;
  • the pushing module is configured to push a new version of the to-be-pushed message to the client according to the second request.
  • the first request carries first version information of the to-be-push message stored by the client;
  • the request result sending module includes: a second version obtaining submodule, a determining submodule, and a request result generating submodule,
  • the second version acquisition submodule is configured to obtain second version information of the to-be-push message stored locally;
  • the determining sub-module is configured to determine, according to the first version information and the second version information, whether a new version of the to-be-push message exists locally;
  • the request result generating submodule is configured to generate a request result according to the judgment result obtained by the determining submodule.
  • the second version acquiring the submodule is specifically configured to be used according to the base of the client.
  • the pushing module is configured to obtain a new version of the to-be-push message according to at least one of the basic information of the client and the second request, and push the obtained version to the client.
  • the new version of the to-be-sent message; the basic information includes: language information used by the client, a geographical location of the client, version information of an operating system of the terminal where the client is located, and the client Side version information.
  • the embodiment of the present application provides a storage medium for storing executable code, where the executable code is used to execute the method for obtaining a push message provided by the first aspect of the embodiment of the present application.
  • the embodiment of the present application provides a storage medium for storing executable code, where the executable code is used to execute the message pushing method provided by the second aspect of the embodiment of the present application.
  • the embodiment of the present application provides an application program for performing, at runtime, a method for obtaining a push message provided by the first aspect of the embodiment of the present application.
  • the embodiment of the present application provides an application program for performing the message pushing method provided by the second aspect of the embodiment of the present application at runtime.
  • the embodiment of the present application provides a push message acquiring device, including: a processor, a memory, a communication interface, and a bus;
  • the processor, the memory, and the communication interface are connected by the bus and complete communication with each other;
  • the memory stores executable program code
  • the processor by reading the executable program code stored in the memory, runs a program corresponding to the executable program code for performing the push message obtaining method provided by the first aspect of the embodiment of the present application.
  • the embodiment of the present application provides a message pushing device, including: a processor, a memory, a communication interface, and a bus;
  • the processor, the memory, and the communication interface are connected by the bus and complete communication with each other;
  • the memory stores executable program code
  • the processor by reading the executable program code stored in the memory, runs a program corresponding to the executable program code for performing the message pushing method provided by the second aspect of the embodiment of the present application.
  • the push message acquisition and message push method and device may send a first request for a version of the message to be pushed to the target server; and receive a request result that is fed back by the target server according to the first request; When the request result confirms that the new version of the to-be-push message exists in the target server, send a second request for acquiring a new version of the to-be-push message to the target server; and receiving the target server according to the The second version of the push-to-push message requested to be pushed.
  • the application provides a scheme for obtaining a push message.
  • the probability that the client successfully obtains the message pushed by the target server is high.
  • the message push scheme provided by the embodiment of the present application has a high probability that the server successfully pushes the message to the client.
  • FIG. 1 is a flowchart of a method for acquiring a push message according to an embodiment of the present application
  • FIG. 2 is another flowchart of a method for acquiring a push message according to an embodiment of the present application
  • FIG. 3 is another flowchart of a method for obtaining a push message according to an embodiment of the present application
  • FIG. 4 is another flowchart of a method for acquiring a push message according to an embodiment of the present application
  • FIG. 5 is a structural diagram of a push message acquiring apparatus according to an embodiment of the present application.
  • FIG. 6 is another structural diagram of a push message acquiring apparatus according to an embodiment of the present application.
  • FIG. 7 is another structural diagram of a push message acquiring apparatus according to an embodiment of the present application.
  • FIG. 8 is another structural diagram of a push message acquiring apparatus according to an embodiment of the present application.
  • FIG. 9 is a flowchart of a message pushing method according to an embodiment of the present application.
  • FIG. 10 is a structural diagram of a message pushing apparatus according to an embodiment of the present application.
  • the embodiment of the present invention provides a method and a device for acquiring a push message, which are applied to a client.
  • the embodiment of the present application further provides a message push method and device, which are applied to a server. The following description will be respectively made.
  • the embodiment of the present application provides a method for obtaining a push message, which is applied to a client, and the method includes:
  • the target server may be only a message version control server provided by the client developer, or another server provided by the client developer with the version management function of the message to be pushed.
  • the message to be pushed may be an advertisement that the client developer wants to push to the client, a client version upgrade information, a current news, a new product release, and the like.
  • the version of the message to be pushed may be the time version of the message to be pushed and configured by the client developer on the target server.
  • the first request may only carry the identifier of the client, so that the target server confirms whether there is a new version of the message to be pushed on the target server according to the identifier of the client and the version control record stored on the target server for the client message;
  • the first request may also carry the first version information of the to-be-push message stored by the client, so that the target server obtains the second version information of the to-be-sent message and the first version information of the to-be-sent message carried in the first request. , to determine whether there is a new version of the message to be pushed in the target server.
  • the first version information may be the latest version of the to-be-pushed message that the client has received, and the second version information may be the version information of the to-be-push message newly configured by the client developer.
  • the client may periodically send a first request for the version of the message to be pushed to the target server; however, when the first request is periodically sent to the target server, if the sending period is set longer, the client does not The purpose of pushing the message to the client in time to the client; if the sending period is set to be short, it will inevitably push the message to the user frequently during the user's rest time, causing the user to be bothered.
  • the client may further send a first request for the version of the message to be pushed to the target server according to the preset time interval; wherein the preset time interval may be: a time interval determined according to the usage habit of the user. For example, users use the client frequently between 6 am to 8 am, 11 noon to 2 pm, and from 6 pm to 10 pm, using customers from 8 am to 11 am and 2 pm to 5 pm The frequency of the end is low, from 10:00 pm to 6:00 am the next day Almost no client is used, according to the frequency of the user's use of the client, the above time interval corresponding to 8:00 am, 8:00 am to 2:00 pm, and 6:00 pm to 10:00 pm can be set to a smaller value.
  • the preset time interval may be: a time interval determined according to the usage habit of the user. For example, users use the client frequently between 6 am to 8 am, 11 noon to 2 pm, and from 6 pm to 10 pm, using customers from 8 am to 11 am and 2 pm to 5 pm The frequency of the end is low, from 10:00 pm to 6:00 am
  • the above time interval corresponding to 8:00 am to 11:00 am and 2:00 pm to 5:00 pm can be set to a larger value, such as: 1 hour, you can move from 10:00 to the next day.
  • the above time interval corresponding to the point can be set to a larger value, such as: 6 hours.
  • the preset time interval can be customized by the user who uses the client to further improve the user experience.
  • the result of the request fed back by the target server may be only the confirmation result, that is, confirming that there is a new version of the message to be pushed on the target server, or confirming that there is no new version of the message to be pushed on the target server;
  • the result of the request fed back by the target server may also be the version information of the message to be pushed stored on the target server.
  • the client may determine that there is a new version of the message to be pushed in the target server when the confirmation result is YES; and then send a second request to obtain the new version of the to-be-push message to the target server.
  • the client may determine whether the version information carried in the request result is higher than the version information of the to-be-sent message stored locally; When the result is YES, it is determined that a new version of the to-be-push message exists in the target server; and then a second request to obtain a new version of the to-be-push message is sent to the target server.
  • the second request carries some basic information of the client, and the basic information may include: language information used by the client, geographic location information of the client, and version information of an operating system of the terminal where the client is located. And at least one of the version information of the client, of course, the basic information is not limited to the above.
  • the target server may be a separate to-be-sent message content server provided by the client developer, or may be a server provided by the client developer and having a message version management function to be pushed and a message content management to be pushed, that is,
  • the message version control server and the message content server may be the same server or different servers, but they may all be collectively referred to as target servers.
  • the message to be pushed may be a general term of the message received by the client, that is, the message to be pushed received by the client may be more than one.
  • the target server pushes the message, it does not depend on whether the client's registerID data is saved, but receives the message sent by the client.
  • the push message is pushed to the client after the request is pushed. Therefore, the probability that the client successfully obtains the message pushed by the target server is high.
  • the applicant has proved by a large number of experiments that the probability of the client successfully obtaining the push message is above 94% by applying the push message obtaining method provided by the embodiment shown in FIG. 1 of the present application.
  • the process of obtaining a push message by means of polling detection is: the user directly sends a request for obtaining a new version message to the target server through the client, and when a new version message exists in the server, the corresponding push is sent to the client.
  • the message when there is no new version message in the server, waits for the next request sent by the client to obtain a new version message.
  • the client is required to frequently send a request for obtaining a new version message directly to the server, and the request for obtaining the new version message usually carries some parameters of the client, such as the language used by the client and the country where the client is located.
  • the version of the operating system used by the client, etc., which makes the request for obtaining a new message sent by the client each time requires more network resources. Therefore, the polling detection method in the prior art requires more traffic for the user, which is not economical and practical.
  • the client In the polling detection mode used in the method for obtaining a push message provided by the embodiment of the present application, the client only needs to occupy the first request for the version of the message to be pushed on the target server, which occupies less network resources at a time. Sent to the target server, and only when there is a new version of the to-be-pushed message for the client on the target server, the second request for obtaining the to-be-push message is sent to the target server to obtain the to-be-pushed message for the client. Therefore, the user's traffic can be saved more.
  • the embodiment of the present application further provides another method for obtaining a push message.
  • the method can also include:
  • S201 Receive a first message pushed by a third-party server.
  • the third-party server may be a GCM (Google Cloud Messaging) server, and of course, may be other third-party servers.
  • GCM Google Cloud Messaging
  • This application does not limit this, but the first message stored on the third-party server is also developed by the client. Business configuration.
  • the client may add a message merging mechanism to repeatedly push the message. The message is processed.
  • each message pushed by the target server and each message pushed by the third-party server may carry a unique identifier that identifies the message, and the identifier may be recorded as a pushID.
  • the merging mechanism is specifically: when the client receives the first message pushed by the third-party server, the received message including the first message may be subjected to weight processing by pressing the pushID, and when found in the received message, When the first message has the same pushID message, it is considered that the client has received the same message as the first message.
  • the first message When the first message has been received, the first message is discarded, otherwise the first message is processed as a new message.
  • the embodiment shown in FIG. 2 as a supplementary technical solution of the embodiment shown in FIG. 1 of the present application, can be used to push a client by using a third-party server while using the method for obtaining a push message provided by the embodiment shown in FIG.
  • the message further improves the probability of the client successfully obtaining the push message.
  • the applicant has found through a large number of experiments that when the push message is obtained by using the solution provided by the embodiment shown in FIG. 2, the probability of the client successfully obtaining the push message is above 97%.
  • the client may obtain the to-be-push message by using a third-party server provided by a third party as a main method for obtaining a message to be pushed, and obtain the target server provided by the client developer.
  • the message to be pushed is used as a supplementary way to obtain the message to be pushed.
  • the preset time interval described in step S101 can be appropriately extended, for example, the client sends the first request to the target server at a first fixed time interval (for example, 6 hours), and reduces the frequency at which the client queries the target server. While increasing the probability that the client successfully obtains push messages, save as much traffic and power as possible for the user.
  • the application embodiment further provides another method for obtaining a push message, and the method may further include:
  • S301 Receive a first instruction sent by a third-party server to obtain a second message to be pushed.
  • the third party server may be a GCM server, and A server that can be provided to other third parties, and the second message to be pushed stored on the third-party server is also configured by the client developer.
  • the third-party server does not directly push the second message itself to the client, but pushes the first instruction to the client to enable the client to obtain the second message to be pushed. So that the client obtains the second message to be pushed on the target server according to the first instruction.
  • the client developer implements the push of the second message through the third-party server, but does not disclose the specific content of the second message to the third-party server, thereby ensuring The security of the message that the client developer pushes to the client.
  • the client may send a third request carrying the basic information of the client to the target server to obtain the second message to be pushed stored on the target server.
  • the same message may be repeatedly received in the embodiment shown in FIG. 3 of the present application, which may cause an interruption to the user. Therefore, the client may add a message.
  • the merging mechanism is used to process the repeatedly received message, and the process of specifically processing the repeatedly pushed message is the same as that in the step S202 in the embodiment shown in FIG. 2, and details are not described herein again.
  • a method for obtaining a push message according to the embodiment shown in FIG. 3 is applied.
  • the preset time interval is consistent with the embodiment shown in FIG. 2, the probability that the client successfully obtains the push message is as shown in FIG. 2 .
  • it is also 97% or more, but the embodiment shown in FIG. 3 of the present application further achieves a good effect of obtaining high security of the message to be pushed.
  • the client may directly obtain the to-be-push message as the main method for obtaining the to-be-sent message through the target server provided by the client developer, and the third-party server provided by the third party.
  • the instruction to be pushed is obtained as a supplementary manner of acquiring the message to be pushed.
  • the preset time interval described in step S101 can also be appropriately extended, for example, causing the client to send the first request to the target server at a second fixed time interval (for example, 6 hours). Reduce the frequency of the client querying the target server to save the user the traffic and power as much as possible while improving the probability that the client successfully obtains the message to be pushed and ensures the security of the message to be pushed.
  • the embodiment of the present application further provides another method for obtaining a push message, which may be considered as further optimization of the method provided by the embodiment shown in FIG. 3 of the present application.
  • the method can also include:
  • S401 Receive a second instruction that is sent by a third-party server and obtain a third message to be pushed, where the second instruction carries a message identifier of the third message.
  • the message identifier of the third message to be pushed carried by the second instruction may also be a pushID.
  • the client may find, in the received message, whether there is a message identical to the identifier of the third message, and if yes, the client has received the third message, otherwise, has not received.
  • the client can send a fourth request to the target server to carry the basic information of the client.
  • a method for obtaining a push message provided by the embodiment shown in FIG. 4 is a method for obtaining a third message to be pushed sent by a third-party server.
  • the third message is judged whether it has been received, instead of after the third message is obtained, the processing of the repeatedly received message is omitted, the workload of the client is reduced, and the client is reduced. LF.
  • the embodiment of the present application further provides another method for obtaining a push message, and the method may further include:
  • Step 1 Detect whether the basic information of the user changes; if yes, perform step two;
  • the basic information may include: the language information used by the client, the geographical location of the client, the version information of the operating system of the terminal where the client is located, and the version information of the client, etc., which is not limited by the application.
  • the content contained in the above basic information may include: the language information used by the client, the geographical location of the client, the version information of the operating system of the terminal where the client is located, and the version information of the client, etc., which is not limited by the application. The content contained in the above basic information.
  • Step 2 Send a fifth request for obtaining the to-be-push message to the target server.
  • Step 3 Receive the to-be-push message pushed by the target server according to the fifth request.
  • the purpose of providing this embodiment is to save traffic and power to the client from another aspect.
  • the client After the basic information of the client changes, it indicates that the environment in which the client is located has changed. For the new environment in which the client is located, the version of the message to be pushed that the client developer wants to push to the client. Most likely it is the new version. Therefore, the client does not need to send the first request to the target server to confirm whether the version of the message to be pushed stored on the target server is a new version, but directly sends a fifth request for obtaining the message to be pushed to the target server. In turn, the client saves traffic and power.
  • the client developer wants to push the client's message, if it is weather information, the client does not need to vainly confirm whether the message is a new one before obtaining the message. Version of the message.
  • a method for obtaining a push message may: send a first request for a version of a message to be pushed to a target server; receive a request result that is fed back by the target server according to the first request; and according to the request As a result, when it is confirmed that the new version of the to-be-push message exists in the target server, sending a second request for acquiring a new version of the to-be-push message to the target server; and receiving the target server to push according to the second request The new version of the message to be pushed.
  • the target server Since the target server does not depend on whether it stores the register ID data of the client, but after receiving the second request for obtaining the new version of the to-be-sent message sent by the client, the message is pushed to the client, therefore, the application The embodiment of the present application provides a solution for obtaining a push message, and the probability that the client successfully obtains the message pushed by the target server is high.
  • the present application further provides a push message acquiring apparatus, where the apparatus includes: a first request sending module 501, a first receiving module 502, and a second request sending. Module 503 and first to-be-sent message receiving module 504,
  • the first request sending module 501 is configured to send, to the target server, a first request for a version of the message to be pushed;
  • the target server may be only a message version control server provided by the client developer, or another server provided by the client developer with the version management function of the message to be pushed.
  • the message to be pushed may be an advertisement that the client developer wants to push to the client, client version upgrade information, current news, weather information, new product release, and the like.
  • the version of the message to be pushed may be the time version of the message to be pushed and configured by the client developer on the target server.
  • the first request may only carry the identifier of the client, so that the target server confirms whether there is a new version of the message to be pushed on the target server according to the identifier of the client and the version control record stored on the target server for the client message;
  • the first request may also carry the first version information of the to-be-push message stored by the client, so that the target server obtains the second version information of the to-be-sent message and the first version information of the to-be-sent message carried in the first request. , to determine whether there is a new version of the message to be pushed in the target server.
  • the first version information may be the latest version of the to-be-pushed message that the client has received, and the second version information may be the version information of the to-be-push message newly configured by the client developer.
  • the first request sending module 501 can send a first request for the version of the message to be pushed to the target server according to the preset time interval; wherein the preset time interval is determined according to the usage habit of the user. time interval.
  • the preset time interval is consistent with the preset time interval described in the method embodiment shown in FIG. 1 , and details are not described herein again.
  • the preset time interval can be customized by the user who uses the client to further improve the user experience.
  • the first receiving module 502 is configured to receive a request result that is fed back by the target server according to the first request;
  • the result of the request fed back by the target server may be only the confirmation result, that is, confirming that there is a new version of the message to be pushed on the target server, or confirming that there is no new version of the message to be pushed on the target server;
  • the result of the request fed back by the target server may also be the version information of the message to be sent stored on the target server.
  • a second request sending module 503, configured to send, to the target server, a second version of the to-be-push message obtained by acquiring a new version when the new version of the to-be-push message exists in the target server according to the result of the request request;
  • the target server may be a separate server to be pushed message content provided by the client developer, or may be a server provided by the client developer and having a version management function of the message to be pushed and a content management of the message to be pushed, that is, in the actual application.
  • the message version control server and the message content server may be the same server or different servers, but they may all be collectively referred to as target servers.
  • the second request sending module 503 includes: a first determining submodule, a determining result determining submodule, and a second request sending submodule,
  • a first determining sub-module configured to determine, when carrying the version information of the message to be pushed, whether the version information carried in the request result is higher than the version information of the to-be-sent message stored locally; or Whether the result of the request received by the receiving module 502 is YES;
  • a determination result determining submodule configured to determine that a new version of the to-be-push message exists in the target server when the determination result obtained by the first determining sub-module is YES;
  • a second request sending submodule configured to send, to the target server, a second request for obtaining a new version of the to-be-push message
  • the second request carries some basic information of the client, and the basic information may include: the guest At least one of the language information used by the client, the geographical location information of the client, the version information of the operating system of the terminal where the client is located, and the version information of the client.
  • the basic information is not limited to the above. Several.
  • the first to-be-polished message receiving module 504 is configured to receive the to-be-push message of the new version that the target server pushes according to the second request.
  • the message to be pushed may be a general term of the message received by the client, that is, the message to be pushed received by the client may be more than one.
  • the target server pushes the message, it does not depend on whether it saves the registerID data of the client sent by the client, but receives the client. After the message sent by the terminal pushes the request, the message is pushed to the client. Therefore, the probability that the client successfully obtains the message pushed by the target server is high.
  • the experiment proves that with the push message obtaining device provided by the embodiment shown in FIG. 5 of the present application, the probability that the client successfully obtains the push message is above 94%.
  • the method for obtaining a push message by the polling detection method in the prior art requires the client to directly send a request for obtaining a new version message directly to the server, and the request for obtaining the new version message usually carries some parameters of the client. For example, the language used by the client, the country where the client is located, and the version of the operating system used by the client, etc., make the request for obtaining a new message sent by the client each time occupying more network resources. Therefore, the polling detection method in the prior art requires more traffic for the user, which is not economical and practical.
  • the specific manner of the polling detection in the prior art is the same as that in the method embodiment shown in FIG. 1, and details are not described herein again.
  • the client In the polling detection mode used in the push message obtaining apparatus provided by the embodiment of the present application, the client only needs to occupy the first request for the version of the message to be pushed on the target server, which occupies less network resources at a time. Sent to the target server, and only when there is a new version of the to-be-pushed message for the client on the target server, the second request for obtaining the to-be-push message is sent to the target server to obtain the to-be-pushed message for the client. Therefore, the user's traffic can be saved more.
  • the embodiment of the present application further provides another push message acquiring device.
  • the device may further include: a first message receiving module 601, a first determining module 602, a first discarding module 603, and a first displaying module 604;
  • the first message receiving module 601 is configured to receive a first message pushed by a third-party server
  • the third-party server may be a GCM (Google Cloud Messaging) server, and of course, may be other third-party servers. This application does not limit this, but the third-party service.
  • the first message stored on the server is also configured by the client developer.
  • the first determining module 602 is configured to determine, according to the message identifier carried in the first message, whether the first message has been received;
  • the client may add a message merging mechanism to repeatedly push the message. The message is processed.
  • the first discarding module 603 is configured to discard the first message when the judgment result obtained by the first judging module 602 is YES;
  • the first display module 604 is configured to display the first message when the determination result obtained by the first determining module 602 is negative.
  • the embodiment shown in FIG. 6 can be used as a supplementary technical solution of the embodiment shown in FIG. 5 of the present application, and can be used to push a client by using a third-party server while using the device for obtaining a push message provided by the embodiment shown in FIG. 5 .
  • the message further improves the probability of the client successfully obtaining the push message.
  • the applicant has found through a large number of experiments that when the device provided in the embodiment shown in FIG. 6 obtains the push message, the probability of the client successfully obtaining the push message is above 97%.
  • the client may obtain the to-be-push message by using a third-party server provided by a third party as a main method for obtaining a message to be pushed, and obtain the target server provided by the client developer.
  • the message to be pushed is used as a supplementary way to obtain the message to be pushed.
  • the preset time interval in the first request sending module 501 can be appropriately extended, for example, the client sends the first request to the target server at a first fixed time interval (for example, 6 hours), and reduces the frequency at which the client queries the target server. In order to improve the probability of the client successfully obtaining push messages, save as much traffic and power as possible for the user.
  • the application embodiment further provides another push message obtaining device, and the device may further include: a first instruction receiving module 701, a third request sending module 702, a second message receiving module 703, a second determining module 704, and a second discarding.
  • the first instruction receiving module 701 is configured to receive a first instruction sent by a third-party server to obtain a second message to be pushed;
  • the third request sending module 702 is configured to send, according to the first instruction, a third request for acquiring the second message to the target server;
  • the third-party server does not directly push the second message itself to the client, but pushes the first instruction to the client to enable the client to obtain the second message to be pushed. So that the client obtains the second message to be pushed on the target server according to the first instruction.
  • the client developer implements the push of the second message through the third-party server, but does not disclose the specific content of the second message to the third-party server, thereby ensuring The security of the message that the client developer pushes to the client.
  • the third request sending module 702 may send a third request carrying the basic information of the client to the target server to obtain the second message to be pushed stored on the target server.
  • the second message receiving module 703 is configured to receive the second message that is sent by the target server according to the third request.
  • the second determining module 704 is configured to determine, according to the message identifier carried in the second message, whether the second message has been received.
  • the same message may be repeatedly received in the embodiment shown in FIG. 7 of the present application, which may cause disturbance to the user. Therefore, the client may add a message.
  • the merging mechanism is used to process the repeatedly received message, and the process of specifically processing the repeatedly pushed message is consistent with the embodiment shown in FIG. 6, and details are not described herein again.
  • the second discarding module 705 is configured to discard the second message when the judgment result obtained by the second judging module 704 is YES;
  • the second display module 706 is configured to display the second message when the determination result obtained by the second determining module 704 is negative.
  • the probability that the client successfully obtains the push message is also 97% or more.
  • the embodiment shown in FIG. 7 of the present application further achieves a good effect of obtaining high security of the message to be pushed.
  • the client may directly obtain the to-be-push message as the main to-be-sent message acquisition mode by the target server provided by the client developer, and the third-party server provided by the third party.
  • the preset time interval described in the first request sending module 501 can be appropriately extended to reduce the frequency at which the client queries the target server, so as to improve the probability that the client successfully obtains the message to be pushed and ensure the security of the message to be pushed. At the same time, save as much traffic and power as possible for the user.
  • the embodiment of the present application further provides another push message obtaining device, which can be considered as further optimization of the device provided by the embodiment shown in FIG. 7 of the present application.
  • the device may further include: a second instruction receiving module 801, a third determining module 802, a fourth request sending module 803, and a third message receiving module 804,
  • the second instruction receiving module 801 is configured to receive a second instruction that is sent by a third-party server to obtain a third message to be pushed, where the second instruction carries a message identifier of the third message;
  • the message identifier of the third message to be pushed carried by the second instruction may also be a pushID.
  • the third determining module 802 is configured to determine, according to the message identifier of the third message, whether the third message has been received;
  • the method for processing the repeatedly received message is the same as that in the embodiment shown in FIG. 7, and details are not described herein again.
  • the fourth request sending module 803 is configured to: when the determining result obtained by the third determining module 802 is negative, send a fourth request for acquiring the third message to the target server according to the second instruction;
  • the client can send a fourth request to the target server to carry the basic information of the client.
  • the third message receiving module 804 is configured to receive the third message that is sent by the target server according to the fourth request.
  • the push message obtaining apparatus provided in the embodiment shown in FIG. 4 is received by the third-party server to obtain the third message to be pushed.
  • the third message is judged whether it has been received, instead of after the third message is obtained, the processing of the repeatedly received message is omitted, the workload of the client is reduced, and the client is reduced. LF.
  • the embodiment of the present application further provides another push message acquiring device, which may further include: a basic information detecting module, a fifth request sending module, and a second to-be-pushed Message receiving module
  • the basic information detecting module is configured to detect whether the basic information of the user changes
  • the basic information may include: language information used by the client, geographic location information of the client, version information of an operating system of the terminal where the client is located, and the client.
  • the version information and the like, the application does not limit the content included in the above basic information.
  • a fifth request sending module configured to send, when the detection result obtained by the basic information detecting module is YES, a fifth request for acquiring the to-be-push message to the target server;
  • the second to-be-polished message receiving module is configured to receive the to-be-push message pushed by the target server according to the fifth request.
  • the purpose of providing this embodiment is to save traffic and power to the client from another aspect. Since the environment of the client changes after the basic information of the client changes, the version of the message to be pushed that the client developer wants to push to the client is likely to be new for the new environment in which the client is located. version. Therefore, the client does not need to send the first request to the target server to confirm whether the version of the message to be pushed stored on the target server is a new version, but directly sends a fifth request for obtaining the message to be pushed to the target server. In turn, the client saves traffic and power.
  • a push message obtaining apparatus may send a first request for a version of a message to be pushed to a target server; receive a request result that is fed back by the target server according to the first request; and according to the request As a result, when it is confirmed that the new version of the to-be-push message exists in the target server, sending a second request for acquiring a new version of the to-be-push message to the target server; and receiving the target server to push according to the second request The new version of the message to be pushed.
  • the target server Since the target server does not depend on whether it stores the register ID data of the client, but after receiving the second request for obtaining the new version of the to-be-sent message sent by the client, the message is pushed to the client, therefore, the application The embodiment of the present application provides a solution for obtaining a push message, and the probability that the client successfully obtains the message pushed by the target server is high.
  • the following describes a message pushing method and apparatus for a server.
  • the embodiment of the present application provides a message pushing method, which is applied to a server, and the method may include:
  • S901. Receive a first request sent by a client for a version of a message to be pushed.
  • the first request may only carry the identifier of the client; the first request may further carry the first version information of the to-be-sent message stored by the client; wherein the first version information may be the latest version of the to-be-push message that the client has received.
  • the server may maintain a version control record of the message to be pushed for each client, and according to the identifier of the client and the to-be-sent The version control record confirms whether there is a new version of the message to be pushed on the server, and then generates a request result;
  • the server may generate the request result by the following steps:
  • Step 1 obtaining second version information of the to-be-push message stored locally
  • the second version information may be version information of the newly configured to-be-sent message of the client developer.
  • the server may obtain the second version information of the to-be-push message stored locally according to at least one of the basic information of the client, that is, find the locally stored service for the client according to the basic information of the client.
  • a version of the push message includes: language information used by the client, geographic location information of the client, version information of an operating system of the terminal where the client is located, and a version of the client information.
  • Step 2 Determine, according to the first version information and the second version information, whether a new version of the to-be-push message exists locally;
  • the version in the second version information is higher than the version in the first version information, it is determined whether a new version of the to-be-push message exists locally.
  • Step 3 Generate a request result according to the judgment result.
  • the result of the request may simply be the result of confirmation, that is, confirming that there is a new version of the message to be pushed on the target server, or confirming that there is no new version of the message to be pushed on the target server;
  • the result of the request may also be version information of a message to be sent stored on the target server.
  • S903 Receive a second request that is sent by the client to obtain a new version of the to-be-sent message, where the second request is: the client confirms that the server exists in the server according to the request result. Sent when a new version of the message is pushed;
  • the second request can carry the basic information of the client.
  • Obtaining a new version of the to-be-push message according to at least one of the basic information of the client and the second request, and pushing the obtained new version of the to-be-push message to the client; to be pushed Messages can be configured on the server by the client developer and pushed to the client by the server.
  • server that performs the version control of the message to be pushed and the server that pushes the message to be pushed may be the same server or different servers.
  • a message pushing method provided by the embodiment of the present application may receive a first request for a version of a message to be pushed sent by a client, and obtain a version of the message to be pushed according to the first request. And generating a request result, and sending the request result to the client; receiving a second request sent by the client to obtain a new version of the to-be-push message, where the second request is: Transmitting, according to the result of the request, that the new version of the to-be-push message exists in the server, and sending a new version of the to-be-push message to the client according to the second request.
  • the server Since the server does not depend on whether it stores the register ID data of the client, but after receiving the second request for obtaining the new version of the to-be-sent message sent by the client, the server pushes the message to the client, therefore, the application Applying the message pushing scheme provided by the embodiment, the probability that the server successfully pushes the message to the client is high.
  • the embodiment of the present application further provides a message pushing apparatus, where the apparatus may include: a first request receiving module 1001, a request result sending module 1002, and a second Requesting receiving module 1003 and pushing module 1004;
  • the first request receiving module 1001 is configured to receive a first request sent by the client for a version of the message to be pushed;
  • the first request may only carry the identifier of the client; the first request may further carry the first version information of the to-be-sent message stored by the client; wherein the first version information may be the latest version of the to-be-push message that the client has received.
  • the request result sending module 1002 is configured to obtain version information of the to-be-push message according to the first request, generate a request result, and send the request result to the client;
  • the server may maintain a version control record of the message to be pushed for each client, and the request result sending module 1002 may confirm the server according to the identifier of the client and the version control record of the message to be pushed. Whether there is a new version of the message to be pushed on, and then generate a request result;
  • the request result sending module 1002 may include: a second version obtaining submodule, a determining submodule, and a request result generating submodule,
  • the second version acquisition sub-module is configured to obtain the second version information of the to-be-push message stored locally when the first request carries the first version information of the to-be-sent message stored by the client;
  • the second version information may be version information of the newly configured to-be-sent message of the client developer.
  • the second version obtaining sub-module may be configured to obtain the second version information of the to-be-push message stored locally according to at least one of the basic information of the client, that is, find the service local according to the basic information of the client.
  • the basic information includes: language information used by the client, geographic location information of the client, version information of an operating system of the terminal where the client is located, and The version information of the client.
  • the determining sub-module is configured to determine, according to the first version information and the second version information, whether a new version of the to-be-push message exists locally;
  • the version in the second version information is higher than the version in the first version information, it is determined whether a new version of the to-be-push message exists locally.
  • the request result generating submodule is configured to generate a request result according to the judgment result obtained by the determining submodule.
  • the result of the request may simply be the result of confirmation, that is, confirming that there is a new version of the message to be pushed on the target server, or confirming that there is no new version of the message to be pushed on the target server;
  • the result of the request may also be version information of a message to be sent stored on the target server.
  • the second request receiving module 1003 is configured to receive a second request for acquiring a new version of the to-be-sent message sent by the client, where the second request is: the client confirms the location according to the request result Sent when there is a new version of the message to be pushed in the server;
  • the second request can carry the basic information of the client.
  • the pushing module 1004 is configured to push a new version of the to-be-push message to the client according to the second request.
  • the pushing module 1004 is configured to obtain a new version of the to-be-push message according to at least one of the basic information of the client and the second request, and push the obtained new version to the client.
  • the to-be-pushed message; wherein the to-be-pushed message can be configured by the client developer on the server and pushed by the server to the client.
  • the message pushing device may receive a first request for a version of the message to be pushed sent by the client, obtain information about the version of the message to be pushed according to the first request, and generate a request result. And sending the request result to the client, and receiving, by the client, a second request for acquiring a new version of the to-be-push message, where the second request is: the client according to the request. The result is sent when the new version of the message to be pushed exists in the server; and the new version of the to-be-push message is pushed to the client according to the second request.
  • the server Since the server does not depend on whether it stores the register ID data of the client, but after receiving the second request for obtaining the new version of the to-be-sent message sent by the client, the server pushes the message to the client, therefore, the application Applying the message pushing scheme provided by the embodiment, the probability that the server successfully pushes the message to the client is high.
  • the embodiment of the present application provides a storage medium for storing executable code, which is used to execute at runtime:
  • the method for obtaining a push message provided by the embodiment of the present application; specifically, the method for obtaining a push message includes:
  • the storage medium stores an application that executes the push message obtaining method provided by the embodiment of the present application at the time of running, thereby achieving the purpose of improving the probability that the client successfully obtains the message pushed by the target server.
  • the embodiment of the present application provides a storage medium for storing executable code, where the executable code is used to execute the message provided by the embodiment of the present application.
  • Push method specifically, the message pushing method includes:
  • the storage medium stores an application that executes the message pushing method provided by the embodiment of the present application at runtime, thereby achieving the purpose of improving the probability of successfully pushing a message to the client.
  • the embodiment of the present application provides an application program for performing, at runtime, a method for obtaining a push message provided by the embodiment of the present application; specifically, the push message is Acquisition methods, including:
  • the application performs the push message obtaining method provided by the embodiment of the present application at the time of running, thereby achieving the purpose of improving the probability that the client successfully obtains the message pushed by the target server.
  • the embodiment of the present application provides an application program, which is used to perform the message pushing method provided by the embodiment of the present application.
  • the message pushing method includes :
  • the application performs the message pushing method provided by the embodiment of the present application at runtime, so that the purpose of improving the probability of successfully pushing the message to the client can be achieved.
  • the embodiment of the present application provides a push message acquiring device, including: a processor, a memory, a communication interface, and a bus;
  • the processor, the memory, and the communication interface are connected by the bus and complete communication with each other;
  • the memory stores executable program code
  • the processor by reading the executable program code stored in the memory, to run a program corresponding to the executable program code, for performing the push message obtaining method provided by the embodiment of the present application;
  • the method for obtaining a push message includes:
  • the push message acquiring device runs a program corresponding to the executable program code by reading executable program code stored in the memory, and the program executes the application at runtime
  • the push message obtaining method provided by the embodiment can achieve the purpose of improving the probability that the client successfully obtains the message pushed by the target server.
  • the embodiment of the present application provides a message pushing device, including: a processor, a memory, a communication interface, and a bus;
  • the processor, the memory, and the communication interface are connected by the bus and complete communication with each other;
  • the memory stores executable program code
  • the processor by reading the executable program code stored in the memory, to run a program corresponding to the executable program code, for performing: the message pushing method provided by the embodiment of the present application; specifically, the Message push methods include:
  • the message pushing device runs the program corresponding to the executable program code by reading the executable program code stored in the memory, and the program executes the message pushing method provided by the embodiment of the present application at runtime, thereby enabling Implementation: Improve the probability of successfully pushing messages to the client.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本申请实施例提供的推送消息获取、消息推送方法及装置，可以向目标服务器发送针对待推送消息的版本的第一请求；接收目标服务器根据第一请求反馈的请求结果；在根据请求结果确认目标服务器中存在待推送消息的新版本时，向目标服务器发送获取新版本的待推送消息的第二请求；接收目标服务器根据第二请求推送的新版本的待推送消息。由于目标服务器并不依赖于自身是否保存有客户端的registerID数据，而是在接收到客户端发送的获取新版本的待推送消息的第二请求后，便向客户端推送消息，因此，应用本申请实施例提供的方案，客户端成功获取目标服务器推送的消息的概率高，服务器向客户端成功推送消息的概率也高。

Description

推送消息获取、消息推送方法及装置
本申请要求于2016年04月19日提交中国专利局、申请号为201610245239.4、发明名称为“推送消息获取、消息推送方法及装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及消息推送技术领域，特别是涉及推送消息获取、消息推送方法及装置。
背景技术
客户端开发商为了提高其客户端的活跃度，引起用户关注，激发用户对其客户端的使用欲望，同时唤醒沉睡用户，增加用户粘性，使客户端获得长久的生命力和更强大的市场竞争力，不可避免地要从服务器向客户端推送消息。
以基于安卓操作系统的客户端为例，现有技术中一般是通过Google提供的GCM(Google Cloud Messaging)服务来实现消息推送的，具体过程如下：
客户端向其对应的开发商服务器发送消息推送请求后，服务器从其本地存储的registerID(注册标识)数据库中获得上述客户端的registerID，并确定要推送的消息，然后对所获得的registerID和上述要推送的消息进行数据封装处理，并将封装后的数据发送至GCM服务器，由GCM服务器根据上述封装后的数据向客户端推送上述待推送消息。
其中，registerID是客户端请求GCM服务器生成的，客户端获得GCM服务器反馈的registerID后，将其发送至上述开发商服务器，上述开发商服务器将该registerID存储至本地的registerID数据库中，以备后续消息推送时使用。
客户端一般能够应用上述方式获得推送消息，但是由于通过GCM服务器向客户端推送消息时，上述封装后的数据中必须包含客户端的registerID，GCM服务器才能成功进行消息推送，所以，只有上述registerID数据库中存储有该客户端的registerID的情况下才能应用上述方式实现消息推送。而实际应用中由于客户端未及时请求GCM服务器为其生成registerID或者由于GCM服务器自身因素无法及时为客户端生成registerID等原因，上述registerID数据库无法保证能够存储有所有客户端的registerID，进而应用上述方式成功获取推送消息的概率偏低。
发明内容
本申请实施例的目的在于提供推送消息获取、消息推送方法及装置，以解决客户端成功获取推送消息的概率偏低的技术问题。
第一方面，本申请实施例公开了一种推送消息获取方法，应用于客户端，所述方法包括：
向目标服务器发送针对待推送消息的版本的第一请求；
接收所述目标服务器根据所述第一请求反馈的请求结果；
在根据所述请求结果确认所述目标服务器中存在所述待推送消息的新版本时，向所述目标服务器发送获取新版本的所述待推送消息的第二请求；
接收所述目标服务器根据所述第二请求推送的新版本的所述待推送消息。
可选的，所述请求结果中携带所述待推送消息的版本信息；
所述在根据所述请求结果确认所述目标服务器中存在所述待推送消息的新版本时，向所述目标服务器发送获取新版本的所述待推送消息的第二请求包括：
判断所述请求结果中携带的版本信息是否高于本地存储的所述待推送消息的版本信息；
若为是，判定所述目标服务器中存在所述待推送消息的新版本；
向所述目标服务器发送获取新版本的所述待推送消息的第二请求。
可选的，所述方法还包括：
接收第三方服务器推送的第一消息；
根据所述第一消息携带的消息标识，判断是否已接收过所述第一消息；
如果是，将所述第一消息丢弃；
否则，展示所述第一消息。
可选的，所述方法还包括：
接收第三方服务器发送的获取待推送的第二消息的第一指令；
根据所述第一指令，向所述目标服务器发送获取所述第二消息的第三请求；
接收所述目标服务器根据所述第三请求推送的所述第二消息；
根据所述第二消息携带的消息标识，判断是否已接收过所述第二消息；
如果是，将所述第二消息丢弃；
否则，展示所述第二消息。
可选的，所述方法还包括：
接收第三方服务器发送的获取待推送的第三消息的第二指令，其中，所述第二指令携带有所述第三消息的消息标识；
根据所述第三消息的消息标识，判断是否已接收过所述第三消息；
如果否，根据所述第二指令，向所述目标服务器发送获取所述第三消息的第四请求；
接收所述目标服务器根据所述第四请求推送的所述第三消息。
可选的，所述向目标服务器发送针对待推送消息的版本的第一请求包括：
按照预设的时间间隔向目标服务器发送针对待推送消息的版本的第一请求，其中，所述预设的时间间隔为：根据用户的使用习惯确定的时间间隔。
可选的，所述方法还包括：
检测自身的基本信息是否发生变化；
如果是，向所述目标服务器发送获取所述待推送消息的第五请求；
接收所述目标服务器根据所述第五请求推送的所述待推送消息。
第二方面，本申请实施例公开了一种消息推送方法，应用于服务器，所述方法包括：
接收客户端发送的针对待推送消息的版本的第一请求；
根据所述第一请求获得所述待推送消息的版本的信息，生成请求结果，并向所述客户端发送所述请求结果；
接收所述客户端发送的获取新版本的所述待推送消息的第二请求，其中，所述第二请求为：所述客户端根据所述请求结果确认所述服务器中存在所述待推送消息的新版本时发送的；
根据所述第二请求向所述客户端推送新版本的所述待推送消息。
可选的，所述第一请求携带所述客户端存储的所述待推送消息的第一版本信息；
所述根据所述第一请求获得所述待推送消息的版本的信息，生成请求结果，包括：
获得本地存储的所述待推送消息的第二版本信息；
根据所述第一版本信息和所述第二版本信息，判断本地是否存在所述待推送消息的新版本；
根据判断结果生成请求结果。
可选的，所述获得本地存储的所述待推送消息的第二版本信息，包括：
根据所述客户端的基本信息中的至少一种，获得本地存储的所述待推送消息的第二版本信息；所述基本信息包括：所述客户端使用的语言信息、所述客户端所处地理位置信息、所述客户端所在终端的操作系统的版本信息和所述客户端的版本信息。
可选的，所述根据所述第二请求向所述客户端推送新版本的所述待推送消息，包括：
根据所述客户端的基本信息中的至少一种以及所述第二请求，获得所述待推送消息的新版本，并向所述客户端推送所获得的新版本的所述待推送消息；所述基本信息包括：所述客户端使用的语言信息、所述客户端所处地理位置、所述客户端所在终端的操作系统的版本信息和所述客户端的版本信息。
第三方面，本申请实施例还公开了一种推送消息获取装置，应用于客户端，所述装置包括：第一请求发送模块、第一接收模块、第二请求发送模块和第一待推送消息接收模块；
所述第一请求发送模块，用于向目标服务器发送针对待推送消息的版本的第一请求；
所述第一接收模块，用于接收所述目标服务器根据所述第一请求反馈的请求结果；
所述第二请求发送模块，用于在根据所述请求结果确认所述目标服务器中存在所述待推送消息的新版本时，向所述目标服务器发送获取新版本的所述待推送消息的第二请求；
所述第一待推送消息接收模块，用于接收所述目标服务器根据所述第二请求推送的新版本的所述待推送消息。
可选的，所述第一接收模块接收的所述请求结果中携带所述待推送消息的版本信息；
所述第二请求发送模块包括：第一判断子模块、判定结果确定子模块和第二请求发送子模块，
所述第一判断子模块，用于判断所述请求结果中携带的版本信息是否高于本地存储的所述待推送消息的版本信息；
所述判定结果确定子模块，用于在所述第一判断子模块获得的判断结果为是时，判定所述目标服务器中存在所述待推送消息的新版本；
所述第二请求发送子模块，用于向所述目标服务器发送获取新版本的所 述待推送消息的第二请求。
可选的，所述装置还包括：
第一消息接收模块，用于接收第三方服务器推送的第一消息；
第一判断模块，用于根据所述第一消息携带的消息标识，判断是否已接收过所述第一消息；
第一丢弃模块，用于在所述第一判断模块获得的判断结果为是时，将所述第一消息丢弃；
第一展示模块，用于在所述第一判断模块获得的判断结果为否时，展示所述第一消息。
可选的，所述装置还包括：
第一指令接收模块，用于接收第三方服务器发送的获取待推送的第二消息的第一指令；
第三请求发送模块，用于根据所述第一指令，向所述目标服务器发送获取所述第二消息的第三请求；
第二消息接收模块，用于接收所述目标服务器根据所述第三请求推送的所述第二消息；
第二判断模块，用于根据所述第二消息携带的消息标识，判断是否已接收过所述第二消息；
第二丢弃模块，用于在所述第二判断模块获得的判断结果为是时，将所述第二消息丢弃；
第二展示模块，用于在所述第二判断模块获得的判断结果为否时，展示所述第二消息。
可选的，所述装置还包括：
第二指令接收模块，用于接收第三方服务器发送的获取待推送的第三消息的第二指令，其中，所述第二指令携带有所述第三消息的消息标识；
第三判断模块，用于根据所述第三消息的消息标识，判断是否已接收过所述第三消息；
第四请求发送模块，用于在所述第三判断模块获得的判断结果为否时，根据所述第二指令，向所述目标服务器发送获取所述第三消息的第四请求；
第三消息接收模块，用于接收所述目标服务器根据所述第四请求推送的所述第三消息。
可选的，所述第一请求发送模块，具体用于按照预设的时间间隔向目标 服务器发送针对待推送消息的版本的第一请求，其中，所述预设的时间间隔为：根据用户的使用习惯确定的时间间隔。
可选的，所述装置还包括：
基本信息检测模块，用于检测自身的基本信息是否发生变化；
第五请求发送模块，用于在所述基本信息检测模块获得的检测结果为是时，向所述目标服务器发送获取所述待推送消息的第五请求；
第二待推送消息接收模块，用于接收所述目标服务器根据所述第五请求推送的所述待推送消息。
第四方面，本申请实施例还公开了一种消息推送装置，应用于服务器，所述装置包括：第一请求接收模块、请求结果发送模块、第二请求接收模块和推送模块；
所述第一请求接收模块，用于接收客户端发送的针对待推送消息的版本的第一请求；
所述请求结果发送模块，用于根据所述第一请求获得所述待推送消息的版本的信息，生成请求结果，并向所述客户端发送所述请求结果；
所述第二请求接收模块，用于接收所述客户端发送的获取新版本的所述待推送消息的第二请求，其中，所述第二请求为：所述客户端根据所述请求结果确认所述服务器中存在所述待推送消息的新版本时发送的；
所述推送模块，用于根据所述第二请求向所述客户端推送新版本的所述待推送消息。
可选的，所述第一请求携带所述客户端存储的所述待推送消息的第一版本信息；
所述请求结果发送模块包括：第二版本获取子模块、判断子模块和请求结果生成子模块，
所述第二版本获取子模块，用于获得本地存储的所述待推送消息的第二版本信息；
所述判断子模块，用于根据所述第一版本信息和所述第二版本信息，判断本地是否存在所述待推送消息的新版本；
所述请求结果生成子模块，用于根据所述判断子模块获得的判断结果生成请求结果。
可选的，所述所述第二版本获取子模块，具体用于根据所述客户端的基 本信息中的至少一种，获得本地存储的所述待推送消息的第二版本信息；所述基本信息包括：所述客户端使用的语言信息、所述客户端所处地理位置信息、所述客户端所在终端的操作系统的版本信息和所述客户端的版本信息。
可选的，所述推送模块，具体用于根据所述客户端的基本信息中的至少一种以及所述第二请求，获得所述待推送消息的新版本，并向所述客户端推送所获得的新版本的所述待推送消息；所述基本信息包括：所述客户端使用的语言信息、所述客户端所处地理位置、所述客户端所在终端的操作系统的版本信息和所述客户端的版本信息。
第五方面，本申请实施例提供了一种存储介质，用于存储可执行代码，所述可执行代码在运行时用于执行：本申请实施例第一方面提供的推送消息获取方法。
第六方面，本申请实施例提供了一种存储介质，用于存储可执行代码，所述可执行代码在运行时用于执行：本申请实施例第二方面提供的消息推送方法。
第七方面，本申请实施例提供了一种应用程序，用于在运行时执行：本申请实施例第一方面提供的推送消息获取方法。
第八方面，本申请实施例提供了一种应用程序，用于在运行时执行本申请实施例第二方面提供的消息推送方法。
第九方面，本申请实施例提供了一种推送消息获取设备，包括：处理器、存储器、通信接口和总线；
所述处理器、所述存储器和所述通信接口通过所述总线连接并完成相互间的通信；
所述存储器存储可执行程序代码；
所述处理器通过读取所述存储器中存储的可执行程序代码来运行与所述可执行程序代码对应的程序，以用于执行：本申请实施例第一方面提供的推送消息获取方法。
第十方面，本申请实施例提供了一种消息推送设备，包括：处理器、存储器、通信接口和总线；
所述处理器、所述存储器和所述通信接口通过所述总线连接并完成相互间的通信；
所述存储器存储可执行程序代码；
所述处理器通过读取所述存储器中存储的可执行程序代码来运行与所述可执行程序代码对应的程序，以用于执行：本申请实施例第二方面提供的消息推送方法。
本申请实施例提供的推送消息获取、消息推送方法及装置，可以向目标服务器发送针对待推送消息的版本的第一请求；接收所述目标服务器根据所述第一请求反馈的请求结果；在根据所述请求结果确认所述目标服务器中存在所述待推送消息的新版本时，向所述目标服务器发送获取新版本的所述待推送消息的第二请求；接收所述目标服务器根据所述第二请求推送的新版本的所述待推送消息。由于目标服务器并不依赖于自身是否保存有客户端的registerID数据，而是在接收到客户端发送的获取新版本的所述待推送消息的第二请求后，便向客户端推送消息，因此，应用本申请实施例提供获取推送消息的方案，客户端成功获取目标服务器推送的消息的概率高；应用本申请实施例提供的消息推送方案，服务器向客户端成功推送消息的概率也高。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单的介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本申请实施例提供的一种推送消息获取方法的流程图；
图2为本申请实施例提供的一种推送消息获取方法的另一流程图；
图3为本申请实施例提供的一种推送消息获取方法的另一流程图；
图4为本申请实施例提供的一种推送消息获取方法的另一流程图；
图5为本申请实施例提供的一种推送消息获取装置的结构图；
图6为本申请实施例提供的一种推送消息获取装置的另一结构图；
图7为本申请实施例提供的一种推送消息获取装置的另一结构图；
图8为本申请实施例提供的一种推送消息获取装置的另一结构图；
图9为本申请实施例提供的一种消息推送方法流程图；
图10为本申请实施例提供的一种消息推送装置结构图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整的描述，显然，所描述的实施例仅仅是本申请的一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有 作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
本申请实施例提供了一种推送消息获取方法及装置，应用于客户端；相应的，本申请实施例还提供了一种消息推送方法及装置，应用于服务器。下面分别进行说明。
首先对应用于客户端的一种推送消息获取方法及装置进行说明
如图1所示，本申请实施例提供了一种推送消息获取方法，应用于客户端，该方法包括：
S101、向目标服务器发送针对待推送消息的版本的第一请求；
其中，目标服务器可以仅仅是客户端开发商提供的消息版本控制服务器，也可以为客户端开发商提供的具有待推送消息的版本管理功能的其它服务器。
待推送消息，可以是客户端开发商想要推送给客户端的广告、客户端版本升级信息、时事新闻、新产品发布等消息。
待推送消息的版本，可以是待推送消息的时间版本，并由客户端开发商配置在目标服务器上。
第一请求可以仅携带客户端的标识，使目标服务器根据客户端的标识以及目标服务器上存储的针对该客户端消息版本控制记录，确认目标服务器上是否存在待推送消息的新版本；
第一请求也可以携带客户端存储的待推送消息的第一版本信息，以使目标服务器根据本地存储的待推送消息的第二版本信息和第一请求中携带的待推送消息的第一版本信息，判断目标服务器中是否存在待推送消息的新版本。其中，第一版本信息可以是客户端已经接收的待推送消息的最新版本，第二版本信息可以是客户端开发商新配置的待推送消息的版本信息。
具体的，客户端可以周期性地向目标服务器发送针对待推送消息的版本的第一请求；但是，当周期性地向目标服务器发送第一请求时，如果发送周期设置的较长，则达不到客户端开发商向客户端及时推送消息的目的；如果发送周期设置的较短，则不可避免的会在用户的休息时间频繁地向用户推送消息，给用户造成打扰。
因此，优选的，客户端还可以按照预设的时间间隔向目标服务器发送针对待推送消息的版本的第一请求；其中，预设的时间间隔可以为：根据用户的使用习惯确定的时间间隔。例如，用户在上午6至上午8点、中午11点至下午2点、晚上6点至晚上10点使用客户端的频率较高，上午8点至上午11点、下午2点至下午5点使用客户端的频率较低，晚上10点至次日上午6点 几乎不使用客户端，则根据用户使用该客户端的频率，可以将上午6至上午8点、中午11点至下午2点、晚上6点至晚上10点对应的上述时间间隔设置为较小的值，如：10分钟，可以将上午8点至上午11点、下午2点至下午5点对应的上述时间间隔设置为较大的值，如：1小时，可以将晚上10点至次日上午6点对应的上述时间间隔可设置为更大的值，如：6小时。
当然，较佳的，还可以由使用该客户端的用户自定义该预设的时间间隔，以进一步提高用户的体验效果。
S102、接收所述目标服务器根据所述第一请求反馈的请求结果；
目标服务器反馈的请求结果可以只是确认结果，即确认目标服务器上存在待推送消息的新版本，或者确认目标服务器上不存在待推送消息的新版本；
目标服务器反馈的请求结果也可以是目标服务器上存储的待推送消息的版本信息。
S103、在根据所述请求结果确认所述目标服务器中存在所述待推送消息的新版本时，向所述目标服务器发送获取新版本的所述待推送消息的第二请求；
当目标服务器反馈的请求结果只是确认结果时，客户端可以在确认结果为是时，判定目标服务器中存在待推送消息的新版本；然后向目标服务器发送获取新版本的待推送消息的第二请求。
当目标服务器反馈的请求结果中携带待推送消息的版本信息时，客户端可以通过判断所述请求结果中携带的版本信息是否高于本地存储的所述待推送消息的版本信息；在获得的判断结果为是时，判定所述目标服务器中存在所述待推送消息的新版本；然后向所述目标服务器发送获取新版本的所述待推送消息的第二请求。
其中，第二请求中携带有客户端的一些基本信息，基本信息可以包括：所述客户端使用的语言信息、所述客户端所处地理位置信息、所述客户端所在终端的操作系统的版本信息和所述客户端的版本信息中的至少一种，当然，基本信息并不仅限于上述几种。
此时，目标服务器可以是客户端开发商提供的单独的待推送消息内容服务器，也可以是客户端开发商提供的同时具有待推送消息版本管理功能和待推送消息内容管理的服务器，也即，在实际应用中，消息版本控制服务器和消息内容服务器可以为同一服务器，也可以为不同服务器，但均可以将它们统称为目标服务器。
S104、接收所述目标服务器根据所述第二请求推送的新版本的所述待推送消息。
可以理解的是，待推送消息可以是客户端接收的消息的总称，即客户端接收的待推送消息可以是一条以上。
由于在本申请图1所示的实施例提供的一种推送消息获取方法中，目标服务器推送消息时，并不依赖于自身是否保存有客户端的registerID数据，而是在接收到客户端发送的消息推送请求后即向客户端推送消息。因此客户端成功获取目标服务器推送的消息的概率较高。申请人通过大量实验证明，应用本申请图1所示的实施例提供的推送消息获取方法，客户端成功获取推送消息的概率在94％以上。
另外，现有技术中通过轮询检测方式获取推送消息的过程为：用户通过客户端直接向目标服务器发送获取新版本消息的请求，当服务器中存在新版本消息时，便向客户端推送相应的消息，当服务器中不存在新版本消息时，则等待客户端发送的下一个获取新版本消息的请求。由于现有技术中，需要客户端频繁地直接向服务器发送获取新版本消息的请求，而获取新版本消息的请求中通常携带有客户端的一些参数，如客户端使用的语言、客户端所在的国家、客户端所使用的操作系统的版本等，这使得客户端每次发送的获取新消息的请求需要占用较多的网络资源。因此，现有技术中的轮询检测方式需要开销用户较多的流量，不够经济实用。
而本申请实施例提供的一种推送消息获取方法中所采用的轮询检测方式，客户端每次只需要将占用网络资源较少的，针对目标服务器上的待推送消息的版本的第一请求发送给目标服务器，并且，仅在目标服务器上存在针对该客户端的新版本的待推送消息时，才向目标服务器发送获取待推送消息的第二请求，以获取针对该客户端的待推送消息。因此，更能节省用户的流量。
为了进一步提高客户端成功获取推送消息的概率，较佳的，如图2所示，在图1所示的实施例的基础上，本申请实施例还提供了另一种推送消息获取方法，该方法还可以包括：
S201、接收第三方服务器推送的第一消息；
具体的，该第三方服务器可以为GCM(Google Cloud Messaging)服务器，当然，还可以是其他第三方服务器，本申请并不对此进行限定，但第三方服务器上存储的第一消息也由客户端开发商配置。
S202、根据所述第一消息携带的消息标识，判断是否已接收过所述第一 消息，如果是，执行S203；否则，执行S204；
在使用目标服务器和第三方服务器同时向客户端推送消息时，可能会存在同一消息被两个服务器重复推送的问题，这会给用户造成打扰，因此，客户端可以增设消息合并机制以对重复推送的消息进行处理。
具体的，可以使目标服务器推送的每一消息和第三方服务器推送的每一消息，均携带有标识该消息的唯一标识，该标识可以记为pushID。合并机制具体为：当客户端接收到第三方服务器推送的第一消息时，可以对包括第一消息在内的已接收到的消息按pushID进行排重处理，当在已接收的消息中找到与第一消息的pushID相同的消息时，即认为客户端已接收过与第一消息相同的消息。
S203、将所述第一消息丢弃；
S204、展示所述第一消息。
当第一消息已接收过时，则将第一消息丢弃，否则将第一消息作为一个新的消息进行处理。
图2所示的实施例作为本申请图1所示的实施例的补充技术方案，可以在采用图1所示的实施例提供的获取推送消息的方法的同时，使用第三方服务器向客户端推送消息，进一步提高了客户端成功获取推送消息的概率。申请人经过大量实验发现，应用图2所示实施例提供的方案获取推送消息时，客户端成功获取推送消息的概率在97％以上。
优选的，在图2所示的实施例中，客户端可以将通过第三方提供的第三方服务器获取待推送消息作为主要的待推送消息获取方式，而将通过客户端开发商提供的目标服务器获取待推送消息作为补充的待推送消息获取方式。这样，可以适当延长步骤S101中所述的预设的时间间隔，例如使客户端以第一固定时间间隔(例如6小时)向目标服务器发送第一请求，降低客户端询问目标服务器的频率，以在提高客户端成功获取推送消息的概率的同时，尽可能多地为用户节省流量和电量。
进一步，在保证客户端具有较高的成功获取待推送消息的概率的基础上，为了提高目标服务器推送消息的安全性，如图3所示，在图1所示的实施例的基础上，本申请实施例还提供了另一种推送消息获取方法，该方法还可以包括：
S301、接收第三方服务器发送的获取待推送的第二消息的第一指令；
与本申请图2所示的实施例一样，第三方服务器可以为GCM服务器，还 可以为其他第三方提供的服务器，第三方服务器上存储的待推送的第二消息也由客户端开发商配置。
S302、根据所述第一指令，向所述目标服务器发送获取所述第二消息的第三请求；
可见，在本申请图3所示的实施例中，第三方服务器并不直接向客户端推送第二消息本身，而是向客户端推送以使客户端获取待推送的第二消息的第一指令，以使客户端根据该第一指令去目标服务器上获取待推送的第二消息。
这样，当目标服务器为客户端开发商提供的服务器时，客户端开发商虽然通过第三方服务器实现了第二消息的推送，但是并没有将第二消息的具体内容透露给第三方服务器，从而保证了客户端开发商向客户端推送的消息的安全性。
同样的，客户端可以向目标服务器发送携带客户端基本信息的第三请求，以获取目标服务器上存储的待推送的第二消息。
S303、接收所述目标服务器根据所述第三请求推送的所述第二消息；
S304、根据所述第二消息携带的消息标识，判断是否已接收过所述第二消息，如果是，执行S305，否则，执行S306；
与本申请图2所示的实施例一样，本申请图3所示的实施例中也可能存在同一消息被重复接收的问题，这会给用户造成打扰，因此，同样的，客户端可以增设消息合并机制以对重复接收的消息进行处理，具体的处理重复推送的消息的过程与图2所示的实施例中的步骤S202中一致，此处不再赘述。
S305、将所述第二消息丢弃；
S306：展示所述第二消息。
应用本申请图3所示的实施例提供的一种推送消息获取方法，当预设的时间间隔与图2所示的实施例中一致时，客户端成功获取推送消息的概率与图2所示的实施例一样，也在97％以上，但是本申请图3所示的实施例进一步取得了获取的待推送消息安全性高的良好效果。
优选的，在图3所示的实施例中，客户端可以将通过客户端开发商提供的目标服务器直接获取待推送消息作为主要的待推送消息获取方式，而将通过第三方提供的第三方服务器获取待推送消息的指令作为补充的待推送消息获取方式。这样，同样可以适当延长步骤S101中所述的预设的时间间隔，例如使客户端以第二固定时间间隔(例如6小时)向目标服务器发送第一请求， 降低客户端询问目标服务器的频率，以在提高客户端成功获取待推送消息的概率、保证待推送消息的安全性的同时，尽可能多地为用户节省流量和电量。
如图4所示，在图1的基础上，本申请实施例还提供了另一种推送消息获取方法，该方法可以认为是对本申请图3所示的实施例提供的方法的进一步优化，该方法还可以包括：
S401、接接收第三方服务器发送的获取待推送的第三消息的第二指令，其中，所述第二指令携带有所述第三消息的消息标识；
具体的，第二指令携带的待推送的第三消息的消息标识也可以为pushID。
S402、根据所述第三消息的消息标识，判断是否已接收过所述第三消息；如果否，执行S403；
具体的，客户端可以在已接收到的消息中查找是否存在与第三消息的标识相同的消息，如果是，则说明客户端已接收过第三消息，否则，未接收过。
S403、根据所述第二指令，向所述目标服务器发送获取所述第三消息的第四请求；
同样的，客户端可以向目标服务器发送携带客户端基本信息的第四请求。
S404、接收所述目标服务器根据所述第四请求推送的所述第三消息。
与本申请图3所示的是实施例相比，本申请图4所示的实施例提供的一种推送消息获取方法，是在收到第三方服务器发送的获取待推送的第三消息的第二指令时，就对是否已接收过第三消息进行判断，而不是在获取第三消息后进行，省去了对重复接收的消息的处理过程，减少了客户端计算工作量，降低了客户端的资源消耗。
另外，在图1所示的实施例的基础上，本申请实施例还提供了另一种推送消息获取方法，该方法还可以包括：
步骤一、检测自身的基本信息是否发生变化；如果是，执行步骤二；
基本信息可以包括：所述客户端使用的语言信息、所述客户端所处地理位置、所述客户端所在终端的操作系统的版本信息和所述客户端的版本信息等等，本申请并不限定上述基本信息所包含的内容。
步骤二、向所述目标服务器发送获取所述待推送消息的第五请求；
步骤三、接收所述目标服务器根据所述第五请求推送的所述待推送消息。
提供这一实施例的目的在于从另一方面为客户端节省流量和电量。由于当客户端的基本信息发生变化后，说明客户端所处的环境发生了变化，针对客户端所处的新环境，客户端开发商想要推送给客户端的待推送消息的版本 极有可能就是新版本。因此，客户端也没有必要再向目标服务器发送第一请求以确认目标服务器上存储的待推送消息的版本是否为新版本，而是直接向目标服务器发送获取待推送消息的第五请求即可，进而为客户端节省了流量和电量。例如客户端所处的地理位置由北京变为上海，客户端开发商想要推送客户端的消息如果为天气信息时，客户端没有必要在获取这个消息之前，徒劳地去确认该消息是否是一个新版本的消息。
本申请实施例提供的一种推送消息获取方法，可以向目标服务器发送针对待推送消息的版本的第一请求；接收所述目标服务器根据所述第一请求反馈的请求结果；在根据所述请求结果确认所述目标服务器中存在所述待推送消息的新版本时，向所述目标服务器发送获取新版本的所述待推送消息的第二请求；接收所述目标服务器根据所述第二请求推送的新版本的所述待推送消息。由于目标服务器并不依赖于自身是否保存有客户端的registerID数据，而是在接收到客户端发送的获取新版本的所述待推送消息的第二请求后，便向客户端推送消息，因此，应用本申请实施例提供获取推送消息的方案，客户端成功获取目标服务器推送的消息的概率高。
相应于图1所示的方法实施例，如图5所示，本申请还提供了一种推送消息获取装置，该装置包括：第一请求发送模块501、第一接收模块502、第二请求发送模块503和第一待推送消息接收模块504，
第一请求发送模块501，用于向目标服务器发送针对待推送消息的版本的第一请求；
其中，目标服务器可以仅仅是客户端开发商提供的消息版本控制服务器，也可以为客户端开发商提供的具有待推送消息的版本管理功能的其它服务器。
待推送消息，可以是客户端开发商想要推送给客户端的广告、客户端版本升级信息、时事新闻、天气信息、新产品发布等消息。
待推送消息的版本，可以是待推送消息的时间版本，并由客户端开发商配置在目标服务器上。
第一请求可以仅携带客户端的标识，使目标服务器根据客户端的标识以及目标服务器上存储的针对该客户端消息版本控制记录确认目标服务器上是否存在待推送消息的新版本；
第一请求也可以携带客户端存储的待推送消息的第一版本信息，以使目标服务器根据本地存储的待推送消息的第二版本信息和第一请求中携带的待推送消息的第一版本信息，判断目标服务器中是否存在待推送消息的新版本。 其中，第一版本信息可以是客户端已经接收的待推送消息的最新版本，第二版本信息可以是客户端开发商新配置的待推送消息的版本信息。
优选的，第一请求发送模块501，可以按照预设的时间间隔向目标服务器发送针对待推送消息的版本的第一请求；其中，所述预设的时间间隔为：根据用户的使用习惯确定的时间间隔。具体的，预设的时间间隔与图1所示的方法实施例中所述的预设的时间间隔一致，此处不再赘述。当然，较佳的，还可以由使用该客户端的用户自定义该预设的时间间隔，以进一步提高用户的体验效果。
第一接收模块502，用于接收所述目标服务器根据所述第一请求反馈的请求结果；
目标服务器反馈的请求结果可以只是确认结果，即确认目标服务器上存在待推送消息的新版本，或者确认目标服务器上不存在待推送消息的新版本；
目标服务器反馈的请求结果也可以是目标服务器上存储的待发送消息的版本信息。
第二请求发送模块503，用于在根据所述请求结果确认所述目标服务器中存在所述待推送消息的新版本时，向所述目标服务器发送获取新版本的所述待推送消息的第二请求；
目标服务器可以是客户端开发商提供的单独的待推送消息内容服务器，也可以是客户端开发商提供的同时具有待推送消息版本管理功能和待推送消息内容管理的服务器，也即，在实际应用中，消息版本控制服务器和消息内容服务器可以为同一服务器，也可以为不同服务器，但均可以将它们统称为目标服务器。
第二请求发送模块503包括：第一判断子模块、判定结果确定子模块和第二请求发送子模块，
第一判断子模块，用于在携带待推送消息的版本信息时，判断所述请求结果中携带的版本信息是否高于本地存储的所述待推送消息的版本信息；或者，用于判断第一接收模块502接收的请求结果是否为是；
判定结果确定子模块，用于在所述第一判断子模块获得的判断结果为是时，判定所述目标服务器中存在所述待推送消息的新版本；
第二请求发送子模块，用于向所述目标服务器发送获取新版本的所述待推送消息的第二请求；
第二请求中携带有客户端的一些基本信息，基本信息可以包括：所述客 户端使用的语言信息、所述客户端所处地理位置信息、所述客户端所在终端的操作系统的版本信息和所述客户端的版本信息中的至少一种，当然，基本信息并不仅限于上述几种。
第一待推送消息接收模块504，用于接收所述目标服务器根据所述第二请求推送的新版本的所述待推送消息。
可以理解的是，待推送消息可以是客户端接收的消息的总称，即客户端接收的待推送消息可以是一条以上。
由于在本申请图5所示的实施例提供的一种推送消息获取装置，目标服务器推送消息时，并不依赖于自身是否保存有客户端发送的该客户端的registerID数据，而是在接收到客户端发送的消息推送请求后即向客户端推送消息。因此客户端成功获取目标服务器推送的消息的概率较高。实验证明，应用本申请图5所示的实施例提供的推送消息获取装置，客户端成功获取推送消息的概率在94％以上。
另外，由于现有技术中通过轮询检测方式获取推送消息的方法，需要客户端频繁地直接向服务器发送获取新版本消息的请求，而获取新版本消息的请求中通常携带有客户端的一些参数，如客户端使用的语言、客户端所在的国家、客户端所使用的操作系统的版本等，这使得客户端每次发送的获取新消息的请求需要占用较多的网络资源。因此，现有技术中的轮询检测方式需要开销用户较多的流量，不够经济实用。关于现有技术中的轮询检测的具体方式与图1所示的方法实施例中一致，此处不再赘述。
而本申请实施例提供的一种推送消息获取装置中所采用的轮询检测方式，客户端每次只需要将占用网络资源较少的，针对目标服务器上的待推送消息的版本的第一请求发送给目标服务器，并且，仅在目标服务器上存在针对该客户端的新版本的待推送消息时，才向目标服务器发送获取待推送消息的第二请求，以获取针对该客户端的待推送消息。因此，更能节省用户的流量。
为了进一步提高客户端成功获取推送消息的概率，较佳的，如图6所示，在图5所示的实施例的基础上，本申请实施例还提供了另一种推送消息获取装置，该装置还可以包括：第一消息接收模块601、第一判断模块602、第一丢弃模块603和第一展示模块604；
第一消息接收模块601，用于接收第三方服务器推送的第一消息；
具体的，该第三方服务器可以为GCM(Google Cloud Messaging)服务器，当然，还可以是其他第三方服务器，本申请并不对此进行限定，但第三方服 务器上存储的第一消息也由客户端开发商配置。
第一判断模块602，用于根据所述第一消息携带的消息标识，判断是否已接收过所述第一消息；
在使用目标服务器和第三方服务器同时向客户端推送消息时，可能会存在同一消息被两个服务器重复推送的问题，这会给用户造成打扰，因此，客户端可以增设消息合并机制以对重复推送的消息进行处理。
消息合并机制的具体处理过程与图2所示的方法实施例中描述的一致，此处不再赘述。
第一丢弃模块603，用于在所述第一判断模块602获得的判断结果为是时，将所述第一消息丢弃；
第一展示模块604，用于在所述第一判断模块602获得的判断结果为否时，展示所述第一消息。
图6所示的实施例作为本申请图5所示的实施例的补充技术方案，可以在采用图5所示的实施例提供的获取推送消息的装置的同时，使用第三方服务器向客户端推送消息，进一步提高了客户端成功获取推送消息的概率。申请人经过大量实验发现，应用图6所示实施例提供的装置获取推送消息时，客户端成功获取推送消息的概率在97％以上。
优选的，在图6所示的实施例中，客户端可以将通过第三方提供的第三方服务器获取待推送消息作为主要的待推送消息获取方式，而将通过客户端开发商提供的目标服务器获取待推送消息作为补充的待推送消息获取方式。这样，可以适当延长第一请求发送模块501中的预设的时间间隔，例如使客户端以第一固定时间间隔(例如6小时)向目标服务器发送第一请求，降低客户端询问目标服务器的频率，以在提高客户端成功获取推送消息的概率的同时，尽可能多地为用户节省流量和电量。
进一步，在保证客户端具有较高的成功获取待推送消息的概率的基础上，为了提高目标服务器推送消息的安全性，如图7所示，在图1所示的实施例的基础上，本申请实施例还提供了另一种推送消息获取装置，该装置还可以包括：第一指令接收模块701、第三请求发送模块702、第二消息接收模块703、第二判断模块704、第二丢弃模块705和第二展示模块706；
第一指令接收模块701，用于接收第三方服务器发送的获取待推送的第二消息的第一指令；
第三方服务器的定义及其中保存的待推送消息的来源与图6所示的装置 实施例中相同，此处不作重复叙述。
第三请求发送模块702，用于根据所述第一指令，向所述目标服务器发送获取所述第二消息的第三请求；
可见，在本申请图7所示的实施例中，第三方服务器并不直接向客户端推送第二消息本身，而是向客户端推送以使客户端获取待推送的第二消息的第一指令，以使客户端根据该第一指令去目标服务器上获取待推送的第二消息。
这样，当目标服务器为客户端开发商提供的服务器时，客户端开发商虽然通过第三方服务器实现了第二消息的推送，但是并没有将第二消息的具体内容透露给第三方服务器，从而保证了客户端开发商向客户端推送的消息的安全性。
同样的，第三请求发送模块702可以向目标服务器发送携带客户端基本信息的第三请求，以获取目标服务器上存储的待推送的第二消息。
第二消息接收模块703，用于接收所述目标服务器根据所述第三请求推送的所述第二消息；
第二判断模块704，用于根据所述第二消息携带的消息标识，判断是否已接收过所述第二消息；
与本申请图6所示的实施例一样，本申请图7所示的实施例中也可能存在同一消息被重复接收的问题，这会给用户造成打扰，因此，同样的，客户端可以增设消息合并机制以对重复接收的消息进行处理，具体的处理重复推送的消息的过程与图6所示的实施例中一致，此处不再赘述。
第二丢弃模块705，用于在所述第二判断模块704获得的判断结果为是时，将所述第二消息丢弃；
第二展示模块706，用于在所述第二判断模块704获得的判断结果为否时，展示所述第二消息。
应用本申请图7所示的实施例提供的一种推送消息获取装置，当预设的时间间隔与图6所示的实施例中一致时，客户端成功获取推送消息的概率也在97％以上，但是本申请图7所示的实施例进一步取得了获取的待推送消息安全性高的良好效果。
优选的，在图7所示的实施例中，客户端可以将通过客户端开发商提供的目标服务器直接获取待推送消息作为主要的待推送消息获取方式，而将通过第三方提供的第三方服务器获取待推送消息的指令作为补充的待推送消息 获取方式。这样，同样可以适当延长第一请求发送模块501中所述的预设的时间间隔，降低客户端询问目标服务器的频率，以在提高客户端成功获取待推送消息的概率、保证待推送消息的安全性的同时，尽可能多地为用户节省流量和电量。
如图8所示，在图6的基础上，本申请实施例还提供了另一种推送消息获取装置，该装置可以认为是对本申请图7所示的实施例提供的装置的进一步优化，该装置还可以包括：第二指令接收模块801、第三判断模块802、第四请求发送模块803和第三消息接收模块804，
第二指令接收模块801，用于接收第三方服务器发送的获取待推送的第三消息的第二指令，其中，所述第二指令携带有所述第三消息的消息标识；
具体的，第二指令携带的待推送的第三消息的消息标识也可以为pushID。
第三判断模块802，用于根据所述第三消息的消息标识，判断是否已接收过所述第三消息；
具体的，处理重复接收的消息的方法与图7所示的实施例中相同，此处不再赘述。
第四请求发送模块803，用于在所述第三判断模块802获得的判断结果为否时，根据所述第二指令，向所述目标服务器发送获取所述第三消息的第四请求；
同样的，客户端可以向目标服务器发送携带客户端基本信息的第四请求。
第三消息接收模块804，用于接收所述目标服务器根据所述第四请求推送的所述第三消息。
与本申请图7所示的是实施例相比，本申请图4所示的实施例提供的一种推送消息获取装置，是在收到第三方服务器发送的获取待推送的第三消息的第二指令时，就对是否已接收过第三消息进行判断，而不是在获取第三消息后进行，省去了对重复接收的消息的处理过程，减少了客户端计算工作量，降低了客户端的资源消耗。
另外，在图1所示的实施例的基础上，本申请实施例还提供了另一种推送消息获取装置，该装置还可以包括：基本信息检测模块、第五请求发送模块和第二待推送消息接收模块；
基本信息检测模块，用于检测自身的基本信息是否发生变化；
其中，基本信息可以包括：所述客户端使用的语言信息、所述客户端所处地理位置信息、所述客户端所在终端的操作系统的版本信息和所述客户端 的版本信息等等，本申请并不限定上述基本信息所包含的内容。
第五请求发送模块，用于在所述基本信息检测模块获得的检测结果为是时，向所述目标服务器发送获取所述待推送消息的第五请求；
第二待推送消息接收模块，用于接收所述目标服务器根据所述第五请求推送的所述待推送消息。
提供这一实施例的目的在于从另一方面为客户端节省流量和电量。由于当客户端的基本信息发生变化后，说明客户端所处的环境发生了变化，针对客户端所处的新环境，客户端开发商想要推送给客户端的待推送消息的版本极有可能就是新版本。因此，客户端也没有必要再向目标服务器发送第一请求以确认目标服务器上存储的待推送消息的版本是否为新版本，而是直接向目标服务器发送获取待推送消息的第五请求即可，进而为客户端节省了流量和电量。
本申请实施例提供的一种推送消息获取装置，可以向目标服务器发送针对待推送消息的版本的第一请求；接收所述目标服务器根据所述第一请求反馈的请求结果；在根据所述请求结果确认所述目标服务器中存在所述待推送消息的新版本时，向所述目标服务器发送获取新版本的所述待推送消息的第二请求；接收所述目标服务器根据所述第二请求推送的新版本的所述待推送消息。由于目标服务器并不依赖于自身是否保存有客户端的registerID数据，而是在接收到客户端发送的获取新版本的所述待推送消息的第二请求后，便向客户端推送消息，因此，应用本申请实施例提供获取推送消息的方案，客户端成功获取目标服务器推送的消息的概率高。
下面对应用于服务器的一种消息推送方法及装置进行说明。
如图9所示，本申请实施例提供了一种消息推送方法，应用于服务器，该方法可以包括：
S901、接收客户端发送的针对待推送消息的版本的第一请求；
第一请求可以仅携带客户端的标识；第一请求还可以携带客户端存储的待推送消息的第一版本信息；其中，第一版本信息可以是客户端已经接收的待推送消息的最新版本。
S902、根据所述第一请求获得所述待推送消息的版本的信息，生成请求结果，并向所述客户端发送所述请求结果；
在第一请求仅携带客户端的标识的情况下，服务器上可以维护一个针对每一客户端的待推送消息版本控制记录，并根据客户端的标识以及待推送消 息版本控制记录确认服务器上是否存在待推送消息的新版本，进而生成请求结果；
在第一请求携带客户端存储的待推送消息的第一版本信息的情况下，服务器可以通过下述步骤生成请求结果：
步骤一、获得本地存储的所述待推送消息的第二版本信息；
第二版本信息可以是客户端开发商新配置的待推送消息的版本信息。
具体的，服务器可以根据所述客户端的基本信息中的至少一种获得本地存储的所述待推送消息的第二版本信息，也就是根据客户端的基本信息找到服务地本地存储的针对该客户端的待推送消息的版本；其中，所述基本信息包括：所述客户端使用的语言信息、所述客户端所处地理位置信息、所述客户端所在终端的操作系统的版本信息和所述客户端的版本信息。
步骤二、根据所述第一版本信息和所述第二版本信息，判断本地是否存在所述待推送消息的新版本；
具体的，当第二版本信息中的版本高于第一版本信息中的版本时，判断本地是否存在所述待推送消息的新版本。
步骤三、根据判断结果生成请求结果。
请求结果可以只是确认结果，即确认目标服务器上存在待推送消息的新版本，或者确认目标服务器上不存在待推送消息的新版本；
请求结果也可以是目标服务器上存储的待发送消息的版本信息。
S903、接收所述客户端发送的获取新版本的所述待推送消息的第二请求，其中，所述第二请求为：所述客户端根据所述请求结果确认所述服务器中存在所述待推送消息的新版本时发送的；
第二请求可以携带客户端的基本信息。
S904、根据所述第二请求向所述客户端推送新版本的所述待推送消息。
根据所述客户端的基本信息中的至少一种以及所述第二请求，获得所述待推送消息的新版本，并向所述客户端推送所获得的新版本的所述待推送消息；待推送消息可以由客户端开发商配置在该服务器上，并由该服务器推送给客户端。
需要说明的是，进行待推送消息版本控制的服务器和待推送消息推送的服务器可以是同一服务器，也可以是不同服务器。
本申请实施例提供的一种消息推送方法，可以接收客户端发送的针对待推送消息的版本的第一请求；根据所述第一请求获得所述待推送消息的版本 的信息，生成请求结果，并向所述客户端发送所述请求结果；接收所述客户端发送的获取新版本的所述待推送消息的第二请求，其中，所述第二请求为：所述客户端根据所述请求结果确认所述服务器中存在所述待推送消息的新版本时发送的；根据所述第二请求向所述客户端推送新版本的所述待推送消息。由于服务器并不依赖于自身是否保存有客户端的registerID数据，而是在接收到客户端发送的获取新版本的所述待推送消息的第二请求后，便向客户端推送消息，因此，应用本申请实施例提供的消息推送方案，服务器向客户端成功推送消息的概率高。
相应于图9所示的方法实施例，如图10所示，本申请实施例还提供了一种消息推送装置，该装置可以包括：第一请求接收模块1001、请求结果发送模块1002、第二请求接收模块1003和推送模块1004；
第一请求接收模块1001，用于接收客户端发送的针对待推送消息的版本的第一请求；
第一请求可以仅携带客户端的标识；第一请求还可以携带客户端存储的待推送消息的第一版本信息；其中，第一版本信息可以是客户端已经接收的待推送消息的最新版本。
请求结果发送模块1002，用于根据所述第一请求获得所述待推送消息的版本信息，生成请求结果，并向所述客户端发送所述请求结果；
在第一请求仅携带客户端的标识的情况下，服务器上可以维护一个针对每一客户端的待推送消息版本控制记录，请求结果发送模块1002可以根据客户端的标识以及待推送消息版本控制记录，确认服务器上是否存在待推送消息的新版本，进而生成请求结果；
或者，请求结果发送模块1002可以包括：第二版本获取子模块、判断子模块和请求结果生成子模块，
第二版本获取子模块，用于在第一请求携带客户端存储的待推送消息的第一版本信息的情况下，获得本地存储的所述待推送消息的第二版本信息；
第二版本信息可以是客户端开发商新配置的待推送消息的版本信息。
具体的，第二版本获取子模块可以用于根据所述客户端的基本信息中的至少一种获得本地存储的所述待推送消息的第二版本信息，也就是根据客户端的基本信息找到服务地本地存储的针对该客户端的待推送消息的版本；其中，基本信息包括：所述客户端使用的语言信息、所述客户端所处地理位置信息、所述客户端所在终端的操作系统的版本信息和所述客户端的版本信息。
所述判断子模块，用于根据所述第一版本信息和所述第二版本信息，判断本地是否存在所述待推送消息的新版本；
具体的，当第二版本信息中的版本高于第一版本信息中的版本时，判断本地是否存在所述待推送消息的新版本。
所述请求结果生成子模块，用于根据所述判断子模块获得的判断结果生成请求结果。
请求结果可以只是确认结果，即确认目标服务器上存在待推送消息的新版本，或者确认目标服务器上不存在待推送消息的新版本；
请求结果也可以是目标服务器上存储的待发送消息的版本信息。
第二请求接收模块1003，用于接收所述客户端发送的获取新版本的所述待推送消息的第二请求，其中，所述第二请求为：所述客户端根据所述请求结果确认所述服务器中存在所述待推送消息的新版本时发送的；
第二请求可以携带客户端的基本信息。
推送模块1004，用于根据所述第二请求向所述客户端推送新版本的所述待推送消息。
具体的，推送模块1004可以用于根据所述客户端的基本信息中的至少一种以及所述第二请求，获得所述待推送消息的新版本，并向所述客户端推送所获得的新版本的所述待推送消息；其中，待推送消息可以由客户端开发商配置在该服务器上，并由该服务器推送给客户端。
本申请实施例提供的一种消息推送装置，可以接收客户端发送的针对待推送消息的版本的第一请求；根据所述第一请求获得所述待推送消息的版本的信息，生成请求结果，并向所述客户端发送所述请求结果；接收所述客户端发送的获取新版本的所述待推送消息的第二请求，其中，所述第二请求为：所述客户端根据所述请求结果确认所述服务器中存在所述待推送消息的新版本时发送的；根据所述第二请求向所述客户端推送新版本的所述待推送消息。由于服务器并不依赖于自身是否保存有客户端的registerID数据，而是在接收到客户端发送的获取新版本的所述待推送消息的第二请求后，便向客户端推送消息，因此，应用本申请实施例提供的消息推送方案，服务器向客户端成功推送消息的概率高。
另外，相应于上述实施例提供的推送消息获取方法，本申请实施例提供了一种存储介质，用于存储可执行代码，所述可执行代码在运行时用于执行： 本申请实施例提供的推送消息获取方法；具体的，所述推送消息获取方法，包括：
向目标服务器发送针对待推送消息的版本的第一请求；
接收所述目标服务器根据所述第一请求反馈的请求结果；
在根据所述请求结果确认所述目标服务器中存在所述待推送消息的新版本时，向所述目标服务器发送获取新版本的所述待推送消息的第二请求；
接收所述目标服务器根据所述第二请求推送的新版本的所述待推送消息。
本实施例中，存储介质存储有在运行时执行本申请实施例所提供的推送消息获取方法的应用程序，因此能够实现：提高客户端成功获取目标服务器推送的消息的概率的目的。
另外，相应于上述实施例提供的消息推送方法，本申请实施例提供了一种存储介质，用于存储可执行代码，所述可执行代码在运行时用于执行：本申请实施例提供的消息推送方法；具体的，所述消息推送方法包括：
接收客户端发送的针对待推送消息的版本的第一请求；
根据所述第一请求获得所述待推送消息的版本的信息，生成请求结果，并向所述客户端发送所述请求结果；
接收所述客户端发送的获取新版本的所述待推送消息的第二请求，其中，所述第二请求为：所述客户端根据所述请求结果确认所述服务器中存在所述待推送消息的新版本时发送的；
根据所述第二请求向所述客户端推送新版本的所述待推送消息。
本实施例中，存储介质存储有在运行时执行本申请实施例所提供的消息推送方法的应用程序，因此能够实现：提高向客户端成功推送消息的概率的目的。
另外，相应于上述实施例提供的推送消息获取方法，本申请实施例提供了一种应用程序，用于在运行时执行：本申请实施例提供的推送消息获取方法；具体的，所述推送消息获取方法，包括：
向目标服务器发送针对待推送消息的版本的第一请求；
接收所述目标服务器根据所述第一请求反馈的请求结果；
在根据所述请求结果确认所述目标服务器中存在所述待推送消息的新版本时，向所述目标服务器发送获取新版本的所述待推送消息的第二请求；
接收所述目标服务器根据所述第二请求推送的新版本的所述待推送消息。
本实施例中，应用程序在运行时执行本申请实施例所提供的推送消息获取方法，因此能够实现：提高客户端成功获取目标服务器推送的消息的概率的目的。
另外，相应于上述实施例提供的消息推送方法，本申请实施例提供了一种应用程序，用于在运行时执行：本申请实施例提供的消息推送方法；具体的，所述消息推送方法包括：
接收客户端发送的针对待推送消息的版本的第一请求；
根据所述第一请求获得所述待推送消息的版本的信息，生成请求结果，并向所述客户端发送所述请求结果；
接收所述客户端发送的获取新版本的所述待推送消息的第二请求，其中，所述第二请求为：所述客户端根据所述请求结果确认所述服务器中存在所述待推送消息的新版本时发送的；
根据所述第二请求向所述客户端推送新版本的所述待推送消息。
本实施例中，应用程序在运行时执行本申请实施例所提供的消息推送方法，因此能够实现：提高向客户端成功推送消息的概率的目的。
另外，相应于上述实施例提供的推送消息获取方法，本申请实施例提供了一种推送消息获取设备，包括：处理器、存储器、通信接口和总线；
所述处理器、所述存储器和所述通信接口通过所述总线连接并完成相互间的通信；
所述存储器存储可执行程序代码；
所述处理器通过读取所述存储器中存储的可执行程序代码来运行与所述可执行程序代码对应的程序，以用于执行：本申请实施例提供的推送消息获取方法；具体的，所述推送消息获取方法，包括：
向目标服务器发送针对待推送消息的版本的第一请求；
接收所述目标服务器根据所述第一请求反馈的请求结果；
在根据所述请求结果确认所述目标服务器中存在所述待推送消息的新版本时，向所述目标服务器发送获取新版本的所述待推送消息的第二请求；
接收所述目标服务器根据所述第二请求推送的新版本的所述待推送消息。
本实施例中，推送消息获取设备通过读取存储器中存储的可执行程序代码来运行与所述可执行程序代码对应的程序，该程序在运行时执行本申请实 施例提供的推送消息获取方法，因此能够实现：提高客户端成功获取目标服务器推送的消息的概率的目的。
另外，相应于上述实施例提供的消息推送方法，本申请实施例提供了一种消息推送设备，包括：处理器、存储器、通信接口和总线；
所述处理器、所述存储器和所述通信接口通过所述总线连接并完成相互间的通信；
所述存储器存储可执行程序代码；
所述处理器通过读取所述存储器中存储的可执行程序代码来运行与所述可执行程序代码对应的程序，以用于执行：本申请实施例提供的消息推送方法；具体的，所述消息推送方法包括：
接收客户端发送的针对待推送消息的版本的第一请求；
根据所述第一请求获得所述待推送消息的版本的信息，生成请求结果，并向所述客户端发送所述请求结果；
接收所述客户端发送的获取新版本的所述待推送消息的第二请求，其中，所述第二请求为：所述客户端根据所述请求结果确认所述服务器中存在所述待推送消息的新版本时发送的；
根据所述第二请求向所述客户端推送新版本的所述待推送消息。
本实施例中，消息推送设备通过读取存储器中存储的可执行程序代码来运行与所述可执行程序代码对应的程序，该程序在运行时执行本申请实施例提供的消息推送方法，因此能够实现：提高向客户端成功推送消息的概率的目的。
对于推送消息获取装置、消息推送装置、推送消息获取设备、消息推送设备、应用程序以及存储介质实施例而言，由于所涉及的方法内容基本相似于前述的方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要 素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
本领域普通技术人员可以理解实现上述方法实施方式中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，所述的程序可以存储于计算机可读取存储介质中，这里所称得的存储介质，如：ROM/RAM、磁碟、光盘等。
以上所述仅为本申请的较佳实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和原则之内所作的任何修改、等同替换、改进等，均包含在本申请的保护范围内。

Claims (28)

  1. 一种推送消息获取方法，其特征在于，应用于客户端，所述方法包括：
    向目标服务器发送针对待推送消息的版本的第一请求；
    接收所述目标服务器根据所述第一请求反馈的请求结果；
    在根据所述请求结果确认所述目标服务器中存在所述待推送消息的新版本时，向所述目标服务器发送获取新版本的所述待推送消息的第二请求；
    接收所述目标服务器根据所述第二请求推送的新版本的所述待推送消息。
  2. 根据权利要求1所述的方法，其特征在于，
    所述请求结果中携带所述待推送消息的版本信息；
    所述在根据所述请求结果确认所述目标服务器中存在所述待推送消息的新版本时，向所述目标服务器发送获取新版本的所述待推送消息的第二请求包括：
    判断所述请求结果中携带的版本信息是否高于本地存储的所述待推送消息的版本信息；
    若为是，判定所述目标服务器中存在所述待推送消息的新版本；
    向所述目标服务器发送获取新版本的所述待推送消息的第二请求。
  3. 根据权利要求1所述的方法，其特征在于，所述方法还包括：
    接收第三方服务器推送的第一消息；
    根据所述第一消息携带的消息标识，判断是否已接收过所述第一消息；
    如果是，将所述第一消息丢弃；
    否则，展示所述第一消息。
  4. 根据权利要求1所述的方法，其特征在于，所述方法还包括：
    接收第三方服务器发送的获取待推送的第二消息的第一指令；
    根据所述第一指令，向所述目标服务器发送获取所述第二消息的第三请求；
    接收所述目标服务器根据所述第三请求推送的所述第二消息；
    根据所述第二消息携带的消息标识，判断是否已接收过所述第二消息；
    如果是，将所述第二消息丢弃；
    否则，展示所述第二消息。
  5. 根据权利要求1所述的方法，其特征在于，所述方法还包括：
    接收第三方服务器发送的获取待推送的第三消息的第二指令，其中，所述第二指令携带有所述第三消息的消息标识；
    根据所述第三消息的消息标识，判断是否已接收过所述第三消息；
    如果否，根据所述第二指令，向所述目标服务器发送获取所述第三消息 的第四请求；
    接收所述目标服务器根据所述第四请求推送的所述第三消息。
  6. 根据权利要求1-5任一项所述的方法，其特征在于，所述向目标服务器发送针对待推送消息的版本的第一请求包括：
    按照预设的时间间隔向目标服务器发送针对待推送消息的版本的第一请求，其中，所述预设的时间间隔为：根据用户的使用习惯确定的时间间隔。
  7. 根据权利要求1所述的方法，其特征在于，所述方法还包括：
    检测自身的基本信息是否发生变化；
    如果是，向所述目标服务器发送获取所述待推送消息的第五请求；
    接收所述目标服务器根据所述第五请求推送的所述待推送消息。
  8. 一种消息推送方法，其特征在于，应用于服务器，所述方法包括：
    接收客户端发送的针对待推送消息的版本的第一请求；
    根据所述第一请求获得所述待推送消息的版本的信息，生成请求结果，并向所述客户端发送所述请求结果；
    接收所述客户端发送的获取新版本的所述待推送消息的第二请求，其中，所述第二请求为：所述客户端根据所述请求结果确认所述服务器中存在所述待推送消息的新版本时发送的；
    根据所述第二请求向所述客户端推送新版本的所述待推送消息。
  9. 根据权利要求8所述的方法，其特征在于，
    所述第一请求携带所述客户端存储的所述待推送消息的第一版本信息；
    所述根据所述第一请求获得所述待推送消息的版本的信息，生成请求结果，包括：
    获得本地存储的所述待推送消息的第二版本信息；
    根据所述第一版本信息和所述第二版本信息，判断本地是否存在所述待推送消息的新版本；
    根据判断结果生成请求结果。
  10. 根据权利要求9所述的方法，其特征在于，所述获得本地存储的所述待推送消息的第二版本信息，包括：
    根据所述客户端的基本信息中的至少一种，获得本地存储的所述待推送消息的第二版本信息；所述基本信息包括：所述客户端使用的语言信息、所述客户端所处地理位置信息、所述客户端所在终端的操作系统的版本信息和所述客户端的版本信息。
  11. 根据权利要求8-9中任一项所述的方法，其特征在于，所述根据所述第二请求向所述客户端推送新版本的所述待推送消息，包括：
    根据所述客户端的基本信息中的至少一种以及所述第二请求，获得所述待推送消息的新版本，并向所述客户端推送所获得的新版本的所述待推送消息；所述基本信息包括：所述客户端使用的语言信息、所述客户端所处地理位置信息、所述客户端所在终端的操作系统的版本信息和所述客户端的版本信息。
  12. 一种推送消息获取装置，其特征在于，应用于客户端，所述装置包括：第一请求发送模块、第一接收模块、第二请求发送模块和第一待推送消息接收模块；
    所述第一请求发送模块，用于向目标服务器发送针对待推送消息的版本的第一请求；
    所述第一接收模块，用于接收所述目标服务器根据所述第一请求反馈的请求结果；
    所述第二请求发送模块，用于在根据所述请求结果确认所述目标服务器中存在所述待推送消息的新版本时，向所述目标服务器发送获取新版本的所述待推送消息的第二请求；
    所述第一待推送消息接收模块，用于接收所述目标服务器根据所述第二请求推送的新版本的所述待推送消息。
  13. 根据权利要求12所述的装置，其特征在于，所述请求结果中携带所述待推送消息的版本信息；
    所述第二请求发送模块包括：第一判断子模块、判定结果确定子模块和第二请求发送子模块，
    所述第一判断子模块，用于判断所述请求结果中携带的版本信息是否高于本地存储的所述待推送消息的版本信息；
    所述判定结果确定子模块，用于在所述第一判断子模块获得的判断结果为是时，判定所述目标服务器中存在所述待推送消息的新版本；
    所述第二请求发送子模块，用于向所述目标服务器发送获取新版本的所述待推送消息的第二请求。
  14. 根据权利要求12所述的装置，其特征在于，所述装置还包括：
    第一消息接收模块，用于接收第三方服务器推送的第一消息；
    第一判断模块，用于根据所述第一消息携带的消息标识，判断是否已接收过所述第一消息；
    第一丢弃模块，用于在所述第一判断模块获得的判断结果为是时，将所述第一消息丢弃；
    第一展示模块，用于在所述第一判断模块获得的判断结果为否时，展示 所述第一消息。
  15. 根据权利要求12所述的装置，其特征在于，所述装置还包括：
    第一指令接收模块，用于接收第三方服务器发送的获取待推送的第二消息的第一指令；
    第三请求发送模块，用于根据所述第一指令，向所述目标服务器发送获取所述第二消息的第三请求；
    第二消息接收模块，用于接收所述目标服务器根据所述第三请求推送的所述第二消息；
    第二判断模块，用于根据所述第二消息携带的消息标识，判断是否已接收过所述第二消息；
    第二丢弃模块，用于在所述第二判断模块获得的判断结果为是时，将所述第二消息丢弃；
    第二展示模块，用于在所述第二判断模块获得的判断结果为否时，展示所述第二消息。
  16. 根据权利要求12所述的装置，其特征在于，所述装置还包括：
    第二指令接收模块，用于接收第三方服务器发送的获取待推送的第三消息的第二指令，其中，所述第二指令携带有所述第三消息的消息标识；
    第三判断模块，用于根据所述第三消息的消息标识，判断是否已接收过所述第三消息；
    第四请求发送模块，用于在所述第三判断模块获得的判断结果为否时，根据所述第二指令，向所述目标服务器发送获取所述第三消息的第四请求；
    第三消息接收模块，用于接收所述目标服务器根据所述第四请求推送的所述第三消息。
  17. 根据权利要求12-16任一项所述的装置，其特征在于，所述第一请求发送模块，具体用于按照预设的时间间隔向目标服务器发送针对待推送消息的版本的第一请求，其中，所述预设的时间间隔为：根据用户的使用习惯确定的时间间隔。
  18. 根据权利要求12所述的装置，其特征在于，所述装置还包括：
    基本信息检测模块，用于检测自身的基本信息是否发生变化；
    第五请求发送模块，用于在所述基本信息检测模块获得的检测结果为是时，向所述目标服务器发送获取所述待推送消息的第五请求；
    第二待推送消息接收模块，用于接收所述目标服务器根据所述第五请求推送的所述待推送消息。
  19. 一种消息推送装置，其特征在于，应用于服务器，所述装置包括： 第一请求接收模块、请求结果发送模块、第二请求接收模块和推送模块；
    所述第一请求接收模块，用于接收客户端发送的针对待推送消息的版本的第一请求；
    所述请求结果发送模块，用于根据所述第一请求获得所述待推送消息的版本的信息，生成请求结果，并向所述客户端发送所述请求结果；
    所述第二请求接收模块，用于接收所述客户端发送的获取新版本的所述待推送消息的第二请求，其中，所述第二请求为：所述客户端根据所述请求结果确认所述服务器中存在所述待推送消息的新版本时发送的；
    所述推送模块，用于根据所述第二请求向所述客户端推送新版本的所述待推送消息。
  20. 根据权利要求19所述的装置，其特征在于，
    所述第一请求携带所述客户端存储的所述待推送消息的第一版本信息；
    所述请求结果发送模块包括：第二版本获取子模块、判断子模块和请求结果生成子模块，
    所述第二版本获取子模块，用于获得本地存储的所述待推送消息的第二版本信息；
    所述判断子模块，用于根据所述第一版本信息和所述第二版本信息，判断本地是否存在所述待推送消息的新版本；
    所述请求结果生成子模块，用于根据所述判断子模块获得的判断结果生成请求结果。
  21. 根据权利要求20所述的装置，其特征在于，所述第二版本获取子模块，具体用于根据所述客户端的基本信息中的至少一种，获得本地存储的所述待推送消息的第二版本信息；所述基本信息包括：所述客户端使用的语言信息、所述客户端所处地理位置信息、所述客户端所在终端的操作系统的版本信息和所述客户端的版本信息。
  22. 根据权利要求19-21任一项所述的装置，其特征在于，所述推送模块，具体用于根据所述客户端的基本信息中的至少一种以及所述第二请求，获得所述待推送消息的新版本，并向所述客户端推送所获得的新版本的所述待推送消息；所述基本信息包括：所述客户端使用的语言信息、所述客户端所处地理位置、所述客户端所在终端的操作系统的版本信息和所述客户端的版本信息。
  23. 一种存储介质，其特征在于，用于存储可执行代码，所述可执行代码在运行时用于执行权利要求1-7任一项所述的推送消息获取方法。
  24. 一种存储介质，其特征在于，用于存储可执行代码，所述可执行代码在运行时用于执行权利要求8-11任一项所述的消息推送方法。
  25. 一种应用程序，其特征在于，所述应用程序用于在运行时执行权利要求1-7任一项所述的推送消息获取方法。
  26. 一种应用程序，其特征在于，所述应用程序用于在运行时执行权利要求8-11任一项所述的消息推送方法。
  27. 一种推送消息获取设备，其特征在于，包括：处理器、存储器、通信接口和总线；
    所述处理器、所述存储器和所述通信接口通过所述总线连接并完成相互间的通信；
    所述存储器存储可执行程序代码；
    所述处理器通过读取所述存储器中存储的可执行程序代码来运行与所述可执行程序代码对应的程序，以用于执行：权利要求1-7任一项所述的推送消息获取方法。
  28. 一种消息推送设备，其特征在于，包括：处理器、存储器、通信接口和总线；
    所述处理器、所述存储器和所述通信接口通过所述总线连接并完成相互间的通信；
    所述存储器存储可执行程序代码；
    所述处理器通过读取所述存储器中存储的可执行程序代码来运行与所述可执行程序代码对应的程序，以用于执行：权利要求8-11任一项所述的消息推送方法。
PCT/CN2016/111303 2016-04-19 2016-12-21 推送消息获取、消息推送方法及装置 WO2017181709A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201610245239.4A CN105915612A (zh) 2016-04-19 2016-04-19 推送消息获取、消息推送方法及装置
CN201610245239.4 2016-04-19

Publications (1)

Publication Number Publication Date
WO2017181709A1 true WO2017181709A1 (zh) 2017-10-26

Family

ID=56746540

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2016/111303 WO2017181709A1 (zh) 2016-04-19 2016-12-21 推送消息获取、消息推送方法及装置

Country Status (2)

Country Link
CN (1) CN105915612A (zh)
WO (1) WO2017181709A1 (zh)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111901366A (zh) * 2019-05-06 2020-11-06 广州市百果园信息技术有限公司 一种数据推送方法、装置、设备和存储介质
CN112231612A (zh) * 2019-07-15 2021-01-15 腾讯科技（深圳）有限公司 配置信息的传输方法及装置、存储介质、电子装置
CN112583694A (zh) * 2019-09-27 2021-03-30 广州艾美网络科技有限公司 消息推送方法、装置、存储介质及控制终端
CN112579093A (zh) * 2020-12-11 2021-03-30 杭州安恒信息技术股份有限公司 一种信息推送方法、装置及相关设备
CN113094002A (zh) * 2021-05-12 2021-07-09 北京字节跳动网络技术有限公司 消息处理方法、装置、电子设备和计算机介质
CN114339286A (zh) * 2021-12-29 2022-04-12 杭州米络星科技(集团)有限公司 一种广播消息的多语言化展示系统及方法
CN114553947A (zh) * 2022-01-29 2022-05-27 北京金堤科技有限公司 一种对消息进行处理的方法及装置
CN115004673A (zh) * 2020-05-26 2022-09-02 深圳市欢太科技有限公司 消息推送方法、装置、电子设备及计算机可读介质
CN115242870A (zh) * 2022-06-23 2022-10-25 宁波三星医疗电气股份有限公司 用电数据推送方法、装置、服务器和计算机可读存储介质

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105915612A (zh) * 2016-04-19 2016-08-31 北京金山安全软件有限公司 推送消息获取、消息推送方法及装置
CN107704491B (zh) * 2017-08-22 2022-01-04 腾讯科技（深圳）有限公司 消息处理方法和装置
CN107566465A (zh) * 2017-08-23 2018-01-09 广东欧珀移动通信有限公司 一种信息推送的方法、装置、存储介质及移动终端
CN108009247B (zh) * 2017-11-30 2021-01-12 广州酷狗计算机科技有限公司 信息推送方法及装置
CN108874876B (zh) * 2018-05-03 2023-04-18 平安科技（深圳）有限公司 一种消息推送方法、计算机可读存储介质及终端设备
CN108833584B (zh) * 2018-06-29 2020-07-24 掌阅科技股份有限公司 消息推送方法、终端、服务器及计算机存储介质
CN110071864B (zh) * 2019-04-29 2022-05-17 秒针信息技术有限公司 一种消息发送方法及装置

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101576828A (zh) * 2009-06-01 2009-11-11 中兴通讯股份有限公司 软件版本升级方法及装置、服务器
CN103237060A (zh) * 2013-04-08 2013-08-07 北京小米科技有限责任公司 一种数据对象获取方法、装置及系统
CN103634695A (zh) * 2013-11-06 2014-03-12 康佳集团股份有限公司 一种智能电视接收Google GCM推送消息的方法及系统
US20150205592A1 (en) * 2014-01-23 2015-07-23 Electronics And Telecommunications Research Nstitute System and method for managing application program for terminal
CN105245560A (zh) * 2014-07-11 2016-01-13 阿里巴巴集团控股有限公司 一种实现分布式缓存的方法、装置及系统
CN105915612A (zh) * 2016-04-19 2016-08-31 北京金山安全软件有限公司 推送消息获取、消息推送方法及装置

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101576828A (zh) * 2009-06-01 2009-11-11 中兴通讯股份有限公司 软件版本升级方法及装置、服务器
CN103237060A (zh) * 2013-04-08 2013-08-07 北京小米科技有限责任公司 一种数据对象获取方法、装置及系统
CN103634695A (zh) * 2013-11-06 2014-03-12 康佳集团股份有限公司 一种智能电视接收Google GCM推送消息的方法及系统
US20150205592A1 (en) * 2014-01-23 2015-07-23 Electronics And Telecommunications Research Nstitute System and method for managing application program for terminal
CN105245560A (zh) * 2014-07-11 2016-01-13 阿里巴巴集团控股有限公司 一种实现分布式缓存的方法、装置及系统
CN105915612A (zh) * 2016-04-19 2016-08-31 北京金山安全软件有限公司 推送消息获取、消息推送方法及装置

Cited By (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111901366A (zh) * 2019-05-06 2020-11-06 广州市百果园信息技术有限公司 一种数据推送方法、装置、设备和存储介质
CN111901366B (zh) * 2019-05-06 2023-08-29 广州市百果园信息技术有限公司 一种数据推送方法、装置、设备和存储介质
CN112231612A (zh) * 2019-07-15 2021-01-15 腾讯科技（深圳）有限公司 配置信息的传输方法及装置、存储介质、电子装置
CN112231612B (zh) * 2019-07-15 2023-08-25 腾讯科技（深圳）有限公司 配置信息的传输方法及装置、存储介质、电子装置
CN112583694B (zh) * 2019-09-27 2023-06-02 广州艾美网络科技有限公司 消息推送方法、装置、存储介质及控制终端
CN112583694A (zh) * 2019-09-27 2021-03-30 广州艾美网络科技有限公司 消息推送方法、装置、存储介质及控制终端
CN115004673B (zh) * 2020-05-26 2024-04-16 深圳市欢太科技有限公司 消息推送方法、装置、电子设备及计算机可读介质
CN115004673A (zh) * 2020-05-26 2022-09-02 深圳市欢太科技有限公司 消息推送方法、装置、电子设备及计算机可读介质
CN112579093A (zh) * 2020-12-11 2021-03-30 杭州安恒信息技术股份有限公司 一种信息推送方法、装置及相关设备
CN113094002A (zh) * 2021-05-12 2021-07-09 北京字节跳动网络技术有限公司 消息处理方法、装置、电子设备和计算机介质
CN113094002B (zh) * 2021-05-12 2023-07-18 抖音视界有限公司 消息处理方法、装置、电子设备和计算机介质
CN114339286A (zh) * 2021-12-29 2022-04-12 杭州米络星科技(集团)有限公司 一种广播消息的多语言化展示系统及方法
CN114553947A (zh) * 2022-01-29 2022-05-27 北京金堤科技有限公司 一种对消息进行处理的方法及装置
CN114553947B (zh) * 2022-01-29 2024-01-19 北京金堤科技有限公司 一种对消息进行处理的方法及装置
CN115242870A (zh) * 2022-06-23 2022-10-25 宁波三星医疗电气股份有限公司 用电数据推送方法、装置、服务器和计算机可读存储介质
CN115242870B (zh) * 2022-06-23 2023-10-27 宁波三星医疗电气股份有限公司 用电数据推送方法、装置、服务器和计算机可读存储介质

Also Published As

Publication number Publication date
CN105915612A (zh) 2016-08-31

Similar Documents

Publication Publication Date Title
WO2017181709A1 (zh) 推送消息获取、消息推送方法及装置
US11206451B2 (en) Information interception processing method, terminal, and computer storage medium
US10158697B2 (en) Channel ownership in a publish-subscribe system
WO2018133306A1 (zh) 内容分发网络中的调度方法和设备
CN102255935B (zh) 云服务消费方法、云服务中介及云系统
JP2019533235A5 (zh)
TW201346761A (zh) 離線資料的離線傳遞和顯示方法、裝置及系統
JP2017501497A (ja) 目標の情報をプッシュするための方法および装置
CN110781013B (zh) 一种灰度发布方法、装置、设备及介质
US20160080515A1 (en) Network injected storage redirection for embedded applications
TW201441934A (zh) 客戶端的更新方法及裝置
US8375124B1 (en) Resumable upload for hosted storage systems
CN110659121A (zh) 任务数据获取方法及装置、任务配置方法及装置和服务器
CN107920018B (zh) 一种实现延迟推送数据的方法、服务器及系统
WO2022257604A1 (zh) 一种用户标签的确定方法和装置
WO2012028033A1 (zh) 消息更新的方法和装置
US20210176186A1 (en) Resource processing method and system, storage medium and electronic device
US20180288170A1 (en) Resource Acquiring Method and Apparatus
US9609085B2 (en) Broadcast-based update management
US20160112525A1 (en) Distribution control device and method for same, push distribution system, and storage medium
US10904746B2 (en) Implementation method, apparatus and system for remote access
US20150082402A1 (en) System and method for automated authentication
KR20150109720A (ko) 프로그램 일괄배포방법 및 이를 이용하는 서버-클라이언트 시스템
CN109379704B (zh) 短信的区域信息校正方法、装置、设备及存储介质
CN113742617A (zh) 一种缓存更新的方法和装置

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16899288

Country of ref document: EP

Kind code of ref document: A1

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205 DATED 31/01/2019)

122 Ep: pct application non-entry in european phase

Ref document number: 16899288

Country of ref document: EP

Kind code of ref document: A1