まずは「Google Codelabs」から試してみよう?

バージョンやライブラリの依存など環境の違いでわかりづらくなってきているのが StackOverflow.

ある意味公式のGoogleのサイトから眺め始めるのが筋か.

ある程度まとまってきています.

Google Codelabs

Google_Codelabs

Android なら「BY TECHNOLOGY」から「Android」を選択.

Google_Codelabs 2

Google_Codelabs 3

たとえば, テスト関連ならこのへんか.

- Automated Performance Testing Codelab
- Unit and UI Testing in Android Studio
- Android Testing Codelab

Android_Testing_Codelab

Automated_Performance_Testing_Codelab

Unit_and_UI_Testing_in_Android_Studio 2

イベントやカンファレンスなどのサンプルコードをベースに各リファレンス参照しながらお試しできる構成になっておりますね.


見えないところは塗りつぶすな - 不要なオーバードロー削除で高速化

「アプリを作ったけど なぜか表示が遅い」

そのようなレンダリング時間の改善するための方法のひとつとして GPUオーバードローツールを利用しましょう.

「オーバードロー」とは?

アプリがシステムに他の何かの上に描画することを「オーバードロー」といいます.「GPUオーバードロー」ツールを使うとそのピクセルが何回再描画されたか画面上に色をかぶせて表示させることができます.

GPUオーバードローツールを有効化する

以下ので順で有効化します.

1.「設定」
2.「開発者向けオプション」
3.「GPUオーバードローをデバッグ」
4.「オーバードロー領域の表示」

20160221-134639

画面の色が変化したと思います.

20160221-134651

あなたのアプリを開いてレイアウトの改善を行ってみましょう.

Screenshot_2016-02-01-11-08-40

変化した色の違いは何を表しているのか?

画面上のピクセルに対してオーバードローを行った回数を表しています.

オリジナル色
– オーバードローなし
– そのピクセルは一度だけ塗りつぶされた

- 1回 オーバードロー
- そのピクセルは2回塗りつぶされた

...
ピンク
...

...

Debug_GPU_Overdraw_Walkthrough___Android_Developers

どのようにオーバードローを改善するか?

たとえば, RelativeLayout のbackground color を削除して テーマのみにbackground color を描画させる.

<RelativeLayout
            android:layout_width="match_parent"
            android:layout_height="match_parent"
            android:background="#FFFFFF">

<RelativeLayout
     android:layout_width="match_parent"
     android:layout_height="match_parent">

これにより, オリジナル色と青色のオーバードローが少しに改善させることができました. いくつかのオーバードローは避けることができません.

オーバードローがすべて背景色に関連しているわけではありません. 非常に複雑なレイアウト階層構造の多すぎるビューの中にたくさん存在すると思われます。

オーバードローが発生している理由は, Hierarchy Viewer や GL Tracer などのツールで確認することができます.

Hierarchy_Viewer_Walkthrough___Android_Developers

Hierarchy Viewer Walkthrough | Android Developers

Tracer for OpenGL ES | Android Developers

まずは, 最大で2回のオーバードロー(緑)を目指してみましょう.

Debug_GPU_Overdraw_Walkthrough___Android_Developers 2

Optimizing Layouts in Android - Reducing Overdraw - Riggaroo

Debug GPU Overdraw Walkthrough | Android Developers


ソースディレクトリの構成時にもっておくべき「会社別」のイメージ

ひとつの部分を変更しようとして, 必死に複数のファイルをいったりきたりしながら更新してみると, 意図しないところが壊れている.

想像してみてください.

マネージャー会社, プログラマー会社, 人事会社, マーケティング会社がある.

プログラマー会社には, マネージャーやマーケティングや人事の人はいなくて, プログラマーしかいない.

いきなり src 直下に「activities」「fragments」「views」ディレクトリを作成してしまうことに似ていません?

「何をするか」ではなく「何であるか」でまとめられたものは, 探そうとすると何度も大きく移動しなければならない.

「会社の業種別」「会社別」のような「何をするか」を優先させたイメージでディレクトリを構成していくと以下のようになります.

1-A-m20R0Qve-eB4ishqZc_Q

良い点

- 高モジュール化.
- 見つけるのが分かりやすい.
- 高レベルな抽象化.
- 機能とレイヤー両方で分けられている
- 構成のメンテがやりやすい.
- 凝縮されている.
- スケール変更しやすい
- 関係ないクラスやファイルを変更するアクシデントが少なくなる.
- 機能の追加や削除がしやすい.
- 再利用しやすい.

Package by features, not layers — The linkedcare Engineering team — Medium

【2015-10-14 公開!!】Google I/O 2015 のソースコードに見るディレクトリ構成

ひとつの考え方として根底にあったほうがよいと思いました.

これに合わせてリソースディレクトリも小分けにできるという話は以下から.
res ディレクトリは小分けにしたほうがいいのではないか