שיפור הקוד באמצעות בדיקות לאיתור שגיאות בקוד (lint)

בנוסף לבדיקות build כדי לוודא שהאפליקציה עומדת בדרישות הפונקציונליות שלה, חשוב גם להריץ את הקוד בכלי ה-lint כדי לוודא שאין בו בעיות מבניות. כלי ה-lint עוזר למצוא קוד בעל מבנה לקוי שעלול להשפיע על המהימנות והיעילות של אפליקציות Android, ולהקשות על התחזוקה של הקוד. מומלץ מאוד לתקן את כל השגיאות ש-lint מזהה לפני פרסום האפליקציה.

לדוגמה, אם קובצי המשאבים בפורמט XML מכילים מרחבי שמות שלא בשימוש, הפעולה הזו תופסת מקום ונדרש עיבוד מיותר. בעיות מבניות אחרות, כמו שימוש ברכיבים שהוצאו משימוש או קריאות ל-API שלא נתמכות בגרסאות ה-API היעד, עלולות לגרום לכך שהקוד לא יפעל כמו שצריך. Lint יכול לעזור לכם לפתור את הבעיות האלה.

כדי לשפר את הביצועים של איתור השגיאות בקוד, תוכלו גם להוסיף הערות לקוד.

סקירה כללית

ב-Android Studio יש כלי לסריקה של קוד שנקרא lint, שעוזר לזהות ולתקן בעיות באיכות המבנית של הקוד בלי צורך להריץ את האפליקציה או לכתוב תרחישי בדיקה. כל בעיה שזוהתה על ידי הכלי מדווחת עם תיאור ורמת חומרה, כדי שתוכלו לתת עדיפות לשיפורים הקריטיים שצריך לבצע. אפשר גם להוריד את רמת החומרה של בעיה כדי להתעלם מבעיות שלא רלוונטיות לפרויקט, או להעלות את רמת החומרה כדי להדגיש בעיות ספציפיות.

כלי ה-lint בודק את קובצי המקור של פרויקט Android כדי לאתר באגים פוטנציאליים ושיפורים באופטימיזציה של הדיוק, האבטחה, הביצועים, נוחות השימוש, הנגישות וההתאמה לשימוש ברחבי העולם. כשמשתמשים ב-Android Studio, בדיקות ה-IDE וה-lint שהוגדרו פועלות כשמפתחים את האפליקציה. עם זאת, אפשר להפעיל את הבדיקות באופן ידני או להפעיל את ה-lint משורת הפקודה, כפי שמתואר בדף הזה.

הכלי המובנה לאיתור שגיאות בקוד בודק את הקוד בזמן השימוש ב-Android Studio. אפשר להציג אזהרות ושגיאות בשתי דרכים:

  • כטקסט קופץ בחלון העריכה. כשהכלי מוצא בעיה, הוא מדגיש את הקוד הבעייתי בצהוב. בבעיות חמורות יותר, הקוד מודגש באדום.
  • בחלון Inspection Results של איתור השגיאות, כשלוחצים על Code > Inspect Code.

הערה: כשהקוד עובר הידור ב-Android Studio, מתבצעות בדיקות קוד נוספות של IntelliJ כדי לייעל את בדיקת הקוד. חשוב לוודא שגרסת Android Studio מעודכנת ככל האפשר, כדי לוודא שכללי הבדיקה והבדיקות האחרונים זמינים.

איור 1 מראה איך הכלי לאיתור שגיאות בקוד מעבד קובצי מקור של אפליקציה.

תהליך עבודה של סריקת קוד באמצעות הכלי לאיתור שגיאות בקוד.
איור 1. תהליך העבודה של סריקת הקוד באמצעות הכלי לזיהוי שגיאות בקוד (lint).
קובצי מקור של אפליקציות
קבצי המקור מורכבים מהקבצים שמרכיבים את פרויקט Android, כולל קובצי Kotlin,‏ Java ו-XML, סמלים וקובצי תצורה של ProGuard.
הקובץ lint.xml
קובץ תצורה שאפשר להשתמש בו כדי לציין בדיקות איתור שגיאות בקוד שרוצים להחריג, ולהתאים אישית את רמות החומרה של הבעיות.
כלי האיתור של שגיאות בקוד
כלי לסריקת קוד סטטי שאפשר להריץ בפרויקט Android דרך שורת הפקודה או ב-Android Studio. כלי ה-lint בודק בעיות מבניות בקוד שעלולות להשפיע על האיכות והביצועים של אפליקציית Android.
תוצאות בדיקת השגיאות
אפשר להציג את התוצאות של איתור השגיאות במסוף או בחלון Inspection Results ב-Android Studio. אם מריצים את lint משורת הפקודה, התוצאות נכתבות לתיקייה build/. פרטים נוספים זמינים בקטע הפעלת בדיקות באופן ידני.

