CN113507406A - 消息管理方法及相关设备 - Google Patents

Abstract

本申请的实施例提供了一种消息管理方法及相关设备，涉及终端技术领域。所述方法解析通知消息的关键属性，并在确定通知消息的消息类型为消费类消息时，根据关键属性确定通知消息是否属于已发生的一笔交易。该方法在确定通知消息属于所述交易且存在与所述交易对应的消息历史记录、以及屏幕正在展示通知消息的同类消息时，对通知消息和同类消息进行合并或者删减处理或者执行阅读状态的更新操作。利用本实施例可有效提升消息管理的效率。

Description

消息管理方法及相关设备

技术领域

本申请实施例涉及终端技术领域，尤其涉及一种消息管理方法及相关设备。

背景技术

移动支付已经成为广大用户的日常高频行为。在线支付发展迅猛，市场上存在的在 线支付平台众多，一个用户的电子设备(例如，智能手机、平板电脑等设备)上通常使 用多个支付平台，每个支付平台均关联用户的银行卡账户。由此，当用户的银行卡账户 产生了一笔银行卡交易时，电子设备的通知栏会收到多个平台推送的关于所述笔银行卡 交易的消息。如此，必然导致消息的数量增多，不仅占用内存，也不便有效信息的及时 查看。

发明内容

本申请实施例公开了一种消息管理方法及相关设备，能够优化电子设备的通知消息 的展示。

本申请第一方面公开了一种消息管理方法，应用于电子设备中，该方法包括：接收通知消息，并解析所述通知消息的关键属性，所述关键属性包括消息来源、消息类型、消费状态、金额、银行名、银行***、交易时间，所述消费状态包括收入和支出；若确定所述通 知消息的消息类型为消费类消息时，根据所述通知消息的关键属性确定所述通知消息是 否属于已发生的一笔交易；及若确定所述通知消息属于所述交易且存在与所述交易对应的消息历史记录、以及确定正在展示所述通知消息的同类消息时，对所述通知消息和所述正在展示的同类消息进行合并处理或者删减处理或者执行阅读状态的更新操作。

采用所述技术方案，在确定正在展示与新收到的通知消息属于同一笔交易的同类消 息时，可以对新收到的通知消息和该同类消息进行合并处理或者删减处理或者执行阅读状 态的更新操作，由此优化电子设备对通知消息的展示的功能。

在一些可选的实施方式中，所述方法还包括：若确定正在展示同类消息，在通知栏展 示所述通知消息；根据所述关键属性，合并所述通知消息和所述正在展示的同类消息，获 得合并消息；及从所述通知栏中删除所述通知消息和所述正在展示的同类消息并展示所述合 并消息。采用所述技术方案，根据关键属性对通知消息和同类消息进行合并，删除在通 知栏展示的通知消息和同类消息并在通知栏展示合并消息，可以简化通知栏所展示的内 容同时便利用户阅读通知消息。

在一些可选的实施方式中，所述方法还包括：若确定正在展示同类消息，在通知栏不 展示所述通知消息；根据所述关键属性，合并所述通知消息和所述正在展示的同类消息， 获得合并消息；及从所述通知栏中删除所述同类消息并在所述通知栏中展示所述合并消息。 采用所述技术方案，不在通知栏展示通知消息，并根据关键属性对通知消息和同类消息 进行合并，删除在通知栏展示的同类消息并在通知栏展示合并消息，可以进一步简化通 知栏所展示的内容同时便利用户阅读通知消息。

在一些可选的实施方式中，所述方法还包括：若确定正在展示所述同类消息，在通知 栏展示或者不展示所述通知消息；合并所述通知消息和所述正在展示的同类消息，获得所 述合并消息；及在所述通知栏展示所述合并消息，并将所述通知消息和所述正在展示的同类 消息折叠展示在所述合并消息的下方。采用所述技术方案，通过合并通知消息和同类消息 以及在通知栏展示合并消息，并将通知消息和同类消息折叠展示，可以便利用户阅读通知 消息的同时还可供用户查阅每条消息对应的内容。

在一些可选的实施方式中，所述方法还包括：若确定正在展示所述同类消息，从所述 通知消息和所述正在展示的同类消息中确定一个保留消息；及从通知栏中删除其他消息， 所述其他消息是指所述通知消息和所述正在展示的同类消息中，除所述保留消息之外的消 息。

在一些可选的实施方式中，所述方法还包括：若确定正在展示所述同类消息，展示所 述通知消息；从所述通知消息和所述正在展示的同类消息中确定一个保留消息；及将其他 消息的阅读状态标记为已读状态，并从通知栏删除所述其他消息，所述其他消息表示所述通知消息和所述正在展示的同类消息中，除所述保留消息之外的消息。

采用所述技术方案，可以简化通知栏对消息内容的展示的同时避免用户阅读相同消 息。

在一些可选的实施方式中，所述方法还包括：获取所述其他消息对应的已读按钮，所 述已读按钮用于将其他消息的阅读状态标记为已读状态；点击已读按钮将其他消息的阅 读状态标记为已读状态。

在一些可选的实施方式中，所述保留消息为所述通知消息和所述正在展示的同类消 息中的任意一个消息。

在一些可选的实施方式中，所述保留消息为所述通知消息和所述正在展示的同类消 息中，最早收到的一个消息或者最晚收到的一个消息。

在一些可选的实施方式中，所述保留消息为所述通知消息和所述正在展示的同类消 息中，源自所设置的消息来源的消息。

在一些可选的实施方式中，所述方法还包括：提供设置界面，响应用户操作，设置一 个消息来源。采用所述技术方案，可以根据用户的需求来管理通知消息的展示。

在一些可选的实施方式中，所述方法还包括：将所述通知消息存储到所述交易的消息 历史记录内。

在一些可选的实施方式中，所述方法还包括：预先创建合并消息的消息模板；及根据 所述关键属性填充所述消息模板，获得合并消息。采用所述技术方案，基于所创建的消息模板来获得合并消息可以快速获得合并消息。

在一些可选的实施方式中，所述方法还包括：利用通知管理器预设通知频道；利用所 述通知管理器对所述通知频道预设若干字段，所述若干字段与所述消费类消息的各个属 性一一对应；若所述通知管理器接收到所述通知消息，利用所述通知管理器按照所述若干字段解析所述通知消息并获得所述关键属性。

在一些可选的实施方式中，所述方法还包括：利用通知管理器的NotificationListenerService获取通知栏中的所有通知消息的标题及内容；及利用自然语言处理 NLP技术，从所获取的通知消息的标题及内容中抽取关键属性。

采用所述技术方案，可以从通知消息中准确获得关键属性。

在一些可选的实施方式中，所述关键属性包括消息来源、消息类型、消费状态、金额、 银行名、银行***、交易时间。

在一些可选的实施方式中，所述方法还包括:对所述关键属性进行格式化处理。

在一些可选的实施方式中，所述方法还包括:若确定所述通知消息不属于所述交易， 将所述通知消息存储到与所述通知消息对应的消息历史记录。

在一些可选的实施方式中，所述方法还包括:若确定所述通知消息属于所述交易但不 存在与所述交易对应的消息历史记录，为所述交易创建对应的消息历史记录。

在一些可选的实施方式中，所述同类消息是指已经存储在所述交易对应的消息历史记 录内，且为收到所述通知消息之前的预定时长内所接收到的消息。

在一些可选的实施方式中，所述方法还包括：若确定没有展示同类消息，在通知栏展 示所述通知消息或者不展示所述通知消息。

在一些可选的实施方式中，所述方法还包括：按照收到消息的先后顺序对预设时间内 来自同一消息来源的两个或多个消费类消息分别进行标记以区分多笔先后发生的不同交 易；及根据所述标记基于预先创建的消息模板对属于同笔交易但来自不同消息来源的消 费类消息进行合并处理。

在一些可选的实施方式中，所述方法还包括：对预设时间内的属于不同交易但是消费 状态相同的消息进行合并处理，包括：基于所述不同交易涉及的交易金额统计总交易金 额；及基于所述消息模板以及总交易金额生成合并消息。

在一些可选的实施方式中，所述方法还包括：对预设时间内的属于不同交易但是消费 状态不相同的消息进行合并处理，包括：基于所述不同交易涉及的交易金额统计总交易 金额；及基于所述消息模板以及总交易金额生成合并消息。

采用所述技术方案，便利用户了解个人消费的总体情况。

本申请第二方面公开了一种电子设备，包括处理器和存储器；所述存储器，用于存储指 令；所述处理器，用于调用所述存储器中的指令，使得所述电子设备执行所述的消息管理方 法。

本申请第三方面公开了一种计算机可读存储介质，所述计算机可读存储介质存储有至少 一个指令，所述至少一个指令被处理器执行时实现所述的消息管理方法。

第二方面至第三方面所带来的技术效果可参见上述方法部分各涉及的方法相关的描 述，此处不再赘述。

附图说明

图1是一种消息管理方法的应用场景示意图。

图2A-图2E是本实施例提供的消息管理方法的应用场景示意图。

图3是本申请实施例提供的一种消息管理方法流程图。

图4A-图4E是本申请实施例提供的一种消息管理方法示意图。

图5A-图5D是本申请实施例提供的一种消息管理方法示意图。

图6A-图6E是本申请实施例提供的一种消息管理方法示意图。

图7A-图7C是本申请实施例提供的一种消息管理方法示意图。

图8A-图8C是本申请实施例提供的一种消息管理方法示意图。

图9A-图9C是本申请实施例提供的一种消息管理方法示意图。

图10A-图10C是本申请实施例提供的一种消息管理方法示意图。

图11A-图11E是本申请实施例提供的一种消息管理方法示意图。

图12A-图12J是本申请实施例提供的一种消息管理方法示意图。

图13是本申请实施例提供的一种消息管理方法流程图。

图14是本申请实施例提供的一种消息管理方法流程图。

图15是本申请实施例提供的另一种消息管理方法流程图。

图16A-图16B是本申请实施例提供的另一种消息管理方法示意图。

图17是本申请实施例提供的电子设备的结构示意图。

图18是本申请实施例提供的电子设备的软件结构框图。

具体实施方式

需要说明的是，本申请实施例中“至少一个”是指一个或者多个，“多个”是指两个或 多于两个。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/ 或B可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A，B可以是 单数或者复数。本申请的说明书和权利要求书及附图中的术语“第一”、“第二”、“第三”、 “第四”等(如果存在)是用于区别类似的对象，而不是用于描述特定的顺序或先后次序。

图1是一种消息管理方法的应用场景示意图。

如图1所示，电子设备在通知栏展示了三个通知消息，所述三个通知消息分别来自

