CN109324866A - 应用角标的处理方法、装置、计算机可读存储介质及终端 - Google Patents

Abstract

本申请提供一种应用角标的处理方法、装置、计算机可读存储介质及终端，所述的方法包括：在应用启动时，从预先存储的各个用户的应用角标数据中，获取所述应用当前登录用户的应用角标数据；根据所述当前登录用户的应用角标数据，构建所述当前登录用户的树形结构模型；所述树形结构模型用于描述所述应用中各级应用角标的路径；在接收到所述应用内产生的新消息时，根据所述树形结构模型对对应路径的应用角标数据进行更新。本申请实施例实现了应用角标的统一管理。

Description

应用角标的处理方法、装置、计算机可读存储介质及终端

技术领域

本申请涉及互联网技术领域，具体而言，本申请涉及一种应用角标的处理方法、装置、计算机可读存储介质及终端。

背景技术

随着App(Application，应用)的用户量越来越大，App的应用体验成为各个应用提供方努力的方向。应用上线之后，经常会有功能的更新或者改版，另外，应用内部经常也会有各类的运营活动。在现阶段的移动客户端应用中，普通使用应用角标(如小红点等)来对用户进行提示。

通常情况下，应用角标不是独立使用的，一个应用角标的显示可能涉及到多个子功能模块，而且由于版本的迭代速度越来越快，大量的应用角标将会投放到不同的功能模块。如果没有对应用角标进行统一管理，会导致之后大量应用角标之间的依赖关系变得错综复杂，这样也会给App的日常维护带来极大的挑战，使App出现问题的概率不断增大。因此亟需一种能够统一管理应用角标的方案。

发明内容

本申请针对现有方式存在的缺乏统一管理应用角标方案的缺点，提出一种应用角标的处理方法、装置、计算机可读存储介质及终端，以实现应用角标的统一管理。

本申请的实施例根据第一个方面，提供了一种应用角标的处理方法，包括：

在应用启动时，从预先存储的各个用户的应用角标数据中，获取所述应用当前登录用户的应用角标数据；

根据所述当前登录用户的应用角标数据，构建所述当前登录用户的树形结构模型；所述树形结构模型用于描述所述应用中各级应用角标的路径；

在接收到所述应用内产生的新消息时，根据所述树形结构模型对对应路径的应用角标数据进行更新。

在一个实施例中，所述构建所述当前登录用户的树形结构模型，之后，所述在接收到所述应用内产生的新消息时，根据所述树形结构模型对对应路径的应用角标数据进行更新，之前，还包括：

检测所述当前登录用户的应用角标数据是否需要升级；

若需要升级，获取所述树形结构模型中的根节点；

通过所述根节点搜索出所述树形结构模型中的各个子节点；

对各个子节点进行增删、路径修改以及应用角标数据的更新。

在一个实施例中，所述检测所述当前登录用户的应用角标数据是否需要升级，包括：

获取所述当前登录用户的应用角标数据对应的原始应用版本号，以及所述应用的当前版本号；

若所述当前版本号高于所述原始应用版本号，确定需要升级。

在一个实施例中，各个用户的应用角标数据预先存储在沙盒中；

所述从预先存储的各个用户的应用角标数据中，获取所述应用当前登录用户的应用角标数据，包括：

根据传入的沙盒路径，从各个用户的应用角标数据中，获取所述应用当前登录用户的应用角标数据。

在一个实施例中，应用角标的路径包括应用角标的类型；

所述构建所述当前登录用户的树形结构模型，之后，所述在接收到所述应用内产生的新消息时，根据所述树形结构模型对对应路径的应用角标数据进行更新，之前，还包括：

在所述树形结构模型中，若本级应用角标的类型有多个，将本级应用角标的每种类型对应的路径之间设置为互斥关系；所述互斥关系用于指示应用按照预设的优先级顺序先后显示对应类型的本级应用角标。

在一个实施例中，所述根据所述树形结构模型对对应路径的应用角标数据进行更新，包括：

从所述树形结构模型中获取所述新消息对应的目标应用角标的路径；

根据所述目标应用角标的路径对目标应用角标数据进行更新；

通知所述目标应用角标的路径下预先注册的观察者对象更新应用界面中对应的应用角标。

在一个实施例中，所述通知所述目标应用角标的路径下预先注册的观察者对象更新应用界面中的应用角标，之后，还包括：

若存在所述目标应用角标的上一级应用角标，从所述树形结构模型中获取上一级应用角标的路径；

