Service control method and device, equipment, medium and program product

Abstract

The invention relates to a service control method and device, equipment, a medium and a program product. The service control method comprises the following steps: determining service type information, calling state information and application state information of a first service; determining whether the first service is a to-be-released service based on the service type information, the calling state information and the application state information; and in response to the first service being the to-be-released service, executing a service release strategy on the first service. The service type information, the calling state information and the application state information of the first service are used as the basis for judging whether the first service is the to-be-released service or not, so that the first services of different types, different calling states and different application states are comprehensively monitored; according to the method and the device, the service release strategy is executed on the first service which actually has no operation requirement so as to be released in time, the system performance is prevented from being influenced and unnecessary response is prevented from being generated when the memory load is heavy, and the user experience is improved.

Description

Technical Field

[0001] This disclosure relates to the field of memory technology, specifically to a service control method, apparatus, device, medium, and program product. Background Technology

[0002] As a crucial component of a system, services provide functional support to the application they reside in or other applications. To conserve resources such as memory, it is typically necessary to monitor the services running in the system and release services that are no longer needed, thus releasing the resources they consume in a timely manner.

[0003] However, the service control methods using related technologies rely solely on the state of the application to determine whether a service has operational needs. This makes it difficult to release some services that do not actually have operational needs in a timely manner, which can affect system performance when memory load is heavy and generate unnecessary responses, resulting in a poor user experience. Summary of the Invention

[0004] To overcome the problems existing in related technologies, this disclosure provides a service control method, apparatus, equipment, medium, and program product.

[0005] According to a first aspect of the present disclosure, a service control method is provided, the service control method comprising:

[0006] The service type information, call status information, and application status information of the first service are determined, wherein the service type information is used to characterize the service type of the first service, the call status information is used to characterize whether the first service is called, and the application status information is used to characterize the status of the application corresponding to the first service in the system.

[0007] Based on the service type information, the call status information, and the application status information, determine whether the first service is a service to be released;

[0008] In response to the first service being a service to be released, a service release policy is executed for the first service.

[0009] In some embodiments of this disclosure, determining whether the first service is a service to be released based on the service type information, the call status information, and the application status information includes:

[0010] If the service type information indicates that the first service is a task-type service, and in response to the call status information satisfying the release conditions for task-type services and the application status information indicating that the application is in the system background and has no background running permission, the first service is determined to be a service to be released.

[0011] In some embodiments of this disclosure, the call status information includes a task call count for the first service, wherein the task call count is incremented once when the first service is started by a task call, and the task call count is decremented once when the first service is finished by a task call.

[0012] The release condition for the task-type service includes: the task call count returning to zero.

[0013] In some embodiments of this disclosure, determining whether the first service is a service to be released based on the service type information, the call status information, and the application status information includes:

[0014] If the service type information indicates that the first service is a call-type service, and the call status information satisfies the release conditions for call-type services and the application status information indicates that the application is in the system background and has no background running permission, then the first service is determined to be a service to be released.

[0015] In some embodiments of this disclosure, the call status information includes the caller binding relationship information of the first service;

[0016] The release condition for the call-type service includes: the caller binding relationship information of the first service indicates that there is no caller bound to the first service.

[0017] In some embodiments of this disclosure, the caller binding relationship information includes the number of callers or the caller identifier.

[0018] In some embodiments of this disclosure, the call status information includes key-value pairs, where the service instance corresponding to the first service is the key in the key-value pairs, and the caller identifier of each caller bound to the first service is the value in the key-value pairs.

[0019] The release condition for the callable service includes: the value of the key-value pair corresponding to the first service is empty.

[0020] In some embodiments of this disclosure, the service control method further includes:

[0021] In response to the first service being bound to a new calling client, the calling client identifier of the newly bound calling client is added to the value of the key-value pair corresponding to the first service;

[0022] In response to the first service unbinding from the calling client, the calling client identifier of the unbound calling client is deleted from the value of the key-value pair corresponding to the first service;

[0023] In response to the termination of the application process of the first service, the caller identifier corresponding to the terminated application is deleted from the value of the key-value pair corresponding to the first service.

[0024] In some embodiments of this disclosure, there are multiple first services and multiple determined services to be released, and the step of executing a service release policy on the first service includes:

[0025] Based on the uninvoked time information and priority information of each of the first services identified as services to be released, some or all of the services to be released are released. The uninvoked time information is used to characterize the duration during which the first service has not been invoked, and the priority information is used to characterize the priority of the application corresponding to the first service in the system.

[0026] In some embodiments of this disclosure, based on the uncall time information and priority information of each of the first services determined to be services to be released, some or all of the services to be released are released, including:

[0027] In response to the fact that the duration of the uncalled time information exceeds a preset time threshold and the priority represented by the priority information is lower than a preset level, the service to be released is released.

[0028] In some embodiments of this disclosure, releasing the service to be released based on its uncalled time information and priority information includes:

[0029] Based on the uncalled time information and the priority information, the release order of each of the services to be released is determined;

[0030] In response to the satisfaction of preset service release conditions, the services to be released are released in the release order.

[0031] In some embodiments of this disclosure, the preset service release conditions include:

[0032] Memory pressure exceeds the pressure threshold, and / or,

[0033] The number of services to be released exceeds the quantity threshold.

[0034] According to a second aspect of the present disclosure, a service control apparatus is provided, the service control apparatus comprising:

[0035] The first determining module is used to determine the service type information, call status information and application status information of the first service, wherein the service type information is used to characterize the service type of the first service, the call status information is used to characterize whether the first service is called, and the application status information is used to characterize the status of the application corresponding to the first service in the system.

[0036] The second determining module is used to determine whether the first service is a service to be released based on the service type information, the call status information, and the application status information.

[0037] A release module is configured to execute a service release policy on the first service in response to the first service being a service to be released.

[0038] According to a third aspect of the present disclosure, an electronic device is provided, the electronic device comprising:

[0039] processor;

[0040] Memory used to store processor-executable instructions;

