WO2019119951A1 - 设备资源管理 - Google Patents

设备资源管理 Download PDF

Info

Publication number
WO2019119951A1
WO2019119951A1 PCT/CN2018/110850 CN2018110850W WO2019119951A1 WO 2019119951 A1 WO2019119951 A1 WO 2019119951A1 CN 2018110850 W CN2018110850 W CN 2018110850W WO 2019119951 A1 WO2019119951 A1 WO 2019119951A1
Authority
WO
WIPO (PCT)
Prior art keywords
apps
app
priority
time window
background
Prior art date
Application number
PCT/CN2018/110850
Other languages
English (en)
French (fr)
Inventor
侯景宽
申燊
赛音毕力格
李朋举
柳晶
Original Assignee
北京三快在线科技有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 北京三快在线科技有限公司 filed Critical 北京三快在线科技有限公司
Publication of WO2019119951A1 publication Critical patent/WO2019119951A1/zh

Links

Images

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
    • 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

Definitions

  • the present disclosure relates to the field of Internet technologies, and in particular, to a device resource management method and apparatus, and an intelligent terminal.
  • APP applications
  • the APP provides services such as promotion, settlement, and payment to ordinary consumers.
  • the device resources occupied by the APP at runtime and in the background are also becoming more and more serious, causing the system of the terminal device to become severe.
  • a device resource management method is provided, which is applied to a device in which a plurality of application programs are installed, the method comprising: according to a historical usage of the plurality of APPs, according to one or And the plurality of APPs are prioritized by the plurality of time windows to obtain a prioritization result of the plurality of APPs in each of the time windows; and the resource occupation ratio and the plurality of APPs according to the device.
  • the respective current states and the prioritization results of the plurality of APPs in the current time window perform background application control on the plurality of APPs.
  • a device resource management apparatus which is applied to a device in which a plurality of application programs are installed, the device comprising: a priority module, configured to be based on a history of the plurality of APPs a usage case, prioritizing the plurality of APPs according to one or more time windows, obtaining a prioritization result of the plurality of APPs in each of the time windows; and applying an application module, configured to The resource usage ratio of the device and the current state of each of the plurality of APPs and the prioritization result of the plurality of APPs in the current time window perform background application control on the plurality of APPs.
  • a storage medium storing a computer program that, when executed by a processor of a device in which a plurality of application programs are installed, causes the device to perform the above The method described in one embodiment.
  • a smart terminal comprising: a processor; a storage medium storing instructions executable by the processor; wherein the processor is configured to perform any of the above embodiments Said method.
  • different initialization configurations may be adapted based on the device type of the application, and the priority of the application data changes according to the user behavior may be dynamically adjusted, thereby implementing system performance optimization based on the application scenario, and improving the user.
  • the priority of the application data changes according to the user behavior may be dynamically adjusted, thereby implementing system performance optimization based on the application scenario, and improving the user.
  • FIG. 1 is a flowchart of a device resource management method according to an embodiment of the present disclosure.
  • FIG. 2 is a flow chart of prioritization according to an embodiment of the present disclosure.
  • FIG. 3 is a flowchart of background application control according to an embodiment of the present disclosure.
  • FIG. 4 is a flowchart of a device resource management method according to another embodiment of the present disclosure.
  • FIG. 5 is a flowchart of background application control according to another embodiment of the present disclosure.
  • FIG. 6 is a schematic block diagram of a device resource management apparatus according to an embodiment of the present disclosure.
  • FIG. 7 is a schematic block diagram of a smart terminal according to an embodiment of the present disclosure.
  • embodiments of the present disclosure may be implemented as a system, apparatus, device, method, or computer program product. Accordingly, the present disclosure may be embodied in the form of full hardware, complete software (including firmware, resident software, microcode, etc.), or a combination of hardware and software.
  • a device resource management method and apparatus and a medium and a smart terminal are proposed.
  • FIG. 1 is a flowchart of a device resource management method according to an embodiment of the present disclosure. As shown in FIG. 1 , the method in this embodiment includes the following steps S101-S102. In one embodiment, the method of the present embodiment may be performed by a device (eg, a cell phone, a tablet, a smart POS machine) on which an application APP is installed.
  • a device eg, a cell phone, a tablet, a smart POS machine
  • an application APP is installed.
  • step S101 based on the historical usage of the plurality of APPs, the plurality of APPs are prioritized according to the time window.
  • This step can achieve priority ordering based on the calculus principle. For example, a single business cycle can be disassembled first, and then multiple historical business cycles can be compared horizontally to complete the priority calculation.
  • the disassembly of a single business cycle is performed by a time window. For example, if a single business cycle is 24 hours a day, the single business cycle can be subdivided into 24 time windows, or a single business cycle can be roughly divided into 2 time windows based on business hours and non-business hours. It can be used as needed, and is not limited here.
  • the result of prioritizing the plurality of APPs in this step may be updated according to a preset period. For example, each time the prioritization sorts the data of the same time window (for example, 8:00-9:00) within 3 days according to a predetermined algorithm, the processing result is sorted, and the sorting result is updated 3 days later.
  • the predetermined algorithm may be to accumulate data within the same time window, and other algorithms may be employed as needed.
  • this step S101 can be implemented by the following process including steps S201-S202.
  • step S201 the usage time of the plurality of APPs in the foreground in a single time window and the number of handovers to the foreground are respectively counted.
  • step S202 according to the usage time and the number of handovers of each APP, priority is performed according to any one of the following ranking strategies: the longer the usage time, the higher the priority of the corresponding APP; and, in two or more When the usage time of the APPs is the same, the higher the number of handovers, the higher the priority of the corresponding APP.
  • the usage time and switching of the same time window for example, 8:00-9:00
  • the preset period for example, 3 days
  • the number of times is: APP 1 (1 hour, 10 times), APP 2 (0.6 hours, 15 times), and APP 3 (0.6 hours, 12 times)
  • the priority ranking result based on the sorting strategy of step S202 is APP 1 >APP 2>APP 3.
  • the foregoing sorting policy further includes: when the usage time and the number of handovers of the two or more APPs are the same, the earlier the handover to the foreground is, the higher the priority of the corresponding APP is.
  • the prioritization of this step may be performed only for applications (also referred to as active applications) that have been used in the corresponding time window of the previous cycle.
  • priority ordering may also be set for the foregoing priority ordering, for example, in each time window, there may be no active application, but the number of active applications does not exceed the preset. Number (for example, 3).
  • step of acquiring an initial configuration may also be included before step S101.
  • the initial configuration for multiple APPs installed on the device can be obtained locally or from the server.
  • the step of obtaining the initial configuration includes determining an initial configuration with the highest matching degree in the same-purpose device usage habit database established according to the label according to the label corresponding to the device.
  • all devices communicating with the server are bound to several specific tags (also can be understood as users or merchants using the device are bound to these tags), and different tags can correspond to different service attributes. For example, including but not limited to industry classification, store size, business nature and mode of operation, and the like.
  • the server side generates a usage habit model in different business scenarios based on the usage history big data of these devices in advance, and stores the generated usage habit model in association with the tag in the usage habit database.
  • the server can search the usage habit database according to the tag bound to the device, and match the most suitable usage habit model to be sent to the device as an initial configuration.
  • the usage habit database is not limited to a certain device, but can be applied to a certain type of device or a plurality of types of devices.
  • the initial configuration includes a prioritization result of at least part of the APPs of the plurality of APPs.
  • the current device obtains the most suitable usage habit model from the server and carries information indicating the following priority: APP 1>APP 2>APP 3, the device applies the priority order to the locally installed APP 1 to APP 3 As the basis for the background application control in the initial stage.
  • the initial configuration further includes information such as a service attribute, an active state, and a virtual memory value corresponding to each APP. For details, refer to the description of the subsequent embodiments.
  • the initial configuration acquired here may also be stored in a time window, for example, subdivided into 24 time windows on a 24 hour basis, or based on business hours and non-business hours. Divided into two time windows, this embodiment can be used as needed, and is not limited herein.
  • step S102 according to the resource occupancy ratio of the device and the current state of the plurality of APPs, the background application control is performed on the plurality of APPs based on the corresponding priority ranking result in the current time window.
  • the embodiment may control the background application of multiple APPs, including: at least one APP running in the background for multiple APPs, combined with the prioritization result of the foregoing steps, and current device resource usage.
  • the situation and the preset threshold are used to selectively keep or terminate the application.
  • this step S102 can be implemented by the following process including steps S301-S305.
  • step S301 it is determined whether the resource occupancy ratio of the device is lower than or equal to the preset value. If yes, go to step S302. Otherwise, if the resource occupancy ratio of the device is higher than the preset value, go to step S303.
  • step S302 in response to any of the plurality of APPs being returned to the background, the APP is applied and kept.
  • the default value is set according to the normal situation of the device resource (for example, the device system has no card). If the resource occupancy ratio of the device is lower than or equal to the preset value, the resource occupancy does not deviate from the normal situation.
  • APPs running in the background can perform keep-alive processing to allocate corresponding system resources.
  • step S303 it is determined whether the resource occupancy ratio of the device is lower than or equal to the warning value. If yes, the process goes to step S304. Otherwise, if the resource occupancy ratio of the device is higher than the warning value, the process goes to step S305.
  • step S304 in response to the APP in the plurality of APPs having a priority higher than or equal to the preset level, the APP is applied to keep the application, and in response to the APP in which the priority is lower than the preset level, the APP is returned to the APP.
  • the app is terminated in the background.
  • the alarm value is set according to the boundary condition of the device resource. If the resource usage ratio of the device is higher than the preset value but lower than the alarm value, the resource occupancy is on the verge of deviating from the normal situation. Therefore, the optimal configuration is required.
  • Part of the APP allocates system resources. For example, for the sort result of APP 1>APP 2>APP 3, assuming that the preset level is 1, the keep-alive processing is performed only when APP 1 is returned to the background, and when APP 2 or APP 3 is returned to the background. The termination process is performed to maintain the resource occupancy of the device in a normal state.
  • step S305 the application is terminated in the order of priority from low to high for the APPs in the background of the plurality of APPs until the resource occupancy ratio of the device is lower than or equal to the preset value.
  • the resource occupancy ratio of the device is higher than the warning value, indicating that the resource usage of the device has deviated from the normal situation, and thus some background applications need to be terminated to recover the corresponding system resources.
  • the APP running in the background is terminated in the order of APP 3, APP 2, and APP 1 in step S305 until the resource occupancy ratio of the device is lower than or equal to a preset value.
  • the resource occupation ratio mentioned in this step S102 may include the occupation percentage of the CPU and the actual usage ratio of the memory, and the corresponding preset value and the warning value are also separately set for the CPU and the memory.
  • the resource occupancy ratio of the device is lower than or equal to the preset value
  • the resource occupation ratio is the memory usage ratio
  • the resource occupancy ratio of the device may utilize the resource occupation before the execution step. The ratio is determined by subtracting the virtual memory value of the corresponding APP in the initial configuration.
  • different initialization configurations may be adapted based on the device type of the application, and the priority of the application data may be dynamically adjusted according to the user behavior, thereby implementing system performance optimization and improvement based on the application scenario.
  • the user experience may be adapted based on the device type of the application, and the priority of the application data may be dynamically adjusted according to the user behavior, thereby implementing system performance optimization and improvement based on the application scenario.
  • the device resource management method of the present disclosure is applicable to smart terminals (eg, smart POS machines) with specialized service requirements.
  • system performance optimization schemes are generally based on To C (To Customer) scenarios, while for To B (To Business) scenarios with specialized business needs, the related technologies are not particularly applicable. Construction plan.
  • To B and To C scenarios have the following differences.
  • To C does not distinguish between detailed usage scenarios and services. It needs to ensure that users at the consumer level have a smooth experience with any application.
  • the To B scenario has strong business attributes and needs to ensure a smooth experience in business applications. Let's make other applications have a smooth experience as much as possible.
  • the To C scenario cannot be expected.
  • the terminal device may have hundreds of applications, and the user does not have a very clear usage rule; the To B scenario is vertical, the service usage is periodic, and the user behavior can be expected.
  • the To C scene is sensitive to power and needs to control power consumption.
  • the To B scene can be charged at any time and is not sensitive to power consumption.
  • FIG. 4 is a flowchart of a device resource management method according to the embodiment.
  • the method in this embodiment includes the following steps S401-S403.
  • the method may be performed by a device having at least one service APP and a plurality of non-service applications installed.
  • the service APP is, for example, an APP dedicated to realizing settlement cashier
  • the non-service APP includes, for example, various APPs for implementing functions such as queuing and take-out orders.
  • step S401 an initial configuration for a plurality of non-service APPs is acquired and applied.
  • the initial configuration for multiple APPs installed on the device can be obtained locally or from the server.
  • the step includes determining an initial configuration with the highest matching degree in the usage habit database established according to the label according to the label corresponding to the device.
  • the specific tags to be matched may include: the industry classification of the merchant (eg, catering, hotel, movie, etc.), the size of the store of the merchant (three sizes of large, medium and small), the nature of the business of the merchant (fast food, barbecue, dinner, etc.) and The way the merchant operates (single store, chain store) and so on.
  • the third-party server can obtain the label content newly bound by the merchant, thereby matching the most suitable non-use in the usage habit database.
  • Business APP initialization configuration For the content of the initial configuration, refer to the description of the embodiment of FIG. 1 , and details are not described herein again.
  • step S402 based on the historical usage of the plurality of non-service APPs, the plurality of non-service APPs are prioritized according to the time window.
  • step S101 in the embodiment of FIG. 1 , which is not repeated here.
  • step S403 according to the resource occupancy ratio of the device and the current state of each APP, the background application control is performed on all APPs based on the result of the corresponding priority ranking in the current time window.
  • the embodiment may control the background application of all the APPs, including: combining the priority ranking result of the foregoing steps, the current device resource usage status, and the current device resource usage for the at least one service APP and the multiple non-service applications. Preset thresholds to selectively keep or terminate applications.
  • this step S403 can be implemented by the following process including steps S501-S505.
  • step S501 it is determined whether the resource occupancy ratio of the device is lower than or equal to the preset value. If yes, go to step S502. Otherwise, if the resource occupancy ratio of the device is higher than the preset value, go to step S503.
  • step S502 in response to any APP in all APPs returning to the background, the application is kept keep alive.
  • the preset value is set according to the normal situation of the device resource occupation (for example, the device system has no card).
  • the resource occupancy ratio of the device is lower than or equal to the preset value, the resource occupancy does not deviate from the normal situation, and the optimized configuration does not need to be triggered.
  • the APP running in the background can perform keep-alive processing to allocate corresponding system resources.
  • step S503 it is determined whether the resource occupancy ratio of the device is lower than or equal to the warning value. If yes, go to step S504. Otherwise, if the resource occupancy ratio of the device is higher than the warning value, go to step S505.
  • step S504 in response to the application of any service APP falling back to the background, the service APP is kept, and the non-service APP is returned to the background in response to the application of the plurality of non-service APPs having a priority higher than or equal to the preset level.
  • the application keeps alive, and the non-service APP is terminated in response to the APP whose priority is lower than the preset level in the plurality of non-service APPs is returned to the background.
  • the alarm value is set according to the boundary condition of the device resource. If the resource occupancy ratio of the device is higher than the preset value but lower than the alarm value, the resource occupancy is on the verge of deviating from the normal situation. Therefore, the optimal configuration needs to be performed only for the service APP and the priority.
  • the higher-level part of the non-business APP allocates system resources. For example, for the non-business APP ranking result APP 1>APP 2>APP 3, assuming that the preset level is 1, the keep-alive processing is performed only when the APP 1 retreats to the background, and when the APP 2 or the APP 3 retreats The termination process is performed during the background operation, so that the resource occupancy of the device is maintained in a normal state under the condition that sufficient resources are allocated for the service APP.
  • step S505 the non-service APPs in the background of the plurality of non-service APPs are terminated in the order of priority from low to high until the resource occupancy ratio of the device is lower than or equal to a preset value.
  • the resource occupancy ratio of the device is higher than the warning value, indicating that the resource usage of the device has deviated from the normal situation, and thus some background applications need to be terminated to recover the corresponding system resources.
  • the APP running in the background is terminated in the order of APP 3, APP 2, and APP 1 in step S505 until the resource occupancy ratio of the device is lower than or equal to a preset value.
  • the To B scenario is reconstructed, and different initialization configurations may be adapted based on the scenario type of the device application, and the non-business application priority dynamics may be performed according to the application data change caused by the user behavior.
  • the adjustment ensures that the resource usage of the device is always maintained in a normal state under the condition that sufficient resources are allocated for the service application, and the system performance optimization based on the application scenario is implemented, thereby improving the user experience.
  • a device resource management apparatus is further provided in the exemplary embodiment.
  • FIG. 6 is a schematic block diagram of a device resource management apparatus according to an embodiment of the present disclosure. As shown in the figure, the device resource management apparatus of this embodiment includes a priority module 61 and an application control module 62.
  • the priority module 61 is configured to prioritize the plurality of APPs according to one or more time windows based on historical usage of the plurality of APPs, to obtain the plurality of APPs at each of the times The result of the prioritization in the window;
  • the application control module 62 is configured to set the plurality of APPs according to the resource occupancy ratio of the device and the current state of each of the plurality of APPs and the priority ranking result of the plurality of APPs in the current time window. Perform background application control.
  • the priority module 61 is configured to respectively determine a usage time of the plurality of APPs in the foreground in a single time window and a number of handovers to switch to the foreground, and according to the usage time and the number of handovers of each APP, The prioritization is performed according to any one of the preset sorting strategies.
  • the preset scheduling policy includes: the longer the usage time, the higher the priority of the corresponding APP; when the usage time of two or more APPs is the same, the higher the number of handovers, the priority of the corresponding APP The higher the level.
  • the preset scheduling policy further includes: when the usage time and the number of handovers of the two or more APPs are the same, the earlier the handover to the foreground is, the higher the priority of the corresponding APP is.
  • the priority module 61 is further configured to update the prioritization of the plurality of APPs according to a preset period.
  • the background application control of the application control module 62 includes at least one of: when the resource occupancy ratio of the device is lower than or equal to a preset value, in response to any of the plurality of APPs retreating to the background, App-preserving the APP; when the resource occupancy ratio of the device is higher than a preset value but lower than the warning value, the APP that is higher than or equal to the preset level in the plurality of APPs is returned to the background. Applying the keep-alive of the APP, responding to the APP in which the priority is lower than the preset level in the plurality of APPs, returning to the background, and terminating the application of the APP; and the resource occupancy ratio of the device is higher than the warning value. When the APPs in the background of the plurality of APPs are terminated in the order of priority from low to high, until the resource occupancy ratio of the device is lower than or equal to a preset value.
  • the device resource management apparatus further includes an initialization module (not shown) configured to obtain an initial configuration with the highest matching degree from the usage habit database established according to the label according to the label corresponding to the device, and The initial configuration acquired by the plurality of APP applications.
  • the initial configuration includes a prioritization result of at least a portion of the APPs of the plurality of APPs.
  • the plurality of APPs are non-service APPs, and the device is further installed with at least one service APP.
  • modules or units of equipment for action execution are mentioned in the detailed description above, such division is not mandatory. Indeed, in accordance with embodiments of the present disclosure, the features and functions of two or more modules or units described above may be embodied in one module or unit. Conversely, the features and functions of one of the modules or units described above may be further divided into multiple modules or units.
  • the components displayed as modules or units may or may not be physical units, ie may be located in one place or may be distributed over multiple network elements. Some or all of the modules may be selected according to actual needs to achieve the objectives of the present disclosure. Those of ordinary skill in the art can understand and implement without any creative effort.
  • a computer readable storage medium having stored thereon a computer program that, when executed by a processor, implements the steps of the method described in any one of the above embodiments.
  • the computer readable storage medium may be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, and an optical data storage device.
  • a smart terminal is also provided, which may be a mobile terminal such as a mobile phone or a tablet computer, or may be a terminal device such as a desktop computer or a server, which is not limited in this embodiment.
  • FIG. 7 shows a schematic diagram of a smart terminal 70 in accordance with an example embodiment of the present disclosure.
  • the smart terminal 70 can be provided as a mobile terminal.
  • smart terminal 70 includes a processing component 71 that further includes one or more processors, and storage resources represented by storage medium 72 for storing instructions executable by processing component 71, such as an application.
  • An application stored in storage medium 72 may include one or more modules each corresponding to a set of instructions.
  • the processing component 71 is configured to execute instructions to perform the device resource management method described above. For the steps of the method, reference may be made to the detailed description in the foregoing method embodiments, and details are not described herein again.
  • the smart terminal 70 may also include a power supply component 73 configured to perform power management of the smart terminal 70, a wired or wireless network interface 74 configured to connect the smart terminal 70 to the network, and an input/output (I/O) interface 75 .
  • the smart terminal 70 can operate based on an operating system stored on the storage medium 72, such as Android, IOS, or the like.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本公开是关于一种设备资源管理方法，应用于安装有多个应用程序APP的设备中。根据该方法，基于所述多个APP的历史使用，按照时间窗对所述多个APP进行优先级排序。根据所述设备的资源占用比例和所述多个APP各自的当前状态，在当前时间窗中基于相应的优先级排序结果对所述多个APP进行后台应用控制。

