テクノロジー| Androidのインストールパッケージの最適化

著作権

1.この記事では、元のソースと著者情報をマークする必要があります再版、元の作者に属します。

2.著者：趙ゆう（vimerzhao）、パーマネントリンク：https://github.com/vimerzhao/vimerzhao.github.io/blob/master/android/2020-02-11-apk-size-opt.md。

3.公共の数：ラインでVマスターズ。Eメール：[email protected] 。

背景

なぜ、インストールパッケージの展開

ビジネスの進化の産物を増やしインストールパッケージ不可欠な理由のサイズを大きくすることです。しかし、進化の途中で、いくつかのいわゆる技術的負債として、例えば：

切断せずにリソースの使用（例えば、フォントファイルのすべてとしては、解像度が大きすぎる画像です）
（オンライン引っ張るような大規模なビデオ、オーディオなど、）不当に大きなリソース
組立ラインは、関連するコードをクリアしていないオフ事業は、資源となっています
等

それはので、我々は一部を最適化する必要がある理由で不必要な増加、これらの過失インストールパッケージです。

インストールパッケージ最適化された値

一部の人々は今、ユーザーがインストールパッケージのサイズに敏感であってはならないので、モバイルデバイスやストレージ容量のパフォーマンスは、適切である、基本的には4G、WiFiネットワーク環境であることを感じることがあります。しかし、これは実際には錯覚である、それは第二層の都市、もちろん、問題ありません場合は、より多くの時間が、彼らのターゲット市場が表示されるはずですが、それは4層の都市部と農村部、沈没市場やインド、ブラジルなど海外市場であれば、明らかに、これらの仮定は確立されていません。

一般的には、インストールパッケージのサイズは、以下の指標に影響を与えます。

ダウンロードコンバージョン率
インストールの成功率
プロモーションコスト
メモリ、フットプリントを実行します

要約すると、チームの「余力」のために、インストールパッケージのサイズを最適化することは、まだ非常に必要です。

インストールパッケージの日常的な最適化

上記の理由により、ビジネスの観点から、パケットサイズは、「トラブルが終了する必要がある」をインストールするように最適化され、それは次のようになります。

圧縮リソース
オンラインリソースは大きなプルに変身します
調査役に立たないとオフラインビジネス

これらの方法は、より従来のものであり、救済策のように、カーディング以下の技術いくつかの普遍的な方法は、業務とは無関係に、試してみましたが、上記のものの方法では、パケットサイズインストールすることも可能である「より下の階に。」

インストールパッケージは、主にコードとリソースで構成されていますが、これらの二つの側面を最適化します。

コード

混乱

一般的に通じProGuard、悪いの多い、および管理の問題があります。最後に、このプロジェクトを見て、多くのクラスは、歴史的背景が有効であるかわからない、生きてくださいされています。

デックスの最適化

行番号情報ツールを削除し、問題がクラッシュ位置を持ち帰ったのではなく、解決することができます
マルチデックスは、並べ替えインデックスによってクロスデックスを避けるためにすると、より複雑な実装
デックス圧縮、実際の圧縮デックスは、負荷へのシェルが起動によって初めて、それが起動速度に影響を与えますが、解決することができるだけでなく、より複雑

最適ので、

したがって、最適化ツールやJavaコードは、実際には圧縮手段の中核機構を介して非常に類似し、または切断することです。

リソース

自分自身をリソース

ツール無用資源を走査することにより、それらの自身の理由にはいくつかのプロジェクトでは、明示的な参照を持っていないかもしれませんが、外部のコンパイルスクリプトは非常にピットがあるプロジェクトの独自のスクリプトを変更します
例えばPNGなどの最適化リソース形式は、JPG（アルファチャンネルを除去する）、転送フォーマットWEBPを回します
フォントファイルは、独自の二次リソースの最適化を使用するだけで保持します

リソースのインデックス

よるAndResGuardので、インデックスファイルのサイズを小さくし、リソース名を圧縮する手段。

感情

核となるアイデア

未使用（明らかに）削除
有用な圧縮/転送（例えば、マップテーブル情報混乱このような大きなリソースの転送などの画像、フォントファイル、などの転送もあります）
生成されたシステムを合理化（DEX転位）

簡単にボトルネックに到達するために、従来の手段、そこには深遠な複雑さ、互換性、および他の多くの問題が、一緒に、または2は、以下のとおりです。

深い理解根底：APKコンパイルプロセス、DEXフォーマット、リソース参照は、そのようなロード処理の原則として、プロセスを開始
深い理解ツール：ProGuardの（多くの人がコピーProGuardの設定変更あり）、可約式、AndResGuardなど

道路を計量

多くの場合、最適化はトレードオフである、選択することが重要です。

圧縮デックスは、起動速度を向上させます
行番号を削除し、スタッククラッシュを復元することはより困難です
コードを難読化、それはスクリプトの複雑さを増大させるコンパイル
等

基本的な方法

監視の確立：年に一度のチームは特に、常に混乱、削除、圧縮時のリソースは、このリソースの導入の目的を理解していない、我々は軽率行動する勇気がなかった、インストールパッケージのサイズを最適化します。最後にインクリメンタル記録がある場合には、組立ラインとタイムリーなソリューションをオフにしましょうリマインダーがあるように、システムを持っている、いないすべてのエンドも技術的負債です。
標準の開発：意味では、インストールパッケージのサイズの最適化が個人的なものではなく、チームの事、ベストプラクティスのガイドラインや、関連するコードレビューの規格。無効なロジックは不合理な行動を抑制するためのルールを持っているために、組立ラインオフリソースの導入、あるいはビジネスの後に無視されたとき。

参照

上記

公共のコード番号、最新の情報へのタイムリーなアクセスの注目を掃引へようこそ。