הרצת איתור שגיאות בקוד משורת הפקודה

אם אתם משתמשים ב-Android Studio או ב-Gradle, תוכלו להשתמש ב-Gradle wrapper כדי להפעיל את המשימה lint בפרויקט. לשם כך, מזינים אחת מהפקודות הבאות מתוך ספריית השורש של הפרויקט:

הערה: חשוב להקפיד שהפלאגין של Android Gradle יהיה עדכני ככל האפשר, כדי שתוכלו להשתמש בכללים העדכניים ביותר של איתור שגיאות בקוד.

  • ב-Windows: 
    gradlew lint
  • ב-Linux או ב-macOS: 
    ./gradlew lint

הפלט אמור להיראות כך:

> Task :app:lintDebug
Wrote HTML report to file:<path-to-project>/app/build/reports/lint-results-debug.html

כשכלי האיתור של שגיאות הקוד מסיים את הבדיקות, הוא מספק נתיבים לגרסאות ה-XML וה-HTML של דוח האיתור. לאחר מכן תוכלו לנווט לדוח ה-HTML ולפתוח אותו בדפדפן, כפי שמוצג באיור 2.

דוח לדוגמה של איתור שגיאות בקוד HTML
איור 2. דוח לדוגמה של איתור שגיאות בקוד HTML.

אם הפרויקט כולל וריאנטים של גרסאות build, הבדיקה של איתור השגיאות תתבצע רק בוריאנטים שמוגדרים כברירת מחדל. אם רוצים להריץ את הבדיקה על וריאנט אחר, צריך להשתמש באותיות רישיות בשם הווריאנט ולהוסיף לו את הקידומת lint. 

./gradlew lintRelease

הערה: בדיקת Lint לא פועלת באופן אוטומטי כחלק מה-build. מומלץ מאוד להריץ את ה-lint באופן מפורש כחלק מbuild של שילוב רצוף, כדי לראות את בדיקות ה-lint העדכניות ביותר בזמן ה-build של קוד המקור הקיים.

מידע נוסף על הרצת משימות Gradle משורת הפקודה זמין במאמר בניית האפליקציה משורת הפקודה.

איך מפעילים את איתור השגיאות בקוד באמצעות הכלי הנפרד

אם אתם לא משתמשים ב-Android Studio או ב-Gradle, תוכלו להתקין את כלים של Android SDK לשורת הפקודה כדי להשתמש בכלי ה-lint העצמאי. צריך לאתר את הכלי לאיתור שגיאות בקוד בכתובת android_sdk/cmdline-tools/version/bin/lint.

הערה: אם מנסים להריץ את הכלי העצמאי בפרויקט Gradle, מופיעה הודעת שגיאה. תמיד צריך להשתמש ב-gradle lint (ב-Windows) או ב-./gradlew lint (ב-macOS או ב-Linux) כדי להריץ איתור שגיאות בקוד בפרויקט Gradle.

כדי להריץ איתור שגיאות בקוד (lint) ברשימת קבצים בספריית פרויקט, משתמשים בפקודה הבאה:

lint [flags] <project directory>

לדוגמה, אפשר להשתמש בפקודה הבאה כדי לסרוק את הקבצים בספרייה myproject ובספריות המשנה שלה. מזהה הבעיה MissingPrefix מציין ל-lint לסרוק רק מאפייני XML שבהם חסרה התחילית של מרחב השמות של Android.

lint --check MissingPrefix myproject

כדי לראות את הרשימה המלאה של הדגלים והארגומנטים של שורת הפקודה שנתמכים בכלי, משתמשים בפקודה הבאה:

lint --help

בדוגמה הבאה מוצג הפלט של מסוף ה-CLI כשמריצים את פקודת האיתור של שגיאות בקוד (lint) בפרויקט שנקרא Earthquake: 

$ lint Earthquake

Scanning Earthquake: ...............................................................................................................................
Scanning Earthquake (Phase 2): .......
AndroidManifest.xml:23: Warning: <uses-sdk> tag appears after <application> tag [ManifestOrder]
  <uses-sdk android:minSdkVersion="7" />
  ^