根据上一级应用角标的路径对上一级应用角标数据进行更新；

通知上一级应用角标的路径下预先注册的观察者对象更新应用界面中对应的应用角标。

本申请的实施例根据第二个方面，还提供了一种应用角标的处理装置，包括：

应用角标数据获取模块，用于在应用启动时，从预先存储的各个用户的应用角标数据中，获取所述应用当前登录用户的应用角标数据；

树形结构模型构建模块，用于根据所述当前登录用户的应用角标数据，构建所述当前登录用户的树形结构模型；所述树形结构模型用于描述所述应用中各级应用角标的路径；

更新模块，用于在接收到所述应用内产生的新消息时，根据所述树形结构模型对对应路径的应用角标数据进行更新。

本申请的实施例根据第三个方面，还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如权利要求1至7中任意一项所述的应用角标的处理方法。

本申请的实施例根据第四个方面，还提供了一种终端，所述终端包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现上述任意一项所述的应用角标的处理方法。

上述的应用角标的处理方法、装置、计算机可读存储介质及终端，将应用角标数据和用户进行绑定，在应用启动时，获取当前登录用户对应的应用角标数据，在有新消息时，根据该应用角标数据构建的树形结构模型进行应用角标数据的更新。通过树型结构模型，对应用内的应用角标数据和层次结构进行统一管理，使应用内的应用角标分布结构和数据清晰明了，不仅降低了维护成本，同时在业务层面上也省去了大部分不必要的重复逻辑。相较于现有技术中采用单例模式，即将应用角标数据跟应用进行绑定，而导致的灵活性较差的缺陷，本申请将每一份应用角标数据和用户进行绑定，应用角标数据独立，不互相影响，提高了应用角标管理的灵活性。

本申请附加的方面和优点将在下面的描述中部分给出，这些将从下面的描述中变得明显，或通过本申请的实践了解到。

附图说明

本申请上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1为本申请一个实施例的应用角标的处理方法的流程示意图；

图2为本申请一个具体实施例的小红点的路径的示意图；

图3为本申请一具体实施例的小红点数据展示方法的示意图；

图4为本申请一个实施例的观察者对象注册方法的流程示意图；

图5为本申请一个实施例的小红点数据更新方法的流程示意图；

图6为本申请一个实施例的应用角标的处理装置的结构示意图；

图7为本申请一个实施例的终端的结构示意图。

具体实施方式

下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本申请，而不能解释为对本申请的限制。

本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本申请的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。

本技术领域技术人员可以理解，除非另外定义，这里使用的所有术语(包括技术术语和科学术语)，具有与本申请所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是，诸如通用字典中定义的那些术语，应该被理解为具有与现有技术的上下文中的意义一致的意义，并且除非像这里一样被特定定义，否则不会用理想化或过于正式的含义来解释。

本技术领域技术人员可以理解，这里所使用的“终端”既包括无线信号接收器的设备，其仅具备无发射能力的无线信号接收器的设备，又包括接收和发射硬件的设备，其具有能够在双向通信链路上，执行双向通信的接收和发射硬件的设备。这种设备可以包括：蜂窝或其他通信设备，其具有单线路显示器或多线路显示器或没有多线路显示器的蜂窝或其他通信设备；PCS(Personal Communications Service，个人通信系统)，其可以组合语音、数据处理、传真和/或数据通信能力；PDA(Personal Digital Assistant，个人数字助理)，其可以包括射频接收器、寻呼机、互联网/内联网访问、网络浏览器、记事本、日历和/或GPS(Global Positioning System，全球定位系统)接收器；常规膝上型和/或掌上型计算机或其他设备，其具有和/或包括射频接收器的常规膝上型和/或掌上型计算机或其他设备。这里所使用的“终端”可以是便携式、可运输、安装在交通工具(航空、海运和/或陆地)中的，或者适合于和/或配置为在本地运行，和/或以分布形式，运行在地球和/或空间的任何其他位置运行。这里所使用的“终端”还可以是通信终端、上网终端、音乐/视频播放终端，例如可以是PDA、MID(Mobile Internet Device，移动互联网设备)和/或具有音乐/视频播放功能的移动电话，也可以是智能电视、机顶盒等设备。

如图1所示，在一个实施例中，一种应用角标的处理方法，包括：

S110、在应用启动时，从预先存储的各个用户的应用角标数据中，获取所述应用当前登录用户的应用角标数据。

