CN109831484B

CN109831484B - Election method, device, medium and electronic equipment for APP (application) sharing pushing SDK (software development kit) service

Info

Publication number: CN109831484B
Application number: CN201811635900.8A
Authority: CN
Inventors: 赵岘
Original assignee: Tianjin ByteDance Technology Co Ltd
Current assignee: Tianjin ByteDance Technology Co Ltd
Priority date: 2018-12-29
Filing date: 2018-12-29
Publication date: 2022-04-22
Anticipated expiration: 2038-12-29
Also published as: CN109831484A

Abstract

The utility model provides an election method of APP sharing pushing SDK service, which comprises the following steps: starting a current APP, and acquiring an APP list accessed to a pushing SDK service; if the APP list is empty, the current APP election is a main APP; if the APP list is not empty, calculating election values of the current APP and the main APP in the APP list; and selecting a new main APP according to the election value. The method for electing the APP-sharing pushing SDK service utilizes the data characteristics of each application program, elects a more efficient main APP through a mode of continuously updating iteration main APPs, realizes pushing of all SDK services by one main APP at each time, is flexible and efficient in electing strategy, avoids the defect that each third-party application is low in system efficiency due to dispute pushing, and ensures high survival rate and high functionality of the pushing services.

Description

Election method, device, medium and electronic equipment for APP (application) sharing pushing SDK (software development kit) service

Technical Field

The disclosure relates to the technical field of computers, in particular to an election method, device, medium and electronic device for APP sharing push SDK service.

Background

With the development of mobile internet technology, various commercial or non-commercial services become more popular, often requiring active push through systems or third party applications.

The *** push service of the Android platform is castrated, and cannot provide stable push service like the iOS platform, so that a plurality of third-party push services, namely, push SDKs, exist. Therefore, a plurality of third-party applications are pushed to serve and fight each other, the running cost of the system is increased, the overall running efficiency is reduced, and therefore a good solution is not provided for improving the pushing success rate and the survival rate of a pushing channel on the premise of low power consumption in pushing the SDK.

Disclosure of Invention

The present disclosure is directed to an election method, an election device, an election medium, and an electronic device for APP-shared push SDK service, which may solve at least one of the above-mentioned technical problems. The specific scheme is as follows:

according to a specific implementation manner of the present disclosure, in a first aspect, the present disclosure provides an election method for APP sharing push SDK service, including: starting a current APP, and acquiring an APP list accessed to a pushing SDK service; if the APP list is empty, the current APP election is a main APP; if the APP list is not empty, calculating election values of the current APP and the main APP in the APP list; and selecting a new main APP according to the election value.

Optionally, the calculating the election value of the current APP and the main APP in the APP list includes: acquiring the push SDK versions of the current APP and the main APP in the APP list, the weight of each SDK version and the daily survival time; and calculating the election value according to the SDK versions, the weight of each SDK version and the daily survival time.

Optionally, the election value includes: election value SDK version weight + daily survival time.

Optionally, the daily survival time is obtained by: the current APP writes the survival information of the current APP into the queue of the current APP at regular time; the queue sends the survival information to the main APP at regular time; and the main APP calculates the daily survival time of the current APP through all the survival information received every day.

Optionally, the sending the survival information to the main APP by the queue at regular time further includes: the main APP receives the survival information and returns confirmation information; if the current APP receives the confirmation information, deleting the survival information; and if the current APP does not receive the confirmation information, continuing to send the survival information next time.

Optionally, the method further includes: the main APP sends new main APP information to all APPs; the new master APP starts the creation and maintenance of the push channel.

According to a specific embodiment of the present disclosure, in a second aspect, the present disclosure provides an election device for APP sharing push SDK service, including: the device comprises an acquisition unit, a sending unit and a receiving unit, wherein the acquisition unit is used for starting a current APP and acquiring an APP list accessed to the pushing SDK service; a calculating unit, configured to elect the current APP as a primary APP if the APP list is empty; if the APP list is not empty, calculating election values of the current APP and the main APP in the APP list; and the election unit is used for electing a new main APP according to the election value.

Optionally, the computing unit is further configured to: acquiring the push SDK versions of the current APP and the main APP in the APP list, the weight of each SDK version and the daily survival time; and calculating the election value according to the SDK versions, the weight of each SDK version and the daily survival time.

