之前一篇說了ios推送證書的生成。這是開發(fā)推送的基礎(chǔ)環(huán)境。這次介紹的是怎么去開發(fā)。
來幾句廢話：
蘋果的推送相比于安卓的推送，顯得更加清晰，簡明許多。首先不必考慮那么多廠商配置，其次蘋果的送達率要比安卓高，也很快速。所以一旦你開發(fā)的Apple能接收到第一條通知欄且流程正常，那么在后續(xù)的測試中，就很少會出問題。相比于Android而言，有時廠商通道過來消息會收不到或者延遲時間長，這當(dāng)然區(qū)別于不同的廠商及不同機型。廢話不多說，看看怎么做ios的推送。

一、原理介紹

其實更詳細的原理介紹在這篇文章，App推送。如果你事先看過這篇，可能理解接下來的介紹會清晰很多，這里原理介紹不多，只是說前后端的代碼及關(guān)鍵的參數(shù)怎么操作。
iOS的推送涉及個推和蘋果APNs推送。

• 在線，即app在前臺打開運行時，消息通過個推通道下發(fā)到客戶端。
• 離線，即app在后臺、鎖屏?xí)r，消息將通過個推側(cè)請求對應(yīng)廠商側(cè)的服務(wù)端，由蘋果進行推送。

二、服務(wù)端選擇方案

1、個推選擇的是透傳消息類型，
即 push_message中的transmission，這里的透傳內(nèi)容不再拘泥于UNIPUSH要求的數(shù)據(jù)格式，是自定義的內(nèi)容。個推通道對于ios是不支持通知消息的。實際中，開發(fā)者可以跟安卓共用代碼，即不用做任何區(qū)分。

2、廠商推送，iOS建議選擇這種通知消息類型的方式，即 push_channel =》ios=>type選notify，payload是自定義數(shù)據(jù)，這個數(shù)據(jù)不必拘束unipush規(guī)定數(shù)據(jù)，aps=>alert=>title,body；這種方式會顯示通知欄，客戶端點擊觸發(fā)click事件，payload即為客戶端獲取到的數(shù)據(jù)。具體的參數(shù)參考個推文檔去查看，但這幾個參數(shù)是要特別注意的。注意在下發(fā)策略時，參數(shù)ios的選擇似乎已經(jīng)不重要了，可以不選擇，default做選擇就行。

三、客戶端的操作

這里要說明的一點是，客戶端的對于消息的處理方式跟服務(wù)端選擇的下發(fā)策略及消息類型是至關(guān)重要的，所以一定要跟服務(wù)端配合好，否則可能會出現(xiàn)，服務(wù)端通知下發(fā)成功了，但客戶端出現(xiàn)的情況會五花八門，很難找到規(guī)律去處理。而這篇文章主要解決的問題就是將服務(wù)端和客戶端統(tǒng)一起來，避免前后端的開發(fā)者做到懷疑人生。
第二部分介紹了服務(wù)端幾個重要的參數(shù)，接下來的介紹是建立在第二部分的基礎(chǔ)上所做的操作，所以如果服務(wù)端的選擇是其他方式，那么下面的介紹可能會出現(xiàn)其他不可預(yù)知的情況。

• 1、對于個推透傳消息的處理。
  如果按照UNIPUSh封裝好的數(shù)據(jù)格式，對于安卓，則會新建通知欄，只觸發(fā)click事件，但對于iOS，會觸發(fā)receive事件，所以需要客戶端 監(jiān)聽到receive事件時，自建通知欄，但iOS自建通知欄，還會再觸發(fā)receive事件，所以這里有個aps標識。即自建通知欄的aps值為null，ios通過APNS過來的aps是有值的，所以以此來處理通知欄問題，避免出現(xiàn)通知欄重建循環(huán)的問題。
  代碼如下，僅供參考

plus.push.addEventListener('receive', function(message) {
            console.log('receive接受消息')
            console.log(message)
            var data=message.payload
            console.log(data)
            if(message.aps){//aps下發(fā)的消息，應(yīng)用在前臺
                var options={
                    title:message.title
                }
                 var localData=data
                 localData.type='Local' //用于做本地創(chuàng)建通知欄的標識
                 console.log(localData)
                 // 新建本地通知欄,還會觸發(fā)receive事件，但此時的aps為null，以此來對通知欄循環(huán)創(chuàng)建的處理；
        plus.push.createMessage(message.content,JSON.stringify(localData),options)
            }else if(JSON.parse(message.payload).type =='Local'){
                // 本地創(chuàng)建的通知欄所觸發(fā)的事件，不做任何處理
                console.log('本地創(chuàng)建的消息，不做處理')
             }else{//這是個推透傳過來的消息， 對iOS而言，要處理通過個推過來的透傳消息，此時的aps為null，要新建通知欄進行展示
                console.log('個推透傳消息過來的數(shù)據(jù)')
            }
        },false);

• 2、對于Apns通道的處理。
  廠商通道的下發(fā)，會展示通知欄。但當(dāng)在消息有效期內(nèi)，打開APP時，push_message中的transmission內(nèi)容還將通過個推通道傳遞給客戶端，此時可在客戶端透傳回調(diào)中的參數(shù)pushmessage對象中獲取aps屬性值來片段是否是APNs下發(fā)的內(nèi)容；這個是比較關(guān)鍵的，在處理receive事件時要注意，不然會出現(xiàn)點擊通知欄啟動App時，再次新建出通知欄展示。
  參考代碼如下

plus.push.addEventListener('click', function(message) {
        console.log('click事件')
        console.log(message.payload) //自定義過來的數(shù)據(jù)
        if(message.aps){//ios點擊的廠商推送,離線情況下
            console.log('ios點擊事件')
            var data=message.payload
        }else{//android或者是iOS的自建通知欄時，所觸發(fā)的click事件
            console.log('android點擊事件')
            if(plus.os.name=='iOS'){
                var data=JSON.parse(message.payload)
            }else{
                var data=message.payload
            }
         }
        //對data進行自身的業(yè)務(wù)處理
})

最后要說明的是，unipush的推送，所涉及到的推送方案，消息類型，參數(shù)等要以unipush的文檔為主，個推的api作為參考，原因是unipush對某些參數(shù)做了處理，所以最后的結(jié)果會跟個推文檔敘述有不一致的東西。所以推送時，客戶端常常會出現(xiàn)各種各樣的問題，但大部分關(guān)鍵因素都在于服務(wù)端的選擇，所以一定要跟服務(wù)端去做好溝通，這至關(guān)重要.
這篇文章可能小白看了一頭霧水，但如果開發(fā)者正在試著做unipush的推送，那這篇文章或者對你大有用處。有問題留言評論，看到會回復(fù)的。