月別: 2015年5月

アプリを公開してコメントもらえて嬉しかった話

この記事は最終更新から3ヶ月以上が経過しています。情報が古い可能性があります。

Google Playで公開しているカスタムフォトウォッチで初めてコメントをもらいました。

英語でのコメントだったのですが、「12時間表示のオプションが欲しい」っていう内容でした。

おそらく私は、単にそれだけのコメントでも嬉しかったと思います。自分で作ったものに対して反応がもらえるっていうのは、それだけでうれしいのです。

しかし今回のコメントはさらに嬉しい要素がありました。「12時間表示が必要だからアンインストールしたけど、時刻や日付の色やサイズを変えれるのはとてもいい」と褒めてくれていました。

英語でのコメントでしたけど、褒めてくれてるっぽくてテンションが上りました。

つたない英語力とGoogle Translateの力を借りつつ、コメントくれた人とメッセージのやり取りしました。思えば生まれて初めて海外の人とコミュニケーションした気がします。

12時間表示は実は奥が深い

今回の話は「単に嬉しかった」だけに終わりません。実はいい勉強にもなりました。それは12時間表示についてです。

今回もらったコメントに対して、さっそく12時間表示への対応を行いました。スマホの時刻設定で12時間表示にしている場合、wear側での表示を12時間表示にするようにしたのです。12時になったら0時と表示するようにしたわけです。

しかしコメントをくれた方とのやりとりの中で、「うちの国では0時は深夜の0時(24時)を意味するんだ」ということを言われました。

カスタムフォトウォッチでは日付の表示方法についてはいろいろなパターンを提供するようにしていました。海外では月/日ではなく、日/月と表示する場合もあることは知っていたからです。

しかし時刻の表示についても似たような問題があることを、ここにきて初めて知りました。

アプリの海外対応は、文字面だけを英語にするだけではないのだなと、とてもいい勉強になりました。

とりあえず公開してしまえも必要なのかも

アプリを公開するにあたって、「こんな機能も要るかな」とかいろいろ迷ったりもしました。色の選択肢はもっと増やしたほうがいいのかとか、デザインはこれでいいのかとか。

それでも最終的には「ぐだぐだ考えるの面倒くさくなったからもういいや」でアプリを公開しました。いつまでたっても公開できる気がしないし、何のリアクションももらえない状態で開発するのもモチベーションが保てなかったのです。

全てのユーザが今回の方のように丁寧なレビューをくれるとは限りません。それどころか「何やねんこの糞アプリ」みたいなコメントが寄せられるかもしれません。が、それでも公開しなければ何の反応ももらえません。

作るところまで作ったら、後は利用者の反応を見ながら開発するっていうのもいいのかもしれません。

コメント付きレビューをもらえたのが初めてだったので、なんか無性に嬉しかったっていう話でした。

EventBusを使ってAsyncTaskLoaderでProgressを通知する

この記事は最終更新から3ヶ月以上が経過しています。情報が古い可能性があります。

greenrobot/EventBus – GitHubを使ってみました。

異なるスレッドからのイベントの通知でもうまくハンドリングしてくれるので、AsyncTaskLoaderでProgressを通知するのにも利用できます。

Broadcastを使って実装するのと比較するとコードがシンプルになって良いです。IntentFilterやIntentにデータを埋め込む際に使うキー文字列を定義したりしなくて済みます。

更に独自のオブジェクトをイベントとして渡すこともできるので、Broadcastでは難しいイベントの通知も簡単に出来ます。

準備

/app/build.gradleのdependenciesにcompile 'de.greenrobot:eventbus:2.4.0'と、1行追加するだけで使えます。

イベントの送信

イベントを送信したいところで、EventBus.getDefault().post("イベント発生");とするだけです。

これは単にStringオブジェクトを渡しているだけですが、独自オブジェクトを定義して渡すことも可能です。

イベントの受信

イベントの購読・解除

Activityでイベントを受信するなら、onResume()EventBus.getDefault().register(this);とすることでイベントの購読を行います。

この際、onPause()EventBus.getDefault().unregister(this);で購読解除を忘れないように。

イベントのハンドリング

AsyncTaskLoaderからのイベントを受信してUIを更新するなら、onEventMainThread()をActivityに実装します。

public void onEventMainThread(String event){
    mTextView.setText(event);
}