AndroidManifest.xml:23: Warning: <uses-sdk> tag should specify a target API level (the highest verified version; when running on later versions, compatibility behaviors may be enabled) with android:targetSdkVersion="?" [UsesMinSdkAttributes]
  <uses-sdk android:minSdkVersion="7" />
  ^
res/layout/preferences.xml: Warning: The resource R.layout.preferences appears to be unused [UnusedResources]
res: Warning: Missing density variation folders in res: drawable-xhdpi [IconMissingDensityFolder]
0 errors, 4 warnings

בפלט לדוגמה מפורטות ארבע אזהרות וללא שגיאות.

שתי אזהרות קשורות לקובץ AndroidManifest.xml של הפרויקט:

  • ManifestOrder
  • UsesMinSdkAttributes
אחת מהאזהרות מתייחסת לקובץ הפריסה Preferences.xml: UnusedResources.

אזהרה אחת מתייחסת לספרייה res: IconMissingDensityFolder.

הגדרת איתור שגיאות בקוד כדי לדכא אזהרות

כברירת מחדל, כשמריצים סריקה לאיתור שגיאות בקוד, הכלי בודק את כל הבעיות שיש תמיכה בהן באיתור שגיאות בקוד. אפשר גם להגביל את הבעיות ש-lint בודק, ולהקצות רמות חומרה לבעיות. לדוגמה, אפשר לדכא את בדיקת האיתור של שגיאות בקוד לגבי בעיות ספציפיות שלא רלוונטיות לפרויקט, ואפשר להגדיר את האיתור של שגיאות בקוד כך שידווח על בעיות לא קריטיות ברמת חומרה נמוכה יותר.

רמות החומרה הן:

  • enable
  • disable או ignore
  • informational
  • warning
  • error
  • fatal

אפשר להגדיר בדיקת שגיאות בקוד ברמות שונות:

  • ברמת הפרויקט כולו
  • מודול הפרויקט
  • מודול ייצור
  • מודול בדיקה
  • פתיחת קבצים
  • היררכיית הכיתות
  • היקפי הרשאות של מערכת לניהול גרסאות (VCS)

הגדרת קובץ ה-lint

אפשר לציין את ההעדפות לבדיקת שגיאות בקוד בקובץ lint.xml. אם יוצרים את הקובץ הזה באופן ידני, צריך למקם אותו בספריית השורש של פרויקט Android.

קובץ lint.xml מורכב מתג הורה מסוג <lint> שמקיף אותו, ומכיל רכיב <issue> אחד או יותר של צאצאים. איתור השגיאות בקוד מגדיר ערך ייחודי של מאפיין id לכל <issue>:

<?xml version="1.0" encoding="UTF-8"?>
<lint>
    <!-- list of issues to configure -->
</lint>

כדי לשנות את רמת החומרה של בעיה או להשבית את בדיקת האיתור של שגיאות בקוד בבעיה, מגדירים את מאפיין החומרה בתג <issue>.

טיפ: כדי לקבל רשימה מלאה של הבעיות הנתמכות ב-lint ומזהי הבעיות התואמים, מריצים את הפקודה lint --list.

קובץ lint.xml לדוגמה

בדוגמה הבאה מוצג התוכן של קובץ lint.xml:

<?xml version="1.0" encoding="UTF-8"?>
<lint>
    <!-- Disable the IconMissingDensityFolder check in this project -->
    <issue id="IconMissingDensityFolder" severity="ignore" />

    <!-- Ignore the ObsoleteLayoutParam issue in the specified files -->
    <issue id="ObsoleteLayoutParam">
        <ignore path="res/layout/activation.xml" />
        <ignore path="res/layout-xlarge/activation.xml" />
    </issue>

    <!-- Ignore the UselessLeaf issue in the specified file -->
    <issue id="UselessLeaf">
        <ignore path="res/layout/main.xml" />
    </issue>

    <!-- Change the severity of hardcoded strings to "error" -->
    <issue id="HardcodedText" severity="error" />
</lint>

בדוגמה הזו מוצג איך מדווחים על סוגי בעיות שונים. הבדיקה IconMissingDensityFolder מושבתת לגמרי, והבדיקה של ObsoleteLayoutParam מושבתת רק בקבצים שצוינו בהצהרות <ignore ... /> המצורפות.