[0041] The processor is configured to execute the service control method as described in the first aspect.

[0042] According to a fourth aspect of the present disclosure, a non-transitory computer-readable storage medium is provided, wherein when instructions in the storage medium are executed by a processor of an electronic device, the electronic device is enabled to perform the service control method as described in the first aspect.

[0043] According to a fifth aspect of the present disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements the service control method as described in the first aspect.

[0044] The technical solutions provided by the embodiments of this disclosure may include the following beneficial effects: the service type information, call status information and application status information of the first service are all used as the basis for determining whether the first service is a service to be released, realizing comprehensive monitoring of the first service of different types, different call statuses and different application statuses, ensuring that the service release strategy is executed for the first service that has no actual running needs so as to be released in a timely manner, avoiding the impact on system performance and the generation of unnecessary responses when the memory load is heavy, and improving the user experience.

[0045] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0046] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0047] Figure 1 This is a flowchart illustrating a service control method according to an exemplary embodiment.

[0048] Figure 2 This is a system framework diagram illustrating a service control method for task-oriented services according to an exemplary embodiment.

[0049] Figure 3 This is a system framework diagram illustrating a service control method for a calling service, according to an exemplary embodiment.

[0050] Figure 4 This is a flowchart illustrating, according to an exemplary embodiment, the process of releasing a service to be released based on its uncalled time information and priority information.

[0051] Figure 5 This is a flowchart illustrating a service control method according to another exemplary embodiment.

[0052] Figure 6 This is a block diagram of a service control device according to an exemplary embodiment.

[0053] Figure 7 This is a block diagram of an electronic device according to an exemplary embodiment.

[0054] In the picture:

[0055] 10-First determining module; 20-Second determining module; 30-Release module; 101-Processing component; 102-Memory; 103-Power component; 104-Multimedia component; 105-Audio component; 106-Input / output interface; 107-Sensor component; 108-Communication component; 109-Processor. Detailed Implementation

[0056] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Rather, they are merely examples of apparatuses and methods consistent with some aspects of the invention as detailed in the appended claims.

[0057] Services are important components of a system. For example, push notification services, voice engine services, and audio playback services provide corresponding functionalities for their respective applications or other applications. It is typically necessary to monitor running services in the system in real time and release services that are no longer needed to save resources such as memory.

[0058] In related technologies, services running in a process can be released when the process dies. Also, when a background application with restricted permissions is running in the background, the processor can be put into a low-power idle state after a period of time, and the task-oriented services can be released.

[0059] However, the service control methods using related technologies rely solely on the state of the application in which the service resides to determine whether the service still needs to run. This lacks monitoring of callable services, making it difficult to release some services that do not actually need to run in a timely manner. This results in system performance being affected when memory load is heavy and unnecessary responses being generated, leading to a poor user experience.

[0060] Based on this, the exemplary embodiments of this disclosure provide a service control method. By determining the service type information, call status information, and application status information of a first service, and based on these information, determining whether the first service is a service to be released, and then executing a service release policy on the first service when it is a service to be released, this method achieves automatic release of first services with no operational needs, saving resources such as memory. By using the service type information, call status information, and application status information of the first service as the basis for determining whether the first service is a service to be released, comprehensive monitoring of first services of different types, call statuses, and application statuses is achieved. This ensures that service release policies are executed on first services with no actual operational needs to achieve timely release, avoiding the impact on system performance and unnecessary responses when memory load is heavy, thus improving the user experience.

[0061] In one exemplary embodiment, a service control method is provided, applied to the framework (FW) layer of a system, referenced. Figure 1 As shown, the service control methods include:

[0062] S100. Determine the service type information, call status information and application status information of the first service, wherein the service type information is used to characterize the service type of the first service, the call status information is used to characterize whether the first service has been called, and the application status information is used to characterize the status of the application corresponding to the first service in the system.

[0063] In step S100, the first service can be one or more. The first service can be all currently running services in the system, or it can be some of the currently running services. If the first service is some of the currently running services, the remaining currently running services in the system other than the first service are the second running services. The second running services may not be the target of subsequent monitoring and release. For example, the second service may be the part of the currently running services with the highest priority and the lowest probability of release for the corresponding calling end.

[0064] Each service has corresponding service type information, invocation status information, and application status information. Service type information represents the service type of the first service, which may include, for example, task-based services and invocation-based services. Invocation status information represents the status of the first service being invoked by a task or invoking client; if a first service is not invoked by a task or invoking client, it means that the first service may not have a running requirement. Application status information represents the status of the application corresponding to the first service in the system, such as whether the corresponding application is in the foreground or background of the system and whether it has background running permissions. If the application corresponding to a first service is in the background of the system and does not have background running permissions, it means that the application containing the first service is in an invisible background, and the first service may not have a running requirement.

[0065] S200: Based on service type information, call status information, and application status information, determine whether the first service is a service to be released.

[0066] In step S200, it can be determined whether the first service is a service to be released based on the service type information, call status information, and application status information of the first service. For example, by monitoring the service type of the first service, whether it is called by a task or a calling client, whether the application it belongs to is in the foreground or background of the system, and whether it has background running permissions, it can be determined whether the first service is a service to be released. At different times during system operation, the number of first services identified as services to be released can be 0, 1, ..., N, where N is a positive integer greater than 1.

[0067] S300: In response to the first service being a service to be released, execute the service release policy for the first service.

[0068] In step S300, if a first service is a service to be released, it means that the first service has no operational requirement at the current moment, and continuing to run the first service would result in meaningless occupation of resources such as memory. Therefore, when a first service is determined to be a service to be released, a service release policy is executed for the first service to release it in the manner corresponding to the service release policy. Releasing the first service may include, for example, destroying all data and information related to the service itself, thereby saving resources such as memory.