送信するイベントのオブジェクトごとにこのメソッドを用意してやる必要があります。例えば他にMyEventという独自オブジェクトがある場合、別途public void onEventMainThread(MyEvent event){}を実装してやります。

メソッドをオーバーライドするわけではないので、コード補完は効きません。タイポするとこんな例外が起きてアプリが落ちます。

java.lang.RuntimeException: Unable to start activity ComponentInfo{jp.gcreate.sample.asynctaskloadersample/jp.gcreate.sample.asynctaskloadersample.MainActivity}: de.greenrobot.event.EventBusException: Illegal onEvent method, check for typos: public void jp.gcreate.sample.asynctaskloadersample.MainActivity.onEventBackgroundThrad(jp.gcreate.sample.asynctaskloadersample.MyEvent)

まとめ

AsyncTaskLoaderのProgressの通知で使ってみましたが、とても便利だなと思いました。

内部的にはHandlerを使ってイベントのハンドリングを行っているみたいでした。Handlerの具体的な使用例としていい勉強にもなって、個人的には一石二鳥な感じです。ありがたや〜。

便利な半面、無計画に使うとイベントが乱立してカオスな事になりそうなので、実際に使うときには気を付けないといけないなと思いました。

LocalBroadcastを使ってAsyncTaskLoaderでProgressの通知を実装する

この記事は最終更新から3ヶ月以上が経過しています。情報が古い可能性があります。

AsyncTaskLoaderにはAsyncTaskのpublishProgress()のような途中経過を通知するメソッドが標準では用意されていません。

そこでブロードキャストを利用してこれを実装します。

Context#sendBroadcast()を使ってもいいのですが、これだと自分のアプリ外にもブロードキャストが送信されてしまうので、LocalBroadcastManagerを利用します。

AsyncTaskLoaderでの処理

AsyncTaskLoader側ではloadInBackground()内で、ブロードキャストの送信を行うだけです。

この際、途中経過のデータはIntentに埋め込んで送信する必要があります。

@Override
public String loadInBackground(){
    //非同期処理
    Intent intent = new Intent(MainActivity.ACTION_PROGRESS)
        .putExtra("key", "hoge");
    LocalBroadcastManager.getInstance(getContext()).sendBroadcast(intent);

}

MainActivity.ACTION_PROGRESSはインテントフィルタを表す文字列です。

Activity側の実装

//インテントフィルタの定義
public static final String ACTION_PROGRESS = "jp.gcreate.sample.asynctaskloadersample.ACTION_PROGRESS";
//ブロードキャストレシーバーの作成
private BroadcastReceiver mReceiver = new BroadcastReceiver() {
    @Override
    public void onReceive(Context context, Intent intent) {
        String progress = intent.getStringExtra("key");
        mTextView.setText(progress);
    }
};

@Override
protected void onStart() {
    super.onStart();
    //ブロードキャストレシーバーの登録
    LocalBroadcastManager manager = LocalBroadcastManager.getInstance(this);
    manager.registerReceiver(mReceiver, new IntentFilter(ACTION_PROGRESS));
}

@Override
protected void onStop() {
    super.onStop();
    //ブロードキャストレシーバーの解除
    LocalBroadcastManager.getInstance(this).unregisterReceiver(mReceiver);
}

ブロードキャストレシーバーを作成して、ここでAsyncTaskLoaderから送られてくるProgressを受け取りとUIの更新処理を実装します。

後はonStart()でブロードキャストレシーバーの登録、onStop()で解除を行ってやればOKです。

細かいサンプルはGitHubにおいてます。

Android StudioでJunit4によるテストを走らせる

この記事は最終更新から3ヶ月以上が経過しています。情報が古い可能性があります。

基本的にはここに書いてあるとおりにやればいいだけの話です。

準備

/app/build.gradleのdependenciesにjunitを追加します。

testCompile 'junit:junit:4.12'
testCompile 'org.mockito:mockito-core:1.9.5'

この際に注意が必要なのは、androidTestCompiletestCompileは別物であるということです。

何が別物かというと、テストコードを配置するディレクトリがそれぞれ違います。

その名の通りandroidTestCompileandroidTestディレクトリに配置したテストコードのコンパイル時にだけ使うライブラリです。同じくtestCompiletestディレクトリに配置したテストコードのみに使われるライブラリになります。

