この素晴らしいAndroid StudioにTipsを

第11章では、第9章内で解説したプロジェクト改善活動の成果である、Android Studioをより便利に使うためのTipsとLintの運用方法について紹介します。

全章を一括して購入されたい方はこちらの記事をご購入ください。https://note.mu/nikkei_staff/n/n44623c9b9ab4

⽇経電⼦版のアプリチームでAndroidアプリを開発しているおがぱん/@ogapantsです。

本章では、第9章内で解説した「Android Studio 最強の使い⽅選⼿権」と「Lint 警告撲滅会」で取り上げられたTips を紹介します。

操作を覚えたり事前準備する⼿間がありますが、慣れてしまえば確実により早く効率的なコーディングができます。今回は⽐較的利⽤シーンが多く利便性の⾼いものを取り上げるので、もし知らないものがあったら是⾮触れてみてください。

対象読者はAndroid Studio をある程度使いこなしている⽅です。初学者の⽅は公式のユーザーガイド*1を⾒つつ、そういうのもあるのかという気持ちで⾒てください。

なお、本章に記載されたコマンドは全てMac 向けですので、他の動作環境の場合は適宜脳内変換してください。また、Android Studio3.2 RC03 にて動作確認を⾏っています。

11.1 キーボードショートカット

まずはAndroid Studio のキーボードショートカットについて紹介します。公式ページ*2に載っているものも⼀部含まれます。

11.1.1 標準のキーボードショートカット

Android Studio に標準で⼊っており、すぐに使える中でもややマイナーなものを紹介します。

command+E
最近開いたファイル⼀覧を表⽰します。

command+shift+F
全ファイルの⽂字列検索ができます。

command+shift+R
全ファイルの⽂字列置換ができます。

command+shift+O
全ての拡張⼦のファイルが検索できます。

command+option+B
インターフェースのメソッドを呼ぶ箇所で⾏うと、実装部分にジャンプします。

command+shift+B
変数にカーソルを当てた状態で⾏うと、変数のクラスにジャンプします。

command+1
Project ツリーウィンドウの開閉を切り替えます。他の数字もウィンドウの開閉が割り当てられており、たとえばcommand+6はLogcat のウィンドウが開閉します。

11.1.2 拡張のキーボードショートカット

キーボードショートカットはPreference -> Keymapから独⾃で拡張して設定することもできます。設定⽅法は先述の公式ページを参考にしてください。

ここでは社内勉強会で上がった拡張キーボードショートカットの例をいくつか紹介します。設定⽤のコマンドは実際に弊社内で使われているものですが、ご⾃⾝の環境にあわせた最強のキー割り当てを⾏ってください。設定ファイルを使ってチームで共有するのもいいのですが、キーボードの配列による差異があるので注意が必要です。

command+_ ...Search with Google
ドラッグした範囲をすぐブラウザでGoogle 検索できます。

command+I ...Select in Project View
エディタ内でフォーカスしている状態で⾏うと、Project ツリー内のファイルにフォーカスが移ります。Autoscroll to Sourceの設定をするよりも便利です。

