[android] 앱 업데이트시 다운로드 사이즈 줄이기

https://android-developers.googleblog.com/2016/12/saving-data-reducing-the-size-of-app-updates-by-65-percent.html

-

돼왕 : 참고로 링크 걸린 원글은 2016.12.06 글임을 참고하시길..

-

2016년 초부터 bsdiff algorithm 을 사용하여 app update 시 과거와 비교하여 47% 정도의 apk download size 를 줄일 수 있었다.

File-by-File patching 기술을 이용하여 평균적으로 앱 업데이트시 본 apk 사이즈에 비해 약 65% 정도 작은 사이즈를 내려보낼 수 있게 되었다.

-

새로운 버전을 다운로드 받을 때 Google Play 는 과거버전과 새로운 버전의 앱 사이의 diff 만 내려보낸다.

File-by-File patching 에 사용된 기술

-

안드로이드 앱은 APK 로 package 되는데 이는 특별한 convention 을 가진 ZIP과 같다.

대부분의 ZIP 파일은 Deflate 라는 기술을 사용하여 압축된다.

Deflate 는 압축을 잘 하지만, 단점이 있다.

압축되기 전 원본 컨텐츠에 조그만 변화가 생겨도, 압축이 된 파일은 정말 큰 변화를 겪는다. (돼왕 : hash 와 비슷한 성질이라 보면 되겠다.)

압축되기 전 파일의 변화는 쉽게 찾을 수 있다. 하지만 압축된 파일의 변화는 어떤 부분이 변했는지 쉽게 파악하기가 어려워 비효율적인 패치를 해야만 한다.

-

File-by-File 을 압축전 상태의 변화를 찾는데 사용한다.

patch 를 만들기 위해 먼저 old file 과 new file 의 압축을 해제한다.

그리고 압축해제된 파일에서 diff 를 찾아내고, 그 다음 새로운 파일로 다시 압축한다.

이를 통해 단말에서의 APK 는 정확히 Play Store 에 있는 APK 와 맞춰진다. (APK Signature Schema v2 도 이와 관련있다)

-

새로운 파일을 재압축할 때 두가지 까다로운 점에 마딱뜨렸다.

첫번째는, Deflate 가 output 에 영향을 주는 몇가지 설정값을 가지고 있다는 것이고, 우리는 그 세팅이 무엇인지 알 수 없다는 것이다.

두번째는, 많은 Deflate version 이 존재하며, 단말에 있는 deflate 버전과 호환이 되는지 알아야 한다는 것이었다.

다행히도, 분석을 통해 대부분의 Play Store 에 있는 앱들은 zlib 기반의 deflate 버전을 사용한다는 것을 알았다.

게다가 기본 세팅 값인 level=6 과 최대 압축 세팅인 level=9 가 실제로 쓰인 값들이란 것도 알아냈다.

-

이 기술을 쓰는데 한 가지 trade off 가 있으니...

바로 단말에서 더 많은 processing power 를 사용한다는 것이다.

2015년부터의 최신 단말들의 경우, 재압축하는데 MB 당 1초 이상이 걸렸고, 오래된 단말이나 저사양단말의 경우는 더 오래 걸린다.

평균적으로 patch size 가 반이 되면, 이 패치를 적용하는데 걸리는 시간은 2배가 되었다.

-

현재는 이 새로운 patch 기술을 auto-update 에만 한정하고 있다. ( 돼왕 : 2019.10.30 기준 대부분에 적용된듯 )

(auto update 는 bg 상태에서 발생하며, phone 이 plug-in 되어있고, 밤에만 작동 -> 폰 미사용상태로 판단)

만약 직접 update 를 누를 경우 보여지는 파일 사이즈는 File-by-file 기술이 적용되지 않았기 때문에 용량이 클 것이다.

-

끝!!!