サーバーからデータをダウンロードして表示するアプリケーションを書いています。データは、テキスト、ビデオ、オーディオ、および画像ファイルで構成されています。データは、いわゆるデータバンドルでダウンロードされます。データバンドルは、数キロバイトから数百メガバイトまでのすべてのデータタイプの集合で構成できます。データバンドルが大きすぎる理由は、ビデオファイルです。
サーバーはGoで記述され、アプリケーションはJava（Android）で記述されています。
質問：データバンドル（大小）を送信する場合、どの圧縮アルゴリズムが最適な方法ですか？Deflateで十分ですか、それとももっと洗練されたアプローチを検討する必要がありますか？
まず、ビデオ、オーディオ、および画像ファイルは、非可逆アルゴリズムで既に圧縮されていると仮定します。その場合、通常、追加の別の圧縮アルゴリズムを使用してデータを (あまり) 圧縮することはできません。テキスト データが通常、データ バンドル全体のほんの一部である場合、ソフトウェアに複雑さを加えて全体的な利益を非常に小さくすることは正当化されないため、それ以上の圧縮を適用する必要はまったくないと思います。たとえば、10MB のオーディオ ファイルを 5kB のテキスト ファイルと組み合わせて、テキストを 1kB に圧縮できる場合 (これは、実際に達成するよりもはるかに優れている可能性があります)、データ バンドルの完全なサイズは、 10.005MB から 10.001MB に、つまり 0.04% 削減されます。
テキストの量が一般的に非常に多く、圧縮を正当化できる場合、Android は標準の Android API を使用して inflate/deflate と gzip をサポートします。bzip2 および lzma(2) 用のサードパーティ Java ライブラリもあり、Android 用に変更せずにコンパイルできると思います (まだ試していません)。Google で簡単に検索すると、Go の gzip、bzip2、および lzma の実装も見つかります。
これらのアルゴリズムは一般に、deflate、gzip、bzip2、lzma の順に計算コストとメモリ要件が高くなりますが、データをより適切に圧縮します。特に、lzma エンコーダー/デコーダーは、Android アプリケーションで実際に使用できるよりも多くのメモリを必要とする場合があります。特に、コンプレッサーは比較的多くのメモリを必要とし、デコーダーは小さな辞書を保持する場合はそれほど多くは必要ありません。