应用(Application，App)、

App、***。所述三个通知消息所包 括的消费状态(即支出)、交易时间(如2021年4月1日9:59)、金额(即0.01元) 等属性相同。即所述三个通知消息实际上为对应同一笔交易的消息。可见，电子设备为 用户重复展示了三个相同的通知消息，影响消息管理效率以及用户的使用体验。

图2A-图2E是本申请实施例提供的一种应用场景示意图。

如图2A-图2B所示，电子设备在交易D1发生后，先后收到源自招商银行App的通知消息M1和源自支付宝App的消息M1’。如图2C所示，电子设备对属性相同的消息M1和 M1’合并处理为消息N1并在通知栏展示消息N1。如图2D所示，电子设备随后又收到源自 ***的消息M1”，并将消息M1”和消息N1合并处理为消息N1’(也即是将消息M1、 M1’，及M1”进行合并处理)，并展示消息N1’如图2E所示。也即本申请实施例提供的电子 设备可以对先后收到的来源不同但是属性相同的消息M1、M1’、M1”进行合并处理，有 效提升了消息管理效率，便利用户及时查阅消息。具体方法参见后面对图3的介绍。

图3是本申请实施例提供的一种消息管理方法流程图。本申请实施例提供的消息管 理方法可以应用于电子设备，具体地，可以应用于电子设备的应用程序框架层(Application Framework)的通知管理器(Notification Manager)中(即以下步骤S11-S20可由通知管理器来执行)。所述消息管理方法也可以应用于电子设备的应用程序层，作 为一个应用程序实现(即以下步骤S11-S20可由应用程序来执行)。

具体地，消息管理方法包括：

S11，于发生一笔交易时，创建与交易对应的交易记录。

举例而言，当发生交易D1时，则为交易D1创建交易记录。

在本申请的一个实施例中，所述交易记录包括，但不限于，银行名、银行***、消费状态(或称“消费类型”)、交易时间、金额等。

S12，接收通知消息，并解析所述通知消息关键属性。

具体而言，电子设备接收的通知消息可能为所述交易产生的消息，也可能为其他交易 所产生的消息，或者非因交易所产生的消息。

以所述通知消息为所述交易产生的消息为例，假设用户的支付宝App关联了用户的招商 银行的账户C1，用户在利用支付宝App完成了一笔交易D1后，则招商银行App会生成一条 通知消息并推送给电子设备。此外，支付宝App也会基于所述交易D1生成一条通知消息并 推送给电子设备。

在本申请的一个实施例中，所述关键属性包括消息来源、消息类型、消费状态、金额。 在其他实施例中，所述关键属性还可以进一步包括银行名、银行***、交易时间。

需要说明的是，具体可根据实际业务需要，可以继续增加属性以在后续(例如步骤S18) 进行相同消息的判断时具备更高的准确性，或者减少部分属性，以适应更多的消息来源格式， 但在后面进行相同消息的判断时准确性会降低。关于相同消息的判断将在下文(例如步骤 S18)进行详细介绍。

在本申请的一个实施例中，所述消息来源是指发送所述通知消息的平台，例如可以是 银行App(如

等)、支付平台App(如

等)、***消息和IM平台消息(如短信、邮箱、微信等)。所述消息类型包括，但不限于，消费类消息、通信类消息、广告类消息、提醒类消息。所述消费状态 可以是指支出或收入。

以所述消息管理方法应用于应用程序框架层的通知管理器为例，在本申请的一个实 施例中，为能够实现对所述通知消息的关键属性的解析，可以利用通知管理器预设一种通 知频道(notification channel)，并为通知频道命名，例如将通知频道命名为transaction (交易)；并对通知频道预设若干字段，即针对消费类消息定义若干字段，所述若干字 段与消费类消息的各个属性一一对应。具体可参阅后面对图12的介绍。

例如，所述若干字段的内容分别与所述消费类消息的关键属性如消息来源、消息类型、 银行名、银行***、交易时间、消费状态、金额一一对应。

需要说明的是，以上仅以消费类消息为例说明，可根据实际业务需要对所述多个字 段的内容格式进行设计。

对于需要推送消费类消息的应用程序(如银行App(如招商银行、掌上生活、中国银行、缤纷生活等)、支付平台App(如支付宝、微信、云闪付等)、***消息和IM平台消 息(如短信、邮箱、微信等)等)，可将消费类消息的内容按照所述若干字段进行填充， 及按照所述通知频道推送消费类消息到通知管理器。由此当通知管理器接收到所述通知 消息时即可按照所述预先对所述若干字段的定义来解析所述通知消息获得关键属性，例 如消息来源、消息类型、银行名、银行***、交易时间、消费状态、金额等。

具体而言，可在开发这类需要推送消费类消息的应用程序时，将所要推送的消费类 消息匹配到通知频道，由此即可将消费类消息的内容按照所述若干字段进行填充获得所 要推送的通知消息，并将通知消息推送到通知管理器。

在本申请的一个实施例中，在解析获得了所述通知消息的关键属性时，还对所述关 键属性进行格式化处理。

以对银行名进行格式化处理为例，例如可以将招行和招商银行统一成招商银行；以对银 行***进行格式化处理为例，例如可以将银行***统一为银行***的尾号四位；以对金额进 行格式化处理为例，例如可以将1分钱和0.01元统一为0.01元；以对交易时间进行格式化处 理为例，例如可以将年月日小时分钟统一为小时分钟；以对消费状态进行格式化处理为例， 例如可以将支付、支出、消费和花费统一为支出，也即支付、支出、消费和花费是同一个消 费状态。需要说明的是，在本实施例中，收入和支出不是同一个消费状态；充值和支付也不 是同一个消费状态。例如，在某时某分，某人a利用银行卡c支付了一个订单的金额d元， 完成了交易t1，则交易t1对应的消费状态为支出；又如，继交易t1完成之后的预设时间内(短 时间内例如1分钟内)有另一个人b给a的银行卡c转账了d元完成了交易t2，则该笔交易 t2对应的消费状态为收入。这里需要说明的是，由于交易t1和t2对应的消费状态不同，因此 交易t1和t2属于两笔不同的交易。

在本申请的其他实施例中，可以根据发送所述通知消息的平台确定所述通知消息的消 息来源。例如，当所接收的通知消息来源于支付宝App时即可确定所述通知消息的消息来源 为支付宝App。

在其他实施例中，以所述消息管理方法应用于电子设备的应用程序层，作为一个应 用程序实现为例，在本申请的一个实施例中，为能够实现对所述通知消息的关键属性的解 析，可以由应用程序利用通知管理器里的NotificationListenerService获取通知栏中的所有 通知消息的标题及内容(Notification.EXTRA_TITLE、Notification.EXTRA_TEXT)；由 应用程序利用自然语言处理(Natural Language Processing，NLP)技术，从所获取的通 知消息的标题及内容抽取关键属性如银行名、银行***、交易时间、消费状态、金额等实 体。具体可参阅后面对图14的介绍。

S13，确定所述通知消息的消息类型是否为消费类消息。若确定所述通知消息的消息 类型为消费类消息时，执行S14；若确定所述通知消息的消息类型不是消费类消息时，执行S20。

在本申请的其他实施例中，也可以在S12仅先对所述通知消息的消息类型进行解析， 若在S13确定所述通知消息的消息类型为消费类消息时，再在S14对所述通知消息的其他属性如消息来源、消费状态、金额、银行名、银行***、交易时间等进行识别。

S14，若确定所述通知消息的消息类型为消费类消息时，根据所述通知消息的关键属 性确定所述通知消息是否属于所述交易。若确定所述通知消息不属于所述交易时，执行S15；若确定所述通知消息属于所述交易时，执行S16。

如前面所述，当发生交易时会为所述交易创建交易记录，所述交易记录包括，但不限于，银行名、银行***、消费状态、交易时间、金额等。在本申请的一个实施例中， 可以将所述通知消息的关键属性与所述交易记录进行比较，若所述关键属性所包括的银 行名、银行***、消费状态、交易时间、金额与所述交易记录记载的均一致，则确定所 述通知消息属于所述交易。

S15，若确定所述通知消息不属于所述交易，将所述通知消息存储到与所述通知消息对 应的消息历史记录，然后，流程转至步骤S20。

举例而言，假设所述通知消息不属于S11中发生的交易D1，而属于交易D2，则将所述 通知消息存储到与所述通知消息对应的交易D2的消息历史记录中。

S16，若确定所述通知消息属于所述交易，确定是否存在所述交易对应的消息历史记 录。若不存在所述交易对应的消息历史记录，执行S17；若存在所述交易对应的消息历史记 录，执行S18。

在本申请的实施例中，若确定所述通知消息属于所述交易但是不存在所述交易对应的 消息历史记录，即可确定所述通知消息为首次收到的属于所述交易的消费类消息。若确定 所述通知消息属于所述交易且已经存在所述交易对应的消息历史记录，可确定所述通知消 息不是首次收到的属于所述交易的消费类消息，也即所述通知消息为属于所述交易的新 收到的消息。

在本申请的一个实施例中，电子设备于首次收到属于每笔交易的消费类消息时为所 述每笔交易对应创建一个消息历史记录，即每笔交易对应一个消息历史记录。例如交易D1对应消息历史记录L1；交易D2对应消息历史记录L2。在本申请的一个实施例中， 每笔交易对应的消息历史记录可以存储于电子设备的存储器中。

在本申请的一个实施例中，每笔交易对应的所述消息历史记录是一个列表，包括多 个栏位，用于记录属于每笔交易的消费类消息。所述多个栏位包括，但不限于，收到消息的时间、消息来源、消息类型、银行名、银行***、交易时间、消费状态、金额等。

S17，若不存在所述交易对应的消息历史记录，创建所述交易对应的消息历史记录，将 所述通知消息存储到所述交易对应的消息历史记录，然后，流程转至步骤S20。

举例而言，若所述通知消息属于交易D1，所述存储器中不存在交易D1对应的消息历史 记录L1时，即所述通知消息为电子设备首次收到的属于交易D1的消费类消息，则为交易 D1创建对应的消息历史记录L1，并将所述通知消息存储到交易D1对应的消息历史记录L1 中。具体地，将收到所述通知消息的时间、所述通知消息的消息来源、消息类型、银行名、银行***、交易时间、消费状态、金额等对应存储到所述消息历史记录L1的各个栏位。

S18，若存在所述交易对应的消息历史记录，确定是否正在展示所述通知消息的同类 消息(即与所述通知消息属性相同的消息)，其中，所述同类消息已经存储在所述交易的消息历史记录内。若确定正在展示所述同类消息，执行S19；若确定没有展示所述同类 消息，执行S20。