Description

设备资源管理
相关申请的交叉引用
本专利申请要求于2017年12月22日提交的、申请号为201711405724.4、发明名称为“设备资源管理方法和装置以及智能终端”的中国专利申请的优先权，该申请的全文以引用的方式并入本文中。
技术领域
本公开涉及互联网技术领域，尤其涉及一种设备资源管理方法和装置以及智能终端。
背景技术
随着互联网特别是移动网络的普及，越来越多的产品和服务提供商都选择使用应用程序(APP)作为与消费者交互的渠道之一，甚至越来越多的商业用户也选择第三方提供的APP来向普通消费者提供推广、结算、支付等服务。随着终端设备上安装的APP越来越多，APP在运行时以及在后台占用的设备资源也日益严重，造成终端设备的***卡顿变得严重。
以不断拓展的智能支付业务为例，根据某智能POS(Point of Sale，销售终端)机的使用情况以及商户反馈，无论是在独立收银还是混合使用(例如设备兼顾收银、排队和外卖等多种功能)的业务场景下，都会出现***卡顿的现象，随着使用时间越长甚至会越严重，不仅影响收银相关业务，对其他第三方的应用也会造成影响。
发明内容
本公开的目的是提供一种设备资源管理方法和装置以及智能终端，进而至少在一定程度上克服由于相关技术的限制和缺陷而导致的一个或者多个问题。
本公开的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本公开的实践而习得。
根据本公开实施例的第一方面，提供一种设备资源管理方法，应用于安装有多个应用程序APP的设备中，所述方法包括：基于所述多个APP的历史使用情况，按照一个或多个时间窗对所述多个APP进行优先级排序，得到所述多个APP在每个所述时间窗 内的优先级排序结果；以及根据所述设备的资源占用比例和所述多个APP各自的当前状态以及所述多个APP在当前时间窗内的优先级排序结果，对所述多个APP进行后台应用控制。
根据本公开实施例的第二方面，提供一种设备资源管理装置，应用于安装有多个应用程序APP的设备中，所述装置包括：优先级模块，设置为基于所述多个APP的历史使用情况，按照一个或多个时间窗对所述多个APP进行优先级排序，得到所述多个APP在每个所述时间窗内的优先级排序结果；以及应用控制模块，设置为根据所述设备的资源占用比例和所述多个APP各自的当前状态以及所述多个APP在当前时间窗内的优先级排序结果，对所述多个APP进行后台应用控制。
根据本公开实施例的第三方面，提供一种存储有计算机程序的存储介质，所述计算机程序在由安装有多个应用程序APP的设备的处理器运行时，使所述设备执行如以上任一实施例所述的方法。
根据本公开实施例的第四方面，提供一种智能终端，包括：处理器；存储介质，存储有可由所述处理器执行的指令；其中所述处理器被配置为执行如以上任一实施例所述的方法。
根据本公开的实施例中，可以基于应用的设备类型适配不同的初始化配置，并且根据用户行为导致的应用数据变化进行优先级的动态调整，从而实现基于应用场景的***性能优化，提升了用户体验。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。
附图说明
图1为根据本公开一实施例的设备资源管理方法流程图。
图2为根据本公开一实施例的优先级排序流程图。
图3为根据本公开一实施例的后台应用控制流程图。
图4为根据本公开另一实施例的设备资源管理方法流程图。
图5为根据本公开另一实施例的后台应用控制流程图。
图6为根据本公开一实施例的设备资源管理装置示意框图。
图7为根据本公开一实施例的智能终端示意框图。
具体实施方式
下面将参考若干示例性实施方式来描述本公开的原理和精神。应当理解，给出这些实施方式仅仅是为了使本领域技术人员能够更好地理解进而实现本公开，而并非以任何方式限制本公开的范围。相反，提供这些实施方式是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。
本领域技术人员知道，本公开的实施方式可以实现为一种***、装置、设备、方法或计算机程序产品。因此，本公开可以具体实现为以下形式，即：完全的硬件、完全的软件(包括固件、驻留软件、微代码等)，或者硬件和软件结合的形式。
根据本公开的实施方式，提出了一种设备资源管理方法和装置以及介质和智能终端。
下面参考本公开的若干代表性实施方式，详细阐释本公开的原理和精神。
图1为根据本公开一实施例的设备资源管理方法流程图，如图1所示，本实施例的方法包括以下步骤S101-S102。在一个实施例中，本实施例的方法可由安装有应用程序APP的设备(例如手机、平板、智能POS机)来执行。
在步骤S101中，基于多个APP的历史使用情况，按照时间窗对多个APP进行优先级排序。
为了确定在后续步骤S102中进行后台应用控制的依据，本步骤中需要对多个APP进行优先级排序。本步骤可基于微积分原理来实现优先级的排序。例如，可先将单个业务周期进行拆解，然后再横向对比多个历史业务周期完成优先级的计算。这里，单个业务周期的拆解按时间窗来进行。例如以每天24小时为单个业务周期，则可将这单个业务周期细分为24个时间窗，或者以营业时间和非营业时间为基础将单个业务周期粗分为2个时间窗，本实施例可视需要采用，此处并不加以限制。
在一个实施例中，本步骤对多个APP的优先级排序的结果可按照预设周期进行更新。例如，每次优先级排序对3天内同一时间窗(例如8:00-9:00)的数据按照预定算法进行处理后，对该处理结果进行排序，3天后更新一次排序结果。例如，该预定算法可以是对同一时间窗内的数据进行累加，根据需要也可以采用其他算法。
如图2所示，在一个实施例中，本步骤S101可通过以下包括步骤S201-S202的流程实现。
在步骤S201中，分别统计多个APP在单个时间窗内处于前台的使用时间和切换到前台的切换次数。
在步骤S202中，根据各APP的所述使用时间和切换次数，按照以下排序策略的任意一者进行优先级排序：使用时间越长，对应APP的优先级越高；以及，在两个或多个APP的使用时间相同时，切换次数越高，对应APP的优先级越高。
以设备本地安装的APP 1至APP 3为例，假设经步骤S201统计得到三者在预设周期(例如3天)内同一时间窗(例如8:00-9:00)累加的使用时间和切换次数分别为：APP 1(1小时，10次)、APP 2(0.6小时，15次)和APP 3(0.6小时，12次)，则基于步骤S202的排序策略得到的优先级排序结果为APP 1＞APP 2＞APP 3。
另外，在一个实施例中，上述排序策略还包括：在两个或多个APP的使用时间和切换次数均相同时，切换到前台的时间越早，对应APP的优先级越高。
在一个实施例中，本步骤的优先级排序可仅针对前一周期相应时间窗使用过的应用(也可称活跃应用)进行。另外，为了实现设备资源的优化配置，在一个实施例中针对上述优先级排序还可设置优先级限制，例如，在每个时间窗内，可以没有活跃应用，但活跃应用的数目不超过预设数目(例如3个)。
在一个实施例中，步骤S101之前还可包括获取初始化配置的步骤。
当设备新投入使用时，可从本地或从服务器获取针对设备上已安装的多个APP的初始化配置。在一个实施例中，获取初始化配置的步骤包括根据设备对应的标签，在按照标签建立的同类设备使用习惯数据库中，确定匹配度最高的初始化配置。
以从服务器获取初始化配置为例，所有与服务器通信的设备都与若干个特定的标签绑定(也可以理解为使用设备的用户或商户与这些标签绑定)，不同标签可对应不同的业务属性，例如包括但不限于行业分类、门店规模、业务性质和运营方式等等。服务器侧预先基于这些设备的使用历史大数据生成不同业务场景下使用习惯模型，将生成的使用习惯模型与标签相对应地存储于使用习惯数据库。当新投入使用的设备与服务器通信时，服务器可根据该设备绑定的标签搜索使用习惯数据库，匹配出最适合的使用习惯模型，以作为初始化配置发送至该设备。该使用习惯数据库不局限于某一设备，而可以应用于某一类设备或多类设备。
这里，所述的初始化配置包括上述多个APP中至少部分APP的优先级排序结果。例如，当前设备从服务器获取到最适配的使用习惯模型中携带指示以下优先级的信息： APP 1＞APP 2＞APP 3，则设备将该优先级排序应用于本地安装的APP 1至APP 3以作为初始阶段进行后台应用控制的依据。在一个实施例中，初始化配置还包括各APP对应的业务属性、活跃状态和虚拟内存值等信息，详见后续实施例的描述。
另外，与步骤S101和S102相对应，此处获取的初始化配置也可按时间窗进行存储，例如以每天24小时为基础细分为24个时间窗，或者以营业时间和非营业时间为基础粗分为2个时间窗，本实施例可视需要采用，此处并不加以限制。
在步骤S102中，根据设备的资源占用比例和多个APP的当前状态，在当前时间窗中基于相应的优先级排序结果对多个APP进行后台应用控制。
为了实现设备资源的优化配置，本实施例可对多个APP的后台应用进行控制，包括：针对多个APP中运行于后台的至少一个APP，结合前述步骤的优先级排序结果、当前设备资源使用情况以及预设阈值来选择性的保活或终止应用。
如图3所示，在一个实施例中，本步骤S102可通过以下包括步骤S301-S305的流程实现。
在步骤S301中，判断设备的资源占用比例是否低于等于预设值，若是则转步骤S302，否则，设备的资源占用比例高于预设值时，转步骤S303。
在步骤S302中，响应于多个APP中任意APP退到后台均对该APP进行应用保活。
预设值根据设备资源占用的正常情况(例如，设备***无卡顿)进行设置，设备的资源占用比例低于等于该预设值时，表示资源占用没有偏离正常情况，无需触发优化配置，任意在后台运行的APP均可以进行保活处理，从而分配相应的***资源。
在步骤S303中，判断设备的资源占用比例是否低于等于预警值，若是则转步骤S304，否则，设备的资源占用比例高于预警值时，转步骤S305。
在步骤S304中，响应于多个APP中优先级高于等于预设级别的APP退到后台而对该APP进行应用保活，响应于多个APP中优先级低于预设级别的APP退到后台而对该APP进行应用终止。
预警值根据设备资源占用的边界情况进行设置，设备的资源占用比例高于预设值但低于等于预警值时，表示资源占用濒临偏离正常情况，从而需要进行优化配置，仅对优先级较高的部分APP分配***资源。例如，对于APP 1＞APP 2＞APP 3的排序结果，假设预设级别为1，则仅在APP 1退到后台运行时才进行保活处理，而当APP 2或APP  3退到后台运行时都进行终止处理，从而将设备的资源占用维持在正常状态。
在步骤S305中，对于多个APP中处于后台的APP，按照优先级从低到高的顺序进行应用终止，直至设备的资源占用比例低于等于预设值。
设备的资源占用比例高于预警值，表示设备的资源占用已偏离正常情况，从而需要终止部分后台应用，回收相应的***资源。例如，对于APP 1＞APP 2＞APP 3的排序结果，在步骤S305中按照APP 3、APP 2、APP 1的顺序终止后台运行的APP，直至设备的资源占用比例低于等于预设值。
在一个实施例中，本步骤S102所提及的资源占用比例可以包括CPU的占用百分比和内存的实际使用比例，相应的预设值和预警值也针对CPU和内存分别进行设置。
另外，对于步骤S305的终止条件“设备的资源占用比例低于等于预设值”，在资源占用比例为内存使用比例时，为便于快速计算，设备的资源占用比例可以利用执行步骤之前的资源占用比例减去初始化配置中相应APP的虚拟内存值来确定。
根据上述实施例的设备资源管理方法，可以基于应用的设备类型适配不同的初始化配置，并且根据用户行为导致的应用数据变化进行优先级的动态调整，从而实现基于应用场景的***性能优化，提升了用户体验。
在一个实施例中，本公开的设备资源管理方法可应用于有专门业务需求的智能终端(例如智能POS机)。实际上，***性能优化方案一般都是基于To C(To Customer，针对消费者)的场景，而对于具有专门业务需求的To B(To Business，针对商户)场景，相关技术并没有特别适用的重构方案。一般来说，To B和To C场景有以下几点区别。
第一，To C不区分细化使用场景，也不区分业务，需要保证消费级别用户使用任何应用都有流畅的体验；而To B场景有很强的业务属性，需要保证在业务应用的流畅体验下，尽可能让其他应用也有流畅的体验。
第二，To C场景无法预期，终端设备可能会有几百个应用，用户没有非常明确的使用规律；To B场景很垂直，业务使用有周期性，用户行为可预期。
第三，To C场景对电量敏感，需要控制功耗，To B场景可以随时充电，对电量消耗不敏感。
基于以上区别，以下实施例的设备资源管理方法对To B场景进行方案重构。图4为该实施例的设备资源管理方法的流程图，如图4所示，本实施例的方法包括以下步骤 S401-S403。在一个实施例中，该方法可由安装有至少一个业务APP和多个非业务APP的设备来执行。以智能POS机为例，业务APP例如是专用于实现结算收银的APP，而非业务APP例如包括用于实现排队、外卖接单等功能的各种APP。
在步骤S401中，获取并应用针对多个非业务APP的初始化配置。
当设备新投入使用时，可从本地或从服务器获取针对设备上已安装的多个APP的初始化配置。在一个实施例中，本步骤包括根据设备对应的标签，在按照标签建立的使用习惯数据库中，确定匹配度最高的初始化配置。例如，匹配的具体标签可以包括：商户的行业分类(例如餐饮、酒店、电影等)、商户的门店规模(大中小三个规模可选)、商户的业务性质(快餐、烧烤、正餐等)和商户的运营方式(单店、连锁店)等等。
以从服务器获取初始化配置为例，当商户在第三方提供的智能POS机上第一次登陆时，第三方服务器可获取商户新绑定的标签内容，从而在使用习惯数据库中匹配出最适合的非业务APP初始化配置。初始化配置的内容可参见图1实施例的描述，此处不再赘述。
在步骤S402中，基于多个非业务APP的历史使用，按照时间窗对多个非业务APP进行优先级排序。
本步骤的实施可参见图1实施例步骤S101的描述，此处不再重复。
在步骤S403中，根据设备的资源占用比例和所有APP各自的当前状态，在当前时间窗中基于相应的优先级排序的结果对所有APP进行后台应用控制。
为了实现设备资源的优化配置，本实施例可对所有APP的后台应用进行控制，包括：针对至少一个业务APP和多个非业务APP，结合前述步骤的优先级排序结果、当前设备资源使用情况以及预设阈值来选择性的保活或终止应用。
与图1实施例步骤S102不同的是，由于此处适用的To B场景，本步骤S403中同时要考虑业务APP的状态。如图5所示，在一个实施例中，本步骤S403可通过以下包括步骤S501-S505的流程实现。
在步骤S501中，判断设备的资源占用比例是否低于等于预设值，若是则转步骤S502，否则，设备的资源占用比例高于预设值时，转步骤S503。
在步骤S502中，响应于所有APP中任意APP退到后台均对该APP进行应用保活。
预设值根据设备资源占用的正常情况(例如，设备***无卡顿)进行设置，设备的 资源占用比例低于等于预设值时，表示资源占用没有偏离正常情况，无需触发优化配置，任意在后台运行的APP均可以进行保活处理，从而分配相应的***资源。
在步骤S503中，判断设备的资源占用比例是否低于等于预警值，若是则转步骤S504，否则，设备的资源占用比例高于预警值时，转步骤S505。
在步骤S504中，响应于任意业务APP退到后台均对该业务APP进行应用保活，响应于多个非业务APP中优先级高于等于预设级别的APP退到后台而对该非业务APP进行应用保活，响应于多个非业务APP中优先级低于预设级别的APP退到后台而对该非业务APP进行应用终止。
预警值根据设备资源占用的边界情况进行设置，设备的资源占用比例高于预设值但低于等于预警值时，表示资源占用濒临偏离正常情况，从而需要进行优化配置，仅对业务APP以及优先级较高的部分非业务APP分配***资源。例如，对于非业务APP的排序结果APP 1＞APP 2＞APP 3，假设预设级别为1，则仅在APP 1退到后台运行时才进行保活处理，而当APP 2或APP 3退到后台运行时都进行终止处理，从而在保证为业务APP分配足够资源的条件下将设备的资源占用维持在正常状态。
在步骤S505中，对于多个非业务APP中处于后台的非业务APP，按照优先级从低到高的顺序进行应用终止，直至设备的资源占用比例低于等于预设值。
设备的资源占用比例高于预警值，表示设备的资源占用已偏离正常情况，从而需要终止部分后台应用，回收相应的***资源。例如，对于APP 1＞APP 2＞APP 3的排序结果，在步骤S505中按照APP 3、APP 2、APP 1的顺序终止后台运行的APP，直至设备的资源占用比例低于等于预设值。
图5实施例的其他内容可参见图3实施例的描述，此处不再重复。
根据上述实施例的设备资源管理方法，针对To B场景进行了重构，可以基于设备应用的场景类型适配不同的初始化配置，并且根据用户行为导致的应用数据变化进行非业务应用优先级的动态调整，从而在保证为业务应用分配足够资源的条件下将设备的资源占用始终维持在正常状态，实现基于应用场景的***性能优化，提升了用户体验。
需要说明的是，尽管在附图中以特定顺序描述了本公开中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。另外，也易于理解的是，这些 步骤可以是例如在多个模块/进程/线程中同步或异步执行。
本示例实施方式中进一步提供了一种设备资源管理装置。
图6为根据本公开一实施例的设备资源管理装置示意框图。如图所示，本实施例的设备资源管理装置包括优先级模块61和应用控制模块62。
在一个实施例中，优先级模块61设置为基于多个APP的历史使用情况，按照一个或多个时间窗对上述多个APP进行优先级排序，得到所述多个APP在每个所述时间窗内的优先级排序结果；应用控制模块62设置为根据设备的资源占用比例和多个APP各自的当前状态以及所述多个APP在当前时间窗内的优先级排序结果，对上述多个APP进行后台应用控制。
在一个实施例中，优先级模块61设置为分别确定所述多个APP在单个时间窗内处于前台的使用时间和切换到前台的切换次数，并根据各APP的所述使用时间和切换次数，按照预设排序策略的任意一者进行所述优先级排序。
在一个实施例中，上述预设排序策略包括：使用时间越长，对应APP的优先级越高；在两个或多个APP的使用时间相同时，所述切换次数越高，对应APP的优先级越高。在另一个实施例中，上述预设排序策略还包括：在两个或多个APP的使用时间和切换次数均相同时，切换到前台的时间越早，对应APP的优先级越高。
在一个实施例中，优先级模块61还设置为按照预设周期更新对所述多个APP的优先级排序。
在一个实施例中，应用控制模块62的后台应用控制包括以下至少一种：在所述设备的资源占用比例低于等于预设值时，响应于所述多个APP中任意APP退到后台、对该APP进行应用保活；在所述设备的资源占用比例高于预设值但低于等于预警值时，响应于所述多个APP中优先级高于等于预设级别的APP退到后台、对该APP进行应用保活，响应于所述多个APP中优先级低于预设级别的APP退到后台、对该APP进行应用终止；以及在所述设备的资源占用比例高于预警值时，对于所述多个APP中处于后台的APP，按照优先级从低到高的顺序进行应用终止，直至所述设备的资源占用比例低于等于预设值。
在一个实施例中，设备资源管理装置还包括初始化模块(图中未示出)，设置为根据设备对应的标签，从按照标签建立的使用习惯数据库中，获取匹配度最高的初始化配置，并对所述多个APP应用获取的所述初始化配置。在一个实施例中，所述初始化配 置包括上述多个APP中至少部分APP的优先级排序结果。
在一个实施例中，上述多个APP为非业务APP，所述设备还安装有至少一个业务APP。
关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。
应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。作为模块或单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本公开方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
通过以上实施方式的描述，本领域的技术人员易于理解，上文描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。
例如，在一个示例实施方式中，还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时可以实现上述任意一个实施例中所述方法的步骤。所述方法的具体步骤可参考前述实施例中的详细描述，此处不再赘述。所述计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。
在另一个示例实施方式中，还提供一种智能终端，该智能终端可以是手机、平板电脑等移动终端，也可以是台式计算机、服务器等终端设备，本示例实施方式中对此不作限制。图7示出根据本公开示例实施方式中一种智能终端70的示意图。例如，智能终端70可以被提供为一移动终端。参照图7，智能终端70包括处理组件71，其进一步包括一个或多个处理器，以及由存储介质72所代表的存储资源，用于存储可由处理组件71的执行的指令，例如应用程序。存储介质72中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外，处理组件71被配置为执行指令，以执行上述设备资源管理方法。该方法的步骤可参考前述方法实施例中的详细描述，此处不再赘述。
智能终端70还可以包括一个电源组件73被配置为执行智能终端70的电源管理，一 个有线或无线网络接口74被配置为将智能终端70连接到网络，和一个输入输出(I/O)接口75。智能终端70可以基于存储在存储介质72的操作***进行操作，例如Android、IOS或类似。
本领域技术人员在考虑说明书及实践本公开后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由所附的权利要求指出。
虽然已参照几个典型实施例描述了本公开，但应当理解，所用的术语是说明和示例性、而非限制性的术语。由于本公开能够以多种形式具体实施而不脱离申请的精神或实质，所以应当理解，上述实施例不限于任何前述的细节，而应在随附权利要求所限定的精神和范围内广泛地解释，因此落入权利要求或其等效范围内的全部变化和改型都应为随附权利要求所涵盖。