なお、androidTestディレクトリは自動的に作成されていますが、testディレクトリは自分で作らなければなりません。(ディレクトリは/app/src/test/java/パッケージ名にしてやればOK)

androidTestとtestの切り替え

Build Variantsウィンドウを開くと、Test Artifactという欄があります。

Build VariantsのTest Artifact

Android Instrumentation Testsを選択していると、androidTestディレクトリ以下にあるテストコードが有効化されます。有効化されるというのが適切なのかは分かりませんが、Android Studioからコンパイル対象のソースコードであると認識されます。

Unit Testsに切り替えると、testディレクトリが有効化されます。試しに切り替えてみると、androidTestディレクトリの色が変わって、テストコードのアイコンに赤いJアイコンが出るようになると思います。

IDE上からテストを実行しようと思うと、このBuild Variantsをいちいち切り替えないといけないのが面倒くさいかもしれません。

しかし、ターミナルからGradleを使って実行する場合は、このTest Artifactsの切り替えはしなくてもいいみたいです。Gradleからテストを実行する場合、./gradlew connectedAndroidTestがAndroid Instrumentation Testsを、./gradlew testがUnit Testsを選択してテストを実行するのと同じになります。この場合のテスト結果は/app/build/reports/testsの中に出力されます。

テストコードはViewやActivityなどのUIに関するテストをandroidTestディレクトリに、純粋なJavaコードのテストはtestディレクトリに置くように工夫すべきでしょう。そうしてやれば、ユニットテストにかかる時間を削減できて幸せになれると思います。

Espressoを使ってUIテストを書いてみた

この記事は最終更新から3ヶ月以上が経過しています。情報が古い可能性があります。

Android Studio 1.2でEspresso2.1を使ったUIテストをやってみました。

テストの実行に実機(エミュレータ)が必要なのが面倒くさいですが、実機無しでテストが実行できるようにする方が面倒くさい(というかやり方がわからない)ので、テストができるだけマシだと考えることにしました。

テストを実行する際に、開発者オプションでアニメーションの無効化をしておかないと、アニメーションのせいで同じテストが失敗することがあるのは注意が必要かもしれません。

しかしながら、Android Support Libraryに入っているおかげでテストを実行するまでのハードルが低いのはうれしいところです。

また、EspressoによるUIテストの書き方も非常にシンプルで分かりやすいと思います。

準備

詳しい手順はここに書いてあるとおりです。Get started – android-test-kit

まずは/app/build.gradleにテストで利用するライブラリを追加します。

dependencies {

    // Testing-only dependencies

    androidTestCompile 'com.android.support.test:runner:0.2'

    androidTestCompile 'com.android.support.test:rules:0.2'

    androidTestCompile 'com.android.support.test.espresso:espresso-core:2.1'

}

/app/build.gradleにtestInstrumentationRunnerを追記します。場所はdefaultConfigの中です。

testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"

更に以下のおまじないも追加します。

packagingOptions {

    exclude 'LICENSE.txt'

}

最終的な/app/build.gradle

適宜読み替えて使ってください。

apply plugin: 'com.android.application'

android {

    compileSdkVersion 22

    buildToolsVersion "22.0.1"


    defaultConfig {

        applicationId "jp.gcreate.product.developersettingsshortcut"

        minSdkVersion 15

        targetSdkVersion 22

        versionCode 1

        versionName "1.0"


        testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"

    }

    buildTypes {

        release {

            minifyEnabled false

            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'

        }

    }

    packagingOptions {

        exclude 'LICENSE.txt'

    }

}



dependencies {

    compile fileTree(dir: 'libs', include: ['*.jar'])

    compile 'com.android.support:appcompat-v7:22.1.1'

    compile 'com.jakewharton:butterknife:6.1.0'


    // Testing-only dependencies

    androidTestCompile 'com.android.support.test:runner:0.2'

    androidTestCompile 'com.android.support.test:rules:0.2'

    androidTestCompile 'com.android.support.test.espresso:espresso-core:2.1'

}

一時的なバグ?

Warning:Conflict with dependency 'com.android.support:support-annotations'. Resolved versions for app and test app differ.というエラーが出てビルドが止まってしまう問題が生じるかもしれません。

どうもバグらしくて、プロジェクトルートのbuild.gradleに以下を追記することで対処できるそうです。

