LoginSignup
75
76

More than 5 years have passed since last update.

@shikato(加藤 真也)inYahoo!デベロッパーネットワーク

DroidKaigi 2016で得た知見のまとめ

Last updated at Posted at 2016-02-21

2日間DroidKaigi 2016に参加し、多くの知見を得ることができたので、忘れない/すぐに実行に移すためのまとめ(メモ)です。
(当日中にまとめたかったのですが、懇親会でそこそこお酒を飲んでしまったため当日は断念し、加えて翌日には予定が入っていたので、今日(2016-02-21)のpostとなってしまいました:droplet:)

発表資料

だいたいの資料を網羅してくれている、ありがたい記事がありました。
DroidKaigi 2016講演資料まとめ #DroidKaigi

※ ここから先の「知見のグループ分け」は、あくまでも今現在の私の状況に基づくものです。

すぐに活かせそうな知見

Research

ちゃんとWatchしたいです（英語の勉強もかねて）
以前、Android ArsenalのTwitterアカウントに、拙作のinfo-dumperをツイートしてもらったことがあるのですが、その際にGitHubスターが20くらい増えたので、Android絡みのライブラリを公開する時には、Android Arsenalに紹介してもらう、というのを一つの目標にするのも良さそうです。

quoted from
OSSの動向を捉えた実装方針

Takt

FPSを表示してくれるOSSライブラリです。
ちょうど今、動画関連の案件に関わっているので導入してみたいと思います。
以前にAdvent Calendarでwasabeefさんの記事を読んだ時にも↑のように思い、記事のストックまでしていたにもかかわらず、未だ導入できていなかったので、これを機にちゃんと導入します:droplet:)

Takt

quoted from
OSSの動向を捉えた実装方針

Android Lint

Nkznさんの資料にある通り、Android LintはAndroidアプリ開発におけるGoogleの正解集、もしくはアンチパターンということで、ちゃんとやります。
(前にCookpadさんの朝Lint活動の記事を読んだ後にも良さそう、と思い、GitHubに「朝Lint的な活動をする」のようなissueを立てただけで満足してしまっていたので、これを機にちゃんとやります:droplet:)

ちなみにNkznさんの発表関連だと、Android Lintが意外と泥臭い方法でチェックしていたり、DroidKaigi 2016 アプリがabortOnError falseになっているのでPR送る、あたりのくだりが面白かったです。
(発表当日にちゃんとPRが送られmergeされていました)

quoted from
Android Lintで正しさを学ぼう
クックパッドにおけるAndroidエンジニアの役割とその変遷

MockWebServer

「A scriptable web server for testing HTTP clients」ということで、良さそうなので導入したいです。

MockWebServer

quoted from
僕がテスト書け書けおじさんになった経緯とその過程でやったこと

gradle.propertiesへの追記

gradle.properties
org.gradle.daemon=true
org.gradle.jvmargs=-Xmx2048m -XX:MaxPermSize=512m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8
org.gradle.parallel=true
org.gradle.configureondemand=true

こちらの記事にもまとまっていますが、これまでgradle.propertiesに追記しようしようと思いつつ、都度忘れ、都度「./gradlew --daemon hoge」みたいにしてたので、これを機に追記します:droplet:

quoted from
怖くないgradleでのビルド環境設定とBazel

ext {...}

ExtraPropertiesExtension

build.gradle
ext {
    supportLibVersion = '23.1.1'
}
dependencies {
    compile "com.android.support:design:${supportLibVersion}"
    compile "com.android.support:cardview-v7:${supportLibVersion}"
}

quoted from
Support Libraryノススメ/Support Library Internal

パッケージ名の省略記法

長くなりがちなパッケージ名を短く、かつ、分かりやすく省略できるので、自分も使っていきたいと思いました。
自分が公開しているAndroidCoverageCheckプラグインでも使えそうなので、とりあえずissueを立てておきました。
（最初、Layoutファイル上でだと↑の記法が使えるのかと思い試してみたら「aused by: android.view.InflateException: Binary XML file line #36: Error inflating class 〜」ということで普通に怒られてしまいました:droplet:）

quoted from
Support Libraryノススメ/Support Library Internal

規模が大きくなれば「たぶん動くと思うからリリースしようぜ」はダメ

私は最近、アプリ自体の開発はあまりしておらず、ライブラリ的な開発ばかりなのですが、そのライブラリは社内の多くのアプリに組み込まれたりするので、改めて肝に銘じておきたい所です。

quoted from
クックパッドにおけるAndroidエンジニアの役割とその変遷

dokumi

以前見かけた時は、まだiOSのみの対応だった気がするけど、Androidにも対応されたようなので、なるはやで試してみたいです。

quoted from
クックパッドにおけるAndroidエンジニアの役割とその変遷

