6

私が開発しているPixel-Cがあります。私の最小 API レベルは 21 です。これは、ART が Dalvik を置き換えたレベルでもあります。私は両方を試しました：

adb shell setprop dalvik.vm.enableassertions all
adb shell setprop debug.assert 1

そして、それらは正常に実行されているようです。私は置いた

assert false : "assertions are active!";

私の onStart で、logcat にスタック トレースが表示されません。インストールして実行するとすぐにアプリが終了すると思います。このアサーションを実行する方法を教えてください。

JUnit やアサーションを行うその他の方法、またはエラーを明示的にスローする必要があるソリューションについては言及しないでください。製品コードはエラーをスローしたり、エラーをキャッチして処理しようとしたりしてはなりません。そのため、アサーションが言語に追加され、テスト環境で不変式に違反した場合にアプリをクラッシュさせる方法があり、本番環境でオーバーヘッドやリスクをまったく発生させません。

この 6 年前の質問は基本的に同じですが、Dalvik (IE が古い) の場合、解決策は機能しないか、良くありません: Android デバイスで assert を使用できますか?

4

2 に答える 2

3

しぶしぶ申し上げておきますが、答えは次のようです。 ART でアサーションを有効にすることはできません。機能するのは、すべてのアサーションを、次のような if ステートメントでラップされた明示的にスローされた AssertionError に置き換えることです。

if (BuildConfig.DEBUG) {
  if (writeBuffer.hasRemaining()) {
    // As with all assertions, this condition should never be met.
    throw new AssertionError("whole buffer not written");
  }
}

どうやら、API レベル 21、22、および 23 では、インストール時に非デバッグ ビルドからブロックされた場合、つまり BuildConfig.DEBUG == false の場合、ART は実際にはこのバイトコードを完全に削除します。これらの API レベルでは、ART はインストール時にバイトコードをネイティブにコンパイルしますが、これは Android N では変更されています。そのため、Android N では、オプティマイザーがコンパイルする可能性があるまで、BuildConfig.DEBUG をチェックする本番環境で ART のパフォーマンス ペナルティが無視できる程度になる可能性があると推測します。一定量の使用が発生した後、アウトします。

apk で特定のパッケージのアサーションを実行することを選択する機能が削除されるため、これは好きではありません。現在、選択はビルド全体の粒度であり、ビルド時のみです。

これが厄介なもう 1 つの主な理由は、冗長で見苦しいことです。アサーションは簡潔であるため、コードをインラインで文書化するのに適しています。これらのハッキングされたアサーションはドキュメントとして機能しますが、もはや目立たず、読みやすいものではありません。その例を見てください。5 行ではなく、1 行にする必要があります。

ART がアサーションをサポートしていないように見える理由 (たとえば、技術的なハードルや Google の内部政治に関する内部知識など) についての考えがある場合は、コメントするか、新しい回答を残してください。私の推測では、アサーションの有用性と役割に関する誤解が広まり、アンチパターンの使用が蔓延しているため、Android チームは全員を教育するのではなく、単に機能を無効にするようになったのです。Android チームも同じ誤解に悩まされているのかもしれません。

于 2016-04-26T22:47:36.193 に答える