アプリが実行されている限り、定期的にサーバーと通信する Android アプリを構築しています。
アプリの起動時にサーバーへの接続を開始することでこれを行います。次に、threadと呼ばれるメッセージを受信するための別の がありますReceiverThread。これthreadは からメッセージを読み取りsocket、分析して、アプリケーションの適切な部分に転送します。
これthreadはループで実行され、読み取る必要があるものはすべて読み取り、read()新しいデータが到着するまでコマンドをブロックするため、ほとんどの時間がブロックされます。
と呼ばれる別のスレッドを介してメッセージの送信を処理しますSenderThread。私が疑問に思っているのSenderThreadは、同様の方法で構造化する必要があるかどうかです。つまり、このスレッドのキューを何らかの形で維持し、キュー内のすべてのメッセージを送信してから、新しいメッセージがキューに入るまでブロックするか、メッセージを送信する必要があるたびにスレッドの新しいインスタンスを開始する必要があります、メッセージを送信してから「死ぬ」ようにしますか？私は最初のアプローチに傾いていますが、パフォーマンス (ブロックされたスレッドをメモリに保持するか、新しいスレッドを初期化するか) とコードの正確さの両方の点で実際に何が優れているかはわかりません。
また、すべてのアクティビティでメッセージを送受信できる必要があるため、Applicationクラス内の両方のスレッドへの参照を保持していますが、それは受け入れられるアプローチですか、それとも別の方法で実装する必要がありますか?
これに関して私が遭遇した問題の 1 つは、アプリケーションを閉じて再度実行すると、実際には ReceiverThread のインスタンスが 2 つあるため、メッセージが 2 回表示されることがあります。
これは、アプリケーションが実際には閉じられず、前のスレッドがまだアクティブ (read()操作でブロックされていた) であり、アプリケーションを再度開いたときに新しいスレッドが初期化されたが、両方がサーバーに接続されていたためだと推測しています。両方にメッセージを送信しました。この問題を回避する方法、または正しくなるように完全に再編成する方法に関するヒントはありますか?
これらの質問を調べてみましたが、最初の質問で矛盾する例がいくつか見つかりました.2番目の質問に当てはまるものはありません...