According to a third aspect, the present disclosure provides a computer readable storage medium having stored thereon a computer program which, when executed by a processor, implements the method of any one of the above.

According to a fourth aspect thereof, the present disclosure provides an electronic device, comprising: one or more processors; storage means for storing one or more programs which, when executed by the one or more processors, cause the one or more processors to carry out a method as claimed in any preceding claim.

Compared with the prior art, the scheme of the embodiment of the disclosure at least has the following beneficial effects: the method for electing the APP-sharing pushing SDK service utilizes the data characteristics of each application program, elects a more efficient main APP through a mode of continuously updating iteration main APPs, realizes pushing of all SDK services by one main APP at each time, is flexible and efficient in electing strategy, avoids the defect that each third-party application is low in system efficiency due to dispute pushing, and ensures high survival rate and high functionality of the pushing services.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present disclosure and together with the description, serve to explain the principles of the disclosure. It is to be understood that the drawings in the following description are merely exemplary of the disclosure, and that other drawings may be derived from those drawings by one of ordinary skill in the art without the exercise of inventive faculty. In the drawings:

fig. 1 shows a schematic diagram of the steps of an election method of APP shared push SDK service according to an embodiment of the present disclosure;

fig. 2 shows a flowchart of an election method of APP shared push SDK service according to an embodiment of the present disclosure;

fig. 3 shows a schematic structural diagram of an election device for APP shared push SDK service according to an embodiment of the present disclosure;

fig. 4 shows an electronic device connection structure schematic according to an embodiment of the present disclosure.

Detailed Description

To make the objects, technical solutions and advantages of the present disclosure clearer, the present disclosure will be described in further detail with reference to the accompanying drawings, and it is apparent that the described embodiments are only a part of the embodiments of the present disclosure, rather than all embodiments. All other embodiments, which can be derived by one of ordinary skill in the art from the embodiments disclosed herein without making any creative effort, shall fall within the scope of protection of the present disclosure.

The terminology used in the embodiments of the present disclosure is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. As used in the disclosed embodiments and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise, and "a plurality" typically includes at least two.

It should be understood that the term "and/or" as used herein is merely one type of association that describes an associated object, meaning that three relationships may exist, e.g., a and/or B may mean: a exists alone, A and B exist simultaneously, and B exists alone. In addition, the character "/" herein generally indicates that the former and latter related objects are in an "or" relationship.

It should be understood that although the terms first, second, third, etc. may be used to describe … … in embodiments of the present disclosure, these … … should not be limited to these terms. These terms are used only to distinguish … …. For example, the first … … can also be referred to as the second … … and, similarly, the second … … can also be referred to as the first … … without departing from the scope of embodiments of the present disclosure.

The words "if", as used herein, may be interpreted as "at … …" or "at … …" or "in response to a determination" or "in response to a detection", depending on the context. Similarly, the phrases "if determined" or "if detected (a stated condition or event)" may be interpreted as "when determined" or "in response to a determination" or "when detected (a stated condition or event)" or "in response to a detection (a stated condition or event)", depending on the context.

It is also noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that an article or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such article or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in the article or device in which the element is included.

Alternative embodiments of the present disclosure are described in detail below with reference to the accompanying drawings.

Example 1

As shown in fig. 1-2, the present disclosure provides an election method for APP sharing push SDK service, which is applied to any mobile terminal, especially a mobile terminal under an Android platform, and specifically includes the following steps:

step S102: and starting the current APP, and acquiring an APP list accessed to the pushing SDK service.

When App is started, the push service is also started, when the App is started, a network request is initiated, an APP list carried by or accessed to the push SDK in the equipment (usually, a mobile terminal) is obtained, and the weight of each version of the push SDK is obtained. The list of APPs typically already exists before the current APP, all APPs typically including identity information such as name, type, etc.

Step S104: and if the APP list is empty, the current APP election is the main APP.

At this moment, whether at least one APP already exists in the current APP list needs to be inquired through the system, if no APP exists in the current list, namely the current APP is the first APP, the current APP is directly elected as the main APP, and the push channel is created and maintained through the current APP, namely the main APP.

Step S106: and if the APP list is not empty, calculating the election value of the current APP and the main APP in the APP list.

