Sikre høy kvalitet Android-kode med statisk analyseverktøy

I dagens veiledning lærer vi om hvordan du sikrer Android-koden av høy kvalitet i våre prosjekter ved hjelp av noen statiske kodeanalyseverktøy for Java. Vi ser på Checkstyle, FindBugs, PMD og Android Studio Lint-alle gratis og åpen kildekode!

Hva er Static Code Analysis Tools?

Dette er verktøy som analyserer og analyserer kildekoden uten å faktisk utføre den. Målet er å finne potensielle sårbarheter som feil og sikkerhetsfeil. En populær gratis statisk kodeanalysator som FindBugs kontrollerer koden din mot et sett med regler som koden din skal følge med. Hvis koden ikke følger disse reglene, er det et tegn på at noe kan være feil. Tenk på statisk kodeanalyseverktøy som en ekstra kompilator som kjøres før den endelige samlingen i systemspråket.  

Mange programvarefirmaer krever prosjekter for å passere statiske kodeanalyse tester, i tillegg til å gjøre kodeanmeldelser og enhetstesting i byggeprosessen. Selv opprettholdere av open source-prosjekter inkluderer ofte en eller flere statiske kodeanalysesteg i byggeprosessen. Så å lære om statisk analyse er et viktig skritt i å skrive kvalitetskode. Vær oppmerksom på at statisk kodeanalyse - også kjent som "white-box" -testing - ikke bør ses som en erstatning for enhetstesting av kildekoden din.

I denne opplæringen skal vi lære om noen populære statiske analyseverktøy som er tilgjengelige for Android og Java. Men først, la oss se noen av fordelene ved å bruke statisk analyse.

fordeler

• Hjelper med å oppdage potensielle feil som selv enhet eller manuell testing kan ha savnet.
• Definerer prosjektspesifikke regler. For eksempel hjelper statisk analyse som en del av byggekjeden nykommere å få fart på kodestandarder for sitt nye team.
• Hjelper deg med å forbedre kunnskapen til et nytt språk.
• Skanner hele prosjektet ditt, inkludert filer som du kanskje ikke har lest.

Setup

Alle kodeanalyseværktøyene vi vil lære om i denne opplæringen er tilgjengelige som Gradle-plugins, slik at vi kan lage individuelle Gradle-oppgaver for hver av dem. La oss bruke en enkelt Gradle-fil som vil inkludere dem alle. Men før det, la oss lage en mappe som vil inneholde alle våre filer for statisk kodeanalyse. 

Åpne Android Studio og inne i app-modulet (i Prosjekt vis), opprett en ny mappe og gi den navnet code_quality_tools. Denne mappen inneholder XML-filene for kodeanalysverktøyene, og den vil også ha en Gradle-fil, quality.gradle, som vil kjøre våre statiske analyseoppgaver. 

Endelig besøk din build.gradle i appmodulmappen og inkludere denne linjen på slutten av filen:

søk fra: '/code_quality_tools/quality.gradle'

Her, vår kvalitet.Gradle Gradle script blir brukt med en referanse til sin lokale filplassering. 

Checkstyle

Gitt regler som du oppgir i en XML-fil for å håndheve en kodingsstandard for prosjektet, håndhever Checkstyle disse reglene ved å analysere kildekoden og sammenligne dem mot kjente kodingsstandarder eller -konvensjoner. 

Checkstyle er et åpen kildekodeverktøy som aktivt vedlikeholdes av fellesskapet. Dette betyr at du kan lage dine egne tilpassede sjekker eller endre eksisterende som passer dine behov. For eksempel kan Checkstyle sjekke de konstante navnene (endelig, statisk eller begge deler) i klassene dine. Hvis dine konstante navn ikke holder fast i en regel om å være i store versjoner med ord skilt av et understreke, vil problemet bli flagget i den endelige rapporten. 

// feil privat endelig statisk streng myConstant = "myConstant"; // riktig privat endelig statisk streng MY_CONSTANT = "myConstant";

Integrerende Checkstyle

Jeg skal vise deg hvordan du integrerer Checkstyle i vårt Android Studio-prosjekt og demonstrerer et praktisk eksempel.