הגדרת בדיקת איתור שגיאות בקוד לקובצי מקור של Kotlin,‏ Java ו-XML

אפשר להשבית את בדיקת ה-lint בקובצי המקור של Kotlin,‏ Java ו-XML בתיבת הדו-שיח Preferences:

  1. בוחרים באפשרות קובץ > הגדרות (ב-Windows) או Android Studio > העדפות (ב-macOS או ב-Linux).
  2. בוחרים באפשרות Editor (עריכה) > Inspections (בדיקות).
  3. כדי להשבית, מבטלים את הבחירה בקובץ המקור המתאים.

אפשר להגדיר אותן לסביבת הפיתוח המשולבת (IDE) או לפרויקטים ספציפיים על ידי בחירת הפרופיל המתאים.

הגדרת בדיקת איתור שגיאות בקוד ב-Java או ב-Kotlin

כדי להשבית את בדיקת ה-lint במיוחד לכיתה או לשיטה בפרויקט Android, מוסיפים את ההערה @SuppressLint לקוד הזה.

בדוגמה הבאה מוסבר איך להשבית את בדיקת האיתור של שגיאות בקוד (lint) לגבי הבעיה NewApi בשיטה onCreate. כלי איתור השגיאות בקוד ממשיך לחפש את הבעיה NewApi בשיטות אחרות בכיתה הזו.

Kotlin

@SuppressLint("NewApi")
override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContentView(R.layout.main)

Java

@SuppressLint("NewApi")
@Override
public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.main);

אפשר לעשות את אותו הדבר בכל רכיב Composable. בקטע הקוד הבא מוסבר איך להשבית את הבדיקות של NewApi בכל רכיב Composable.

Kotlin

  @SuppressLint("NewApi")
  @Composable
  fun MyComposable{
    ...
  }

הדוגמה הבאה מראה איך להשבית את בדיקת האיתור של שגיאות בקוד (lint) לגבי הבעיה ParserError בכיתה FeedProvider:

Kotlin

@SuppressLint("ParserError")
class FeedProvider : ContentProvider() {

Java

@SuppressLint("ParserError")
public class FeedProvider extends ContentProvider {

כדי לבטל את הבדיקה של כל בעיות האיתור בקוד בקובץ, משתמשים במילות המפתח all:

Kotlin

@SuppressLint("all")

Java

@SuppressLint("all")

אפשר להשתמש באותה הערה כדי לבטל את בדיקות ה-lint בכל פונקציה של Composable.

הגדרת בדיקת איתור שגיאות בקוד ב-XML

אפשר להשתמש במאפיין tools:ignore כדי להשבית את בדיקת הטעויות בקובצי XML בקטעים ספציפיים. צריך להזין את הערך הבא של מרחב השמות בקובץ lint.xml כדי שהכלי לאיתור שגיאות בקוד יזהה את המאפיין: 

namespace xmlns:tools="http://schemas.android.com/tools"

הדוגמה הבאה מראה איך משביתים את בדיקת ה-lint של הבעיה UnusedResources באובייקט <LinearLayout> בקובץ פריסה של XML. המאפיין ignore עובר בירושה לרכיבי הצאצאים של רכיב ההורה שבו המאפיין מוצהר. בדוגמה הזו, בדיקת האיתור של שגיאות בקוד מושבתת גם לאלמנט הצאצא <TextView>: 

<LinearLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    tools:ignore="UnusedResources" >