// Temporary workaround for bug: https://code.google.com/p/android-test-kit/issues/detail?id=136

configurations.all {

    resolutionStrategy.force 'com.android.support:support-annotations:22.1.0'

}

suppot-annotationsの利用するバージョンがコンフリクトを起こしているせいで出ている警告メッセージなので、利用するsupport-annotationsのバージョンを強制的に指定して問題をやり過ごしています。

Gradle徹底入門のP244あたりから読むと何となく分かるかもしれません。

テストを書く

package jp.gcreate.product.developersettingsshortcut;



import android.support.test.rule.ActivityTestRule;

import android.support.test.runner.AndroidJUnit4;

import android.test.suitebuilder.annotation.LargeTest;



import org.junit.Rule;

import org.junit.Test;

import org.junit.runner.RunWith;



import static android.support.test.espresso.Espresso.onView;

import static android.support.test.espresso.action.ViewActions.click;

import static android.support.test.espresso.assertion.ViewAssertions.matches;

import static android.support.test.espresso.matcher.ViewMatchers.isChecked;

import static android.support.test.espresso.matcher.ViewMatchers.isNotChecked;

import static android.support.test.espresso.matcher.ViewMatchers.withId;



@RunWith(AndroidJUnit4.class)

@LargeTest

public class TextableSwitchViewUiTest {

    @Rule

    public ActivityTestRule<UsingTestActivity> mActivityRule = new ActivityTestRule<>(UsingTestActivity.class);



    @Test

    public void 初期値がfalseになっている(){

        onView(withId(R.id.preference_switch)).check(matches(isNotChecked()));

    }



    @Test

    public void タップすると内部のスイッチが有効に切り替わる(){

        //Preference > Editor > Code Style > Java > importでEspresso関係をスタティックインポートするように

        //設定しておかないとコード補完聞いてくれない

        onView(withId(R.id.test)).perform(click());

        onView(withId(R.id.preference_switch)).check(matches(isChecked()));

    }


}


extends ActivityInstrumentationTestCase2を書かなくてもよくなったようです。前々から「ActivityInstrumentationTestCase2って長いわ、そもそも2ってなんやねん」と思っていたので、この変更はうれしいです。

代わりに@Rule ActivityTestRuleを使うようになり、かなりシンプルになったように思います。

このテストはSwitchの初期値がfalseになっているか、タップしたら有効になるかのテストです。書き方もシンプルで分かりやすい気がします。

static importについて

コメントにも書いていますが、Preference > Editor > Code Style > Java > importのタブでstatic importするクラスとしてEspresso関連のクラスを登録しておきましょう。そうすると、onView()と書いた時にalt + Enterでstatic importが候補に出てきてくれるようになります。

static importの設定

テストの実行

テストを実行するためにはエミュレータか実機をパソコンに接続しておく必要があります。

単純なJUnit4のテストを実機無しで実行したくていろいろ調べたりもしましたが、最近はテストができればいいんじゃないかと妥協することにしました。

IDE上でテストを実行

androidTest/javaのフォルダを右クリック、Run→ドロイド君のアイコンのAll Testsを選択すると、テストの実行結果がAndroid Studioで確認できます。

Android Studioからテストを実行

テストが失敗した時のスタックトレースをすぐに確認できますし、IDE上でテストを実行した方が分かりやすいと思います。

コマンドでテストを実行

ターミナルから./gradlew connectedAndroidTestを実行、もしくはGradleツールウィンドウから> connectedAndroidTestをダブルクリックします。

Gradleツールウィンドウから実行

テストの結果は/app/build/outputs/reports/index.htmlを開くと確認できます。

アプリのパフォーマンスを向上させる GPUオーバードロー

この記事は最終更新から3ヶ月以上が経過しています。情報が古い可能性があります。

LinearLayoutをネストしすぎたりするなど、Viewの階層を深くするとアプリのパフォーマンスに良くないという話はよく聞くと思います。

それと似たような話で、画面を何回描画しているかを確認して、アプリのパフォーマンスに役立てることができきます。今回はそれの紹介です。

確認の仕方

端末の開発者オプションで「GPUオーバードローをデバッグ」を有効にします。

GPUオーバードローをデバッグ

これを有効にすると、目に悪そうな色で画面が表示されるようになります。

各色の意味

