消息读取状态的确定方法、装置、电子设备及存储介质与流程

本申请实施例涉及数据处理技术领域，尤其涉及一种消息读取状态的确定方法、装置、电子设备及存储介质。

背景技术：

消息目前是各类客户端(业界又称之为app)中必不可少的一个功能，尤其对于具备社交功能的各类客户端来说，消息是实现其社交功能的重要手段之一。示例性地，比如消息基于点赞、评论社交行为产生。而基于此类社交行为产生的消息，通常都会有展示消息的读取状态的需求。

现有的消息的读取状态的设置与用户操作有关，即，若用户读取了某条消息，则将其标记为已读状态；对于用户尚未读取的消息则标记为未读状态。但这种方式一方面增加了用户的操作负担，另一方面也增加了客户端的数据处理负担。

技术实现要素：

本申请实施例提供一种消息读取状态的确定方法、装置、电子设备及存储介质，用以至少部分克服或者缓解现有技术存在的上述技术问题。

本申请实施例提供一种消息读取状态的确定方法，其包括：根据对消息中心的访问操作向服务端发送消息获取请求，所述消息获取请求用于向所述服务端请求消息，所述消息获取请求中携带有前次向所述服务端进行消息请求操作的第一读取时间；以及接收所述服务端返回的携带有读取状态的目标消息，所述读取状态根据所述目标消息的产生时间以及所述第一读取时间确定。

本申请实施例提供一种消息读取状态的确定方法，其包括：接收客户端发送的消息获取请求，所述消息获取请求中携带有所述客户端前次进行消息请求操作的第一读取时间；确定存储的消息列表中的目标消息的产生时间；根据所述目标消息的产生时间以及所述第一读取时间，确定所述目标消息的读取状态；以及向所述客户端返回携带有所述读取状态的目标消息。

本申请实施例提供一种消息读取状态的确定装置，其包括：请求发送单元，用于根据对消息中心的访问操作向服务端发送消息获取请求，所述消息获取请求用于向所述服务端请求消息，所述消息获取请求中携带有前次向所述服务端进行消息请求操作的第一读取时间；以及目标消息接收单元，用于接收所述服务端返回的携带有读取状态的目标消息，所述读取状态根据所述目标消息的产生时间以及所述第一读取时间确定。

本申请实施例提供一种消息读取状态的确定装置，其包括：请求接收单元，用于接收客户端发送的消息获取请求，所述消息获取请求中携带有前次进行消息请求操作的第一读取时间；时间确定单元，用于确定存储的消息列表中的目标消息的产生时间；读取状态确定单元，用于根据所述目标消息的产生时间以及所述第一读取时间，确定所述目标消息的读取状态；以及消息返回单元，用于向所述客户端返回携带有所述读取状态的所述目标消息。

本申请实施例提供一种电子设备，包括：处理器、存储器、通信接口和通信总线，所述处理器、所述存储器和所述通信接口通过所述通信总线完成相互间的通信；所述存储器用于存放至少一可执行指示，所述可执行指示使所述处理器执行如上所述的消息读取状态的确定方法对应的操作。

本申请实施例提供一种计算机存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上所述的消息读取状态的确定方法。

本申请实施例提供的技术方案中，在消息获取请求中携带有前次向服务端进行消息请求操作的第一读取时间，以此便于服务端确定目标消息的读取状态并向客户端反馈。基于此，实现了客户端展示的目标消息的读取状态的批量处理，避免了针对每个目标消息在客户端和服务端之间进行多次交互，从而降低了客户端开发成本和数据处理负担，也降低了用户的操作负担，并且减少了客户端和服务端之间的数据传输负担。

附图说明

后文将参照附图以示例性而非限制性的方式详细描述本申请实施例的一些具体实施例。附图中相同的附图标记标示了相同或类似的部件或部分。本领域技术人员应该理解，这些附图未必是按比例绘制的。附图中：

图1a为本申请实施例一提供的一种消息读取状态的确定方法流程示意图；

图1b为本申请实施例一提供的一种使用场景示意图；

图2a为本申请实施例二提供的一种消息读取状态的确定方法流程示意图；

图2b为本申请实施例二提供的一种使用场景示意图；

图3为本申请实施例三提供的一种消息读取状态的确定方法流程示意图；

图4为本申请实施例四提供的一种消息读取状态的确定方法流程示意图；

图5为本申请实施例五提供的一种消息读取状态的确定方法流程示意图；

图6为本申请实施例六提供的一种消息读取状态的确定方法流程示意图；

图7为本申请实施例七提供的一种消息读取状态的确定装置结构示意图；

图8为本申请实施例八提供的一种消息读取状态的确定装置结构示意图；

图9为本申请实施例九的一种电子设备的结构示意图。

具体实施方式

为了使本领域的人员更好地理解本申请实施例中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本申请实施例一部分实施例，而不是全部的实施例。基于本申请实施例中的实施例，本领域普通技术人员所获得的所有其他实施例，都应当属于本申请实施例保护的范围。

下面结合本申请实施例附图进一步说明本申请实施例具体实现。

图1a为本申请实施例一提供的一种消息读取状态的确定方法流程示意图；本申请实施例提供的方案是从客户端这一侧进行描述。具体地，如图1a所示，其包括如下步骤s101-s102：

