Building Android Apps — 30 things that experience made me learn the hard way — Medium
読んでみましたが, 納得できることばかりです.
一読の価値はあると思います.
実際は, 35個ありました.
1. サード・パーティのライブラリを追加する前に2度考えよう. それは本当に重要な決意なのです.
2. ユーザーがそれを見ることができないならば, 描画してはならない.
見えないところは塗りつぶすな – 不要なオーバードロー削除で高速化
3. 本当に必要でなければデータベースは使うな.
4. メソッド数 65000個はすぐに到達するが MultiDex が助けてくれる.
[DEX] Sky’s the limit? No, 65K methods is — Medium
5. AsyncTask のベストな代替は RxJava でこれのほうがかなりよい.
Party tricks with RxJava, RxAndroid & Retrolambda — The Startup — Medium
6. Retrofit がベストなネットワークライブラリである.
Retrofit
7. Retrolambda でコードを短縮しよう.
Retrolambda on Android — Android & Tech — Medium
8. RxJava と Retrofit と Retrolambda を一緒につかうと最強.
Party tricks with RxJava, RxAndroid & Retrolambda — The Startup — Medium
9. EventBus は素晴らしいが, コードが乱雑になるので多用するのは控えている.
greenrobot/EventBus: Android optimized event bus that simplifies communication between Activities, Fragments, Threads, Services, etc. Less code, better quality.
10. レイヤーでなく機能によって構成する.
ソースディレクトリの構成時にもっておくべき「会社別」のイメージ
11. アプリケーションスレッドのすべてをOFFにしろ.
12. レイアウトとそのヒエラルヒーを最適化するために lint するべし. 削除できる不要なレイアウトを特定できる.
layoutopt | Android Developers
13. Gradle を使っているなら, いろんな方法でスピードアップしよう.
Android お手軽なビルド時間の短縮メモ
14. ビルド時には プロファイルレポートを使え, それぞれのビルドにかかった時間が分かる.
オプションに「–profile」をつけて Run時間が1分から2秒になった話
15. 有名なアーキテクチャーを使え.
Architecting Android…The evolution – Fernando Cejas
16. テストは時間がかかるが, 一度コツを掴むとテストしないときより高速で堅牢となる.
Is Unit Testing worth the effort? - Stack Overflow
17. Dependency Injection を使え. よりモジュール化されテストしやすくなる.
Tasting Dagger 2 on Android – Fernando Cejas
18. Fragmented の podcast を聞け. きっとあなたにとって素晴らしいものとなる.
Fragmented – An Android Developer Podcast
19. 個人的メールアドレスは Android Market の公開アカウントに使うな.
Google Play - Only one strike is needed to ruin you : Android
20. 常に適切な入力タイプを使え.
Specifying the Input Method Type | Android Developers
21. (Google) Analytics を使って利用パターンを見つけバグを隔離すべし.
22. 新しいライブラリの人気のあるやつを使え. (dryrun を使って出力をより速く)
【AndroidStudio 不要】サンプルアプリは「dryrun」で試してすぐ捨てよう
cesarferreira/dryrun: Try the demo project of any Android Library
23. Service はできるだけ素早く処理して終了しろ.
24. ユーザ名やメールアドレスのサジェストにアカウントマネージャーを使え.
AccountManager | Android Developers
25. ビルドやベータ版の配布や apk の作成にはCIを使え.
26. 自分の CIサーバは使うな. サーバーのメンテに時間を使う. ディスク容量・セキュリテイの問題・SSL攻撃防御のサーバの更新なども. Circle CI や travis, shippabele を使え. これらは 安価で手間も少ない.
27. PlayStore へのデプロイは自動化しよう.
Triple-T/gradle-play-publisher: Gradle Plugin to upload your APK and metadata to the Google Play Store
28. ライブラリが巨大でその一部しか使ってない場合は, より小さくなる方法を探せ(例えば プロガードを利用する)
Shrink Your Code and Resources | Android Developers
29. 実際に必要以上なモジュールを使うな. もしそのモジュールを頻繁に更新していないのなら, コードからそれらをコンパイルする時間や, 以前のそれぞれのモジュールのビルドが最新版であるかチェックも必要となることについて考えることが重要です. バイナリ .jar/.aar の簡単な読込みにすると4倍くらい向上できます.
30. PNGを捨ててSVG化することを考え始めよう.
Vector Asset Studio | Android Developers
31. ライブラリの抽象化クラスを作れ. ライブラリを変更するときに一箇所の変更で簡単に行うことができる.
JakeWharton/timber: A logger with a small, extensible API which provides utility on top of Android's normal Log class.
32. Connectivity とその種類を監視しろ. (WiFi のときにより多くのデータを更新しているか?)
33. 電源とバッテリーを監視しろ. (充電中に更新データを多くしているか, バッテリーが少ないときには更新を停止しているか?)
34. UIとはジョークのようなものだ. 説明が必要であればそれは良くない.
35. テストのパフォーマンスは偉大です. テストで何も壊れないか確認し、その後ゆっくりと正しい実装を記述する → 最適化
Dan LewさんはTwitterを使っています: "Tests are great for performance: Write slow (but correct) implementation then verify optimizations don't break anything with tests."
しかし, Medium ていい記事ばかりあるけどなぜなのかな.
