发明内容
有鉴于此,本发明实施例希望提供一种应用自启动的控制方法、终端及服务器,使用户即使不知道该怎么选择禁止或者允许哪些应用自启动,也能实现应用自启动的控制,且无需用户手工选择。
本发明实施例的技术方案是这样实现的:
本发明实施例提供一种应用自启动的控制方法,所述方法包括:
上报内置应用的标识信息;所述标识信息用于对内置应用进行标识,使服务器能根据所述标识信息识别出所述内置应用;
接收为所述内置应用配置的自启动属性;
按照所述自启动属性控制内置应用的自启动。
优选的,所述上报内置应用的标识信息包括:周期性上报的方式、或符合预设上报配置条件时上报的方式。
优选的,若采取所述周期性上报的方式,则所述上报内置应用的标识信息之前还包括:
扫描内置应用,获取全部的内置应用;
相应的,所述上报内置应用的标识信息为:上报所述全部的内置应用的标识信息。
优选的,若采取所述符合预设上报配置条件时上报的方式,则所述上报内置应用的标识信息之前还包括:
检测终端运行状态;
所述终端运行状态为第一状态时,获取与所述第一状态对应的预设上报配置条件;
触发符合所述预设上报配置条件的内置应用扫描,获取全部的内置应用;
相应的,所述上报内置应用的标识信息为:上报所述全部的内置应用的标识信息。
优选的,所述按照所述自启动属性控制内置应用的自启动,包括:
所述自启动属性配置为允许自启动时,控制所述内置应用在开机时允许自启动运行或者允许在后台自启动运行;
所述自启动属性配置为禁止自启动,控制所述内置应用在开机时禁止自启动运行或者禁止在后台自启动运行。
优选的,若采取所述符合预设上报配置条件时上报的方式,则所述上报内置应用的标识信息之前还包括:
检测终端运行状态;
所述终端运行状态为第二状态时,获取与所述第二状态对应的预设上报配置条件;
触发符合所述预设上报配置条件的内置应用扫描,获取部分的内置应用,所述部分的内置应用自身设置有第一自启动属性;
相应的,所述上报内置应用的标识信息为:上报所述部分的内置应用的标识信息,且携带有所述第一自启动属性。
优选的,所述按照所述自启动属性控制应用的自启动,包括:
扫描内置应用,检测到内置应用自身设置有所述第一自启动属性时,将接收到的所述自启动属性作为第二自启动属性并不予处理,按照所述第一自启动属性处理;
本地获取所述第一自启动属性;
所述第一自启动属性配置为允许自启动时,控制所述内置应用在开机时允许自启动运行或者允许在后台自启动运行;
所述第一自启动属性配置为禁止自启动时,控制所述内置应用在开机时禁止自启动运行或者禁止在后台自启动运行。
优选的,所述按照所述自启动属性控制应用的自启动,包括:
扫描内置应用,检测到内置应用自身未设置有所述第一自启动属性时,将接收到的所述自启动属性作为第二自启动属性,并按照所述第二自启动属性处理;
获取所述第二自启动属性;
所述第二自启动属性配置为允许自启动时,控制所述内置应用在开机时允许自启动运行或者允许在后台自启动运行;
所述第二自启动属性配置为禁止自启动时,控制所述内置应用在开机时禁止自启动运行或者禁止在后台自启动运行。
本发明实施例还提供一种应用自启动的控制方法,所述方法包括:
接收内置应用的标识信息;
根据所述标识信息识别出所述内置应用;
根据配置策略对所述内置应用进行自启动分析,得到自启动属性;
为所述内置应用配置自启动属性;
发送为所述内置应用配置的自启动属性。
优选的,所述根据配置策略对所述内置应用进行自启动分析,得到自启动属性,包括以下任意一种方式:
方式一:获取所有终端使用所述内置应用的历史记录,从所述历史记录中得到所述内置应用的使用频率,若所述使用频率达到阈值,则得到所述自启动属性为允许自启动,否则,得到所述自启动属性为禁止自启动;
方式二:获取所有终端使用所述内置应用的历史记录,从所述历史记录中得到所述内置应用的允许自启动次数与禁止自启动次数,若所述允许自启动次数大于所述禁止自启动次数,则得到所述自启动属性为允许自启动,否则,得到所述自启动属性为禁止自启动;
方式三:获取当前上报的终端使用所述内置应用的使用频率,若所述使用频率达到阈值,则得到所述自启动属性为允许自启动,否则,得到所述自启动属性为禁止自启动;
方式四:获取当前上报的终端使用所述内置应用的允许自启动次数,若所述允许自启动次数达到阈值,则得到所述自启动属性为允许自启动,否则,得到所述自启动属性为禁止自启动;
方式五:获取当前上报的终端使用所述内置应用的禁止自启动次数,若所述禁止自启动次数达到阈值,则得到所述自启动属性为禁止自启动,否则,得到所述自启动属性为允许自启动。
本发明实施例还提供一种终端,所述终端包括:
上报单元,用于上报内置应用的标识信息;所述标识信息用于对内置应用进行标识,使服务器能根据所述标识信息识别出所述内置应用;
接收单元,用于接收为所述内置应用配置的自启动属性;
第二控制单元,用于按照所述自启动属性控制内置应用的自启动。
优选的,所述上报内置应用的标识信息包括:周期性上报的方式、或符合预设上报配置条件时上报的方式。
优选的,所述终端包括:
方式确定单元,用于确定采取所述周期性上报的方式;
扫描单元,用于扫描内置应用,获取全部的内置应用;
相应的,所述上报单元,进一步用于上报所述全部的内置应用的标识信息。
优选的,所述终端包括:
方式确定单元,用于确定采取所述符合预设上报配置条件时上报的方式;
检测单元,用于检测终端运行状态;
条件获取单元,用于所述终端运行状态为第一状态时,获取与所述第一状态对应的预设上报配置条件;
扫描单元,用于触发符合所述预设上报配置条件的内置应用扫描,获取全部的内置应用;
相应的,所述上报单元,进一步用于上报所述全部的内置应用的标识信息。
优选的,所述第二控制单元,进一步包括:
第一控制子单元,用于所述自启动属性配置为允许自启动时,控制所述内置应用在开机时允许自启动运行或者允许在后台自启动运行;
第二控制子单元,用于所述自启动属性配置为禁止自启动,控制所述内置应用在开机时禁止自启动运行或者禁止在后台自启动运行。
优选的,所述终端包括:
方式确定单元,用于确定采取所述符合预设上报配置条件时上报的方式;
检测单元,用于检测终端运行状态;
条件获取单元,用于所述终端运行状态为第二状态时,获取与所述第二状态对应的预设上报配置条件;
扫描单元,用于触发符合所述预设上报配置条件的内置应用扫描,获取部分的内置应用,所述部分的内置应用自身设置有第一自启动属性;
相应的,所述上报单元,进一步用于上报所述部分的内置应用的标识信息,且携带有所述第一自启动属性。
优选的,所述第二控制单元,进一步包括:
扫描检测子单元,用于扫描内置应用,检测到内置应用自身设置有所述第一自启动属性时,将接收到的所述自启动属性作为第二自启动属性并不予处理,按照所述第一自启动属性处理;
属性获取子单元,用于本地获取所述第一自启动属性;
第一控制子单元,用于所述第一自启动属性配置为允许自启动时,控制所述内置应用在开机时允许自启动运行或者允许在后台自启动运行;
第二控制子单元,用于所述第一自启动属性配置为禁止自启动时,控制所述内置应用在开机时禁止自启动运行或者禁止在后台自启动运行。
优选的,所述第二控制单元,进一步包括:
扫描检测子单元,用于扫描内置应用,检测到内置应用自身未设置有所述第一自启动属性时,将接收到的所述自启动属性作为第二自启动属性,并按照所述第二自启动属性处理;
属性获取子单元,用于获取所述第二自启动属性;
第一控制子单元,用于所述第二自启动属性配置为允许自启动时,控制所述内置应用在开机时允许自启动运行或者允许在后台自启动运行;
第二控制子单元,用于所述第二自启动属性配置为禁止自启动时,控制所述内置应用在开机时禁止自启动运行或者禁止在后台自启动运行。
本发明实施例还提供一种服务器,所述服务器包括:
信息接收单元,用于接收内置应用的标识信息;
信息识别单元,用于根据所述标识信息识别出所述内置应用;
分析确定单元,用于根据配置策略对所述内置应用进行自启动分析,得到自启动属性;
配置单元,用于为所述内置应用配置自启动属性;
发送单元,用于发送为所述内置应用配置的自启动属性。
优选的,所述分析确定单元,进一步用于采取包括以下任意一种方式进行分析:
方式一:获取所有终端使用所述内置应用的历史记录,从所述历史记录中得到所述内置应用的使用频率,若所述使用频率达到阈值,则得到所述自启动属性为允许自启动,否则,得到所述自启动属性为禁止自启动;
方式二:获取所有终端使用所述内置应用的历史记录,从所述历史记录中得到所述内置应用的允许自启动次数与禁止自启动次数,若所述允许自启动次数大于所述禁止自启动次数,则得到所述自启动属性为允许自启动,否则,得到所述自启动属性为禁止自启动;
方式三:获取当前上报的终端使用所述内置应用的使用频率,若所述使用频率达到阈值,则得到所述自启动属性为允许自启动,否则,得到所述自启动属性为禁止自启动;
方式四:获取当前上报的终端使用所述内置应用的允许自启动次数,若所述允许自启动次数达到阈值,则得到所述自启动属性为允许自启动,否则,得到所述自启动属性为禁止自启动;
方式五:获取当前上报的终端使用所述内置应用的禁止自启动次数,若所述禁止自启动次数达到阈值,则得到所述自启动属性为禁止自启动,否则,得到所述自启动属性为允许自启动。
采用本发明实施例的方法,上报内置应用的标识信息;所述标识信息用于对内置应用进行标识,使服务器能根据所述标识信息识别出所述内置应用;接收为所述内置应用配置的自启动属性;按照所述自启动属性控制内置应用的自启动,从而能按照所述自启动属性控制内置应用的自启动,实现了一种自动化控制的应用自启动控制方案,无需用户手工选择,用户也不用担心即使不知道该怎么选择禁止或者允许哪些应用自启动,也能实现应用自启动的控制。
具体实施方式
下面结合附图对技术方案的实施作进一步的详细描述。
方法实施例一:
本发明实施例的一种应用自启动的控制方法,如图1所示,所述方法包括:
步骤101、获取符合预设条件的至少一个应用;
步骤102、将所述至少一个应用添加入配置信息列表中;
步骤103、扫描内置应用;
步骤104、判断扫描到的所述内置应用是否归属于所述配置信息列表,得到判断结果;
步骤105、根据所述判断结果配置所述内置应用的自启动属性,按照所述自启动属性控制内置应用的自启动。
采用本发明实施例的方法,通过步骤101可以先获取符合预设条件的至少一个应用,由于设置有配置信息列表,因此,通过步骤102可以将所述至少一个应用添加入配置信息列表中,则所述配置信息列表中包含符合预设条件的至少一个应用。在此基础上,通过步骤103-105能扫描内置应用,根据判断扫描到的所述内置应用是否归属于所述配置信息列表所得到的判断结果,来配置所述内置应用的自启动属性,从而能按照所述自启动属性控制内置应用的自启动。实现了一种自动化控制的应用自启动控制方案,无需用户手工选择,用户也不用担心即使不知道该怎么选择禁止或者允许哪些应用自启动,也能实现应用自启动的控制。
在本发明实施例一优选实施方式中,所述符合预设条件的至少一个应用包括:在同类应用比较中符合所述预设条件的应用、或者,在不同类应用比较中符合所述预设条件的应用。比如,MSN、微博、微信等都属于社交类应用,也就是说MSN、微博、微信等属于同类应用,获取同类应用中下载量排名位于TOP5之前的应用,下载量排名位于TOP5之前的应用即为符合预设条件的至少一个应用。当然,也可以不区分是否为同类应用,而是针对各类应用的所有排名,得到下载量排名位于TOP5之前的应用,下载量排名位于TOP5之前的应用也为符合预设条件的至少一个应用。
方法实施例二:
本发明实施例的一种应用自启动的控制方法,如图2所示,所述方法包括:
步骤201、获取符合预设条件的至少一个应用;
步骤202、将所述至少一个应用添加入配置信息列表中;
步骤203、扫描内置应用;
步骤204、判断扫描到的所述内置应用是否归属于所述配置信息列表,得到判断结果;
步骤205、当所述判断结果表明所述内置应用归属于所述配置信息列表时,将所述内置应用的自启动属性配置为允许自启动,控制所述内置应用在开机时允许自启动运行或者允许在后台自启动运行。
采用本发明实施例的方法,通过步骤201可以先获取符合预设条件的至少一个应用,由于设置有配置信息列表,因此,通过步骤202可以将所述至少一个应用添加入配置信息列表中,则所述配置信息列表中包含符合预设条件的至少一个应用。在此基础上,通过步骤203-205能扫描内置应用,根据判断扫描到的所述内置应用是否归属于所述配置信息列表所得到的判断结果,来配置所述内置应用的自启动属性,当所述判断结果表明所述内置应用归属于所述配置信息列表时,将所述内置应用的自启动属性配置为允许自启动,控制所述内置应用在开机时允许自启动运行或者允许在后台自启动运行,实现了一种自动化控制的应用自启动控制方案,无需用户手工选择,用户也不用担心即使不知道该怎么选择禁止或者允许哪些应用自启动,也能实现应用自启动的控制。
方法实施例三:
本发明实施例的一种应用自启动的控制方法,如图3所示,所述方法包括:
步骤301、获取符合预设条件的至少一个应用;
步骤302、将所述至少一个应用添加入配置信息列表中;
步骤303、扫描内置应用;
步骤304、判断扫描到的所述内置应用是否归属于所述配置信息列表,得到判断结果;
步骤305、当所述判断结果表明所述内置应用不归属于所述配置信息列表时,将所述内置应用的自启动属性配置为禁止自启动,控制所述内置应用在开机时禁止自启动运行或者禁止在后台自启动运行。
采用本发明实施例的方法,通过步骤301可以先获取符合预设条件的至少一个应用,由于设置有配置信息列表,因此,通过步骤302可以将所述至少一个应用添加入配置信息列表中,则所述配置信息列表中包含符合预设条件的至少一个应用。在此基础上,通过步骤303-305能扫描内置应用,根据判断扫描到的所述内置应用是否归属于所述配置信息列表所得到的判断结果,来配置所述内置应用的自启动属性,当所述判断结果表明所述内置应用不归属于所述配置信息列表时,将所述内置应用的自启动属性配置为禁止自启动,控制所述内置应用在开机时禁止自启动运行或者禁止在后台自启动运行,实现了一种自动化控制的应用自启动控制方案,无需用户手工选择,用户也不用担心即使不知道该怎么选择禁止或者允许哪些应用自启动,也能实现应用自启动的控制。
上述方法实施例一至方法实施例三,是利用终端与第三方服务器的交互,获取符合预设条件的至少一个应用,比如某应用市场应用下载量排名,用户关注度排名等的至少一个应用,根据这些获取的至少一个应用形成配置信息列表,使得归属于配置信息列表中的应用为允许开机时或后台自启动,非配置信息列表中的应用为禁止开机时或后台自启动。
方法实施例四:
本发明实施例的一种应用自启动的控制方法,如图4所示,所述方法包括:
步骤401、上报内置应用的标识信息;所述标识信息用于对内置应用进行标识,使服务器能根据所述标识信息识别出所述内置应用;
步骤402、接收为所述内置应用配置的自启动属性;
步骤403、按照所述自启动属性控制内置应用的自启动。
采用本发明实施例,通过步骤401终端能上报可以使服务器识别出该内置应用的标识信息,标识信息可以包括:应用的包名或应用的名字,比如,将MSN这一应用的名字上报给服务器;通过步骤402终端能接收到服务器为其配置的内置应用的自启动属性;通过步骤403能根据接收的自启动属性控制应用的自启动。
在本发明实施例一优选实施方式中,所述上报内置应用的标识信息包括:周期性上报的方式、或符合预设上报配置条件时上报的方式。
方法实施例五:
本发明实施例的一种应用自启动的控制方法,如图5所示,所述方法包括:
步骤501、采取所述周期性上报的方式,扫描内置应用,获取全部的内置应用;
步骤502、上报全部的内置应用的标识信息;所述标识信息用于对内置应用进行标识,使服务器能根据所述标识信息识别出所述内置应用;
步骤503、接收为所述内置应用配置的自启动属性;
步骤504、按照所述自启动属性控制内置应用的自启动。
采用本发明实施例,通过步骤501能根据不同的上报方式,比如本实施例的周期性上报的方式确定扫描策略,无需设置扫描条件,可以说是一种盲扫描方式,扫描内置应用来获取全部的内置应用;通过步骤502终端能上报可以使服务器识别出该内置应用的标识信息,标识信息可以包括:应用的包名或应用的名字,比如,将MSN这一应用的名字上报给服务器;通过步骤503终端能接收到服务器为其配置的内置应用的自启动属性;通过步骤504能根据接收的自启动属性控制应用的自启动。
在本发明实施例一优选实施方式中,与上述方法实施例五一样,也是全部上报的场景,但是有所区别的是,本优选实施方式为采取符合预设上报配置条件时上报的方式,需要配合检测终端运行状态来实现。
如图6所示,所述上报内置应用的标识信息之前还包括:
步骤S11、检测终端运行状态;
步骤S12、所述终端运行状态为第一状态时,获取与所述第一状态对应的预设上报配置条件;
步骤S13、触发符合所述预设上报配置条件的内置应用扫描,获取全部的内置应用。
相应的,所述上报内置应用的标识信息为:上报所述全部的内置应用的标识信息。
采用本优选实施方式,第一状态包括:终端处于闲的状态,此时,可以采取全部上报,且并不会影响到终端的运行速度等性能指标。
除了这个闲的状态,第一状态还可以包括:终端的耗电量状态为低电量状态、或者资源占用状态为低占用率状态。具体地,可以通过预设的阈值范围来界定是否落入低电量状态,或低占用率状态。与所述第一状态对应的状态为第二状态,与第一状态正好相反,在第二状态时为部分上报,否则会影响到终端的运行速度等性能指标。在后续优选实施方式中具体描述。
针对上述全部上报的场景,本优选实施方式为:对上述步骤504进一步细化描述,所述按照所述自启动属性控制内置应用的自启动,包括:
步骤50411、所述自启动属性配置为允许自启动时,控制所述内置应用在开机时允许自启动运行或者允许在后台自启动运行;
步骤50412、所述自启动属性配置为禁止自启动,控制所述内置应用在开机时禁止自启动运行或者禁止在后台自启动运行。
在本发明实施例另一优选实施方式中,是部分上报的场景,本优选实施方式为采取符合预设上报配置条件时上报的方式,需要配合检测终端运行状态来实现。
如图7所示,所述上报内置应用的标识信息之前还包括:
步骤S21、检测终端运行状态;
步骤S22、所述终端运行状态为第二状态时,获取与所述第二状态对应的预设上报配置条件;
步骤S23、触发符合所述预设上报配置条件的内置应用扫描,获取部分的内置应用,所述部分的内置应用自身设置有第一自启动属性。
相应的,所述上报内置应用的标识信息为:上报所述部分的内置应用的标识信息,且携带有所述第一自启动属性。
本优选实施方式,第二状态包括:终端处于忙的状态,此时,可以采取部分上报,且并不会影响到终端的运行速度等性能指标。
除了这个忙的状态,第二状态还可以包括:终端的耗电量状态为高电量状态、或者资源占用状态为高占用率状态。具体地,可以通过预设的阈值范围来界定是否落入高电量状态,或高占用率状态。
针对上述部分上报的场景,本优选实施方式为:对上述步骤504进一步细化描述,所述按照所述自启动属性控制内置应用的自启动,包括:
步骤50421、扫描内置应用,检测到内置应用自身设置有所述第一自启动属性时,将接收到的所述自启动属性作为第二自启动属性并不予处理,按照所述第一自启动属性处理;
步骤50422、本地获取所述第一自启动属性;
步骤50423、所述第一自启动属性配置为允许自启动时,控制所述内置应用在开机时允许自启动运行或者允许在后台自启动运行;
步骤50424、所述第一自启动属性配置为禁止自启动时,控制所述内置应用在开机时禁止自启动运行或者禁止在后台自启动运行。
本优选实施方式是遵循服务器为终端配置的自启动属性,实现自启动控制。
针对上述部分上报的场景,本优选实施方式为:对上述步骤504进一步细化描述,所述按照所述自启动属性控制内置应用的自启动,包括:
步骤50431、扫描内置应用,检测到内置应用自身未设置有所述第一自启动属性时,将接收到的所述自启动属性作为第二自启动属性,并按照所述第二自启动属性处理;
步骤50432、获取所述第二自启动属性;
步骤50433、所述第二自启动属性配置为允许自启动时,控制所述内置应用在开机时允许自启动运行或者允许在后台自启动运行;
步骤50433、所述第二自启动属性配置为禁止自启动时,控制所述内置应用在开机时禁止自启动运行或者禁止在后台自启动运行。
综上所述,针对部分上报场景而言,第一自启动属性为终端为内置应用自身配置的自启动属性,有可能不是最优的自启动属性,因此,可以一并上报给服务器,由服务器对该自启动属性进行判断是否合适;收到服务器返回的自启动属性,一种实现方式是,遵循服务器统计的结果,为了方便区分,将从服务器接收到的自启动属性确定为第二自启动属性,即:终端按照第二自启动属性控制本地内置应用的自启动控制;另一种实现方式是,虽然终端设置的第一自启动属性不是最优的,但是每个用户有不同的使用习惯,需要遵循用户的使用习惯,为此,优选地,采用用户DIY的第一启动属性来控制本地内置应用的自启动控制,除非用户DIY的第一自启动属性与所述第二自启动属性比对时发现很有问题,终端才会按照第二自启动属性控制本地内置应用的自启动控制。
上述方法实施例四至方法实施例五,是利用终端与后台服务器(类型为云端服务器)的交互,可以选择采用终端DIY自启动配置的情况。将终端为本地内置应用自身配置的第一自启动属性上报给服务器,由服务器统计后得到服务器为终端配置的第二自启动属性,终端收到第二自启动属性,优选遵循所述第一自启动属性来实现控制,或者,将第一自启动属性与第二自启动属性比较,选择较为优化的自启动属性,或者,也遵循所述第二自启动属性来实现控制。
方法实施例六:
本发明实施例的一种应用自启动的控制方法,如图8所示,所述方法包括:
步骤801、接收内置应用的标识信息;
步骤802、根据所述标识信息识别出所述内置应用;
步骤803、根据配置策略对所述内置应用进行自启动分析,得到自启动属性;
步骤804、为所述内置应用配置自启动属性;
步骤805、发送为所述内置应用配置的自启动属性。
在本发明实施例一优选实施方式中,所述根据配置策略对所述内置应用进行自启动分析,得到自启动属性,包括以下任意一种方式:
方式一:获取所有终端使用所述内置应用的历史记录,从所述历史记录中得到所述内置应用的使用频率,若所述使用频率达到阈值,则得到所述自启动属性为允许自启动,否则,得到所述自启动属性为禁止自启动;
方式二:获取所有终端使用所述内置应用的历史记录,从所述历史记录中得到所述内置应用的允许自启动次数与禁止自启动次数,若所述允许自启动次数大于所述禁止自启动次数,则得到所述自启动属性为允许自启动,否则,得到所述自启动属性为禁止自启动;
方式三:获取当前上报的终端使用所述内置应用的使用频率,若所述使用频率达到阈值,则得到所述自启动属性为允许自启动,否则,得到所述自启动属性为禁止自启动;
方式四:获取当前上报的终端使用所述内置应用的允许自启动次数,若所述允许自启动次数达到阈值,则得到所述自启动属性为允许自启动,否则,得到所述自启动属性为禁止自启动;
方式五:获取当前上报的终端使用所述内置应用的禁止自启动次数,若所述禁止自启动次数达到阈值,则得到所述自启动属性为禁止自启动,否则,得到所述自启动属性为允许自启动。
以下对终端与服务器交互的场景描述如下:
场景一:如图9所示,终端使用配置信息列表,采取默认配置,包括以下步骤:
步骤901、获取符合预设条件的至少一个应用;
步骤902、将所述至少一个应用添加入配置信息列表中;
步骤903、扫描内置应用;
步骤904、判断扫描到的所述内置应用是否归属于所述配置信息列表,得到判断结果,根据判断结果进行内置应用的自启动控制。
场景二:如图10所示,终端上报标识信息,由服务器进行统计,收到服务器返回的自启动属性,包括以下步骤:
步骤1001、上报内置应用的标识信息;
所述标识信息用于对内置应用进行标识,使服务器能根据所述标识信息识别出所述内置应用;
步骤1002、接收内置应用的标识信息,根据所述标识信息识别出所述内置应用;
步骤1003、根据配置策略对所述内置应用进行自启动分析,得到自启动属性;
步骤1004、发送为所述内置应用配置的自启动属性;
步骤1005、接收为所述内置应用配置的自启动属性,按照所述自启动属性控制内置应用的自启动。
场景三:如图11所示,终端上报第一自启动属性,由服务器进行统计,收到服务器返回的第二自启动属性,包括以下步骤:
步骤1101、上报内置应用的标识信息,携带第一自启动属性;
所述标识信息用于对内置应用进行标识,使服务器能根据所述标识信息识别出所述内置应用;
步骤1102、接收内置应用的标识信息,根据所述标识信息识别出所述内置应用,解析出第一自启动属性;
步骤1103、收集第一自启动属性,计算阈值,根据配置策略对所述内置应用进行自启动分析,得到第二自启动属性;
步骤1104、发送为所述内置应用配置的第二自启动属性;
步骤1105、接收为所述内置应用配置的第二自启动属性,按照控制策略选择采用第一自启动属性或第二自启动属性控制内置应用的自启动。
控制策略包括:若设置为遵循服务器的配置,即:按照第二自启动属性来控制内置应用的自启动;若设置为遵循终端的配置,即:按照第一自启动属性控制内置应用的自启动;若未设置遵循哪一个的配置,则比对第一自启动属性和第二自启动属性,选择其中较佳的配置。
这里需要指出的是,优选地,收到为所述内置应用配置的第二自启动属性后,采用第一自启动属性来控制内置应用的自启动,如图12所示,具体包括:
步骤1201、服务器下发第二自启动属性;
步骤1202、终端接收到第二自启动属性,对于内置应用,判断应用是否已经本地设置有第一自启动属性,如果是,则执行步骤1203;否则,执行步骤1204;
步骤1203、对服务器下发的第二自启动属性,不予处理,仍然采用第一自启动属性进行应用自启动控制;
步骤1204、采用服务器下发的第二自启动属性进行应用自启动控制。
场景四:终端无需上报,服务器发送自启动控制指令,如图13所示,包括以下步骤:
步骤1301、服务器发送自启动控制指令;
所述自启动控制指令用于指示终端应用对应的自启动属性,自启动属性包括:允许开机时或在后台运行时自启动、和/或禁止开机时或在后台运行时自启动。
步骤1302、终端接收到自启动控制指令,解析自启动控制指令,得到应用对应的自启动属性;
步骤1303、终端查找本地内置应用,判断是否能查询到所述自启动控制指令中指示的应用,根据判断结果采取应用对应的自启动属性进行自启动控制。
这里,所述根据判断结果采取应用对应的自启动属性进行自启动控制,包括:扫描本地内置应用,如果能从中查询到所述自启动控制指令中指示的应用,则采用该应用对应的自启动属性进行自启动控制;如果不能从中查询到所述自启动控制指令中指示的应用,则不予处理。
场景五:终端无需上报,服务器主动实时监测终端的应用运行状态,如图14所示,包括以下步骤:
步骤1401、服务器主动实时监测终端的应用运行状态;
步骤1402、服务器根据自启动强制控制策略监测到终端的应用运行状态发生变化时,下发强制控制指令;
步骤1403、终端接收强制控制指令,不考虑应用对应的自启动属性,而是根据所述强制控制指令对应用进行自启动控制。
比如,当服务器根据自启动强制控制策略监测到终端中存在恶意应用,而导致应用运行状态发生变化时,会下发强制控制指令,指示终端侧来控制关闭该恶意应用。当然,也可以采用服务器侧控制的方式,直接由服务器侧来控制关闭该恶意应用。
这里需要指出的是,恶意软件包括:360这种流氓软件或者试图修改浏览器主页的软件。
又如,当服务器根据自启动强制控制策略监测到终端中存在耗费资源或耗电的应用,而导致应用运行状态发生变化时,会下发强制控制指令,指示终端侧来控制关闭该耗费资源或耗电的应用。当然,也可以采用服务器侧控制的方式,直接由服务器侧来控制关闭该耗费资源或耗电的应用。
再如,除了上述终端运行恶意软件、存在耗费资源或耗电的应用,而终端不自知的情况,需要服务器通知终端侧进行控制,或者由服务器侧直接干扰来控制禁止应用的运行的情况;还可以是有些应用被终端主动误关闭,或者应用运行异常自动退出,而终端不自知的情况,此时,需要服务器通知终端侧进行控制,或者由服务器侧直接干扰来控制应用的自启动运行。
这里,以终端为手机为例的场景,对本发明实施例说明如下:
一、应用本发明实施例,可以在手机上安装一个客户端,比如安装一个服务程序,这种控制方案主要是默认帮用户配置一些用于应用自启动管理的配置信息列表,可以采用白名单的方式,而且,白名单可以为多个,分为不同的优选级。从第三方服务器提供的网站或论坛,比如主流的应用下载市场获取各类应用下载的TOP5。比如微信等,将其默认内置为白名单中。该白名单允许白名单内的应用为开机自启动或后台自启动,比如微信、MSN、360手机卫士、闹钟等,除了白名单以外的应用全都设置为开机不能自启。需要指出的是,有些应用,如万年历或照相机是不存在自身的自启动属性的,因为这类应用不用自启动,需要用户触发才能启动,所以,并不是手机中的所有应用都有自启动属性的。
也就是说,默认配置白名单中的应用可以开机时自启动或在后台自启动,这样保证用户在开机后不会有很多应用程序在后台启动,提升了用户的开机启动速度,也避免后台运行的应用私自上传用户隐私、或者偷跑用户流量。
二、除了上述默认配置白名单的应用自启动控制方案,手机也可以自定义设置应用自启动的控制方案,即:用户DIY配置手机的应用开机自启,比如允许某一应用开机自启或禁止某个应用开机自启或后台自启。这种控制方案主要是基于手机的上报,及服务器对手机上报的分析得到为手机配置的应用自启动属性来实现手机内置应用的自启动控制,以下具体阐述:
具体来说,可以在手机上安装一个客户端,比如安装在手机上的服务程序序根据用户的自行配置,将用户添加的允许自启应用或禁止自启应用的名字或包名上报到后台服务器(可以为云服务器)中,这样后台服务器就会根据配置策略分析某个应用开启开机自启和关闭开机自启动的情况,比如后台服务器计算该应用被用户允许自启的次数和被禁止自启的次数,根据一个阀值(60%)判断是否要帮其他用户关闭该应用的自启动属性。后台服务器再根据统计的数据,判断哪些应用下发给手机允许自启动,哪些禁止自启动。判断用户是否主动设置过该应用的自启动属性,如果用户已经在手机上对该应用设置了自启动属性,那么就以用户的设置为准,保留用户的设置;如果用户没有设置,那么就以后台服务器为准,用服务器的配置设置该应用程序自启属性,这样普通用户即使不知道怎么配置应用的自启动,后台服务器也会帮用户设置好。如此一来,不但提高了用户的开机速度,而且还避免了一些不该自启动的应用在后台运行占用手机资源,从而提升了用户体验。
三、区别于上述以手机上报为基础的一种手机与服务器交互的应用自启动控制方案为:无需手机上报,服务器主动下发应用自启动控制指令给手机,应用自启动控制指令中包含允许在手机上开机自启动或在后台运行自启动的应用列表,手机收到该应用列表后,与本地保存的应用列表进行匹配,如果在本地保存的应用列表中查找到与接收到的应用列表中相同的应用,则设置该应用的自启动属性为允许自启动,以实现根据该自启动属性的应用自启动控制。这个方案的好处是节约服务器的运算成本,即服务器无需计算,由手机这种终端进行运算。由于运算量非常小,并不会影响到手机的运行速度。
四、区别于上述以手机上报为基础的一种手机与服务器交互的应用自启动控制方案为:也是无需手机上报,但是,服务器是主动对手机监测,以便能及时获知手机中是否下载了恶意应用而不自知,比如360这种流氓软件,或者篡改浏览器主页的软件,下发应用自启动控制指令,强制关闭这些应用。当然,也可以强制打开某些误关闭的应用。
五、结合上述一和二所述的内容,即:根据所述配置信息列表进行区分,采取不同的控制方案。判断出本地内置应用归属于所述配置信息列表时,这些应用属于内置列表中的应用,采取上述一的系统默认配置控制方案;判断出本地内置应用不归属于所述配置信息列表时,采取上述二的用户DIY控制方案,即:当用户需要对内置以外的应用加入到自启管理时,手机上安装的服务程序会把用户添加的应用的包名或应用的名字上报到后台服务器中,这样后台服务器就会统计某个应用开启开机自启和关闭开机自启的情况。后台再根据统计的数据,判断哪些应用下发给用户允许自启,哪些不允许。如果用户已经对该应用程序设置了自启属性,那么就以用户的为准,如果用户没有设置,那么就以后台为准,这样普通用户即使不知道怎么配置应用程序的自启,服务器也会帮他设置好。这样不但提高了用户的开机速度,而且还保证了一些不该启来的应用程序在后台占用手机资源。提升了用户体验。
这里需要指出的是:以下对应上述方法项的产品描述,与上述方法描述是类似的,同方法的有益效果描述,不做赘述。对于本发明产品描述中未披露的技术细节,请参照本发明方法实施例的描述。
终端实施例一:
本发明实施例的一种终端,如图15所示,所述终端包括:
获取单元11,用于获取符合预设条件的至少一个应用;
添加单元12,用于将所述至少一个应用添加入配置信息列表中;
扫描单元13,用于扫描内置应用;
判断单元14,用于判断扫描到的所述内置应用是否归属于所述配置信息列表,得到判断结果;
第一控制单元15,用于根据所述判断结果配置所述内置应用的自启动属性,按照所述自启动属性控制应用的自启动。
在本发明实施例一优选实施方式中,所述符合预设条件的至少一个应用包括:在同类应用比较中符合所述预设条件的应用、或者,在不同类应用比较中符合所述预设条件的应用。
终端实施例二:
本发明实施例的一种终端,如图15所示,所述终端包括:
获取单元11,用于获取符合预设条件的至少一个应用;
添加单元12,用于将所述至少一个应用添加入配置信息列表中;
扫描单元13,用于扫描内置应用;
判断单元14,用于判断扫描到的所述内置应用是否归属于所述配置信息列表,得到判断结果;
第一控制单元15,用于根据所述判断结果配置所述内置应用的自启动属性,按照所述自启动属性控制应用的自启动,当所述判断结果表明所述内置应用归属于所述配置信息列表时,将所述内置应用的自启动属性配置为允许自启动,控制所述内置应用在开机时允许自启动运行或者允许在后台自启动运行。
终端实施例三:
本发明实施例的一种终端,如图15所示,所述终端包括:
获取单元11,用于获取符合预设条件的至少一个应用;
添加单元12,用于将所述至少一个应用添加入配置信息列表中;
扫描单元13,用于扫描内置应用;
判断单元14,用于判断扫描到的所述内置应用是否归属于所述配置信息列表,得到判断结果;
第一控制单元15,用于根据所述判断结果配置所述内置应用的自启动属性,按照所述自启动属性控制应用的自启动,当所述判断结果表明所述内置应用不归属于所述配置信息列表时,将所述内置应用的自启动属性配置为禁止自启动,控制所述内置应用在开机时禁止自启动运行或者禁止在后台自启动运行。
终端实施例四:
本发明实施例的一种终端,如图16所示,所述终端包括:
上报单元21,用于上报内置应用的标识信息;所述标识信息用于对内置应用进行标识,使服务器能根据所述标识信息识别出所述内置应用;
接收单元22,用于接收为所述内置应用配置的自启动属性;
第二控制单元23,用于按照所述自启动属性控制内置应用的自启动。
在本发明实施例一优选实施方式中,所述上报内置应用的标识信息包括:周期性上报的方式、或符合预设上报配置条件时上报的方式。
终端实施例五:
本发明实施例的一种终端,如图17所示,包括:
方式确定单元31,用于确定采取所述周期性上报的方式;
扫描单元32,用于扫描内置应用,获取全部的内置应用;
上报单元21,进一步用于上报所述全部的内置应用的标识信息;
接收单元22,用于接收为所述内置应用配置的自启动属性;
第二控制单元23,用于按照所述自启动属性控制内置应用的自启动。
在本发明实施例一优选实施方式中,所述终端包括:
方式确定单元,用于确定采取所述符合预设上报配置条件时上报的方式;
检测单元,用于检测终端运行状态;
条件获取单元,用于所述终端运行状态为第一状态时,获取与所述第一状态对应的预设上报配置条件;
扫描单元,用于触发符合所述预设上报配置条件的内置应用扫描,获取全部的内置应用;
相应的,所述上报单元,进一步用于上报所述全部的内置应用的标识信息。
在本发明实施例一优选实施方式中,所述第二控制单元,进一步包括:
第一控制子单元,用于所述自启动属性配置为允许自启动时,控制所述内置应用在开机时允许自启动运行或者允许在后台自启动运行;
第二控制子单元,用于所述自启动属性配置为禁止自启动,控制所述内置应用在开机时禁止自启动运行或者禁止在后台自启动运行。
在本发明实施例一优选实施方式中,所述终端包括:
方式确定单元,用于确定采取所述符合预设上报配置条件时上报的方式;
检测单元,用于检测终端运行状态;
条件获取单元,用于所述终端运行状态为第二状态时,获取与所述第二状态对应的预设上报配置条件;
扫描单元,用于触发符合所述预设上报配置条件的内置应用扫描,获取部分的内置应用,所述部分的内置应用自身设置有第一自启动属性;
相应的,所述上报单元,进一步用于上报所述部分的内置应用的标识信息,且携带有所述第一自启动属性。
在本发明实施例一优选实施方式中,所述第二控制单元,进一步包括:
扫描检测子单元,用于扫描内置应用,检测到内置应用自身设置有所述第一自启动属性时,将接收到的所述自启动属性作为第二自启动属性并不予处理,按照所述第一自启动属性处理;
属性获取子单元,用于本地获取所述第一自启动属性;
第一控制子单元,用于所述第一自启动属性配置为允许自启动时,控制所述内置应用在开机时允许自启动运行或者允许在后台自启动运行;
第二控制子单元,用于所述第一自启动属性配置为禁止自启动时,控制所述内置应用在开机时禁止自启动运行或者禁止在后台自启动运行。
在本发明实施例一优选实施方式中,所述第二控制单元,进一步包括:
扫描检测子单元,用于扫描内置应用,检测到内置应用自身未设置有所述第一自启动属性时,将接收到的所述自启动属性作为第二自启动属性,并按照所述第二自启动属性处理;
属性获取子单元,用于获取所述第二自启动属性;
第一控制子单元,用于所述第二自启动属性配置为允许自启动时,控制所述内置应用在开机时允许自启动运行或者允许在后台自启动运行;
第二控制子单元,用于所述第二自启动属性配置为禁止自启动时,控制所述内置应用在开机时禁止自启动运行或者禁止在后台自启动运行。
服务器实施例一:
本发明实施例的一种服务器,如图18所示,所述服务器包括:
信息接收单元31,用于接收内置应用的标识信息;
信息识别单元32,用于根据所述标识信息识别出所述内置应用;
分析确定单元33,用于根据配置策略对所述内置应用进行自启动分析,得到自启动属性;
配置单元34,用于为所述内置应用配置自启动属性;
发送单元35,用于发送为所述内置应用配置的自启动属性。
在本发明实施例一优选实施方式中,所述分析确定单元,进一步用于采取包括以下任意一种方式进行分析:
方式一:获取所有终端使用所述内置应用的历史记录,从所述历史记录中得到所述内置应用的使用频率,若所述使用频率达到阈值,则得到所述自启动属性为允许自启动,否则,得到所述自启动属性为禁止自启动;
方式二:获取所有终端使用所述内置应用的历史记录,从所述历史记录中得到所述内置应用的允许自启动次数与禁止自启动次数,若所述允许自启动次数大于所述禁止自启动次数,则得到所述自启动属性为允许自启动,否则,得到所述自启动属性为禁止自启动;
方式三:获取当前上报的终端使用所述内置应用的使用频率,若所述使用频率达到阈值,则得到所述自启动属性为允许自启动,否则,得到所述自启动属性为禁止自启动;
方式四:获取当前上报的终端使用所述内置应用的允许自启动次数,若所述允许自启动次数达到阈值,则得到所述自启动属性为允许自启动,否则,得到所述自启动属性为禁止自启动;
方式五:获取当前上报的终端使用所述内置应用的禁止自启动次数,若所述禁止自启动次数达到阈值,则得到所述自启动属性为禁止自启动,否则,得到所述自启动属性为允许自启动。
本发明实施例所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时,也可以存储在一个计算机可读取存储介质中。基于这样的理解,本发明实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本发明各个实施例所述方法的全部或部分。而前述的存储介质包括:U盘、移动硬盘、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。这样,本发明实施例不限制于任何特定的硬件和软件结合。
相应的,本发明实施例还提供一种计算机存储介质,其中存储有计算机程序,该计算机程序用于执行本发明实施例的应用自启动的控制方法。
以上所述,仅为本发明的较佳实施例而已,并非用于限定本发明的保护范围。