s101、客户端根据对消息中心的访问操作向服务端发送消息获取请求。

其中，所述消息获取请求用于向所述服务端请求消息，所述消息获取请求中携带有前次向所述服务端进行消息请求操作的第一读取时间。

本实施例中，客户端具体可以为安装在电子设备上的应用程序，依赖于电子设备的提供的资源(如硬件资源、软件资源)执行上述相应的步骤和操作。而服务端可以实现为服务器或服务器集群或云端等，以与客户端交互，并向客户端提供数据和服务。

本实施例中，所述客户端中设置有供用户浏览消息的消息中心，当用户访问该消息中心时触发从服务端获取相应的消息。

本实施例中，在向服务端发送的消息获取请求中携带有客户端前次向服务端进行消息请求操作的第一读取时间。在实际应用中，消息获取请求中还会携带有用户的信息，如用户的标识id等，以便服务端据此提供与该标识id对应的消息。通过访问消息中心时，在发送的消息获取请求中携带有所述第一读取时间，可以使得服务端可以快速有效地确定出目标信息的读取状态。

比如，若目标消息的产生时间大于第一读取时间，则确定出所述目标消息的读取状态为未读状态；或者，若所述目标消息的产生时间小于等于所述第一读取时间，则确定出所述目标消息的读取状态为已读状态。

具体地，可以通过比较所述目标消息的产生时间与所述第一读取时间，从而确定出所述目标消息的产生时间与所述第一读取时间的大小关系。该比较过程优选在服务端执行。当然，此处需要说明的是，如果客户端本地具有足够的资源执行上述比较判断的过程的话，上述确定读取状态的技术处理过程也可以在客户端本地执行。

由上述分析可见，由于第一读取时间是基于用户访问消息中心产生的，而用户访问消息中心，其目的是读取消息，因此，如果所述目标的产生时间大于所述第一读取时间，则表明在第一读取时间之后，用户并没有访问消息中心，因此，在第一读取时间之后产生的消息未被读取，则据此可直接确定出所述目标消息的读取状态为未读状态；如果所述目标的产生时间小于等于所述第一读取时间，则表明在第一读取时间之前，用户访问过消息中心，因此，在第一读取时间之前产生的消息被读取，则据此可直接确定出所述目标消息的读取状态为已读状态。因此，由于在所述消息获取请求中携带有所述第一读取时间，如果要确定多个目标消息的读取状态，只要比较每个目标消息的产生时间与第一读取时间的大小关系，即可实现批量地确定出多个目标消息的读取状态，实现了消息读取状态的批量处理，避免了针对其中的每个目标消息，在客户端和服务端之间进行多次交互，从而降低了客户端开发成本和数据处理负担，也降低了用户的操作负担，并且减少了客户端和服务端之间的数据传输负担。

s102、客户端接收服务端返回的携带有读取状态的目标消息，所述读取状态根据所述目标消息的产生时间以及所述第一读取时间确定。

本实施例中，在服务端确定出目标消息的读取状态后，将携带有该读取状态的目标消息发送给客户端，并由客户端接收即可，从而可在客户端直观地对目标消息的读取状态进行直观的展示，便于用户查看、管理消息。

进一步可选地，如果某个目标消息的读取状态为未读状态，则在客户端展示的时候提示用户进行查看，相反，如果某个目标消息的读取状态为未读状态，则在客户端展示的时候提示用户无须进行查看，由此使得消息中心中的消息的读取状态一目了然，这些读取状态准确度较高。

上述过程的一种使用场景示例如图1b所示，当用户访问消息中心时，客户端向服务端发送携带有所述第一读取时间的消息获取请求；服务端在接收到该消息获取请求后，根据第一读取时间确定目标消息的读取状态；然后，向客户端返回携带有确定的读取状态的目标消息；客户端在接收到目标消息后，根据其读取状态通过消息中心的界面向用户展示目标消息。

通过本实施例，在消息获取请求中携带有前次向服务端进行消息请求操作的第一读取时间，以此便于服务端确定目标消息的读取状态并向客户端反馈。基于此，实现了客户端展示的目标消息的读取状态的批量处理，避免了针对每个目标消息在客户端和服务端之间进行多次交互，从而降低了客户端开发成本和数据处理负担，也降低了用户的操作负担，并且减少了客户端和服务端之间的数据传输负担。

图2a为本申请实施例二提供的一种消息读取状态的确定方法流程示意图；与上述图1a提供的实施例相同，本实施例仍然从客户端这一侧进行描述；与上述实施例不同的是，主要增加了在客户端展示未读消息的相关处理步骤。具体地，如图2a所示，其包括如下步骤s201-203：

s201、向服务端发送消息轮询请求，并接收所述服务端根据消息轮询请求返回的所述第一读取时间。

本实施例中，在每次向服务端进行消息请求操作后，对应的第一读取时间都被存储在服务端，当客户端被启动时，客户端可以向服务端发送消息轮询请求，该消息轮询请求主要用于向服务端请求所述第一读取时间，从而实现由服务端发送给客户端第一读取时间。该消息轮询请求中携带有用户的信息，如用户的标识或客户端的标识等，根据该标识从而由服务端发送对应该用户的所述第一读取时间，此处，用户的信息不做特别限定，可以为任意适当的可标识用户的信息。

