[Android]
モジュール管理で
ビルド高速化!
!
@ichigotake
!
#potatotips 5
Profile
• name: @ichigotake
• hoby: 2013年夏頃からAndroidアプリ開発
!
• work: スタディプラス株式会社
注意事項
• この実験は全て構想段階もしくは模索中のもの
• まだまだ検証不足( 先週から開始
• gradle-android-plugin の仕様・バグを掴んでい
ないとハマるリスクがとても高い
• 検証の経過報告と思ってください
Androidアプリ開発の悩み
!
• 巨大ではなくてもビルド時間がかる
• すぐに30秒越え
• つらい
• ツラい・つらい……
検証のきっかけ
• ビルド時間を短くしたい!!!!
• LogCatの追記で1分も待たされる…
• ProductFlavors の模索時に気付きを得る
検証のきっかけ
• ビルド時間を短くしたい!!!!
• LogCatの追記で1分も待たされる…
• ProductFlavors の模索時に気付きを得る
• ???「ライブラリのコンパイル速いよね」
試しにアプリケーションプロジェクトを
ライブラリ化してみよう!!!!
まずは結果から
assembleDebugの実行時間
0秒
15秒
30秒
45秒
60秒
大きいアプリ

(12,000行 リソース/依存多)
そこそこのアプリ

(7,000行)
小さいアプリ

(3,000行)
8秒10秒12秒
30秒
...
前提条件
• assembleBuild を通す事のみを確認
(アプリは起動しない
• 試行ケース・回数は少なめ
• 実験結果はあくまで理論値
検証した事
1. 既存アプリを丸ごとライブラリ化
- apply plugin: android'
+apply plugin: android-library'
!
2. mavenLocal化
!
$ ./gradlew :App:uplo...
言いたい事は1つ
構成イメージ
/ProjectRoot
/App # dependencies { compile ${stock} }
/Stock # アプリのソース/リソースを詰めたライブラリ
/repository # /Stock のアップロード先
...
何がダメだったのか
アプリケーションプロジェクトでは…
• 毎回 mergeResource, preDexCompile を実行
• この2つが一番のボトルネック
• ライブラリは clean しない限り1回だけ実行?
効能
コードをいじるためのコストが少し増える
• レガシー資産を凍結する仕組みとして
• 処理の共通化・汎用化への意識向上
• 注) デメリットと表裏一体
考慮すべき事 その1
• Activityはライブラリ化しない
• いわゆるコントローラを楽に編集出来ると小回り
利く
• 密結合度が高いならI/Fの抽出などしてみる
• 自身のモジュール内に置かないとダメなモノもある
• AndroidMan...
考慮すべき事 その2
既存コードの修正が必要な場合も
• ライブラリでは R.* が定数でなくなる
• R.* はアノテーションの引数・case文に使えない
• IDEで switch文をif-else に変換しよう
考慮すべき事 その3
• 毎回実行されるタスクのコストを下げる
• アプリモジュールにモノを置かない工夫
• モジュール の include を増やさない
• 依存でcompile projectを使わない工夫
考慮すべき事 その4
1. いちいちuploadArchivesやるのはめんどう!
2. 作業中だけ作業用モジュールで
3. fixしたらライブラリモジュールへ
など、運用の一例として。
考慮すべき事 そのn
細かい注意点はまだまだ他にも…!!
(5分でまとめるには多すぎる…)
考慮すべき事 まとめ
• アプリモジュールは「今作業してるもの」のみに
すると速くなる
• 用意,運用の手間とビルド時間短縮の費用対効果
• スムーズに移行出来るか,運用で混乱させないか
実験対象の実測値は?
• でかいものは依存が複雑で難しい
• 各種罠と複雑な運用を避けると…
60秒 -> 2,30秒
くらいにはなりそう(未検証/予測値
そもそも…
コード量を減らす,汎用処理はライブラリ化などを
実践していればこの実験も工夫もいらないはず…
新規or小さい規模なら…
• モジュール内に置かないスタイルへの移行はそこ
まで苦にならないはず
• あわよくば独自汎用ライブラリも充実…するか
も
• 後日 検証結果をまとめて公開します
• おおよそ罠と回避策は見つかった
Best, :)
Upcoming SlideShare
Loading in …5
×

Potatotips 5 bakusoku_compile

260 views
193 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
260
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Potatotips 5 bakusoku_compile

  1. 1. [Android] モジュール管理で ビルド高速化! ! @ichigotake ! #potatotips 5
  2. 2. Profile • name: @ichigotake • hoby: 2013年夏頃からAndroidアプリ開発 ! • work: スタディプラス株式会社
  3. 3. 注意事項 • この実験は全て構想段階もしくは模索中のもの • まだまだ検証不足( 先週から開始 • gradle-android-plugin の仕様・バグを掴んでい ないとハマるリスクがとても高い • 検証の経過報告と思ってください
  4. 4. Androidアプリ開発の悩み ! • 巨大ではなくてもビルド時間がかる • すぐに30秒越え • つらい • ツラい・つらい……
  5. 5. 検証のきっかけ • ビルド時間を短くしたい!!!! • LogCatの追記で1分も待たされる… • ProductFlavors の模索時に気付きを得る
  6. 6. 検証のきっかけ • ビルド時間を短くしたい!!!! • LogCatの追記で1分も待たされる… • ProductFlavors の模索時に気付きを得る • ???「ライブラリのコンパイル速いよね」
  7. 7. 試しにアプリケーションプロジェクトを ライブラリ化してみよう!!!!
  8. 8. まずは結果から assembleDebugの実行時間 0秒 15秒 30秒 45秒 60秒 大きいアプリ
 (12,000行 リソース/依存多) そこそこのアプリ
 (7,000行) 小さいアプリ
 (3,000行) 8秒10秒12秒 30秒 40秒 60秒 Before After
  9. 9. 前提条件 • assembleBuild を通す事のみを確認 (アプリは起動しない • 試行ケース・回数は少なめ • 実験結果はあくまで理論値
  10. 10. 検証した事 1. 既存アプリを丸ごとライブラリ化 - apply plugin: android' +apply plugin: android-library' ! 2. mavenLocal化 ! $ ./gradlew :App:uploadArchives # /repository へ 3. 新アプリモジュール内はAndroidManifestのみ
  11. 11. 言いたい事は1つ
  12. 12. 構成イメージ /ProjectRoot /App # dependencies { compile ${stock} } /Stock # アプリのソース/リソースを詰めたライブラリ /repository # /Stock のアップロード先 mavenLocal() で /repository を追加しておく
  13. 13. 何がダメだったのか アプリケーションプロジェクトでは… • 毎回 mergeResource, preDexCompile を実行 • この2つが一番のボトルネック • ライブラリは clean しない限り1回だけ実行?
  14. 14. 効能 コードをいじるためのコストが少し増える • レガシー資産を凍結する仕組みとして • 処理の共通化・汎用化への意識向上 • 注) デメリットと表裏一体
  15. 15. 考慮すべき事 その1 • Activityはライブラリ化しない • いわゆるコントローラを楽に編集出来ると小回り 利く • 密結合度が高いならI/Fの抽出などしてみる • 自身のモジュール内に置かないとダメなモノもある • AndroidManifestで参照する R.* など
  16. 16. 考慮すべき事 その2 既存コードの修正が必要な場合も • ライブラリでは R.* が定数でなくなる • R.* はアノテーションの引数・case文に使えない • IDEで switch文をif-else に変換しよう
  17. 17. 考慮すべき事 その3 • 毎回実行されるタスクのコストを下げる • アプリモジュールにモノを置かない工夫 • モジュール の include を増やさない • 依存でcompile projectを使わない工夫
  18. 18. 考慮すべき事 その4 1. いちいちuploadArchivesやるのはめんどう! 2. 作業中だけ作業用モジュールで 3. fixしたらライブラリモジュールへ など、運用の一例として。
  19. 19. 考慮すべき事 そのn 細かい注意点はまだまだ他にも…!! (5分でまとめるには多すぎる…)
  20. 20. 考慮すべき事 まとめ • アプリモジュールは「今作業してるもの」のみに すると速くなる • 用意,運用の手間とビルド時間短縮の費用対効果 • スムーズに移行出来るか,運用で混乱させないか
  21. 21. 実験対象の実測値は? • でかいものは依存が複雑で難しい • 各種罠と複雑な運用を避けると… 60秒 -> 2,30秒 くらいにはなりそう(未検証/予測値
  22. 22. そもそも… コード量を減らす,汎用処理はライブラリ化などを 実践していればこの実験も工夫もいらないはず…
  23. 23. 新規or小さい規模なら… • モジュール内に置かないスタイルへの移行はそこ まで苦にならないはず • あわよくば独自汎用ライブラリも充実…するか も
  24. 24. • 後日 検証結果をまとめて公開します • おおよそ罠と回避策は見つかった
  25. 25. Best, :)

×