[0069] In this embodiment, by determining the service type information, call status information, and application status information of the first service, and based on these information, determining whether the first service is a service to be released, and then executing a service release policy when the first service is a service to be released, automatic release of the first service with no operational needs is achieved, saving resources such as memory. Using the service type information, call status information, and application status information of the first service as the basis for determining whether the first service is a service to be released enables comprehensive monitoring of first services of different types, call statuses, and application statuses. This ensures that the service release policy is executed on first services with no actual operational needs for timely release, avoiding the impact on system performance under heavy memory load and the generation of unnecessary responses, thus improving the user experience.

[0070] In some embodiments, determining whether a first service is a service to be released based on service type information, call status information, and application status information includes:

[0071] If the service type information indicates that the first service is a task-type service, and the call status information meets the release conditions for a task-type service and the application status information indicates that the application is in the system background and has no background running permissions, then the first service is determined to be a service to be released.

[0072] As mentioned earlier, the first service type can include task-type services. Task-type services are called through the startservice interface but do not provide an external interface. Task-type services have corresponding task-type service release conditions. If the service type information indicates that the first service is a task-type service, and the call status information of the task-type service meets the task-type service release conditions, and the application status information indicates that the application is in the system background and does not have background running permissions, it means that the task-type service has not been called by a task and the application is in an invisible background. It can be considered that the first service does not have a running requirement at the current moment. Therefore, the first service is identified as a service to be released, and the service release policy is subsequently executed on the first service, realizing the monitoring and control of task-type services.

[0073] In this embodiment, the service type of the first service is classified according to service type information. If the first service is a task-type service, it is determined whether the call status information meets the release conditions for task-type services. Then, it is determined whether the application containing the first service is in the system background and does not have background running permissions based on the application status information. This allows task-type services whose call status information meets the release conditions for task-type services and whose application status information indicates that the application is in the system background and does not have background running permissions to be identified as services to be released, thus realizing the determination of whether the first service is a service to be released. Using the call status information meeting the release conditions for task-type services as the basis for determining services to be released ensures that the first service has not been called by a task. Using the application status information indicating that the application is in the system background and does not have background running permissions as the basis for determining services to be released ensures that the application is in an invisible background, thereby ensuring that the first service identified as a service to be released does not have running requirements, thus improving the accuracy of determining services to be released.

[0074] In some embodiments, the call status information includes a task call count for the first service. The task call count is incremented once when the first service is started by a task call, and decremented once when the first service is finished by a task call. The release condition for a task-based service includes: the task call count reaching zero.

[0075] As mentioned earlier, the call status information is used to indicate whether the first service has been called. For task-type services, the call status information indicates whether it has been called by a task, i.e., whether there is a task that calls the task-type service. The call status information includes the task call count corresponding to the first service. The task call count is incremented once when the first service is called by a task and decremented once when the first service is called by a task, so as to represent the number of tasks that call the first service through the task call count.

[0076] For task-based services, there may be situations where a single task-based service is called by multiple tasks. Although multiple service instances are not created, the `onStartCommand` entity will execute multiple times due to the different data carried by the tasks. Only when all tasks calling the task-based service have completed their execution, meaning there are no longer any tasks calling the service at the current moment, can the task-based service be considered to have no runtime requirement at the call state level and can be released. Therefore, resetting the task call count to zero can be used as the release condition for the corresponding task-based service.

[0077] For example, when the first service starts being called by M tasks, the task call count increases by M; when the first service ends being called by L of these tasks, the task call count decreases by L, where M is a positive integer and L is a positive integer less than or equal to M. When the task call count reaches zero, it means that all tasks calling the first service have completed execution, and it can be determined that there are no tasks calling the first service at the current moment. Therefore, the task call count reaching zero can be used as a condition for releasing a task-based service. (Reference) Figure 2 As shown, for task-type services, task call counts can be counted in the application (APP) layer of the system, and the system framework (FW) layer can determine whether the task call count meets the release conditions of the task-type service and whether the application status information indicates that the application is in the background of the system and has no background running permission, so as to determine whether the task-type service can be released as a service to be released and implement the service release strategy.

[0078] In this embodiment, the task call count is used as call status information. The task call count increments once when the first service is called by a task and decrements once when the first service is finished being called by a task. When the task call count reaches zero, it indicates that there are currently no tasks calling the first service, serving as the release condition for the task-type service. This avoids the difficulty in determining whether the first service still has operational needs after being called by multiple tasks. Using the task call count reaching zero as the release condition provides a basis for determining services to be released, ensuring that first services without operational needs are identified as services to be released and subsequently released through service release strategies, thus improving the user experience.

[0079] In some embodiments, determining whether a first service is a service to be released based on service type information, call status information, and application status information includes:

[0080] If the service type information indicates that the first service is a call-type service, and the call status information meets the release conditions for call-type services and the application status information indicates that the application is in the system background and has no background running permissions, then the first service is determined to be a service to be released.

[0081] As mentioned earlier, the first service type can also include invocation services. Invocation services are invoked through the bindservice interface and provide interfaces to the outside world. Invocation services have corresponding release conditions. If the service type information indicates that the first service is an invocation service, and the invocation status information of the invocation service meets the release conditions of the invocation service, and the application status information indicates that the application is in the system background and does not have background running permissions, it means that the invocation service has not been invoked by the calling end, i.e., other applications, and the application is in an invisible background. It can be considered that the first service does not have a running requirement at the current moment. Therefore, the first service is identified as a service to be released, and the service release policy is subsequently executed on the first service, realizing the monitoring and control of invocation services.

[0082] In this embodiment, the service type of the first service is classified according to service type information. If the first service is a call-type service, it is determined whether the call status information meets the release conditions for call-type services. Then, it is determined whether the application containing the first service is in the system background and does not have background running permissions based on the application status information. This allows call-type services whose call status information meets the release conditions for call-type services and whose application status information indicates that the application is in the system background and does not have background running permissions to be identified as services to be released, thus realizing the determination of whether the first service is a service to be released. Using the call status information meeting the release conditions for call-type services as the basis for determining services to be released ensures that the first service has not been called by the caller. Using the application status information indicating that the application is in the system background and does not have background running permissions as the basis for determining services to be released ensures that the application is in an invisible background, thereby ensuring that the first service identified as a service to be released does not have running requirements, thus improving the accuracy of determining services to be released.

