Обеспечить высокое качество андроид код с инструменты статического анализа
() translation by (you can also view the original English article)
В сегодняшнем уроке, мы узнаем о том, как обеспечить высокое качество кода Android в наши проекты, используя некоторые инструменты статического анализа кода для Java. Мы будем смотреть на Checkstyle, в FindBugs, PMD, и Android-студия корпит—все из них бесплатные и с открытым исходным кодом!
Какие Инструменты Статического Анализа Кода?
Это инструменты, которые анализируют и анализируют исходный код без их фактического выполнения. Цель состоит в том, чтобы найти потенциальных уязвимостей, таких как ошибки и недостатки безопасности. Популярный бесплатный статический анализатор кода, такие как FindBugs, не проверяет свой код на соответствие набору правил, который ваш код должен придерживаться—если код не следовать этим правилам, это признак того, что что-то может быть не так. Думаю, что инструментов статического анализа кода в качестве дополнительного компилятором, который выполняется перед финальной компиляции на язык системы.
Многие компании по разработке программного обеспечения требуют проекты проходят статические испытания анализ кода, в дополнение к делать ревью кода и модульное тестирование в процессе сборки. Даже разработчики проектов с открытым исходным кодом часто включают в себя один или более статический анализ кода шаги в процессе построения. Поэтому изучение статический анализ является важным шагом в написании качественного кода. Следует помнить, что статический анализ—также код, известный как "белого ящика" тестирование—не должна рассматриваться в качестве замены для модульного тестирования исходного кода.
В этом уроке, мы собираемся, чтобы узнать о некоторых популярных инструментов статического анализа, которые доступны для Android и Java. Но сначала, давайте посмотрим некоторые из преимуществ использования статического анализа.
Преимущества
- Помогает обнаружить потенциальные ошибки, которые даже блок или ручного тестирования, возможно, пропустили.
- Определяются правилами конкретного проекта. Например, Статический анализ, как часть цепочки строить помогает новичкам получить до скорости с нормами Кодекса об их новой команде.
- Поможет вам улучшить ваши знания нового языка.
- Сканирует ваш весь проект, включая файлы, которые вы бы не читали.
Установки
Все инструменты анализа кода мы будем изучать в этом учебнике доступны как Gradle плагинов, так что мы можем создавать отдельные задачи Gradle для каждого из них. Давайте использовать один файл Gradle, который будет включать их все. Но перед этим, давайте создадим папку, которая будет содержать все наши файлы для статического анализа кода.
Откройте Android Studio и внутри App модуль (в виде проекта), создайте новую папку и назовите ее code_quality_tools. Эта папка будет содержать файлы XML для анализа кода, а также будет иметь файл Gradle, качество.Gradle в, которой будет управлять нашей статические задачи анализа.