具体地，本实施例中，步骤s201中在向所述服务端发送消息轮询请求，并接收所述服务端根据消息轮询请求返回的所述第一读取时间时，具体可以通过向所述服务端上的轮询请求接口发送消息轮询请求，并接收所述服务端根据该消息轮询请求返回的所述第一读取时间。该轮询请求接口配置在服务端，从而可以有效地保证可成功从所述服务端接收到所述第一读取时间。

s202、客户端根据对消息中心的访问操作，向服务端的消息列表接口发送消息获取请求。

本实施例中，与上述实施例不同的是，客户端在向服务端发送消息获取请求时，具体向服务端的消息列表接口发送当前访问消息中心时的消息获取请求。即在服务端上配置有消息列表接口，从而可以有效地保证可将消息获取请求发送至所述服务端，以从服务端获取到目标消息。

如前所述，该消息获取请求是因用户访问消息中心产生，可见，当客户端启动时，客户端发送消息轮询请求至服务端，以从服务端获取所述第一读取时间，而进一步当用户访问消息中心时，客户端进一步发送消息获取请求，而将服务端之前发送的所述第一读取时间携带在消息获取请求中发送至所述服务端，从而可以使得服务端可以基于相同的第一读取时间进行统计，避免了在由于发送消息轮询请求和消息获取请求之间存在时间差，而无法准确统计出未读消息的数量的情形发生。具体地，服务端可根据第一读取时间在服务端进行开放式搜索(opensearch)，从而快速地统计出未读消息的数量。

s203、接收所述服务端发送的所述未读消息的数量以进行展示。

如前所述，该未读消息的数量根据第一读取时间统计确定。

本实施例中，客户端接收服务端推送的所述未读消息的数量以进行展示，当然，在其他实施例中，客户端也可以主动去从服务端拉取所述未读消息的数量以进行展示，而具体的哪些消息属于未读消息，主要通过后续步骤s204来的处理来展示。

s204、客户端接收所述服务端返回的携带有读取状态的目标消息，所述读取状态根据所述目标消息的产生时间以及所述第一读取时间确定。

本实施例中，有关步骤s204的详细解释可参见上述实施例一中相关部分的记载，在此不再赘述。当然，在其他实施例中，步骤s204也可以采用不同的方式来实施。

可选地，本实施例中，若所述目标消息的数量为多个，则多个所述目标消息被划分为至少两个消息级别，根据所述目标消息的产生时间以及所述第一读取时间确定所述读取状态的目标消息为所述至少两个消息级别中至少一消息级别的目标消息，所述目标消息被划分为的消息级别根据所述目标消息的内容或消息类型确定。具体设置时，可以根据目标消息的内容或消息类型，可以将用户不关注的消息划分至同一消息级别，并针对该消息级别的目标消息，根据所述目标消息的产生时间以及所述第一读取时间确定所述读取状态，针对其他消息级别的消息，则不根据第一读取时间确定，以避免遗漏。

例如，可以根据多个目标消息的内容或消息类型，将多个目标消息划分为重要级别、次要级别、不关注级别等，例如广告消息可以划分为不关注级别，用户订阅的消息可以划分为重要级别。根据所述目标消息的产生时间以及所述第一读取时间确定所述读取状态的目标消息为次要级别、不关注级别的目标消息，而重要级别的目标消息，可以根据用户对目标消息的读取操作确定读取状态，从而可以避免遗漏掉较为重要的目标消息。当然，应当理解的是，上述仅为举例说明，并不作为本申请的限定。

图2b示出了上述过程的一种使用场景，如图2b中所示，客户端启动时，向服务端发送消息轮询请求，其中包含用户的信息；服务端通过轮询请求接口接收该消息轮询请求，并向客户端返回与所述用户的信息对应的所述第一读取时间；客户端接收到对消息中心的访问操作，向服务端发送消息获取请求，并在其中携带第一读取时间和所述用户的信息；服务端通过消息列表接口接收到该消息获取请求后，根据第一读取时间，为消息中心中与所述用户的信息对应的消息(目标消息)确定读取状态；然后，服务端将携带有读取状态的目标消息返回给客户端，客户端在接收到目标消息后，根据其读取状态通过消息中心的界面向用户进行展示。

需要说明的是，在实际应用中，目标消息根据用户在消息中心的操作确定，例如，服务端根据用户的操作每次仅向用户返回一定数量的消息，比如，用户点击进入消息中心时，服务端根据消息获取请求向客户端返回10条消息；若用户基于当前展示的消息进行了设定操作，如翻页操作，则该翻页操作的信息将被传递给服务端，服务端将再根据该信息向客户端返回另外10条消息。依此类推，直至确定用户在一定时间内未再进行翻页操作或者用户退出消息中心。在实际应用中，服务端返回的消息可按照消息产生时间距离当前时间从近到远的顺序返回，以便用户可以获得最新消息。

可选地，本实施例中，用户退出消息中心的时间信息或者进行最后一次翻页操作的时间信息也会传递给服务端，以使服务端可以据此更新原来的第一读取时间，保证信息的准确性和及时性。

