1.如果設(shè)備offline品追，APNs的策略是什么？
根據(jù)蘋果的官方文檔卒茬，如果設(shè)備離線船老，APNs會啟動QoS機制，實現(xiàn)原理：針對該device token和該app圃酵，APNs只會保留來自provider的最后一個消息柳畔，即新的消息會覆蓋舊的消息。所以如果你的朋友手機關(guān)機或者飛行模式郭赐，你給他發(fā)10條微信薪韩，如果微信Provider不做特殊處理的話，你朋友再次啟動手機的時候只會收到最后一條消息提醒捌锭。
2. device token什么時候會變俘陷？
Device和App的四種組合，這里我們討論的是同一Device的同一App观谦，其他三種組合device token肯定都不一樣的拉盾。
一般情況下，App每次啟動從APNs獲取的device token是不會變的豁状。但是有以下幾種特殊情況：
（1）iOS系統(tǒng)升級盾剩，這個可能會導(dǎo)致拿到不同的device token。
（2）App卸載重裝替蔬，這種情況在iOS 7/8下是沒問題的，但是在iOS9/10系統(tǒng)下屎暇，拿到的device token就是不同的承桥。
（3）APNs禁用你的device token，因為某些原因根悼，比如安全問題凶异，之前獲取的device token失效，這時候再次獲取的時候也是不同的挤巡。
面對這些不確定的因素剩彬，可以采取的策略是每次都重新獲取device token，跟本地緩存的比較矿卑，如果相同喉恋，則不用更新。如果不同母廷，則向自己的服務(wù)器去更新轻黑，同時更新本地緩存的token。
3. 如何提高推送消息的送達率
APNs跟device的長鏈接由iOS操作系統(tǒng)建立和管理琴昆，我們無法控制氓鄙，我們能控制的是Provider跟APNs的通信，如何減少消息丟失以及避免重復(fù)消息可以在這里做一點研究业舍。
先來看下無效token的情況抖拦，上面說的devicetoken可能會改變或者失效升酣，這時候provider再給這個token發(fā)推送就會導(dǎo)致APNs返回失敗。因為provider與APNs之間也是通過TCP長鏈接态罪，這個失敗報錯不會立刻返回噩茄，而是要我們的服務(wù)器主動去監(jiān)聽。而且一旦有一個失敗向臀，后續(xù)的推送將會全部失敗巢墅，連接也會被延時斷開。所以如何準(zhǔn)確的定位哪個消息推送失敗券膀，是解決所有問題的關(guān)鍵君纫。
蘋果定義了推送消息體的結(jié)構(gòu)，其中有個字段identifier是消息的唯一標(biāo)志符芹彬。推送失敗的情況下蓄髓，會返回給provider這個identifier，可以通過獲取這個值來定位失敗的消息舒帮，從而可以構(gòu)造下一批重新推送的消息集合会喝。
還有一個feedback service也是APNs的配套，蘋果會把失敗的device token維護在這個服務(wù)器上的一個列表玩郊，provider可以定期去獲取這個列表肢执，來更新本地服務(wù)器的token列表，從而可以減少無效的token译红，也就減少了失敗的推送以及重連的次數(shù)预茄。
4. iOS10的推送新特性
iOS10的推送更加豐富了，增加了聲音侦厚，圖片視頻的推送耻陕，需要extention的支持，這可能是需要客戶端最大改動的部分刨沦。交互方式也大大增加诗宣，支持多個category和action，用戶可以自定義行為想诅。
