一度、1つのプロジェクトを書きました。 プロジェクトは大規模であることが判明し、私は長い間それを書きました。
押し込むことができるすべてがありました-そして、retrolambda / java8、および数十個
他のライブラリ(新機能に対する顧客の欲望は際限がなかったため、
依存関係の数が増加しました)。
しかし、これはそれについてでさえありません。 リリースを行う時です。 そして、それはプロジェクトで
多くのログがあり、それらをリリースビルドから削除するとよいでしょう。 誰もが知っている
ProGuardを使用したメソッドは、最初は機能しませんでした。 すべての新しい「-keep」で
アプリケーションは新しい場所でクラッシュしました。 したがって、ProGuardは無効にする必要がありました
良い時まで。
この間ずっと、ロギングcのレベルを制御しているという感覚
バイトコードの変更を使用するのはばかげています。 それから30分で
プリミティブロガー。
通常、私はめったに自分のプロジェクトを終わらせることはめったにありませんが、ここではとても簡単でした-今では
githubにあります;
必要であれば 、それを使用してください。
互換性のあるAPI-簡単な移行
Timberを使用しなかった理由の1つは、指が
Log.dの入力に使用します。 また、クラスを「Log」と呼び、「android.util.Log」と互換性のあるメソッドを作成しました。
これは、標準のロガーから飛び降りたい場合-ちょうど
インポートを置き換えます。 これは、sedを使用するか、お気に入りを使用して実行できます。
IDE
利点は何ですか?
さて、ロガーの主な機能を示すいくつかのコードスニペットがあります。
どこで入手できますか?
Githubソース:
github.com/zserge/logbuild.gradleでは、ライブラリは通常どおり接続されます。
repositories { jcenter()
これは、インポートを置き換える方法です。
$ find -name "*.java" -type f -exec sed -i 's/import android.util.Log/import trikita.log.Log/g' {} \;
MITで認可されたロガー、健康のために使用。 なしの1つのクラスがあります
依存関係は250行のみであるため、プロジェクトが重くなったり遅くなったりすることはありません。
要望やバグ報告(特にパッチを含む)は大歓迎です!
UPD:コードレビューと建設的なコメントをありがとう。 おかげで、バージョン1.1.5を投稿しました。
- スレッドの安全性は、同期化によって額の中で行わなければなりませんでした。 速度を測定しました-実際には速度は低下しませんでしたが、複数のメッセージが異なるストリームから印刷された場合に壊れることはありません。 はい、突然プリンターがマルチスレッド化されていない場合は落ち着きます
- 私はベンチマークをチェックしました-はい、私のロガーは反射のためにandroid.util.Logよりも遅いです。 しかし、彼はTimberより遅くはありません。 一般に、1秒あたり10,000ログ未満を書き込む場合-パフォーマンスの問題はありません
- さて、プライベートコンストラクタを追加しました。些細なことに、名前が整理されている場所、ドキュメントがあります