If the network request returns a result indicating that other APPs have access to the push SDK, that is, at least one App exists in the current App list, then election operation needs to be performed, assuming that all APPs in the previous App list adopt the method, and a main App has been elected to perform push channel creation and maintenance, then computing the election values of the current App and the main App in the App list.

Specifically, the calculation of the election value of the current APP and the main APP in the APP list includes the following steps:

step S1062: and acquiring the push SDK versions of the current APP and the main APP in the APP list, the weight of each SDK version and the daily survival time.

The manner of acquiring the version of the pushed SDK is as follows:

when each APP starts the push service, the server side is used for obtaining the SDK information of each version and the calculation weight of the SDK of each version. For example, if the SDK weight of the version 3.5 is 3 and the SDK weight of the version 3.3 is 2, the overall weight of the version 3.5 is 3.5x 3-10.5, and the overall weight of the version 3.3 is 3.3x 2-6.6.

One specific example is as follows:

the pushing SDK carried by each APP can start a pushing service in the background, and when the APP is alive, the pushing service is also alive. The APP (subsequently called small A) pushes the service and starts a timer, the timer is used for writing the survival information of the APP into a queue at regular time (for example, 30 minutes), and the queue is responsible for sending the survival information to the main App (subsequently called small B) through the system call of the start service.

If the small B receives the information, the message of 'successful sending' is returned to the small A, and the small A deletes the sent message in the queue after receiving the message of 'successful sending'. If the message is not received by the small B, the small A cannot receive the message of 'successful transmission', the message which is transmitted in the past always exists in the queue, and the transmission is tried again when the timer is triggered next time.

And storing a plurality of messages of the small A received by the small B, and calculating the survival time of each App according to the messages.

Step S1064: and calculating the election value level according to the SDK version A, the weight B of each SDK version and the daily survival time C.

Optionally, the election value includes: the election value level SDK version a SDK version weight B + daily survival duration C.

Step S108: and selecting a new main APP according to the election value, and naming the main APP as D.

Optionally, the method further comprises the following steps:

step S110: and the main APP sends the new main APP information to all APPs.

Step S112: the new master APP starts the creation and maintenance of the push channel.

As described above, the selected master APP calculates the APP with the highest Level according to the Level ═ SDK version weight + daily survival time of the APPs, and after calculating the APP with the highest Level, the master APP notifies all APPs that "the APP with the highest Level is D, and the master APP thereafter is D".

After the App with the highest Level receives the message that the App with the highest Level is D and the main App later is D, the main work of election and main App handover is completed, and the App with the highest Level is used for creating and maintaining the push channel.

The method for electing the APP-sharing pushing SDK service utilizes the data characteristics of each application program, elects a more efficient main APP through a mode of continuously updating iteration main APPs, realizes pushing of all SDK services by one main APP at each time, is flexible and efficient in electing strategy, avoids the defect that each third-party application is low in system efficiency due to dispute pushing, and ensures high survival rate and high functionality of the pushing services.

Example 2

As shown in fig. 2 to 3, according to a specific embodiment of the present disclosure, in a second aspect, the present disclosure provides an election device for APP sharing push SDK service, which is applied to any mobile terminal, especially a mobile terminal under an Android platform, and specifically includes: an acquisition unit 302, a calculation unit 304, and an election unit 306.

The acquisition unit 302: the method is used for starting the current APP and obtaining the APP list accessed to the pushing SDK service.

The push service is started when the APP is started, a network request is initiated when the APP is started, an APP list carried by or accessed to the push SDK in the equipment (usually, a mobile terminal) is obtained, and the weight of each version of the push SDK is obtained. The list of APPs typically already exists before the current APP, all APPs typically including identity information such as name, type, etc.

A calculating unit 304, configured to elect the current APP as a main APP if the APP list is empty. And if the APP list is not empty, calculating the election value of the current APP and the main APP in the APP list.

If the network request returns a result indicating that other APPs have access to the push SDK, that is, at least one APP exists in the current APP list, the election operation needs to be performed, assuming that all the APPs in the previous APP list adopt the method, and one main APP has been elected to perform push channel creation and maintenance, the election values of the current APP and the main APP in the APP list are calculated.

Specifically, calculating the election value of the current APP and the main APP in the APP list includes:

