【老文档20160925】一种基于大数据进行预防与阻断应用相互唤醒启动的方法

【老文档20160925】一种基于大数据进行预防与阻断应用相互唤醒启动的方法 一、本专利技术所属的领域：

领域： *** 作系统/应用管理
常规用途：通过合理的应用管理，改善性能和功耗。

二、相关技术背景

技术背景：手机耗电、卡顿的原因之一，部分耗电应用在后台频繁调度CPU导致不必要的功耗和内存占用。举个例子：为用户明明没有主动打开某个应用，却在使用过程中出现了该应用推送过来的广告，这就是典型的耗电应用单纯为自身商业利益进行的异常且不必要的行为。
本发明方案基于大数据进行应用异常行为收集并在此基础上制定的限制相互唤醒启动策略，旨在准确预防和阻断应用后台唤醒启动行为，让耗电应用从此再无机会后台偷偷频繁调度CPU资源，进而改善系统性能和续航能力。

三、本发明技术方案的详细阐述 3.1 应用相互唤醒启动现象

应用相互唤醒启动的触发源：【附图1相互唤醒启动的触发源及危害】
1.开机事件
2.解锁事件
3.网络变化事件
4.数据同步事件
5.推送事件
6.定时启动事件
7.不同应用之间自定义广播事件
8.不同应用数据交互事件
9.应用启动群发Aciton事件
10.等等
上述事件是应用相互唤醒启动的事件源，如果不作任何的管理和限制的话，即使用户不打开任何应用，通过上述事件的任意事件触发，就有可能出现应用后台的偷偷唤醒启动。

应用相互唤醒启动的方式：
目前安卓系统共有4中启动类型，ActivityServiceContentProviderBroadCastRecevier,应用后台相互启动共4个就占了3种，即ServiceContentProviderBroadCastRecevier.可见后台应用相互唤醒的现状有多么严峻。

Ps：这里通俗的解释下4中启动类型带来的现象，便于理解。
Activity类型启动：
Activity本身有界面的意思，该类型启动时用户可以看到界面出现，比如桌面上点开一个应用就可以打开对应应用界面
Service类型启动：
后台相互唤醒启动主要通过该类型进行启动，比如流氓应用后台通过Service偷偷上传或下载数据,由于不需要任何界面让用户看到，蒙蔽用户而偷偷运行行为。
ContentProvider类型启动：
同一家公司旗下存在多个APP下通过内部协商制定一个数据访问的接口，这样一来自家公司的多个APP就可以跨进程相互访问数据了。通过调用该数据访问接口，就可以启动该公司下的所有已装在用户手机的应用，该方式非常隐蔽主要是进行数据交互使用，也有个别公司纯粹利用数据交互形式可以启动其他应用的特点进行后台偷偷运行。
BroadCastRecevier类型启动：
例如应用想开机时进行自启动，可以通过注册BroadCastRecevier对应的开机广播实现开机自启动功能。

综合上述的现象和现状，提出基于大数据进行预防和阻断应用相互唤醒启动的方法，旨在有针对性的管控应用的异常行为，即蛇打七寸即有效可完成目的。

3.2 基于大数据进行预防和阻断应用相互唤醒启动的方法

• 3.2.1 大数据的主要目的是采集应用异常启动行为
• 3.2.2 根据异常启动行为数据库制定相互唤醒策略并推送更新规则
• 3.2.3 基于大数据推送的唤醒策略进行预防和阻断应用相互唤醒

3.2.1 大数据的主要目的是采集应用异常启动行为和推送更新相互唤醒策略

A.大数据收集应用异常行为数据方法【附图2大数据收集应用异常行为数据】
因为Activity类型启动方式一般是用户主动点击程序的，属于正常的行为，但是应用异常启动往往通过ServiceContentProviderBroadCastRecevier的方式进行启动，这3中类型的启动其中一个共同点之一启动不需任何界面或提示，就可以达到再后台偷偷运行的目的，故我们进行下面的数据采集步骤

①　ServiceContentProviderBroadCastRecevier的启动入口设置采集点
②　通过下面的采集规则进行数据收集工作
1.启动发起源Src，例如A进程
2.被启动对象Dest，例如B进程
3.启动动作方式Action
即获取A进程某个动作Aciton启动了B进程这个行为，我们还可以继续收集发生这个行为的时间和出现次数统计。

③　根据上述收集规则保存到本地应用异常启动数据库，并根据需要定期上传到服务器。可以根据产品定义每周或每月上传一次数据到服务器。

3.2.2 根据异常启动行为数据库制定相互唤醒策略并推送更新规则