[0083] In some embodiments, the call status information includes the caller binding relationship information of the first service. The release condition for the call-type service includes: the caller binding relationship information of the first service indicating that there is no caller bound to the first service.

[0084] The calling end is any application other than the application containing the first service that can call the first service. The call status information may include the calling end binding relationship information of the first service. For example, the calling end binding relationship information may represent the statistics of the calling ends that call the first service, that is, the statistics of the calling ends that have a binding relationship with the first service. The calling end binding relationship information can be used to determine whether there is a calling end that is currently bound to the first service.

[0085] For call-based services, the calling client obtains an IBinder reference to the service (i.e., the application containing the first service) through `bindservice` and then makes the API call. All `bindservice` and `unbindservice` calls can be tracked at the framework layer. Related API calls can be defined, modified, or intercepted through AMS (Activity Manager Service). Only after all calling clients have unbound is the first service no longer used by the calling clients. Therefore, the call-based service can be considered to have no runtime requirement at the call state level and can be released. Thus, the calling client binding relationship information representing the absence of a calling client bound to the first service can be used as the release condition for the call-based service.

[0086] refer to Figure 3 As shown, for call-type services, the caller can call the service and bind and unbind the service with each caller in the application (APP) layer of the system. The caller binding relationship information of each call-type service is updated in the framework (FW) layer of the system. The framework layer of the system judges whether the caller binding relationship information meets the release conditions of the call-type service and whether the application status information indicates that the application is in the background of the system and has no background running permission, so as to determine whether the call-type service can be released and implement the service release strategy.

[0087] In this embodiment, the call status information includes the caller binding relationship information of the first service. Using the absence of a caller bound to the first service as a condition for service release allows for the determination of whether the service has operational needs at the call status level, providing a basis for determining whether the first service is a service to be released. This ensures that none of the first services subsequently executing the service release strategy have any bound callers, avoiding situations where callers cannot call their bound first services, thus guaranteeing system stability.

[0088] In some embodiments, the caller binding relationship information includes the number of callers or the caller identifier.

[0089] As mentioned earlier, the caller binding relationship information can characterize the statistics of the callers that call the first service, that is, the statistics of the callers that have a binding relationship with the first service. Based on the caller binding relationship information, it can be determined whether there is a caller that is currently bound to the first service.

[0090] The caller binding relationship information can include the number of callers, which can be an integer equal to or greater than 0. The number of callers can directly represent the number of callers that are bound to the first service. When a caller binds to the first service, the number of callers increases by 1. When a caller unbinds from the first service, the number of callers decreases by 1. The number of callers can be used to represent the statistics of callers that are bound to the first service.

[0091] The caller binding relationship information may also include a caller identifier, which can be, for example, the name or number corresponding to the caller. For instance, the caller identifier could be caller1, caller2, etc. The caller identifier can represent the identity information of the caller that is bound to the first service. When a caller binds to the first service, the corresponding caller identifier is added to the caller list of the first service. When a caller unbinds from the first service, the corresponding caller identifier is removed from the caller list of the first service. This allows the caller identifier in the caller list to represent the statistical information of the callers bound to the first service.

[0092] In this embodiment, the number of callers or the caller identifier is used as the caller binding relationship information. This allows for the statistical representation of callers bound to the first service through the number of callers or the caller identifiers in the caller list. When the number of callers is zero or no caller identifier is found in the caller list, it indicates that no caller is bound to the first service. Using zero callers or no caller identifier in the caller list as a condition for releasing call-type services provides a basis for determining services to be released. This ensures that subsequent service release strategies can be executed on first services with no operational needs to achieve timely release, thus improving the user experience.

[0093] In some embodiments, the call status information includes key-value pairs, where the service instance corresponding to the first service is the key, and the caller identifier of each caller bound to the first service is the value. The release condition for a call-type service includes: the value of the key-value pair corresponding to the first service is empty.

[0094] The call status information can also include key-value pairs. The key in the key-value pair is the service instance corresponding to the first service, and the value is the caller identifier of each caller bound to the first service. The key-value pairs can represent the statistics of the callers that call the first service, that is, the statistics of the callers that are bound to the first service. The key-value pairs can be used to determine whether there are any callers bound to the first service at the current time. When the value in the key-value pair is empty, it means that there are no callers bound to the first service at the current time.

[0095] As mentioned earlier, the first service is only no longer used by the calling parties after the binding between the first service and each calling party is removed. Therefore, it can be considered that this calling service has no operational requirement at the calling state level and can be released. Thus, the condition for releasing the calling service can be that the key-value pair corresponding to the first service is null.

[0096] In this embodiment, the call status information includes key-value pairs. The service instance corresponding to the first service is used as the key in the key-value pair, and the caller identifier of each caller bound to the first service is used as the value in the key-value pair. When the value of the key-value pair corresponding to the first service is empty, it means that there is no caller bound to the first service. Key-value pairs facilitate the simultaneous determination of whether multiple first services have callers bound to them. Using an empty value for the key-value pair corresponding to the first service as a release condition for the call-type service provides a basis for determining whether the first service is a service to be released. This ensures that service release strategies can be executed on first services that have no running requirements to achieve timely release, thus improving the user experience.

[0097] In some embodiments, the service control method further includes:

[0098] In response to the first service binding a new caller, the caller identifier of the newly bound caller is added to the value of the corresponding key-value pair of the first service.

[0099] When a first service is bound to a new caller, the caller identifier of the newly bound caller is added to the value of the key-value pair corresponding to the first service, so that the value of the key-value pair corresponding to the first service is not empty. When determining whether the release condition of the caller service is met, the existence of a caller bound to the first service can be determined based on the key-value pair, so that the first service cannot be determined as a service to be released and the service release policy is executed in the subsequent process, thereby maintaining the normal operation of the first service.

