一种应用程序处理方法、装置、终端及服务器与流程

本发明涉及通信
技术领域：
，具体涉及一种应用程序处理方法、装置、终端及服务器。
背景技术：
：目前，由于安卓操作系统容易形成卡顿，有的手机厂商会根据一些自己定义的软件策略来清除内存解决卡顿的问题。目前，对于卡顿问题，大部分厂商的做法是：第一种方式：厂商自己确定清除内存的白名单，在白名单外的所有手机应用和进程可以被kill。第二种方式：引入第三方应用，各类手机助手如手机管家、猎豹清理大师等来清除手机应用。第三种方式：引入类似冷藏室，将暂时不用的应用冻结，在需要启动的时候再尝试启动。上述的几种方式分别代表了厂商决定，用户决定和APP决定手机应用处理的方式，但这些方式都没有考虑到每一个用户的使用习惯，没有针对每个用户的使用习惯进行应用程序的清理。在这个体验和用户习惯为上的时代，无论是用户还是厂商或者第三方都无法决定用户在什么时刻需要打开app和使用多长时间的app，能够真正能够真实反映用户使用习惯的是数据。技术实现要素：本发明实施例要解决的主要技术问题是，提供一种应用程序处理方法、装置、终端及服务器，解决现有技术中对应用程序的清理未考虑到用户使用习惯造成的应用程序处理不合理，不具有针对性的问题。为解决上述技术问题，本发明实施例提供一种应用程序处理装置，包括：获取模块，用于获取预设周期内用户对目标应用程序的使用数据；确定模块，用于根据使用数据确定下一个周期内对目标应用程序的处理策略，处理策略包括后台管理策略和内存优化策略；处理策略用于在下一个周期内对目标应用程序进行相应的处理。为解决上述技术问题，本发明实施例还提供一种终端，包括上述的应用程序处理装置，还包括：处理模块，用于根据应用程序处理装置确定的处理策略，在下一个周期对目标应用程序进行相应的处理。为解决上述技术问题，本发明实施例还提供一种服务器，包括上述的应用程序处理装置，还包括：发送模块，用于将应用程序处理装置确定的处理策略发送给目标终端，处理策略用于目标终端在下一个周期内对目标应用程序进行相应的处理。为解决上述技术问题，本发明实施例还提供一种应用程序处理方法，包括：获取预设周期内用户对目标应用程序的使用数据；根据使用数据确定下一个周期内对目标应用程序的处理策略，处理策略包括后台管理策略和内存优化策略；处理策略用于在下一个周期内对目标应用程序进行相应的处理。本发明实施例公开了一种应用程序处理方法、装置、终端及服务器，可以根据预设周期内的用户对目标应用程序的使用数据，确定下一周期对目标应用程序的处理策略，对于每个用户而言，使用数据是实时反映其对应用程序的使用习惯的数据，所以本发明实施例的处理策略具有对各用户习惯的针对性和友好性，是为每个用户量身定做的策略，相对于现有技术，更加符合用户使用习惯。附图说明图1为本发明实施例一提供的一种应用程序处理方法的流程图；图2为本发明实施例二提供的一种应用程序处理装置的结构图；图3为本发明实施例二提供的另一种应用程序处理装置的结构图；图4为包括实施例二中的应用程序处理装置的一种终端的结构图；图5为包括实施例二中的应用程序处理装置的一种服务器的结构图。具体实施方式下面通过具体实施方式结合附图对本发明作进一步详细说明。实施例一：参见图1，本实施例示出了一种应用程序处理方法，可以在一定的周期内获取用户对某些应用程序的使用数据，从使用数据中分析用户应用程序的使用习惯，比如哪些应用使用频繁，使用时间长等等信息，然后根据对使用数据的分析确定出对应用程序的处理策略，帮助终端在使用过程中对应用程序进行合理的清除内存或关闭程序等处理，有效节约终端的内存资源，有效避免终端的卡顿问题。本实施例的应用程序处理方法包括：S101、获取预设周期内用户对目标应用程序的使用数据；S102、据使用数据确定下一个周期内对目标应用程序的处理策略，其中，处理策略包括后台管理策略和内存优化策略；处理策略用于在下一个周期内对目标应用程序进行相应的处理。本实施例中目标应用程序包括手机系统自带的程序以及从第三方下载的应用程序。目前用户可以选择的应用程序越来越多，生活类、工作学习类、娱乐类等等类型的应用程序越来越多的被开发，一个用户终端上可能存在多达几十上百的应用程序，不是每一个应用程序都会占用大量内存的，若将所有的应用程序均作为目标应用程序，则会浪费一定的运算资源。优选的，可以根据一定的选择规则，将终端上其中一部分应用程序划分为目标应用程序。例如，将非系统应用程序划分为目标应用程序；或者将占用内存空间较大的前N(N>0，N为正整数)个应用程序划分为目标应用程序，上述的划分可以由终端自动完成，也可以作为选择规则呈现给用户，供用户选择。此外，用户还可以自由设置目标应用程序。为了使得本实施例中S102中的处理策略稳定可靠，S101中的使用数据应具有稳定性和可靠性，鉴于此，使用数据应为一定时间周期内的统计数据，该周期可以预设，预设周期为一周及以上的时间是比较合理的。当然，低于一周的预设周期也是可取的，只是预设周期越短，使用数据的稳定可靠性就越低，S102中的处理策略可靠性相应地也就越低。可以理解，使用数据是能反映用户对目标应用程序使用习惯的数据，从使用数据中可以看出用户最常用的应用程序，使用最频繁的应用程序，使用时间长的应用程序等等，优选的，本实施例的使用数据包括但不限于目标应用程序的打开时间、关闭时间以及利用打开时间关闭时间计算得到的应用程序的使用时间、使用频率等数据。其中，目标应用程序的使用时间可理解为在预设周期内的累计使用时间。其中，S101中的预设周期和S102中的下一个周期可以设置为相同的时长，也可以是不同的时长。预设周期和该下一个周期可以根据实际情况重新设置。可以预见，在终端的使用过程中，终端上的应用程序可能会发变化，例如增加或删除某些应用程序，此外，用户对某应用程序的使用习惯可能也会发生变化，例如，用户在某一时间段开始进行运动健身，健身类APP使用时间和使用频率增加。因此，在制定了处理策略后，还是需要继续监控用户的使用习惯、获取对目标应用程序的使用数据，然后对处理策略进行相应的修正。所以，在下一个周期内，当使用上一周期确定的处理策略时，同时还是需要继续记录各个目标应用程序的使用数据，根据该周期内目标应用程序的使用数据确定再下一个周期对目标应用程序的处理策略。可以预见，若在某周期内，用户新装了某个应用程序，则可以自动或根据用户设置将该程序划分为目标应用程序，记录其使用数据。在S102中的处理策略包括后台管理策略和内存优化策略，分别用于在下一个周期内对目标应用程序进行后台管理和内存优化管理。可以预见，在预设周期内，使用时间长，使用频繁的应用程序是需要为用户保留的程序，因此在确定处理策略时，依据的中心思想是根据使用数据确定用户对各目标应用程序的使用需求的强弱，使用需求越强则越需要被保留。为了方便对终端上的目标应用程序的处理，S101中根据使用数据确定目标应用程序的处理策略的具体过程包括：A、根据使用数据，以及预设的使用数据与应用程序使用等级之间的对应关系，确定目标应用程序的使用等级；B、根据目标应用程序的使用等级；以及预设的应用程序使用等级与应用程序的处理策略之间的对应关系，确定下一个周期内对目标应用程序的处理策略。在步骤A中，使用数据可以反映用户常用的目标应用程序，其中，可以预见目标应用程序的使用等级越高，表明该目标应用程序越常被使用，越需要保留，所以目标应用程序的使用等级越高，其对应的处理策略中，对后台关闭该目标应用程序以及清除该目标应用程序的内存的条件应设置的越宽容，才能在后台管理应用程序和内存时，将用户常使用的应用程序保留，避免误关闭以及误清除内存造成的目标应用程序的数据丢失，给用户带来不便等问题。下面举例说明如何根据使用数据确定使用等级：假设目标应用程序包括QQ、微信、去哪儿、便签。在预设周期(一周)内，QQ的打开次数是30次，使用时间累计为10小时；微信的打开次数是50次，使用时间为11小时；去哪儿的打开次数为5次，使用时间为30分钟；便签的打开次数为4次，使用时间为15分钟；则根据打开次数和使用时长的比较，用户对目标应用程序的常用度从高到低的排列为微信、QQ、去哪儿、便签。可以预见，在确定应用程序的使用等级时，微信、QQ一定比去哪儿、便签的等级高。其中，根据使用数据确定目标应用程序的使用等级比较简单的方法，可以参考上述的例子，根据使用数据对目标应用程序从最常用的到最不常用的进行排序，根据排列的顺序对每个APP设置一个使用等级。可以预见，若每个目标APP均设有一个等级，则对应的每个等级都需要设置对应的处理策略，在目标应用程序数量较多的时候，处理策略数目较多，会浪费终端的资源。优选的，可以根据实际的使用数据将目标应用程序划分为具体的几个使用等级，将使用次数，累计时长等数据统计相近的划分为一个使用等级，例如将上述的QQ、微信划分为一个等级“频繁”，表明对应的APP使用频繁，在处理时需要尽可能地保留。为了进一步降低使用等级划分复杂度，可以根据用户实际的使用数据，为每个目标应用程序设置一个对应的打开次数(打开频率)的区间以及使用时长的区间，某一目标应用程序的使用数据中对应的数据在各个区间内，则该目标应用程序属于该使用等级。由于各用户使用目标应用程序的频繁度不一样，对于区间的设置可以根据使用数据来确定。进一步地，本实施例中可以设置表1：使用等级表，根据使用数据和该表确定使用等级。表1如下：表1可以理解上表只用于进行示例说明，对于实际的使用等级的设置没有限定。上述的使用等级还可以用一级、二级、三级等表示，并不局限于上述的“频繁”“常用”等表示方式。为了降低根据使用等级确定目标应用程序的处理策略的复杂度，可以预先设置各使用等级与处理策略的对应关系，即预先设置目标应用程序的使用等级与后台管理策略以及内存优化策略的对应关系。应用程序的后台运行无疑会占用终端的运行内存，消耗终端的电量，后台运行时间越长，消耗的电量就越多，同时一直占用运行内存会挤压其他应用程序的运行空间，极易造成卡顿问题。所以，可以以终端的后台运行时间的长短作为是否在后台kill目标应用程序的条件，当然，kill目标应用程序需要结合应用程序的使用等级，使用等级越高，kill该目标应用程序的条件越高。这才是符合用户使用习惯的后台管理方式。假设根据上述的目标应用程序QQ、微信、去哪儿、便签的使用数据将QQ、微信的使用等级划分为“频繁”，将去哪儿、便签的使用等级划分为“很少”，则在制定后台管理策略时，考虑到QQ、微信的使用等级，后台管理策略对killQQ和微信的kill条件要求最高，QQ和微信的kill优先级最低。优选的，可以根据终端上的目标应用程序的闲置时长来确定是否关闭目标应用程序，进一步地，对于目标应用程序的每一使用等级，都设置对应的预设时长，当目标应用程序闲置时长达到预设时长，则可以对目标应用程序进行后台关闭。参见表2，示出了目标应用程序的使用等级与后台管理策略的对应关系等级后台管理策略内存kill优先级频繁后台不kill，提示通知最低常用1个小时闲置后kill低一般半小时闲置后kill中很少10分钟后kill高表2上述的后台管理策略仅用于示例说明，对实际的预设时长不作限定。对于本实施例中的内存优化策略，由于优化的是目标应用程序的内存，需要结合目标应用程序的实际内存和目标应用程序的使用等级来确定。优选的，内存优化策略包括：目标应用程序内存达到预设值则清除该目标应用程序的内存。可以预见，每个使用等级对应的目标应用程序内存的预设值是不同的。例如下表3。使用等级内存优化策略频繁内存不优化，达到预设值提示通知常用超过200M，优化内存一般超过100M，优化内存很少超过50M，优化内存表3对于上述表3，考虑到各个目标应用程序的大小本身不一样，对于同一使用等级的目标应用程序而言，使用同一内存优化判断标准不是最优方案，上述还可以进一步细化，对于同一使用等级的目标应用程序，可以根据目标应用程序本身的大小进一步设置合适的预设值。上述的过程是根据使用数据得到处理策略的过程，在实际中，上述的过程可以全部由安装目标应用程序的终端自身进行，即终端获取自身的在预设周期内对目标应用程序的使用数据，根据使用数据确定目标应用程序的使用等级，根据目标应用程序的使用等级以及预设在终端上的使用等级与处理策略的对应关系确定最终对目标应用程序的处理策略。其中，终端上对使用数据的分析可以由终端系统自带的程序实现，使用等级与处理策略的对应关系预存在终端上。此外，还可以由在终端上安装的独立的后台管理APP实现，该后台管理APP在获取用户的使用数据前，需要获得用户的许可，避免用户的私密信息泄露。在另一实施例中，根据使用数据得到处理策略的过程可以由服务器实现，即上述的额S101和S102可以由服务器实现。其中，安装目标应用程序的目标终端负责收集自身对应用程序的使用数据，发送使用数据给服务器，在S102之后，服务器将确定的处理策略发送给目标终端，目标终端接收并使用该处理策略即可。其中，服务器发送处理策略前，可以将不同APP的使用等级以及处理策略等数据写入不同的配置文件，通过OTA(Over－the－AirTechnology，空中下载技术)或者一个APP推送的方式达到目标终端。可以预见，由于发送使用数据给服务器以及服务器发送处理策略给终端涉及用户隐私，为了保护用户隐私安全，可以将本实施例的方案作为用户体验计划中的一部分，当用户同意加入用户体验计划时，才允许目标终端收集使用数据，允许目标终端与服务器之间传输时延数据和处理策略。进一步地，在用户打开用户体验计划时，用户会了解厂商回收用户的隐私用户数据，如果用户对收集的使用数据中某些隐私数据不同意发送，或对某些应用程序不同意加入体验计划，则可以将该数据类型或应用程序加入白名单进行保护。进一步的，目标终端可以设置为在WiFi网络下向服务器上传使用数据，服务器根据该目标终端的IMEI号记录该目标终端的数据。当然，将上述两种确定处理策略的方式进行合适的结合，由目标终端和服务器共同完成处理策略的确定也是可行的，例如，目标终端向服务器传输对目标应用程序的使用数据，服务器根据使用数据确定目标应用程序的使用等级，将各目标应用程序与使用等级的对应关系发送给目标终端，目标终端根据自身存储的目标应用程序的使用等级与处理策略的对应关系确定对目标应用程序的处理策略。采用本实施例，获取使用数据，通过用户自身的操作习惯来决定自己手机终端的清理方式，解决卡顿问题的同时，解决了用户体验的关键问题。进一步地，通过数据的回传和大数据的算法分析，通过给单一用户画像，再对用户习惯进行分类研究，输出稳定的版本，更加友好，更加符合以后的趋势。获得用户使用数据的同时也能够获得相应的用户粘性，具有非常大的价值。实施例二：参见图2，本实施例示出一种应用程序处理装置，包括：获取模块21，用于获取预设周期内用户对目标应用程序的使用数据；确定模块22，用于根据所述使用数据确定下一个周期内对所述目标应用程序的处理策略，所述处理策略包括后台管理策略和内存优化策略；所述处理策略用于在所述下一个周期内对所述目标应用程序进行相应的处理。本实施例中目标应用程序包括手机系统自带的程序以及从第三方下载的应用程序。目前用户可以选择的应用程序越来越多，生活类、工作学习类、娱乐类等等类型的应用程序越来越多的被开发，一个用户终端上可能存在多达几十上百的应用程序，为了节约应用程序处理装置的资源，应用程序处理装置可以包括设置模块，用于根据一定的选择规则，将目标终端(安装目标应用程序的终端)的一部分应用程序划分为目标应用程序。例如，将非系统应用程序划分为目标应用程序；或者将占用内存空间较大的前N(N>0，N为正整数)个应用程序划分为目标应用程序，该选择规则可以预先存储在应用程序处理装置中，也可以由用户设定。本实施例对此没有限制。其中，可以理解的是对于使用数据而言，收集其的预设周期越短，使用数据的稳定可靠性就越低，确定模块22确定的处理策略可靠性相应地也就越低。鉴于此，需要保证预设周期具有一定的时长，预设周期为一周及以上是比较合理的。确定模块22确定的处理策略包括后台管理策略和内存优化策略，对于后台管理策略和内存优化策略可以理解为在下一个周期内对目标应用程序进行后台管理和内存优化管理的策略。根据一般的理解，在预设周期内，使用时间长，使用频繁的应用程序是需要为用户保留的程序，因此确定模块22在确定处理策略时，依据的中心思想是根据使用数据确定用户对各目标应用程序的使用需求的强弱，使用需求越强则越需要被保留。其中，可以理解的是，随着时间的变化，用户终端上的应用程序会发生变化(增加或减少)，用户对某些应用程序的使用习惯也会变化，例如在结束减肥后，对于健身类的APP使用频率明显下降。所以，在下一个周期结束时，获取模块21还是需要继续获取各个目标应用程序的使用数据，根据该周期内目标应用程序的使用数据确定再下一个周期对目标应用程序的处理策略。其中，若在某周期内，用户新装了某个应用程序，则设置模块可以自动或根据用户设置将该程序划分为目标应用程序，获取模块21需要同时获取该应用程序的使用数据。便于确定模块22制定处理策略。对于用户而言，使用数据是如实反应其对目标应用程序的使用习惯的数据，用户对终端的操作包括打开和关闭，所以使用数据包括打开时间和关闭时间，由打开时间和关闭时间还可以计算得到目标应用程序在预设周期内的打开频率，以及使用时间(周期内的累计使用时间)，这些也可以包括在使用数据中，当然使用数据还可以包括目标应用程序调用的APP等数据。优选的，参见图3，本实施例的确定模块22包括：第一确定子模块221，用于根据所述使用数据，以及预设的使用数据与应用程序使用等级之间的对应关系，确定所述目标应用程序的使用等级；第二确定子模块222，用于根据所述目标应用程序的使用等级；以及预设的应用程序使用等级与应用程序的处理策略之间的对应关系，确定所述下一个周期内对所述目标应用程序的处理策略。其中，目标应用程序的使用等级越高，表明该目标应用程序越常被使用，越需要保留，所以目标应用程序的使用等级越高，其对应的处理策略中，对后台关闭该目标应用程序以及清除该目标应用程序的内存的条件应设置的越宽容，才能在后台管理应用程序和内存时，将用户常使用的应用程序保留，避免误关闭以及误清除内存造成的目标应用程序的数据丢失，给用户带来不便等问题。第一确定子模块221，根据使用数据确定目标应用程序的使用等级时，可以根据目标应用程序的使用时间的长短以及使用频率的大小来确定某个目标应用程序的使用等级，使用时间越长，使用频率越高，目标应用程序的使用等级就越高。其中，使用等级的具体确定方案可以参考实施例一中的例子和表1，本实施例对比不再赘述。本实施例中的目标应用程序的使用等级可以采用实施例一中的“频繁”、“常用”、“一般”、“很少”等表示方式。参看本方案可知应用程序使用等级与应用程序的处理策略之间的对应关系是事先设置好的，这是为了减少确定处理策略的时间。其中，处理策略包括后台管理策略和内存优化策略，所以，本实施例中，预先设置目标应用程序的使用等级与后台管理策略以及内存优化策略的对应关系。应用程序的后台运行无疑会占用终端的运行内存，消耗终端的电量，后台运行时间越长，消耗的电量就越多，同时一直占用运行内存会挤压其他应用程序的运行空间，极易造成卡顿问题。所以，后台管理策略中，可以以终端的后台运行时间的长短作为是否在后台kill目标应用程序的条件，当然，kill目标应用程序需要结合应用程序的使用等级，使用等级越高，kill该目标应用程序的条件越高。这才是符合用户使用习惯的后台管理方式。其中，使用等级与后台管理策略的对应关系设置的方式参考实施例一的表1以及相关叙述，本实施例对此不再赘述。对于本实施例中的内存优化策略，由于优化的是目标应用程序的内存，需要结合目标应用程序的实际内存和目标应用程序的使用等级来确定。优选的，内存优化策略包括：目标应用程序内存达到预设值则清除该目标应用程序的内存。使用等级与内存优化策略的对应关系参见实施例一的表3。在另一实施例中，提供一种终端，参见图4，包括本实施例的应用程序处理装置，还包括处理模块42，该处理模块42用于根据所述应用程序处理装置确定的处理策略，在下一个周期对目标应用程序进行相应的处理。其中，考虑到使用数据中可能包括隐私数据，为了保护用户的隐私，该终端还可以包括隐私保护模块，用于在获取模块31获取使用数据前，询问用户是否同意获取使用数据。在另一实施例中，提供了一种服务器，参见图5，包括本实施例的应用程序处理装置，以及发送模块52，发送模块52用于将所述应用程序处理装置确定的处理策略发送给目标终端，该处理策略用于所述目标终端在下一个周期内对目标应用程序进行相应的处理。其中，应用程序处理装置3中的确定模块22在确定了处理策略后，可以将不同APP的使用等级以及处理策略等数据写入不同的配置文件；发送模块52可以通过OTA(Over－the－AirTechnology，空中下载技术)或者一个APP推送的方式达到目标终端。可以预见，由于服务器回传数据涉及用户隐私，为了保护用户隐私，使用服务器确定处理策略时，目标终端上需要提示用户获取的使用数据为哪些，并且取得用户的同意。采用本实施例，可以利用获取模块获取预设周期内用户对目标应用程序的使用数据；利用确定模块根据所述使用数据确定下一个周期内对所述目标应用程序的处理策略，对于每个用户而言，使用数据是实时反映其对应用程序的使用习惯的数据，所以本实施例的处理策略是为每个用户量身定做的策略，相对于现有技术，更加符合用户使用习惯，能更加友好和更针对性地解决终端卡顿问题。显然，本领域的技术人员应该明白，上述本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储介质(ROM/RAM、磁碟、光盘)中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。所以，本发明不限制于任何特定的硬件和软件结合。以上内容是结合具体的实施方式对本发明所作的进一步详细说明，不能认定本发明的具体实施只局限于这些说明。对于本发明所属
技术领域：
的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干简单推演或替换，都应当视为属于本发明的保护范围。当前第1页1 2 3