И, наконец, посетить свою сборку.Gradle в папке модуля приложение и включить эту строку в конец файла:
1 |
apply from: '/code_quality_tools/quality.gradle' |
Здесь наши quality.gradle Gradle сценарий применяется со ссылкой на его расположение локального файла.
Checkstyle
Учитывая указанные правила в XML-файл, чтобы применить стандарт кодирования для вашего проекта, Checkstyle применяет эти правила, анализируя исходный код и сравнивает их с известными стандартами кодирования или конвенций.
Checkstyle-это инструмент с открытым исходным кодом, которая активно поддерживается сообществом. Это означает, что вы можете создавать свои собственные пользовательские проверки или изменять существующие, чтобы удовлетворить ваши потребности. Например, Checkstyle можете запустить проверку на имена констант (конечный, статичный, или оба) в ваших классах. Если ваши постоянные имена не придерживаться правило в верхнем регистре, слова разделяются символом подчеркивания, проблемы будут отмечены в итоговом отчете.
1 |
// incorrect
|
2 |
private final static String myConstant = "myConstant"; |
3 |
|
4 |
// correct
|
5 |
private final static String MY_CONSTANT = "myConstant"; |
Интеграция Checkstyle
Я покажу вам, как интегрировать Checkstyle в нашей студии проект Android и продемонстрировать на практическом примере.
Во-первых, нам нужно создавать свои правила кодирования. Внутри checkstyle.xml мы создаем некоторые правила конфигурация Checkstyle, который будет выполняться наш код.
1 |
<?xml version="1.0"?><!DOCTYPE module PUBLIC
|
2 |
"-//Puppy Crawl//DTD Check Configuration 1.2//EN"
|
3 |
"https://www.puppycrawl.com/dtds/configuration_1_2.dtd">
|
4 |
<module name="Checker"> |
5 |
<module name="FileTabCharacter"/> |
6 |
<module name="TreeWalker"> |
7 |
|
8 |
<!-- Checks for Naming Conventions -->
|
9 |
<!-- See http://checkstyle.sourceforge.net/config_naming.html -->
|
10 |
<module name="MethodName"/> |
11 |
<module name="ConstantName"/> |
12 |
|
13 |
<!-- Checks for Imports -->
|
14 |
<!-- See http://checkstyle.sourceforge.net/config_imports.html-->
|
15 |
<module name="AvoidStarImport"/> |
16 |
<module name="UnusedImports"/> |
17 |
|
18 |
<!-- Checks for Size -->
|
19 |
<!-- See http://checkstyle.sourceforge.net/config_sizes -->
|
20 |
<module name="ParameterNumber"> |
21 |
<property name="max" value="6"/> |
22 |
</module>
|
23 |
|
24 |
<!-- other rules ignored for brevity -->
|
25 |
</module>
|
В приведенном выше коде, мы включаем правила или проверяет, мы хотим Checkstyle, чтобы проверить наш исходный код. Одно правило AvoidStarImport, который, как следует из названия, проверяет, если ваш исходный код включен оператор импорта, как Java.утиль.*. (Вместо этого вы должны явно указать пакет для импорта, например, Java.утиль.Наблюдаема.)
Некоторые правила имеют свойства, которые мы можем установить, как мы делали для ParameterNumber—это ограничивает количество параметров метода или конструктора. По умолчанию свойство Макс 7, но мы поменяли его на 6 вместо. Взгляните на некоторые из других проверок на сайте Checkstyle.
Чтобы выполнить эту проверку, нам необходимо создать задачи Gradle. Так что посетите качеством.файл Gradle и создать задачу checkstyle:
1 |
apply plugin: 'checkstyle' |
2 |
|
3 |
task checkstyle(type: Checkstyle) { |
4 |
description 'Check code standard' |
5 |
group 'verification' |
6 |
|
7 |
configFile file('./code_quality_tools/checkstyle.xml') |
8 |
source 'src' |
9 |
include '**/*.java' |
10 |
exclude '**/gen/**' |
11 |
|
12 |
classpath = files() |
13 |
ignoreFailures = false |
14 |
}
|
Обратите внимание, что в приведенном выше коде, мы впервые применили Checkstyle плагин Gradle в. Мы дали ей описание и добавил его в уже заранее определенной группы Gradle в называемой проверке.
Ключевые свойства задачи Checkstyle Gradle в нас интересует несколько:
- конфигурационный файл: в Checkstyle файл с настройками.
- IgnoreFailures: разрешать или не разрешать строить продолжать, если есть предупреждения.
- включает: набор включить модели.
- исключить: набор исключают моделей. В данном случае, мы не сканируем созданных классов.
Наконец, вы можете запустить скрипт Gradle посетив окне утилиты на Android Gradle в студии, открытие группы проверки, а затем нажав на checkstyle для выполнения задачи.



Другой способ заключается в использовании командной строки:
1 |
gradle checkstyle |
После завершения выполнения данной задачи, будет создан отчет, который доступен в App модуль > построить > отчеты > checkstyle. Вы можете открыть checkstyle.html чтобы просмотреть отчет.