the method comprises the steps of firstly, obtaining push SDK versions of the current APP and the main APP in the APP list, weights of the SDK versions and daily survival time.

The manner of acquiring the version of the pushed SDK is as follows:

One specific example is as follows:

the pushing SDK carried by each APP can start a pushing service in the background, and when the APP is alive, the pushing service is also alive. The APP (subsequently called small A) pushes the service and starts a timer, the timer is used for writing the survival information of the APP into a queue at regular time (for example, 30 minutes), and the queue is responsible for sending the survival information to the main APP (subsequently called small B) through the system call of the start service (startService).

And storing a plurality of messages of the small A received by the small B, so as to calculate the survival time of each APP.

And secondly, calculating the election value according to the SDK versions, the weight of each SDK version and the daily survival time.

Election unit 308: and the method is used for electing a new main APP according to the election value.

Optionally, the method further includes: and the main APP sends the new main APP information to all APPs. The new master APP starts the creation and maintenance of the push channel.

As described above, the selected main APP calculates the APP with the highest Level according to the Level ═ SDK version weight + daily survival time of the APPs, and after calculating the APP with the highest Level, the main APP notifies all APPs that "the APP with the highest Level is D, and the main APP thereafter is D".

The APP with the highest Level receives the message that the APP with the highest Level is D and the main APP later is D, so that the main work of election and main APP handover is completed, and the APP with the highest Level is used for creating and maintaining the push channel.

This is disclosed through constructing the election device of APP sharing propelling movement SDK service, has utilized the data characteristic of each application itself, and through the mode of the main APP of the iteration of constantly updating, a more efficient main APP is elected, realizes the propelling movement of all SDK services by a main APP at every turn, and the election strategy is nimble high-efficient, has avoided each third party application to strive for the drawback that the propelling movement leads to the inefficiency of system, has guaranteed the high survival rate and the high functionality of propelling movement service.

Example 3

As shown in fig. 4, this embodiment provides an electronic device, where the electronic device is used in an election method for APP sharing push SDK service, and the electronic device includes: at least one processor; and a memory communicatively coupled to the at least one processor; wherein the content of the first and second substances,

the memory stores instructions executable by the one processor to cause the at least one processor to: starting a current APP, and acquiring an APP list accessed to a pushing SDK service; if the APP list is empty, the current APP election is a main APP; if the APP list is not empty, calculating election values of the current APP and the main APP in the APP list; and selecting a new main APP according to the election value.

Example 4

The embodiment of the present disclosure provides a non-volatile computer storage medium, where a computer-executable instruction is stored in the computer storage medium, and the computer-executable instruction may execute an election method of an APP shared push SDK service in any method embodiment described above.

Example 5

Referring now to FIG. 4, a block diagram of an electronic device 400 suitable for use in implementing embodiments of the present disclosure is shown. The terminal device in the embodiments of the present disclosure may include, but is not limited to, a mobile terminal such as a mobile phone, a notebook computer, a digital broadcast receiver, a PDA (personal digital assistant), a PAD (tablet computer), a PMP (portable multimedia player), a vehicle terminal (e.g., a car navigation terminal), and the like, and a stationary terminal such as a digital TV, a desktop computer, and the like. The electronic device shown in fig. 4 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present disclosure.

As shown in fig. 4, electronic device 400 may include a processing device (e.g., central processing unit, graphics processor, etc.) 401 that may perform various appropriate actions and processes in accordance with a program stored in a Read Only Memory (ROM)402 or a program loaded from a storage device 408 into a Random Access Memory (RAM) 403. In the RAM 403, various programs and data necessary for the operation of the electronic apparatus 400 are also stored. The processing device 401, the ROM 402, and the RAM 403 are connected to each other via a bus 404. An input/output (I/O) interface 405 is also connected to bus 404.

Generally, the following devices may be connected to the I/O interface 405: input devices 406 including, for example, a touch screen, touch pad, keyboard, mouse, camera, microphone, accelerometer, gyroscope, etc.; an output device 407 including, for example, a Liquid Crystal Display (LCD), a speaker, a vibrator, and the like; storage 408 including, for example, tape, hard disk, etc.; and a communication device 409. The communication means 409 may allow the electronic device 400 to communicate wirelessly or by wire with other devices to exchange data. While fig. 4 illustrates an electronic device 400 having various means, it is to be understood that not all illustrated means are required to be implemented or provided. More or fewer devices may alternatively be implemented or provided.

