2011-02-10 12 views
21

私はデバッグのために多くのLog.d()またはLog.e()を使用するアプリケーションを持っています。今すぐリリースするために最終パッケージを作成したいと思います。 EclipseのAndroidエクスポート機能に、私が行ったマニフェストの"Debuggable"フラグを削除することが記載されています。また、アプリケーションのパフォーマンスを向上させるためのすべてのLog呼び出しにコメントする必要がありますか?または、これらの呼び出しは、デバッグ不可能な最終バージョンパッケージで何も行いません。 developer.android.comから最後のパッケージを作成する際に、ログ呼び出しにコメントする必要がありますか?

答えて

18

私は、ログのメソッドを反映し、トレースと呼ばれるクラスにLogクラスをサブクラス化しています。 Trace.d(TAG、 "blah")を実行し、Trace.dメソッド内で、コードはLOGGING_LEVELという静的最終クラス変数に基づいて実行されます。レベル1-5(なし、エラーのみ、エラー&警告、エラー&警告&情報、およびすべてを含むデバッグ)。プロダクションAPKを制作する場合、Proguardはアプリケーションで使用されていないコードをすべて削除してくれます。私にとって

、ロギングがソースから削除するにはあまりにも重要ですが、それは、パフォーマンス、セキュリティ保護、知的財産上の理由から、本番アプリケーションから削除する必要があります。

この構造は、私はデバッグの問題がはるかに簡単に行うアプリケーションに、より多くのログを追加することができますが、生産上の一切影響を与えずにAPK

public class Trace 
{ 
    public static final int NONE       = 0; 
    public static final int ERRORS_ONLY     = 1; 
    public static final int ERRORS_WARNINGS    = 2; 
    public static final int ERRORS_WARNINGS_INFO   = 3; 
    public static final int ERRORS_WARNINGS_INFO_DEBUG = 4; 

    private static final int   LOGGING_LEVEL = ERRORS_ONLY;  // Errors + warnings + info + debug (default) 

    public static void e(String tag, String msg) 
    { 
     if (LOGGING_LEVEL >=1) Log.e(tag,msg); 
    } 

    public static void e(String tag, String msg, Exception e) 
    { 
     if (LOGGING_LEVEL >=1) Log.e(tag,msg,e); 
    } 

    public static void w(String tag, String msg) 
    { 
     if (LOGGING_LEVEL >=2) Log.w(tag, msg); 
    } 

    public static void i(String tag, String msg) 
    { 
     if (LOGGING_LEVEL >=3) Log.i(tag,msg); 
    } 

    public static void d(String tag, String msg) 
    { 
     if (LOGGING_LEVEL >=4) Log.d(tag, msg); 
    } 

} 
+1

これは既にAndroidのLogクラスに含まれていると思いました。なぜ、Log.setLogLevel(Log.ERROR)を実行できないのですか?あなたの解決策が本当に良いように見える場合。 – jmbouffard

+16

"プロダクションAPKには何の影響もありません" ...間違っています。これはよく知られた反パターンです。問題は、実際にメッセージを記録するかどうかにかかわらずmsg引数が常に評価されることです。たとえば、Trace.e( "blah"、 "error was:" + error.getCode()+ "、ruh roh!"など)。あなたがログを記録するかどうかにかかわらず、3つの一時文字列オブジェクトが作成され、2つの余計なメソッド呼び出しがあります。 –

+0

@jmbouffard setLogLevel()というログにはメソッドがありません –

4

ログとデバッグをオフにして、リリースのためのデータ/ファイルをクリーンアップ

、あなた はデバッグ機能が がオフになっていることを確認し、そのデバッグや 他の不要なはずですデータ/ファイルは、アプリケーションプロジェクトから削除された です。

マニフェストの 要素からandroid:debuggable = "true" 属性を削除します。ログ ファイル、バックアップファイル、および 不要なファイルをアプリケーション プロジェクトから削除します。非公開または の専有データを確認し、 として必要なものを削除してください。ソースコード内のLog メソッドへの呼び出しをすべて無効にします。

Source

+2

すべてのロギングを削除するのはあまり厳しくありませんが、確実にロギングをデバッグします。 –

+0

私はすでにアンドロイドデベロッパーのウェブサイトにその情報を見ましたが、すべてのコメント以外の「ロギングをオフにする」メカニズムがあるかどうかは私には分かりませんでした。また、「ソースコードのメソッドをログに記録する呼び出しを非アクティブにする」と言うときは、「コメント」を意味するのか、別の方法があるのか​​は明確ではありません。 – jmbouffard

+16

偽善者が書いたことはなんですか?アンドロイドのログは、アンドロイドのアプリやサービスからのメッセージが98%いっぱいです。 「ログメッセージを探したいときにログが乱雑にならないように、すべてのログを無効にする」ということだったかもしれません。 –

8

これは、私は、彼らはまだ、私は間違っていた、コード内のlog.d行が何らかの形でマニフェストに設定デバッグフラグなしで署名リリースAPKに表示されないであろうと、私の仮定をチェック作ら現れる。それは非常にうまく機能し、あなたが任意のコードを変更する必要はありません Remove all debug logging calls before publishing: are there tools to do this?

SO上のクイック検索は、この質問への受け入れ答えに私を導きました。

+0

良い解決策に見えますが、Proguardを使いたいかどうかはわかりません。 – jmbouffard

+0

@jmbouffard:既にリリースapkをビルドするためにAntを使用している場合は、SDKのmain_rules.xmlに既にターゲットがあるため、Proguardを追加するのはかなり簡単です。あなたがAntに精通していないなら、私は同意する、それは少し痛みかもしれない。 – NickT

2

私は以下のように、ロギングコードを削除します:

-assumenosideeffects class android.util.Log { 
    public static boolean isLoggable(java.lang.String, int); 
    public static int v(...); 
    public static int i(...); 
    public static int w(...); 
    public static int d(...); 
    public static int e(...); 
    public static java.lang.String getStackTraceString(java.lang.Throwable); 
} 

-assumenosideeffects class java.lang.Exception { 
    public void printStackTrace(); 
} 

-assumenosideeffects class * implements org.slf4j.Logger { 
    public void trace(...); 
    public void debug(...); 
    public void info(...); 
    public void warn(...); 
    public void error(...); 
    public boolean isTraceEnabled(...); 
    public boolean isDebugEnabled(...); 
    public boolean isInfoEnabled(...); 
    public boolean isWarnEnabled(...); 
    public boolean isErrorEnabled(...); 
} 

必要に応じて、エラーカテゴリと警告カテゴリを保持することができます。しかし、最適化と縮小がビルドで有効になってからコード除去が有効になることを確認してください。

関連する問題