CN113821312B - Player management method and device - Google Patents
Player management method and device Download PDFInfo
- Publication number
- CN113821312B CN113821312B CN202010570894.3A CN202010570894A CN113821312B CN 113821312 B CN113821312 B CN 113821312B CN 202010570894 A CN202010570894 A CN 202010570894A CN 113821312 B CN113821312 B CN 113821312B
- Authority
- CN
- China
- Prior art keywords
- player
- party
- priority
- occupying
- occupant
- Prior art date
- Legal status (The legal status 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 status listed.)
- Active
Links
- 238000007726 management method Methods 0.000 title claims abstract description 69
- 230000004044 response Effects 0.000 claims abstract description 49
- 238000000034 method Methods 0.000 claims description 20
- 230000015654 memory Effects 0.000 claims description 17
- 238000012544 monitoring process Methods 0.000 claims description 6
- 238000012545 processing Methods 0.000 abstract description 4
- 238000004891 communication Methods 0.000 description 9
- 238000010586 diagram Methods 0.000 description 8
- 238000004590 computer program Methods 0.000 description 5
- 238000005516 engineering process Methods 0.000 description 3
- 230000006870 function Effects 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 230000000694 effects Effects 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 239000004973 liquid crystal related substance Substances 0.000 description 2
- 230000001413 cellular effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000008569 process Effects 0.000 description 1
- 230000001953 sensory effect Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
- 239000002699 waste material Substances 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
- G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Transfer Between Computers (AREA)
- Telephonic Communication Services (AREA)
Abstract
The embodiment of the application discloses a player management method and device, and relates to the technical field of media data processing. Inquiring whether the player is occupied or not in response to receiving a use request of the player sent by a requester; in response to a query that the player is occupied, sending a request for commonly using the player to an occupant, the request for commonly using the player including attribute information of the requester; and in response to receiving the message of refusing to jointly use the player sent by the occupying party, controlling the party with high priority to use the player in the requesting party and the occupying party according to the priority of the requesting party and the priority of the occupying party, thereby effectively avoiding the mutual preemption of resources between the player requiring party and the occupying party and improving the effectiveness of managing the player.
Description
Technical Field
The present application relates to the field of computer technologies, and in particular, to the field of media data processing technologies, and in particular, to a method and an apparatus for player management.
Background
With the development of communication technology, the types of terminal applications are more and more, but the players of the terminals are very limited, when different terminal applications request the players at the same time, the players are in conflict, and after the players are preempted by part of the terminal applications, the players cannot be released in time, so that the waste of the players is caused.
The current manner of handling player conflicts is mainly: when the requesting terminal application requests to use the player, but the player is already occupied by the occupying terminal application, the requesting terminal application may use the player after the end of the use of the occupying terminal application or in a use gap.
Disclosure of Invention
The method provides a player management method, a player management device, player management equipment and a storage medium.
According to a first aspect, the present embodiment provides a player management method, including: inquiring whether the player is occupied or not in response to receiving a use request of the player sent by a requester; in response to a query that the player is occupied, sending a request to the occupant to commonly use the player, the request to commonly use the player including attribute information of the requester; and in response to receiving a message sent by the occupying party and refusing to jointly use the player, controlling the party with high priority to use the player according to the priority of the requesting party and the priority of the occupying party.
In some embodiments, controlling a higher priority party of the requesting party and the occupying party to use the player according to the priority of the requesting party and the priority of the occupying party includes: comparing the priority of the requesting party with the priority of the occupying party; in response to determining that the priority of the requestor is higher than the priority of the occupant, the occupant is controlled to release the player for use by the requestor.
In some embodiments, controlling the player to be used by a higher priority party of the requesting party and the occupying party according to the priority of the requesting party and the priority of the occupying party further comprises: in response to determining that the priority of the requestor is lower than the priority of the occupant, a message is sent to the requestor that the request failed.
In some embodiments, the priority of the requestor and the priority of the occupant are determined based on registration information sent at the time of initialization of the requestor and the occupant, respectively.
In some embodiments, the requestor and the occupant are different modules of the same application, and the priority of the requestor and the priority of the occupant are determined from the hosting service of the application.
In some embodiments, the method further comprises: in response to receiving a message sent by the occupant to allow the player to be commonly used, the requester is allowed to commonly use the player with the occupant, wherein the message to allow the player to be commonly used is determined by the occupant based on attribute information of the requester.
According to a second aspect, the present embodiment provides a player management apparatus, including: a query module configured to query whether the player is occupied in response to receiving a use request for the player sent by the requester; a request module configured to send a request for commonly using the player to an occupant in response to a query that the player is occupied, the request for commonly using the player including attribute information of the requester; and the control module is configured to control one of the requesting party and the occupying party to use the player according to the priority of the requesting party and the priority of the occupying party in response to receiving the message of refusing to commonly use the player sent by the occupying party.
In some embodiments, the control module further comprises: a comparison sub-module configured to compare the priority of the requestor with the priority of the occupant; a release sub-module configured to control the occupant to release the player for use by the requestor in response to determining that the priority of the requestor is higher than the priority of the occupant.
In some embodiments, the control module further comprises: a sending sub-module configured to send a message to the requestor that a request failed in response to determining that the priority of the requestor is lower than the priority of the occupant.
In some embodiments, the priority of the requestor and the priority of the occupant are determined based on registration information sent at the time of initialization of the requestor and the occupant, respectively.
In some embodiments, the requestor and the occupant are different modules of the same application, and the priority of the requestor and the priority of the occupant are determined from the hosting service of the application.
In some embodiments, the apparatus further comprises: and a use module configured to allow the requesting party to use the player together with the occupying party in response to receiving a message sent by the occupying party to allow the player to be used together, wherein the message to allow the player to be used together is determined by the occupying party based on attribute information of the requesting party.
According to a third aspect, the present embodiment provides a playback manager, including a management unit for performing a playback management method.
In some embodiments, the playback manager further comprises at least one of: a request unit for sending a player use request to the management unit; a registration unit for registering with the management unit when the request unit is initialized; and the monitoring unit is used for monitoring the message of releasing the player sent by the management unit and sending the monitored message of interrupting the player and changing the route to the management unit.
According to a fourth aspect, the present embodiment provides an electronic device comprising one or more processors; and a storage device having one or more programs stored thereon, which when executed by the one or more processors, cause the one or more processors to implement a player management method.
According to a fifth aspect, the present embodiment provides a computer-readable medium having stored thereon a computer program which, when executed by a processor, implements a player management method.
The player management method and the device provided by the application inquire whether the player is occupied or not by responding to the use request of the player sent by the receiving request party; in response to a query that the player is occupied, sending a request for commonly using the player to an occupant, the request for commonly using the player including attribute information of the requester; and in response to receiving the message of refusing to jointly use the player sent by the occupying party, controlling the party with high priority to use the player in the requesting party and the occupying party according to the priority of the requesting party and the priority of the occupying party, thereby effectively avoiding the mutual preemption of resources between the player requiring party and the occupying party and improving the effectiveness of managing the player.
It should be understood that the description in this section is not intended to identify key or critical features of the embodiments of the disclosure, nor is it intended to be used to limit the scope of the disclosure. Other features of the present disclosure will become apparent from the following specification.
Drawings
FIG. 1 is an exemplary system architecture diagram in which the present application may be applied;
FIG. 2 is a flow chart of one embodiment of a player management method according to the present application;
FIG. 3 is a schematic diagram of an application scenario of a player management method according to the present application;
FIG. 4 is a flow chart of yet another embodiment of a player management method according to the present application;
FIG. 5 is a schematic diagram of one embodiment of a player management device in accordance with the present application;
FIG. 6 is a schematic diagram of one embodiment of a playback manager in accordance with the present application;
FIG. 7 is a schematic diagram of a computer system suitable for use with a server implementing an embodiment of the application.
Detailed Description
Exemplary embodiments of the present application will now be described with reference to the accompanying drawings, in which various details of the embodiments of the present application are included to facilitate understanding, and are to be considered merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the application. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.
It should be noted that, without conflict, the embodiments of the present application and features of the embodiments may be combined with each other. The application will be described in detail below with reference to the drawings in connection with embodiments.
Fig. 1 illustrates an exemplary system architecture 100 in which an embodiment of a player management method of the present application may be applied.
As shown in fig. 1, a system architecture 100 may include terminal devices 101, 102, 103, a network 104, and a server 105. The network 104 is used as a medium to provide communication links between the terminal devices 101, 102, 103 and the server 105. The network 104 may include various connection types, such as wired, wireless communication links, or fiber optic cables, among others.
The user may interact with the server 105 via the network 104 using the terminal devices 101, 102, 103 to receive or send messages or the like. Various client applications capable of playing back playback and/or video data, such as an instant messaging application, a video playing application, etc., may be installed on the terminal devices 101, 102, 103.
The terminal devices 101, 102, 103 may be hardware or software. When the terminal devices 101, 102, 103 are hardware, they may be various electronic devices with display screens, including but not limited to smartphones, tablets, laptop and desktop computers, and the like. When the terminal devices 101, 102, 103 are software, they can be installed in the above-listed electronic devices. Which may be implemented as multiple software or software modules (e.g., to provide player management), or as a single software or software module. The present invention is not particularly limited herein.
The server 105 may be a server that provides various services, for example, receives a player usage request uploaded by a requester, inquires whether the player is occupied, transmits a request for commonly using the player to an occupant in response to inquiry that the player is occupied, and controls a party having a high priority among the requester and the occupant to use the player in response to receiving a message sent by the occupant to reject commonly using the player according to the priority of the requester and the priority of the occupant.
It should be noted that, the method for managing a player provided in the embodiment of the present application is generally executed by the server 105, and accordingly, the player management device is generally disposed in the server 105. It should also be noted that the player management application may be installed in the terminal devices 101, 102, 103, and the terminal devices 101, 102, 103 may also manage the player based on the use request of the player sent by the requester, and in this case, the player management method may also be executed by the terminal devices 101, 102, 103, and accordingly, the player management apparatus may also be provided in the terminal devices 101, 102, 103. At this point, the exemplary system architecture 100 may also not include the server 105 and the network 104.
The server 105 may be hardware or software. When the server 105 is hardware, it may be implemented as a distributed server cluster formed by a plurality of servers, or as a single server. When the server is software, it may be implemented as a plurality of software or software modules (e.g., to provide player management services), or as a single software or software module. The present invention is not particularly limited herein.
It should be understood that the number of terminal devices, networks and servers in fig. 1 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.
Fig. 2 shows a flow diagram 200 of an embodiment of a player management method that can be applied to the present application. The player management method comprises the following steps:
In step 201, in response to receiving a request for use of the player sent by the requester, it is queried whether the player is occupied.
In this embodiment, the executing body (for example, the server 101 or the terminal devices 101, 102, 103 in fig. 1) may monitor the player usage request sent by the requester in real time, or may directly receive the player usage request sent by the requester, which is not limited in the present application. After receiving a use request for the player sent by the requester, the execution subject inquires whether the player is occupied. If the current player is unoccupied, a message is sent to the requesting party to allow use of the player to inform the requesting party to use the current player.
Here, the requester may be an application program. For example, instant messaging applications such as video call applications, voice chat applications, etc., non-instant messaging applications such as music play applications, gaming applications with background music, etc.; or may be a module in an application program, for example, a voice call module, a music playing module, etc. in a voice chat application, which is not limited in the present application.
The requesting party may also be a terminal device. Such as smartphones, tablet computers, laptop portable computers, desktop computers, and the like.
The player may be a player that plays audio data, video data, or other media data.
Step 202, in response to querying that the player is occupied, a request is sent to the occupant to commonly use the player.
In this embodiment, if the executing entity inquires that the player is occupied, a request for using the player together with the requester is sent to the occupying party, wherein the request for using the player together includes attribute information of the requester.
Here, the attribute information of the requester may include a type of use of the player by the requester, for example, a video call, a voice call, a dictation, game background music, and the like, and an application name to which the requester belongs.
In step 203, in response to receiving the message sent by the occupant to reject the player for common use, the party with high priority among the requester and the occupant is controlled to use the player according to the priority of the requester and the priority of the occupant.
In this embodiment, after the executing body sends the request of the requesting party to the occupying party for commonly using the player, the occupying party may determine based on a preset compatible use rule, and if the requesting party cannot use the player in a compatible manner, send a message for refusing to commonly use the player. After receiving the message of refusing the commonly used player sent by the occupying party, the executing main body can compare the priority of the occupying party with the priority of the requesting party according to the preset priority information of the requesting party and the occupying party, if the priority of the requesting party is high, the executing main body controls the requesting party to use the player, and if the priority of the occupying party is high, the executing main body controls the occupying party to continue to use the player.
Here, the preset compatible usage rules may be set according to experience, actual application requirements, and specific application scenarios.
Specifically, the preset compatible usage rule may be determined based on attribute information of the requesting party, or may be determined based on whether the requesting party and the occupying party belong to the same application program, for example, the requesting party and the occupying party belonging to the same application program may be compatible to use the player, the requesting party and the occupying party belonging to different application programs may not be compatible to use the player, and the application is not limited thereto.
In some alternatives, the requesting party is permitted to use the player with the occupant in response to receiving a message sent by the occupant to permit the player to be used together.
In this implementation, after the executing body sends the request of the requesting party to the occupying party for the common use of the player, the occupying party may determine based on a preset compatible use rule, and if the requesting party can use the common use of the player in a compatible manner, send a message for allowing the common use of the player.
Here, the preset compatible usage rule may be determined according to attribute information of the requester and attribute information of itself.
Specifically, the preset compatible usage rule may be that the attribute information is a requester/occupant of the instant messaging class and the attribute information is a requester/occupant of the non-instant messaging class may be compatible with the player, and the attribute information is both a requester and an occupant of the instant messaging class and may not be compatible with the player. When the occupied party is game background music, the requesting party is video call, namely the attribute information of the occupied party is non-instant communication application, and the attribute information of the requesting party is instant communication application, the executing main body sends a message allowing the player to be commonly used; when the occupied party is a video call and the requesting party is a voice call, namely the attribute information of the requesting party and the occupied party are both instant messaging applications, a message for refusing to commonly use the player is sent.
After receiving the message sent by the occupying party and allowing the player to be used together, the executing body sends a notification message to the player requesting party, wherein the notification message allows the requesting party and the occupying party to use the player together, and the player requesting party and the player occupying party use the player together after receiving the notification message.
According to the implementation mode, the player is allowed to be used jointly by the occupied party and the requesting party by receiving the message which is sent by the occupied party and is allowed to be used jointly by the occupied party and the requesting party, so that the player can be used jointly by the occupied party and the requesting party of the player under the condition of no conflict, and the use rate of the player is improved.
With continued reference to fig. 3, fig. 3 is a schematic diagram of an application scenario of the player management method according to the present embodiment.
In the application scenario of fig. 3, the executing body 301 first receives a request for use of a player sent by the requesting party 302, for example, a video call module in an instant messaging application, inquires whether the player is occupied, grants the requesting party 302 to use the player if the current player is not occupied, and sends a request for commonly using the player to the occupying party 303, for example, a game background sound module, if the current player is occupied. The occupant 303, upon receiving a request to commonly use the player, may determine whether to be compatible for use with the requesting party according to preset compatible use criteria. After receiving the message of refusing to use the player together sent by the occupant 303, the executing body 301 compares the priority of the occupant 303 with the priority of the requester 302 according to the preset priority information of the occupant 303 and the requester 302, and as a result, the priority of the requester 302 is higher than the priority of the occupant 303, so that the executing body 301 can directly interrupt the use of the player by the occupant 303 to enable the requester 302 to use the player. .
According to the player management method provided by the embodiment of the disclosure, whether the player is occupied is inquired by responding to the use request of the player sent by the requester; in response to a query that the player is occupied, sending a request for commonly using the player to an occupant, the request for commonly using the player including attribute information of the requester; and in response to receiving the message of refusing to jointly use the player sent by the occupying party, controlling the party with high priority to use the player in the requesting party and the occupying party according to the priority of the requesting party and the priority of the occupying party, thereby effectively avoiding the mutual preemption of resources between the player requiring party and the occupying party and improving the effectiveness of managing the player.
With further reference to fig. 4, a flow 400 of yet another embodiment of a player management method is shown. The flow 400 of the player management method of the present embodiment may include the following steps:
Step 401, in response to receiving a use request for a player sent by a requester, querying whether the player is occupied.
In this embodiment, the implementation details and technical effects of step 401 may refer to the description of step 201, which is not described herein.
In response to the query that the player is occupied, a request to commonly use the player is sent to the occupant, step 402.
In this embodiment, the implementation details and technical effects of step 402 may refer to the description of step 202, which is not repeated here.
In response to receiving the message from the occupant rejecting the common use player, step 403, the priority of the requesting party is compared with the priority of the occupant.
In this embodiment, after receiving the message sent by the occupant to reject the player for common use, the executing body may directly obtain the priority information pre-stored by the requester and the priority information pre-stored by the occupant, or may send a request for obtaining the priority information to the requester and the occupant, respectively, so as to obtain the priority information of the requester and the occupant. Wherein the priority information includes priorities of the requesting party and the occupying party for use by the player.
After the execution body acquires the priority information of the requesting party and the priority information of the occupying party, the priority of the player used by the occupying party is compared with the priority of the player used by the requesting party.
The priority of the requesting party and the priority of the occupying party can be predetermined according to actual requirements and specific application scenes. For example, the requestor and the occupant are different applications, the requestor is an instant messaging application, and the occupant is a non-instant messaging application, so that the priority of the instant messaging application, i.e., the requestor, can be set to be high, and the priority of the non-instant messaging application, i.e., the occupant, can be set to be low.
For another example, the requesting party and the occupying party are different modules in the same application program, the requesting party is a call module, the occupying party is a music playing module, and the priority of the call module, i.e. the requesting party, can be set to be high, and the priority of the music playing module, i.e. the occupying party, is set to be low.
In some alternatives, the requestor and the occupant are different modules of the same application, and the priority of the requestor and the priority of the occupant are determined from the hosting service of the application.
In this implementation, if the requester and the occupant are different modules of the same application, the priority of the requester and the priority of the occupant are determined according to the host service of the application.
For example, if the host service of the current application program is instant messaging, when the requesting party is the instant messaging module of the current application program and the occupying party is any module of the current application program except the instant messaging module, the priority information of the requesting party is high priority and the priority information of the occupying party is low priority. In a specific example, an instant messaging application is an instant messaging application, where the primary service is instant messaging, and if the occupying party and the requesting party are a call module and a music playing module of an application program respectively, the priority information of the occupying party is high priority, and the priority information of the requesting party is low priority.
For another example, if the hosting service of the current application program is music playing, when the requesting party is a music playing module of the current application program and the occupying party is any module of the current application program other than the music playing module, the priority information of the requesting party is high priority and the priority information of the occupying party is low priority. For example, in a music playing application, the primary service is music playing, and if the occupying party and the requesting party are respectively a music playing module and a message pushing prompt tone module of an application program, the priority information of the occupying party is high priority, and the priority information of the requesting party is low priority.
In addition, it should be noted that the priority of the player used by each module belonging to the same application may be further prioritized according to the association degree between each module and the application hosting service.
Specifically, the application program includes three modules that require the player to be used: the first module, the second module and the third module are sequentially arranged from high to low in association degree with the application program camping service, and the second module can be set to be the first priority, namely the highest priority, the third module is the second priority, and the first module is the third priority, namely the lowest priority.
According to the implementation mode, the priority of the requesting party and the occupying party for the player is determined according to the main service of the same application program to which the modules corresponding to the requesting party and the occupying party respectively belong, so that the modules corresponding to the main service of the application program can be effectively ensured not to be preempted by the modules corresponding to the non-main service when the player is used, and the effectiveness and the practicability for managing the player are further improved.
In some alternatives, the priority of the requestor and the priority of the occupant are determined based on registration information sent at initialization of the requestor and the occupant, respectively.
In this implementation, the executing body may determine priorities of the requesting party and the occupying party according to the registration information respectively received from the requesting party and the occupying party and transmitted at the time of initialization, where the executing body may determine priorities of the requesting party and the occupying party directly according to priority information included in the registration information transmitted from the requesting party and priority information included in the registration information transmitted from the occupying party; the priority information corresponding to the registration information of the requesting party and the registration information of the occupying party can be searched in a preset registration information and priority information comparison table according to the registration information sent by the requesting party and the registration information sent by the occupying party, so that the priorities of the requesting party and the occupying party are determined.
According to the implementation mode, the priority information of the occupied party and the priority information of the requesting party are contained in the registration information sent during initialization, so that the execution main body can store the priority information of the requesting party and the priority information of the occupied party in advance, the problem that a request for acquiring the priority information is temporarily sent to the requesting party and the occupied party during priority comparison of the occupied party and the requesting party is avoided, and the efficiency of managing the player is improved.
In response to determining that the priority of the requestor is higher than the priority of the occupant, the occupant is controlled to release the player for use by the requestor, step 405.
In this embodiment, the executing body may send a message to the occupant requesting the occupant to terminate use of the player after comparing the priorities of the requester and the occupant and determining that the priority of the requester is higher than the priority of the occupant. After the received message, the occupying party terminates the use of the player and releases the player to the requesting party for use.
Specifically, the requesting party and the occupying party are respectively a video call module and a music playing module of the instant messaging application, and because the host service of the instant messaging application is instant messaging, the video call module is of high priority, the music playing module is of low priority, that is, the priority of the requesting party is higher than that of the occupying party, the executing main body sends a message for requesting the occupying party to terminate using the player to the occupying party after comparing the priority of the requesting party with that of the occupying party to determine that the priority of the requesting party is higher than that of the occupying party, and the occupying party, that is, the music module, after receiving the message, releases the player for the requesting party, that is, the video call module.
In addition, it should be noted that the requesting party may return the player to the occupying party after using the player, so that the occupying party can continue to use the player.
In some alternatives, a message is sent to the requestor that the request failed in response to determining that the priority of the requestor is lower than the priority of the occupant.
In this implementation, the executing body sends a request failure message to the requesting party after comparing the priority of the requesting party with the priority of the occupying party, and determining that the priority of the requesting party is lower than the priority of the occupying party, where the request failure message may include a reason for the request failure, for example, that the player is being used by other applications or other modules.
According to the implementation mode, after the priority of the requesting party is lower than that of the occupying party, the message of the request failure is sent to the requesting party, so that the requesting party is prevented from randomly preempting the player, and the management effectiveness of the player is further improved.
In the above embodiment of the present application, after receiving the message sent by the occupant to reject the player for common use, the priority of the requester is compared with the priority of the occupant; and in response to determining that the priority of the requesting party is higher than the priority of the occupying party, controlling the occupying party to release the player for the requesting party, and controlling the player to actively release the player for the requesting party according to the priorities of the requesting party and the occupying party under the condition that the requesting party and the occupying party cannot use the player together, so that the reliability of managing the player is ensured, and the effectiveness of managing the player is further improved.
With further reference to fig. 5, as an implementation of the method shown in the foregoing figures, the present application provides an embodiment of a player management device, where the embodiment of the device corresponds to the embodiment of the method shown in fig. 1, and the device is specifically applicable to various electronic devices.
As shown in fig. 5, the player management device 500 of the present embodiment includes: a query module 501, a request module 502, a use module 503.
Wherein the query module 501 may be configured to query whether the player is occupied in response to receiving a request for use of the player sent by the requester.
The request module 502 may be configured to send a request to the occupant to commonly use the player in response to a query that the player is occupied.
The control module 503 may be configured to control a party with a higher priority to use the player according to the priority of the requesting party and the priority of the occupying party in response to receiving a message sent by the occupying party that refuses to commonly use the player.
In some alternatives of this embodiment, the control module further comprises: a comparison sub-module configured to compare the priority of the requesting party with the priority of the occupying party; and a release unit configured to control the occupant to release the player for use by the requester in response to determining that the priority of the requester is higher than the priority of the occupant.
In some alternatives of this embodiment, the control module further comprises: and a sending sub-module configured to send a message to the requestor that the request failed in response to determining that the priority of the requestor is lower than the priority of the occupant.
In some alternative aspects of this embodiment, the priority of the requestor and the priority of the occupant are determined based on registration information sent upon initialization of the requestor and the occupant, respectively.
In some optional manners of this embodiment, the requesting party and the occupying party are both user parties of the same application program, and the priority information of the requesting party and the priority information of the occupying party are determined according to a camping service of the application program.
In some alternatives of this embodiment, the apparatus further comprises: and a use module configured to allow the requesting party to use the player together with the occupying party in response to receiving a message sent by the occupying party to allow the player to be used together, wherein the message to allow the player to be used together is determined by the occupying party based on attribute information of the requesting party.
In this embodiment, the play manager includes a management unit 601, where the management unit 601 is configured to perform the player management method described in any of the above embodiments.
The management unit 601 may be configured to manage the player, for example, in response to receiving a use request sent by a requester for the player, query whether the player is occupied, and if the player is unoccupied, directly allocate the player to the requester; if the player is already occupied, a party with a high priority is controlled to use the player, etc., according to the priorities of the occupied party and the requesting party.
In some alternatives, the player manager further comprises at least one of: a request unit 602, configured to send a player usage request to the management unit; a registration unit 603 for registering with the management unit at the time of initialization of the request unit; and the monitoring unit is used for monitoring the message of releasing the player sent by the management unit and sending the monitored message of interrupting the player and changing the route to the management unit.
In this implementation, the requesting units 602, 603, 604 are configured to send player usage requests to the management unit 601. Here, the requesting units 602, 603, 604 may be various units requiring a player, for example, a video call unit, a dictation unit, a video play unit, an audio play unit, etc., which is not limited by the present application.
Registration units 605, 606, 607 for registering with the management unit 601 at the time of initialization of the request units 602, 603, 604, i.e. transmitting registration information to the management unit 601
The registration information may include, among other things, priority information of the requesting units 602, 603, 604, attribute information, whether a play protocol is used, etc.
Here, the play protocol is a commonly observed convention defined between the requesting units 602, 603, 604 and the management unit 601, to require that the requesting units 602, 603, 604 have to send an application to the management unit 601 when using the player.
The registration units 605, 606, 607 may register the class of the above-described play protocol in the management unit 601 upon initialization of the request units 602, 603, 604.
A listening unit 608, configured to listen to the message sent by the management unit 601 to release the player, so as to control the occupant to release the player for the requester, and to listen to the message interrupting the player and the route changing and send the message to the management unit 601.
Here, the reason why the listening unit 608 receives the interrupt player message may include various kinds, for example, interrupted or resumed by a phone or third party software, and the like.
The reason why the listening unit 608 receives the route change message may also include various kinds, for example, switching on or off the headset, etc.
According to an embodiment of the present application, the present application also provides an electronic device and a readable storage medium.
As shown in fig. 7, which is a block diagram of an electronic device of a player management method according to an embodiment of the present application.
Electronic devices are intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The electronic device may also represent various forms of mobile devices, such as personal digital processing, cellular telephones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions, are meant to be exemplary only, and are not meant to limit implementations of the applications described and/or claimed herein.
As shown in fig. 7, the electronic device includes: one or more processors 701, memory 702, and interfaces for connecting the various components, including high-speed interfaces and low-speed interfaces. The various components are interconnected using different buses and may be mounted on a common motherboard or in other manners as desired. The processor may process instructions executing within the electronic device, including instructions stored in or on memory to display graphical information of the GUI on an external input/output device, such as a display device coupled to the interface. In other embodiments, multiple processors and/or multiple buses may be used, if desired, along with multiple memories and multiple memories. Also, multiple electronic devices may be connected, each providing a portion of the necessary operations (e.g., as a server array, a set of blade servers, or a multiprocessor system). One processor 701 is illustrated in fig. 7.
Memory 702 is a non-transitory computer readable storage medium provided by the present application. The memory stores instructions executable by the at least one processor to cause the at least one processor to perform the player management method provided by the present application. The non-transitory computer readable storage medium of the present application stores computer instructions for causing a computer to execute the player management method provided by the present application.
The memory 702 is used as a non-transitory computer readable storage medium for storing non-transitory software programs, non-transitory computer executable programs, and modules, such as program instructions/modules (e.g., the query module 501, the request module 502, and the control module 503 shown in fig. 5) corresponding to the player management method according to the embodiments of the present application. The processor 701 executes various functional applications of the server and data processing by running non-transitory software programs, instructions, and modules stored in the memory 702, that is, implements the player management method in the above-described method embodiments.
Memory 702 may include a storage program area that may store an operating system, at least one application program required for functionality, and a storage data area; the storage data area may store data created by use of the electronic device of the player management method, and the like. In addition, the memory 702 may include high-speed random access memory, and may also include non-transitory memory, such as at least one magnetic disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory 702 optionally includes memory remotely located relative to processor 701, which may be connected to player-managed electronic devices via a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.
The electronic device of the player management method may further include: an input device 703 and an output device 704. The processor 701, the memory 702, the input device 703 and the output device 704 may be connected by a bus or otherwise, in fig. 7 by way of example.
The input device 703 may receive input numeric or character information and generate key signal inputs related to user settings and function control of the electronic device managed by the player, such as a touch screen, keypad, mouse, trackpad, touchpad, pointer stick, one or more mouse buttons, track ball, joystick, and like input devices. The output device 704 may include a display apparatus, auxiliary lighting devices (e.g., LEDs), and haptic feedback devices (e.g., vibration motors), among others. The display device may include, but is not limited to, a Liquid Crystal Display (LCD), a Light Emitting Diode (LED) display, and a plasma display. In some implementations, the display device may be a touch screen.
Various implementations of the systems and techniques described here can be realized in digital electronic circuitry, integrated circuitry, application specific ASIC (application specific integrated circuit), computer hardware, firmware, software, and/or combinations thereof. These various embodiments may include: implemented in one or more computer programs, the one or more computer programs may be executed and/or interpreted on a programmable system including at least one programmable processor, which may be a special purpose or general-purpose programmable processor, that may receive data and instructions from, and transmit data and instructions to, a storage system, at least one input device, and at least one output device.
These computing programs (also referred to as programs, software applications, or code) include machine instructions for a programmable processor, and may be implemented in a high-level procedural and/or object-oriented programming language, and/or in assembly/machine language. As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, apparatus, and/or device (e.g., magnetic discs, optical disks, memory, programmable Logic Devices (PLDs)) used to provide machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term "machine-readable signal" refers to any signal used to provide machine instructions and/or data to a programmable processor.
To provide for interaction with a user, the systems and techniques described here can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to a user; and a keyboard and pointing device (e.g., a mouse or trackball) by which a user can provide input to the computer. Other kinds of devices may also be used to provide for interaction with a user; for example, feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form, including acoustic input, speech input, or tactile input.
The systems and techniques described here can be implemented in a computing system that includes a background component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front-end component (e.g., a user computer having a graphical user interface or a web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such background, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: local Area Networks (LANs), wide Area Networks (WANs), and the internet.
The computer system may include a client and a server. The client and server are typically remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.
According to the technical scheme of the embodiment of the application, the effective management of the player is realized, and the problem that players are mutually preempted among the players is avoided.
It should be appreciated that various forms of the flows shown above may be used to reorder, add, or delete steps. For example, the steps described in the present application may be performed in parallel, sequentially, or in a different order, provided that the desired results of the disclosed embodiments are achieved, and are not limited herein.
The above embodiments do not limit the scope of the present application. It will be apparent to those skilled in the art that various modifications, combinations, sub-combinations and alternatives are possible, depending on design requirements and other factors. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present application should be included in the scope of the present application.
Claims (14)
1. A player management method comprising:
inquiring whether the player is occupied or not in response to receiving a use request of the player sent by a requester;
In response to a query that a player is occupied, sending a request for commonly using the player to an occupant, wherein the request for commonly using the player comprises attribute information of the requester; the attribute information of the requester includes the type of use of the player by the requester;
Responding to the received message of refusing to jointly use the player, and controlling a party with high priority to use the player according to the priority of the requesting party and the priority of the occupying party; the message of refusing to jointly use the player is obtained by judging the occupying party based on a preset compatible use rule; the preset compatible use rules are determined based on attribute information of the requesting party or based on whether the requesting party and the occupying party belong to the same application program;
the method further comprises the steps of:
And allowing the requesting party to commonly use the player with the occupying party in response to receiving a message which is sent by the occupying party and allows the player to be commonly used, wherein the message which allows the player to be commonly used is determined by the occupying party based on the attribute information of the requesting party.
2. The method of claim 1, the controlling a higher priority party of the requesting party and the occupying party to use a player according to the priority of the requesting party and the priority of the occupying party, comprising:
comparing the priority of the requester with the priority of the occupant;
in response to determining that the priority of the requestor is higher than the priority of the occupant, the occupant is controlled to release a player for use by the requestor.
3. The method of claim 2, wherein controlling the player to be used by the one of the requesting party and the occupying party having the higher priority according to the priority of the requesting party and the priority of the occupying party, further comprises:
And in response to determining that the priority of the requesting party is lower than the priority of the occupying party, sending a message to the requesting party that the request failed.
4. A method according to any of claims 1-3, wherein the priority of the requesting party and the priority of the occupying party are determined based on registration information sent at initialization of the requesting party and the occupying party, respectively.
5. A method according to any of claims 1-3, wherein the requesting party and the occupying party are different modules of the same application, and the priority of the requesting party and the priority of the occupying party are determined according to the hosting service of the application.
6. A player management apparatus comprising:
A query module configured to query whether the player is occupied in response to receiving a use request for the player sent by the requester;
a request module configured to send a request for commonly using the player to an occupant in response to a query that the player is occupied, the request for commonly using the player including attribute information of the requester; the attribute information of the requester includes the type of use of the player by the requester;
A control module configured to control a party with a higher priority among the requester and the occupant to use a player according to the priority of the requester and the priority of the occupant in response to receiving a message sent by the occupant to reject the common use of the player; the message of refusing to jointly use the player is obtained by judging the occupying party based on a preset compatible use rule; the preset compatible use rules are determined based on attribute information of the requesting party or based on whether the requesting party and the occupying party belong to the same application program;
The apparatus further comprises:
And a use module configured to allow the requesting party to use the player together with the occupying party in response to receiving a message sent by the occupying party to allow the player to be used together, wherein the message to allow the player to be used together is determined by the occupying party based on attribute information of the requesting party.
7. The apparatus of claim 6, the control module further comprising:
a comparison sub-module configured to compare the priority of the requestor with the priority of the occupant;
a release sub-module configured to control the occupant to release a player for use by the requestor in response to determining that the priority of the requestor is higher than the priority of the occupant.
8. The apparatus of claim 7, the control module further comprising: a sending sub-module configured to send a message to the requestor that a request failed in response to determining that the priority of the requestor is lower than the priority of the occupant.
9. The apparatus of any of claims 6-8, wherein the priority of the requesting party and the priority of the occupying party are determined based on registration information sent at initialization of the requesting party and the occupying party, respectively.
10. The apparatus of any of claims 6-8, wherein the requestor and the occupant are different modules of a same application, and the priority of the requestor and the priority of the occupant are determined according to a camping service of the application.
11. A play manager comprising a management unit for performing the method of one of claims 1-5.
12. The play manager of claim 11, wherein the player manager further comprises at least one of:
A request unit, configured to send a player usage request to the management unit;
A registration unit configured to register with the management unit when the request unit is initialized;
and the monitoring unit is used for monitoring the message of releasing the player sent by the management unit and sending the monitored message of interrupting the player and changing the route to the management unit.
13. An electronic device, comprising:
at least one processor; and
A memory communicatively coupled to the at least one processor; wherein,
The memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-5.
14. A non-transitory computer readable storage medium storing computer instructions for causing the computer to perform the method of any one of claims 1-5.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010570894.3A CN113821312B (en) | 2020-06-19 | 2020-06-19 | Player management method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010570894.3A CN113821312B (en) | 2020-06-19 | 2020-06-19 | Player management method and device |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113821312A CN113821312A (en) | 2021-12-21 |
| CN113821312B true CN113821312B (en) | 2024-07-19 |
Family
ID=78912302
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010570894.3A Active CN113821312B (en) | 2020-06-19 | 2020-06-19 | Player management method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113821312B (en) |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107229448A (en) * | 2017-06-30 | 2017-10-03 | 联想(北京)有限公司 | Audio frequency playing method and electronic equipment |
| CN111061546A (en) * | 2019-10-24 | 2020-04-24 | 深圳市元征科技股份有限公司 | Power amplifier management method, device, terminal equipment and storage medium |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101600015A (en) * | 2008-06-06 | 2009-12-09 | 深圳富泰宏精密工业有限公司 | Audio playing management system and method |
| CN105530171B (en) * | 2015-12-23 | 2020-08-25 | 腾讯科技（深圳）有限公司 | Method and device for playing instant message voice by vehicle-mounted terminal |
| CN105790802A (en) * | 2016-02-29 | 2016-07-20 | 惠州市德赛西威汽车电子股份有限公司 | Sound sources management method in dual-terminal interconnection mode |
| CN106155828A (en) * | 2016-07-13 | 2016-11-23 | 微鲸科技有限公司 | For play-back application resource control method and equipment |
-
2020
- 2020-06-19 CN CN202010570894.3A patent/CN113821312B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107229448A (en) * | 2017-06-30 | 2017-10-03 | 联想(北京)有限公司 | Audio frequency playing method and electronic equipment |
| CN111061546A (en) * | 2019-10-24 | 2020-04-24 | 深圳市元征科技股份有限公司 | Power amplifier management method, device, terminal equipment and storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113821312A (en) | 2021-12-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20170293465A1 (en) | Playback manager | |
| JP2022023769A (en) | Method for allocating server resource, device, electronic device, computer readable storage medium and computer program | |
| US8813177B2 (en) | Background application management | |
| US11341443B2 (en) | Prioritizing sequential application tasks | |
| US11432137B2 (en) | Service notification method for mobile edge host and apparatus | |
| US10536322B2 (en) | Resource management for services | |
| JP2017523709A (en) | Proxy transactions between communication endpoints | |
| WO2019001074A1 (en) | Remote process calling method and apparatus, and computer device | |
| KR20070027613A (en) | System for dynamic arbitration of a shared resource on a device | |
| CN112437018A (en) | Flow control method, device, equipment and storage medium for distributed cluster | |
| KR20070028446A (en) | System for application priority based on device operating mode | |
| JP2017530589A (en) | Communication awareness transmission over cellular networks | |
| US11831735B2 (en) | Method and device for processing mini program data | |
| CN111770176B (en) | Traffic scheduling method and device | |
| CN112650879A (en) | Song playing method, device, equipment, storage medium and computer program product | |
| CN113821312B (en) | Player management method and device | |
| JP2021010164A (en) | Method and apparatus for processing notification using notification preset | |
| KR101541664B1 (en) | Method and system for managing parallel resource requests in a portable computing device | |
| US20140049594A1 (en) | Conference Server Communication Techniques | |
| CN108702301B (en) | System and method for host facility assignment for conference sessions | |
| CN112328404B (en) | Load balancing method and device, electronic equipment and computer readable medium | |
| CN107409127B (en) | License management for contacts with multiple identities | |
| CN110933122A (en) | Method, apparatus, and computer storage medium for managing server | |
| CN109831385B (en) | Message processing method and device and electronic equipment | |
| US20110125902A1 (en) | Apparatus And A Method For Resource Management |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |