Spotify: iOSのビルド作業時間を短縮する

http://labs.spotify.com/2013/11/04/shaving-off-time-from-the-ios-edit-build-test-cycle/

1 comment | 0 points | by Jshiike 約3年前


Jshiike 約3年前 | ▲upvoteする | link

Spotifyのブログで、iOSのビルド作業において、XCodeが実行する間の待ち時間を短縮する取組みを紹介しています。



1) 背景


ソースコードをいじった後、XCodeでRunボタンを押してからシミュレータで結果を確認できるまでの時間は、自宅のiMacで平均82秒かかっていた。コマンドラインで確認したところ、linkingで29秒、dSYMファイルの生成で25秒。SpotifyのiOSクライアントのコードベースはかなり大きく、linkerが2,000のオブジェクトファイルをまとめる必要があるので、おそらく取組みがいがあると判断。


2) dSYM file generation


dSYMは、OSXの初期、linkerでDWARFをサポートするのに気乗りしなかったAppleが、オブジェクトファイルからデバッグの情報を取得して、共有の場所に置く (dSYM bundle)、別のlinkerファイル (dsymutil) をつくることで回避したのがはじまり。dSYM bundleは本番リリースには有用だが、開発時点ではなくてもよいので、ビルドの “Debug Information Format” を “DWARF with dSYM File” から “DWARF” に変更。


3) Linking


少し古いがAppleはld64のソースコードを公開しているので、プロファイルをチェックしてみた。(スクリーンショット)ld::tool::Resolver::resolve() はld64のパイプラインのResolvingステージに対応している、つまりこのステージは各オブジェクトファイルのグラフを大きなグローバルグラフにもっていく役割を担っている。(ld64のドキュメント


各オグジェクとファイルのグラフを読み込むのは早めの段階でおきるので、resolveにコストがかかり、実行時間の多くを占めるというのは解せない。詳しく見ると、linkingの53%が ld::tool::Resolver::linkTimeOptimize() であることがわかる。Clang/LLVMの世界では、Link Time Optimization (LTM) をしているということは、linkerは通常のオブジェクトファイルではなく、LLVM bitcodeファイルを扱ってるということになる。よって、このbitcodeは高い抽象化レベルのプログラムとしてLTOをするが、一方副作用として、ネイティブコードに翻訳される必要があるので、linkに余計な処理時間がかかってしまう。


最終的に、原因となるbitcodeファイルが、-O4コンパイルセッティングされている静的ライブラリにあるのを発見し、最適化レベルを -O3 に変更し、linkerは51%スピード改善。


4) Profit


自宅のiMACで40秒改善したので、


  • 新しいハードに替えて x2効果

  • エンジニアあたりEdit-Build-Testサイクルが10分

  • エンジニアが1日5時間開発する

として、40s / 2 * (5 * 60 / 10) = 600s = 10m/developer/day


SpotifyのようにiOSエンジニアが多い所帯だと、1年トータルでそれなりに時間の節約効果はでるのではないか。


5) Future work


次の社内ハッカソンでld64向けのincremental linkingに挑戦して、更なる改善を図りたい。


また、ブランチを頻繁に変更し、都度ビルドを強いられるエンジニアもいるが、AppleはXCode4.3で分散ビルドのサポートを取りやめているCocoa Podsのバイナリバージョンをつくる、もしくはgit hashを利用したオブジェクト/ライブラリストレージなどのアイデアも話している。


次はAndroidビルドの業務改善に取り組みたい。




Path: スクローリング時の画像表示を早くするiOSライブラリをオープンソースで提供


iOS: 地図にデータを効率よく表示する



#spotify #モバイル #モバイルアプリ #ios #iphone #開発スタイル #コーディング

Back