［優れたUXを目指して］アプリの性能について：第３回

1. 環境を知る 　2. 実行回数を知る 　3. 描画を知る 　4. メモリを知る 　5. 処理タイミングを知る　 　6. 通信を知る 　7. ビルドを知る

TEXT: 2020年7月6日 上田恵

処理タイミングの一つ目の話はファイルのロードタイミングです。アプリを起動する際、いろいろなファイルをロードすると思いますが、適切なタイミングでロードすることで起動速度を最適化できます。

例えば、Webであれば CSSやJSファイルの読み込みタイミングになります。ブラウザでWebサイトを開いた際、ブラウザは返ってきたHTMLを上から順番に処理していきますが、その途中で重たい読み込み処理があるとそこで画面の描画が止まってしまいます。そのため、今では慣習のように書いてますが、JSファイルはHTMLの最後の方でロードすることが多いかと思います。最初に全てHTMLを描画させてしまい、後からJSファイルを読み込み、処理を開始するためです。さらにCSSや画像などにはpreloadという指定をすることができます。

こうすることで優先的にダウンロードするようにブラウザに指示できるので、状況によるとは思いますが初期画面の表示にかかる時間を最適化できる可能性があります。ただし、preloadのブラウザサポートは完璧ではないので注意が必要です。

JSファイルも読み込みタイミングを調整可能です。最近のWebアプリ開発では、巨大な1個のJSファイルを作らずに複数のJSファイルまたはTSファイルをwebpackのようなバンドラーで1個にまとめていると思います。このまとめ方も1個にせずに、必要な単位で分割することができます。

ルーティングの単位で分割したり、もしくはユーザーがよく使う機能・画面が最初から想定できるのであればよく使う機能だけは最初に読み込んでおいて、あまり使われない機能は必要な時に読み込むようにするなど、色々な戦略が考えられます。例えばAngularのルーティング機能であれば暇な時に先読みするような機能もあります。

ファイルの単位は更新頻度も考慮すると良いかもしれません。よくあるのは、滅多に更新しないサードパーティ製のライブラリやフレームワーク等だけ別ファイルにまとめておくことで、何かしらのアプリ修正が入ったとしてもサードパーティのJSファイルだけはブラウザのキャッシュを利用して読み込むのでダウンロード時間に影響を与えないという手法です。

最後はビルドの話です。プログラムを書いたら最後はビルドしてアプリを配布可能な状態にしますが、そこでもいろんな工夫がされています。

WebアプリであればTree Shakingとminifyがあります。Tree Shakingとは利用されていないコードを除去する機能です。不要なコードを削除することでファイルサイズを小さくします。minifyはファイルから空白や改行を除去したり、変数名を短くしたりロジックを短くしたり、など色々な方法で記述内容を減らしてファイルサイズを小さくしてくれます。環境によってはProductionのビルドをすると自動的にしてくれるので意識していない人もいるかもしれませんが、一から開発する場合は必ずチェックしておかないといけないことなので知っておく必要があります。

他にも AOT（Ahead-of-time）という機能があります。これはアプリ動作時に実行・解釈している処理をアプリコンパイル時に実行する機能です。AOTにすると一般的には生成されるファイルサイズが大きくなりますが、処理が効率化されるため性能は向上します。

この仕組みは、その環境で直接動くようなバイナリでない限りは、何かしら独自の構文で処理ステップが書かれており、それを解釈しながら、より低レイヤーな命令に変換しています。AOTとはその変換処理を事前にやってしまうことです。一般的にはコンパイル時に変換してしまうとコンパイル結果のファイルは大きくなります。ファイルが大きくなるデメリットよりも性能向上によるメリットの方が大きい場合にAOTを利用します。

しかし、必ずファイルが大きくなるわけではなく、例えば AngularであればAOTを使うと、Webアプリ実行時にAngularのランタイムが不要となるために結果的にはファイルサイズが小さくなる、といったこともあります。ここでいうAngularのランタイムとは、Angularの構文で書かれた処理を解釈する機能のことを指します。Angularのランタイムはかなりファイルサイズが大きいため、AOTによるファイルサイズ肥大化よりもランタイムをなくす方が最終的なファイルサイズが小さくなる可能性があるのです。実際、よっぽど巨大な WEB アプリでない限りは AOTにした方が軽くなるはずです。

ちなみに他のプラットフォームの話をするとAndroidの場合はJIT/AOTの両方が動きますが、iOSについてはシミューレーターはJITですが、実機はAOTでないと動かないようになっています。

このように利用するプラットフォーム、フレームワーク毎に様々な手段が用意されています。コンパイラには私のような常人には理解できないレベルでいろんな工夫がされていますので、変な小細工は考えず最適化周りはコンパイラに任せるというのも手です。

例えば、私が学生時代はgccでC++をコンパイルして研究用のプログラムを実行していました。AOT/JITの話でいうとAOTになります。gccには最適化オプションがあるのですが、最適化オプションをつけると劇的に処理速度が早くなりました。中身としては関数のインライン展開をしていたりします。関数呼び出しをするためには、レジスタの値をスタックに積んで関数のプログラムまでジャンプするという処理がアセンブラレベルでは実行されており、関数呼び出しをなくすだけでもそれらの処理ステップが省けて高速になるという仕組みでした。

ただし、何でもかんでもインライン展開すれば良いと言うわけではないらしく、インライン展開するべきかどうかをヒューリスティックに判定していると聞いたことがあります。この話自体はかなり昔の話なので今でも通用する話かはわかりませんが、いずれにせよ人類の叡智が詰まっていると言っても過言ではなく、小手先の工夫をするよりもコンパイラに任せる方が無難なことが多いでしょう。

利用する開発環境やフレームワークなどにどういったコンパイル機能が用意されているかは知っておいても損はないと思います。