前兩天群里有兄弟在吐槽，做遠程推送的時候：老闆要求APP桌面圖標的右上角顯示紅色未讀數字（數字角標）要精準，有多少未讀通知就顯示數字幾；但是後臺的弟兄在發送推送通知的時候，每次的角標是1，然後要移動端這邊自己去把這個未讀數字去累加，然後顯示在APP上；並且後臺非常固執的認為這個累加未讀消息數量是在移 ...
前兩天群里有兄弟在吐槽，做遠程推送的時候：老闆要求APP桌面圖標的右上角顯示紅色未讀數字（數字角標）要精準，有多少未讀通知就顯示數字幾；但是後臺的弟兄在發送推送通知的時候，每次的角標是1，然後要移動端這邊自己去把這個未讀數字去累加，然後顯示在APP上；並且後臺非常固執的認為這個累加未讀消息數量是在移動端處理的.....
這就尷尬了，碰到固執的隊友，溝通不成的時候確實是很痛苦的！
這裡我說說自己在做推送功能時候的這個角標的驗證過程和理解，給後面的為碰到類似情況的同學一些參考。
隨便截個圖舉個例子看看
當APP是處於後臺的時候，實現這個還是好說的，因為當推送通知到達的時候是可以監聽到的，可以獲取到推送信息裡面的角標數字然後進行累加。
但是當APP完成退出後臺的時候，想要app監聽到通知並且讀取通知信息設置角標，這個好像是辦不到的！
後臺推送消息的格式按照蘋果官方提供的格式，大致是這樣：
{ "aps" : { "alert" : { "title" : "Game Request", "body" : "Bob wants to play poker", "action-loc-key" : "PLAY" }, "badge" : 5 }, "acme1" : "bar", "acme2" : [ "bang", "whiz" ] }
“aps”格式是固定的，後面的"acme1", "acme2”是自定義的數據。其中“badge"就是app的角標數字
所以要證實APP的桌面紅色角標（未讀消息數字）到底是由後臺控制的還是移動端自己控制的，這個很容易。
讓app內部不要自己操作角標變化，或者把該app完全退出，然後後臺開始推送，假設推送的消息badge是數字幾，而且app的角標也是顯示數字幾，
這個就足以證明app的紅色角標是由後臺推送時候控制的了！
當然話說回來，想要實現對app這個角標的精準顯示，需要一個強大的後臺：對每個會員在app的讀取未讀消息進行追蹤記錄上報，
然後下次推送的時候，對每個會員要進行未讀消息的統計，然後在推送消息裡面設置精準的badge數字。就能做到app精準的顯示未讀消息數字了。
我們看比如QQ，微信等app，它們的角標數字是做的非常精準的，人家的後臺之強大，那是沒得比的。
但是我們一般的APP, 你也想做到角標精準？有必要嗎？你連做推送都是用了第三方的推送sdk如極光、個推，你還想做到精準顯示角標，你去看看極光和個推對於群推的方法，
壓根都沒提供精準設置badge的位置，說明想實現精準實現角標，專門研究推送的這些第三方公司也覺得難度很大，或者說要付出很大的代價！
一般來說，大多數app的角標數字做的是意思意思，沒那個精準，我測試過的有百度地圖、簡書、新浪財經等等，app的角標顯示也沒有做什麼精準顯示。所以對於咱們做的如果是一個普通的app， 角標數字的顯示也就意思意思就行了，主要是為了提醒用戶你有未讀消息嘛！真的想做到精準顯示角標，那就要和後臺的兄弟談好，讓他們做好準備加油開乾把！