应用为设备中任意需要展示应用角标的应用，例如微信等等。应用角标(例如目前普遍采用的小红点等)作为一种通知图标，用于提醒用户应用内产生的新消息，例如App内已有功能、活动的更新或改版，App内添加新功能，未读短信信息或者来电等等。可选的，应用角标数据包括应用角标的类型、数目、以及跟其他应用角标之间的依赖关系等等。应用角标的类型为应用角标的展现形式，可以采用不同的标识区分一个应用角标的不同类型。以小红点为例，目前小红点的类型包括纯红点和数字红点，则可以采用RedPoint标识纯红点，数字红点的标识可以为空或者其它字符，只要能够和纯红点的标识区分开即可。

记录App内产生的应用角标数据，将应用角标数据与用户进行绑定，原则上每个用户应对应一份唯一的应用角标数据。当用户登录某一应用时，就会从预先存储的各个用户的应用角标数据中读取当前登录用户的应用角标数据。通过将用户与应用角标数据绑定的方式进行应用角标管理，相较于传统技术中应用角标数据和应用绑定的方式，使应用角标数据独立，不互相影响，从而提高了后续应用角标管理的灵活性。

S120、根据所述当前登录用户的应用角标数据，构建所述当前登录用户的树形结构模型；所述树形结构模型用于描述所述应用中各级应用角标的路径。

App的页面本身是分级的，页面的访问路径也是一个树型结构。而应用角标一般也是跟着页面走的，所以，可以通过建立一个树型结构模型，来对应用角标进行统一管理。

keyPath(应用角标的路径)为App内标识应用角标的唯一标识。keyPath中，每一级的节点的名字是不能够重复的。可选的，应用角标的路径包括各级节点的名称，进一步的，还可以在路径中对每一级节点的应用角标的类型进行标识。路径中每个节点的名称可以通过“.”符号或者其他符号串联起来。所以，可选的，本申请支持的keyPath格式可以为“root.第一级子节点(根节点的下一级节点)以及应用角标的类型.第二级子节点(第一级子节点的下一级节点)以及应用角标的类型.……”，其中，root表示根节点。

如图2所示，为一具体实施例的小红点的路径的示意图，设应用在桌面icon(图标)显示的小红点的keyPath为：root.app；设应用内的小红点，但是不影响桌面App icon显示的小红点的keyPath为：root.aaa。在纯红点的模式下，root.app显示为root.app.bbb和root.app.ccc的并集。在数字红点的模式下，root.aaa显示为root.aaa.ddd和root.aaa.fff的数目之和。

S130、在接收到所述应用内产生的新消息时，根据所述树形结构模型对对应路径的应用角标数据进行更新。

新消息指的是App内已有功能、活动的更新或改版，App内添加新功能，未读短信信息或者来电等等。当应用内产生新消息时，利用为当前登录用户建立的树形结构模型，即可以实现对相应路径下的应用角标数据进行更新。

上述实施例通过树型结构模型，对应用内的应用角标数据和层次结构进行统一管理，使应用内的应用角标分布结构和数据清晰明了，不仅降低了维护成本，同时在业务层面上也省去了大部分不必要的重复逻辑。另外，相较于现有技术中采用单例模式，即将应用角标数据跟应用进行绑定，而导致的灵活性较差的缺陷，本申请将每一份应用角标数据和用户进行绑定，应用角标数据独立，不互相影响，提高了应用角标管理的灵活性。

在一个实施例中，各个用户的应用角标数据预先存储在沙盒中；所述从预先存储的各个用户的应用角标数据中，获取所述应用当前登录用户的应用角标数据，包括：根据传入的沙盒路径，从各个用户的应用角标数据中，获取所述应用当前登录用户的应用角标数据。沙盒是存储数据的地方，由于本身相对于外部来说是不固定位置，普通用户无法自己找到该路径地址，所以放在这里的数据相对来说是非常安全。App内产生的应用角标数据会持久化到本地沙盒中，沙盒路径由外部自定义传入，根据传入的沙盒路径即可以获取到应用当前登录用户对应的应用角标数据。应当理解的是，应用角标数据存储，可以通过json(JavaScript Object Notation，JS对象简谱)文件进行存储，也可通过本地数据库来存储。

