プッシュ関連の紹介
ユーザーがアプリを開いていない場合、サーバーはサーバーの最新のメッセージ データをユーザーにプッシュします。これをプッシュと呼びます。メッセージ プッシュは、一般的な e コマース アプリの製品プロモーション活動や情報アプリのニュース プッシュなど、モバイル開発のさまざまなシナリオで使用されます。実際の開発では、プロダクトデザインのニーズに合わせてプッシュ機能を開発することが多いです。しかし、実装プロセスでは、次のような多くの問題に直面することになります。自分で実装しますか、それともサードパーティのプッシュを選択しますか? サードパーティプッシュを選択するにはどうすればよいですか? メッセージプッシュのデータセキュリティを確保するにはどうすればよいですか? プッシュの到着率を確保するにはどうすればよいですか? 実際、これらの問題点は主に Android スマートフォンにあり、この記事の焦点も Android スマートフォンの強化にあります。
part1: iOS プッシュと Android システム プッシュの比較
iOSプッシュサービスの通知は、独自の専用プッシュサーバーであるAPNs（Apple Push Notificationサービス）によって行われ、APNsが独自のアプリケーションサーバーから送信されたプッシュメッセージを受信し、指定されたiOSデバイスにプッシュ通知するというプロセスです。 iOS デバイスをアプリケーションに送信すると、プロンプトが表示されるか、表示されます。iOS リモート プッシュの前提条件は、アプリケーションを備えた iOS デバイスが APNs サーバーに登録されている必要があるということです。メッセージをプッシュする必要がある場合、アプリケーション サーバーは指定された形式に従ってメッセージをパッケージ化し、iOS デバイスのデバイストークンとともに APNs サーバーに送信します。私たちのアプリケーションは APNs サーバーとの TCP ベースの長期接続を維持し、APNs サーバーは新しいメッセージを iOS デバイスにプッシュし、プッシュされたメッセージをデバイス画面に表示します。(注: すべてのサードパーティのプッシュは Apple サーバーの APN を経由する必要があります)。
また、バックグラウンドでプッシュする必要があるすべての Android アプリケーションには、それぞれのサーバーと通信してデータを交換するために、個別のバックグラウンド プロセスが必要です。実はAndroidにもAPNSのGCM（Google Cloud Message）に似たサービスがあり、Androidアプリのプッシュもこの方式を採用すればiOSのプッシュと同じになります。GCM 関連のプログラムは、いわゆる Gapps に統合される必要があります。ただし、中国では Android 携帯電話の GCM が基本的に利用できないことと、Android デバイスの深刻な断片化により、Android プッシュを行う際に考慮する必要がある上記の問題が発生します。
part2: プッシュの本質と原則
メッセージプッシュの本質は、アプリがサーバーの更新情報をユーザーにプッシュすること、つまりアプリがサーバー情報を取得してユーザーにプッシュすることです。サーバーから最新ニュースを取得: プッシュとプル
- 能動的取得方式（Pull）：クライアントがサーバから定期的に能動的に情報を取得し、更新情報があるかどうかを確認し、更新情報があればクライアントに送信する
- パッシブ受け入れモード (プッシュ): サーバーが情報を更新すると、その情報がクライアントにアクティブに送信されます。
コントラスト: プッシュ方式はプル方式よりも優れています。プル方式を使用する場合、クライアントはサーバーの変更を継続的に監視する必要があるため、クライアントのリソース (CPU リソース、ネットワーク トラフィック、システム電力) がより多く消費されます。
パート 3: Android でメッセージ プッシュを実装するためのいくつかのソリューション
プッシュの原理を理解した後、Android でメッセージ プッシュを実装するためのいくつかのソリューションについて説明します。
解決策 1. GCM サービス (Google Cloud Messaging) を使用する
はじめに: Google が開始したクラウド メッセージング サービスは、G2DM の第 2 世代です。
利点: Google が提供するサービスはネイティブでシンプルであり、サーバーを実装して展開する必要はありません。
短所: このサービスは中国では十分に安定しておらず、ユーザーは Google アカウントをバインドする必要がありますが、これは Google によって制限されています。
シナリオ 2. ポーリング
概要: プル方式に基づいて、アプリケーションは定期的にサーバーにアクティブに接続し、新しいメッセージがあるかどうかをクエリします。
短所: 高コスト、メッセージ キューイングなど、サーバーとの通信を自分で実現する必要がある、到着率が不確実、ポーリングの頻度を考慮する: 低すぎるとメッセージ遅延が発生する可能性がある、高すぎるとサーバー上のリソースが増加するクライアント (CPU リソース、ネットワーク トラフィック、システム電力) とサーバー リソース (ネットワーク帯域幅)
シナリオ3.SMS（ショートメッセージ送信）
概要: SMS メッセージを傍受し、メッセージの内容を解析してサーバーの意図を理解し、処理する表示コンテンツを取得します。
利点: 完全なリアルタイム操作が可能です。
デメリット：比較的コストが高い。なぜなら、現時点では、対応するショートメッセージ料金をオペレータに支払うことによってのみ、この解決策を実現するための無料のショートメッセージ送信ゲートウェイを見つけることは困難だからである。
解決策 4. MQTT プロトコルを使用する (詳細については、 http://mqtt.org/を参照)
概要: 軽量のエージェントベースの「パブリッシュ/サブスクライブ」モードのメッセージ転送プロトコル。
利点: プロトコルは簡潔、コンパクト、拡張性が高く、トラフィック節約、省電力であり、エンタープライズ分野にも適用されており (参考: http://mqtt.org/software )、C++ バージョンもあり ます。サーバーコンポーネントrsmb。
短所: 未熟で実装が複雑、オープンソースのサーバー コンポーネント rsmb ではない、ハードウェアの導入コストが高い。
解決策 5、XMPP プロトコルを使用する (Openfire + Spark + Smack)
はじめに: 以前は Jabber として知られていた XML プロトコルに基づく通信プロトコルは、IETF 国際標準化機構によって標準化されました。
利点: プロトコルは成熟し、強力で、拡張性が高く、現在主に多くのチャット システムで使用されており、開発サンプル androidpn のオープン ソース Java バージョンがあります。
短所: プロトコルは複雑で冗長 (XML ベース)、トラフィックと電力が消費され、ハードウェアの導入コストが高くなります。
シナリオ 6. サードパーティのプラットフォームを使用する
はじめに: サードパーティのメッセージ プッシュ プラットフォームを使用します。現在の主流のプッシュ プラットフォームは次のように分類されます ------
携帯電話メーカー: Xiaomi Push、Huawei Pushなど...
サードパーティ プラットフォーム: Youmeng Push、Jiguang Push、Getui...
BAT メーカーのプラットフォーム プッシュ: Alibaba Cloud Mobile Push、Tencent Cloud Mobile Push、Baidu Cloud Push。
以下、詳しく説明する。
パート 4: サードパーティのメッセージ プッシュ プラットフォームの詳細な紹介
1. 主流のサードパーティプッシュプラットフォームの分類
携帯電話メーカー: Xiaomi Push、Huawei Push...
サードパーティ プラットフォーム: Youmeng Push、Jiguang Push、Getui...
BAT メーカーのプラットフォーム プッシュ: Alibaba Cloud Mobile Push、Tencent Mobile Push、Baidu Cloud Push
2. 他のプッシュ方式の特性を比較する
- 効果的にコストを削減できる
上記のプッシュのほとんどは無料ですが、自分で実装すると、多くのリソース (開発コストとバックグラウンド管理、統計コスト) が消費されます。
- 高いメッセージ到着率
携帯電話内の複数のアプリが同じプッシュ サービスを使用している場合、これらのアプリはメッセージ チャネルを共有します。アプリ プッシュ サービスが強制終了された場合でも、ユーザーがプッシュ サービスを統合する他のアプリを開いている限り、ホーム プッシュはユーザーに到達できます。 。
- 低いセキュリティ
他人のサーバーを使用すると、データ漏洩のリスクが依然として残ります。（ただし、一部のプッシュサービスはプライベートサーバー対応のため￥がかかります）
- サービスは強制終了されます
Android システムの仕組みにより、バックグラウンド プッシュ サービスはさまざまなアクティブまたはパッシブな動作によって強制終了されます。サービスが強制終了されると、プッシュ メッセージを受信できなくなります。(一部のプッシュ サービスは統合ベンダー チャネルをサポートしているため、統合ベンダー チャネルは (オフライン) プッシュ到着率を向上させることができますが、\ も必要になります)
パート 5: サードパーティ プラットフォームのプッシュ サービスを選択するにはどうすればよいですか?
サードパーティプッシュの特徴を知った上で、どう選べばいいのでしょうか？注意すべき3つの原則を明確にする必要があります。
1. 携帯電話メーカーの推進
暗黙のルールを覚えておいてください。オペレーティング システムは、独自のブランドのプッシュ サービスを強制終了しないということです。
携帯電話メーカーのプッシュ サービスは、その携帯電話のシステム レベルのサービスです。つまり、システムが独自のプッシュ サービスを強制終了することはありません。たとえば、Android ネイティブ システムは C2DM メッセージ プッシュ サービスを強制終了しませんし、MIUI システムは Xiaomi のプッシュ サービスを強制終了しません。
(Xiaomi Push 公式 Web サイトのスクリーンショット - 統合アプリケーション)
Xiaomi Pushの公式Webサイトを見ると、市場の主流アプリのほとんどがXiaomi Pushを統合していることがわかります。
2. サードパーティのプラットフォーム
ルールを覚えておいてください。プッシュ システムはプッシュ チャネルを共有します。
これは、あなたが Youmeng Push に接続していると仮定すると、たまたま Toutiao も Youmeng に接続していることを意味します。ある日、アプリが強制終了されますが、この時点でユーザーが Toutiao を起動すると、プッシュ システムが共有プッシュ チャネルを通じてプッシュ メッセージを携帯電話に送信し (プッシュの到着率が向上します)、その後ウェイクアップすることができます。あなたのプロセスも（「生きたまま」でした）。したがって、プッシュ用のサードパーティプラットフォームをどのように選択するかについては、プッシュプラットフォームのスケール効果が非常に重要です。
では、その規模と市場シェアをどのようにして知ることができるのでしょうか? 主に次の 2 つの点に注目してください。
-
中の友達に聞いてください。
- どの大手アプリがプッシュ プラットフォームの協力顧客に含まれているかを確認します。対応する公式 Web サイトの協力事例を参照してください。
(Getui 公式 Web サイト - 統合アプリケーションのスクリーンショット)
3. 大手BATメーカーからのプッシュ
一言で言えば、大手 BAT メーカーの推進には実際には何のメリットもありません。
Tencent Mobile Push を使用することで WeChat を利用でき、アプリが決して強制終了されないと考える人もいるかもしれませんが、それは幻想です。Aliyun のモバイル プッシュに関しては、市場で主流のアプリケーションがどれだけ使用しているかわかりませんが、淘宝網が他のプラットフォームで他のサードパーティ プッシュ (Youmeng Push、Xiaomi Push など) を使用していることはわかります。
プッシュ プラットフォームを選択するときは、上記の 3 つの原則に加えて、次の要素も考慮する必要があります。
ユーザーグループ属性（機器）：どのようなユーザーグループで、どのような機器が多く使われているか。次に、携帯電話メーカーを検討してみましょう。
リーチ率: たとえば、Xiaomi と Huawei のプッシュを統合するかどうか、サードパーティ プラットフォームを選択するときにメーカー チャネルを統合するかどうか、サードパーティ プラットフォームの規模...
実現コスト: 人件費、時間コスト、資本コスト...
したがって、自分の状況に応じてメッセージプッシュプラットフォームを選択する必要があります。
part6: プッシュメッセージのカテゴリの選択
1. プッシュメッセージの種類
一般に、サードパーティのプッシュ プラットフォームは、通知バー メッセージと透過的な送信メッセージの 2 種類のプッシュ メッセージをサポートします。
通知バー メッセージ: このタイプのメッセージはユーザーのデバイスに配信された後、システム通知バーの形式でユーザーに直接表示され、アプリには渡されません。
透過的なメッセージ送信: このタイプのメッセージはユーザーのデバイスに配信された後、引き続きアプリに送信され、アプリの BroadcastReceiver をコールバックすることによってメッセージがアプリの内部に送信されます。このメッセージをどのように処理して表示するかはアプリが決定します。
したがって、透過的な送信メッセージは、必ずしもプログラマによってカスタマイズされたシステム通知バーの形式でプッシュされるとは限りません。
2. メッセージカテゴリの違いと特徴
2 つの違いは、メッセージ送信プロセス全体において、透過的送信メッセージには通知バー メッセージよりも 1 つ多くのステップ (アプリに渡すステップ) があることです。
通知バーメッセージの利点: 高い配信率
透過的な送信メッセージは、メッセージ送信プロセス全体 (アプリに渡される) において通知バー メッセージよりも一歩進んでおり、そのため、透過的な送信メッセージはシステムによって制限される可能性が高く、システムによって強制終了される可能性が高くなります。の方が高いため、通知バーのメッセージはパススルー メッセージよりも優れた配信性を提供する必要があります。
透過的なメッセージ送信の利点:
- 高度なメッセージ操作と高度なカスタマイズ。
- メッセージ データに対するより柔軟な操作機能を提供します。
- アプリが通知バー メッセージを渡すだけの場合、メッセージ データ自体にはアクセスできません。
- 通知リマインダーのスタイルはカスタマイズ可能です（プロンプトのスタイル、サウンドなどのプロンプト形式など）
要約する
上記では、プッシュとプッシュの実装スキームとサードパーティ プッシュについて包括的かつ詳細に紹介するだけでなく、サードパーティ プッシュを選択する際に考慮する必要がある要素や注意すべき事項についても説明します。セキュリティとメッセージ到着率を向上させる方法について個別に紹介するものはありませんが、いくつかの言及が他のコンテンツに散りばめられています。読んで何か得るものがあれば幸いです。