この各色が、GPUによって何回上書き描画されているのかを示しています。

  • 青色:1回
  • 緑色:2回
  • 薄赤:3回
  • 濃赤:4回以上

この状態で画面が真っ赤っ赤だと、描画方法を改善した方がいいぞということになります。

対策

例えばFrameLayoutでbackgroundDrawableを持ったViewを何個も重ねていくと、見えているのは一番上のものだけなのに、見えない下の要素まで描画するため上書き回数が増えて赤色になってしまいます。

そのため不要なbackgroundDrawableを描画しないようにすることが、この問題の対策になります。

例えばActivityでgetWindow().setBackgroundDrawable(null)とするだけでも画面の赤色が薄くなると思います。(ただし、これをやるとListViewやGridViewなど、スクロールをともなうViewの描画がおかしくなります)

重ねて描画せざるをえない場合は、canvas.clipRectを使って重なって見えない部分を描画しないようにすることで対応できるようです。

効果

ムダな描画回数を減らすことにつながるので、その分アプリの動きが軽快になるでしょう。

さらにバッテリーにも優しくなると思います。

ただし、アプリのもっさり感解消のための施策としては、優先度は低いのかなと思います。ちまたに出ているアプリでも、割と真っ赤なアプリが多いですし、赤くとも動作がもっさりしているものは少ない印象です。

やらないよりやった方がマシでしょうが、ここを気にするより、メモリの使用量を抑えるといったチューニングの方が、アプリのパフォーマンスにとって効果が高いような気がします。

Android Performance

この話はUDACITYのAndroid Performanceという動画を見て知りました。

英語オンリーかつ字幕すらありませんが、大体雰囲気で分かるんじゃないかなと思います。

Android Performance – UDACITY

その画面がどんなViewを使って作られているか調べる方法

この記事は最終更新から3ヶ月以上が経過しています。情報が古い可能性があります。

「このアプリのデザインを参考にしたいんだけど、どうやって作ってるのか知りたい」というときに便利かもしれないコマンドです。

調べたい画面を表示させた状態で、ターミナルからadb shell dumpsys activity topと入力すると、現在表示中のView階層などが表示されます。

View階層だけを調べたいなら、hierarchyviewerを使った方がグラフィカルに見えて便利なのですが、hierarchyviewerはroot権限がないと起動しないので、実機で調べたい画面を表示して解析することができません。

その点、このadb shell dumpsys activity topはroot権限を必要としないので、実機でちょっと調べたいという時に便利だと思います。

どこからどこまでがActionBarの領域で、どこがコンテンツの領域なのかが非常に分かりづらいのですが、Viewに割り振られているIDも一緒に表示されるのである程度把握できると思います。

このIDが表示されるのを利用して、View階層の中でIDの衝突が起こっていないかなんてことを調べるのにも便利かもしれません。

ちなみにadb shell dumpsys activityと最後のtopを省略すると、Activity Managerの情報がズラズラと表示されます。

Broad castがどうなってるかとか、Content Providerがどんなのが動いているかとか、どんなServiceが動いているかとか、スタックがどうなってるかとかが出力されます。

実機でコマンドを打つだけで調べられるので、手軽で便利だと思います。

BaseSaveStateにを拡張してカスタムViewの状態を復元する際の注意点

この記事は最終更新から3ヶ月以上が経過しています。情報が古い可能性があります。

カスタムViewを作った場合、BaseSaveStateを拡張してViewの状態をカスタムView自身で復元できるようにできます。

この際に注意すべきことが3点あります。

Activityを保持しないを有効にしてチェックする

カスタムViewの復元機能を実装したら、必ず開発者オプションのActivityを保持しないを有効にしてちゃんどう動くかどうか確認しましょう。

自分ではちゃんと実装したつもりでも、これを有効にした状態で画面回転させるとアプリが落ちる場合があります。

フィールド名のタイポに注意

BaseSaveStateを拡張したクラスには、必ずpublic static final Parcelable.Creator<BaseSaveStateを拡張したクラス名> CREATORというフィールドが必要です。

このフィールドの名前はCREATORでなければなりません。

CREATERとタイポすると動きません。動かない上にエラーメッセージはjava.lang.RuntimeException: Unable to start activity ComponentInfo{jp.gcreate.sample.savestatecustomview/jp.gcreate.sample.savestatecustomview.MainActivity2Activity}: java.lang.RuntimeException: Parcel android.os.Parcel@18c09797: Unmarshalling unknown type code 2131296303 at offset 264のように、「フィールド名が違います」と教えてくれません。