在一个实施例中，应用角标的路径包括应用角标的类型；所述构建所述当前登录用户的树形结构模型，之后，所述在接收到所述应用内产生的新消息时，根据所述树形结构模型对对应路径的应用角标数据进行更新，之前，还包括：在所述树形结构模型中，若本级应用角标的类型有多个，将本级应用角标的每种类型对应的路径之间设置为互斥关系；所述互斥关系用于指示应用按照预设的优先级顺序先后显示对应类型的本级应用角标。若某个视图需要根据不同的场景交替显示一个应用角标的不同类型，如一个小红点交替显示纯红点和数字红点，那么就需要将该应用角标的每种类型对应的keyPath设置为互斥关系。那么后续在显示时就会优先显示其中一种类型的应用角标，在没有该种类型时再显示该应用角标的另一种类型。

如图3所示，为一具体实施例的小红点数据展示方法的示意图，首页的MessageTab，有新活动的时候显示纯红点，但是如有未读IM(Instant Messaging，即时通讯)或者未接来电，则只显示数字红点，不显示纯红点。此时该Tab需要定义纯红点和数字红点两个keyPath，并把纯红点keyPath的互斥关系设为数字红点的keyPath，数字红点的keyPath的优先级高于纯红点keyPath，那么Message Tab就会优先显示数字红点，没有数字红点的时候再显示纯红点。

在一个实施例中，所述根据所述树形结构模型对对应路径的应用角标数据进行更新，包括：从所述树形结构模型中获取所述新消息对应的目标应用角标的路径；根据所述目标应用角标的路径对目标应用角标数据进行更新；通知所述目标应用角标的路径下预先注册的观察者对象更新应用界面中对应的应用角标。

应用角标的路径监测以及事件分发，是通过观察者模式来实现的。观察者模式是软件设计模式的一种，在此种模式中，一个目标物件管理所有相依于它的观察者物件，并且在它本身的状态改变时主动发出通知。定义一对多的依赖关系，即一个keyPath可以对应多个观察者对象，让多个观察者对象能够同时监听某个keyPath。当某路径下的子路径的应用角标数据发生变化时，将会通知到该路径下预先注册的各个观察者对象，使它们能够更新当前的视图应用角标。

在一个实施例中，所述通知所述目标应用角标的路径下预先注册的观察者对象更新应用界面中的应用角标，之后，还包括：若存在所述目标应用角标的上一级应用角标，从所述树形结构模型中获取上一级应用角标的路径；根据上一级应用角标的路径对上一级应用角标数据进行更新；通知上一级应用角标的路径下预先注册的观察者对象更新应用界面中对应的应用角标。

本实施例中，上一级应用角标指的是目标应用角标对应子节点的父节点的应用角标，根据目标应用角标的路径可以确定是否存在上一级应用角标。以目前应用角标的路径：root.app.message.callHistory为例，根据该路径可以得到父节点为root.message、root.app和root。当目标应用角标的数据更新时，会逐层通知到每个父路径(也即是父节点)中，更新每个父路径下的应用角标的数据，并且会逐层通知到每个父路径对应的观察者对象，使它们能够更新当前的视图应用角标。

为了更好的理解上述应用角标数据更新的过程，下面结合一个具体实例进行介绍。

如图3所示，该页面的小红点有四个，分别是call history的数字红点、activity的纯红点、IM消息的数字红点、Message Tab的可能是数字，可能是红点。分别设keyPath值(RedPoint表示类型为纯红点，节点后面的标识为空则表示类型为数字红点)：root.app.message.callHistory、root.app.message.im3980、root.app.messageRedPoint.activityRedPoint以及Message Tab的root.app.message和root.app.messageRedPoint。其中，由于Message Tab可能显示纯红点，可能显示数字红点，所以需要两个不同的路径，并将两个路径设置为互斥关系，优先显示数字节点。

当有未接IP来电或者未读IM消息的时候，设置root.app.message.callHistory和root.app.message.im3980这两个keyPath相对应的红点数目，同时也会通知其父节点root.message、root.app和root，并刷新他们的红点数目。如果这时候activity有纯红点，也不会影响message tab的红点数目，但是当没有其他数字红点需要显示的时候，messagetab就会显示为纯红点。

可选的，本申请采用的观察者模式，是通过定义一个抽象类，该类将继承于NSProxy，通过弱引用观察者对象的方式，利用消息转发机制，将消息转发到观察者对象上，以此来实现观察者对象的自释放。