这里主要通过大数据进行数据分析的工作，目的通过异常现象制定限制相互唤醒规则。为了便于理解，这里举一些目前我司制定的规则。
我们通过大数据分析发现ServiceContentProviderBroadCastRecevier 3种类型启动的现象有共同点，于是我们根据实际收集到的数据分别进行如下规则制定，当然规则会随着大数据的不断更新而更新和加强。
限制BroadCastRecevier广播类型启动的规则可以如下 ：
当一个应用在手机安装完成后，我们可以进行进一步的“应用体检”，若是应用包含的广播组件中含有开启启动、解锁、网络变化、推送等功能时，我们会禁用该组件并保存“相互唤醒组件”数据库中；
限制Service服务类型启动的规则可以如下 ：
当一个应用在手机安装完成后，我们可以进行进一步的“应用体检”，若是应用包含的服务组件中含推送、同步、唤醒等功能时，其中对应推送功能的服务组件我们甚至研究了市面上23家主流推送公司的SDK并按实际情况调整规则，我们会禁用该组件并保存“相互唤醒组件”数据库中；
限制ContentProvider数据交互类型启动的规则可以如下 ：
由于该数据交互类型启动比较特殊，我们一般通过收集的信息会进行专项分析进行专项规则建立，保证确实只是后台唤醒启动特性的才会被禁用该组件并保存“相互唤醒组件”数据库中；

综上规则的建立是根据实际应用后台相互唤醒的的现象进行收集和分析而得到，虽然大家的分析方法可能不一样，但是总的原则都是为了得到应用相互唤醒的异常组件。
同样对于规则的变更我们同样选择让服务器定期按需推送新规则到用户的手机端。推送的时间同样根据实际产品定义而定。

3.2.3 基于大数据推送的唤醒策略进行预防和阻断应用相互唤醒

预防应用相互唤醒的方法
【附图3预防应用相互唤醒的方法】
用户每安装完成一个应用后，还需进行应用体检，目的是将应用每个组件信息与唤醒策略进行配对，若属于唤醒策略规则的组件，会被禁用并保存“相互唤醒组件”数据库。应用体检也可以等同功能阉割理解，相当于应用安装完成后其中解锁启动、网络变化启动、广告推送启动的功能将被禁用，即阉割掉，但是应用本身主要的功能却不会受到任何影响。
通过应用体检的应用一些相互唤醒的行为将被得到有效的预防。

阻断应用相互唤醒的方法
【附图4阻断应用相互唤醒的方法】
实时动态监控应用启动状态，当一个应用启动时可以根据启动类型判断是否用户主动点击启动还是后台启动。
若是用户主动点击启动，则读取该应用对应相互唤醒组件”数据库的组件信息，恢复之前被禁用的组件
若是后台启动，则需要判定是否属于允许后台运行的白名单应用，若是运行后台运行的白名单应用，则读取该应用对应相互唤醒组件”数据库的组件信息，恢复之前被禁用的组件。若不是白名单应用，则读取该应用对应相互唤醒组件”数据库的组件信息，继续禁用该应用对应的组件，最后清理该应用进程，防止其后台偷偷运行。

3.4 本发明技术方案带来的有益效果(优点)

本方案主要针对应用耗电行为的管理，通过预防和阻断耗电行为可以带来下面的好处：
1.减轻CPU的负担，彻底杜绝应用偷偷调度CPU资源行为，减轻这一情况带来的额外负担；
2.防止WiFi/Gps/Gprs的后台额外被使用
3.减少屏幕绘制事件的次数，后台应用的每个d出消息，都需要调度屏幕绘制并显示；
4.杜绝应用后台偷偷运行行为和阻断应用之间相互启动行为，减少系统内存占用和系统内大量后台应用运行造成的发热，功耗现象。
5.通过大数据的反馈和推送新增规则，动态调整预防和阻断唤醒启动的策略，进一步加强和改善应用管理策略。

上述的好处，本质是减少CPU资源调度和CPU被唤醒的次数，可以减低手机日常使用下各种场景的平均电流和系统内存占用，改善系统性能和续航能力。

四、提供本发明创造的附图

附图1相互唤醒启动的触发源及危害

附图2大数据收集应用异常行为数据

【附图3预防应用相互唤醒的方法】

【附图4阻断应用相互唤醒的方法】

五、本发明的技术关键点或欲保护点是什么

1.收集ServiceContentProviderBroadCastRecevier 3种类型启动的行为数据
2.将应用异常启动行为按期上传大数据服务器
3.异常行为分析并制定针对性规则
4.服务器不定时推送更新的相互唤醒规则
5.根据相互唤醒策略的规则进行应用体检，预防应用唤醒启动
6.根据监听应用启动行为进行动态清理、禁用和恢复禁用应用的机制