    <TextView
        android:text="@string/auto_update_prompt" />
</LinearLayout>

כדי להשבית יותר מבעיה אחת, מציינים את הבעיות שרוצים להשבית במחרוזת מופרדת בפסיקים. לדוגמה:

tools:ignore="NewApi,StringFormatInvalid"

כדי לבטל את הבדיקה של כל בעיות ה-lint ברכיב ה-XML, משתמשים במילות המפתח all:

tools:ignore="all"

הגדרת אפשרויות איתור שגיאות בקוד באמצעות Gradle

הפלאגין Android Gradle מאפשר להגדיר אפשרויות אימות שגיאות מסוימות, כמו בדיקות שצריך להריץ או להתעלם, באמצעות הבלוק lint{} בקובץ build.gradle ברמת המודול.

בקטע הקוד הבא מוצגים חלק מהמאפיינים שאפשר להגדיר:

Kotlin

android {
    ...
    lint {
        // Turns off checks for the issue IDs you specify.
        disable += "TypographyFractions" + "TypographyQuotes"
        // Turns on checks for the issue IDs you specify. These checks are in
        // addition to the default lint checks.
        enable += "RtlHardcoded" + "RtlCompat" + "RtlEnabled"
        // To enable checks for only a subset of issue IDs and ignore all others,
        // list the issue IDs with the 'check' property instead. This property overrides
        // any issue IDs you enable or disable using the properties above.
        checkOnly += "NewApi" + "InlinedApi"
        // If set to true, turns off analysis progress reporting by lint.
        quiet = true
        // If set to true (default), stops the build if errors are found.
        abortOnError = false
        // If set to true, lint only reports errors.
        ignoreWarnings = true
        // If set to true, lint also checks all dependencies as part of its analysis.
        // Recommended for projects consisting of an app with library dependencies.
        checkDependencies = true
    }
}
...

Groovy

android {
    ...
    lint {
        // Turns off checks for the issue IDs you specify.
        disable 'TypographyFractions','TypographyQuotes'
        // Turns on checks for the issue IDs you specify. These checks are in
        // addition to the default lint checks.
        enable 'RtlHardcoded','RtlCompat', 'RtlEnabled'
        // To enable checks for only a subset of issue IDs and ignore all others,
        // list the issue IDs with the 'check' property instead. This property overrides
        // any issue IDs you enable or disable using the properties above.
        checkOnly 'NewApi', 'InlinedApi'
        // If set to true, turns off analysis progress reporting by lint.
        quiet true
        // If set to true (default), stops the build if errors are found.
        abortOnError false
        // If set to true, lint only reports errors.
        ignoreWarnings true
        // If set to true, lint also checks all dependencies as part of its analysis.
        // Recommended for projects consisting of an app with library dependencies.
        checkDependencies true
    }
}
...

כל שיטות האיתור של שגיאות בקוד שמבטלות את רמת החומרה של בעיה מסוימת פועלות לפי סדר ההגדרה. לדוגמה, הגדרת בעיה כקריטית ב-finalizeDsl() מבטלת את השבתתה ב-DSL הראשי.

יצירת ערך בסיס לאזהרות

אתם יכולים ליצור קובץ snapshot של קבוצת האזהרות הנוכחית בפרויקט, ואז להשתמש ב-snapshot כבסיס לפעולות בדיקה עתידיות, כדי שידווחו רק על בעיות חדשות. קובץ ה-snapshot של הבסיס מאפשר להתחיל להשתמש באיתור שגיאות בקוד כדי להיכשל ב-build, בלי שתצטרכו לחזור ולטפל בכל הבעיות הקיימות.

כדי ליצור קובץ snapshot של בסיס, משנים את הקובץ build.gradle של הפרויקט באופן הבא:

Kotlin

android {
    lint {
        baseline = file("lint-baseline.xml")
    }
}

Groovy

android {
    lintOptions {
        baseline file("lint-baseline.xml")
    }
}

כשמוסיפים את השורה הזו בפעם הראשונה, נוצר הקובץ lint-baseline.xml כדי להגדיר את נקודת הבקרה. לאחר מכן, הכלים קוראים את הקובץ רק כדי לקבוע את הבסיס. כדי ליצור קו בסיס חדש, צריך למחוק את הקובץ באופן ידני ולהריץ שוב את הבדיקה כדי ליצור אותו מחדש.

לאחר מכן, מריצים את lint מה-IDE על ידי בחירה באפשרות Code > Inspect Code או משורת הפקודה באופן הבא. הפלט מודפס במיקום של הקובץ lint-baseline.xml. מיקום הקובץ בהגדרה שלכם עשוי להיות שונה מזה שמוצג כאן: 

$ ./gradlew lintDebug -Dlint.baselines.continue=true
...
Wrote XML report to file:///app/lint-baseline.xml
Created baseline file /app/lint-baseline.xml

הרצת lint מתעדת את כל הבעיות הנוכחיות בקובץ lint-baseline.xml. קבוצת הבעיות הנוכחיות נקראת בסיס. אם רוצים לשתף את הקובץ lint-baseline.xml עם אחרים, אפשר להוסיף אותו למערכת בקרת הגרסאות.

התאמה אישית של קו הבסיס

אם רוצים להוסיף לקו הבסיס רק סוגים מסוימים של בעיות, צריך לציין את הבעיות שרוצים להוסיף על ידי עריכת הקובץ build.gradle של הפרויקט באופן הבא:

Kotlin

android {
    lint {
        checkOnly += "NewApi" + "HandlerLeak"
        baseline = file("lint-baseline.xml")
    }
}

Groovy

android {
    lintOptions {
        checkOnly 'NewApi', 'HandlerLeak'
        baseline file("lint-baseline.xml")
    }
}

אם תוסיפו אזהרות חדשות לקוד אחרי שתיצרו את הבסיס, ה-lint יציג רק את הבאגים החדשים.

אזהרה לגבי ערך בסיס

כשבסיס נתונים פעיל, מופיעה אזהרה מידעית על כך שבעיה אחת או יותר סוננו כי הן מפורטות בבסיס הנתונים. האזהרה הזו עוזרת לכם לזכור שהגדרתם קו בסיס שתצטרכו לתקן את כל הבעיות בו בשלב כלשהו.

האזהרה הזו עוזרת גם לעקוב אחרי בעיות שכבר לא מדווחות. המידע הזה מאפשר לכם לדעת אם תיקנתם את הבעיות בפועל, כדי שתוכלו ליצור מחדש את קו הבסיס כדי למנוע שגיאה שתופיע שוב בלי שיזוהו.

הערה: קווים בסיסיים מופעלים כשמריצים בדיקות במצב באצווה בסביבת הפיתוח המשולבת, אבל הם מתעלמים מהם בבדיקות שבתוך העורך שפועלות ברקע בזמן העריכה של קובץ. הסיבה לכך היא שערכי הבסיס מיועדים למקרים שבהם ב-codebase יש מספר גדול של אזהרות, אבל כדאי לתקן בעיות באופן מקומי כשנוגעים בקוד.

הרצת בדיקות באופן ידני

כדי להריץ באופן ידני בדיקות איתור שגיאות בקוד שהוגדרו ובדיקות אחרות של סביבת הפיתוח המשולבת, בוחרים באפשרות Code > Inspect Code. תוצאות הבדיקה מופיעות בחלון Inspection Results.

מגדירים את היקף הבדיקה והפרופיל

בוחרים את הקבצים שרוצים לנתח (היקף הבדיקה) ואת הבדיקות שרוצים להריץ (פרופיל הבדיקה) באופן הבא:

  1. בתצוגה Android, פותחים את הפרויקט ובוחרים את הפרויקט, התיקייה או הקובץ שרוצים לנתח.
  2. בסרגל התפריטים, לוחצים על קוד > בדיקת קוד.

  3. בתיבת הדו-שיח Specify Inspection Scope, בודקים את ההגדרות.

    בדיקת ההגדרות של היקף הבדיקה
    איור 3. בודקים את ההגדרות של היקף הבדיקה.

    האפשרויות שמופיעות בתיבת הדו-שיח Specify Inspection Scope משתנות בהתאם לבחירה שלכם: פרויקט, תיקייה או קובץ:

    • כשבוחרים פרויקט, קובץ או ספרייה, בתיבת הדו-שיח Specify Inspection Scope מוצגת הנתיב לפרויקט, לקובץ או לספרייה שבחרתם.
    • אם בוחרים יותר מפרויקט, קובץ או ספרייה אחת, בתיבת הדו-שיח Specify Inspection Scope יופיע לחצן בחירה Selected files.

    כדי לשנות את הבדיקה, בוחרים באחד מלחצני הבחירה האחרים. תיאור של כל השדות האפשריים בתיבת הדו-שיח ציון היקף הבדיקה מופיע בתיבת הדו-שיח של היקף הבדיקה.

  4. בקטע Inspection profile (פרופיל הבדיקה), בוחרים את הפרופיל שבו רוצים להשתמש.

  5. לוחצים על OK כדי להריץ את הבדיקה.

    באיור 4 מוצגות תוצאות של בדיקת איות ותוצאות אחרות של בדיקת IDE מההרצה של Inspect Code:

    בוחרים בעיה כדי לראות את הפתרון שלה.
    איור 4. התוצאות של הבדיקה. בוחרים בעיה כדי לראות את הפתרון שלה.

  6. כדי להציג את תוצאות הבדיקה בחלונית Inspection Results, מרחיבים את החלונית ובוחרים בקטגוריות, בסוגים או בבעיות של השגיאות.

    בחלונית Inspection Report מוצג דוח הבדיקה של הקטגוריה, הסוג או הבעיה של השגיאה שנבחרו בחלונית Inspection Results, ומוצגים גם השם והמיקום של השגיאה. במקרים הרלוונטיים, בדוח הבדיקה מוצג מידע נוסף, כמו סיכום של הבעיה, שיעזור לכם לפתור אותה.