writeToParcelで書き出す順番

writeToParcelで書き出す順番とコンストラクタで読み出す順番は同じ順番にしなければなりません。

書き出す順番と読み出す順番が異なるとうまく復元することができません。

順番を同じにすることと一緒に忘れていけないのは、最初にsuperを呼び出すことです。

        public ImageState(Parcel source) {
            super(source);
            savedUri = source.readParcelable(Uri.class.getClassLoader());
        }

        @Override
        public void writeToParcel(@NonNull Parcel dest, int flags) {
            super.writeToParcel(dest, flags);
            dest.writeParcelable(savedUri, flags);
        }
```

コンストラクタで`super(source)`を最初に呼び出す、`writeToParcel`の最初で`super.writeToParcel(dest, flags)`を呼び出すことも忘れてはいけません。

単純なことですが、エラーメッセージからどこが悪いのか把握しづらいので、知らないとドはまりするので注意しましょう。

## サンプル

public class UriImageView extends ImageView{
 private Uri mUri;

 public UriImageView(Context context, AttributeSet attrs) {
 super(context, attrs);
 setImage();
 }

 private void setImage() {
 if(mUri == null){
 setImageDrawable(getContext().getResources().getDrawable(android.R.drawable.btn_star, getContext().getTheme()));
 }else{
 setImageURI(mUri);
 }
 }

 public void setUri(Uri uri) {
 mUri = uri;
 setImage();
 }

 @Override
 protected Parcelable onSaveInstanceState() {
 Parcelable superState = super.onSaveInstanceState();
 ImageState imageState = new ImageState(superState);
 imageState.savedUri = mUri;
 return imageState;
 }

 @Override
 protected void onRestoreInstanceState(Parcelable state) {
 ImageState imageState = (ImageState) state;
 super.onRestoreInstanceState(imageState.getSuperState());
 setUri(imageState.savedUri);
 requestLayout();
 }

 static class ImageState extends BaseSavedState{
 public static final Parcelable.Creator CREATOR = new Parcelable.Creator(){

 @Override
 public ImageState createFromParcel(Parcel source) {
 return new ImageState(source);
 }

 @Override
 public ImageState[] newArray(int size) {
 return new ImageState[size];
 }
 };
 Uri savedUri;

 public ImageState(Parcel source) {
 super(source);
 savedUri = source.readParcelable(Uri.class.getClassLoader());
 }

 public ImageState(final Parcelable superState) {
 super(superState);
 }

 @Override
 public void writeToParcel(@NonNull Parcel dest, int flags) {
 super.writeToParcel(dest, flags);
 dest.writeParcelable(savedUri, flags);
 }
 }
}
“`

Android StudioでLogcatをフィルタリングする

この記事は最終更新から3ヶ月以上が経過しています。情報が古い可能性があります。

Logcatでアプリのデバッグをする際に、自分のアプリからのログ出力だけ見たいなんてときありますよね。

そんなときにどうやってフィルタリングをするかという話です。

キーワードやログレベルでのフィルタリングはここでできます。

ログレベル・キーワードでフィルタリング

ちなみにログレベルでのフィルタリングは、指定したレベル以下のものを出力するというフィルタ設定になります。

例えばここでInfoを選ぶとInfo以下のものだけが出力されるようになり、VerboseとDebugレベルのログは表示されなくなります。

ログレベルは下図で囲った部分です。ログレベル/タグという形式で出力されています。

ログレベル

特定のアプリからのログ出力だけ見たい場合は、Show only selected applicationのところをクリックして、Edit Filter Configrationを選びます。

Edit Filter Configration

ここでPackage Nameのところで調べたいアプリのパッケージ名を指定してやると、自分のアプリからの出力しか表示されなくなります。

Package Nameでアプリからの出力のみに絞れる

こういったフィルタリングの設定をうまく使えば、アプリ開発も捗ると思います。

一方でLogcatにこれらのフィルタ設定をしているときには注意しなければならないことがあります。それは、アプリが落ちた時のスタックトレースまでフィルタされて表示されないことがあるということです。

「アプリが落ちたのにLogcatに何も表示されない・・・」と混乱しないようにしましょう。