[0100] In response to the first service unbinding from the calling client, the calling client identifier of the unbound calling client is removed from the value of the key-value pair corresponding to the first service.

[0101] When a first service is unbound from a caller, the caller identifier of the unbound caller is deleted from the value of the key-value pair corresponding to the first service. If the value of the key-value pair corresponding to the first service is empty after deletion, when determining whether the release condition of the caller-type service is met, it can be determined from the key-value pair that there is no caller bound to the first service, so that the first service can be identified as a service to be released and the service release strategy can be executed in the subsequent process, thereby realizing the release of the first service.

[0102] In response to the termination of the application process of the first service, the caller identifier corresponding to the terminated application is removed from the value of the key-value pair corresponding to the first service.

[0103] When an application process of a first service terminates, the caller identifier corresponding to the terminated application is deleted from the value of the key-value pair corresponding to the first service. If the value of the key-value pair corresponding to the first service is empty after deletion, when determining whether the release condition of the call-type service is met, it can be determined from the key-value pair that there is no caller bound to the first service. This allows the first service to determine the service to be released so as to execute the service release strategy in the subsequent process, thereby realizing the release of the first service.

[0104] In this embodiment, when a new calling client is bound to the first service, the calling client identifier of the calling client is added to the value of the key-value pair corresponding to the first service. When the first service is unbound from the calling client or the application process ends, the calling client identifier of the application that is unbound or terminated is deleted from the value of the key-value pair corresponding to the first service. This achieves real-time updating of the key-value pair, ensuring that whether the value of the key-value pair corresponding to the first service is empty can accurately represent whether there is a calling client bound to the first service. This ensures accurate judgment of the release conditions of the calling service when the call status information includes key-value pairs, improving the accuracy and convenience of determining whether the first service is a service to be released.

[0105] Understandably, if the service type information indicates that the first service is both a task-type service and a call-type service, and the call status information simultaneously meets the release conditions for both task-type and call-type services, and the application status information indicates that the application is running in the system background and has no background running permissions, then the first service is determined to be a service to be released.

[0106] The first service can also be both a task-oriented service and a call-oriented service. In this case, the first service can be called by a task through the `startservice` interface and by the caller (i.e., other applications) through the `bindservice` interface. If the service type information indicates that the first service is both a task-oriented service and a call-oriented service, and the call status information of the first service simultaneously meets the release conditions for both task-oriented and call-oriented services, and the application status information indicates that the application is in the system background and does not have background running permissions, it means that the first service has not been called by a task or caller and the application is in an invisible background. Only then can it be considered that the first service does not have a running requirement at the current moment, and the first service is identified as a service to be released. Subsequently, the service release policy is executed on the first service, realizing the monitoring and control of the first service that is simultaneously a task-oriented service and a call-oriented service.

[0107] It should be noted that the above three methods for determining whether the first service is a service to be released can be executed simultaneously, or any one of them or any combination of two can be selected. When executed simultaneously, the monitoring and control of all first services can be achieved based on the call status information and application status information.

[0108] Understandably, if the call status information of a task-based service does not meet the release conditions, or if the call status information of a call-based service does not meet the release conditions, it means that the first service is still being called by the task or the caller. If the application status information of the first service indicates that the application is in the system foreground, or that the application is in the system background and has background running permissions, it means that the first service still needs to provide the corresponding functional support. If these first services are identified as services to be released and the service release policy is executed, some functions will not be supported, affecting the normal operation of the system. Therefore, it is necessary to maintain the normal operation of other first services except those identified as services to be released.

[0109] In some embodiments, there are multiple first services and multiple services determined to be released. The service release strategy is executed on the first services, including: releasing some or all of the services to be released based on the uncalled time information and priority information of each first service determined to be a service to be released. The uncalled time information is used to characterize the duration during which the first service has not been called, and the priority information is used to characterize the priority of the application corresponding to the first service in the system.

[0110] The "Not Called Time" information represents the duration for which the first service has not been called. The longer the first service remains uncalled, the lower the likelihood of it being called again, and the less impact releasing it will have on the normal operation of the system. The "Priority" information represents the priority of the application corresponding to the first service within the system. The lower the priority of the application corresponding to the first service within the system, the lower the probability of the first service being potentially called, and the less impact releasing it will have on the normal operation of the system.

[0111] For example, the time information of not being invoked can be represented by a timestamp. The timestamp can record the time when the first service was last invoked and be set and cleared when it is invoked again. Resident applications, foreground visible applications, and applications with user-aware functions have the highest priority in the system. Applications not visible in the foreground, applications bound to system processes, and background applications bound to foreground applications have the next highest priority in the system. Applications in cached state and empty process state have the lowest priority.

[0112] When there are multiple services identified as pending release, some or all of the pending release services can be released based on the uncall time information and priority information of each of the pending release services. This ensures that the possibility and potential probability of the released pending release services being called again are low, so that the released services will not affect the normal operation of the system.

[0113] In this embodiment, based on the uncall time information and priority information of each first service determined to be a service to be released, some or all of the services to be released are released. This ensures that the possibility and potential probability of the released services being called again are low, so that the released first services will not affect the normal operation of the system. This realizes the release of first services that have no running requirements, avoids the impact on system performance and unnecessary responses when the memory load is heavy, and improves the user experience.

[0114] In some embodiments, based on the uncall time information and priority information of each first service determined to be a service to be released, some or all of the services to be released are released, including: in response to the duration represented by the uncall time information exceeding a preset time threshold and the priority represented by the priority information being lower than a preset level, the services to be released are released.

[0115] When releasing some or all of the services to be released based on the uncalled time information and priority information of each first service identified as a service to be released, if the duration of the current uncalled time information of the service identified as a service to be released exceeds a preset time threshold, and the priority information indicates a priority lower than a preset level, that is, if the corresponding application's lower priority service has not been called for a period of time, it means that the possibility of this part of the service to be released being called again is low, and the service to be released can be released, thus realizing the active release of the first services identified as services to be released.

