かんたんAndroidビルド高速化 / tokaidolug-yokohama-201803

8d165742bfa77804ae2fc8bd3962473b?s=47 hota
March 24, 2018

かんたんAndroidビルド高速化 / tokaidolug-yokohama-201803

横浜で喋ったやつです。
https://tokaidolug.connpass.com/event/78990/

久々にAndroid要素があります。

合わせて読んで欲しい(ダイレクトマーケティング): https://dev.maud.io/entry/2018/03/19/howto-build-lineageos-15-1/

8d165742bfa77804ae2fc8bd3962473b?s=128

hota

March 24, 2018
Tweet

Transcript

  1. 3.

    3

  2. 4.

    4 自己紹介 • ほた • Android のビルド・翻訳・開発動向追っかけ • mstdn.maud.io 管理

    • @hota@mstdn.maud.io • Twitter/GitHub: @lindwurm • 春からまた学生に戻ります
  3. 6.

    6 Mastodon • そろそろ 1 年ですね • mstdn.maud.io やってます •

    ユーザ数 800 人を超えました • 割と見かける(アクティブ)のは凡そ 50-60 人 • OSC や東海道らぐへの導線にも? • たのしい
  4. 10.

    10 Android をビルドする • 最新の Android バージョン • 最新のセキュリティパッチ •

    機能追加、それらの翻訳確認 • 最近は kernel に linux-stable を merge する android- linux-stable とかが面白い
  5. 12.

    12 Android のビルドのつらみ • そもそも規模がでかい – Git リポジトリ数 600 強

    • kernel のリポジトリもほぼ機種ごとに生える • 細かく別れてるかと思いきや、でかいリポジトリがある – frameworks_base.git: 2.4GB • out も 30GB くらいは平気で食う • /tmp も酷使する
  6. 15.

    15 ビルドを高速化する手法 • ソフトウェア側の工夫 – ccache を使う – make -jN

    の N の最適値を探る • ハードウェア側を強化する – より良いストレージ – 気持ち多めの RAM – 強い CPU • 雲の向こうに任せる
  7. 16.
  8. 17.

    17 ccache • C/C++ コンパイラの出力をキャッシュする • HAL より下のレイヤには効果的 – Java

    っぽいとこには関係しないのでハイ • 普通に prebuilt なバイナリがある • export USE_CCACHE=1 立てるだけ • 30GB も割り当てれば足りるはず – prebuilts/misc/linux-x86/ccache/ccache -M 30G
  9. 18.

    18 ccache • 初回ビルドはハッシュの生成とか入って少し遅くなる – 自宅マシンだとだいたい 2 時間半 • キャッシュが効くとかなり速い

    – make clean した後でも 36 分くらい • どのみち Java 絡みは普通にビルドされるので、更新が そんなに多くならない HW 周りのビルドを短縮できて おいしい
  10. 20.

    20 make -jN (N=?) • grep processor /proc/cpuinfo | wc

    -l – Intel HTT も含めての論理プロセッサの総数 • AOSP はこの数の等倍から 2 倍くらいの N が最も早く なるとしている – source.android.com/setup/building#build-the-code • ほんとか? • 気になったので試してみる
  11. 21.

    21 自宅ビルド鯖 (mashiro) で検証 – i7-2600K(4C/8T), 32GB(PC3-12800), 500GB SSD(SATA) •

    make -j8 – 初回 / 02:32:02(hh:mm:ss) – Ccache / 38:56(mm:ss) • make -j16 – 初回 / 02:31:33 (hh:mm:ss) – Ccache / 35:27 (mm:ss) • あんまり変わらなくない?
  12. 22.

    22 あえて減らす(おまけ) • make -j4 – 初回 / 03:02:25 (hh:mm:ss)

    – Ccache / 42:38 (mm:ss) • make -j8 (参考) – 初回 / 02:32:02(hh:mm:ss) – Ccache / 38:56(mm:ss) • 流石にメモリに余裕があるときに減らすのはアホ • 今のところは等倍が最適そう
  13. 23.

    23 注意点(ちょっと HW 寄り) • コア数に見合った十分な RAM が必要 – Java

    / Jack 周りのために – 推奨は > 4GB かつ、論理プロセッサ数 *2-4GB • 4core/8GB でも out of memory でコケるけど Jack の設定を ちょっと直せばよくて、 export ANDROID_JACK_VM_ARGS="- Dfile.encoding=UTF-8 -XX:+TieredCompilation -Xmx4G"   とかしてやると 4 時間ちょっとで終わる • 少なくとも N* 2GB の RAM を確保した上での make -jN がおすすめ
  14. 25.

    25 ボトルネックになりがちと言われる順 • より良いストレージ – I/O は最大のボトルネック – SSD >

    HDD の差はかなり出るという話 • 気持ち多めの RAM – さっき書いた • 強い CPU – 力こそパワーそれはそう
  15. 26.

    26 SSD と HDD でのビルド時間の差 • 差が出るとは聞いてるけど、よく考えたら久しく HDD でビルドしてないので気になってしまった •

    レギュレーション – さくらのクラウドで 8core/32GB を 2 つ立てる – make -j8 – ストレージはそれぞれ 250GB の SSD, HDD – manifest やターゲットは手元と同じものを使用 – めんどいので ccache 無効で初回ビルドだけ
  16. 27.

    27 SSD と HDD でのビルド時間の差 • 結果 – HDD: 01:55:47

    (hh:mm:ss) – SSD: 01:43:10 (hh:mm:ss) • HDD もサーバ用のそれなのか、思ったほどは差がない みたいなところはある – 型番確認すればよかったですね – 5400rpm HDD → SSD とかならもうちょい恩恵がありそう • リポジトリの取得、 fetch は HDD が目に見えて遅い
  17. 29.

    29 うおおお NVMe SSD だ • Intel SSD 750 Series

    (SSDPEDMW400G4X1) • 400GB あれば ccache 含めてもビルドには十分すぎる • 流行りの M.2 スロットはまだ Sandy 世代なビルド鯖の M/B には無いので PCIe 接続なの助かる – ビルド鯖なので GPU 挿してない • PCIe 3.0 (Gen3) – ん?
  18. 36.

    36 PCIe Gen3 の夢 • 幸いなことに LGA1155 は Ivy Bridge

    世代が積める – i7-3770/K /S/T • 今の M/B も Gen3 対応なのは確認済 • 総入れ替えまで行かずとも Gen3 接続は可能 • よかったですね – ストレージもあるに越したことはないので当面は Gen2 で使うつもり
  19. 37.

    37 一応ビルド回してみる (make -j8) • SATA3 接続の 2.5” SSD (Samsung

    850 EVO) – 初回 / 02:32:02(hh:mm:ss) – Ccache / 38:56(mm:ss) • PCIe Gen2 接続の NVMe SSD (Intel 750) – 初回 / 02:30:51(hh:mm:ss) – Ccache / 36:01(mm:ss) • 少し速いかな程度 – ちなみに -j16 で回したら SATA のほうがちょっと早い
  20. 38.

    38 Gen2/3 間の比較が無いので憶測 • Gen3 接続の NVMe SSD は SATA

    SSD と比較して実測 で 2.5 倍くらい速いらしい • PCIe Gen3 は Gen2 の 2 倍の帯域幅 • SSD だと SATA3 と PCIe Gen2 ではそこまで差が 出ない? • さっきの結果もそういうことなのでは – 複数回測る余裕がなかったのでガバ • CPU 性能で頭打ちの可能性もある
  21. 41.

    41 わたしが試したやつ • さくらのクラウド - cloud.sakura.ad.jp – 柔軟なスペック選択 – 36core/224GB

    とかいう化物みたいな上限 – シャットダウンしてる限り課金が発生しない • Vultr - www.vultr.com – ネットワーク速い – 性能の割に安い (8core/32GB で $0.238/h) – サーバのスナップショット保存が無料
  22. 43.

    43 Vultr • VPS: 7 カ国 15 箇所から選べるリージョン – 東京もある

    • ベアメタルインスタンスも安い – なんか 60% OFF になってて $0.179/h で 8core / 32GB RAM / 240GB SSD*2 (sofware RAID1 可 ) が立つ – 東京は無い ( アメリカ / シンガポール / オランダ ) • ネットワークめちゃ速い – http://www.speedtest.net/result/7165299831
  23. 45.

    45 共通の注意点 • ビルドに 150GB は必須なので少なくとも 200GB 以上 のディスクを持ったプランが必要 –

    もちろん SSD がおすすめ • ディスクのアーカイブ / スナップショットは作成にも 書き戻すのにも時間がかかる(サイズがサイズなので) – 潔く潰して毎回立て直したほうが実は速くて安い – さっき挙げた 2 つならセットアップとソースの取得で 1 時間あれば済みそうなので…
  24. 46.

    46 結局どうなん? • 使い方次第 – 都度立てる手間はあっても、強いスペックを非常に安く 済ませたいなら VPS/ クラウドはあり –

    24/7 いつでもすぐにビルド回し始められる環境、継続的 な使用を求めるなら手元にマシン置いたほうが良い – わたしは基本自宅のビルド鯖使ってて、既に安定した 複数機種向けのリリースをまとめてビルドしたいときに VPS/ クラウドで一時的に強いインスタンス使ってます