通常情况下，版本升级会对现有功能进行更新或者改版，这样就可能会导致功能模块的应用角标间依赖关系有所改动，由于本申请的应用角标数据是持久化在本地沙盒中的，而且应用角标数据可能还会影响到其他应用角标的展示，所以版本的升级可能会导致应用角标数据的错乱。而针对该种缺陷，现有技术中缺乏相关的处理方案。

针对上述缺陷，本申请提供了应用角标数据升级的功能，以避免版本升级而导致的应用角标数据的错乱。因此，在一个实施例中，所述构建所述当前登录用户的树形结构模型，之后，所述在接收到所述应用内产生的新消息时，根据所述树形结构模型对对应路径的应用角标数据进行更新，之前，还包括：

检测所述当前登录用户的应用角标数据是否需要升级；

若需要升级，获取所述树形结构模型中的根节点；

通过所述根节点搜索出所述树形结构模型中的各个子节点；

对各个子节点进行增删、路径修改以及应用角标数据的更新。

本实施例中，首先检测应用角标数据是否需要升级，如果需要进行数据升级，则找出应用角标的树形结构模型的根节点，通过这个根节点，可以搜索出整个树形结构模型的所有子节点，然后用户就可以根据需要进行子节点的增加或者删除，对子节点的路径进行修改，以及更新子节点的应用角标数据等等，从而完成应用角标数据升级。

在一个实施例中，所述检测所述当前登录用户的应用角标数据是否需要升级，包括：获取所述当前登录用户的应用角标数据对应的原始应用版本号，以及所述应用的当前版本号；若所述当前版本号高于所述原始应用版本号，确定需要升级。可以通过版本号决定是否需要进行应用角标数据的升级，如果当前启动应用的版本号高于获取的应用角标数据对应的原始版本号，则需要对应用角标数据进行升级，如果当前启动应用的版本号与获取的应用角标数据对应的原始版本号相等，则无需对应用角标数据进行升级。通过该种方式，在版本更新的时候，可对旧版本的应用角标数据进行相应的更新。

为了更好的理解应用角标的处理方法，下面结合一个小红点的具体实施例进行介绍。

如图4所示，为一实施例的观察者对象注册方法的流程示意图，该注册方法包括：

S1、应用启动，传入沙盒路径；

S2、初始化红点管理器，根据传入的沙盒路径获取应用当前登录用户的小红点数据，根据该小红点数据建立用户的树形结构模型，其中，红点管理器用于处理小红点数据；

S3、根据版本号确定是否需要数据迁移或者升级；

S4、如果需要进行数据迁移或者升级，则获取树形结构模型中的根节点，根据该根节点获取树形结构模型中的所有子节点，对所有子节点的小红点数据进行迁移或者升级；之后，进入设置各小红点keyPath的互斥关系的步骤；

S5、如果不需要进行数据迁移或者升级，从树形结构模型中找到需要设置互斥关系的小红点，设置该小红点keyPath的互斥关系；

S6、通过keyPath注册观察者对象。

如图5所示，为一实施例的小红点数据更新方法的流程示意图，该更新方法包括：

S7、接收新消息；

S8、红点管理器根据keyPath更新红点数据；

S9、通知该keyPath下所有观察者对象更新UI(User Interface，用户界面)中的小红点；

S10、根据该keyPath判断是否有父节点；

S11、如有父节点，则根据该keyPath获取父节点的keyPath，返回步骤S8；

S12、若没有父节点，结束。

基于同一发明构思，本申请还提供一种应用角标的处理装置，下面结合附图对本申请装置的具体实施方式进行详细介绍。

如图6所示，在一个实施例中，一种应用角标的处理装置，包括：

应用角标数据获取模块110，用于在应用启动时，从预先存储的各个用户的应用角标数据中，获取所述应用当前登录用户的应用角标数据；

树形结构模型构建模块120，用于根据所述当前登录用户的应用角标数据，构建所述当前登录用户的树形结构模型；所述树形结构模型用于描述所述应用中各级应用角标的路径；

更新模块130，用于在接收到所述应用内产生的新消息时，根据所述树形结构模型对对应路径的应用角标数据进行更新。

在一个实施例中，所述装置还包括连接在树形结构模型构建模块120和更新模块130之间的升级模块，所述升级模块包括：

检测单元，用于检测所述当前登录用户的应用角标数据是否需要升级；

根节点获取单元，用于在需要升级时，获取所述树形结构模型中的根节点；

子节点搜索单元，用于通过所述根节点搜索出所述树形结构模型中的各个子节点；

升级单元，用于对各个子节点进行增删、路径修改以及应用角标数据的更新。