[0116] In this embodiment, when the duration of the uncalled time information of the first service identified as a service to be released exceeds a preset time threshold, and the priority information indicates a priority lower than a preset level, the service to be released is released. This proactively releases services with a low probability of being called again or potentially called, thus enabling the proactive release of some first services with no operational needs. This avoids impacting system performance and generating unnecessary responses when memory load is heavy, thereby improving the user experience.

[0117] In some embodiments, reference Figure 4 As shown, based on the uncalled time information and priority information of the service to be released, the service to be released is released, including:

[0118] S310. Based on the uncalled time information and priority information, determine the release order of each service to be released.

[0119] In step S310, since the non-call time information and priority information determine the possibility and probability of the first service being called again, the release order of each service to be released can be determined according to the non-call time information and priority information. The service to be released with the lower possibility and probability of being called again is determined as the higher release order, so that the service to be released with the higher release order can be released first in the future.

[0120] For example, based on the priority information of each service to be released, i.e., the priority of the application corresponding to the first service to be released in the system, the services to be released with higher priority in the system corresponding to the application are identified as Class A services, all of which correspond to lower release orders. The services to be released with lower priority in the system corresponding to the application are identified as Class B services, all of which correspond to higher release orders. Then, based on the uncalled time information, the Class B services with higher release orders are sorted. Services to be released with longer uncalled durations within Class B are assigned higher release orders, while services to be released with shorter uncalled durations within Class B are assigned lower release orders.

[0121] S320. In response to the satisfaction of the preset service release conditions, release the services to be released in the release order.

[0122] In step S320, when the preset service release condition is met, it indicates that the system is under significant pressure and there is a high demand to release services to conserve memory and other resources. If the system has ample free memory and other resources, the system can still operate normally even without releasing services. Therefore, when the preset service release condition is met, i.e., when there is a high demand to release services, services can be released in a predetermined release order. For example, when the preset service release condition is met, services with higher release order among the B-type services can be released first, until all B-type services are released, and then the A-type services are released.

[0123] In this embodiment, the release order of each service to be released is determined based on the non-call time information and priority information. When the preset service release conditions are met, the services to be released are released in the release order. This can prioritize the release of services with low probability of being called again and low probability of being called when the system is under heavy pressure. This allows the release of services to be released to be passively executed according to the system operation, and minimizes the impact of service release on system operation, thereby improving the user experience.

[0124] In some embodiments, the preset service release conditions include: memory pressure exceeding a pressure threshold, or the number of services to be released exceeding a quantity threshold, or both memory pressure exceeding a pressure threshold and the number of services to be released exceeding a quantity threshold.

[0125] As mentioned earlier, when the preset service release conditions are met, it indicates that the system is under significant pressure, and there is a high demand to release services to conserve memory and other resources. A preset service release condition can be set by setting the memory pressure to a threshold. This allows services to be released in order of priority when the memory pressure exceeds the threshold, thereby reducing system memory pressure. Alternatively, a preset service release condition can be set by setting the number of services to be released to a threshold. This allows services to be released in order of priority when the number of services to be released exceeds the threshold, thereby reducing the number of services awaiting release in the system.

[0126] In this embodiment, either or a combination of the following conditions is used: memory pressure exceeding a pressure threshold and the number of services to be released exceeding a quantity threshold. This can reduce the system's memory pressure or the number of services to be released in the system by releasing the services to be released. In this way, when the system is under high operating pressure, the services to be released are released passively to ensure the normal operation of the system and improve the user experience.

[0127] In one exemplary embodiment, a service control method is provided, referring to... Figure 5 As shown, the service control methods include:

[0128] S1. The task call count of any first service is incremented by one when the first service is started by a task call, and decremented by one when the first service is finished by a task call.

[0129] S2. In response to any first service binding a new caller, add the caller identifier of the newly bound caller to the value of the key-value pair corresponding to that first service;

[0130] S3. In response to any first service unbinding from the calling end, the calling end identifier of the unbound calling end is deleted from the value of the key-value pair corresponding to that first service;

[0131] S4. In response to the termination of any application process of the first service, delete the caller identifier corresponding to the terminated application from the value of the key-value pair corresponding to the first service.

[0132] S5. Determine the service type of each first service based on the service type information of each first service;

[0133] S6. If the first service is a task-type service, in response to the task call count of the first service being zeroed and the application status information indicating that the application is in the background of the system and has no background running permission, the first service is determined to be a service to be released.

[0134] S7. If the first service is a call-type service, and the value of the key-value pair corresponding to the first service is empty and the application status information indicates that the application is in the background of the system and has no background running permission, then the first service is determined to be a service to be released.

[0135] S8. If the first service is both a task-type service and a call-type service, in response to the task call count of the first service being zeroed, the corresponding key-value pair being empty, and the application status information indicating that the application is in the system background and has no background running permission, the first service is determined to be a service to be released.

[0136] S9. Based on the uncall time information and priority information of each first service identified as a service to be released, determine the release order of each service to be released;

[0137] S10. In response to memory pressure exceeding the pressure threshold and / or the number of services to be released exceeding the quantity threshold, release the services to be released in the order of release.

[0138] In this embodiment, by determining the service type information, call status information, and application status information of the first service, and based on these information, determining whether the first service is a service to be released, and then executing a service release policy when the first service is a service to be released, automatic release of the first service with no operational needs is achieved, saving resources such as memory. Using the service type information, call status information, and application status information of the first service as the basis for determining whether the first service is a service to be released enables comprehensive monitoring of first services of different types, call statuses, and application statuses. This ensures that the service release policy is executed on first services with no actual operational needs for timely release, avoiding the impact on system performance under heavy memory load and the generation of unnecessary responses, thus improving the user experience.