Плагин Checkstyle свободно доступен для Android Studio или IntelliJ идея. Он предлагает сканирование в режиме реального времени Java-файлы.
ПМД
PMD-это другое открытым исходным кодом инструмент анализа, который анализирует исходный код. Он находит общие недостатки как неиспользуемые переменные, пустые блоки catch, ненужное создание объекта и так далее. ПМД имеет множество наборов правил, которые вы можете выбрать из. Пример правила, которое является частью набора правил проектирования:
- SimplifyBooleanExpressions: избежать ненужных сравнений в логических выражениях, которые усложняют простой код. Пример:
1 |
public class Bar { |
2 |
// can be simplified to
|
3 |
// bar = isFoo();
|
4 |
private boolean bar = (isFoo() == true); |
5 |
|
6 |
public isFoo() { return false;} |
7 |
}
|
ПМД настраивается с помощью файла pmd.xml . Внутри его, мы будем включать некоторые правила конфигурации, такие как те для Андроид, нейминг, и дизайн.
1 |
<?xml version="1.0"?>
|
2 |
<ruleset xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="Android Application Rules" |
3 |
xmlns="http://pmd.sf.net/ruleset/1.0.0" |
4 |
xsi:noNamespaceSchemaLocation="http://pmd.sf.net/ruleset_xml_schema.xsd" |
5 |
xsi:schemaLocation="http://pmd.sf.net/ruleset/1.0.0 http://pmd.sf.net/ruleset_xml_schema.xsd"> |
6 |
|
7 |
<description>Custom ruleset for Android application</description> |
8 |
|
9 |
<exclude-pattern>.*/R.java</exclude-pattern> |
10 |
<exclude-pattern>.*/gen/.*</exclude-pattern> |
11 |
|
12 |
<!-- Android --->
|
13 |
<!-- http://pmd.sourceforge.net/pmd-4.3.0/rules/android.html -->
|
14 |
<rule ref="rulesets/java/android.xml"/> |
15 |
|
16 |
<!-- Design -->
|
17 |
<!-- http://pmd.sourceforge.net/pmd-4.3.0/rules/design.html -->
|
18 |
<rule ref="rulesets/java/design.xml"> |
19 |
<exclude name="UncommentedEmptyMethod"/> |
20 |
</rule>
|
21 |
|
22 |
<!-- Naming -->
|
23 |
<!-- http://pmd.sourceforge.net/pmd-4.3.0/rules/naming.html -->
|
24 |
<rule ref="rulesets/java/naming.xml/ShortClassName"> |
25 |
<properties>
|
26 |
<property name="minimum" value="3"/> |
27 |
</properties>
|
28 |
</rule>
|
29 |
<!-- other rules ignored for brevity -->
|
30 |
</ruleset>
|
Как мы это делали для Checkstyle, мы также должны создать задачу ПМД Градля для проверки должны быть выполнены внутри качества.файл Gradle.
1 |
apply plugin: 'pmd' |
2 |
|
3 |
task pmd(type: Pmd) { |
4 |
description 'Run PMD' |
5 |
group 'verification' |
6 |
ruleSetFiles = files("./code_quality_tools/pmd.xml") |
7 |
source 'src' |
8 |
include '**/*.java' |
9 |
exclude '**/gen/**' |
10 |
reports { |
11 |
xml.enabled = false |
12 |
html.enabled = true |
13 |
}
|
14 |
|
15 |
ignoreFailures = false |
16 |
}
|
ПМД также доступна в виде плагина Gradle в.
Ключевые свойства задач, которые мы создали, являются:
- ruleSetFiles: настраиваемые правила набора файлов, которые будут использоваться.
- источник: источником для этой задачи.
- отчеты: отчеты должны быть созданы в данной задаче.
Наконец, вы можете запустить скрипт Gradle посетив окне инструмента Gradle, а открыв папку группы проверки, а затем нажав на ПМД для выполнения задачи. Или вы можете запустить его через командную строку:
1 |
gradle pmd |
Отчет также будет создан после выполнения задания, которое доступно в App модуль > построить > отчеты > ПМД. Также существует плагин для IntelliJ доступен ПМД или Android Studio для вас, чтобы загрузить и интегрировать, если хочешь.
В FindBugs
FindBugs-это еще один бесплатный инструмент статического анализа, который анализирует ваш класс ищет потенциальных проблем, проверяя свой байткод со списком известных паттерны. Некоторые из них:
- Класс определяет hashCode (), но не равен(): класс реализует метод hashCode (), но не равен()—таким образом, в двух случаях может быть равной, но не имеют одинаковые хэш-коды. Это подпадает под категорию плохой практикой.
- Плохое сравнение int значение с длинными постоянные: код сравнивает значение int с длинной константой, которая находится вне диапазона значений, которое может быть представлено как значение типа int. Это сравнение-бессмысленно, и, возможно, принесут неожиданный результат. Это попадает под категорию правильность.
- Теста нет тестов: класс теста в JUnit, но не реализовали методы испытаний. Этот шаблон тоже под категорию правильность.
FindBugs-это проект с открытым исходным кодом, так что вы можете просматривать, участвовать или следить за ходом исходный код на GitHub.
В файле findbugs-exclude.xml мы хотим это предотвратить, в FindBugs от сканирования некоторых классов (используя регулярные выражения) в наших проектах, таких как автоматически сгенерированные классы ресурсов и автоматически проявляться классов. Также, если вы используете Кинжал, мы хотим в FindBugs не для проверки сгенерированных классов Кинжал. Мы можем также сказать в FindBugs, чтобы игнорировать некоторые правила, если мы хотим.
1 |
<FindBugsFilter>
|
2 |
<!-- Do not check auto-generated resources classes -->
|
3 |
<Match>
|
4 |
<Class name="~.*R\$.*"/> |
5 |
</Match>
|
6 |
|
7 |
<!-- Do not check auto-generated manifest classes -->
|
8 |
<Match>
|
9 |
<Class name="~.*Manifest\$.*"/> |
10 |
</Match>
|
11 |
|
12 |
<!-- Do not check auto-generated classes (Dagger puts $ into class names) -->
|
13 |
<Match>
|
14 |
<Class name="~.*Dagger*.*"/> |
15 |
</Match>
|
16 |
|
17 |
<!-- http://findbugs.sourceforge.net/bugDescriptions.html#ST_WRITE_TO_STATIC_FROM_INSTANCE_METHOD-->
|
18 |
<Match>
|
19 |
<Bug pattern="ST_WRITE_TO_STATIC_FROM_INSTANCE_METHOD" /> |
20 |
</Match>
|
21 |
</FindBugsFilter>
|
И, наконец, мы будем включать задания FindBugs в качество.Gradle в:
1 |
apply plugin: 'findbugs' |
2 |
|
3 |
task findbugs(type: FindBugs) { |
4 |
description 'Run findbugs' |
5 |
group 'verification' |
6 |
classes = files("$project.buildDir/intermediates/classes") |
7 |
source 'src' |
8 |
classpath = files() |
9 |
effort 'max' |
10 |
reportLevel = "high" |
11 |
excludeFilter file('./code_quality_tools/findbugs-exclude.xml') |
12 |
reports { |
13 |
xml.enabled = false |
14 |
html.enabled = true |
15 |
}
|
16 |
ignoreFailures = false |
17 |
}
|
В первой строке выше, мы обратились в FindBugs плагин Gradle и затем создал задачу в FindBugs. Ключевые свойства задачи в FindBugs мы очень волнуют:
- классы: классы должны быть проанализированы.
- усилие: анализ уровня усилий. Указанное значение должно быть одной из мин, по умолчанию, или Макс. Следует помнить, что более высокие уровни повышения точности и найти больше ошибок в стоимости времени выполнения и потребления памяти.
- reportLevel: приоритет порог для сообщений об ошибках. Если установлен низкий, сообщили все ошибки. Если установлен средний (по умолчанию), сообщил, средним и высоким приоритетом ошибок. Если установлен высокий уровень, сообщается только ошибок с высоким приоритетом.
- команду excludefilter: имя фильтр, задающий жучки исключить из сообщается, что мы уже создали.
Затем вы можете запустить скрипт Gradle, посетив окне инструмента Gradle, а открыв папку группы проверки, а затем нажав на FindBugs, не для выполнения задания. Или запустить его из командной строки:
1 |
gradle findbugs |
Отчет также будет сгенерировано, когда задача завершит выполнение. Это будет доступно в App модуль > построить > отчеты > в FindBugs. Плагин FindBugs-это еще свободно доступен плагин для скачивания и интеграция с IntelliJ идея или Android студия.
Линт Андроид
Линт-это еще один инструмент анализа кода, но это приходит с Android Studio по умолчанию. Он проверяет исходные файлы проекта Android для потенциальных ошибок и оптимизации за правильность, безопасность, производительность, удобство использования, доступность, интернационализация.
Чтобы настроить Линт, вы должны включить lintOptions {} блок в модуле построения уровня.файл Gradle:
1 |
lintOptions { |
2 |
abortOnError false |
3 |
quiet true |
4 |
lintConfig file('./code_quality_tools/lint.xml') |
5 |
}
|
Ключевые параметры Линт нас интересует, являются:
- abortOnError: то ли ворсинки должны установить код выхода из процесса, если нашли ошибки.
- тихий: можно ли отключить анализ докладов о ходе работы.
- lintConfig: по умолчанию конфигурационный файл.
Ваш lint.xml файл может включать в себя вопросы, которые вы хотите Линт игнорировать или изменять, как в примере ниже:
1 |
<?xml version="1.0" encoding="UTF-8"?>
|
2 |
<lint>
|
3 |
<!-- Disable the given check in this project -->
|
4 |
<issue id="IconMissingDensityFolder" severity="ignore" /> |
5 |
|
6 |
<!-- Change the severity of hardcoded strings to "error" -->
|
7 |
<issue id="HardcodedText" severity="error" /> |
8 |
</lint>
|
Вы можете запустить Линт вручную из Android Studio, нажав в меню "анализ" выбираем код проверить... (объема контроля является весь проект), а затем нажав на кнопку ОК, чтобы продолжить.






