かんたん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. かんたん Android ビルド高速化 東海道らぐ横浜の集い 2018 桜舞う巻 @hota@mstdn.maud.io

  2. 2 自己紹介

  3. 3

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

    • @hota@mstdn.maud.io • Twitter/GitHub: @lindwurm • 春からまた学生に戻ります
  5. 5 いつもの宣伝

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

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

  8. 8 公式アカウントがツイ消し • 具体的な日程がない企画を 2099 年で立てるのはやめよう • ページは消されなかった • ゆるく募集してます

    • akane-blue.connpass.com/ event/82935/
  9. 9 本題

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

    機能追加、それらの翻訳確認 • 最近は kernel に linux-stable を merge する android- linux-stable とかが面白い
  11. 11 ビルド回す上での 微妙なつらさ

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

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

  14. 14 ソリューション

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

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

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

    っぽいとこには関係しないのでハイ • 普通に prebuilt なバイナリがある • export USE_CCACHE=1 立てるだけ • 30GB も割り当てれば足りるはず – prebuilts/misc/linux-x86/ccache/ccache -M 30G
  18. 18 ccache • 初回ビルドはハッシュの生成とか入って少し遅くなる – 自宅マシンだとだいたい 2 時間半 • キャッシュが効くとかなり速い

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

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

    -l – Intel HTT も含めての論理プロセッサの総数 • AOSP はこの数の等倍から 2 倍くらいの N が最も早く なるとしている – source.android.com/setup/building#build-the-code • ほんとか? • 気になったので試してみる
  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) • あんまり変わらなくない?
  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) • 流石にメモリに余裕があるときに減らすのはアホ • 今のところは等倍が最適そう
  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 がおすすめ
  24. 24 ハードウェア編

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

    HDD の差はかなり出るという話 • 気持ち多めの RAM – さっき書いた • 強い CPU – 力こそパワーそれはそう
  26. 26 SSD と HDD でのビルド時間の差 • 差が出るとは聞いてるけど、よく考えたら久しく HDD でビルドしてないので気になってしまった •

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

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

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

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

  31. 31 M/B: PCIe Gen3 対応

  32. 32 CPU: …

  33. 33 CPU: …

  34. 34 CPU: …

  35. 35 CPU: PCIe Gen2

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

    世代が積める – i7-3770/K /S/T • 今の M/B も Gen3 対応なのは確認済 • 総入れ替えまで行かずとも Gen3 接続は可能 • よかったですね – ストレージもあるに越したことはないので当面は Gen2 で使うつもり
  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 のほうがちょっと早い
  38. 38 Gen2/3 間の比較が無いので憶測 • Gen3 接続の NVMe SSD は SATA

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

  40. 40 VPS / クラウドにぶん投げる • 「ビルド用にマシン組む手間も、数万単位の初期投資も 要らない!最高!」 • 「時間課金なんだし、強いインスタンス立てて短時間で 終わらせればいいじゃん!」

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

    とかいう化物みたいな上限 – シャットダウンしてる限り課金が発生しない • Vultr - www.vultr.com – ネットワーク速い – 性能の割に安い (8core/32GB で $0.238/h) – サーバのスナップショット保存が無料
  42. 42 さくらのクラウド • 最初から管理用の一般ユーザ ubuntu が生えていて便利 • コンパネから立てる時点で公開鍵認証オンリーにできる

  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
  44. 44 あまりにも速すぎる回線ーーー!!! http://www.speedtest.net/result/7165299831

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

    もちろん SSD がおすすめ • ディスクのアーカイブ / スナップショットは作成にも 書き戻すのにも時間がかかる(サイズがサイズなので) – 潔く潰して毎回立て直したほうが実は速くて安い – さっき挙げた 2 つならセットアップとソースの取得で 1 時間あれば済みそうなので…
  46. 46 結局どうなん? • 使い方次第 – 都度立てる手間はあっても、強いスペックを非常に安く 済ませたいなら VPS/ クラウドはあり –

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