在本申请的一个实施例中，所述同类消息是指已经存储在所述交易对应的消息历史 记录内，且为收到所述通知消息之前的预定时长内(例如5分钟之内)所接收到的消息。

在本申请的一个实施例中，属性相同的消息可以是指消息类型都为消费类消息，消 息来源不同，但银行名、银行***、交易时间、消费状态以及金额都相同的消息。在其 他实施例中，属性相同的消息也可以是指消息类型都为消费类消息，消息来源不同，但 是金额和消费状态都相同的消息。具体可根据实际业务需要，为确保更高的判断准确性， 可以对消息的更多的属性进行比较判断以确定相同的消息，或者减少部分属性的判断以适应更多的消息来源格式，但准确性会降低。

S19，若确定正在展示同类消息，对所述通知消息和正在展示的同类消息进行合并处理 或者删减处理或者执行阅读状态的更新操作；以及将所述通知消息存储到所述交易的消息历 史记录。

在本申请的第一实施例中，若确定正在展示同类消息时，电子设备在通知栏展示所 述通知消息；根据关键属性，合并所述通知消息和正在展示的同类消息，获得一个合并消 息；从通知栏中删除所述通知消息和所述正在展示的同类消息并展示所述合并消息。

电子设备还可以在展示所述通知消息的同时播放预设的第一提示音效，以及在展示 所述合并消息的同时播放预设的第二提示音效。所述第一提示音效与所述第二提示音效 可以相同或者不同。

电子设备还将合并消息存储到所述交易的消息历史记录内。

在本申请的一个实施例中，电子设备可以预先创建一个合并消息的消息模板；根据 所述关键属性填充所述消息模板，获得合并消息。

举例而言，所述消息模板为“①通知：您的②③于④⑤⑥；合并自⑦App消息”， ①至⑦则依次代表需要填入模板的相关内容，①至⑦分别代表所述通知消息的消息类型、 银行名、银行***、交易时间、消费状态、金额、所述通知消息的来源和所述正在展示 的同类消息的来源。在一个实施例中，针对所述合并消息，还可以将所述通知消息的来 源所对应的文字与所述通知消息创建关联，以及将所述正在展示的同类消息的来源所对 应的文字与所述正在展示的同类消息创建关联；当从所述合并消息中，接收到用户点击 所述通知消息的来源所对应的文字所产生的信号时，展示所述通知消息的详细内容，及 当从所述合并消息中，接收到用户点击所述正在展示的同类消息的来源所对应的文字所 产生的信号时，展示该同类消息的详细内容。

在本申请的一个实施例中，当所述消息管理方法应用于通知管理器时，可以利用通 知管理器将所述通知消息和所述正在展示的同类消息进行合并处理获得合并消息，以及从通 知栏删除所述通知消息及/或删除正在展示的同类消息，并利用通知管理器模拟一个应用程 序向通知管理器(即自身)推送合并消息，以及在通知栏展示所述合并消息。

在本申请的一个实施例中，当所述消息管理方法应用于应用程序层以一个应用程序 来实现时，所述应用程序将所述通知消息和所述正在展示的同类消息进行合并处理获得合并 消息，并利用NotificationListenerService的cancelNotification方法，从通知栏将所述通知消息 和所述正在展示的同类消息删除，并向通知管理器推送合并消息，由此利用通知管理器在通 知栏显示所述合并消息。

为清楚说明本申请的所述第一实施例，请参图4A-图4E所述，具体以交易D1发生后， 电子设备先后收到来源不同的属于交易D1的通知消息M1、M1’、M1”，对消息M1、M1’、M1”进行合并处理为例进行说明。

假设交易D1发生后，电子设备接收到来源于招商银行App的消息M1，则对消息 M1的关键属性如消息来源、消息类型、银行名、银行***、交易时间、消费状态、金额等 进行解析。假设解析得出所述消息M1的消息类型为消费类消息，根据所述消息M1的关 键属性判断得出所述消息M1属于交易D1，且确定尚未存在所述交易D1的消息历史记 录(也即所述消息M1为首次收到的属于所述交易D1的消费类消息)时，如图4A所示， 电子设备为所述交易D1创建消息历史记录L1，并在通知栏展示所述消息M1并同时输 出提示信号(例如，播放通知声S1)以提示用户查阅消息M1。

假设电子设备随后又收到交易D1产生的新消息M1’,同样地，电子设备对新消息M1’ 的关键属性进行解析，若解析得出消息M1’的消息类型为消费类消息，根据消息M1’的关键属性判断得出消息M1’属于交易D1，且确定已经存在交易D1的消息历史记录(也 即消息M1’不是首次收到的属于交易D1的消费类消息)时，判断所述通知栏是否正在展 示与消息M1’的属性相同的消息，即同类消息。若确定所述通知栏正在展示同类消息M1， 如图4B所示，电子设备在通知栏展示消息M1’并同时播放通知声S2。然后，如图4C所 示，将所述消息M1’和M1进行合并获得合并消息N1,在通知栏展示合并消息N1及播放 通知声S3以提示用户阅读所述合并消息N1。另外，如图4C所示，在一个实施例中，当 从所述合并消息N1中，接收到用户点击文字“招商银行”的信号时，可以展示所述消息 M1的内容。当从所述合并消息中，接收到用户点击文字“支付宝”的信号时，展示所述消 息M1’的内容。

假设电子设备随后又收到交易D1产生的新消息M1”。同样地，电子设备对所述新消息M1”的关键属性进行解析，若解析得出所述消息M1”的消息类型为消费类消息，根 据所述消息M1”的关键属性判断得出所述消息M1”属于交易D1，且确定已经存在交易 D1的消息历史记录(也即所述消息M1”不是首次收到的属于所述交易D1的消费类消息) 时，判断所述通知栏是否正在展示同类消息。若判断得出所述通知栏正在展示与所述消 息M1”的属性相同的消息即在展示同类消息N1时，如图4D所示，展示所述消息M1” 并播放通知声S4。然后将所述消息M1”和N1进行合并获得合并消息N1’,如图4E所示， 在通知栏将所述消息M1”和N1清除并在通知栏展示所述合并消息N1’及播放通知声S5 以提示用户阅读合并消息N1’。

为清楚说明本申请的第一实施例，请再参图5A-图5D所述，具体以交易D1发生后，电 子设备先后收到来源不同的属于交易D1的通知消息M1、M1’，在收到消息M1和M1’的 期间还收到非交易D1产生的消息M2,对消息M1、M1’进行合并处理为例进行说明。

假设电子设备收到属于交易D1的消费类消息M1后，在判断得出尚未存在交易D1的消 息历史记录，为交易D1创建消息历史记录L1后，在通知栏显示所述消息M1并播放通知声S1如图5A所示。

假设电子设备随后收到非交易D1所产生的消息M2，并在通知栏展示所述消息M2并播 放通知声S2如图5B所示；其后，电子设备收到属于交易D1的消费类消息M1’，在判断得出所述消息M1’与正在展示的消息M1为相同的消息时，在通知栏展示所述消费类消息M1’并播放通知声S3如图5C所示，电子设备还将消息M1、M1’进行合并获得合并消息N1； 并将消息M1、M1’从通知栏清除，以及在通知栏中所述消息M2的下方显示所述合并消 息N1如图5D所示。

在本申请的第二实施例中，若确定正在展示所述同类消息时，电子设备不在通知栏 展示所述通知消息；电子设备根据所述关键属性，合并所述通知消息和所述正在展示的同 类消息，获得所述合并消息；从通知栏中删除所述同类消息并在通知栏中展示所述合并消息。 电子设备还可以在展示所述合并消息时播放提示音效。同样地，电子设备还将所述合并消 息存储到所述交易的消息历史记录内。

需要说明的是，本申请的第二实施例与所述第一实施例的区别在于，电子设备不在 通知栏展示所述通知消息。

在本申请的第三实施例中，若确定正在展示所述同类消息时，电子设备在通知栏展 示所述通知消息；合并所述通知消息和所述正在展示的同类消息，获得所述合并消息；在 通知栏展示所述合并消息，并将所述通知消息和所述正在展示的同类消息折叠展示在所述合 并消息的下方。同样地，电子设备可以在展示所述通知消息时播放提示音效；以及在通知 栏展示所述合并消息时播放提示音效。电子设备还将所述合并消息存储到所述交易的消息历 史记录内。

在本申请的一个实施例中，电子设备还响应用户在所述合并消息上的向左或向右的滑动 操作，删除所述合并消息或删除所述折叠展示的消息。即用户只需在所述合并消息向左或者 向右滑动即可删除合并消息和折叠展示的消息。

为清楚说明本申请的所述第三实施例，请参图6A-图6E所述，具体以交易D1发生后， 电子设备先后收到来源不同的且属于交易D1的通知消息M1、M1’、M1”，对消息M1、 M1’、M1”进行合并处理获得合并消息N1并把M1、M1’、M1”收起到N1下为例进行说 明。

假设交易D1发生后，接收到来源于招商银行App的消息M1，电子设备则对消息 M1的关键属性如消息来源、消息类型、银行名、银行***、交易时间、消费状态、金额进 行解析。假设解析得出所述消息M1的消息类型为消费类消息，根据所述消息M1的关键 属性判断得出所述消息M1属于交易D1，且确定尚未存在所述交易D1的消息历史记录 (也即所述消息M1为首次收到的属于所述交易D1的消费类消息)时，电子设备则为所 述交易D1创建消息历史记录L1，并在通知栏展示所述消息M1并播放通知声S1以提示 用户查阅消息M1如图6A所示。

假设电子设备随后又收到交易D1产生的新消息M1’,同样地，电子设备对所述新消息M1’的关键属性进行解析，若解析得出所述消息M1’的消息类型为消费类消息，根据 所述消息M1’的关键属性判断得出所述消息M1’属于交易D1，且确定已经存在交易D1 的消息历史记录(也即所述消息M1’不是首次收到的属于所述交易D1的消费类消息)时， 判断所述通知栏是否正在展示与所述消息M1’的属性相同的消息即同类消息。若判断得 出所述通知栏正在展示同类消息M1时，展示所述消息M1’并播放通知声S2如图6B所 示。然后将所述消息M1’和M1进行合并获得合并消息N1,在通知栏展示所述合并消息 N1并将所述消息M1’和M1折叠展示在所述合并消息N1的下方。电子设备还可以播放通 知声S3以提示用户阅读所述合并消息N1如图6C所示。