进一步可选地，本实施例中，展示目标消息时，可以基于信息流或卡片流的形式在所述消息中心的界面中展示所述目标消息。

例如，服务端可以将多个携带有读取状态的目标消息拼接为一个信息流，并发送至客户端，以使客户端能够以信息流的方式接收服务端返回的目标消息，并基于信息流的形式在所述消息中心的界面中展示所述目标消息，使得用户可以及时获得最新的目标消息。

信息流即feed流，是一种将若干消息源生产的目标消息组合在一起形成内容聚合器，可以帮助用户持续地获取最新的消息源生产的目标消息。

另外，客户端可以接收到多个目标消息，每个目标消息可以对应一张消息中心中展示的卡片，即基于卡片流的形式在所述消息中心的界面中展示所述目标消息。多张卡片可以层叠显示，也可以并列显示，卡片上可以包括目标消息的消息源、目标消息的文字、目标消息的图片等。基于卡片流的形式在消息中心的界面中展示目标消息，可以使得用户能够快速抓取卡片中重点展示的目标信息的内容，节省用户的阅读时间。

具体基于卡片流的形式展示目标消息的界面可以参考图2b中的最右侧界面所示，以卡片流的形式展示了目标消息1、目标消息2、和目标消息3。

此外，需要说明的是，本申请实施例中，轮询请求接口和消息列表接口均可以由本领域技术人员根据实际情况采用任意适当的方式实现，本申请实施例地上接口的具体实现方式不作限定。

通过本实施例，在消息获取请求中携带有前次向服务端进行消息请求操作的第一读取时间，以此便于服务端确定目标消息的读取状态并向客户端反馈。基于此，实现了客户端展示的目标消息的读取状态的批量处理，避免了针对每个目标消息在客户端和服务端之间进行多次交互，从而降低了客户端开发成本和数据处理负担，也降低了用户的操作负担，并且减少了客户端和服务端之间的数据传输负担。

图3为本申请实施例三提供的一种消息读取状态的确定方法流程示意图，本实施例仍然从客户端这一侧进行描述；与上述实施例不同之处在于，增加了可对所述第一读取时间进行更新的处理步骤。如图3所示，其包括如下步骤：

s301、客户端根据对消息中心的访问操作向服务端发送消息获取请求。

所述消息获取请求用于向所述服务端请求消息，所述消息获取请求中携带有前次向所述服务端进行消息请求操作的第一读取时间。

s302、客户端接收所述服务端返回的携带有读取状态的目标消息。

所述读取状态根据所述目标消息的产生时间以及所述第一读取时间确定。

本实施例中，有关步骤s301-s302的详细解释可参见上述实施例中相关部分的记载，在此不再赘述。当然，在其他实施例中，步骤s301-s302也可以采用不同的方式来实施。

s303、向服务端发送访问结束请求，所述访问结束请求用于指示服务端根据客户端获取所述目标消息的第二读取时间更新所述第一读取时间。

比如，用户在客户端查看消息时，会进行翻页操作，以查看不同的消息，因此，每个翻页操作都会对应有相应的时间，以此作为第二读取时间。为此，在一种可行方式中，步骤s303可以包括：

根据对消息中心的消息展示页面的翻页操作，确定退出消息中心时的最后一次翻页操作对应的第二读取时间；将所述第二读取时间信息发送至所述服务端，以使服务端根据所述第二读取时间更新所述第一读取时间。

由此可见，本实施例中，通过第二读取时间，对所述第一读取时间进行更新，从而可以保证信息的准确性和及时性。

当然，也可以不在退出消息中心时更新第一读取时间，而是按照其他方式更新第一读取时间，比如，每确定一个第二读取时间，即根据第二读取时间更新第一读取时间；或者，每间隔预设时长，即根据第二读取时间更新第一读取时间。

图4为本申请实施例四提供的一种消息读取状态的确定方法流程示意图；与上述实施例一至三不同之处在于，本实施例从服务端这一侧进行描述。如图4所示，其包括如下步骤s401-s404：

s401、接收客户端发送的消息获取请求，所述消息获取请求中携带有所述客户端前次进行消息请求操作的第一读取时间。

本实施例中，有关消息获取请求及其第一读取时间的获取均可参见上述实施例一至三中相应部分的记载，详细不再赘述。

s402、确定存储的消息列表中的目标消息的产生时间。

本实施例中，通过解析消息列表，从而确定所述目标消息的产生时间，比如点赞消息或评论的产生时间。

s403、根据所述目标消息的产生时间以及所述第一读取时间，确定所述目标消息的读取状态。

本实施例中，具体地，可以通过比较所述目标消息的产生时间与所述第一读取时间，从而确定出所述目标消息的产生时间与所述第一读取时间的大小关系。若所述目标消息的产生时间大于所述第一读取时间，则确定出所述目标消息的读取状态为未读状态；或者，若所述目标消息的产生时间小于等于所述第一读取时间，则确定出所述目标消息的读取状态为已读状态。

可选地，本实施例中，若所述目标消息的数量为多个，则在步骤s403之前，所述方法还可以包括：

根据多个所述目标消息的内容或消息类型，确定多个所述目标消息分别对应的消息级别，所述消息级别的数量为至少两个。

