昨日、Androidのブログ記事が投稿され、開発者がアップデートのサイズを縮小する作業について話しています。 本文に記載されているように、毎日何百万人ものユーザーがシステムとアプリケーションを更新しており、多くのユーザーがモバイルトラフィックの量を注意深く監視しています。
アップデートのサイズを削減するために、Android開発者は2016年6月にColin Percivalによって作成されたbsdiffアルゴリズムを使用してバイナリファイルにパッチを適用し始めました。 その後、アプリケーションのサイズと更新を、APK全体に対して平均で47％削減できました。
現在、Androidチームは、更新の量を元のサイズの平均65％削減できる新しいソリューションを共有したいと考えています。 ファイルごとのパッチ適用についてです。
アプローチは非常に簡単です。 完全なAPKをダウンロードしてすべてのアプリケーションファイルを再インストールする代わりに、更新システムはユーザーファイルとダウンロードしたファイルを調整します。 これにより、開発中に変更が加えられたファイルのみをダウンロードできます。
Android開発者によると、このシンプルで効果的なアプローチにより、更新トラフィックを1日6ペタバイト削減できます。
しかし、いくつかの落とし穴があります。 Deflateを使用したAPKファイルの圧縮は、ZIPとほぼ同じです。 これによりサイズを大幅に削減できますが、同時に、どのファイルが変更されたかを判断するのが難しくなります。
Deflateのデモンストレーション
上の画像でわかるように、1文字を追加しても、圧縮ファイルの構造は完全に変わります。 したがって、ファイルごとのパッチ適用は、非圧縮ファイルを相互に比較することに基づいています。 更新中に、古いものと新しいものの両方で、解凍されたファイルがチェックされます。 この時点で、bsdiffはまだ使用されています。 次に、パッチを適用するときに、置換が必要なファイルが識別され、ダウンロードされます。 その後、APKはデバイス側で再度再構築されます。 証拠として、開発者はいくつかの最も人気のあるAndroidアプリケーションの要約表を提供します。
これらのアプリケーションは、すでにファイルごとの更新システムを使用しています。
このアプローチにはいくつかの欠点があります。 最初に、最後のAPKは元のバイトとバイトを一致させる必要があります。 このパラメーターは、Deflateアセンブリ（最もよく使用されるのはZlibに基づいてアセンブルされます）とその設定の影響を受けます。
分析中に判明したように、すべての開発者は、Deflateを使用して、デフォルト（6）または最大（9）の2つの圧縮パラメーターのみを使用します。 Android開発者は、他のパラメーターを見つけていません。
アプローチのもう1つの欠点は、エンドデバイス、特にプロセッサの計算能力の要件です。 APKでの開梱、調整、および再組み立てのプロセスには、ユーザーのデバイスから大きな電力が必要であり、既存のすべてのデバイスがこの手順を同様に正常に処理できるわけではありません。 これにより、古い低電力デバイスでのパッチの使用が長くなります。 さらに、更新のサイズに基づいて、処理時間が比例して増加します。