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

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

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

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

Transcript

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