無料で配布されてます.


とりあえず, ebub や PDF すべての形式をダウンロード.


80ページくらいあるし, わーい.
無料で配布されてます.


とりあえず, ebub や PDF すべての形式をダウンロード.


80ページくらいあるし, わーい.
「アプリを作ったけど なぜか表示が遅い」
そのようなレンダリング時間の改善するための方法のひとつとして GPUオーバードローツールを利用しましょう.
アプリがシステムに他の何かの上に描画することを「オーバードロー」といいます.「GPUオーバードロー」ツールを使うとそのピクセルが何回再描画されたか画面上に色をかぶせて表示させることができます.
以下ので順で有効化します.
1.「設定」
2.「開発者向けオプション」
3.「GPUオーバードローをデバッグ」
4.「オーバードロー領域の表示」

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

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

画面上のピクセルに対してオーバードローを行った回数を表しています.
オリジナル色
– オーバードローなし
– そのピクセルは一度だけ塗りつぶされた
青
- 1回 オーバードロー
- そのピクセルは2回塗りつぶされた
緑
...
ピンク
...
赤
...

たとえば, 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
Tracer for OpenGL ES | Android Developers
まずは, 最大で2回のオーバードロー(緑)を目指してみましょう.

Optimizing Layouts in Android - Reducing Overdraw - Riggaroo
参考にしたいサンプルアプリをGiHubで見つけて試してみる場合は以下のような手順
1. サンプルアプリのリポジトリを探す.
2. zip をダウンロードする.
3. それを展開する.
4. AndroidStudio などIDEを開く.
5. インポートする.
6. Gradle が sync する.
7. プロジェクトを run.
8. 実行するデバイスを選択する.
9. 実際に動かしてみる.
10. zipファイルとプロジェクトフォルダを捨てる.
となりますが,「dryrun」をインストールすると
$ gem install dryrun
...
$ dryrun -h
Usage: dryrun GITHUB_URL [OPTIONS]
Options
-m, --module MODULE_NAME Custom module to run
-p, --path PATH Custom path to android project
-h, --help Displays help
-v, --version Displays version
dryrun: Try the demo project of any Android Library
リポジトリのURLのみでターミナルからの一行で起動までが可能になります. AndroidStudioなどIDEは起動しなくてよいです.
プロジェクトディレクトリは残りません.
$ dryrun https://github.com/cesarferreira/android-helloworld


アプリ起動後, 動かしてみて, いらなくなったらターミナル出力の最終行に表示されているadbコマンドでアンインストール.
... > If you want to remove the app you just installed, execute: adb uninstall github.cesarferreira.helloworld
あなたのマシンには試したテストアプリの不要なプロジェクトディレクトリがたくさんありませんか?

2016年5月29日からテスト形式が変わるのはすでにアナウンスされています.
TOEIC|インフォメーション|2015年度|TOEICテスト 出題形式一部変更について
リスニングセクションの変更点
写真描写問題(Part 1)と応答問題(Part 2)の設問数が減ります。
会話問題(Part 3)の設問数が増えます。
会話問題の中に、発言が短くやり取りの多いものが加わります。
3名で会話する設問があります。
Elisions(省略形: going toが gonnaなど)、 Fragments(文の一部分: Yes, in a minute; Down the hall; Could you?など)を含む会話が流れます。
会話やトークの中で聞いたことと、問題用紙に印刷された図などで見た情報を関連づけて解答する設問が加わります。
会話やトークの中で話し手が暗示している意図を問う設問が加わります。
リーディングセクションの変更点
短文穴埋め問題(Part 5)の設問数が減ります。
長文穴埋め問題(Part 6)の一つの文章に含まれる設問が 3問から4問に増えます。
文書の全体的な構成を理解しているか問う設問が加わります。具体的には、
長文穴埋め問題で、文書内の空欄に最も適切な一文を選ぶ問題
Part 7(1つの文書)で、文書内に新たな一文を挿入するのに最も適切な箇所を選ぶ問題
テキストメッセージやインスタントメッセージ(チャット)、オンラインチャット形式で複数名がやり取りを行う設問が加わります。
Part 7(1つの文書、複数の文書)の設問数が増えます。
Part 7(複数の文書)で 3つの関連する文書を読んで理解する設問が加わります。
文書中で書き手が暗示している意図を問う設問が加わります。
TOEIC|プレスリリース|2015年度|「TOEICテスト公式問題集 新形式問題対応編」
必須の参考書となるでしょうね.
ひとつの部分を変更しようとして, 必死に複数のファイルをいったりきたりしながら更新してみると, 意図しないところが壊れている.
想像してみてください.
マネージャー会社, プログラマー会社, 人事会社, マーケティング会社がある.
プログラマー会社には, マネージャーやマーケティングや人事の人はいなくて, プログラマーしかいない.
いきなり src 直下に「activities」「fragments」「views」ディレクトリを作成してしまうことに似ていません?
「何をするか」ではなく「何であるか」でまとめられたものは, 探そうとすると何度も大きく移動しなければならない.
「会社の業種別」「会社別」のような「何をするか」を優先させたイメージでディレクトリを構成していくと以下のようになります.

良い点
- 高モジュール化.
- 見つけるのが分かりやすい.
- 高レベルな抽象化.
- 機能とレイヤー両方で分けられている
- 構成のメンテがやりやすい.
- 凝縮されている.
- スケール変更しやすい
- 関係ないクラスやファイルを変更するアクシデントが少なくなる.
- 機能の追加や削除がしやすい.
- 再利用しやすい.
Package by features, not layers — The linkedcare Engineering team — Medium
【2015-10-14 公開!!】Google I/O 2015 のソースコードに見るディレクトリ構成
ひとつの考え方として根底にあったほうがよいと思いました.
これに合わせてリソースディレクトリも小分けにできるという話は以下から.
res ディレクトリは小分けにしたほうがいいのではないか