В моем приложении есть проблемы с StrictMode, и я добавил фрагмент кода, который в основном отключает StrictModeHelper.
Пожалуйста, исправьте сетевую ошибку.
Какой метод предпочтительнее .. или они в основном делают то же самое?
@TargetApi
и @SuppressLint
имеют тот же основной эффект: они подавляют ошибку Lint.
Разница в том, что с @TargetApi
помощью параметра вы объявляете, к какому уровню API вы обратились в своем коде, чтобы ошибка могла появиться снова, если вы позже измените метод, чтобы попытаться сослаться на что-то более новое, чем уровень API, указанный в @TargetApi
.
Например, предположим, что вместо того, чтобы блокировать StrictMode
жалобы на вашу сетевую ошибку, вы пытаетесь обойти проблему AsyncTask
сериализации в более новых версиях Android. У вас есть такой метод в вашем коде, чтобы выбрать пул потоков на новых устройствах и использовать многопоточное поведение по умолчанию на старых устройствах:
@TargetApi(11)
static public <T> void executeAsyncTask(AsyncTask<T, ?, ?> task,
T... params) {
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) {
task.executeOnExecutor(AsyncTask.THREAD_POOL_EXECUTOR, params);
}
else {
task.execute(params);
}
}
Наличие @TargetApi(11)
означает, что если Lint обнаружит, что я использую что-то новее моего android:minSdkVersion
, но до уровня API 11, Lint не будет жаловаться. В данном случае это работает. Если, однако, я изменил этот метод для ссылки на что-то, что не было добавлено до уровня API 14, тогда снова появится ошибка Lint, потому что моя @TargetApi(11)
аннотация говорит, что я исправил код для работы только на уровне API 11 и ниже , а не API уровня 14 и ниже и выше.
Используя @SuppressLint('NewApi')
, я потеряю ошибку Lint для любого уровня API, независимо от того, на что ссылается мой код и что мой код настроен для обработки.
Следовательно, @TargetApi
это предпочтительная аннотация, поскольку она позволяет вам более детально сказать инструментам сборки: «Хорошо, я исправил эту категорию проблем».