针对所述至少两个消息级别中至少一消息级别的目标消息，执行步骤s403。

具体设置时，可以根据目标消息的内容或消息类型，可以将用户不关注的消息划分至同一消息级别，并针对该消息级别的目标消息，根据所述目标消息的产生时间以及所述第一读取时间确定所述读取状态，针对其他消息级别的消息，则不根据第一读取时间确定，以避免遗漏。

例如，可以根据多个目标消息的内容或消息类型，将多个目标消息划分为重要级别、次要级别、不关注级别等，例如若目标消息的消息类型为广告，则可以将其划分为不关注级别，用户订阅的消息可以划分为重要级别。根据所述目标消息的产生时间以及所述第一读取时间确定所述读取状态的目标消息为次要级别、不关注级别的目标消息，而重要级别的目标消息，可以根据用户对目标消息的读取操作确定读取状态，从而可以避免遗漏掉较为重要的目标消息。当然，应当理解的是，上述仅为举例说明，并不作为本申请的限定。

由上述分析可见，由于第一读取时间是基于用户访问消息中心的消息请求操作产生的，而用户访问消息中心，其目的无非是读取消息，因此，如果所述目标消息的产生时间大于所述第一读取时间，则表明在第一读取时间之后产生的消息未被读取，则据此可直接确定出所述目标消息的读取状态为未读状态；如果所述目标消息的产生时间小于等于所述第一读取时间，则表明在第一读取时间之前产生的消息被读取，则据此可直接确定出所述目标消息的读取状态为已读状态。因此，由于在所述消息获取请求中携带有客户端前次进行消息请求操作的第一读取时间，如果要确定多个目标消息的读取状态，只要比较每个目标消息的产生时间与第一读取时间的大小关系，即可实现批量地确定出多个目标消息的读取状态，避免了针对其中的每个目标消息，在客户端和服务端的服务器之间进行多次交互，从而降低了服务端开发成本，以及降低了服务端的负载。

s404、向所述客户端返回携带有读取状态的目标消息。

通过本实施例，服务端根据目标消息和产生时间和客户端的第一读取时间，即可实现对多个目标消息的读取状态的批量处理，避免了客户端和服务端之间的多次交互，减轻了服务端的数据处理负担，以及客户端与服务端之间的数据传输负担。

图5为本申请实施例五提供的一种消息读取状态的确定方法流程示意图；与上述实施例四相同之处在于，仍然从服务器这一侧进行描述；而与上述实施例四不同的是，主要增加了统计未读消息的处理步骤。具体地，如图5所示，其包括如下步骤s501-s504：

s501、接收客户端发送的消息轮询请求。

s502、根据消息轮询请求确定客户端前次进行消息请求操作的第一读取时间。

s503、根据第一读取时间，统计目标消息中的未读消息的数量。

具体地，可以根据第一读取时间在服务端进行开放式搜索(opensearch)，从而快速地统计出未读消息的数量。当然，在其他实施例中，也可以采用其他方式去统计未读消息的数量，而具体采用那种方式可根据服务端搜索配置和/或数据库的配置确定。

s504、将第一读取时间和未读消息的数量发送至客户端。

本实施例中，在服务端配置有轮询请求接口，因此，具体实现时可以通过轮询请求接口接收所述客户端发送的消息轮询请求，并向所述客户端返回所述第一读取时间。

本实施例中，服务端接收客户端启动触发发送的消息轮询请求，基于此确定第一读取时间。其中，消息轮询请求中携带有用户的信息如用户的标识或客户端的标识，根据该用户的信息返回对应的所述第一读取时间，进一步地，可根据第一读取时间确定未读消息的数量，并向客户端发送第一读取时间和未读消息的数量。

s505、通过消息列表接口接收客户端发送的消息获取请求。

本实施例中，与上述实施例不同的是，服务端接收消息获取请求时，具体通过服务端的消息列表接口接消息获取请求。即在服务端上配置有消息列表接口，从而可以有效地保证服务端可获取消息获取请求。

如前所述，该消息获取请求是因用户访问消息中心产生，尤其可见，当客户端启动时，服务端接收客户端发送的消息轮询请求，以从服务端获取所述第一读取时间，而进一步当访问消息中心时，服务端进一步接收客户端发送的携带有客户端前次进行消息请求操作的第一读取时间的消息获取请求，从而基于同一所述第一读取时间进行统计，避免了在由于发送消息轮询请求和消息获取请求之间存在时间差，而无法准确统计出未读消息的数量的情形发生。

s506、确定存储的消息列表中的目标消息的产生时间。

s507、根据所述目标消息的产生时间以及所述第一读取时间，确定所述目标消息的读取状态。

s508、向所述客户端返回携带有所述读取状态的目标消息。

其中，上述步骤s506-s508可参照实施例四中相关部分的描述，在此不再赘述。

通过本实施例，服务端根据目标消息和产生时间和客户端的第一读取时间，即可实现对多个目标消息的读取状态的批量处理，避免了客户端和服务端之间的多次交互，减轻了服务端的数据处理负担，以及客户端与服务端之间的数据传输负担。