[0139] In one exemplary embodiment, a service control device is provided, with reference to Figure 6As shown, the service control device includes a first determining module 10, a second determining module 20, and a releasing module 30. The first determining module 10 is used to determine the service type information, call status information, and application status information of the first service. The service type information represents the service type of the first service, the call status information represents whether the first service has been called, and the application status information represents the status of the application corresponding to the first service in the system. The second determining module 20 is used to determine whether the first service is a service to be released based on the service type information, call status information, and application status information. The releasing module 30 is used to execute a service release strategy for the first service in response to the first service being a service to be released.

[0140] In this embodiment, the first determining module 10 determines the service type information, call status information, and application status information of the first service. The second determining module 20 then determines whether the first service is a service to be released based on these information. Finally, the releasing module 30 executes a service release strategy on the first service when it is determined to be a service to be released. This achieves automatic release of the first service when it has no operational requirements, saving memory and other resources. By using the service type information, call status information, and application status information of the first service as criteria for determining whether it is a service to be released, comprehensive monitoring of first services of different types, call statuses, and application statuses is achieved. This ensures that service release strategies are executed on first services with no actual operational requirements for timely release, avoiding performance degradation and unnecessary responses under heavy memory loads, thus improving the user experience.

[0141] In one embodiment, the second determining module 20 is further configured to: if the service type information indicates that the first service is a task-type service, in response to the call status information satisfying the release conditions of the task-type service and the application status information indicating that the application is in the system background and has no background running permission, determine that the first service is a service to be released.

[0142] In one embodiment, the call status information includes the task call count of the first service. The task call count is incremented once when the first service is called by a task and decremented once when the first service is called by a task. The release condition of the task-type service includes: the task call count reaches zero.

[0143] In one embodiment, the second determining module 20 is further configured to: if the service type information indicates that the first service is a call-type service, in response to the call status information satisfying the release conditions of the call-type service and the application status information indicating that the application is in the system background and has no background running permission, determine that the first service is a service to be released.

[0144] In one embodiment, the call status information includes the caller binding relationship information of the first service; the call type service release condition includes: the caller binding relationship information of the first service indicates that there is no caller bound to the first service.

[0145] In one embodiment, the caller binding relationship information includes the number of callers or the caller identifier.

[0146] In one embodiment, the call status information includes key-value pairs, where the service instance corresponding to the first service is the key in the key-value pair, and the caller identifier of each caller bound to the first service is the value in the key-value pair; the call type service release condition includes: the value of the key-value pair corresponding to the first service is empty.

[0147] In one embodiment, the service control device further includes an update module, which is configured to: in response to the first service binding a new caller, add the caller identifier of the newly bound caller to the value of the key-value pair corresponding to the first service; in response to the first service unbinding from the caller, delete the caller identifier of the unbound caller from the value of the key-value pair corresponding to the first service; and in response to the application process of the first service ending, delete the caller identifier corresponding to the application that has ended its process from the value of the key-value pair corresponding to the first service.

[0148] In one embodiment, the release module 30 is further configured to: release part or all of the services to be released based on the uncalled time information and priority information of each first service determined to be a service to be released, wherein the uncalled time information is used to characterize the duration during which the first service is not currently called, and the priority information is used to characterize the priority of the application corresponding to the first service in the system.

[0149] In one embodiment, the release module 30 is further configured to: release the service to be released in response to the duration of the uncalled time information representation exceeding a preset time threshold and the priority of the priority information representation being lower than a preset level.

[0150] In one embodiment, the release module 30 is further configured to: determine the release order of each service to be released based on the non-call time information and priority information; and release the services to be released in the release order in response to the satisfaction of the preset service release conditions.

[0151] In one embodiment, the preset service release conditions include: memory pressure exceeding a pressure threshold, and / or, the number of services to be released exceeding a quantity threshold.

[0152] In one exemplary embodiment, an electronic device is provided, such as a mobile phone, laptop computer, tablet computer, smartwatch, or other device capable of providing functional support through services.

[0153] refer to Figure 7As shown, the electronic device may include one or more of the following components: processing component 101, memory 102, power component 103, multimedia component 104, audio component 105, input / output (I / O) interface 106, sensor component 107, and communication component 108.

[0154] Processing component 101 typically controls the overall operation of an electronic device, such as operations associated with display, telephone calls, data communication, camera operation, and recording. Processing component 101 may include one or more processors 109 to execute instructions to perform all or part of the steps of the methods described above. Furthermore, processing component 101 may include one or more modules to facilitate interaction between processing component 101 and other components. For example, processing component 101 may include a multimedia module to facilitate interaction between multimedia component 104 and processing component 101.

[0155] Memory 102 is configured to store various types of data to support the operation of the electronic device. Examples of such data include instructions for any application or method used to operate on the electronic device, contact data, phonebook data, messages, pictures, videos, etc. Memory 102 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0156] Power component 103 provides power to various components of the electronic device. Power component 103 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the electronic device.

[0157] Multimedia component 104 includes a screen that provides an output interface between the electronic device and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touchscreen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors may sense not only the boundaries of touch or swipe actions but also the duration and pressure associated with the touch or swipe operation. In some embodiments, multimedia component 104 includes a front-facing camera and / or a rear-facing camera. When the electronic device is in an operating mode, such as a shooting mode or a video mode, the front-facing camera and / or the rear-facing camera may receive external multimedia data. Each front-facing camera and rear-facing camera may be a fixed optical lens system or have focal length and optical zoom capabilities.

[0158] Audio component 105 is configured to output and / or input audio signals. For example, audio component 105 includes a microphone (MIC) configured to receive external audio signals when the electronic device is in an operating mode, such as call mode, recording mode, and voice recognition mode. The received audio signals may be further stored in memory 102 or transmitted via communication component 108. In some embodiments, audio component 105 also includes a speaker for outputting audio signals.

[0159] I / O interface 106 provides an interface between processing component 101 and peripheral interface modules, such as keyboards, click wheels, buttons, etc. These buttons may include, but are not limited to, home buttons, volume buttons, power buttons, and lock buttons.