  7. בתצוגת העץ של החלונית Inspection Results, לוחצים לחיצה ימנית על קטגוריה, סוג או בעיה כדי להציג את תפריט ההקשר.

    בהתאם להקשר, אפשר:

    • מעבר למקור.
    • החרגה והכללה של הפריטים שנבחרו.
    • ביטול הבעיות.
    • עורכים את ההגדרות.
    • ניהול התראות על בדיקות.
    • מפעילים מחדש את הבדיקה.

לתיאורים של הלחצנים בסרגל הכלים, הפריטים בתפריט ההקשר ושדות דוח הבדיקה, ראו חלון הכלי של תוצאות הבדיקה.

שימוש בהיקף מותאם אישית

משתמשים באחת מהרמות המותאמות אישית שזמינות ב-Android Studio באופן הבא:

  1. בתיבת הדו-שיח Specify Inspection Scope, בוחרים באפשרות Custom scope.

  2. לוחצים על הרשימה היקף מותאם אישית כדי להציג את האפשרויות:

    בוחרים את היקף הבדיקה שבו רוצים להשתמש.
    איור 5. בוחרים את ההיקף המותאם אישית שבו רוצים להשתמש.
    • כל המקומות: כל הקבצים.
    • קבצים בפרויקט: כל הקבצים בפרויקט הנוכחי.
    • קובצי המקור של הפרויקט: רק קובצי המקור בפרויקט הנוכחי.
    • קובצי פרויקט ייצור: רק קובצי הייצור בפרויקט הנוכחי.
    • קבצי הבדיקה של הפרויקט: רק קובצי הבדיקה בפרויקט הנוכחי.
    • שרבוטים ומסופים:רק קובצי הגירוד והמסופים שפתוחים בפרויקט הנוכחי.
    • קבצים שנצפו לאחרונה: רק קבצים שנצפו לאחרונה בפרויקט הנוכחי.
    • הקובץ הנוכחי: רק הקובץ הנוכחי בפרויקט הנוכחי. מופיע כשבוחרים קובץ או תיקייה.
    • Selected Directory (ספרייה שנבחרה): רק התיקייה הנוכחית בפרויקט הנוכחי. מופיע כשבוחרים תיקייה.
    • היררכיית כיתות: כשבוחרים באפשרות הזו ולוחצים על אישור, מופיעה תיבת דו-שיח עם כל הכיתות בפרויקט הנוכחי. בתיבת הדו-שיח, משתמשים בשדה חיפוש לפי שם כדי לסנן ולבחור את המחלקות שרוצים לבדוק. אם לא מסננים את רשימת הכיתות, בדיקת הקוד תבדוק את כל הכיתות.

    3. אם הגדרתם מערכת VCS לפרויקט, יש גם אפשרויות להגבלת החיפוש רק לקובצים ששונו.

  3. לוחצים על אישור.

יצירת היקף מותאם אישית

אם רוצים לבדוק מבחר של קבצים ותיקיות שלא נכללים באף אחד מההיקפים המותאמים אישית הזמינים, אפשר ליצור היקף מותאם אישית:

  1. בתיבת הדו-שיח Specify Inspection Scope, בוחרים באפשרות Custom scope.

  2. לוחצים על שלוש הנקודות שמוצגות אחרי הרשימה היקף מותאם אישית.

    תיבת הדו-שיח Specify Inspection Scope
    איור 6. תיבת הדו-שיח Specify Inspection Scope
    .

    תיבת הדו-שיח Scopes מופיעה.

    יצירת היקף מותאם אישית
    איור 7. יצירת היקף מותאם אישית.
  3. לוחצים על הלחצן בפינה הימנית העליונה של תיבת הדו-שיח כדי להגדיר היקף חדש.
  4. ברשימה Add Scope שמופיעה, בוחרים באפשרות Local.

    במאפיין בדיקת הקוד נעשה שימוש גם בהיקפים המקומיים וגם בהיקפים המשותפים. אפשר להשתמש בהיקף משותף גם בתכונות אחרות של הפרויקט שיש להן שדה היקף. לדוגמה, כשלוחצים על Edit Settings (עריכת ההגדרות) כדי לשנות את ההגדרות של Find Usages, בתיבת הדו-שיח שמתקבלת יופיע שדה Scope שבו אפשר לבחור היקף משותף.

