Проще говоря, как сжатие обычно реализуется?
Проверьте ориентацию экрана во время выполнения.
@Override
public void onConfigurationChanged(Configuration newConfig) {
super.onConfigurationChanged(newConfig);
// Checks the orientation of the screen
if (newConfig.orientation == Configuration.ORIENTATION_LANDSCAPE) {
Toast.makeText(this, "landscape", Toast.LENGTH_SHORT).show();
} else if (newConfig.orientation == Configuration.ORIENTATION_PORTRAIT){
Toast.makeText(this, "portrait", Toast.LENGTH_SHORT).show();
}
}
5 ответов
Алгоритмы сжатия пытаются найти повторяющиеся подпоследовательности, чтобы заменить их более коротким представлением.
Возьмем 25-байтовую строку Бла-бла-бла-бла-бла! (200 бит ) из Объяснение алгоритма Deflate , например.
Наивный подход
Наивный подход заключался бы в кодировании каждого символа кодовым словом одинаковой длины. У нас есть 7 разных символов, и поэтому нам нужны коды длиной ceil (ld (7)) = 3 . Наши кодовые слова могут выглядеть так:
000 → "B"
001 → "l"
010 → "a"
011 → "h"
100 → " "
101 → "b"
110 → "!"
111 → not used
Теперь мы можем закодировать нашу строку следующим образом:
000 001 010 011 100 101 001 010 011 100 101 001 010 011 100 101 001 010 110
B l a h _ b l a h _ b l a h _ b l a !
Для этого потребуется 25 · 3 бит = 75 бит для закодированного слова плюс 7 · 8 бит = 56 бит для словаря , таким образом 131 бит (65,5%)
Или для последовательностей:
00 → "lah b"
01 → "B"
10 → "lah!"
11 → not used
Закодированное слово:
01 00 00 00 00 10
B lah b lah b lah b lah b lah!
Теперь нам просто нужно 6 · 2 бит = 12 бит для закодированного слова и 10 · 8 бит = 80 бит плюс 3 · 8 бит = 24 бит для длины каждого слова, таким образом, 116 бит (58,0%).
Подход с использованием кода Хаффмана
Код Хаффмана используется для кодирования более частых символов / подстрок с более коротким кодом, чем менее частые:
5 × "l", "a", "h"
4 × " ", "b"
1 × "B", "!"
// or for sequences
4 × "lah b"
1 × "B", "lah!"
Возможный код Хаффмана для этого :
0 → "l"
10 → "a"
110 → "h"
1110 → " "
11110 → "b"
111110 → "B"
111111 → "!"
Или для последовательностей:
0 → "lah b"
10 → "B"
11 → "lah!"
Теперь наш Бла-бла-бла-бла-бла! можно закодировать в:
111110 0 10 110 1110 11110 0 10 110 1110 11110 0 10 110 1110 11110 0 10 110 1110 11110 0 10 110 111111
B l a h _ b l a h _ b l a h _ b l a h _ b l a h !
Или для последовательностей:
10 0 0 0 0 11
B lah b lah b lah b lah b lah!
Теперь для первого кода нужно 78 бит или 8 бит вместо 25 · 8 = 200 бит, как у нашей исходной строки. Но нам все еще нужно добавить словарь, в котором хранятся наши символы / последовательности. Для нашего посимвольного примера нам потребуется 7 дополнительных байтов (7 · 8 бит = 56 бит), а нашему примеру для каждой последовательности снова потребуется 7 байтов плюс 3 байта для длины каждой последовательности (таким образом, 59 бит). В результате получится:
56 + 78 = 134 bit (67.0%)
59 + 8 = 67 bit (33.5%)
Фактические числа могут быть неверными. Пожалуйста, не стесняйтесь редактировать / исправлять его.
Проверьте эту вики-страницу ...
Алгоритмы сжатия без потерь обычно используют статистическую избыточность таким образом, чтобы представить данные отправителя более кратко без ошибка. Сжатие без потерь возможно, потому что большинство реальных данных имеют статистическую избыточность. Например, в английском тексте буква «е» встречается гораздо чаще, чем буква «z», и вероятность того, что за буквой «q» будет следовать буква «z», очень мала.
Другой вид сжатия, это называется сжатием данных с потерями или перцепционным кодированием, возможно, если допустима некоторая потеря точности. Как правило, сжатие данных с потерями будет основываться на исследованиях того, как люди воспринимают эти данные. Например, человеческий глаз более чувствителен к незначительным изменениям яркости, чем к изменениям цвета. Сжатие изображений JPEG отчасти «округляет» часть этой менее важной информации. Сжатие данных с потерями позволяет получить наилучшую точность при заданной степени сжатия. В некоторых случаях желательно прозрачное (незаметное) сжатие; в других случаях верность приносится в жертву, чтобы максимально уменьшить объем данных.
Схемы сжатия без потерь являются обратимыми, так что исходные данные могут быть восстановлены, в то время как схемы с потерями допускают некоторую потерю данных для достижения более высокого сжатия.
Однако алгоритмы сжатия данных без потерь всегда не могут сжать некоторые файлы; действительно, любой алгоритм сжатия обязательно не сможет сжать данные, не содержащие заметных шаблонов. Поэтому попытки сжать уже сжатые данные обычно (текстовые файлы обычно могут быть сжаты сильнее после сжатия из-за меньшего количества символов) приводят к расширению, как и попытки сжать все, кроме самых тривиально зашифрованных данных.
На практике сжатие данных с потерями также дойдет до такой степени, что повторное сжатие не работает, хотя алгоритм с очень большими потерями, например, удаление последнего байта файла, всегда будет сжимать файл до точки, в которой он пусто.
Пример без потерь vs.
Эта строка может быть сжата как:
25. [9] 8Исходная строка, интерпретируемая как «двадцать пять и девять десятых», полностью воссоздана, только записана в меньшей форме. В системе с потерями, используя
26вместо этого исходные данные теряются за счет меньшего размера файла.
Говоря ОЧЕНЬ простыми словами, распространенной формой сжатия является http://en.wikipedia.org/wiki/Dictionary_coder . Это включает в себя замену более длинных повторяющихся строк на более короткие.
Например, если у вас есть файл, который выглядит так:
"Monday Night","Baseball","7:00pm"
"Tuesday Night","Baseball","7:00pm"
"Monday Night","Softball","8:00pm"
"Monday Night","Softball","8:00pm"
"Monday Night","Baseball","5:00pm"
Это будет примерно 150 символов, но если вы сделаете простую замену следующим образом: A = «В понедельник вечером», B = «Во вторник вечером», C = «Бейсбол», D = «Софтбол», E = «19:00», F = «20:00», G = 17:00 «
Тогда тот же контент можно было бы закодировать следующим образом:
A,C,E
B,C,E
A,D,F
A,D,F
A,C,G
Использование 25 символов! Умный наблюдатель может также увидеть, как легко уменьшить это число до 15 символов, если мы предположим еще кое-что о формате файла. Очевидно, что существует накладные расходы на ключ подстановки, но часто очень большие файлы содержат много таких подстановок. Это может быть очень эффективным способом сжатия больших файлов или структур данных, и при этом они могут быть «в некоторой степени» удобочитаемыми.
Алгоритмы сжатия без потерь преобразуют каждый возможный вход в отдельные выходы таким образом, что более общие входы преобразуются в более короткие выходные данные. Математически невозможно сжать все возможные входные данные - в противном случае у вас было бы несколько входов A и B, сжимающихся в одну и ту же форму, поэтому, когда вы распаковываете его, вы вернетесь к A или обратно к Б? На практике наиболее полезная информация имеет некоторую избыточность, и эта избыточность соответствует определенным шаблонам; следовательно, данные могут быть с успехом сжаты, потому что случаи, когда расширяют при их сжатии, естественным образом не возникают.
Сжатие с потерями, например, которое используется в сжатии JPEG или MP3, работает, аппроксимируя входные данные данные некоторым сигналом, который может быть выражен в меньшем количестве бит, чем исходный.
Rosetta Code имеет запись в кодировании Хаффмана, как и моя более ранняя запись в блоге .