[0160] Sensor assembly 107 includes one or more sensors for providing state assessments of various aspects of the electronic device. For example, sensor assembly 107 can detect the on / off state of the electronic device, the relative positioning of components such as the display and keypad of the electronic device, changes in the position of the electronic device or a component of the electronic device, the presence or absence of user contact with the electronic device, the orientation or acceleration / deceleration of the electronic device, and temperature changes of the electronic device. Sensor assembly 107 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. Sensor assembly 107 may also include a light sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, sensor assembly 107 may also include an accelerometer, a gyroscope, a magnetometer, a pressure sensor, or a temperature sensor.

[0161] Communication component 108 is configured to facilitate wired or wireless communication between electronic devices and other devices. Devices can access wireless networks based on communication standards, such as WiFi, 2G, or 3G, or combinations thereof. In one exemplary embodiment, communication component 108 receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, communication component 108 also includes a near-field communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on radio frequency identification (RFID) technology, Infrared Data Association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0162] In an exemplary embodiment, the electronic device may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the service control method applied to the electronic device described above.

[0163] In one exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 102 including instructions, which can be executed by a processor 109 of an electronic device to perform the service control method applied to the electronic device described above. For example, the non-transitory computer-readable storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc. When the instructions in the storage medium are executed by the processor 109 of the electronic device, the electronic device is able to perform the service control method shown in the above embodiments.

[0164] In one exemplary embodiment, a computer program product is also provided, including a computer program that, when executed by processor 109, implements the service control method shown in the above embodiments.

[0165] Other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of the invention are indicated by the following claims.

[0166] It should be understood that the present invention is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A service control method, characterized in that, The service control method includes: The service type information, call status information, and application status information of the first service are determined, wherein the service type information is used to characterize the service type of the first service, the call status information is used to characterize whether the first service is called, and the application status information is used to characterize the status of the application corresponding to the first service in the system. Based on the service type information, the call status information, and the application status information, determine whether the first service is a service to be released; In response to the first service being a service to be released, a service release policy is executed for the first service.

2. The service control method according to claim 1, characterized in that, Determining whether the first service is a service to be released based on the service type information, the call status information, and the application status information includes: If the service type information indicates that the first service is a task-type service, and in response to the call status information satisfying the release conditions for task-type services and the application status information indicating that the application is in the system background and has no background running permission, the first service is determined to be a service to be released.

3. The service control method according to claim 2, characterized in that, The call status information includes the task call count of the first service. The task call count is incremented once when the first service is started by a task call and decremented once when the first service is finished by a task call. The release condition for the task-type service includes: the task call count returning to zero.

4. The service control method according to claim 1, characterized in that, Determining whether the first service is a service to be released based on the service type information, the call status information, and the application status information includes: If the service type information indicates that the first service is a call-type service, and the call status information satisfies the release conditions for call-type services and the application status information indicates that the application is in the system background and has no background running permission, then the first service is determined to be a service to be released.

5. The service control method according to claim 4, characterized in that, The call status information includes the caller binding relationship information of the first service; The release condition for the call-type service includes: the caller binding relationship information of the first service indicates that there is no caller bound to the first service.

6. The service control method according to claim 5, characterized in that, The caller binding relationship information includes the number of callers or the caller identifier.

7. The service control method according to claim 5, characterized in that, The call status information includes key-value pairs, where the service instance corresponding to the first service is the key in the key-value pair, and the caller identifier of each caller bound to the first service is the value in the key-value pair. The release condition for the callable service includes: the value of the key-value pair corresponding to the first service is empty.

8. The service control method according to claim 7, characterized in that, The service control method further includes: In response to the first service being bound to a new calling client, the calling client identifier of the newly bound calling client is added to the value of the key-value pair corresponding to the first service; In response to the first service unbinding from the calling client, the calling client identifier of the unbound calling client is deleted from the value of the key-value pair corresponding to the first service; In response to the termination of the application process of the first service, the caller identifier corresponding to the terminated application is deleted from the value of the key-value pair corresponding to the first service.

9. The service control method according to any one of claims 1 to 8, characterized in that, There are multiple first services and determined services to be released. The step of executing a service release policy on the first service includes: Based on the uninvoked time information and priority information of each of the first services identified as services to be released, some or all of the services to be released are released. The uninvoked time information is used to characterize the duration during which the first service has not been invoked, and the priority information is used to characterize the priority of the application corresponding to the first service in the system.

10. The service control method according to claim 9, characterized in that, Based on the uncall time information and priority information of each of the first services identified as services to be released, release some or all of the services to be released, including: In response to the fact that the duration of the uncalled time information exceeds a preset time threshold and the priority represented by the priority information is lower than a preset level, the service to be released is released.

11. The service control method according to claim 9, characterized in that, The step of releasing the service to be released based on its uncalled time information and priority information includes: Based on the uncalled time information and the priority information, the release order of each of the services to be released is determined; In response to the satisfaction of preset service release conditions, the services to be released are released in the release order.

12. The service control method according to claim 11, characterized in that, The preset service release conditions include: Memory pressure exceeds the pressure threshold, and / or, The number of services to be released exceeds the quantity threshold.

13. A service control device, characterized in that, The service control device includes: The first determining module is used to determine the service type information, call status information and application status information of the first service, wherein the service type information is used to characterize the service type of the first service, the call status information is used to characterize whether the first service is called, and the application status information is used to characterize the status of the application corresponding to the first service in the system. The second determining module is used to determine whether the first service is a service to be released based on the service type information, the call status information, and the application status information. A release module is configured to execute a service release policy on the first service in response to the first service being a service to be released.

14. An electronic device, characterized in that, The electronic device includes: processor; Memory used to store processor-executable instructions; The processor is configured to execute the service control method as described in any one of claims 1 to 12.

15. A non-transitory computer-readable storage medium, characterized in that, When the instructions in the storage medium are executed by the processor of the electronic device, the electronic device is able to perform the service control method as described in any one of claims 1 to 12.

16. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the service control method as described in any one of claims 1 to 12.

Images