Вы также можете запустить Линт, посетив окне инструмента Gradle, а открытие группы проверки, а затем нажав на Линт. Наконец, вы можете запустить его через командную строку.
На Windows:
1 |
gradlew lint |
На Linux или Mac:
1 |
./gradlew lint |
Отчет также будет сгенерировано, когда задача завершит выполнение, которое доступно в App модуль > построить > выходы > lint-results.html.
Бонус: StrictMode
StrictMode является разработчиком инструмент, который помогает предотвратить разработчики проекта делают все случайные вспышки ввода/вывода или сетевого ввода-вывода в основном потоке, потому что это может привести к тому, что приложение было вяло и не отвечает. Это также помогает в предотвращении АНР (приложение не отвечает) диалоги с появляться. С вопросами StrictMode исправлена, приложения станут более отзывчивыми и пользователь будет наслаждаться гладкой опыт. StrictMode использует два набора политик для обеспечения соблюдения своих правил:
- Политика ВМ: защищает от плохой практикой программирования, например, не закрывая объекты SQLiteCursor или любой закрывающиеся объект, который был создан.
- Резьба политики: выходит для таких операций, как вспышка ввода-вывода и ввода-вывода выполняются на поток основного приложения, а не в фоновом потоке.
1 |
if (BuildConfig.DEBUG) { |
2 |
StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder() |
3 |
.detectDiskReads() |
4 |
.detectDiskWrites() |
5 |
.detectNetwork() // or .detectAll() for all detectable problems |
6 |
.penaltyLog() // Log detected violations to the system log. |
7 |
.build()); |
8 |
StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder() |
9 |
.detectLeakedSqlLiteObjects() |
10 |
.detectLeakedClosableObjects() |
11 |
.penaltyLog() |
12 |
.penaltyDeath() // Crashes the whole process on violation. |
13 |
.build()); |
14 |
}
|
Приведенный выше код может быть либо в приложении, Активность, или другой компонент приложения onCreate() метод.
Вы можете узнать больше о StrictMode здесь на Envato Tuts+, и.
Образец проекта Android реализует все вышеперечисленное, включая наборы правил из инструментов для типичного проекта Android можно найти в данном посте в GitHub РЕПО.
Заключение
В этом уроке вы узнали о том, как обеспечить высокое качество Android код, используя средства статического анализа кода: что они собой представляют, преимущества их использования, и как использовать Checkstyle, FindBugs, не, Линта, ПМД и StrictMode в приложении. Идти вперед и дать эти средства попробовать—вы можете обнаружить некоторые проблемы в коде, которые вы никогда не ожидали.
В то же время, проверить некоторые из наших других курсов и учебники по разработке приложений Android!
- Андроид СДКRxJava 2 для Android-приложений: RxBinding и RxLifecycleДжессика Thornsby
- Android-СтудияКодирование функциональных приложений для Android в Котлин: Приступая к работеДжессика Thornsby
- Андроид СДКAndroid с нуля: с помощью API-интерфейсов RESTAshraff Hathibelagal
- Андроид СДККак создать приложение чат в Android с помощью опорного пунктаAshraff Hathibelagal