图6为本申请实施例六提供的一种消息读取状态的确定方法流程示意图；与上述实施例四和五相同之处在于，仍然从服务器这一侧进行描述；而与上述实施例不同的是，主要增加了对第一读取时间进行更新的处理步骤。具体地，如图6所示，其包括如下步骤：

s601、接收客户端发送的消息获取请求，所述消息获取请求中携带有所述客户端前次进行消息请求操作的第一读取时间。

s602、确定存储的消息列表中的目标消息的产生时间。

s603、根据目标消息的产生时间以及第一读取时间，确定目标消息的读取状态。

s604、向客户端返回携带有所述读取状态的目标消息。

本实施例中，有关步骤601-s604的详细解释可参见上述实施例四至五中相应部分的描述，在此不再赘述。当然，在其他实施例中，步骤601-s604也可以采用不同的方式来实施。

s605、将向客户端返回目标消息对应的时间作为第二读取时间，并根据第二读取时间更新第一读取时间。

比如，用户在客户端查看消息时，会进行翻页操作，以查看不同的消息，因此，每个翻页操作都会对应有相应的时间，以此作为第二读取时间，并向服务端发送，以使服务端根据所述第二读取时间更新所述第一读取时间信息。

通过本实施例，服务端根据目标消息和产生时间和客户端的第一读取时间，即可实现对多个目标消息的读取状态的批量处理，避免了客户端和服务端之间的多次交互，减轻了服务端的数据处理负担，以及客户端与服务端之间的数据传输负担。

图7为本申请实施例七提供的一种消息读取状态的确定装置结构示意图，该确定装置可以设置在客户端所在设备；具体地，如图7所示，其包括：

请求发送单元701，用于根据对消息中心的访问操作向服务端发送消息获取请求，所述消息获取请求用于向所述服务端请求消息，所述消息获取请求中携带有前次向所述服务端进行消息请求操作的第一读取时间；以及

目标消息接收单元702，用于接收所述服务端返回的携带有读取状态的目标消息，所述读取状态根据所述目标消息的产生时间以及所述第一读取时间确定。

有关请求发送单元、目标信息接收单元所起技术作用的示例性解释，可参参见上述相关实施例的记载。

可选地，本申请任意实施例中，若所述目标消息的产生时间大于所述第一读取时间，则所述目标消息的读取状态为未读状态；或者，若所述目标消息的产生时间小于等于所述第一读取时间，则所述目标消息的读取状态为已读状态。

可选地，本申请任意实施例中，所述装置还包括：轮询请求发送单元，用于向所述服务端发送消息轮询请求，并接收所述服务端根据所述消息轮询请求返回的所述第一读取时间。

可选地，本申请任意实施例中，所述轮询请求发送单元具体用于向所述服务端的轮询请求接口发送所述消息轮询请求，并接收所述服务端根据所述消息轮询请求返回的所述第一读取时间。

可选地，本申请任意实施例中，所述请求发送单元701具体用于根据对所述消息中心的访问操作，向所述服务端的消息列表接口发送所述消息获取请求。

可选地，本申请任意实施例中，所述装置还包括：未读消息数量接收单元，用于接收所述服务端发送的未读消息的数量以进行展示，所述未读消息的数量根据所述第一读取时间统计确定。

可选地，本申请任意实施例中，若所述目标消息的数量为多个，则多个所述目标消息被划分为至少两个消息级别，根据所述目标消息的产生时间以及所述第一读取时间确定所述读取状态的目标消息为所述至少两个消息级别中至少一消息级别的目标消息，所述目标消息被划分为的消息级别根据所述目标消息的内容或消息类型确定。

可选地，本申请任意实施例中，所述装置还包括：展示单元，用于基于信息流或卡片流的形式在所述消息中心的界面中展示所述目标消息。

通过本实施例，在消息获取请求中携带有前次向服务端进行消息请求操作的第一读取时间，以此便于服务端确定目标消息的读取状态并向客户端反馈。基于此，实现了客户端展示的目标消息的读取状态的批量处理，避免了针对每个目标消息在客户端和服务端之间进行多次交互，从而降低了客户端开发成本和数据处理负担，也降低了用户的操作负担，并且减少了客户端和服务端之间的数据传输负担。

图8为本申请实施例八提供的一种消息读取状态的确定装置结构示意图，本实施例的确定装置可设置在服务端；如图8所示，其包括：

请求接收单元801，用于接收客户端发送的消息获取请求，所述消息获取请求中携带有前次进行消息请求操作的第一读取时间；

时间确定单元802，用于确定存储的消息列表中的目标消息的产生时间；

读取状态确定单元803，用于根据所述目标消息的产生时间以及所述第一读取时间，确定所述目标消息的读取状态；以及

消息返回单元804，用于向所述客户端返回携带有所述读取状态的所述目标消息。

可选地，本申请任意实施例中，所述读取状态确定单元803包括：未读状态确定单元，用于若所述目标消息的产生时间大于所述第一读取时间，则确定所述目标消息的读取状态为未读状态；已读状态确定单元，用于若所述目标消息的产生时间小于等于所述第一读取时间，则确定所述目标消息的读取状态为已读状态。