Claims (11)

  1. 一种设备资源管理方法，应用于安装有多个应用程序APP的设备中，所述方法包括：
    基于所述多个APP的历史使用情况，按照一个或多个时间窗对所述多个APP进行优先级排序，得到所述多个APP在每个所述时间窗内的优先级排序结果；以及
    根据所述设备的资源占用比例和所述多个APP各自的当前状态以及所述多个APP在当前时间窗内的所述优先级排序结果，对所述多个APP进行后台应用控制。
  2. 如权利要求1所述的方法，其中，按照所述时间窗对所述多个APP进行优先级排序包括：
    统计所述多个APP在所述时间窗内处于前台的使用时间和切换到前台的切换次数；以及
    根据所述统计的使用时间和切换次数，按照预设的排序策略确定所述多个APP在所述时间窗内的优先级排序结果。
  3. 根据权利要求2所述的方法，其特征在于，所述排序策略包括以下任意一个或多个：
    在所述时间窗内的使用时间越长，对应的所述APP在所述时间窗内的优先级越高；
    在两个或多个所述APP在所述时间窗内的使用时间相同时，所述切换次数越高，对应的所述APP在所述时间窗内的优先级越高；
    在两个或多个所述APP在所述时间窗内的使用时间和切换次数均相同时，切换到前台的时间越早，对应的所述APP在所述时间窗内的优先级越高。
  4. 如权利要求1所述的方法，其中，所述方法还包括：
    按照预设周期更新所述多个APP在每个所述时间窗内的优先级排序结果。
  5. 如权利要求1所述的方法，其中，对所述多个APP进行后台应用控制包括以下步骤的至少一个：
    在所述设备的资源占用比例低于等于预设值时，响应于所述多个APP中任意APP退到后台均对该APP进行应用保活；
    在所述设备的资源占用比例高于所述预设值、但低于等于预警值时，
    响应于所述多个APP中优先级高于等于预设级别的APP退到后台而对该APP进行应用保活，
    响应于所述多个APP中优先级低于所述预设级别的APP退到后台而对该APP进行应用终止；以及
    在所述设备的资源占用比例高于所述预警值时，对于所述多个APP中处于后台的APP，按照优先级从低到高的顺序进行应用终止，直至所述设备的资源占用比例低于等于所述预设值。
  6. 如权利要求1所述的方法，其中，在按照所述时间窗对所述多个APP进行优先级排序之前，所述方法还包括：
    根据所述设备对应的标签，从按照标签建立的使用习惯数据库中，获取匹配度最高的初始化配置；
    其中，所述初始化配置包括所述多个APP中至少部分APP的优先级排序结果。
  7. 如权利要求1至6任一项所述的方法，其中，所述多个APP为非业务APP，所述设备还安装有至少一个业务APP。
  8. 如权利要求7所述的方法，其中，对所述多个APP进行后台应用控制包括以下步骤的至少一个：
    在所述设备的资源占用比例低于等于预设值时，响应于所有APP中任意APP退到后台均对该APP进行应用保活；
    在所述设备的资源占用比例高于所述预设值、但低于等于预警值时，
    响应于任意所述业务APP退到后台而对该APP进行应用保活，
    响应于所述多个非业务APP中优先级高于等于预设级别的非业务APP退到后台而对该非业务APP进行应用保活，
    响应于所述多个非业务APP中优先级低于所述预设级别的非业务APP退到后台而对该非业务APP进行应用终止；以及
    在所述设备的资源占用比例高于所述预警值时，对于所述多个非业务APP中处于后台的非业务APP，按照优先级从低到高的顺序进行应用终止，直至所述设备的资源占用比例低于等于所述预设值。
  9. 一种设备资源管理装置，应用于安装有多个应用程序APP的设备中，所述装置包括：
    优先级模块，设置为基于所述多个APP的历史使用情况，按照一个或多个时间窗对所述多个APP进行优先级排序，得到所述多个APP在每个所述时间窗内的优先级排序结果；以及
    应用控制模块，设置为根据所述设备的资源占用比例和所述多个APP各自的当前状态以及所述多个APP在当前时间窗内的所述优先级排序结果，对所述多个APP进行后台应用控制。
  10. 一种存储有计算机程序的存储介质，所述计算机程序在由安装有多个应用程序APP的设备的处理器运行时，使所述设备执行如权利要求1-8中任一项所述的方法。
  11. 一种智能终端，包括：
    处理器；
    存储介质，存储有可由所述处理器执行的指令；
    其中所述处理器被配置为执行如权利要求1-8中任一项所述的方法。
