fkm blog

software開発に関することを書いていきます

Google I/O 2019: What's New in Android Development Tools

youtu.be

Android Studio 3.2

去年のI/Oでは、Android Studio 3.2が発表された。App bundleやナビゲーションエディタなど。

Android Studio 3.3

今年(2019年)1月にAndroid Studio 3.3がリリースされた。プロジェクト作成ウィザードの刷新や、単一variantのsyncなど。

Android Studio 3.4

今年(2019年)4月にAndroid Studio 3.4がリリースされた。リソースマネージャーの登場や、R8(Proguardの新しい版)がデフォルトになるなど。

Android Studio 3.5

Project Marble。IDEの体験を向上させよう。そのために大量のIssueを - System health - Feature Polish - Bug Backlog に分類したよ。

System health

Android Studio起動時に「統計情報をGoogleに送っていい?」と聞かれるが、その情報が使われてるのがここらしい。

有効にしていて、Android Studioがクラッシュすると、クラッシュレポートがGoogleに送信される。

UIのフリーズは注意しておきたい分野。UIスレッドが数秒とまった場合、すべてのスレッドダンプをとってGoogleに送信している。ダッシュボードによると、平均14秒止まり、発生回数が5万件というのがあったりする。

この統計をもとにバグを直したところ、例としてデータバインディングを使っているXMLの編集がとてもはやくなった。

もちろんスポットで直してるだけではない。ちゃんとリグレッションテストもやってる。例えばUIスレッドがネットワークリクエスト投げていたりしたらテストがFailするようにしてる(Javadoc出したりするときに発生しそう)。

次はメモリに関して。IDEがOOMに遭遇したとき、ヒープの統計とかを収集してGoogleに送信している。このような統計から見えてきたことは、多くのユーザーはAndroid Studioをヒープ1.2GBで動かしていたという事実。

なぜ1.2GBをデフォルトにしたか?デフォルトを大きくすると、ローエンドのマシンで起動すらできなくなってしまうから。だからといって小さくしすぎると、通常のプロジェクトを開くときに開けなくなってしまう。

もしマシンのメモリがたっぷりあるのなら、Android Studioが使用するヒープサイズは大きくしよう。

Android Studio 3.5では、「もうちょいAndroid Studioが使用するヒープサイズ大きくする?」のダイアログが出るように。その場で設定を変更して再起動もできる。

Android Studioメモリリークを調べるには、ヒープダンプを取るのが手っ取り早い。でもでかいし、個人情報が含まれるからそれは無理。そのため、OOMが近くと一旦ヒープダンプをとってローカルに保存し、次回起動時にメモリリークを解析してその結果だけを送信するようにしてある。送信後、保存したダンプファイルは消している。送信前にはどんな情報を送るか、プレーンテキストになっているものが確認できる。

このメモリリークの情報から、有名なサードパーティプラグインメモリリークを突き止めた(すげー)。プラグイン開発者にバグレポートしたところ、「数年前からなんかリークしてたっぽいんだけど、わかんなかったんだよねー」とともに、24時間以内に直してくれた。

だいぶ改善されたとはいえ、メモリリークのあるプロダクトを出荷しているという事実にかわりはない。なので特殊なテストランナーを用意し、テストでメモリリークを発見できるようにした。

次にスピードに関して。1つの手は余計なプラグインをいれないこと。でもパフォーマンスのためにプラグイン使うのやめるのはおすすめしない。

高速化のために、アノテーションプロセッシングのインクリメンタル化をしたよ(別セッションにて)

Android Studioのマジョリティは(Macではなく)Windows。ファイルのセパレータが違うといった、Windows特有の問題もあるけど、パフォーマンスに影響があったのがウィルスチェッカー。SDKやプロジェクトのフォルダを除外すると、速度が4倍になった。そのため、SDKやプロジェクトフォルダがウィルスチェッカーに除外されていない場合、ダイアログを出すようにしたよ。盲目的に除外するのではなく、セキュリティとのトレードオフを考えてね。

エミュレーターもまたCPUをよく使う分野。Google Play入りのものだと、アップデートの確認やアプリの最適化などが走って結構CPU使っている。これをなんとかするために、エミュレーターのデフォルトを「バッテリー使用中」に変更したよ。

もう1つの改善は、マイクでずっと待ち受けするのをやめたよ(ホームとかで「お〜け〜ぐ〜ぐる」と呼ぶと下からにょきっとでてくるあの機能)。マイクが必要な場合はその都度ONにして使ってね。

Feature polish

Instant runの代わりにApply changesを作ったよ。機能的にはInstant runとほぼ同じだけど、Android O以降に限定して変なhack使うのをやめてるよ。Instant runの時はホットスワッピングのためのコードを差し込んでたりしたので、逆にクリーンビルドが遅くなってた。Apply changesはOS側のホットスワップの機能を使ってるので、より安定してるよ。

次はGradle。今までGradleはjarとか、ライブラリで使ってるのをどんどんホームディレクトリにキャッシュとして放り込んでたけど、それを自動で削除してくれる機能が入ったよ。でもAndroid Studio的にはキャッシュから読んだほうが早いので、この機能には困った。けどなんとか直した(It's been fixed)。

飛行機の中とか、ネットワークの使用がめっちゃ制限されている環境で開発する人のために、maven.google.com のリポジトリをダウンロードしてオフラインでも使えるようにしたよ。zipを展開して、READMEに書かれているように設定してみてね。

Android Studioをアップデートして、プロジェクトを開いた時に「いろいろアップデートしてね」のメッセージがこれまでは出ていたが、今後は出なくなる。

データバインディングを使ってる人は、いろいろ改善したのでAndroid Studio 3.5を使ってみてね。

Bug backlog

数週間が400以上のバグを直したよ

Gradle plugin

今までは、Android StudioのバージョンをあげるとGradleプラグインのバージョンもあわせてあげる必要があった。今後はその必要はなくなる(あげたほうがいいが)。そのため、プラグインさえあわせていればAndroid Studioのstable版を使おうが、betaを使おうが、かまわない。

デモは動画みてね。他のセッションで紹介されたものがほとんど。

Chrome OS

Chrome 75以上でx86Chrome OSで、Android Studio 3.5が正式サポート。