在一个实施例中，检测单元用于获取所述当前登录用户的应用角标数据对应的原始应用版本号，以及所述应用的当前版本号；在所述当前版本号高于所述原始应用版本号时，确定需要升级。

在一个实施例中，各个用户的应用角标数据预先存储在沙盒中；应用角标数据获取模块110根据传入的沙盒路径，从各个用户的应用角标数据中，获取所述应用当前登录用户的应用角标数据。

在一个实施例中，所述装置还包括连接在树形结构模型构建模块120和更新模块130之间的互斥关系设置模块，所述互斥关系设置模块用于在所述树形结构模型中，在本级应用角标的类型有多个时，将本级应用角标的每种类型对应的路径之间设置为互斥关系；所述互斥关系用于指示应用按照预设的优先级顺序先后显示对应类型的本级应用角标。

在一个实施例中，更新模块130包括：

第一路径获取单元，用于从所述树形结构模型中获取所述新消息对应的目标应用角标的路径；

第一更新单元，用于根据所述目标应用角标的路径对目标应用角标数据进行更新；

第一通知单元，用于通知所述目标应用角标的路径下预先注册的观察者对象更新应用界面中对应的应用角标。

在一个实施例中，更新模块130还包括与第一通知单元依次相连的第二路径获取单元、第二更新单元和第二通知单元；

所述第二路径获取单元用于在存在所述目标应用角标的上一级应用角标时，从所述树形结构模型中获取上一级应用角标的路径；

所述第二更新单元用于根据上一级应用角标的路径对上一级应用角标数据进行更新；

所述第二通知单元用于通知上一级应用角标的路径下预先注册的观察者对象更新应用界面中对应的应用角标。

本申请实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述任意一项所述的应用角标的处理方法。其中，所述存储介质包括但不限于任何类型的盘(包括软盘、硬盘、光盘、CD-ROM、和磁光盘)、ROM(Read-OnlyMemory，只读存储器)、RAM(Random AcceSS Memory，随即存储器)、EPROM(EraSableProgrammable Read-Only Memory，可擦写可编程只读存储器)、EEPROM(ElectricallyEraSable Programmable Read-Only Memory，电可擦可编程只读存储器)、闪存、磁性卡片或光线卡片。也就是，存储介质包括由设备(例如，计算机)以能够读的形式存储或传输信息的任何介质。可以是只读存储器，磁盘或光盘等。

本申请实施例还提供一种终端，所述终端包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现上述任意一项所述的应用角标的处理方法。

如图7所示，为了便于说明，仅示出了与本申请实施例相关的部分，具体技术细节未揭示的，请参照本申请实施例方法部分。该终端可以为包括手机、平板电脑、PDA(Personal Digital Assistant，个人数字助理)、POS(Point of Sales，销售终端)、车载电脑、服务器等任意终端设备，以终端为手机为例：

图7示出的是与本申请实施例提供的终端相关的手机的部分结构的框图。参考图7，手机包括：射频(Radio Frequency，RF)电路210、存储装置220、输入单元230、显示单元240、传感器250、音频电路260、无线保真(wireless fidelity，Wi-Fi)模块270、处理器280、以及电源290等部件。本领域技术人员可以理解，图7中示出的手机结构并不构成对手机的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

下面结合图7对手机的各个构成部件进行具体的介绍：

RF电路210可用于收发信息或通话过程中，信号的接收和发送，特别地，将基站的下行信息接收后，给处理器280处理；另外，将设计上行的数据发送给基站。通常，RF电路210包括但不限于天线、至少一个放大器、收发信机、耦合器、低噪声放大器(Low NoiseAmplifier，LNA)、双工器等。此外，RF电路210还可以通过无线通信与网络和其他设备通信。上述无线通信可以使用任一通信标准或协议，包括但不限于全球移动通讯系统(GlobalSystem of Mobile communication，GSM)、通用分组无线服务(General Packet RadioService，GPRS)、码分多址(Code Division Multiple Access，CDMA)、宽带码分多址(Wideband Code Division Multiple Access,WCDMA)、长期演进(Long Term Evolution，LTE)、电子邮件、短消息服务(Short Messaging Service，SMS)等。

存储装置220可用于存储软件程序以及模块，处理器280通过运行存储在存储装置220的软件程序以及模块，从而执行手机的各种功能应用以及数据处理。存储装置220可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如应用角标处理功能等)等；存储数据区可存储根据手机的使用所创建的数据(比如树形结构模型、电话本等)等。此外，存储装置220可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

