Why is plain jar file compressed to 76% but after ProGuard shrink & obfuscate; it is compressed to 102% ?! How to fix?

476
Saleh Feek

I have a jar file of size 392 MB. I made another copy of it, so I have now two copies of the same jar file.

For one of them I used 7-zip to compress it. It is compressed to 76% of the original size, that is 298 MB

For the other one; I first used proGuard to shrink and obfuscate it. After shrinking it, its size went down to 348 MB. After that I compressed it with 7-zip. It is compressed to 102% of the shrunk size that is 355 MB!!!

What is wrong?
How to fix?

-1
Сострадание основано на данных, если это не предназначено для сжатия (видео, аудио, запутывание), это происходит, нет ничего плохого, оно работает как задумано Ramhound 8 лет назад 0
@Ramhound; оба представляют собой одну и ту же банку, но у каждого есть дополнительный шаг (сжимать и запутывать) - это не меняет формат. Это по-прежнему баночный формат - меня беспокоит то, что он не сжимается как не усохший, не запутанный! - Хорошо, тогда мне лучше отправить несжатую банку. Saleh Feek 8 лет назад 0
Правильно; виновата запутанность; Ramhound 8 лет назад 3
Я согласен с @Ramhound, это больше не тот же файл ... он был изменен, очищен и запутан, это данные, отличные от исходного файла, нет гарантии, что он будет сжимать так же, как исходный файл, это сейчас другой. acejavelin 8 лет назад 2
Разве не было бы неплохо иметь возможность сжимать файл одним приложением, затем брать этот вывод и снова сжимать его, брать этот вывод и снова сжимать его и т. Д., Пока файл не станет только 1 байтом? Сжатие и шифрование стремятся сделать полученные данные случайными, и вы можете получить их только случайно. В какой-то момент вы просто перестраиваете хаос. Ron Maupin 8 лет назад 0

1 ответ на вопрос

1
Mokubai

By replacing function names with near random names, then changing the calling patterns for the functions and pre-compressing the file ("shrinking") you are effectively removing all the repetitive blocks that a compression algorithm can see and use to compress the file further.

With no repetitive blocks in the data stream there is nothing a compression algorithm can do to remove duplicate blocks, but the reason you are seeing an increase in file size is because the compression method has its own overheads it puts into an output file. The compressor will have a dictionary of "phrases" that are duplicated within the file and then the compressed file essentially is a list of lookups to that dictionary, but with no duplicates in the file the dictionary becomes a copy of the original file and the lookups are still there with each one pointing to only one item in the dictionary.

What this means is that for an already compressed file there is no way that the output file can be smaller than the original file. You will always end up storing what is essentially the entire file along with a lookup table telling the decompression algorithm how to rebuild the original file.