Først må vi lage våre kodingsregler. Innsiden checkstyle.xml, vi lager noen Checkstyle-konfigurasjonsregler som vil bli kjørt mot vår kode.

I ovennevnte kode inkluderer vi regler eller sjekker vi vil at Checkstyle skal validere i kildekoden vår. En regel er AvoidStarImport, som, som navnet sier, sjekker om kildekoden din inneholder en importoppgave som java.util. *. (I stedet bør du spesifikt angi pakken som skal importeres, f.eks. java.util.Observable.) 

Noen regler har egenskaper, som vi kan stille som vi gjorde for ParameterNumber-dette begrenser antall parametere til en metode eller en konstruktør. Som standard er eiendommen max er 7, men vi endret den til 6 i stedet. Ta en titt på noen av de andre kontrollene på Checkstyle-nettstedet.

For å kjøre denne sjekken, må vi opprette en Gradle-oppgave. Så besøk quality.gradle fil og opprett en oppgave kalt checkstyle:

bruk plugin: 'checkstyle' task checkstyle (type: Checkstyle) beskrivelse 'Kontroller kode standard' gruppe 'verifisering' configFile-fil ('./code_quality_tools / checkstyle.xml') kilde 'src' inkluderer '** / *. java' ekskluder '** / gen / **' classpath = filer () ignoreFailures = false

Legg merke til at i koden ovenfor brukte vi først Checkstyle Gradle plugin. Vi ga den en beskrivelse og la den til en allerede forhåndsdefinert Gradle-gruppe kalt verifisering. 

De viktigste egenskapene til Checkstyle Gradle oppgaven vi er opptatt av, er: 

• oppsett: Checkstyle-konfigurasjonsfilen som skal brukes.
  
• IgnoreFailures: om bygningen skal fortsette eller ikke, hvis det er advarsler.
• inkludere: settet med inkludere mønstre.
• utelukke: settet med ekskluder mønstre. I dette tilfellet skanner vi ikke genererte klasser. 

Endelig kan du kjøre Gradle-skriptet ved å gå til Gradle-verktøyvinduet på Android Studio, og åpne bekreftelse gruppe, og deretter klikke på checkstyle å kjøre oppgaven. 

En annen måte er å bruke kommandolinjen: 

gradle checkstyle

Etter at oppgaven er ferdig, vil en rapport bli generert, som er tilgjengelig på app modul> bygge> rapporter> checkstyle. Du kan åpne checkstyle.html for å se rapporten. 

En Checkstyle-plugin er fritt tilgjengelig for Android Studio eller IntelliJ IDEA. Det tilbyr sanntidsskanning av Java-filene dine. 

PMD

PMD er et annet åpen kildekodeanalyseverktøy som analyserer kildekoden din. Det finner vanlige feil som ubrukte variabler, tomme fangstblokker, unødvendig opprettelse av objekt og så videre. PMD har mange regel sett du kan velge mellom. Et eksempel på en regel som er en del av designreglene er:

• SimplifyBooleanExpressions: Unngå unødvendige sammenligninger i boolske uttrykk som kompliserer enkel kode. Et eksempel: 

offentlig klasse Bar // kan forenkles til // bar = isFoo (); privat booleansk bar = (isFoo () == true); offentlig isFoo () return false;

PMD er konfigurert med PMD.xml fil. Inne i den, inkluderer vi noen konfigurasjonsregler som de for Android, Naming og Design. 

  Tilpasset regelsett for Android-applikasjon .* / R.java .* / Gen /.*                 

Som vi gjorde for Checkstyle, må vi også opprette en PMD Gradle-oppgave for sjekken som skal utføres innenfor quality.gradle fil. 

bruk plugin: 'pmd' oppgave pmd (type: Pmd) beskrivelse 'Kjør PMD' gruppe 'verifisering' ruleSetFiles = filer ("./code_quality_tools / pmd.xml") kilde 'src' inkluderer '** / *. java' ekskluder '** / gen / **' rapporter xml.enabled = false html.enabled = true ignoreFailures = false

PMD er også tilgjengelig som en Gradle-plugin. 