    בוחרים היקף שיתוף בתיבת הדו-שיח &#39;חיפוש שימושים&#39;.
    איור 8. בוחרים היקף משותף מתיבת הדו-שיח Find Usages.
  5. נותנים היקף שם ולוחצים על OK.

    בחלונית השמאלית של תיבת הדו-שיח היקפים יופיעו אפשרויות שמאפשרות להגדיר את ההיקף המותאם אישית.

  6. ברשימה, בוחרים באפשרות Project.

    תופיע רשימה של פרויקטים זמינים.

    הערה: אפשר ליצור היקף מותאם אישית לפרויקטים או לחבילות. השלבים זהים.

  7. מרחיבים את תיקיות הפרויקט, בוחרים את מה שרוצים להוסיף להיקף המותאם אישית ובוחרים אם לכלול או להחריג אותו.

    הגדרת היקף מותאם אישית
    איור 9. מגדירים היקף בהתאמה אישית.
    • הכללה: כוללים את התיקייה הזו ואת הקבצים שלה, אבל לא כוללים את תיקיות המשנה שלה.
    • Include Recursively: הכללתה של התיקייה הזו והקבצים שלה, וגם של תיקיות המשנה שלה והקבצים שלהן.
    • החרגה: החרגה של התיקייה הזו והקבצים שלה, אבל לא החרגה של אף אחת מתיקיות המשנה שלה.
    • החרגה היררכית: החרגה של התיקייה הזו והקבצים שלה, וגם של תיקיות המשנה והקבצים שלהן.

    באיור 10 מוצג שהתיקייה main כלולה, והתיקיות java ו-res כלולות באופן רקורסיבי. כחול מציין תיקייה שכלולה חלקית, וירוק מציין תיקיות וקבצים שכלולים באופן רפלוקטיבי.

    דוגמה לדפוס להיקף מותאם אישית
    איור 10. דוגמה לדפוס להיקף מותאם אישית.
    • אם בוחרים בתיקייה java ולוחצים על Exclude Recursively, ההדגשה הירוקה תיעלם בתיקייה java ובכל התיקיות והקבצים שמתחתיה.
    • אם בוחרים את הקובץ MainActivity.kt שמודגש בירוק ולוחצים על החרגה, הקובץ MainActivity.kt לא יודגש יותר בירוק, אבל כל שאר הפריטים בתיקייה java יישארו מודגשים בירוק.
  8. לוחצים על אישור. ההיקף המותאם אישית מופיע בתחתית הרשימה.

בדיקה ועריכה של פרופילי הבדיקה

ב-Android Studio יש מבחר של פרופילים לניפוי שגיאות בקוד ופרופילים אחרים לבדיקות, שמתעדכנים באמצעות עדכוני Android. אפשר להשתמש בפרופילים האלה כפי שהם, או לערוך את השמות, התיאורים, רמות החומרה וההיקפים שלהם. אפשר גם להפעיל ולהשבית קבוצות שלמות של פרופילים או פרופילים ספציפיים בתוך קבוצה.

כדי לגשת להגדרות של הבדיקות:

  1. בוחרים באפשרות קובץ > הגדרות. (ב-Windows) או Android Studio > העדפות (ב-macOS או ב-Linux).
  2. בוחרים באפשרות Editor (עריכה) > Inspections (בדיקות).

  3. בחלונית Inspections מוצגת רשימה של הבדיקות הנתמכות והתיאורים שלהן.

    בדיקות נתמכות והתיאורים שלהן
    איור 11. הבדיקות הנתמכות והתיאורים שלהן.

  4. בוחרים ברשימה Profile כדי לעבור בין הבדיקות Default (Android Studio) ו-Project Default (הפרויקט הפעיל).

    מידע נוסף מופיע בדף ניהול פרופילים של IntelliJ.

  5. ברשימה בדיקות בחלונית הימנית, בוחרים קטגוריית פרופיל ברמה העליונה או מרחיבים קבוצה ובוחרים פרופיל ספציפי.

    כשבוחרים קטגוריה של פרופיל, אפשר לערוך את כל הבדיקות בקטגוריה הזו כבדיקה אחת.

  6. בוחרים ברשימה Show Schema Actions הצגת הסמל של פעולות הסכימה כדי להעתיק, לשנות שם, להוסיף תיאורים, לייצא ולייבא בדיקות.
  7. בסיום, לוחצים על אישור.