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

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

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

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

סקירה כללית

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

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

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

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

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

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

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

הרצת lint משורת הפקודה

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

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

  • ב-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

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

דוח לדוגמה של HTML Lint
איור 2. דוח לדוגמה של HTML lint.

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

./gradlew lintRelease

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

מידע נוסף על הרצת משימות Gradle משורת הפקודה זמין במאמר Build your app from the command line.

הרצת lint באמצעות הכלי העצמאי

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

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

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

lint [flags] <project directory>

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

lint --check MissingPrefix myproject 

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

lint --help

בדוגמה הבאה מוצג פלט המסוף כשמריצים את פקודת ה-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: Warning: Missing density variation folders in res: drawable-xhdpi [IconMissingDensityFolder]
0 errors, 4 warnings

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

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

  • ManifestOrder
  • UsesMinSdkAttributes

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

הגדרת lint להסתרה של אזהרות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    <!-- Ignore the ComposeUnrememberedState issue in the specified files -->
    <issue id="ComposeUnrememberedState">
        <ignore path="src/main/java/com/example/myapp/MainActivity.kt" />
        <ignore path="src/main/java/com/example/myapp/ui/components/SpecialButton.kt" />
    </issue>

    <!-- Ignore the ComposeModifierMissing issue in the specified file -->
    <issue id="ComposeModifierMissing">
        <ignore path="src/main/java/com/example/myapp/ui/screens/HomeScreen.kt" />
    </issue>

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

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

הגדרת בדיקת lint לקובצי מקור ב-Kotlin וב-XML

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

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

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

הגדרת בדיקת lint ב-Kotlin

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

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

@SuppressLint("NewApi")
fun logNotificationChannelInfo() {
    // Uses NotificationChannel (requires API 26+)
    ...
}

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

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

בדוגמה הבאה מוצג איך להשבית את בדיקת ה-lint לבעיה ParserError במחלקה FeedProvider:

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

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

@SuppressLint("all")

אפשר להשתמש באותה אנוטציה כדי להשבית בדיקות כלי לאיתור שגיאות בקוד (lint) בכל פונקציה קומפוזבילית.

הגדרת בדיקת lint ב-XML

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

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

בדוגמה הבאה אפשר לראות איך משביתים את בדיקת ה-lint לבעיה UnusedResources ברכיב <resources> בקובץ strings.xml. המאפיין ignore עובר בירושה לרכיבי הצאצא של רכיב ההורה שבו המאפיין מוצהר. בדוגמה הזו, בדיקת ה-lint מושבתת גם לכל רכיבי <string> שמוקפים בתוכה:

<resources
    xmlns:tools="http://schemas.android.com/tools"
    tools:ignore="UnusedResources" >

    <string name="app_name">My App</string>
    <string name="unused_string">Unused String</string>
</resources>

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

tools:ignore="NewApi,StringFormatInvalid"

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

tools:ignore="all"

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

הפלאגין של Android Gradle מאפשר להגדיר אפשרויות מסוימות של lint, כמו אילו בדיקות להריץ או להתעלם מהן, באמצעות הבלוק 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
    }
}
...

מגניב

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
    }
}
...

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

יצירת בסיס להשוואה של אזהרות

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

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

Kotlin

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

מגניב

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

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

אחר כך מריצים את 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")
    }
}

מגניב

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

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

אזהרה לגבי נתונים בסיסיים

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

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

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

הפעלת בדיקות באופן ידני

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

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

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

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

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

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

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

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

  4. בקטע פרופיל בדיקה, בוחרים את הפרופיל שרוצים להשתמש בו.
  5. לוחצים על אישור כדי להריץ את הבדיקה.

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

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

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

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

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

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

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

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

אפשר להשתמש באחד מההיקפים המותאמים אישית שמופיעים ב-Android Studio באופן הבא:

  1. בתיבת הדו-שיח Specify Inspection Scope (ציון היקף הבדיקה), בוחרים באפשרות Custom scope (היקף מותאם אישית).
  2. לוחצים על הרשימה היקף מותאם אישית כדי להציג את האפשרויות:

    בוחרים את היקף הבדיקה שרוצים להשתמש בו
    איור 5. בוחרים את ההיקף המותאם אישית שרוצים להשתמש בו.
    • כל המקומות: כל הקבצים.
    • קבצים בפרויקט: כל הקבצים בפרויקט הנוכחי.
    • קובצי המקור של הפרויקט: רק קובצי המקור בפרויקט הנוכחי.
    • קבצים של פרויקט בסביבת ייצור: רק הקבצים של הפרויקט הנוכחי בסביבת הייצור.
    • Project Test Files: רק קובצי הבדיקה בפרויקט הנוכחי.
    • Scratches and Consoles: Only the scratch files and consoles you have open in the current project.
    • קבצים שנצפו לאחרונה: רק קבצים שנצפו לאחרונה בפרויקט הנוכחי.
    • הקובץ הנוכחי: רק הקובץ הנוכחי בפרויקט הנוכחי. האפשרות הזו מופיעה כשבוחרים קובץ או תיקייה.
    • הספרייה שנבחרה: רק התיקייה הנוכחית בפרויקט הנוכחי. מופיע כשבוחרים תיקייה.
    • Class Hierarchy: כשבוחרים באפשרות הזו ולוחצים על OK, מופיעה תיבת דו-שיח עם כל המחלקות בפרויקט הנוכחי. בתיבת הדו-שיח, משתמשים בשדה חיפוש לפי שם כדי לסנן ולבחור את הכיתות שרוצים לבדוק. אם לא מסננים את רשימת הכיתות, הבדיקה תבדוק את כל הכיתות.
  3. אם הגדרתם מערכת VCS לפרויקט, יש גם אפשרויות להגביל את החיפוש רק לקבצים שעברו שינוי.

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

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

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

  1. בתיבת הדו-שיח Specify Inspection Scope (ציון היקף הבדיקה), בוחרים באפשרות Custom scope (היקף מותאם אישית).
  2. לוחצים על סמל האפשרויות הנוספות (3 נקודות) אחרי הרשימה היקף בהתאמה אישית.

    תיבת הדו-שיח 'ציון היקף הבדיקה'
    איור 6. מציינים את תיבת הדו-שיח של היקף הבדיקה.

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

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

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

    בחירת היקף משותף מתיבת הדו-שיח Find Usages (איתור שימושים)
    איור 8. בוחרים היקף שיתופי מתיבת הדו-שיח Find Usages (חיפוש שימושים).
  5. נותנים לשם ההיקף ולוחצים על אישור.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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