输入单元230可用于接收输入的数字或字符信息，以及产生与手机的用户设置以及功能控制有关的键信号输入。具体地，输入单元230可包括触控面板231以及其他输入设备232。触控面板231，也称为触摸屏，可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触控面板231上或在触控面板231附近的操作)，并根据预先设定的程式驱动相应的连接装置。可选的，触控面板231可包括触摸检测装置和触摸控制器两个部分。其中，触摸检测装置检测用户的触摸方位，并检测触摸操作带来的信号，将信号传送给触摸控制器；触摸控制器从触摸检测装置上接收触摸信息，并将它转换成触点坐标，再送给处理器280，并能接收处理器280发来的命令并加以执行。此外，可以采用电阻式、电容式、红外线以及表面声波等多种类型实现触控面板231。除了触控面板231，输入单元230还可以包括其他输入设备232。具体地，其他输入设备232可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。

显示单元240可用于显示由用户输入的信息或提供给用户的信息以及手机的各种菜单。显示单元240可包括显示面板241，可选的，可以采用液晶显示器(Liquid CrystalDisplay，LCD)、有机发光二极管(Organic Light-Emitting Diode,OLED)等形式来配置显示面板241。进一步的，触控面板231可覆盖显示面板241，当触控面板231检测到在其上或附近的触摸操作后，传送给处理器280以确定触摸事件的类型，随后处理器280根据触摸事件的类型在显示面板241上提供相应的视觉输出。虽然在图7中，触控面板231与显示面板241是作为两个独立的部件来实现手机的输入和输入功能，但是在某些实施例中，可以将触控面板231与显示面板241集成而实现手机的输入和输出功能。

手机还可包括至少一种传感器250，比如光传感器、运动传感器以及其他传感器。具体地，光传感器可包括环境光传感器及接近传感器，其中，环境光传感器可根据环境光线的明暗来调节显示面板241的亮度，接近传感器可在手机移动到耳边时，关闭显示面板241和/或背光。作为运动传感器的一种，加速计传感器可检测各个方向上(一般为三轴)加速度的大小，静止时可检测出重力的大小及方向，可用于识别手机姿态的应用(比如横竖屏切换、相关游戏、磁力计姿态校准)、振动识别相关功能(比如计步器、敲击)等；至于手机还可配置的陀螺仪、气压计、湿度计、温度计、红外线传感器等其他传感器，在此不再赘述。

音频电路260、扬声器261，传声器262可提供用户与手机之间的音频接口。音频电路260可将接收到的音频数据转换后的电信号，传输到扬声器261，由扬声器261转换为声纹信号输出；另一方面，传声器262将收集的声纹信号转换为电信号，由音频电路260接收后转换为音频数据，再将音频数据输出处理器280处理后，经RF电路210以发送给比如另一手机，或者将音频数据输出至存储装置220以便进一步处理。

Wi-Fi属于短距离无线传输技术，手机通过Wi-Fi模块270可以帮助用户收发电子邮件、浏览网页和访问流式媒体等，它为用户提供了无线的宽带互联网访问。虽然图7示出了Wi-Fi模块270，但是可以理解的是，其并不属于手机的必须构成，完全可以根据需要在不改变发明的本质的范围内而省略。

处理器280是手机的控制中心，利用各种接口和线路连接整个手机的各个部分，通过运行或执行存储在存储装置220内的软件程序和/或模块，以及调用存储在存储装置220内的数据，执行手机的各种功能和处理数据，从而对手机进行整体监控。可选的，处理器280可包括一个或多个处理单元；优选的，处理器280可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器280中。

手机还包括给各个部件供电的电源290(比如电池)，优选的，电源可以通过电源管理系统与处理器280逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。

尽管未示出，手机还可以包括摄像头、蓝牙模块等，在此不再赘述。

在一实施方式中，终端包括一个或多个处理器280，以及一个或多个存储装置220，一个或多个应用程序，其中所述一个或多个应用程序被存储在存储装置220中并被配置为由所述一个或多个处理器280执行，所述一个或多个应用程序配置用于执行以上实施例所述的应用角标的处理方法。