Nøkkelegenskapene til oppgaven vi har opprettet er: 

• ruleSetFiles: Den egendefinerte regelen angir filer som skal brukes.
  
• kilde: Kilden til denne oppgaven.
• rapporter: Rapportene som skal genereres av denne oppgaven.

Til slutt kan du kjøre Gradle-skriptet ved å gå til Gradle-verktøyvinduet, åpne verifikasjonsgruppemappen, og deretter klikke på PMD å kjøre oppgaven. Eller du kan kjøre den via kommandolinjen:

gradle pmd

En rapport vil også bli generert etter utførelsen av oppgaven som er tilgjengelig på app modul> bygge> rapporter> pmd. Det er også et PMD-plugin tilgjengelig for IntelliJ eller Android Studio, slik at du kan laste ned og integrere hvis du vil. 

FindBugs

FindBugs er et annet gratis statisk analyseverktøy som analyserer klassen din etter potensielle problemer ved å sjekke bytekoder mot en kjent liste over feilmønstre. Noen av dem er:

• Klasse definerer hashCode () men ikke like (): En klasse implementerer hashCode () -metoden, men ikke lik () - derfor kan to forekomster være lik, men ikke ha samme hash-koder. Dette faller under kategorien dårlig praksis. 
• Dårlig sammenligning av int verdi med lang konstant: Koden sammenligner en int-verdi med en lang konstant som ligger utenfor rekkevidden av verdier som kan representeres som en int-verdi. Denne sammenligningen er vakuum og vil muligens gi et uventet resultat. Dette faller under kategorien korrekthet. 
• TestCase har ingen test: klassen er en JUnit Testforsøk men har ikke implementert noen testmetoder. Dette mønsteret er også under korrekthetskategorien. 

FindBugs er et open source-prosjekt, slik at du kan se, bidra eller overvåke fremdriften av kildekoden på GitHub. 

I findbugs-exclude.xml fil, vil vi forhindre FindBugs fra å skanne noen klasser (ved hjelp av vanlige uttrykk) i våre prosjekter, som automatisk genererte ressursklasser og auto-genererte manifestklasser. Også, hvis du bruker Dagger, vil vi at FindBugs ikke skal sjekke de genererte Dagger-klassene. Vi kan også fortelle FindBugs å ignorere noen regler hvis vi vil. 

Og til slutt vil vi inkludere findbugs oppgave i quality.gradle:

søk plugin: 'findbugs' task findbugs (type: FindBugs) beskrivelse 'Kjør findbugs' gruppe 'verifikasjon' klasser = filer ("$ project.buildDir / intermediates / classes") kilde 'src' classpath = files 'reportLevel = "høy" excludeFilter-fil (' ./code_quality_tools / findbugs-exclude.xml ') rapporter xml.enabled = false html.enabled = true ignoreFailures = false

I den første linjen over brukte vi FindBugs som en Gradle Plugin og deretter opprettet en oppgave som heter findbugs. Nøkkelegenskapene til findbugs oppgaven vi er veldig opptatt av er: 

• klasser: klassene som skal analyseres.
  
• anstrengelse: Analyseprosessnivået. Verdien spesifisert skal være en av min, misligholde, eller max.  Vær oppmerksom på at høyere nivåer øker presisjonen og finner flere feil på bekostning av kjøretid og minneforbruk.
• reportLevel: Prioritetsgrensen for rapportering av feil. Hvis det er satt til lavt, rapporteres alle feil. Hvis det er satt til middels (standard), rapporteres medium og høy prioritet feil. Hvis de er satt til høye, rapporteres det bare høyprioritetsbuller.
• excludeFilter: Filnavnet til et filter som angir feil for å ekskludere fra å bli rapportert, som vi allerede har opprettet. 

Du kan deretter kjøre Gradle-skriptet ved å gå til Gradle-verktøyvinduet, åpne verifikasjonsgruppemappen, og deretter klikke på findbugs å kjøre oppgaven. Eller start den fra kommandolinjen:

gradle findbugs

