英文:
How to transport data from a server to an Android device, by using data compression?
问题
我正在编写一个应用程序，它从服务器下载数据并显示出来。这些数据包括文本、视频、音频和图片文件。数据以所谓的数据包的形式下载。一个数据包可以包含各种数据类型，从几千字节到几百兆字节不等。数据包过大的原因是视频文件。
服务器是用Go语言编写的，应用程序是用Java（Android）编写的。
问题：如果我想传输数据包（小和大），哪种压缩算法是最好的选择？Deflate足够了吗，还是应该考虑更复杂的方法？
英文:
I am writing an application which downloads data from a server and displays it. The data consists of text, video, audio and picture files. The data is downloaded in so called data-bundles. A data-bundle can consist of a collenction of all data types, ranging from a few kilobytes to many hundreds of megabytes. The reason for too large data-bundles are video files.
Server is written in Go and the application is written Java (Android).
Question: Which compression algorithm would be the best way to go, if I want to transmit data-bundles (small and large)? Is Deflate enough, or should I consider a more sophisticated approach?
答案1
得分: 2
首先，我假设您的视频、音频和图像文件已经使用有损算法进行了压缩。在这种情况下，您通常不会能够使用其他不同的压缩算法来进一步压缩数据（很多）。如果文本数据通常只是整个数据包的一小部分，我认为根本不需要应用任何进一步的压缩，因为为了非常小的整体收益而给您的软件增加复杂性是不合理的。例如，如果您将一个10MB的音频文件与一个5kB的文本文件组合起来，并且能够将文本压缩到1kB（这可能比实际情况要好得多），数据包的完整大小只会从10.005MB减少到10.001MB，或者减少了0.04%。
如果文本的数量通常很高，以至于您可以证明压缩的必要性，Android支持使用标准Android API的inflate/deflate和gzip。还有第三方的Java库可以用于bzip2和lzma(2)，我想这些库在Android上编译时不需要进行修改（我没有尝试过）。快速的谷歌搜索也可以找到Go语言的gzip、bzip2和lzma实现。
这些算法通常按照以下顺序在更好地压缩数据的代价上增加了计算成本和内存需求：deflate、gzip、bzip2、lzma。特别是lzma编码器/解码器可能需要比Android应用程序实际可用的内存更多。特别是压缩器需要相对较多的内存，解码器则不需要太多，如果您使用较小的字典的话。
英文:
First of all, I assume that your video, audio and image files are already compressed with a lossy algorithm. In that case, you usually won't be able to compress the data (much) using an additional, different compression algorithm. If the text data is usually just a small part of the entire data-bundle, I don't think I would bother applying any further compression at all, since adding complexity to your software for a very small overall gain is not justified. For example, if you combine a 10MB audio file with a 5kB text file and could be able to compress the text to 1kB (which is probably much better than what you'd achieve in reality), the complete size of the data bundle would only be reduced from 10.005MB to 10.001MB, or by 0.04%.
If the amount of text is generally so high, that you can justify the compression, Android supports inflate/deflate and gzip using the standard Android API. There are also 3rd party Java libraries for bzip2 and lzma(2), which I suppose would compile without modifications for Android (I haven't tried though). A quick Google search finds gzip, bzip2 and lzma implementations for Go as well.
These algorithms generally compress the data better at the cost of higher computing costs and memory requirements in this order: deflate, gzip, bzip2, lzma. Especially the lzma encoder/decoder may require more memory than actually available to an Android application. Especially the compressor requires relatively much memory, the decoder not so much if you keep to smaller dictionaries.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论