option+[ ...Split Vertically
開いているファイルをSplit で表⽰できます。タブを右クリックして⾏う⽅法よりも視線の動きが少なくなって眼精疲労の緩和に貢献します。

control+shift+O ...Open Recent
Android Studio で過去に開いたプロジェクト⼀覧を表⽰します。

command+S ...Reformat Code
エディタ上でcommand+shift+option+Lを押した際のチェックボックスから、Reformat の他にimport 整理、Rearrange を同時に⾏うよう設定しています。Java、xml ファイル上でそれぞれ実施しましょう。kt ファイル上ではなぜかRearrange がありません。Rearrange するかどうかはプロジェクトに依存するのでチームでよく話し合って⾏いましょう。とても簡単に設定できるので、詳しい設定⽅法はこちら*3をご覧ください。

11.1.3 やっていこうキーボードショートカット

他にも標準のKeymap はまだまだあるので、設定画⾯からひととおり⾒てみてください。また、普段からよくやるような操作も、実は標準でキーの割当てがされていないだけでIDE の操作としては⽤意されているケースもあります。先述したのは全てそのパターンです。

「いいと思ったらすぐ試す」「何度もやる」というのが記憶に定着させるコツです。何度も試して脊髄に記憶させ、やっていきましょう。

11.2 Live Templates

Live Templates*4*5とはエディタ上で任意の⼊⼒をすると使える⾼度なスニペット機能です。ただの定型⽂だけでなく、特定の値を挿⼊した動的な定型⽂を出⼒させる設定もできます。Statement 内やComment 内など、書いて意味のある場所でないと発⽕しないという特徴もあります。

11.2.1 標準のLive Templates

Android Studio に標準で⼊っているLive Templates をいくつか紹介します。KotlinよりJava で使えるもののほうが充実しているので、ここではそちらを挙げます。

gone
よく書くView の表⽰切り替えのボイラープレートを素早く⼊⼒できます。同様にinvisibleやvisibleもあります。$VIEW$にカーソルが当たるのが地味に便利です。

key
String のkey ⽂字列を定義するときの定型⽂が⼀瞬で⼊⼒できます。$value$で⼊⼒した⽂字がそのまま⽂字列になるのも嬉しいです。

ViewConstructors
カスタムView のよくあるコンストラクタ群が⽣成できます。コンストラクタ名も⾃動で⼊⼒されるのでとても捗ります。Kotlin では@JvmOverloadsを使うほうがいいでしょう。

sbc
たまに使いたくなる⼤きめのブロックコメントは、いろいろな書き⽅がありますが標準で登録されているものを使うといいでしょう。しかしそもそもこういったコメントが必要なコードは⾏数が多く構造化できてない可能性もあるので気をつけましょう。

log まわり
メソッド名などを⼀緒にLogcat に出⼒できます。種類豊富でとても便利なので詳細は後述します。

11.2.2 拡張のLive Templates

Live Templates はキーボードショートカットと同様に、独⾃で拡張して設定することができます。登録⽅法は後述します。

今回の紹介例はKotlin とxml ですが、Java でも同様の設定が可能です。出⼒のフックとなる⽂字列であるAbbreviation（略語）も任意に設定できます。

postDelayed
デバッグ時に活躍する、遅延実⾏させるための定番スニペットです。$CURSOR$の位置にカーソルが当たるのがポイントです。Handler クラスはjava.util.logging.Handlerと競合するので、フルパスで書きましょう。他のクラスも同様です。

kkey
先述したとおりJava はkeyと打つと⽂字列定数のスニペットが出てきてくれますが、Kotlin では標準にありません。同様のものが欲しい場合は次のように設定しましょう。

今回の例のようにJava で登録されているLive Templates を移植するときは、Kotlinの⾔語機能で補えないか検討しましょう。

ripple
これはView のタッチフィードバックをripple で表現するための定番な記述です。xml上で発⽕するよう設定しましょう。こういった⾼頻度で使う割にノールックで打ちづらい⽂字列も登録しちゃいましょう。

logg
⼊⼒時の位置のクラス名とメソッド名と⾏数を⼀緒に出⼒します。デバッグにとても便利です。また、***で検索/フィルターすれば独⾃のログのみ抽出できます。log 周りだと標準のLive Templates も充実していますが、登録の仕⽅も併せて後述します。

11.2.3 拡張Live Templates の登録⽅法

ここでは独⾃拡張のLive Templates の登録⽅法を解説します。公式ページ*6を参考に、実際に先述したloggを登録してみましょう。

1. Preference -> Editor -> Live Templates の右側にある+ をクリック。
2. 2.Template Group...で、これから独⾃のLive Templates を⼊れていくグループ名を任意で⼊⼒(MyTemplatesなど) してOK をクリック。
3. もう⼀度+を押して1.Live Templatesをクリック。
4. エディタの下部の「No applicable context yet.Define」をクリックし、そのLive Templates を発⽕させるファイル形式の選択ダイアログを表⽰します。
5. Kotlinの⼦のチェックボックスを開き、Statementをチェックします。今回のケースはStatement 内でだけできれば問題ないでしょう。
6. Abbreviation にloggと⼊⼒します。
7. Description は呼び出し時に表⽰される説明⽂です。なんでもいいですが出⼒例などを書いておきましょう。
8. Template Textに実際に出⼒させる⽂字列「android.util.Log.w("$CLASS_NAME$", "$METHOD_NAME$:$LINE$ *** ")」を記載します。
9. 静的な定型⽂を出⼒させたいだけであればこれで終わりです。今回の例のようにクラス名などを動的に出⼒したい場合はEdit variablesをクリックします。
10. ポップアップが出てくるので次の図11.1 のようにExpression を適宜選択してメソッド名やクラス名を引いてくるように設定します。どれが何を指すかは雰囲気で察しつつ分からなければ公式*7を参考にしてください。
11. OK を押して設定画⾯を閉じ、試してみてください。

今回の例で、Define にJava を追加チェックしてもExpression の違いから正しく動きません。Java ファイルでも同じ出⼒をしたい場合は、loggを複製（Duplicate）してJava専⽤のものを追加しましょう。設定画⾯でloggを選択した状態で、+ の下にあるノートのアイコン（Duplicate）をクリックすることで複製できます。Kotlin で使うものと同じAbbreviation 名は付けられませんが、グループを別にすれば可能です。

これはLog 全般の話ですが、Log は消し忘れてリリースビルドに含まれないようにきちんと削除しましょう。Log クラスで登録しておくと適当にclone してきたプロジェクトでもすぐに使えて便利ですが、Timber*8を導⼊しているプロジェクトならTimber ⽤のLive Templates を⽤意してもいいでしょう。

なお、Android Studio 標準のLive Templates でも、logdで同様のLog が展開されるようになっています。しかし、今回独⾃拡張の形で追加したのには理由があります。標準のものはLog クラスの第⼀引数であるString 変数TAGの⼊⼒が必要であり、これを使⽤するクラス内で必ず毎回定義しなければコンパイルエラーになるからです。今回は別物として新規作成しましたが、既存のLive Templates を上書きする形で登録しても構いません。

11.2.4 Log のLive Templates について

標準で⽤意されているLog まわりのLive Templates は便利なものも多く、学びのある記法もあるので⼀部紹介します。すべてJava で、Kotlin には⽤意されていません。

logt
先述したTAG を定義するのが⾯倒という問題ですが、実は簡単に定義できます。⽂字列にはクラス名が⾃動で⼊ります。

logd
LogLevel.DEBUGの標準ログです。メソッド名が⾃動で⼊り、$content$のところにカーソルが当たります。

loge
LogLevel.ERRORのログです。第三引数が未定義状態です。注意点として、仮にcatchブロック内で追加しても⾃動で⼊⼒されることはありません。

logr
次のLog.d(...の部分が出⼒例です。return ⽤に定義した値を⾃動で抽出して貼ってくれます。とてもよい機能ですが使うチャンスは少ないです。

logm
次のLog.d(...の部分が出⼒例です。メソッドの仮引数を⽂字列付きで出⼒してくれてとても便利です。

引数を抽出する仕組みですが、Edit variablesにて次のようなgroovyScript がワンライナーで動いています。応⽤していろんなことができそうです。

11.2.5 やっていこうLive Templates

キーボードショートカットと同様に、標準だけでもまだまだ紹介しきれないLiveTemplates があります。list で発⽕する.forやNullable なオブジェクトで発⽕する.nonnullなど…設定画⾯から是⾮、新しい発⾒をしてください。欲しいものがなければ作りましょう。普段⻑々と打ち込んでいるボイラープレートがあるなら、それはきっとLiveTemplates がなんとかしてくれるはずです。やっていきましょう。

11.3 Typo Lint を辞書運⽤で制御する

数あるLint 警告の種類のひとつにTypo（miss spell）の警告があります*9*10。誰でも迷わず直せるものと思いがちですが、実は社内⽤語だったり、何かの固有名詞だったり、マイナーな英単語でTypo 扱いになっていたりする場合があります。これらを間違いではないからといって放置すると本当のTypo が埋もれてしまうので、適切に辞書登録をしてチームで共有し、Typo 警告に敏感になれる環境を作りましょう。

ここでは弊社で⾏っている辞書運⽤⽅法について解説します。辞書運⽤は私が⼊社してから提案・導⼊を進めてきましたが、さまざまなメリットがありとても有益です。主なメリットを次に列挙します。

• 真のTypo が明確になる
• メンバーそれぞれが同じ単語を辞書登録する⼿間を回避できる
• ⽤語として定義することで表記のゆらぎを減らせる
• 新しく⼊ったメンバーに⽤語を知ってもらえる

たとえば弊社ではMynewsという機能があり、⽤語として辞書登録しています。これまでmyNewsやmynewsと表記ゆれが多かったのですが、辞書運⽤によってTypo 判定がなくなり命名に迷うことが減りました。

11.3.1 辞書登録こと始め

辞書の運⽤⽅法は⼤きく分けて3 種類あります。

1. xml に⼿動追加する運⽤
2. xml に⾃動追加する運⽤
3. dic ファイルでの運⽤

弊社では1 の「xml に⼿動追加する運⽤」を採⽤しています。詳しい理由は後述しますが、それぞれの⽅法について順番に説明していきます。

11.3.2 ⽅法1:xml に⼿動追加する運⽤について

これは⽤語の分類ごとにxml ファイルを作り、⼿で単語を追記していくやり⽅です。はじめて辞書運⽤する際の全体の流れは次のようになります。

1. xml の辞書ファイルを作る
2. 辞書ファイルを分類する
3. 開発を進めながら追記していく

ひとつひとつ⾒ていきましょう。

xml の辞書ファイルを作る

まずは基礎となるxml の辞書ファイルを作っていきましょう。これはチームのうち⼀⼈だけ⾏ってもらえればOK です。

プロジェクトの規模にもよりますが、いきなり全てのTypo をチェックするのが⼤変な場合は、まずは全体を検索して⽬⽴つものを⼤まかに登録しましょう。

1. Analyze -> Run Inspection By Name... -> Typoで、Run ’Typo’のダイアログが開くのでそのままOK を押します。
2. 既存のプロジェクト内の全ファイルを対象にTypo チェックの検査が⾛ります。
3. 検査結果がツリーで表⽰されるので、展開して⼤まかに確認します。ここで真のTypo を⾒つけても我慢して無視してください。
4. 辞書登録したい単語を選択し、画⾯の右側のSave to project-level dictionaryというボタンを押します。application-levelの⽅はプロジェクトをまたがって登録され、xml も⽣成されないので押さないでください。
5. Android Studio ウィンドウの×を押してプロジェクトを閉じ、再度同プロジェクトを開き直します。Android Studio の再起動までは不要ですが、プロジェクトの開き直しをしないと辞書xml が認識されません。
6. この時点でLint 警告が出なくなったことを確認します。
7. .idea/dictionariesのディレクトリ内に⾃分のPC ユーザー名でxml ファイル（ここでは例としてogapan.xml）が⽣成されていることを確認します。これが辞書ファイルです。
8. 辞書ファイルの中⾝がリスト11.1 のような構成になっていて、<w>hoge</w>が追加されていることを確認します。
9. この段階で何個か登録します。この段階で全て登録できればベストですが、数が多い場合は10 個くらい登録できれば⼤丈夫です。
10. ⼤まかに単語の選別とSave するのが終わったらプロジェクトを開き直します。
11. ogapan.xmlにSave した⽤語が全て⼊っていて、Lint 警告が出なくなっていることを確認しましょう。

Typo 扱いになるかどうか確認する際は、コメント内の⽂字列として該当の英単語を書いてみると容易に確認できます。これで辞書運⽤するための基礎となるファイルが作られました。

実際はこのようなフローでなくても、同じ構成のxml ファイルを⾃分で同じ場所に作れば同じことができます。しかしある程度⾃動で任せたほうが記述ミスがなくなって安全なのでこのやり⽅を推奨します。

辞書ファイルを分類する

続いて1 つのファイルに集まった⽤語を分類化して複数のxml に分けましょう。

1. どう分類するかチームで検討します。
2. 分類の数だけ基礎となるxml（ogapan.xml）を同じディレクトリ内にコピーして分類名にリネームします。
3. リネームしたxml の中のdictionary要素の、name=""の部分をファイル名と同じにします。
4. コピーされたファイルの<w>タグ要素を全て削除します。
5. 基礎となるxml から⽤語を切り取って各分類ごとのxml にペーストしていきます。
6. 全て切り取り終えたら基礎ファイルを削除します。
7. git でignore されないように.gitignoreファイルに!.idea/dictionaries と記載します。
8. 各ファイルをgit add&commit&push しましょう。

これでチームで辞書運⽤を⾏う準備が整いました。
参考ですが、弊社内で実際に運⽤している辞書ファイルは次のような分類となっています。

libraries.xml
crashlyticsやrobolectricなど、Typo 扱いになる各種ライブラリの名称を⼊れます

nikkei.xml
midashiやhashiraなど、社内独⾃の⽤語を⼊れます

ex_english.xml
onboardingやswipeableなど、マイナーでTypo 扱いされてしまう英単語を⼊れます

開発を進めながら追記していく

ここまで⼀⼈でやったら、あとはチームメンバーで⽇々の業務を進めながら追記していきましょう。

この⽅法はマニュアル的な登録⽅法ですのでやや⾯倒ですが、バージョン管理しやすく、ファイルで分類できるので視認性が⾼くなるメリットがあります。加えて、最初にある程度登録してしまえば辞書登録の頻度はそこまで⾼くないので、あまりストレスにはならないと思います。

<w>タグで単語を記載していく際に、Android Studio（IntelliJ）の仕様上注意すべき点があるので列挙します。

• 辞書ファイルの読み込みにはAndroid Studio のプロジェクトを開き直す必要があります。
• 単語を追記するときの順番は気にする必要はありません。プロジェクトの開き直しを⾏うと⾃動でアルファベット順にソートされます。
• xml 内にコメントを書いておいても開き直しで消えてしまうので、⽤語の解説はREADME や社内wiki などでカバーしましょう。
• 登録する単語に⼤⽂字やアンダースコアなどが⼊るとそれを区切りに別単語としてみなされるので、必ず全て⼩⽂字にしましょう。
• 3 ⽂字までなら存在しない単語でもTypo 扱いになりません。しかし誰が⾒ても分かるような3 ⽂字でなければリネームを検討するか、辞書に登録しましょう。
• 先述のとおり、ファイルを分ける際はdictionary要素の変更は忘れないようにしましょう。
• ハッシュ値などTypo で当然で辞書登録したくないものは、Suppress アノテーションで検査から除外することを検討しましょう。詳しくは後述します。
• mynewsなどの意味のあるまとまりを単語扱いにしていいかどうかは、チームでよく検討しましょう。

これらを認識した上で辞書登録を進めましょう。

11.3.3 ⽅法2:xml に⾃動追加する運⽤について

先述した辞書運⽤の三択のうちの2 にあたる⽅法「xml に⾃動追加する運⽤」について簡単に解説します。

これは辞書xml ファイルの作成は「⽅法1:xml に⼿動追加する運⽤」と同じですが、登録は⾃動追加する⼿法を⽤います。⾃動追加するには、Typo 警告が出ている単語でoption+enterを押して「Save ’hoge’ to project-level dictionary」を選択するだけです。⼿動に⽐べて登録が楽なメリットがあります。しかし登録されるファイル名はPCのユーザー名なので、チームで開発していて各⾃で辞書登録を⾏うと⼈数分のxml ファイルが⽣成されて混乱を⽣みます。バージョン管理は⼀応できますが、git がある時代にユーザー名のファイルを作り上げるメリットがあまり浮かびません。

この仕様についてIntelliJ のコミュニティでも何度か話題になっているようですが、特に動きはないようです*11*12。

ただのTypo 制御としては使えるので、個⼈開発に向いていそうです。

11.3.4 ⽅法3:dic ファイルでの運⽤について

先述した辞書運⽤の三択のうちの3 にあたる⽅法「dic ファイルでの運⽤」について簡単に解説します。

xml でなく、dic ファイルという改⾏のみで区切られて単語が羅列されたテキストファイルを⽤いて運⽤します。

option+enter -> Save ’hoge’ to project-level dictionaryで辞書登録するとPreference -> Editor -> Spellingの設定画⾯のAccepted Words タブにも追加されます。これがユーザー固有のdic ファイルとして出⼒されますが、ファイルの置き場はAndroid Studio の設定ファイル内になり、git で管理することには向いてません。

また、dic ファイルと.idea/dictionariesのxml は連動していますが、あえてdic の⽅から登録するメリットも浮かびません。dic ファイルをプロジェクトに参加した最初の1 度だけ読み込む運⽤ならまだ使えますが、辞書は⽇々進化するものですし、都度ファイルを受け渡しするのはあまり現実的ではありません。設定画⾯からGUI 上で単語登録できるのは⼀⾒わかりやすいですが、実⽤には不向きでしょう。

⼀⽅でdic ファイルは既存の辞書ファイルとして使われています。これについては後述します。

11.3.5 Typo 警告を無理やり黙らせる

cons val KEY = "dwqgscdx..."といったハッシュ値などはTypo に判定されてしまいます。これは辞書登録すべきではありませんが、どうにかしてLint 警告を抑えたいですね。

辞書登録せず無理やりLint を黙らせる⽅法として、Java なら@SuppressWarnings("SpellCheckingInspection")をつけることでTypo 警告を回避できます。

しかしKotlin の@Suppressではなぜか同様のものがなく、対応することができません。

@Suppressで定義されるキーワードを管理するクラス*13を探しても、それらしいものは⾒当たりませんでした。

これはAndroid Studio あるいはKotlin のバグではないかと、issue になっていました*14*15。気になる⽅は是⾮スターしてください。

Kotlin でTypo 警告を黙らせるには、現状⼿⽴てがなさそうです。

11.3.6 既存のスペルチェックはどうやっているのか

そもそもなぜLint はTypo を判定できるのでしょうか。それはIntelliJ に標準辞書が登録されており、ホワイトリスト⽅式でチェックしているからです。

既存の辞書はenglish.dic*16、jetbrains.dic*17などいくつかあり、それぞれ中⾝はgithub で公開されています。膨⼤な量なのでブラウザで⾒るのはお勧めしません。これらに載っていないものは全てTypo 扱いになります。

余談ですが、english.dicでnikkeiが定義されていてにこやかになりました。

ではxxxhdpi のようなAndroid 特有のワードがなぜTypo 扱いにならないのでしょうか。それはAndroid Studio がIntelliJ の標準辞書とは別にandroid.dic*18という専⽤辞書をAndroidBundledDictionaryProvider.java*19を介して読み込むようになっているからです。

History を⾒ると、なんとなく趣を感じられて⾯⽩いです。

11.3.7 やっていこう辞書運⽤

辞書運⽤は若⼲事前準備が必要ですが、やってみると楽しく進められます。ただ忘れてはならないのが、本来の辞書運⽤の⽬的は真のTypo を正すということです。Typo について敏感になり、全て消し去って治安維持に努めましょう。チーム内での辞書運⽤は、そのための第⼀歩です。

11.4 おわりに

本章では、弊社で活躍しているAndroid Studio のTips を、ごく⼀部ですが紹介しました。ページ数の都合上載せられなかった便利な機能がまだまだあります。

気づけばいつも同じ操作、同じ⼊⼒、同じLint 解決をしているな…と思ったらIDE の出番です。設定画⾯を覗き込んでみると、意外と知られていない便利な機能が出てきます。Android Studio のTips を探して、公開し合って、業務の効率化を図りましょう。

Android Studio は、いつでもあなたのことを待っていますよ。

著者：おがぱん/@ogapants
軽い気持ちでコラムを書いていたら章になりました。最⾼の校正をしてくださったなかてぃるさんとfrom-unknown さんに深く御礼申し上げます。

140年の歴史ある会社が、AIやデータを駆使した開発を現場で実践しています。是非疑問や感想を #nikkei_dev_book をつけてツイートしてください！

全章を一括して購入されたい方はこちらの記事をご購入ください。
https://note.mu/nikkei_staff/n/n44623c9b9ab4

この記事を購入すると、この下に第１１章だけのダウンロードリンクが表示されます。