PCT/CN2018/110850 2017-12-22 2018-10-18 设备资源管理 WO2019119951A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201711405724.4A CN109960572B (zh) 2017-12-22 2017-12-22 设备资源管理方法和装置以及智能终端
CN201711405724.4 2017-12-22

Publications (1)

Publication Number Publication Date
WO2019119951A1 true WO2019119951A1 (zh) 2019-06-27

Family

ID=66994384

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/110850 WO2019119951A1 (zh) 2017-12-22 2018-10-18 设备资源管理

Country Status (2)

Country Link
CN (1) CN109960572B (zh)
WO (1) WO2019119951A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110443598B (zh) * 2019-08-08 2023-03-28 上海中通吉网络技术有限公司 账户结算方法和装置
CN110554922A (zh) * 2019-09-05 2019-12-10 北京安云世纪科技有限公司 一种***资源分配方法及装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120102497A1 (en) * 2010-10-21 2012-04-26 Stahl Nathaniel R Mobile Computing Device Activity Manager
CN103324536A (zh) * 2012-03-23 2013-09-25 宇龙计算机通信科技(深圳)有限公司 终端和应用程序保护方法
CN103631661A (zh) * 2013-11-27 2014-03-12 青岛海信电器股份有限公司 一种内存管理方法和装置

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101114941A (zh) * 2007-06-28 2008-01-30 中兴通讯股份有限公司 主从设备中从设备获得配置数据的方法
KR102148948B1 (ko) * 2013-12-06 2020-08-27 삼성전자주식회사 전자 장치의 멀티 태스킹 방법 및 그 전자 장치
CN103902335A (zh) * 2014-03-12 2014-07-02 上海天奕达电子科技有限公司 一种后台程序清理的方法及其***

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120102497A1 (en) * 2010-10-21 2012-04-26 Stahl Nathaniel R Mobile Computing Device Activity Manager
CN103324536A (zh) * 2012-03-23 2013-09-25 宇龙计算机通信科技(深圳)有限公司 终端和应用程序保护方法
CN103631661A (zh) * 2013-11-27 2014-03-12 青岛海信电器股份有限公司 一种内存管理方法和装置