En rapport vil også bli generert når oppgaven er fullført. Dette vil bli tilgjengelig på app modul> bygge> rapporter> findbugs. FindBugs-plugin er et annet fritt tilgjengelig plugin for nedlasting og integrasjon med enten IntelliJ IDEA eller Android Studio.

Android Lint

Lint er et annet kodeanalyseværktøy, men dette kommer som standard med Android Studio. Den kontrollerer dine Android-prosjektkildelfiler for potensielle feil og optimaliseringer for korrekthet, sikkerhet, ytelse, brukervennlighet, tilgjengelighet og internasjonalisering. 

For å konfigurere Lint, må du inkludere lintOptions blokkere i modulnivået ditt build.gradle fil:

lintOptions abortOnError falsk stille sant lintConfig-fil ('./code_quality_tools / lint.xml')

De viktigste Lint-alternativene vi er opptatt av, er: 

• abortOnError: om lint skal angi utgangskoden til prosessen hvis det oppdages feil.
• stille: om du vil slå av analyserapporteringsrapporten.
• lintConfig: Standard konfigurasjonsfil som skal brukes.

Din lint.xml fil kan inneholde problemer du vil at Lint skal ignorere eller endre, for eksempel eksempelet nedenfor:

Du kan kjøre Lint manuelt fra Android Studio ved å klikke på Analysere meny, å velge Inspiser kode ...  (inspeksjonsområdet er hele prosjektet), og deretter klikker du på OK knappen for å fortsette.

Du kan også kjøre Lint ved å gå til Gradle-verktøyvinduet og åpne bekreftelse gruppe, og deretter klikke på lo. Til slutt kan du kjøre det via kommandolinjen.

På Windows:

gradvis lint

På Linux eller Mac:

./ gradvis lint

En rapport vil også bli generert når oppgaven er fullført, som er tilgjengelig på app modul> build> outputs> lint-results.html.

Bonus: StrictMode

StrictMode er et utviklerverktøy som forhindrer at utviklere av prosjektet gjør utilsiktet flash I / O eller nettverk I / O på hovedtråden, fordi dette kan føre til at appen er svak eller ikke svarer. Det bidrar også til å forhindre at ANR (App Not Responding) dialoger vises. Med StrictMode-problemer korrigert, blir appen din mer responsiv og brukeren vil få en jevnere opplevelse. StrictMode bruker to sett med retningslinjer for å håndheve sine regler:

• VM-politikk: Vakter mot dårlig koding praksis som ikke lukkes SQLiteCursor objekter eller noe lukk objekt som ble opprettet. 
• Trådretningslinjer: ser ut til operasjoner som flash I / O og nettverk I / O som utføres på hovedprogramtråden i stedet for på en bakgrunnstråd. 

hvis (BuildConfig.DEBUG) StrictMode.setThreadPolicy () StrictMode.ThreadPolicy.Builder () .detectDiskReads () .detectDiskWrites () .detectNetwork () // eller .detectAll () for alle detekterbare problemer .penaltyLog () // Logg oppdaget brudd på systemloggen ... bygge ()); StrictMode.setVmPolicy (new StrictMode.VmPolicy.Builder () .detectLeakedSqlLiteObjects () .detectLeakedClosableObjects () .penaltyLog () .penaltyDeath () // Krasjer hele prosessen på brudd ... bygge ()); 

Koden ovenfor kan være enten i Program, Aktivitet eller annen applikasjonskomponent onCreate () metode. 

Du kan lære mer om StrictMode her på Envato Tuts+. 

Et eksempel på Android-prosjekt som implementerer alle de ovennevnte regelsettene for verktøyene for et typisk Android-prosjekt, finnes i dette innleggets GitHub repo.

Konklusjon

I denne opplæringen har du lært om hvordan du sikrer kvalitetskvalitets Android-kode ved hjelp av statisk kodeanalyseverktøy: hva de er, fordeler med å bruke dem, og hvordan du bruker Checkstyle, FindBugs, Lint, PMD og StrictMode i søknaden din. Gå videre og gi disse verktøyene et forsøk - du kan oppdage noen problemer i koden du aldri forventet.

I mellomtiden kan du se noen av våre andre kurs og opplæringsprogrammer på Android app-utvikling!