上述的应用角标的处理方法、装置、计算机可读存储介质及终端，可以封装为独立的控件，无缝接入iOS项目或者其它项目中，例如在iOS中的Hello、Hello Yo中使用，其中，iOS为苹果公司为移动设备所开发的专有行动作业系统，属于Unix系统，支持装置包括iPhone、iPod touch和iPad等。通过树型结构模型对应用角标进行统一管理，同时将应用角标数据与用户进行绑定，使应用角标数据独立，不互相影响，能够对应用角标数据进行升级，适配于App中的大部分场景。

应该理解的是，虽然附图的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，附图的流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

应该理解的是，在本申请各实施例中的各功能单元可集成在一个处理模块中，也可以各个单元单独物理存在，也可以两个或两个以上单元集成于一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。

以上所述仅是本申请的部分实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。

Claims (10)

1.一种应用角标的处理方法，其特征在于，包括：

在应用启动时，从预先存储的各个用户的应用角标数据中，获取所述应用当前登录用户的应用角标数据；

根据所述当前登录用户的应用角标数据，构建所述当前登录用户的树形结构模型；所述树形结构模型用于描述所述应用中各级应用角标的路径；

在接收到所述应用内产生的新消息时，根据所述树形结构模型对对应路径的应用角标数据进行更新。

2.根据权利要求1所述的应用角标的处理方法，其特征在于，所述构建所述当前登录用户的树形结构模型，之后，所述在接收到所述应用内产生的新消息时，根据所述树形结构模型对对应路径的应用角标数据进行更新，之前，还包括：

检测所述当前登录用户的应用角标数据是否需要升级；

若需要升级，获取所述树形结构模型中的根节点；

通过所述根节点搜索出所述树形结构模型中的各个子节点；

对各个子节点进行增删、路径修改以及应用角标数据的更新。

3.根据权利要求2所述的应用角标的处理方法，其特征在于，所述检测所述当前登录用户的应用角标数据是否需要升级，包括：

获取所述当前登录用户的应用角标数据对应的原始应用版本号，以及所述应用的当前版本号；

若所述当前版本号高于所述原始应用版本号，确定需要升级。

4.根据权利要求1所述的应用角标的处理方法，其特征在于，各个用户的应用角标数据预先存储在沙盒中；

所述从预先存储的各个用户的应用角标数据中，获取所述应用当前登录用户的应用角标数据，包括：

根据传入的沙盒路径，从各个用户的应用角标数据中，获取所述应用当前登录用户的应用角标数据。

5.根据权利要求1至4任意一项所述的应用角标的处理方法，其特征在于，应用角标的路径包括应用角标的类型；

所述构建所述当前登录用户的树形结构模型，之后，所述在接收到所述应用内产生的新消息时，根据所述树形结构模型对对应路径的应用角标数据进行更新，之前，还包括：

在所述树形结构模型中，若本级应用角标的类型有多个，将本级应用角标的每种类型对应的路径之间设置为互斥关系；所述互斥关系用于指示应用按照预设的优先级顺序先后显示对应类型的本级应用角标。

6.根据权利要求1至4任意一项所述的应用角标的处理方法，其特征在于，所述根据所述树形结构模型对对应路径的应用角标数据进行更新，包括：

从所述树形结构模型中获取所述新消息对应的目标应用角标的路径；

根据所述目标应用角标的路径对目标应用角标数据进行更新；

通知所述目标应用角标的路径下预先注册的观察者对象更新应用界面中对应的应用角标。

7.根据权利要求1至4任意一项所述的应用角标的处理方法，其特征在于，所述通知所述目标应用角标的路径下预先注册的观察者对象更新应用界面中的应用角标，之后，还包括：

若存在所述目标应用角标的上一级应用角标，从所述树形结构模型中获取上一级应用角标的路径；

根据上一级应用角标的路径对上一级应用角标数据进行更新；

通知上一级应用角标的路径下预先注册的观察者对象更新应用界面中对应的应用角标。

8.一种应用角标的处理装置，其特征在于，包括：

应用角标数据获取模块，用于在应用启动时，从预先存储的各个用户的应用角标数据中，获取所述应用当前登录用户的应用角标数据；

树形结构模型构建模块，用于根据所述当前登录用户的应用角标数据，构建所述当前登录用户的树形结构模型；所述树形结构模型用于描述所述应用中各级应用角标的路径；

更新模块，用于在接收到所述应用内产生的新消息时，根据所述树形结构模型对对应路径的应用角标数据进行更新。

9.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如权利要求1至7中任意一项所述的应用角标的处理方法。

10.一种终端，其特征在于，所述终端包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1至7中任意一项所述的应用角标的处理方法。