Also Published As

Publication number Publication date
CN109960572B (zh) 2020-06-02
CN109960572A (zh) 2019-07-02

Similar Documents

Publication Publication Date Title
US11487562B2 (en) Rolling resource credits for scheduling of virtual computer resources
US11842208B2 (en) Virtual provisioning with implementation resource boundary awareness
EP3401787B1 (en) Analyzing resource utilization of a cloud computing resource in a cloud computing environment
US9921866B2 (en) CPU overprovisioning and cloud compute workload scheduling mechanism
US9606785B2 (en) Detecting deployment conflicts in heterogeneous environments
US20210297364A1 (en) Systems and methods for provision of a guaranteed batch
US8756322B1 (en) Fulfillment of requests for computing capacity
US8424007B1 (en) Prioritizing tasks from virtual machines
US10013662B2 (en) Virtual resource cost tracking with dedicated implementation resources
US10506024B2 (en) System and method for equitable processing of asynchronous messages in a multi-tenant platform
US8856483B1 (en) Virtual data storage service with sparse provisioning
US20180181911A1 (en) Data object allocation method and apparatus and electronic device
US20210157644A1 (en) Selecting an optimal combination of cloud resources within budget constraints
US10009213B2 (en) System and method for isolation of multi-tenant platform customization using child processes
US20130179880A1 (en) Data and state threading for virtualized partition management
US10986191B2 (en) Method and device for scheduling resources
US11422858B2 (en) Linked workload-processor-resource-schedule/processing-system—operating-parameter workload performance system
US20160321108A1 (en) Intelligent management of processing tasks on multi-tenant or other constrained data processing platform
US20210103468A1 (en) Performance biased scheduler extender
CN110609738A (zh) 自适应数据同步
WO2019119951A1 (zh) 设备资源管理
US20190171489A1 (en) Method of managing dedicated processing resources, server system and computer program product
US9405578B2 (en) Intelligent application back stack management
US11074531B2 (en) Machine learning techniques for automated processing of workflow approval requests
WO2021046777A1 (zh) 资源调度、申请与定价方法、设备、***及存储介质

Legal Events

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

Ref document number: 18893116

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18893116

Country of ref document: EP

Kind code of ref document: A1