可选地，本申请任意实施例中，所述装置还包括：轮询请求接收单元，用于接收所述客户端发送的消息轮询请求，并向所述客户端返回所述第一读取时间。

可选地，本申请任意实施例中，所述轮询请求接收单元具体用于，通过轮询请求接口接收所述客户端发送的消息轮询请求，并向所述客户端返回所述第一读取时间。

可选地，本申请任意实施例中，所述轮询请求接收单元，包括：第一读取时间确定单元，用于接收所述客户端发送的消息轮询请求，根据所述消息轮询请求确定所述第一读取时间；未读消息统计单元，用于根据所述第一读取时间，统计所述目标消息中的未读消息的数量；未读消息发送单元，用于将所述第一读取时间和所述未读消息的数量发送至所述客户端。

可选地，本申请任意实施例中，所述请求接收单元801具体用于通过消息列表接口接收所述客户端发送的消息获取请求。

可选地，本申请任意实施例中，所述装置还包括：第二读取时间返回单元，用于将向所述客户端返回所述目标消息对应的时间作为第二读取时间，并根据所述第二读取时间更新所述第一读取时间。

可选地，本申请任意实施例中，若所述目标消息的数量为多个，则所述装置还包括：级别确定单元，用于根据多个所述目标消息的内容或消息类型，确定多个所述目标消息分别对应的消息级别，所述消息级别的数量为至少两个；

针对所述至少两个消息级别中至少一消息级别的目标消息，通过读取状态确定单元803确定目标消息的读取状态。

可选地，本申请任意实施例中，所述消息返回单元804具体用于向所述客户端返回携带有所述读取状态的目标消息，以基于信息流或卡片流的形式在所述客户端的消息中心的界面中展示所述目标消息。

通过本实施例，服务端根据目标消息和产生时间和客户端的第一读取时间，即可实现对多个目标消息的读取状态的批量处理，避免了客户端和服务端之间的多次交互，减轻了服务端的数据处理负担，以及客户端与服务端之间的数据传输负担。

实施例九

参照图9，示出了本发明实施例九的一种电子设备的结构示意图，本发明具体实施例并不对电子设备的具体实现做限定。

如图9所示，该电子设备可以包括：处理器(processor)901、通信接口(communicationsinterface)902、存储器(memory)903、以及总线904。

其中：

处理器901、通信接口902、以及存储器903通过通信总线904完成相互间的通信。

通信接口902，用于与其它电子设备或服务器进行通信。

处理器901，用于执行程序905，具体可以执行上述消息读取状态的确定方法实施例中的相关步骤。

具体地，程序905可以包括程序代码，该程序代码包括计算机操作指令。

处理器901可能是中央处理器cpu，或者是特定集成电路asic(applicationspecificintegratedcircuit)，或者是被配置成实施本发明实施例的一个或多个集成电路。智能设备包括的一个或多个处理器，可以是同一类型的处理器，如一个或多个cpu；也可以是不同类型的处理器，如一个或多个cpu以及一个或多个asic。

存储器903，用于存放程序905。存储器903可能包含高速ram存储器，也可能还包括非易失性存储器(non-volatilememory)，例如至少一个磁盘存储器。

在一种可将所述电子设备作为客户端设备的可行方式中，程序905具体可以用于使得处理器901执行以下操作：根据对消息中心的访问操作向服务端发送消息获取请求，所述消息获取请求用于向所述服务端请求消息，所述消息获取请求中携带有前次向所述服务端进行消息请求操作的第一读取时间；以及接收所述服务端返回的携带有读取状态的目标消息，所述读取状态根据所述目标消息的产生时间以及所述第一读取时间确定。

在一种可选的实施方式中，若所述目标消息的产生时间大于所述第一读取时间，则所述目标消息的读取状态为未读状态；或者，若所述目标消息的产生时间小于等于所述第一读取时间，则所述目标消息的读取状态为已读状态。

在一种可选的实施方式中，程序905还用于使得处理器901向所述服务端发送消息轮询请求，并接收所述服务端根据所述消息轮询请求返回的所述第一读取时间。

在一种可选的实施方式中，程序905还用于使得处理器901在向所述服务端发送消息轮询请求，并接收所述服务端根据所述消息轮询请求返回的所述第一读取时间时：向所述服务端的轮询请求接口发送所述消息轮询请求，并接收所述服务端根据所述消息轮询请求返回的所述第一读取时间。

在一种可选的实施方式中，程序905还用于使得处理器901在根据对消息中心的访问操作向服务端发送消息获取请求时：根据对所述消息中心的访问操作，向所述服务端的消息列表接口发送所述消息获取请求。

在一种可选的实施方式中，程序905还用于使得处理器901在所述根据对消息中心的访问操作向服务端发送消息获取请求之后：接收所述服务端发送的未读消息的数量以进行展示，所述未读消息的数量根据所述第一读取时间统计确定。

在一种可选的实施方式中，若所述目标消息的数量为多个，则多个所述目标消息被划分为至少两个消息级别，根据所述目标消息的产生时间以及所述第一读取时间确定所述读取状态的目标消息为所述至少两个消息级别中至少一消息级别的目标消息，所述目标消息被划分为的消息级别根据所述目标消息的内容或消息类型确定。

