為什么只有某些設備會收到推送通知

Question

我設置了一個推送通知服務，以基於RSS提要向客戶端發送通知。 我有每分鍾運行一次的服務，以查看是否有新帖子添加到了提要中。 如果是這樣，該服務將向所有客戶端發出通知。 但是，有些人一直抱怨說他們沒有收到任何推送通知。 這是我用來發送消息的功能：

function _sendMessages($tokens, $message) {
        $payload['aps'] = array('alert' => $message, 'sound' => 'default');
        $payload = json_encode($payload);

        $context = stream_context_create();
        stream_context_set_option($context, 'ssl', 'local_cert', $this->certificate);
        stream_context_set_option($context, 'ssl', 'passphrase', '*********');

        $apns = stream_socket_client('ssl://' . $this->server . ':' . $this->port, $error, $errorString,60, STREAM_CLIENT_CONNECT, $context);

        foreach($tokens as $row) {
            $apnsMessage = chr(0) . chr(0) . chr(32) . pack('H*', str_replace(' ', '', $row->device_token)) . chr(0) . chr(strlen($payload)) . $payload;
            $fwrite = fwrite($apns, $apnsMessage);

            if (!$fwrite) echo 'push error';
            else echo 'push success';
        }

        fclose($apns);
    }

我做錯什么了嗎？ PHP不能處理數千次遍歷此循環並通過連接流式傳輸消息嗎？

Answer 1

除了其他人已經提出的建議之外，還有一些清單，這些清單在推送無效時要考慮的事項。

1. 如果您的總推送數據包超過256個字節（包括初始標頭，令牌和JSON有效負載），APNS會直接將其丟棄。 如果您不使用“高級”錯誤檢測，則直到您的用戶開始抱怨之前，您才知道。 您需要做的是檢查編碼的數據包大小，即要抽出線路的實際數據的大小，如果它大於256個字節，則拒絕它，或者切斷某些消息文本並進行編碼直到它的長度小於等於256個字節為止。
2. 如果您的有效載荷以任何方式（包括長度）有任何問題，APNS都會丟棄它，而APNS也會斷開您的連接。
3. 如果您有一個持續的連接，並且閑置了大約20分鍾左右，APNS將靜默斷開連接。 您必須為此做好准備並重新連接。
4. 如果您的APNS證書已過期或不正確，並且您繼續嘗試以太高的速率進行連接，則APNS會將您的IP地址列入黑名單的時間未知，但這要花幾分鍾，甚至是一個小時或更長時間。
5. 如果iPhone沒有3G接收，但是有WiFi，它將嘗試將其用於推送通知。 如果您所在的防火牆區域不允許與Apple網絡的出站連接，那么您的iPhone將無法打開APNS的套接字，並且您是SOL。
6. 我不確定每次客戶端連接到APNS時是否使用推送令牌更新您的SQL DB。 具有推送令牌的靜態數據庫是一個問題，因為推送令牌不會永遠保持不變-甚至在APNS編程指南中也是如此。 iPhone應該在每次啟動時獲取推送令牌，並將其傳遞到服務器端（而且我相信您可以對其進行優化-iPhone可以持久存儲最后一個令牌，並且只有在更改后才發送）。 但是有些事情可能會導致推送令牌發生更改，例如重新注冊iPhone以進行推送，但我不確定還有什么。 我所知道的是，依賴於推送令牌就像GUID一樣會帶來麻煩。 下次令牌更改時，如果您的數據庫未更新，請再推到該客戶端。

希望這可以幫助。

Answer 2

我認為這里存在3個潛在問題：

1）您連接的頻率太高（可能比您想像的要頻繁），而Apple拒絕/斷開連接是因為它認為您太垃圾了。 坦白地說，這將是顯而易見的-由於流已失效，因此您的fwrite將會失敗。

理想情況下，APNS希望連接保持盡可能長的打開時間（10分鍾是我們使用的不活動超時），而不是每分鍾重新建立一次。 SSL協商需要花費CPU，但是保持開放狀態的連接相對便宜。 因此，如果可以的話，我會在運行之間保持該連接的打開狀態，如果由於任何原因將其刪除，則會自動重新建立該連接。

2）您沒有進行任何錯誤檢查。 請參閱《 APNS指南》，但它可能會通過錯誤響應沿着相同的連接進行響應，而您只是忽略了這一點。 我認為，每次循環時，您都應該檢查是否有任何數據要讀取，讀取並將其解釋為錯誤響應數據包。 至少您應該注銷錯誤響應。

3）這是一個遠射。 您是否真的可能刪除了這些用戶，也許是因為反饋服務告訴您？ 如果用戶長時間斷開連接，則該服務將無法發送通知，並且該通知可能會告訴您從列表中刪除這些設備。 如果您在應用啟動時不重新訂閱這些用戶（或至少確認他們仍在訂閱），那么實際上您已經選擇忘記他們時，他們會認為他們已訂閱了通知。

Answer 3

嗯...我沒有發現任何問題。 客戶實際上是否為您的應用程序啟用了推送通知？