R8：GOOGLEのANDROID ビルドパフォーマンスロードマップの1ステップ
Google は最近 Android のビルドプロセスにおいて、デフォルトのコード圧縮ツールとして ProGuard を置き換えるために設計された新しいツール R8 をリリースしました。R8 は ProGuard と同等もしくはそれより優れた出力を生成し、なおかつ ProGuard よりも速く生成する目的で製品化されており、全体のビルド時間を短縮します。R8 は次のリリースの Android Gradle Plugin (v3.4)になるとデフォルトで有効になります。
この変更によって古くからあるコンポーネントの ProGuard が削除され、本質的に同じことをする全く新しいコードに置き換えられます。なぜ Google はこのような高コストでリスクのあることをするのでしょうか？私たちは R8 が初めて公開された時から開発を追跡してきましたが、とても良いアイデアがありました。
Google はビルドパフォーマンスに重点をおいており、R8 は、おそらく従来のJavaバイトコードを完全にプロセスから削除することにより、現在使用されているツールチェーンよりはるかに高速にビルドできる単一コンポーネントのツールチェーンへの道をたどる一歩となります。R8 自身にはそれほど大きな違いはありません。
生成されるファイルサイズとビルドスピードは少しずつ改善されていますが、“後”のビルドは“前”のビルドとほぼ同じです。このステップの価値は、サードパーティのコンポーネントに依存しなくなったため、Google がビルドプロセスをさらに反復して、さらに大きなアーキテクチャの変更を行うことができるようになることです。 これを理解し、さらに今後どこへ向かっているのかということを知るために、Android のビルドプロセスの歴史を振り返ってみましょう。
Android のビルドは Java ソースをJavaバイトコードにコンパイルし、Android dex に変換するため、本質的には複雑です。ここでのバイトコードのプロセスは基本的に必要ではないのでJavaソースコードから dex に直接変換することは可能です。この二段階の変換によりビルドに時間がかかり、それはまた開発者を遅延させ、結果的に全体のエコシステムにおいて悪い圧力を与えます。
Googleはこの事実を重く受け止めています。
2014年、Google は先程の二段階のビルドプロセスを、Java ソースから dex バイトコードに直接変換するために一段階のプロセスに置き換えるように設計された試験的な Jack ツールチェーンを発表しました。この考えは jack が一つのツールチェーン上で不要な変換をせずに全てのビルドを実行するというものです。これによりプロセスは遥かに素早く行われるようになります。
残念なことに、このアプローチはいくつかの大きな障壁に直面します。
まず、もともとの二段階のビルドプロセスは、実のところほんの一部にしか過ぎません。多くの開発者は三段階以上のプロセスを必要とします。
追加のビルドプロセスを使用する開発者のために、Jack には同様の機能を提供する必要がありました。コード圧縮の場合、Google は Jack 内部で独自の実装によりサポートを提供しました。しかし、これらのサードパーティ製のプラグインは動作対象のバイトコードがないため機能しません。これはこのプラグインを使用していた人たちにとっては大きな問題で、実際に多くのプラグインと多くのユーザーに影響がありました。
また、重要な機能 Instant Run を含む、いくつかの Google の他のビルド機能は、Jack ツールチェーンでは動作しませんでした。これは皮肉なことです。なぜならば、Instant Run は実質的には Jack と同じ目的（開発者がより速く作業できるようにサポートすること）を掲げていたからです。
そのため、Jack が開発コミュニティにおいて明らかな勝利にはなりませんでした。しかし、それでも Google はイチかバチかの賭けに出て、Jack ツールチェーンを使用していた開発者向けに Java 8 言語機能のみをサポートすると発表しました。これは開発者に Jack への移行の動機を与える目的でしたが、コミュニティの反応は今ひとつでした。それどころか、それは裏目となりました。
2017年3月、Google は Jack ツールチェーンを廃止させることで落ち着かせ、コアツールチェーンに Java 8 のサポートを移行させました。
この歴史がなぜ重要なのでしょうか。それはまず、いかに Google がビルドのパフォーマンスにこだわったか、またどれほどまでに彼らがそれを達成しようとしているかを表しています。次に、2017年のビルドツールチェーンがどのようになったかを説明します。
2017年のこの時点において、ビルドは 2014年に比べてアーキテクチャ上さらに複雑になりました。
Google はあきらめませんでした。その年（2017年）の後半に Google は dex コンパイラの DX のオプションの代替品として、より高速に実行し、より小さな出力バイナリーを生成するように明確に設計された D8 をリリースしました。そして、desugar のプロセスを D8 の中に移行させることにより、アーキテクチャをシンプルにし、ビルドプロセスがより高速になるようにしました。D8 のビルドプロセスは次のようになります。
Google は、2018年には D8 をデフォルトの dex コンパイラにしました。
そして現在、2019年にProGuardの代わりとなり、かつ D8 のすべての機能をあわせ持つ R8 をリリースしました。それにより、ビルドプロセスは以下のようになりました。
これは、もう1つの大きなアーキテクチャ上の改善点となります、ツールチェーンに含まれるツールが1つ少なくなり、R8 は ProGuard と比較してより速く、より小さくできるようになりました。R8 はあらゆる点で優れています。
Google は Jack と同じ方向（Java ソースから dex に直接変換する一段階のビルドプロセス）に向かっているように思えます。今や、彼らはすべてのツールチェーンを管理下に置いているので、彼らが更にそのアーキテクチャを進化させ続けると私たちは確信しています。次のアーキテクチャの変更はバイトコードのステージを完全にスキップすることです。
明らかにこれはサードパーティのプラグインにとっては大きな変化であり、Google は彼らがそれを受け入れられたいのであれば、これをゆっくりと進めていく必要があります。彼らは D8 と R8 を使って、これらの変更を一度に一つずつ実行することを望んでいると証明しました。私たちはより計算された手段でこの変更を行っていくのだろうと思っています。そしてそれはおそらく成功することでしょう。
結論として、私たちは R8 を“ただのもう一つのツール”としてではなく、アーキテクチャビジョンにおいて“もう一つの重要なステップ”と捉えており、それは最終的には純粋な dex ビルドプロセスになりうるかもしれません。
このビジョンを念頭に、あなたは私たちが DashO for Java/Android (Android と緊密に統合される私たちの強力な Java 難読化およびアプリケーション保護ツール)に大きな変化が来ることを想像しているでしょう。そして私たちはそれを実行します。私たちは“未来”について話すのは好きではありませんが、私たちの新しいアプローチの初期のバージョンを試したお客様は、私たちの今後の変化について楽しみにしていると私は言います。
詳細については、お気軽にお問い合わせください。アプリケーションの保護を強化されたいとお考えのお客様とお話しできることを楽しみにしています！
https://www.preemptive.com/blog/article/1101-r8-a-step-in-google-s-android-build-performance-roadmap/89-DashO
（April 5, 2019 Nathan Arthur 著）