假设电子设备随后又收到交易D1产生的新消息M1”。同样地，电子设备对所述新消息M1”的关键属性进行解析，若解析得出所述消息M1”的消息类型为消费类消息，根 据所述消息M1”的关键属性判断得出所述消息M1”属于交易D1，且确定已经存在交易 D1的消息历史记录(也即所述消息M1”不是首次收到的属于所述交易D1的消费类消息) 时，判断所述通知栏是否`正在展示与所述消息M1”属性相同的消息即同类消息。若判断 得出所述通知栏正在展示同类消息N1时，在通知栏展示折叠消息M1’和M1的下方展示 所述消息M1”并播放通知声S4如图6D所示。然后将所述消息M1”和N1进行合并获得 合并消息N1’,然后在通知栏删除所述合并消息N1，并展示所述合并消息N1’，以及将所 述消息M1”、M1’和M1折叠展示在所述合并消息N1’的下方。电子设备还可以播放通知 声S5以提示用户阅读合并消息N1’如图6E所示。

在本申请的第四实施例中，若确定正在展示所述同类消息时，电子设备不在通知栏 展示所述通知消息；电子设备合并所述通知消息和所述正在展示的同类消息，获得所述合 并消息；在通知栏展示所述合并消息，并将所述通知消息和所述正在展示的同类消息折叠展 示在所述合并消息的下方。同样地，电子设备可以在通知栏展示所述合并消息的同时播放 提示音效。电子设备还将所述合并消息存储到所述交易的消息历史记录内。

需要说明的是，在本申请的第四实施例与第三实施例的区别在于，电子设备不在通 知栏显示所述通知消息。

在本申请的第五实施例中，若确定正在展示所述同类消息时，电子设备从所述通知 消息和所述正在展示的同类消息中确定一个保留消息(即需要保留下来的消息)，并从通 知栏中删除(划掉)其他消息，所述其他消息是指所述通知消息和所述正在展示的同类消 息中，除所述保留消息之外的消息。

在本申请的一个实施例中，所述保留消息可以为所述通知消息和所述正在展示的同类 消息中的任意一个消息。在本申请的一个实施例中，所述保留消息可以为所述通知消息 和所述正在展示的同类消息中，最早收到的一个消息或者最晚收到的一个消息。在本申请 的一个实施例中，所述保留消息可以为所述通知消息和所述正在展示的同类消息中，源自 所设置的消息来源的消息。在本申请的一个实施例中，可以提供一个设置界面，响应用户操作，设置一个消息来源。举例而言，可以在设置界面将消息来源例如支付宝、银行、 短信作为选项供用户选择，若用户设置了银行为消息来源，则在确定了正在展示所述同 类消息时，将所述通知消息和所述正在展示的同类消息中，源自银行的消息作为保留消息。

为清楚说明本申请的第五实施例，参图7A-图7C所述，具体以交易D1发生后，电子设备先后收到来源不同属于交易D1的消息M1、M1’、M1”，只保留最早收到的一个消息 M1，不显示其他消息为例进行说明。

假设交易D1发生后，电子设备接收到来源于招商银行App的消息M1，则对消息 M1的关键属性如消息来源、消息类型、银行名、银行***、交易时间、消费状态、金额进 行解析。假设解析得出所述消息M1的消息类型为消费类消息，根据所述消息M1的关键 属性判断得出所述消息M1属于交易D1，且确定尚未存在所述交易D1的消息历史记录 (也即所述消息M1为首次收到的属于所述交易D1的消费类消息)时，电子设备则为所 述交易D1创建消息历史记录L1，并在通知栏展示所述消息M1并播放通知声S1以提示 用户查阅消息M1如图7A所示。

假设电子设备随后又收到交易D1产生的来源于支付宝App的新消息M1’,同样地，电子设备对所述新消息M1’的关键属性进行解析，若解析得出所述消息M1’的消息类型 为消费类消息，根据所述消息M1’的关键属性判断得出所述消息M1’属于交易D1，且确 定已经存在交易D1的消息历史记录(也即所述消息M1’不是首次收到的属于所述交易 D1的消费类消息)时，判断所述通知栏是否正在展示同类消息。若判断得出所述通知栏 正在展示与消息M1’的属性相同的消息即同类消息M1时，保留最早收到的同类消息M1, 不在通知栏展示所述消息M1’也不播放提示音效如图7B所示。

假设电子设备随后又收到交易D1产生的来源于招商银行信用App的新消息M1”。同样地，电子设备对所述新消息M1”的关键属性进行解析，若解析得出所述消息M1” 的消息类型为消费类消息，根据所述消息M1”的关键属性判断得出所述消息M1”属于交 易D1，且确定已经存在交易D1的消息历史记录(也即所述消息M1”不是首次收到的属 于所述交易D1的消费类消息)时，判断所述通知栏是否正在展示同类消息。若判断得出 所述通知栏正在展示同类消息M1时，保留最早收到的消息即消息M1,不在通知栏展示 所述消息M1”也不播放提示音效如图7C所示。

在本申请的第六实施例中，若确定正在展示所述同类消息时，电子设备展示所述通 知消息；从所述通知消息和所述正在展示的同类消息中确定一个保留消息；以及将其他消息的阅读状态标记为已读状态，并从通知栏删除所述其他消息。所述其他消息是指 所述通知消息和所述正在展示的同类消息中，除所述保留消息之外的消息。

同样地，在本申请的一个实施例中，所述保留消息可以为所述通知消息和所述正在 展示的同类消息中的任意一个消息。在本申请的一个实施例中，所述保留消息可以为所述通知消息和所述正在展示的同类消息中，最早收到的一个消息或者最晚收到的一个消息。在本申请的一个实施例中，所述保留消息可以为所述通知消息和所述正在展示的同 类消息中，源自所设置的消息来源的消息。在本申请的一个实施例中，可以提供一个设 置界面，响应用户操作设置一个消息来源。举例而言，可以在设置界面将消息来源例如 支付宝、银行、短信作为选项供用户选择，若用户设置了银行为消息来源，则在确定了 正在展示所述同类消息时，将所述通知消息和所述正在展示的同类消息中，源自银行的 消息作为保留消息。

在本申请的一个实施例中，所述将其他消息的阅读状态标记为已读状态的方法包括， 但不限于：获取其他消息分别对应的已读按钮，所述已读按钮用于将其他消息的阅读状 态标为已读状态，点击已读按钮将其他消息的阅读状态标记为已读状态；若无法获取到其他消息对应的已读按钮，则获取所述其他消息的目标地址并跳转到所述目标地址对应的目标页；及销毁所述目标页。该目标页加载后对用户不可见。

为清楚说明本申请的第六实施例，参图8A-图8C所述，具体以交易D1发生后，电子设备先后收到来源不同属于交易D1的消息M1、M1’、M1”，以确定最早收到的消息M1 为保留下来的消息，并将其他消息的阅读状态标记为已读为例进行说明。

假设交易D1发生后，电子设备首次收到属于所述交易D1的消费类消息M1，电子 设备则在通知栏展示所述消息M1并播放通知声S1以提示用户查阅消息M1如图8A所 示。

假设电子设备随后又收到属于交易D1的新消息M1’,若判断得出所述通知栏正在展 示与消息M1’属性相同的消息即同类消息M1时，电子设备展示所述消息M1’如图8B 所示；若确定最早收到的同类消息M1作为保留下来的消息时，电子设备将所述消息M1’ 的阅读状态标记为已读状态，并从通知栏删除所述消息M1’如图8C所示。

S20，若确定没有展示同类消息，在通知栏展示所述通知消息或者不展示所述通知消 息。

在本申请的一个实施例中，若所述通知消息的类型不属于所述消费类的消息时(即 从S13执行到S20时)，电子设备可以在通知栏展示所述通知消息，或者不展示所述通知消息。电子设备还可以在展示所述通知消息的同时播放预设的提示音效。

在本申请的一个实施例中，若所述通知消息的类型属于所述消费类的消息，且不属 于所述交易时(即从S15执行到S20时)，电子设备可以在通知栏展示所述通知消息， 或者不展示所述通知消息。同样地，电子设备还可以在展示所述通知消息的同时播放预 设的提示音效。

在本申请的一个实施例中，若所述通知消息的类型属于所述消费类的消息，且属于 所述交易，且尚不存在所述交易的消息历史记录时，电子设备于创建交易D1的消息历史记录后(即从S17执行到S20时)，在通知栏展示所述通知消息。同样地，电子设备还 可以在展示所述通知消息的同时播放提示预设的提示音效。

举例而言，假设交易D1发生后，电子设备收到属于所述交易D1的消费类消息M1，电子设备在确定尚未存在所述交易D1的消息历史记录时，于创建交易D1的消息历史记 录后在通知栏展示所述消息M1并播放通知声S1以提示用户查阅消息M1如图9A所示。

在本申请的一个实施例中，若所述通知消息的类型属于所述消费类的消息，且属于 所述交易，且存在所述交易的消息历史记录，且所述通知栏没有展示所述同类消息时(即 从S18执行到S20时)，电子设备在通知栏展示所述通知消息，并播放提示音效。

举例而言，假设继图9A所示的电子设备在通知栏展示了消息M1后，电子设备响应用户的操作从通知栏删除了消息M1如图9B所示，随后电子设备又收到属于交易D1的 消费类消息M1’，则若收到所述消息M1’时，由于此时通知栏未展示与所述消息M1’相 同的消息，电子设备则在通知栏展示所述消息M1’并播放提示音效S2如图9C所示。

在本申请的另一个实施例中，若所述通知消息的类型属于所述消费类的消息，且属 于所述交易，且存在所述交易的消息历史记录，且所述通知栏没有展示所述同类消息时(即从S18执行到S20时)，电子设备根据最近一次对所述同类消息的处理方式处理所 述通知消息。对所述同类消息的处理方式包括，但不限于，不显示所述同类消息、将所 述同类消息的阅读状态修改为已读、将所述相同消息从通知栏删除。由此，当所述通知 消息到达时电子设备可以直接不显示、删除或者自动标记为已读。

为清楚说明本申请，请参图10A-图10C所述，具体以交易D1发生后，电子设备收到属于交易D1的消费类消息M1后用户清除掉消息M1，继续收到消息M1’为例说明。

假设交易D1发生后，电子设备首次收到属于所述交易D1的消费类消息M1，电子 设备在通知栏展示所述消息M1并播放通知声S1以提示用户查阅消息M1如图10A所示。

假设电子设备随后响应用户的操作从通知栏删除了消息M1如图10B所示即不显示消息M1；随后电子设备又收到属于交易D1且与所述消息M1相同的新消息M1’，则根 据对前一条相同消息M1的处理，电子设备不在通知栏显示所述消息M1’如图10C。

为清楚说明本申请，请再参图11A-图11E所示，具体以交易D1发生后，电子设备先后 收到属于交易D1的消费类消息M1、M1’，并将消息M1、M1’合并为消息N1，响应用户的 操作从通知栏删除了消息N1后继续收到消息M1”为例说明。

假设交易D1发生后，电子设备首次收到属于所述交易D1的来源于招商银行App 的消费类消息M1，电子设备在通知栏展示所述消息M1并播放通知声S1以提示用户查 阅消息M1如图11A所示。

假设电子设备随后收到属于所述交易D1的源于支付宝App的且与消息M1相同的消费类消息M1’，电子设备在通知栏展示所述消息M1’并播放通知声S2以提示用户查阅 消息M1’如图11B所示。电子设备随后将消息M1、M1’合并为合并消息N1，从通知栏删 除所述消息M1、M1’，并在通知栏展示所述合并消息N1并播放通知声S3以提示用户查阅 合并消息N1如图11C所示。

如图11D所示，假设电子设备随后响应用户的操作从通知栏删除了合并消息N1；随后电子设备又收到了属于交易D1的来源于***的消费类消息M1”，如图11E所示， 电子设备根据对前一条相同消息N1的处理，不在通知栏显示所述消息M1”。

另外需要说明的是，在本申请的实施例中，为避免根据之前定义的因子即关键属性 将来自同一消息来源的两个或多个消费类消息误判成同一笔交易，电子设备可以按照收 到消息的先后顺序对预设时间内来自同一消息来源的两个或多个消费类消息分别进行标 记，然后针对每个消息来源的多个消息，可以根据在每个消息来源中的序号标记来与不同消 息来源中序号标记相同的消息进行分别对齐，以区分多笔先后发生的不同交易(如：招商 银行App的序号标记为01、02、03号消息，分别和支付宝App的序号标记为01、02、03号消息进行合并，其中，同一个消息来源的01、02、03消息的各个因子有可能均相同，按照之前的设计这几个消息会被误判成同一个交易。)；然后可以根据标记基于预先创建的消息模板对属于同笔交易(如：招商银行App的序号标记为01号消息与支付宝App的序号标记 为01号消息根据双方的各关键因素和序号标记被认为是同笔交易)但是来自不同消息来源的消费类消息进行合并处理。

举例而言，同一银行***在短时间内例如1分钟内发生两笔或多笔交易金额相同的 交易，电子设备则会在短时间内先后收到源自同一消息来源的两条或多条消费类消息，电子设备则可以对源自同一消息来源的两条或多条消费类消息中的每一条消息进行标记，以区分属于不同交易的消息；然后再根据标记基于预先创建的消息模板对属于同笔 交易但来自不同消息来源的消费类消息进行合并处理。

为清楚说明本发明，请参图12A-12F所示，假设时间点09:59发生交易D1，随后电子设备首次收到属于交易D1来源于招商银行App的消费类消息M1，电子设备则可以对 消息M1进行标记例如利用标记09:59-01标记消息M1以表示消息M1属于交易D1，并 在通知栏展示所述消息M1及播放通知声S1以提示用户查阅消息M1如图12A所示。假 设短时间内例如1分钟之内电子设备又收到属于交易D2来源于招商银行App的消费类 消息M2，电子设备则可以对消息M2进行标记例如利用标记09:59-02标记消息M2以表 示消息M2属于交易D2，并在通知栏展示所述消息M2并播放通知声S2以提示用户查 阅消息M2如图12B所示。随后电子设备收到属于交易D1来源于支付宝平台的新消息 M1’，电子设备则可以对消息M1’进行标记例如标记为09:59-01以表示该消息M2属于交 易D1，并在通知栏展示所述消息M1’并播放通知声S1’以提示用户查阅消息M1’如图12C 所示。由于收到新消息M1’时，电子设备正在展示属于交易D1的同类消息M1，电子设 备根据标记，基于预先创建的消息模板将属于同笔交易D1的来自不同消息来源的消息 M1和M1’合并获得合并消息N1，并播放通知声SN1以提示用户查阅消息N1如图12D 所示。假设随后电子设备又收到属于交易D2来源于支付宝平台的消费类消息M2’，电子 设备则可以对消息M2’以同样的标记09:59-02标记消息M2’以表示消息M2’属于交易D2， 并在通知栏展示所述消息M2’并播放通知声S2’以提示用户查阅消息M2’如图12E所示。 由于收到新消息M2’时，电子设备正在展示属于交易D2的同类消息M2，电子设备根据 标记，基于预先创建的消息模板将属于同笔交易D2的来自不同消息来源的消息M2和 M2’合并获得合并消息N2，并播放通知声SN2以提示用户查阅消息N2如图12F所示。

进一步地，在本申请的一个实施例中，电子设备还可以对预设时间内(短时间内例如1分钟之内)的属于不同交易但是消费状态相同(交易金额可以相同或者不同)的消 息进行合并处理，包括：基于所述不同交易涉及的交易金额统计总交易金额；及基于消 息模板以及总交易金额生成合并消息。

举例而言，请参阅图12G所示，电子设备当前展示了属于交易D1的合并消息N1 和属于交易D2的合并消息N2，消息N1和N2的消费类状态相同都为支出，交易时间都 为09:59，电子设备则对消息N1、N2涉及的交易金额进行统计获得总交易金额为支出0.02 元；电子设备基于消息模板及所统计的总交易金额生成合并消息CN1；从通知栏删除消 息N1、N2，并在通知栏展示合并消息CN1以及播放通知声SCN1以提示用户查阅消息 CN1。

进一步地，在本申请的一个实施例中，电子设备也可以对短时间内的属于不同交易、 消费状态不相同(交易金额可以相同或者不同)的消息进行合并处理，包括：基于不同交易涉及的交易金额统计获得总交易金额；及基于消息模板以及总交易金额生成合并消息。

举例而言，请参阅图12I所示，电子设备当前展示了属于交易D1的合并消息N1和属于交易D2的合并消息N2，消息N1的消费状态为支出，消息N2的消费状态为收入， 消息N1和N2所包括的交易时间都为09:59，电子设备则对消息N1、N2涉及的交易金 额进行统计获得总交易金额为支出0.99元；电子设备基于合并消息模板及所统计的总交 易金额生成合并消息CN1；从通知栏删除消息N1、N2，并在通知栏展示合并消息CN1 以及播放通知声SCN1以提示用户查阅消息CN1如图12J所示。

图13为本申请实施例提供的一种消息管理方法的流程图，主要从所述消息管理方法应 用于电子设备的应用程序框架层的通知管理器为例进行说明。

S121，通知管理器预设一个通知频道，命名为transaction(交易)，并对通知频道预 设若干个字段。

S122，推送消费类消息的应用程序将消费类消息的内容按照所述若干字段进行填充， 及按照所述通知频道推送消费类消息到通知管理器。

S123,通知管理器获取到先后两个消费类消息，并解析各个字段的内容。

S124，通知管理器判断两个消费类消息的内容一致时，通知管理器隐藏或删除这两个消 费类消息，并模拟一个应用程序向通知管理器推送一条新消息。

图14为本申请实施例提供的一种消息管理方法的流程图，主要从所述消息管理方法应 用于电子设备的应用程序层的应用程序为例进行说明。

S131，应用程序利用通知管理器里的NotificationListenerService获取通知栏中的所有通 知消息的标题及内容(Notification.EXTRA_TITLE、Notification.EXTRA_TEXT)。

S132，应用程序利用NLP技术，从所获取的通知消息的标题及内容抽取关键属性如银 行、***、交易时间、消费状态、金额等实体。

S133,应用程序对先后到达的两条通知消息的各个实体进行比较，以判断两条通知消息 是否一样。

S134,应用程序判断两条通知消息一样时，利用NotificationListenerService的cancelNotification方法，可删除这两条通知消息，并向通知管理器推送一条新消息，新消息由 这两条通知消息的关键属性组装而成。

另外需要说明的是，以上实施方式是以对因交易产生的来源不同的消费类消息为例进行 说明。本申请提供的消息管理方法还可用于对源自不同平台的航班行程类消息的管理。图15 为本申请实施例提供的另一消息管理方法的流程图，用于对源自不同平台的航班行程类消息 进行管理时。同样地，图15所示的消息管理方法也可以应用于电子设备的应用程序框架 层(Application Framework)的通知管理器中(即以下S141-S147可由通知管理器来执行)。 所述消息管理方法也可以应用于电子设备的应用程序层，作为一个应用程序实现(即以 下S141-S147可由所述应用程序来执行)。

具体地，消息管理方法包括：

S141，接收通知消息，并解析所述通知消息的关键属性，所述关键属性包括消息类型、 类型、来源、航司、班次号、发生时间、班次状态、地址。

S142，确定所述通知消息的消息类型是否为行程类消息。若确定所述通知消息的消 息类型为行程类消息时，执行S143；若确定所述通知消息的消息类型不是行程类消息时， 执行S147。

S143，若确定所述通知消息的消息类型为行程类消息时，确定是否存在所述行程类消 息的通知记录。若不存在所述行程类消息的通知记录时，执行S144；若存在所述行程类消息 的通知记录时，执行S145。

S144，若不存在所述行程类消息的通知记录时，创建所述行程类消息的通知记录，将 所述通知消息存储到所述通知记录。

S145，若存在所述行程类消息的通知记录时，确定是否正在展示与所述通知消息属性 相同的消息(即同类消息)。若正在展示同类消息时，执行S146；若没有展示同类消息时， 执行S147。

S146，若正在展示同类消息时，对所述通知消息和所述同类消息进行合并处理或者删减 或者更新阅读状态；以及将所述通知消息存储到所述通知记录。

S147，展示所述通知消息。

举例而言，参阅图16A所示，电子设备接收到源自航旅纵横App和海南航空App的相同的行程类消息时，则将所述航旅纵横App和海南航空App发送的行程类消息进行合并获得合并消息；如图16B所示，从通知栏删除所述航旅纵横App和海南航空App分别发送 的行程类消息，并显示合并消息。

图17是本申请实施例提供的电子设备100的结构示意图。电子设备100可以包括处理器110，外部存储器接口120，内部存储器121，通用串行总线(universal serial bus，USB) 接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信 模块150，无线通信模块160，音频模块170，扬声器170A，受话器170B，麦克风170C， 耳机接口170D，传感器模块180，按键190，马达191，指示器192，摄像头193，显示 屏194，以及用户标识模块(subscriber identification module，SIM)卡接口195等。其中传 感器模块180可以包括压力传感器180A，陀螺仪传感器180B，气压传感器180C，磁传 感器180D，加速度传感器180E，距离传感器180F，接近光传感器180G，指纹传感器 180H，温度传感器180J，触摸传感器180K，环境光传感器180L，骨传导传感器180M 等。

可以理解的是，本申请实施例示意的结构并不构成对电子设备100的具体限定。在本申请另一些实施例中，电子设备100可以包括比图示更多或更少的部件，或者组合某 些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软 件和硬件的组合实现。

处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processingunit，GPU)， 图像信号处理器(image signal processor，ISP)，控制器，存储器，视频编解码器，数字信 号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个 或多个处理器中。

其中，控制器可以是电子设备100的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。

处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。所述存储器可以保存处理器110刚用过或循环使用 的指令或数据。如果处理器110需要再次使用所述指令或数据，可从所述存储器中直接 调用。避免了重复存取，减少了处理器110的等待时间，因而提高了***的效率。

在一些实施例中，处理器110可以包括一个或多个接口。接口可以包括集成电路(inter-integrated circuit，I2C)接口，集成电路内置音频(inter-integrated circuitsound，I2S) 接口，脉冲编码调制(pulse code modulation，PCM)接口，通用异步收发传输器(universal asynchronous receiver/transmitter，UART)接口，移动产业处理器接口(mobile industry processor interface，MIPI)，通用输入输出(general-purposeinput/output，GPIO)接口，用 户标识模块(subscriber identity module，SIM)接口，和/或通用串行总线(universal serial bus， USB)接口等。

I2C接口是一种双向同步串行总线，包括一根串行数据线(serial data line，SDA)和一 根串行时钟线(derail clock line，SCL)。在一些实施例中，处理器110可以包含多组I2C 总线。处理器110可以通过不同的I2C总线接口分别耦合触摸传感器180K，充电器，闪 光灯，摄像头193等。例如：处理器110可以通过I2C接口耦合触摸传感器180K，使处 理器110与触摸传感器180K通过I2C总线接口通信，实现电子设备100的触摸功能。

I2S接口可以用于音频通信。在一些实施例中，处理器110可以包含多组I2S总线。处理器110可以通过I2S总线与音频模块170耦合，实现处理器110与音频模块170之 间的通信。在一些实施例中，音频模块170可以通过I2S接口向无线通信模块160传递 音频信号，实现通过蓝牙耳机接听电话的功能。

PCM接口也可以用于音频通信，将模拟信号抽样，量化和编码。在一些实施例中，音频模块170与无线通信模块160可以通过PCM总线接口耦合。在一些实施例中，音频 模块170也可以通过PCM接口向无线通信模块160传递音频信号，实现通过蓝牙耳机接 听电话的功能。所述I2S接口和所述PCM接口都可以用于音频通信。

UART接口是一种通用串行数据总线，用于异步通信。所述总线可以为双向通信总线。它将要传输的数据在串行通信与并行通信之间转换。在一些实施例中，UART接口 通常被用于连接处理器110与无线通信模块160。例如：处理器110通过UART接口与 无线通信模块160中的蓝牙模块通信，实现蓝牙功能。在一些实施例中，音频模块170 可以通过UART接口向无线通信模块160传递音频信号，实现通过蓝牙耳机播放音乐的 功能。

MIPI接口可以被用于连接处理器110与显示屏194，摄像头193等***器件。MIPI接口包括摄像头串行接口(camera serial interface，CSI)，显示屏串行接口(displayserial interface，DSI)等。在一些实施例中，处理器110和摄像头193通过CSI接口通信，实现 电子设备100的拍摄功能。处理器110和显示屏194通过DSI接口通信，实现电子设备 100的显示功能。

GPIO接口可以通过软件配置。GPIO接口可以被配置为控制信号，也可被配置为数据信号。在一些实施例中，GPIO接口可以用于连接处理器110与摄像头193，显示屏194， 无线通信模块160，音频模块170，传感器模块180等。GPIO接口还可以被配置为I2C 接口，I2S接口，UART接口，MIPI接口等。

USB接口130是符合USB标准规范的接口，具体可以是Mini USB接口，Micro USB 接口，USB Type C接口等。USB接口130可以用于连接充电器为电子设备100充电，也 可以用于电子设备100与***设备之间传输数据。也可以用于连接耳机，通过耳机播放 音频。所述接口还可以用于连接其他电子设备，例如AR设备等。

可以理解的是，本申请实施例示意的各模块间的接口连接关系，只是示意性说明，并不构成对电子设备100的结构限定。在本申请另一些实施例中，电子设备100也可以 采用上述实施例中不同的接口连接方式，或多种接口连接方式的组合。

充电管理模块140用于从充电器接收充电输入。其中，充电器可以是无线充电器，也可以是有线充电器。在一些有线充电的实施例中，充电管理模块140可以通过USB接 口130接收有线充电器的充电输入。在一些无线充电的实施例中，充电管理模块140可 以通过电子设备100的无线充电线圈接收无线充电输入。充电管理模块140为电池142 充电的同时，还可以通过电源管理模块141为电子设备供电。

电源管理模块141用于连接电池142，充电管理模块140与处理器110。电源管理模块141接收电池142和/或充电管理模块140的输入，为处理器110，内部存储器121， 外部存储器，显示屏194，摄像头193，和无线通信模块160等供电。电源管理模块141 还可以用于监测电池容量，电池循环次数，电池健康状态(漏电，阻抗)等参数。在其他一 些实施例中，电源管理模块141也可以设置于处理器110中。在另一些实施例中，电源 管理模块141和充电管理模块140也可以设置于同一个器件中。

电子设备100的无线通信功能可以通过天线1，天线2，移动通信模块150，无线通信模块160，调制解调处理器以及基带处理器等实现。

天线1和天线2用于发射和接收电磁波信号。电子设备100中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。例如：可以将 天线1复用为无线局域网的分集天线。在另外一些实施例中，天线可以和调谐开关结合 使用。

移动通信模块150可以提供应用在电子设备100上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块150可以包括至少一个滤波器，开关，功率放大器，低噪声 放大器(low noise amplifier，LNA)等。移动通信模块150可以由天线1接收电磁波，并对 接收的电磁波进行滤波，放大等处理，传送至调制解调处理器进行解调。移动通信模块 150还可以对经调制解调处理器调制后的信号放大，经天线1转为电磁波辐射出去。在 一些实施例中，移动通信模块150的至少部分功能模块可以被设置于处理器110中。在 一些实施例中，移动通信模块150的至少部分功能模块可以与处理器110的至少部分模 块被设置在同一个器件中。

调制解调处理器可以包括调制器和解调器。其中，调制器用于将待发送的低频基带 信号调制成中高频信号。解调器用于将接收的电磁波信号解调为低频基带信号。随后解调器将解调得到的低频基带信号传送至基带处理器处理。低频基带信号经基带处理器处理后，被传递给应用处理器。应用处理器通过音频设备(不限于扬声器170A，受话器170B等)输出声音信号，或通过显示屏194显示图像或视频。在一些实施例中，调制解调处理 器可以是独立的器件。在另一些实施例中，调制解调处理器可以独立于处理器110，与 移动通信模块150或其他功能模块设置在同一个器件中。

无线通信模块160可以提供应用在电子设备100上的包括无线局域网(wirelesslocal area networks，WLAN)(如无线保真(wireless fidelity，Wi-Fi)网络)，蓝牙(bluetooth，BT)， 全球导航卫星***(global navigation satellite system，GNSS)，调频(frequency modulation， FM)，近距离无线通信技术(near field communication，NFC)，红外技术(infrared，IR)等无 线通信的解决方案。无线通信模块160可以是集成至少一个通信处理模块的一个或多个 器件。无线通信模块160经由天线2接收电磁波，将电磁波信号调频以及滤波处理，将 处理后的信号发送到处理器110。无线通信模块160还可以从处理器110接收待发送的 信号，对其进行调频，放大，经天线2转为电磁波辐射出去。

在一些实施例中，电子设备100的天线1和移动通信模块150耦合，天线2和无线 通信模块160耦合，使得电子设备100可以通过无线通信技术与网络以及其他设备通信。 所述无线通信技术可以包括全球移动通讯***(global system for mobile communications，GSM)，通用分组无线服务(general packet radio service，GPRS)，码分多址接入(codedivision multiple access，CDMA)，宽带码分多址(wideband code division multipleaccess，WCDMA)， 时分码分多址(time-division code division multiple access，TD-SCDMA)，长期演进(long term evolution，LTE)，第五代无线通信***(5G，the 5thGeneration of wireless communication system)，BT，GNSS，WLAN，NFC，FM，和/或IR技术等。所述GNSS 可以包括全球卫星定位***(global positioning system，GPS)，全球导航卫星***(global navigation satellite system，GLONASS)，北斗卫星导航***(beidounavigation satellite system，BDS)，准天顶卫星***(quasi-zenith satellitesystem，QZSS)和/或星基增强*** (satellite based augmentation systems，SBAS)。

电子设备100通过GPU，显示屏194，以及应用处理器等实现显示功能。GPU为图 像处理的微处理器，连接显示屏194和应用处理器。GPU用于执行数学和几何计算，用 于图形渲染。处理器110可包括一个或多个GPU，其执行程序指令以生成或改变显示信 息。

显示屏194用于显示图像，视频等。显示屏194包括显示面板。显示面板可以采用液晶显示屏(liquid crystal display，LCD)，有机发光二极管(organic light-emittingdiode， OLED)，有源矩阵有机发光二极体或主动矩阵有机发光二极体(active-matrixorganic light emitting diode的，AMOLED)，柔性发光二极管(flex light-emittingdiode，FLED)，Miniled， MicroLed，Micro-oLed，量子点发光二极管(quantum dot lightemitting diodes，QLED)等。 在一些实施例中，电子设备100可以包括1个或N个显示屏194，N为大于1的正整数。

电子设备100可以通过ISP，摄像头193，视频编解码器，GPU，显示屏194以及应 用处理器等实现拍摄功能。

ISP用于处理摄像头193反馈的数据。例如，拍照时，打开快门，光线通过镜头被传递到摄像头感光元件上，光信号转换为电信号，摄像头感光元件将所述电信号传递给ISP处理，转化为肉眼可见的图像。ISP还可以对图像的噪点，亮度，肤色进行算法优化。ISP 还可以对拍摄场景的曝光，色温等参数优化。在一些实施例中，ISP可以设置在摄像头 193中。

摄像头193用于捕获静态图像或视频。物体通过镜头生成光学图像投射到感光元件。 感光元件可以是电荷耦合器件(charge coupled device，CCD)或互补金属氧化物半导体 (complementary metal-oxide-semiconductor，CMOS)光电晶体管。感光元件把光信号转换 成电信号，之后将电信号传递给ISP转换成数字图像信号。ISP将数字图像信号输出到DSP加工处理。DSP将数字图像信号转换成标准的RGB，YUV等格式的图像信号。在 一些实施例中，电子设备100可以包括1个或N个摄像头193，N为大于1的正整数。

数字信号处理器用于处理数字信号，除了可以处理数字图像信号，还可以处理其他 数字信号。例如，当电子设备100在频点选择时，数字信号处理器用于对频点能量进行傅里叶变换等。

视频编解码器用于对数字视频压缩或解压缩。电子设备100可以支持一种或多种视 频编解码器。这样，电子设备100可以播放或录制多种编码格式的视频，例如：动态图 像专家组(moving picture experts group，MPEG)1，MPEG2，MPEG3，MPEG4等。

NPU为神经网络(neural-network，NN)计算处理器，通过借鉴生物神经网络结构，例 如借鉴人脑神经元之间传递模式，对输入信息快速处理，还可以不断的自学习。通过NPU可以实现电子设备100的智能认知等应用，例如：图像识别，人脸识别，语音识别，文 本理解等。

外部存储器接口120可以用于连接外部存储卡，例如Micro SD卡，实现扩展电子设备100的存储能力。外部存储卡通过外部存储器接口120与处理器110通信，实现数据 存储功能。例如将音乐，视频等文件保存在外部存储卡中。

内部存储器121可以用于存储计算机可执行程序代码，所述可执行程序代码包括指 令。处理器110通过运行存储在内部存储器121的指令，从而执行电子设备100的各种 功能应用以及数据处理。内部存储器121可以包括存储程序区和存储数据区。其中，存 储程序区可存储操作***，至少一个功能所需的应用程序(比如声音播放功能，图像播放 功能等)等。存储数据区可存储电子设备100使用过程中所创建的数据(比如音频数据，电 话本等)等。此外，内部存储器121可以包括高速随机存取存储器，还可以包括非易失性 存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器(universal flash storage，UFS)等。

电子设备100可以通过音频模块170，扬声器170A，受话器170B，麦克风170C， 耳机接口170D，以及应用处理器等实现音频功能。例如音乐播放，录音等。

音频模块170用于将数字音频信息转换成模拟音频信号输出，也用于将模拟音频输 入转换为数字音频信号。音频模块170还可以用于对音频信号编码和解码。在一些实施例中，音频模块170可以设置于处理器110中，或将音频模块170的部分功能模块设置 于处理器110中。

扬声器170A，也称“喇叭”，用于将音频电信号转换为声音信号。电子设备100可以通过扬声器170A收听音乐，或收听免提通话。

受话器170B，也称“听筒”，用于将音频电信号转换成声音信号。当电子设备100接听电话或语音信息时，可以通过将受话器170B靠近人耳接听语音。

麦克风170C，也称“话筒”，“传声器”，用于将声音信号转换为电信号。当拨打电话或发送语音信息时，用户可以通过人嘴靠近麦克风170C发声，将声音信号输入到麦克风170C。电子设备100可以设置至少一个麦克风170C。在另一些实施例中，电子设备100 可以设置两个麦克风170C，除了采集声音信号，还可以实现降噪功能。在另一些实施例 中，电子设备100还可以设置三个，四个或更多麦克风170C，实现采集声音信号，降噪， 还可以识别声音来源，实现定向录音功能等。

耳机接口170D用于连接有线耳机。耳机接口170D可以是USB接口130，也可以是3.5mm的开放移动电子设备平台(open mobile terminal platform，OMTP)标准接口，美国蜂窝电信工业协会(cellular telecommunications industry association of the USA，CTIA)标准 接口。

压力传感器180A用于感受压力信号，可以将压力信号转换成电信号。在一些实施例 中，压力传感器180A可以设置于显示屏194。压力传感器180A的种类很多，如电阻式 压力传感器，电感式压力传感器，电容式压力传感器等。电容式压力传感器可以是包括 至少两个具有导电材料的平行板。当有力作用于压力传感器180A，电极之间的电容改变。 电子设备100根据电容的变化确定压力的强度。当有触摸操作作用于显示屏194，电子 设备100根据压力传感器180A检测所述触摸操作强度。电子设备100也可以根据压力传 感器180A的检测信号计算触摸的位置。在一些实施例中，作用于相同触摸位置，但不同 触摸操作强度的触摸操作，可以对应不同的操作指令。例如：当有触摸操作强度小于第 一压力阈值的触摸操作作用于短消息应用图标时，执行查看短消息的指令。当有触摸操 作强度大于或等于第一压力阈值的触摸操作作用于短消息应用图标时，执行新建短消息 的指令。

陀螺仪传感器180B可以用于确定电子设备100的运动姿态。在一些实施例中，可以通过陀螺仪传感器180B确定电子设备100围绕三个轴(即，x，y和z轴)的角速度。陀螺 仪传感器180B可以用于拍摄防抖。示例性的，当按下快门，陀螺仪传感器180B检测电 子设备100抖动的角度，根据角度计算出镜头模组需要补偿的距离，让镜头通过反向运 动抵消电子设备100的抖动，实现防抖。陀螺仪传感器180B还可以用于导航，体感游戏 场景。

气压传感器180C用于测量气压。在一些实施例中，电子设备100通过气压传感器180C测得的气压值计算海拔高度，辅助定位和导航。

磁传感器180D包括霍尔传感器。电子设备100可以利用磁传感器180D检测翻盖皮套的开合。在一些实施例中，当电子设备100是翻盖机时，电子设备100可以根据磁传 感器180D检测翻盖的开合。进而根据检测到的皮套的开合状态或翻盖的开合状态，设置 翻盖自动解锁等特性。

加速度传感器180E可检测电子设备100在各个方向上(一般为三轴)加速度的大小。 当电子设备100静止时可检测出重力的大小及方向。还可以用于识别电子设备姿态，应用于横竖屏切换，计步器等应用。

距离传感器180F，用于测量距离。电子设备100可以通过红外或激光测量距离。在一些实施例中，拍摄场景，电子设备100可以利用距离传感器180F测距以实现快速对焦。

接近光传感器180G可以包括例如发光二极管(LED)和光检测器，例如光电二极管。发光二极管可以是红外发光二极管。电子设备100通过发光二极管向外发射红外光。电 子设备100使用光电二极管检测来自附近物体的红外反射光。当检测到充分的反射光时， 可以确定电子设备100附近有物体。当检测到不充分的反射光时，电子设备100可以确 定电子设备100附近没有物体。电子设备100可以利用接近光传感器180G检测用户手持 电子设备100贴近耳朵通话，以便自动熄灭屏幕达到省电的目的。接近光传感器180G也 可用于皮套模式，口袋模式自动解锁与锁屏。

环境光传感器180L用于感知环境光亮度。电子设备100可以根据感知的环境光亮度 自适应调节显示屏194亮度。环境光传感器180L也可用于拍照时自动调节白平衡。环境光传感器180L还可以与接近光传感器180G配合，检测电子设备100是否在口袋里，以 防误触。

指纹传感器180H用于采集指纹。电子设备100可以利用采集的指纹特性实现指纹解 锁，访问应用锁，指纹拍照，指纹接听来电等。

温度传感器180J用于检测温度。在一些实施例中，电子设备100利用温度传感器180J 检测的温度，执行温度处理策略。例如，当温度传感器180J上报的温度超过阈值，电子设备100执行降低位于温度传感器180J附近的处理器的性能，以便降低功耗实施热保护。在另一些实施例中，当温度低于另一阈值时，电子设备100对电池142加热，以避免低 温导致电子设备100异常关机。在其他一些实施例中，当温度低于又一阈值时，电子设 备100对电池142的输出电压执行升压，以避免低温导致的异常关机。

触摸传感器180K，也称“触控面板”。触摸传感器180K可以设置于显示屏194，由 触摸传感器180K与显示屏194组成触摸屏，也称“触控屏”。触摸传感器180K用于检测 作用于其上或附近的触摸操作。触摸传感器可以将检测到的触摸操作传递给应用处理器， 以确定触摸事件类型。可以通过显示屏194提供与触摸操作相关的视觉输出。在另一些 实施例中，触摸传感器180K也可以设置于电子设备100的表面，与显示屏194所处的位 置不同。

骨传导传感器180M可以获取振动信号。在一些实施例中，骨传导传感器180M可以获取人体声部振动骨块的振动信号。骨传导传感器180M也可以接触人体脉搏，接收血 压跳动信号。在一些实施例中，骨传导传感器180M也可以设置于耳机中，结合成骨传 导耳机。音频模块170可以基于所述骨传导传感器180M获取的声部振动骨块的振动信 号，解析出语音信号，实现语音功能。应用处理器可以基于所述骨传导传感器180M获 取的血压跳动信号解析心率信息，实现心率检测功能。

按键190包括开机键，音量键等。按键190可以是机械按键。也可以是触摸式按键。电子设备100可以接收按键输入，产生与电子设备100的用户设置以及功能控制有关的 键信号输入。

马达191可以产生振动提示。马达191可以用于来电振动提示，也可以用于触摸振动反馈。例如，作用于不同应用(例如拍照，音频播放等)的触摸操作，可以对应不同的振 动反馈效果。作用于显示屏194不同区域的触摸操作，马达191也可对应不同的振动反 馈效果。不同的应用场景(例如：时间提醒，接收信息，闹钟，游戏等)也可以对应不同的 振动反馈效果。触摸振动反馈效果还可以支持自定义。

指示器192可以是指示灯，可以用于指示充电状态，电量变化，也可以用于指示消息，未接来电，通知等。

SIM卡接口195用于连接SIM卡。SIM卡可以通过***SIM卡接口195，或从SIM 卡接口195拔出，实现和电子设备100的接触和分离。电子设备100可以支持1个或N 个SIM卡接口，N为大于1的正整数。SIM卡接口195可以支持Nano SIM卡，Micro SIM 卡，SIM卡等。同一个SIM卡接口195可以同时***多张卡。所述多张卡的类型可以相 同，也可以不同。SIM卡接口195也可以兼容不同类型的SIM卡。SIM卡接口195也可 以兼容外部存储卡。电子设备100通过SIM卡和网络交互，实现通话以及数据通信等功 能。在一些实施例中，电子设备100采用eSIM，即：嵌入式SIM卡。eSIM卡可以嵌在 电子设备100中，不能和电子设备100分离。

电子设备100的软件***可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。本申请实施例以分层架构的Android***为例，示例性说明电子设备100 的软件结构。

图18是本申请实施例提供的电子设备100的软件结构框图。分层架构将软件分成若 干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将Android***分为四层，从上至下分别为应用程序层，应用程序框架层，安卓运 行时(Android runtime)和***库，以及内核层。应用程序层可以包括一系列应用程序包。

如图18所示，应用程序包可以包括相机，图库，日历，通话，地图，导航，WLAN， 蓝牙，音乐，视频，短信息等应用程序。

应用程序框架层为应用程序层的应用程序提供应用编程接口(applicationprogramming interface，API)和编程框架。应用程序框架层包括一些预先定义的函数。

如图18所示，应用程序框架层可以包括窗口管理器，内容提供器，视图***，电话管理器，资源管理器，通知管理器等。

窗口管理器用于管理窗口程序。窗口管理器可以获取显示屏大小，判断是否有状态 栏，锁定屏幕，截取屏幕等。

内容提供器用来存放和获取数据，并使这些数据可以被应用程序访问。所述数据可 以包括视频，图像，音频，拨打和接听的电话，浏览历史和书签，电话簿等。

视图***包括可视控件，例如显示文字的控件，显示图片的控件等。视图***可用于构建应用程序。显示界面可以由一个或多个视图组成的。例如，包括短信通知图标的 显示界面，可以包括显示文字的视图以及显示图片的视图。

电话管理器用于提供电子设备100的通信功能。例如通话状态的管理(包括接通，挂 断等)。

资源管理器为应用程序提供各种资源，比如本地化字符串，图标，图片，布局文件，视频文件等等。

通知管理器使应用程序可以在状态栏中显示通知信息，可以用于传达告知类型的消 息，可以短暂停留后自动消失，无需用户交互。比如通知管理器被用于告知下载完成，消息提醒等。通知管理器还可以是以图表或者滚动条文本形式出现在***顶部状态栏的通知，例如后台运行的应用程序的通知，还可以是以对话窗口形式出现在屏幕上的通知。例如在状态栏提示文本信息，发出提示音，电子设备振动，指示灯闪烁等。

Android Runtime包括核心库和虚拟机。Android runtime负责安卓***的调度和管理。

核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核 心库。

应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框 架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。

***库可以包括多个功能模块。例如：表面管理器(surface manager)，媒体库(Media Libraries)，三维图形处理库(例如：OpenGL ES)，2D图形引擎(例如：SGL)等。

表面管理器用于对显示子***进行管理，并且为多个应用程序提供了2D和3D图层的融合。

媒体库支持多种常用的音频，视频格式回放和录制，以及静态图像文件等。媒体库可以支持多种音视频编码格式，例如:MPEG4，H.264，MP3，AAC，AMR，JPG，PNG 等。

三维图形处理库用于实现三维图形绘图，图像渲染，合成，和图层处理等。

2D图形引擎是2D绘图的绘图引擎。

内核层是硬件和软件之间的层。内核层至少包含显示驱动，摄像头驱动，音频驱动， 传感器驱动。

所述电子设备100集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或 使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实现上述实施 例方法中的全部或部分流程，也可以通过计算机可读指令来指令相关的硬件来完成，所述的 计算机可读指令可存储于一计算机可读存储介质中，所述计算机可读指令在被处理器执行时， 可实现上述各个方法实施例的步骤。其中，所述计算机可读指令包括计算机可读指令代码， 所述计算机可读指令代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。 所述计算机可读介质可以包括：能够携带所述计算机可读指令代码的任何实体或装置、记录 介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM)、随机存取存储 器(RAM)等。

本实施例还提供一种计算机存储介质，所述计算机存储介质中存储有计算机指令， 当所述计算机指令在电子设备上运行时，使得电子设备执行上述相关方法步骤实现上述 实施例中的消息管理方法。

本实施例还提供了一种计算机程序产品，当所述计算机程序产品在电子设备上运行 时，使得电子设备执行上述相关步骤，以实现上述实施例中的消息管理方法。

另外，本申请的实施例还提供一种装置，这个装置具体可以是芯片，组件或模块，所述装置可包括相连的处理器和存储器；其中，存储器用于存储计算机执行指令，当装 置运行时，处理器可执行存储器存储的计算机执行指令，以使芯片执行上述各方法实施 例中的消息管理方法。

其中，本实施例提供的电子设备、计算机存储介质、计算机程序产品或芯片均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考上文所提供的对应 的方法中的有益效果，此处不再赘述。

通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方 便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以 完成以上描述的全部或者部分功能。

在本申请所提供的几个实施例中，应所述理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块或 单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个 单元或组件可以结合或者可以集成到另一个装置，或一些特征可以忽略，或不执行。另 一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装 置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示 的部件可以是一个物理单元或多个物理单元，即可以位于一个地方，或者也可以分布到多个不同地方。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

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

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时， 可以存储在一个可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上 或者说对现有技术做出贡献的部分或者所述技术方案的全部或部分可以以软件产品的形 式体现出来，所述软件产品存储在一个存储介质中，包括若干指令用以使得一个设备(可 以是单片机，芯片等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory， ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以 存储程序代码的介质。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何在本申请揭露的技术范围内的变化或替换，都应涵盖在本申请的保护范围之内。因此， 本申请的保护范围应以所述权利要求的保护范围为准。

Claims (17)

1.一种消息管理方法，应用于电子设备，其特征在于，所述消息管理方法包括：

接收通知消息，并解析所述通知消息的关键属性，所述关键属性包括消息来源、消息类型、消费状态、金额、银行名、银行***、交易时间，所述消费状态包括收入和支出；

若确定所述通知消息的消息类型为消费类消息时，根据所述通知消息的关键属性确定所述通知消息是否属于已发生的一笔交易；及

若确定所述通知消息属于所述交易且存在与所述交易对应的消息历史记录、以及确定正在展示所述通知消息的同类消息时，对所述通知消息和所述正在展示的同类消息进行合并处理或者删减处理或者执行阅读状态的更新操作。

2.如权利要求1所述的消息管理方法，其特征在于，所述方法还包括：

按照收到消息的先后顺序对预设时间内来自同一消息来源的两个或多个消费类消息分别进行标记以区分多笔先后发生的不同交易；及

根据所述标记基于预先创建的消息模板对属于同笔交易但来自不同消息来源的消费类消息进行合并处理。

3.如权利要求2所述的消息管理方法，其特征在于，所述方法还包括：

对预设时间内的属于不同交易但是消费状态相同的消息进行合并处理，包括：

基于所述不同交易涉及的交易金额统计总交易金额；及

基于所述消息模板以及总交易金额生成合并消息。

4.如权利要求2所述的消息管理方法，其特征在于，所述方法还包括：

对预设时间内的属于不同交易但是消费状态不相同的消息进行合并处理，包括：

基于所述不同交易涉及的交易金额统计总交易金额；及

基于所述消息模板以及总交易金额生成合并消息。

5.如权利要求1至4任意一项所述的消息管理方法，其特征在于，所述方法还包括：

若确定正在展示同类消息，在通知栏展示所述通知消息；

根据所述关键属性，合并所述通知消息和所述正在展示的同类消息，获得合并消息；及

从所述通知栏中删除所述通知消息和所述正在展示的同类消息并展示所述合并消息。

6.如权利要求1至4任意一项所述的消息管理方法，其特征在于，所述方法还包括：

若确定正在展示同类消息，在通知栏不展示所述通知消息；

根据所述关键属性，合并所述通知消息和所述正在展示的同类消息，获得合并消息；及

从所述通知栏中删除所述同类消息并在所述通知栏中展示所述合并消息。

7.如权利要求1至4任意一项所述的消息管理方法，其特征在于，所述方法还包括：

若确定正在展示所述同类消息，在通知栏展示或者不展示所述通知消息；

合并所述通知消息和所述正在展示的同类消息，获得所述合并消息；及

在所述通知栏展示所述合并消息，并将所述通知消息和所述正在展示的同类消息折叠展示在所述合并消息的下方。

8.如权利要求1至4任意一项所述的消息管理方法，其特征在于，所述方法还包括：

若确定正在展示所述同类消息，从所述通知消息和所述正在展示的同类消息中确定一个保留消息；及

从通知栏中删除其他消息，所述其他消息是指所述通知消息和所述正在展示的同类消息中，除所述保留消息之外的消息。

9.如权利要求1至4任意一项所述的消息管理方法，其特征在于，所述方法还包括：

若确定正在展示所述同类消息，展示所述通知消息；

从所述通知消息和所述正在展示的同类消息中确定一个保留消息；及

将其他消息的阅读状态标记为已读状态，并从通知栏删除所述其他消息，所述其他消息表示所述通知消息和所述正在展示的同类消息中，除所述保留消息之外的消息。

10.如权利要求9所述的消息管理方法，其特征在于，所述方法还包括：

获取所述其他消息对应的已读按钮，所述已读按钮用于将其他消息的阅读状态标记为已读状态；点击已读按钮将其他消息的阅读状态标记为已读状态。

11.如权利要求8至10中任一项所述的消息管理方法，其特征在于，所述保留消息为所述通知消息和所述正在展示的同类消息中的任意一个消息。

12.如权利要求8至10中任一项所述的消息管理方法，其特征在于，所述保留消息为所述通知消息和所述正在展示的同类消息中，最早收到的一个消息或者最晚收到的一个消息。

13.如权利要求8至10中任一项所述的消息管理方法，其特征在于，所述保留消息为所述通知消息和所述正在展示的同类消息中，源自所设置的消息来源的消息。

14.如权利要求1至13中任意一项所述的消息管理方法，其特征在于，所述方法还包括：

利用通知管理器预设通知频道；

利用所述通知管理器对所述通知频道预设若干字段，所述若干字段与所述消费类消息的各个属性一一对应；

若所述通知管理器接收到所述通知消息，利用所述通知管理器按照所述若干字段解析所述通知消息并获得所述关键属性。

15.如权利要求1至13中任意一项所述的消息管理方法，其特征在于，所述方法还包括：

利用通知管理器的NotificationListenerService获取通知栏中的所有通知消息的标题及内容；及

利用自然语言处理NLP技术，从所获取的通知消息的标题及内容中抽取关键属性。

16.一种电子设备，其特征在于，包括处理器和存储器；所述存储器，用于存储指令；所述处理器，用于调用所述存储器中的指令，使得所述电子设备执行如权利要求1至15中任一项所述的消息管理方法。

17.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有至少一个指令，所述至少一个指令被处理器执行时实现如权利要求1至15中任一项所述的消息管理方法。

Images