求教IM的ios端未读消息数应该如何统计(比如APP角标上的未读数)

现在在做一个IM的项目，首先说明这个未读数是指，显示在App图标右上角的红色数字，这个红色数字等于App所有会话未读消息的总数。
当App在运行时，我们可以自己在本地维护好消息的未读数，有消息进来时未读数加1，当点进去某个人的会话的话，那么就让总的未读数减去这个会话的未读数。可是问题来了，当我的App没有运行时，代码根本没有运行啊，我没办法统计啊，所以就猜想这个数应该是后台给手机发推送的时候一起带过来的，对于iOS平台来说，服务器发推送的时候有一个字段叫badgeNum，如果这个badgeNum = 10，那么所有收到推送的用户的App角标都会自动变为10了。我的问题是，如果一个有1000人的群聊，里面任何人每发一条消息，都由服务器去统计其他人的未读数，然后再分别给每个人发一条不同的推送消息（不能统一发是因为badgeNum每个人可能都不同），消耗的资源会不会太大？是不是我的思路不对？不知道还有没有其他什么好的办法

看起来你对ios的推送技术本身好像还不是特别了解，你可以把这篇顺便也读一读《了解iOS消息推送一文就够：史上最全iOS Push技术详解》。

好了，下面我来说说我的思路。

iOS的APP上的未读数角标，最常用的是两种设置方法：

• 1）收到服务端后端推送（这个最常见）后，系统自动设置；
• 2）进入APP后的程序内设置。
  

基本上，第一种方法（也就是你帖子内讨论的思路）如果要想保证这个数字的准确性，服务端的逻辑会非常复杂，而且还不一定能保证准确，原因是：

• 1）现在移动端都是直接拉取本缓存本地消息的，至于用户真的有没有读，服务端其实是不知道的，要按你的思路，那app每读一次就要提交一次服务端（告之服务端已读）；
• 2）加上现在多端同步逻辑，这个已读未读就更复杂了。
  

综上：为了保证这个数字的准确性，服务端来做不合适。

回归到事情的本质：
这个未读数角标的目的就是为了告诉你，有未读消息，至于是5条、还是6条或者跟真实的数字差那么几条，很重要吗？（比如：你天天用微信，你有注意过真的是一致的吗？）。

其实，微信上的这个未读数，一样不准确：
比如我在回复你之前，刚图标上显示的未读是6，实际点开app后，里面的未读数是4（app内的未读是最准确的）。

所以，主流的实现方法，其本上是：

• 1）服务端可以推送通知，但没有必要完全让服务端来保证这个准确性（也不太容易办到）；
• 2）服务端推送的数字不太准确也没关系，进入APP后，主动在APP内用真实的未读数来设置一下（即修正一遍，微信、qq也都是这样，你自已观察一下。另外，我的RainbowChat产品中也是这样处理的）。
  

以上就是我的思路和建议，不知你是否理解。

ios的服务端APNS推送API里，
没有办法做到推送的未读数在app端自已叠加上，
要是有这个特性就更方便了

APP桌面图标上的这个未读数很少能看到哪个im的app能完全搞对（普能的app相反更容易做到，因为已读未读都是通过服务端的接口更新服务端的数据），因为im里的消息惯用手法都是先拉下来缓存到本地后，再搞已读未读，有的还能做到多端消息同步，这个就更困难了。

要完全搞准确这个数字，对于整个IM来说，有点本末倒置了，够用就行了，小伙子

引用：JackJiang 发表于 2019-02-25 10:17
看起来你对ios的推送技术本身好像还不是特别了解，你可以把这篇顺便也读一读《了解iOS消息推送一文就够：史 ...

我以前就是用你提到的第二种方法，进入App后程序内设置。但是产品要求要把这个数字做成准确的，所有才考虑收到服务器推送后系统自动设置。但是服务器来统计好像真的太复杂了，没有任何头像，不知道微信是怎么做的

引用：IMDeveloper 发表于 2019-02-25 10:26
APP桌面图标上的这个未读数很少能看到哪个im的app能完全搞对（普能的app相反更容易做到，因为已读未读都是 ...

大神也没有搞好这一块吗？现在没有任何头绪，不知道微信是怎么做的。

引用：大马仕格 发表于 2019-02-25 10:23
ios的服务端APNS推送API里，
没有办法做到推送的未读数在app端自已叠加上，
要是有这个特性就更方便了

是的，现在没有任何头像，不知道微信是怎么做的

引用：Kevin_WuZLu 发表于 2019-02-25 14:48
我以前就是用你提到的第二种方法，进入App后程序内设置。但是产品要求要把这个数字做成准确的，所有才考 ...

其实微信的也不准确，不信你可以多开几个端，比如pc端+手机端+web端都开，反复用，很容易就碰到不一致的情况。

这是你产品经理故意难为你吧。稍微有点技术常识的都不至于非得要程序员这么干，明明可以讲清楚的

iOS 推送不靠谱，经常丢，特别是频繁推送的时候，也就是说就算服务器实时推未读消息数，也没法保证旗标准确，另外服务器实时推送也很耗。
   
推荐处理方案：   
    服务器的处理方案：间隔一段时间推送一次旗标

另外千万别做多端消息同步，巨坑

引用：大年初一 发表于 2019-04-29 20:51
iOS 推送不靠谱，经常丢，特别是频繁推送的时候，也就是说就算服务器实时推未读消息数，也没法保证旗标准确 ...

你踩过坑吧。。

踩过巨坑，苹果推送服渣渣

各位大佬有解决方案了吗

引用：renxianwei 发表于 2023-05-16 14:45
各位大佬有解决方案了吗

方案有多种:我说一种给你参考下吧:
行业通常有一个 专门的推送服务针对该用户(假设你只容许一个端同时在线)计数,每一个来的离线通知,推送服务都加1,并且保存: uid->count,然后推给苹果类服务; 然后如果用户一旦在线,就重置服务端count计数为0.
另外一种: ios 从7.x几开始可以 收到离线推送时后端执行一段代码,你可以利用这段代码从服务端拉取准确未读数也是可以的.希望帮到你

微信的其实不准的,你测试下看看,他其实不是真正的未读数;以前测试过他的策略

引用：renxianwei 发表于 2023-05-16 14:45
各位大佬有解决方案了吗

微信的策略以前测试就是离线期间的离线推送数,并不是真正的未读数;