[Android]
兄弟アプリのロジック共通化と
ビルド高速化の実験
#potatotips 6
!
@ichigotake
Profile
• name: @ichigotake
• hobby: Androidアプリ開発 (not OSS, ストア未公開)
• like: ちっちゃいもの
• work: スタディプラス株式会社
アジェンダ
• 趣味でAndroidアプリ作ってます
• 兄弟アプリをとにかく共通化したい
• 試験運用してる事
• 効能
• 落としどころ
用語について
• アプリ: アプリケーションプロジェクトを表す
• `apply plugin: android `
• ライブラリ: ライブラリプロジェクトを表す
• `apply plugin: android-library `
趣味でアプリ作ってます
• 常にAndroidStudioの最新版を追いかける
• 1つ作ったら兄弟アプリをカジュアルに作りたい
• 設計力を高めたい…
兄弟アプリをとにかく共通化したい
• アプリブランディングと保守性の確保
• 再利用性の高い運用法を探りたい
• 運用実験も兼ねてライブラリ化でビルド高速化も狙う
A. Androidアプリの設計を探る
B. ライブラリ利用前に地力向上したい
...
試験運用してる事
ProductFlavorの代替としてのライブラリ化
ビルド高速化実験を試しつつ、落としどころを探る
Android/Gradleのビルド高速化実験を試験運用してみる
http://ichigotake.hateblo.jp/...
ライブラリ化の効能
• アプリに置くよりはキャッシュが多少強い
• 再利用しやすい実装を意識しやすくなる
• いい設計のメリットが目先(ビルド時間)ですぐにわかる
• 基幹更新を特定アプリにだけ適用したい! -> できる!!
• Product...
構成イメージ
アプリ
Activity
Fragment
DownloadManager
Service
クリックイベントリスナ
独自データと共通interfaceの繫ぎ
ライブラリ
Adapter
ViewBinder
DownloadMan...
ライブラリ化の懸念
!
• 変な罠が多い / ライブラリの更新という一手間 ※前述のブログ参照
• IDEの恩恵が薄い(refactor/コードジャンプ
• 変更の激しい時だけ project compile にする? -> めんどう…
• 複...
落としどころ
• 運用ルールが増えるよりは既存の構成がいいかも
• 実装共有はProductFlavor or マルチプロジェクトが無難?
• ビルド時間を稼いでも運用で混乱したら本末転倒
• 変更が容易orテストが簡単なものをライブラリ化?
...
落としどころ
• スタイル合わせのベストな方法を選ぼう
• ProductFlavor / ライブラリ化 / マルチプロジェクト(git-submodule)
• アプリとライブラリでパッケージ名を分けると一元化に戻すのも楽
• アプリも再利用...
落としどころ
• シンプルな運用法が一番
• やるなら高速化よりも共通化を主眼に置くのが無難
• OOP矯正ギブスとして?
• まだ小さいので高速化効果のほどは不明
落としどころ
何もせずに正座で公式の高速化に期待する
↑
BEST!!!!
参考比較
記録と記憶を頼りにした概算・感覚値(うろ覚え
大きくなったらちゃんとした比較をしたい
ビルド時間 Java行数 Javaファイル数
アプリA: 従来の構成 16-3?秒 約6,700行 148
アプリA: app+library 16...
おわり XD
Upcoming SlideShare
Loading in …5
×

兄弟アプリのロジック共通化とビルド高速化の実験

796 views

Published on

先月のビルド高速化実験を試験運用して思った事

実験記録: http://ichigotake.hateblo.jp/entry/2014/03/15/105451

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
796
On SlideShare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

兄弟アプリのロジック共通化とビルド高速化の実験

  1. 1. [Android] 兄弟アプリのロジック共通化と ビルド高速化の実験 #potatotips 6 ! @ichigotake
  2. 2. Profile • name: @ichigotake • hobby: Androidアプリ開発 (not OSS, ストア未公開) • like: ちっちゃいもの • work: スタディプラス株式会社
  3. 3. アジェンダ • 趣味でAndroidアプリ作ってます • 兄弟アプリをとにかく共通化したい • 試験運用してる事 • 効能 • 落としどころ
  4. 4. 用語について • アプリ: アプリケーションプロジェクトを表す • `apply plugin: android ` • ライブラリ: ライブラリプロジェクトを表す • `apply plugin: android-library `
  5. 5. 趣味でアプリ作ってます • 常にAndroidStudioの最新版を追いかける • 1つ作ったら兄弟アプリをカジュアルに作りたい • 設計力を高めたい…
  6. 6. 兄弟アプリをとにかく共通化したい • アプリブランディングと保守性の確保 • 再利用性の高い運用法を探りたい • 運用実験も兼ねてライブラリ化でビルド高速化も狙う A. Androidアプリの設計を探る B. ライブラリ利用前に地力向上したい C. ライブラリ化されているとカジュアルに作れる(ヤッタ
  7. 7. 試験運用してる事 ProductFlavorの代替としてのライブラリ化 ビルド高速化実験を試しつつ、落としどころを探る Android/Gradleのビルド高速化実験を試験運用してみる http://ichigotake.hateblo.jp/entry/2014/03/26/114954 要約: 実装をMaven(aar)化するとビルド高速化できるよ! でも罠が多いよ!AndroidStudio(Gradle)難しい!!
  8. 8. ライブラリ化の効能 • アプリに置くよりはキャッシュが多少強い • 再利用しやすい実装を意識しやすくなる • いい設計のメリットが目先(ビルド時間)ですぐにわかる • 基幹更新を特定アプリにだけ適用したい! -> できる!! • ProductFlavorは出来ない(もしくはめんどう • マルチプロジェクトよりMavenがシンプル (git-submoduleはややこしい)
  9. 9. 構成イメージ アプリ Activity Fragment DownloadManager Service クリックイベントリスナ 独自データと共通interfaceの繫ぎ ライブラリ Adapter ViewBinder DownloadManager.Request データ定義 その他 interface interfaceを扱う具象クラス 兄弟間で異なる仕様をなるべく作らない方針 DI化を徹底 アプリの実装はほぼ画面遷移のみ 実装は基本的にココへいわゆるコントローラのみ
  10. 10. ライブラリ化の懸念 ! • 変な罠が多い / ライブラリの更新という一手間 ※前述のブログ参照 • IDEの恩恵が薄い(refactor/コードジャンプ • 変更の激しい時だけ project compile にする? -> めんどう… • 複数人開発…(オススメはできない • ビルド高速化のためだけに適用すると苦労の方が大きそう • アプリ間の実装共有効果と合わせて運用コストと相談 • 慣れるまでは一人開発でもファイルの所在で混乱する
  11. 11. 落としどころ • 運用ルールが増えるよりは既存の構成がいいかも • 実装共有はProductFlavor or マルチプロジェクトが無難? • ビルド時間を稼いでも運用で混乱したら本末転倒 • 変更が容易orテストが簡単なものをライブラリ化? • interface, データ定義, リソースetc… • 仕様の固まったものをライブラリ化してビルド時間節約?
  12. 12. 落としどころ • スタイル合わせのベストな方法を選ぼう • ProductFlavor / ライブラリ化 / マルチプロジェクト(git-submodule) • アプリとライブラリでパッケージ名を分けると一元化に戻すのも楽 • アプリも再利用性を強く意識すると、よりカジュアルに兄弟アプリ が作れる • たのしい X)
  13. 13. 落としどころ • シンプルな運用法が一番 • やるなら高速化よりも共通化を主眼に置くのが無難 • OOP矯正ギブスとして? • まだ小さいので高速化効果のほどは不明
  14. 14. 落としどころ 何もせずに正座で公式の高速化に期待する ↑ BEST!!!!
  15. 15. 参考比較 記録と記憶を頼りにした概算・感覚値(うろ覚え 大きくなったらちゃんとした比較をしたい ビルド時間 Java行数 Javaファイル数 アプリA: 従来の構成 16-3?秒 約6,700行 148 アプリA: app+library 16-19秒 約3,800行 app + library 約1,500行 + 約2,300行 97 アプリB: 従来の構成 14-24秒 約3200行 82
  16. 16. おわり XD

×