【ITニュース解説】barK: A Lightweight Logging Library for Android

システム開発の現場では、プログラムが意図通りに動いているか、どこで問題が発生したかを確認するために「ログ」という記録を残すことが非常に重要だ。ログは、プログラムの内部で何が起きているかを教えてくれる「プログラムの日記」のようなもので、システムエンジニアが問題を解決したり、機能改善を行う上で欠かせない情報源となる。しかし、このログの管理は意外と手間がかかることがあり、特にAndroidアプリケーション開発ではいくつかの課題があった。

今回紹介する「barK」は、Androidアプリケーションや、AndroidとiOSなどで共通のコードを使える「Kotlin Multiplatform (KMP)」プロジェクトのために作られた、軽量なロギングライブラリだ。このbarKは、従来のロギングで開発者が感じていた不便さを解消し、より効率的で柔軟なログ管理を可能にすることを目指して開発された。

従来のAndroid開発で使われる標準のログ機能（android.util.Log）や、他の人気のあるロギングライブラリには、いくつかの課題があった。例えば、アプリケーションをユーザーに公開する「リリースビルド」の際には、デバッグ用の詳細なログは不要で、むしろパフォーマンスの低下や情報漏洩のリスクにつながるため、オフにしたい。しかし、開発中に細かく挙動を確認するための「デバッグビルド」では、詳細なログが必要だ。また、プログラムの一部が正しく動作するかを確認する「単体テスト」の際には、通常のアプリケーションとは異なり、コンソール（開発環境の画面）に直接ログを出力したい場合がある。さらに、ライブラリやSDK（ソフトウェア開発キット）として提供されるコードの場合、それを利用する側のアプリケーション開発者が、自分の都合に合わせてログの出力方法を調整したり、完全に停止したりできるような柔軟性が求められていた。

barKは、これらの課題を解決するために考案された。リリースビルドで簡単にログをオフにでき、単体テスト時にはprint()関数を使ってコンソールにログを出力できる。また、アプリケーションに組み込む開発者が、ログの出力を自由に制御できる設計になっている。これにより、デバッグ能力を最大限に高めながら、本番環境では不要なログを出さないといった運用が可能になる。

barKの主な機能は、「タグ付け (Tagging)」、「トレーニング (Training)」、「ロギング (Logging)」の三つに分けられる。

まず「タグ付け」について説明する。ログには通常、「タグ」と呼ばれる目印を付けて、どの部分の処理から出力されたログなのかを識別できるようにする。barKでは、このタグの管理方法が二つある。一つは、デフォルトの「自動検出タグ」機能を使う方法だ。これは、ログを出力しているプログラムのクラス名（例えばMainActivityやLoggingRepositoryといった、プログラムの部品の名前）を自動的にタグとして使用する。これにより、開発者が手動でタグを指定する手間が省け、どのクラスからログが出たのかが一目でわかる。もう一つの方法は、「グローバルタグ」を設定する方法だ。これは、プログラム全体で共通のタグを設定するもので、例えば「MyApp」といったプロジェクト名などをタグとして使うことができる。グローバルタグを設定すると、自動検出機能は無効になり、すべてのログにそのグローバルタグが付けられる。もしグローバルタグを解除したい場合は、untag()関数を呼ぶことで、再び自動検出モードに戻すことが可能だ。

次に「トレーニング」機能だ。barKは、どのようにログを扱うかを「トレーナー」という仕組みを使って学習（トレーニング）させる必要がある。トレーナーは、ログの出力先や、どのようなログレベル（情報の重要度を表すレベル。例えば、詳細な情報、デバッグ情報、警告、エラーなどがある）のログを扱うかを定義する。barKには、いくつかの便利な「組み込みトレーナー」が用意されている。例えば、AndroidLogTrainer()はAndroid標準のログ機能を使って出力し、UnitTestTrainer()は単体テスト時にprint()関数でコンソールに出力する。ColoredUnitTestTrainer()は、さらに色付きで出力して見やすくする機能も持つ。