同じ船に乗る

丁度いま、部署横断PJ的なものに関わっているので、スライドにあった以下のポイントは、常に意識しておきたいと思いました。

  • 関係者の日々の継続的な会話で意識がズレない
  • チャットでのイベントの可視化による議論の活性化
  • やりたい事や要望を話せる雰囲気
  • 本当にやるべきかを真剣に議論しあえる雰囲気
  • 部署横断的に改善を続ける雰囲気

quoted from
クックパッドにおけるAndroidエンジニアの役割とその変遷

計測は未給電で

チャージされているときはデバイスの振る舞いが変わるみたいです。

quoted from
パフォーマンスを追求したAndroidアプリを作るには

電池のゆとりはこころのゆとり

計測には、Battery Historian（Google謹製（golang））が便利そうです。

消費電力の5-7割はアイドル時に消費される傾向（らしい）ということで、バッググラウンドでの消費を減らすのことが大事。
5.0からはJobSchedulerを使い、それ未満ではGCM Network Managerで代用できるらしいです。

quoted from
パフォーマンスを追求したAndroidアプリを作るには

時間と利用者の反応の指標

遅延時間 利用者の反応
0 - 100ms Instant
100 - 300ms Feel sluggish
300ms - 1s Machine is working…
1s + Mental context switch
10s + I'll come back later…

quoted from
パフォーマンスを追求したAndroidアプリを作るには

Jankを避ける(減らす)ことが大事

レンダリングが間に合わなければJankが発生する(フレームがスキップされる→アニメーションの省略やジャンプが発生→リストがかたついたように見えたり)

ViewのMeasure → Layout → Drawにかかる時間の計測など

Measure → Layout → Draw の各段階でかかっている時間はHierarchy Viewerで確認できる。
Drawに最も時間がかかる状態が一般的なので、Measureが遅い場合は対策の価値がある。
（原因は大抵レイアウトのネスト）
Drawが遅い場合はOverdrawを疑う。Overdraw→他のViewが描写した領域を別のViewがさらに描写すること。
開発者向けオプションの「GPU オーバードローをデバッグ」で確認できる。
ただ、Kitkat以降では単純なOverdrawは自動的に無視してくれるようになったので、Kitkat以降だと、そんなに気にしなくても良いかも。

GPUのプロファイル

開発者向けオプションの「GPU レンダリングのプロフィール作成」。
16msのボーダーに収まっていればOK。

dumpsys gfxinfo

描写状況を出力してくれる。
Marshmallowから、Jankの情報も出力してくれるようになった。

quoted from
パフォーマンスを追求したAndroidアプリを作るには

LeakCanary

こちらも「導入する」みたいなissueだけ登録して、満足してしまっていました:droplet:
多くの発表者が良いと言っていたと思うので、これを機にちゃんと導入します。

quoted from
OSSの動向を捉えた実装方針
パフォーマンスを追求したAndroidアプリを作るには

「パフォーマンスを追求したAndroidアプリを作るには」資料の「最後に」スライドに書かれていたこと

  • 非機能を頑張ろう
    • 非機能を頑張れるかどうかがデベロッパーとしての価値を大きく左右する（気がする）
  • 複数の視点で見ることが大事
    • 推測はアテにならない。可視化、計測大事
  • 積み重ね大事
    • 部屋の掃除と一緒。毎日少しずつ気をつけていれば綺麗なまま。少しづつでも継続する（継続できることをする）

quoted from
パフォーマンスを追求したAndroidアプリを作るには

Bintrayにupload

自分が公開しているAndroidCoverageCheckプラグインとinfo-dumperで、またもやissueだけ登録して満足する、という状態になっていたので、スライドを参考にして対応します:droplet:

quoted from
ライブコーディング・Androidのライブラリを作ってみよう

リファクタリングと機能追加をわける

やりがちなので、出来る限り細かい粒度でPRします。
quoted from
5 年続く 「はてなブックマーク」 アプリを継続開発する技術

将来的に活かせそうな知見

OSS関連の知見

最近は、ライブラリ開発関連の仕事が多く、あまりOSSを気軽に使えないのですが、アプリを一から作る際には活用したいです。
あと、Stethoはdebugビルドのみの導入で良いので使用しているのですが、wasabeefさんの発表中に「良さそう」みたいなツイートが幾つかあって、実際にかなり便利なので、改めて導入しておいて良かったなと感じました。



StethoはCustom dump plugin機能も便利なので、興味の有る方は使ってみると良いと思います。
(自分もStethoのCustom dump pluginをOSSとして一つ公開しています)

wasabeefさんの発表で紹介されたOSSは以下の記事にまとめられています。
DroidKaigi 2016 で 紹介された Android開発に役立つ ライブラリ 集

quoted from
OSSの動向を捉えた実装方針

