iOSのAPNSと、AndroidのGCMの実装上の違いをまとめたいと思います。
APNSとGCMの違いまとめ表
思いつく限り、書き出してみました。追加で思いついたら書き足します。他にもあったら教えて下さい！
| iOS | Android | 備考 | |
| サービス名 | APNS | GCM | AndroidはかつてはC2DM |
| 提供元 | Apple | ||
| リリースバージョン | iOS 3.0 | Android 2.2 | |
| 送信のプロトコル | 独自プロトコル | HTTP | |
| 追加で必要なライブラリ | なし | Google Play Services | |
| 認証形式 | SSL | APIキー | |
| WEB設定画面 | Apple Developer Center | Google API Console | |
| シミュレータ利用 | 不可 | 不可 | |
| トークンの名前 | device token | registration id | |
| トークンのコールバック先 | UIApplicationDelegate | BroadCastReceiver | |
| トークン長 | 64バイト | 140〜205バイト | Androidは、ほぼこの範囲だが保証されていない。 |
| デバイストークンの変動 | 一部あり | あり | iOSはiOS7へのアップデートで発生 |
| トークン変動の検知 | 不可能 | 可能 | Androidは通知レスポンスから新しいトークンが取得可能 |
| トークン無効化の検知 | 可能 | 可能 | iOSは無効化日時も取得可能 |
| アプリ削除時のトークン | 無効化される | 無効化されない | |
| debug/releaseビルドの差 | あり | なし | iOSはdebugビルドの場合サンドボックス環境を利用する必要がある |
| dry run | 不可能 | 可能 | dry runは実際に通知しないで送信すること |
| サンドボックス環境 | 有り | 無し | |
| ペイロードの最大長 | 256バイト | 4096バイト | |
| ペイロードの形式 | JSON | JSON | |
| 通知データのキー制約 | あり | なし | iOSはapsキーの中に設定する。 |
| ペイロードあたり配信上限 | 1デバイス | 1,000デバイス | iOSは1回の接続で複数ペイロード送信可能 |
| 不正トークンの影響 | リクエストの停止 | リクエストは継続 | iOSは不正トークン以降のペイロードが破棄される。 |
| 受信方法 | OS依存 | 各自実装 | |
| ダイアログ表示 | 可能 | 各自実装 | |
| 通知センター表示 | 一部可能 | 各自実装 | iOS 5.0以降で通知センターが追加 |
| ロック画面表示 | 可能 | 各自実装 | |
| サウンド | 可能 | 各自実装 | |
| 振動 | 可能 | 各自実装 | iOSはサウンドと振動は連動 |
| バックグラウンド処理 | 一部可能 | 各自実装 | バックグラウンド処理が可能なのはiOS7から |
| バッジ | 可能 | 不可能 | |
| 利用者への確認 | ダイアログ | パーミッション | |
| 利用者によるオフ | 可能 | 一部可能 | Android 4.1以降で可能 |
| 配信制限 | なし | なし | Androidは、C2DM時代は配信制限あり |
少し言い訳しておくと、ちゃんと確認せずに書いているので間違いがあるかもしれません。Wikipediaだったら[要出典]ってたくさん付けられてしまいそうです。
大きな違いをいくつか紹介していきます。
Androidは受信処理を各自実装する必要がある。
iOSとAndroidのプッシュ通知の設計の大きな違いは、iOSはOSの仕組みに乗らなければいけないのに対して、Androidは自由度が高く各自の実装にゆだねられているという点です。
iOSのAPNSは送信するデータの形式もしっかり決まっていて、その形式にしたがって送信すれば、あとはOSが定めた方法で表示されるだけです。一方のAndroid送信データは完全に自由で、それを受信した際にアプリがどんな動作をするかも、制限されていません。
逆にいえばAndroidは受信時の表示などの処理をすべて独自で実装する必要があり、クライアントの実装の手間は数倍になります。
AndroidのGCMはHTTPで一括送信が可能
サーバサイドの違いで大きいのは、iOSのAPNSが独自のプロトコルであるのに対して、AndroidのGCMはHTTPで通知が可能であるということです。
リクエストヘッダーにAPIキーを添え、リクエストボディにメッセージや送信先デバイスのトークンを送るだけなので、非常に単純で、サーバサイドの実装はAndroidの方が簡単と言えます。
実際にAPNSは各言語に対してライブラリがオープンソースで開発されていますが、GCMはただのHTTPであるためにライブラリはほとんど存在しません。
そして、Androidは古いC2DMからGCMへの移行で、1,000デバイスまでの一括送信が可能になりました。iOSのAPNSは1回の接続で複数のペイロードを送信することができるのですが、途中に不正なトークンなどが含まれるとそれ移行のペイロードが破棄されてしまうため、一括送信の制御には手間がかかります。
Androidのトークンはよく変わる
最後の大きな違いとしては、iOSのデバイストークンはほぼ変わらないといって良いのに対して、AndroidのレジストレーションIDはよく変動します。iOSのデバイストークンが変化したのは、3年間の開発歴の中では1回だけで、iOS7へアップデートした時だけです。
トークンの変化が激しいAndroidでは、1つの端末に対して複数のトークンが紐付いてしまう場合があります。トークンが変化しても古いトークンはしばらく有効ですので、サーバに複数のトークンを保持してしまうと多重送信が置きてしまうので、適切に処理してやる必要があります。
GCMにはそのための機構も用意されていて、プッシュ通知を送信したレスポンスにトークンが変化した旨と、新しいトークンが返送されます。これを元に、データベースを更新することで多重送信を制御することができます。
iOSのデバイストークンはほぼ変化しないため、このような機構はありません。
おわりに
こうして眺めてみると、iOSとAndroidの設計思想の違いみたいなものも見えてきます。
最後に例によって宣伝ですが、プッシュ通知の実装は、Growth Pushが便利です！ぜひよろしくお願いします！
iOS、Androidはもちろん、Unity、Cocos2d-xへの導入も簡単にできて、セグメント指定による配信対象の制御などもできます。
Growth Pushの実装中に技術調査したことなど、これからも吐き出していきます。