In particular, according to an embodiment of the present disclosure, the processes described above with reference to the flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method illustrated in the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network via the communication device 409, or from the storage device 408, or from the ROM 402. The computer program performs the above-described functions defined in the methods of the embodiments of the present disclosure when executed by the processing device 401.

It should be noted that the computer readable medium in the present disclosure can be a computer readable signal medium or a computer readable storage medium or any combination of the two. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present disclosure, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In contrast, in the present disclosure, a computer readable signal medium may comprise a propagated data signal with computer readable program code embodied therein, either in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: electrical wires, optical cables, RF (radio frequency), etc., or any suitable combination of the foregoing.

The computer readable medium may be embodied in the electronic device; or may exist separately without being assembled into the electronic device.

The computer readable medium carries one or more programs which, when executed by the electronic device, cause the electronic device to: acquiring at least two internet protocol addresses; sending a node evaluation request comprising the at least two internet protocol addresses to node evaluation equipment, wherein the node evaluation equipment selects the internet protocol addresses from the at least two internet protocol addresses and returns the internet protocol addresses; receiving an internet protocol address returned by the node evaluation equipment; wherein the obtained internet protocol address indicates an edge node in the content distribution network.

Alternatively, the computer readable medium carries one or more programs which, when executed by the electronic device, cause the electronic device to: receiving a node evaluation request comprising at least two internet protocol addresses; selecting an internet protocol address from the at least two internet protocol addresses; returning the selected internet protocol address; wherein the received internet protocol address indicates an edge node in the content distribution network.

Computer program code for carrying out operations for aspects of the present disclosure may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C + +, and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet service provider).

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The units described in the embodiments of the present disclosure may be implemented by software or hardware. Where the name of a unit does not in some cases constitute a limitation of the unit itself, for example, the first retrieving unit may also be described as a "unit for retrieving at least two internet protocol addresses".

Claims

1. An election method for APP sharing push SDK service is characterized by comprising the following steps:

starting a current APP, and acquiring an APP list accessed to a pushing SDK service;

if the APP list is empty, the current APP election is a main APP;

if the APP list is not empty, calculating election values of the current APP and the main APP in the APP list; wherein the election value is SDK version weight + daily survival duration;

electing a new main APP according to the election value,

and the main APP sends the new main APP information to all APPs.

2. The method of claim 1, wherein said calculating election values for said current APP and a master APP in said list of APPs comprises:

acquiring the push SDK versions of the current APP and the main APP in the APP list, the weight of each SDK version and the daily survival time;

and calculating the election value according to the SDK versions, the weight of each SDK version and the daily survival time.

3. The method according to claim 2, wherein the length of daily survival time is obtained by:

the current APP writes the survival information of the current APP into the queue of the current APP at regular time;

the queue sends the survival information to the main APP at regular time;

and the main APP calculates the daily survival time of the current APP through all the survival information received every day.

4. The method of claim 3, wherein the queue periodically sends the survival information to the main APP after further comprising:

the main APP receives the survival information and returns confirmation information;

if the current APP receives the confirmation information, deleting the survival information;

and if the current APP does not receive the confirmation information, continuing to send the survival information next time.

5. The utility model provides a device of electing of APP sharing propelling movement SDK service which characterized in that includes:

the device comprises an acquisition unit, a sending unit and a receiving unit, wherein the acquisition unit is used for starting a current APP and acquiring an APP list accessed to the pushing SDK service;

a calculating unit, configured to elect the current APP as a primary APP if the APP list is empty; if the APP list is not empty, calculating election values of the current APP and the main APP in the APP list; wherein the election value is SDK version weight + daily survival duration;

and the election unit is used for electing a new main APP according to the election value, and the main APP sends new main APP information to all APPs.

6. The apparatus of claim 5, wherein the computing unit is further configured to:

7. A computer-readable storage medium, on which a computer program is stored, which program, when being executed by a processor, carries out the method according to any one of claims 1 to 4.

8. An electronic device, comprising:

one or more processors;

storage means for storing one or more programs which, when executed by the one or more processors, cause the one or more processors to carry out the method of any one of claims 1 to 4.