Canvasを使って新しいUIコンポーネントを作りたい

今までAndroidのCanvasをちゃんと使った事が無かったのですが、amyu_sanさんの発表/資料が分かりやすすぎて、自分もCanvasを使って何か作りたくなりました。
とりあえずリポジトリだけ作りました（リポジトリ名は後で多分変えます :octocat: ）
ShikatoUIView

quoted from
Master of Canvas

サポートライブラリのバグはb.android.comへ

b.android.com

quoted from
Support Libraryノススメ/Support Library Internal

compileSdkVersionとsupportLibraryのバージョンは揃える

今まで、あまり意識したは事はなかったですが、supportLibraryはcompileSdkVersionのバージョンが揃ってる前提で作られてるみたいです。

quoted from
Support Libraryノススメ/Support Library Internal

AppCompatなんとかのことは忘れていい

quoted from
Support Libraryノススメ/Support Library Internal

Cookpadさんのリリースフロー

クックパッドモバイルアプリの開発体制とリリースフロー

quoted from
クックパッドにおけるAndroidエンジニアの役割とその変遷

AT&T ARO

AT&T製の通信最適化ツール。要rooted。
ARO

quoted from
パフォーマンスを追求したAndroidアプリを作るには

CPU最適化(?) 

dumpsys cpuinfo

quoted from
パフォーマンスを追求したAndroidアプリを作るには

DFaaS（造語?）とSTF

quoted from
Android CI: 2016 edition

テスト用のビルドタイプ

ProGuardかけてのテストは良さそうです。

quoted from
5 年続く 「はてなブックマーク」 アプリを継続開発する技術

JVM上でのユニットテスト

Android Gradle Plugin 1.1からAndroidに依存しないテストをJVM上で実施できるようになったことは知っていたのですが、全部のユニットテストがそれで書けるわけではなさそう、テストやカバレッジのレポートがAndroid Testと分散しそう、そもそもカバレッジがAndorid Test同様簡単に計測できるか分からない、等がいろいろと気になっていたので、これまで全てのテストをAndroid Testとして書いていました。
ですが、何人かの発表者の方々がJVM上でのユニットテストを実施しているようだった、という点と、高速にテストを完了させられるのは、やはり魅力的なので、これからはAndroidに依存しないテストはJVM上でのユニットテストに移行することも考慮していきたいです。

quoted from
僕がテスト書け書けおじさんになった経緯とその過程でやったこと
Android CI: 2016 edition
5 年続く 「はてなブックマーク」 アプリを継続開発する技術

興味が満たされた知見

Isntant Runはまだ早くなる余地がある?

「Instant Runを実現する仕組み」で発表者のAtsushi Enoさん(Xamarinの人?)が、Gradleの上に成り立っているInstant Runは、まだ早くなる余地がある?という夢のある話?をしていました。
コードを修正したら、即座にアプリに反映されるContinuousのデモ(iOS/Xamarin)
The Evolution of Interactive C#

ちなみに他には、Instant RunはDataBindingやKotlinと相性が悪い、次世代ビルドツール候補?のBazelには「インクリメンタル インストール」というInstant Run相当の機能が既にある?、そもそもInstant Runのソースは公開されていないので全部推測で話している(とてもそうとは思えない詳細な発表でした)、などの驚きの話がたくさんありました。

その辺りの詳細は、Atsushi Enoさんご自身が書いた記事に書かれています。

quoted from
Instant Runを実現する仕組み

アニメーションFWの整理

2年くらい前にProperty Animationについての記事を自分で書いていたにもかかわらず、ViewProprtyAnimationのことを知らなかったり（記事中ではObjectAnimatorに触れているのみ）と、自分の中で色々と情報を整理/更新することができました。

quoted from
用途に合わせたアニメーションの実装方法

Bazelは今年の12月にAndroid Studioに統合される?

Bazel Feature Roadmapによると、今年の12月にAndroid Studioに統合する予定らしいです。
ただ、発表者のusaganikkiさんによると、Roadmapの日付がガンガン更新されており順調に遅れている?ようです。
いずれにせよ、Gradleとのすみ分け等、いろいろと気になる所です。

quoted from
怖くないgradleでのビルド環境設定とBazel

基本的にはsupport-v4のFragmentを使うのが正しい

自分も昔、すごい悩みました。

quoted from
Support Libraryノススメ/Support Library Internal

さいごに

まだまだ他にも知見はあったように思いますが、まとめるのに疲れてきたので、ここで終了とします :droplet:
自分が見れなかった発表も後日公開されるようなので、時間を見つけてキャッチアップしたいです。
2日とも参加させていただきましたが、両日共に、とても充実した発表ばかりでした。
発表者やスタッフの方々お疲れ様でした:exclamation:

75
76
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
75
76