在一种可选的实施方式中，程序905还用于使得处理器901基于信息流或卡片流的形式在所述消息中心的界面中展示所述目标消息。

在另一种可将所述电子设备作为服务端设备的可行方式中，程序905具体可以用于使得处理器901执行以下操作：接收客户端发送的消息获取请求，所述消息获取请求中携带有所述客户端前次进行消息请求操作的第一读取时间；确定存储的消息列表中的目标消息的产生时间；根据所述目标消息的产生时间以及所述第一读取时间，确定所述目标消息的读取状态；以及向所述客户端返回携带有所述读取状态的目标消息。

在一种可选的实施方式中，程序905还用于使得处理器901在根据所述目标消息的产生时间以及所述第一读取时间，确定所述目标消息的读取状态时：若所述目标消息的产生时间大于所述第一读取时间，则确定所述目标消息的读取状态为未读状态；或者，若所述目标消息的产生时间小于等于所述第一读取时间，则确定所述目标消息的读取状态为已读状态。

在一种可选的实施方式中，程序905还用于使得处理器901在所述接收客户端发送的消息获取请求之前：接收所述客户端发送的消息轮询请求，并向所述客户端返回所述第一读取时间。

在一种可选的实施方式中，程序905还用于使得处理器901在接收所述客户端发送的消息轮询请求，并向所述客户端返回所述第一读取时间时：通过轮询请求接口接收所述客户端发送的消息轮询请求，并向所述客户端返回所述第一读取时间。

在一种可选的实施方式中，程序905还用于使得处理器901在接收所述客户端发送的消息轮询请求，并向所述客户端返回所述第一读取时间时：接收所述客户端发送的消息轮询请求，根据所述消息轮询请求确定所述第一读取时间；根据所述第一读取时间，统计所述目标消息中的未读消息的数量；将所述第一读取时间和所述未读消息的数量发送至所述客户端。

在一种可选的实施方式中，程序905还用于使得处理器901在接收客户端发送的消息获取请求时：通过消息列表接口接收所述客户端发送的消息获取请求。

在一种可选的实施方式中，程序905还用于使得处理器901将向所述客户端返回所述目标消息对应的时间作为第二读取时间，并根据所述第二读取时间更新所述第一读取时间。

在一种可选的实施方式中，若所述目标消息的数量为多个，程序905还用于使得处理器901根据多个所述目标消息的内容或消息类型，确定多个所述目标消息分别对应的消息级别，所述消息级别的数量为至少两个；针对所述至少两个消息级别中至少一消息级别的目标消息，程序905还用于使得处理器901执行根据所述目标消息的产生时间以及所述第一读取时间，确定所述目标消息的读取状态的步骤。

在一种可选的实施方式中，程序905还用于使得处理器901在向所述客户端返回携带有所述读取状态的目标消息时：向所述客户端返回携带有所述读取状态的目标消息，以基于信息流或卡片流的形式在所述客户端的消息中心的界面中展示所述目标消息。

程序905中各步骤的具体实现可以参见上述消息读取状态的确定方法实施例中的相应步骤和单元中对应的描述，在此不赘述。所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的设备和模块的具体工作过程，可以参考前述方法实施例中的对应过程描述，在此不再赘述。

通过本实施例的电子设备，在消息获取请求中携带有前次向服务端进行消息请求操作的第一读取时间，以此便于服务端确定目标消息的读取状态并向客户端反馈。基于此，实现了客户端展示的目标消息的读取状态的批量处理，避免了针对每个目标消息在客户端和服务端之间进行多次交互，从而降低了客户端开发成本和数据处理负担，也降低了用户的操作负担，并且减少了客户端和服务端之间的数据传输负担。

需要指出，根据实施的需要，可将本发明实施例中描述的各个部件/步骤拆分为更多部件/步骤，也可将两个或多个部件/步骤或者部件/步骤的部分操作组合成新的部件/步骤，以实现本发明实施例的目的。

上述根据本发明实施例的方法可在硬件、固件中实现，或者被实现为可存储在记录介质(诸如cdrom、ram、软盘、硬盘或磁光盘)中的软件或计算机代码，或者被实现通过网络下载的原始存储在远程记录介质或非暂时机器可读介质中并将被存储在本地记录介质中的计算机代码，从而在此描述的方法可被存储在使用通用计算机、专用处理器或者可编程或专用硬件(诸如asic或fpga)的记录介质上的这样的软件处理。可以理解，计算机、处理器、微处理器控制器或可编程硬件包括可存储或接收软件或计算机代码的存储组件(例如，ram、rom、闪存等)，当所述软件或计算机代码被计算机、处理器或硬件访问且执行时，实现在此描述的消息读取状态的确定方法。此外，当通用计算机访问用于实现在此示出的消息读取状态的确定方法的代码时，代码的执行将通用计算机转换为用于执行在此示出的消息读取状态的确定方法的专用计算机。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及方法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明实施例的范围。

以上实施方式仅用于说明本发明实施例，而并非对本发明实施例的限制，有关技术领域的普通技术人员，在不脱离本发明实施例的精神和范围的情况下，还可以做出各种变化和变型，因此所有等同的技术方案也属于本发明实施例的范畴，本发明实施例的专利保护范围应由权利要求限定。