各トレーナーは「Pack」という属性を持っており、これによりログの出力先が区別される。例えば、CONSOLEパックはコンソールへ、SYSTEMパックはAndroidの標準ログシステムへ、FILEパックはファイルへログを書き込むことを示す。CUSTOMパックは、開発者が自由に定義できる出力先のために用意されており、このCUSTOMパックのトレーナーだけは、複数同時に有効にできるという特徴がある。他のパックは、同じ種類の出力先への重複を避けるために、一度に一つしか有効にできない。このPackの仕組みによって、barKは同じログが複数の場所に不必要に出力されることを防ぎつつ、必要な場合には柔軟な設定を可能にしている。

また、barKでは開発者が独自の「カスタムトレーナー」を作成することも可能だ。これは、Trainerインターフェースを実装することで実現できる。例えば、特定の警告やエラーメッセージだけを捕捉して、特別な処理を行うトレーナーを作成したり、ログメッセージをSlackのようなチャットツールに送信するトレーナーを作成したりできる。このように、ログの処理方法を完全にカスタマイズできるため、barKは非常に高い柔軟性を持っている。カスタムトレーナーも、その出力先に応じて適切なPackを設定できる。

そして、「ロギング」機能だ。タグ付けとトレーニングの設定が終われば、実際にログを出力するのは非常に簡単だ。barKは、一般的なロギングライブラリと同様に、ログの重要度に応じた関数を提供している。例えば、v()は詳細な情報（Verbose）、d()はデバッグ情報（Debug）、i()は情報（Info）、w()は警告（Warning）、e()はエラー（Error）といったログを出力するために使う。これらの関数を呼ぶだけで、設定されたトレーナーがログメッセージを適切に処理してくれる。

さらに、barKには「ミュート (Muzzling)」という機能もある。これは、実行中にライブラリ全体のログ出力を一時的に停止する機能だ。muzzle()関数を呼ぶとログ出力が停止し、umuzzle()関数で再開できる。これは、機密情報を含む処理など、特定の場面で一時的にログを出したくない場合に非常に役立つ。

実際にbarKをプロジェクトに組み込むには、まずGradleの設定ファイルにbarKのライブラリが公開されている場所（JitPackというリポジトリ）を追加し、次にアプリケーションのビルドファイルにbarKの依存関係（使用する部品の指定）を記述する。これにより、barKライブラリをプロジェクト内で利用できるようになる。

AndroidアプリケーションでbarKを使用する場合、通常はアプリケーションが起動するタイミングでトレーナーを設定する。例えば、ApplicationクラスのonCreate()メソッド内で、AndroidLogTrainerをトレーニングする。この際、BuildConfig.DEBUGという、開発中かリリース中かを判別するフラグを使って、開発中（DEBUGビルド）は詳細なログ（Level.DEBUG以上）を出力し、リリース中（RELEASEビルド）は重要な警告（Level.WARNING以上）のみを出力するといった設定が可能だ。これにより、開発時のデバッグ効率と、リリース時のアプリケーションの安定性の両方を高めることができる。

単体テストの実行時にログを出力したい場合は、テストケースの実行前（@Beforeアノテーションが付いたメソッド内など）に、すべてのトレーナーを一度解除（releaseAllTrainers()）してから、UnitTestTrainerをトレーニングする。こうすることで、テスト実行中にprint()関数を使ってコンソールにログが出力され、テストの挙動を詳細に確認できる。これは、テスト中にプログラムの内部状態を把握するために非常に有効だ。

barKは、このようにAndroidやKotlin Multiplatformプロジェクトにおけるロギングを、よりシンプルかつ強力に管理するためのライブラリだ。開発者の日々の作業を効率化し、アプリケーションの品質向上に貢献することを目指している。将来的には、SDK利用における詳細な解説や、CI/CD（継続的インテグレーション／継続的デリバリー）環境での単体テストにおけるbarKの利点に焦点を当てた情報も公開される予定だ。また、現時点ではAndroidを中心としたサポートだが、今後の開発でiOSへの完全なサポートも計画されている。このライブラリは、開発者がログを「良い家」に住まわせる（適切に管理する）ための、新しい解決策となるだろう。