それがIntentServiceであることを絶対に確信していますか？ それがUIがフリーズする根本的な原因ですか？インテントサービスは、メイン（UI）スレッドから処理をオフロードするためにワーカースレッドで実行するように特別に設計されています。これの主な理由の1つは、防止を支援することです。 UIがフリーズします。
おそらく、UIレベルでデバッグ作業を開始してみてください。特に、ResultReceiverを提供するもの IntentServiceへ 開始するとき、およびonReceiveResultで何をしますか そのレシーバーインスタンスのコールバックメソッド？
それ以外に、フリーズしているアクティビティについては、どのような操作を行っているかを確認してください。メインスレッドのデータベースから大量のデータを読み込む（つまり、Loaderを使用しない） または、処理をワーカースレッドにオフロードするようなもの）は、少なくともこれまでの私の経験では、UIフリーズの一般的な原因です。
更新
私は問題が何であるかを理解したと思います。 2つの主要な問題があり、どちらもVolleyの使用方法に起因します。 Volleyキューにリクエストを追加すると、非同期で実行されます。つまり、queue メソッドはすぐに戻ります。インテントサービスコードでは、これはサービスがすぐにResultReceiverに通知することを意味します 処理が終了したこと、実際に実行したのはリクエストをキューに入れることだけです。 5つのインテントサービスすべてがこれを実行します。つまり、MainActivity 非常に迅速に入力されます。これが最初の問題です。
2番目の問題は、発生しているフリーズについて説明しています。 Volleyはワーカースレッドでリクエストを実行しますが、メインスレッドでのリクエストに対する解析済みの応答を返します。こちらのドキュメントを参照してください。これは、インテントサービスで実行しているすべての応答処理（データをデータベースに配置するなど）が実際にはメイン（UI）スレッドで行われていることを意味します。これが凍結の説明です。
ここでおそらくやりたいことは、VolleyのRequestFutureの使用に切り替えることです。 代わりは。これは基本的に、リクエストが終了するまでブロックできるようにすることで、非同期リクエストを同期リクエストに変えます。これを行うには、適切なタイプのフューチャーを作成します（JSONObject あなたの場合）そしてそれをリクエストのリスナーとエラーリスナーの両方として設定します。次に、今と同じようにリクエストをキューに入れ、その直後にgetを呼び出します。 将来の方法。このメソッドは、応答の処理が完了するまでブロックします。 UIスレッドではなく、ワーカースレッドで実行されるため、インテントサービスでこれを実行しても問題ありません。
リクエストが成功すると、データが返され、現在Response.Listenerにあるすべてのロジックを実行できます。 実装。エラーが発生した場合（つまり、何らかの理由でリクエストが失敗した場合）、futureリクエストは、適切なアクションを実行するために処理できる例外をスローします。
リクエストフューチャーの使用は、リスナーを使用する場合とはまったく異なるアプローチであり、コードを機能させるにはコードをかなり変更する必要があるかもしれませんが、発生している問題は解決するはずです。
お役に立てば幸いです。また、バグを早期に発見できなかったことを心からお詫び申し上げます。