טעינה מראש ב-WebView

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

‫WebView תומך בשלושה סוגים עיקריים של טעינה מראש: Preconnect,‏ Prefetch ו-Prerender, לצד רמזים ל-QUIC כדי לבצע אופטימיזציה למשא ומתן על פרוטוקול.

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

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

בחירה של אסטרטגיית טעינה מראש

ההבדל העיקרי בין השיטות האלה הוא בהיקף שלהן: ממשקי ה-API של רמזים לחיבור מראש ו-QUIC מבוססים על מקור, כלומר הם דורשים רק את דומיין היעד. ממשקי ה-API של Prefetch ו-Prerender מבוססים על כתובות URL, ולכן הם דורשים את הנתיב המדויק של דף האינטרנט.

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

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

חיבור מוקדם למקורות

החיבור מראש מזרז טעינות עתידיות על ידי ביצוע מוקדם של חיפושי DNS ולחיצות יד של TCP/TLS או QUIC למקור שצוין.

בניגוד לשליפה מראש (prefetch) ולטרום-עיבוד (prerender), שדורשים כתובת יעד מדויקת, טרום-חיבור (preconnect) מבוסס אך ורק על מקור. כך אפשר לבצע את הקריאה Preconnect הרבה יותר מוקדם מאשר Prefetch ו-Prerender.

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

הטמעה

כדי ליזום חיבור מראש, מתקשרים אל preconnect(String url) במכונת Profile צריך להפעיל את ה-API הזה בשרשור UI, והוא דורש תמיכה ב-WebViewFeature.PRECONNECT.

ה-API פועל על המקור, אבל כדי שיהיה נוח יותר, אפשר לספק כתובת URL מלאה (למשל https://www.example.com/index.html). המערכת מתייחסת לזה באופן אוטומטי כקריאה למקור (למשל, https://www.example.com). אפשר לקשר כמה מקורות על ידי קריאה ל-API הזה כמה פעמים.

// Must be called on the @UiThread
if (WebViewFeature.isFeatureSupported(WebViewFeature.PRECONNECT)) {
    profile.preconnect("https://www.example.com/index.html")
    // This initiates a connection to the origin https://www.example.com
}

// Must be called on the @UiThread
if (WebViewFeature.isFeatureSupported(WebViewFeature.PRECONNECT)) {
    profile.preconnect("https://www.example.com/index.html");
    // This initiates a connection to the origin https://www.example.com
}

ציון תמיכה בפרוטוקול QUIC באמצעות רמזים ל-QUIC

פרוטוקול HTTP/3 (שפועל על פרוטוקול התעבורה QUIC) מציע שיפורים משמעותיים בזמן האחזור בהשוואה ל-HTTP/2, כולל לחיצות ידיים של 0-RTT, שיפור העמידות של החיבור וביטול החסימה של ראש התור במהלך אובדן מנות.

כברירת מחדל, WebView מנסה ליצור חיבור QUIC רק אם יש לו אינדיקציה לכך שהמקור תומך ב-QUIC, למשל מכותרת Alt-Svc או מרשומה של DNS HTTPS מאינטראקציה קודמת. בלי הידע המוקדם הזה, WebView משתמש ב-HTTP/2 או ב-HTTP/1.1 לחיבור הראשוני.

התקשרות addQuicHints מאכלסת מראש את פרטי התמיכה בפרוטוקול, ומאפשרת ל-WebView להתחבר באמצעות QUIC באופן מיידי בחיבור הראשון למקורות שצוינו.

קישור מקדים עם רמזים של QUIC

גם רמזים לקישור מקדים וגם רמזים ל-QUIC הם אופטימיזציות ברמת המקור ב-Profile, אבל הם ממלאים תפקידים שונים ומשלימים:

• ‫preconnect: פותח באופן פעיל חיבור לרשת (חיפוש DNS ו-TCP/TLS או לחיצת יד של QUIC) ומקיים אותו למשך כ-30 שניות. הוא צורך משאבי מכשיר ורשת כי הוא מחזיק חיבורים פעילים לרשת פתוחים, ולכן צריך להשתמש בו רק כשסביר מאוד שהיעד הוא מקור.
• ‫addQuicHints: לא גורם לתנועת רשת מיידית. היא מעדכנת את מאפייני השרת בזיכרון של Profile מחסנית הרשת כדי לתעד את התמיכה בפרוטוקול. מכיוון שהתקורה שלו זניחה, אפשר להגדיר בבטחה רמזים ל-QUIC במהלך הפעלת האפליקציה לכל המקורות הידועים שתומכים ב-HTTP/3.

כדי לקבל ביצועים אופטימליים, מומלץ להתקשר למספר addQuicHints לפני שמתקשרים למספר preconnect,‏ prefetchUrlAsync או loadUrl. כך מובטח שכל בקשות הדפים או בקשות החיבור מראש הבאות ינהלו משא ומתן על HTTP/3 מההתחלה.

הטמעה

כדי להגדיר רמזים ל-QUIC, מתקשרים אל addQuicHints(Set<String> urls) במופע Profile. צריך לקרוא לממשק ה-API הזה בשרשור UI ולוודא ש-WebView תומך בתכונה WebViewFeature.ADD_QUIC_HINTS_V1.

בדומה ל-preconnect, ‏ addQuicHints פועלת על מקורות, אבל אפשר לספק כתובות URL מלאות (כמו https://www.example.com/index.html) והן עוברות נורמליזציה אוטומטית למקור שלהן (https://www.example.com).

השיטה היא מצטברת: אם קוראים לה כמה פעמים, המקורות שסופקו ימוזגו ב-Profile.

// Must be called on the @UiThread
@OptIn(Profile.ExperimentalAddQuicHints::class)
if (WebViewFeature.isFeatureSupported(WebViewFeature.ADD_QUIC_HINTS_V1)) {
    val quicOrigins = setOf(
        "https://www.example.com",
        "https://api.example.com"
    )
    profile.addQuicHints(quicOrigins)
    // WebView now prioritizes HTTP/3 over QUIC for connections to these origins
}

// Must be called on the @UiThread
// Requires @Profile.ExperimentalAddQuicHints annotation or suppression
if (WebViewFeature.isFeatureSupported(WebViewFeature.ADD_QUIC_HINTS_V1)) {
    Set<String> quicOrigins = new HashSet<>(Arrays.asList(
        "https://www.example.com",
        "https://api.example.com"
    ));
    profile.addQuicHints(quicOrigins);
    // WebView now prioritizes HTTP/3 over QUIC for connections to these origins
}

הגדרה נפוצה: PrefetchParameters ו-PrerenderParameters

התכונות 'טעינה מראש' ו'עיבוד מראש' משתמשות ב-PrefetchParameters או ב-PrerenderParameters כדי להתאים אישית את הבקשה. המחלקות האלה מאפשרות לספק כותרות והצעות נוספות להתאמה של כתובות URL, כמו הגדרות No-Vary-Search.

// Isolated configuration specifically for Cache-Level Prefetching
val prefetchParams = PrefetchParameters.Builder()
    .addAdditionalHeader("X-Custom-Client", "Android-App-V2")
    .setExpectedNoVarySearchHeader(
        NoVarySearchHeader.varyExcept(true, listOf("session_id", "click_ref"))
    )
    .build()

PrefetchParameters prefetchParams = new PrefetchParameters.Builder()
    .addAdditionalHeader("X-Custom-Header", "value")
    /**
     * Hint to ignore specific query parameters during cache matching.
     * This allows the cache to match even if the tracking_id differs.
     */
    .setExpectedNoVarySearchHeader(
        NoVarySearchHeader.varyExcept(true, Arrays.asList("tracking_id"))
    )
    /**
     * Determines if Client Hints are sent.
     * NOTE: This is ignored for Prerendering API requests, which default to
     * the WebView's WebSettings.getJavaScriptEnabled() value.
     */
    .setJavaScriptEnabled(true)
    .build();

שליפה מראש של תוכן

הורדה מראש (prefetching) מורידה את משאב ה-HTML הראשי של כתובת URL ומאחסנת אותו במטמון הרשת של הפרופיל. ב-WebView, רכיב Profile משמש כמאגר לנתוני הדפדפן, כולל קובצי Cookie, מטמון HTTP ועובדי שירות. מכיוון ש-prefetch היא פעולה ברמת הפרופיל, כל WebView שמשויך לפרופיל הזה יכול להשתמש בתגובה שנשמרה במטמון.

הטמעה

כדי להפעיל אחזור מראש, קוראים ל-prefetchUrlAsync() במופע Profile. הפעולה הזו תומכת רק בסכימת HTTPS.

profile.prefetchUrlAsync(
    url,
    prefetchParams,
    cancellationSignal,
    executor,
    object : WebViewOutcomeReceiver<PrefetchResult, PrefetchException> {
        override fun onResult(result: PrefetchResult) {
            if (result.wasDuplicate()) {
                // URL and No-Vary-Search permutations already exist in the cache layer
            } else {
                // The HTML payload has been successfully secured in the HTTP cache
            }
        }

        override fun onError(error: PrefetchException) {
            when (error) {
                is PrefetchNetworkException -> {
                    // Isolates network layer or server-side HTTP anomalies
                    val code = error.httpStatusCode
                    // Facilitates rapid diagnosis of 4xx or 5xx server responses
                }
                else -> {
                    // Catches generalized execution failures and system constraints
                }
            }
        }
    }
)

profile.prefetchUrlAsync(
    url,
    prefetchParams,
    cancellationSignal,
    executor,
    new WebViewOutcomeReceiver<PrefetchResult, PrefetchException>() {
        @Override
        public void onResult(PrefetchResult result) {
            if (result.wasDuplicate()) {
                // URL and No-Vary-Search permutations already exist in the cache layer
            } else {
                // The HTML payload has been successfully secured in the HTTP cache
            }
        }

        @Override
        public void onError(PrefetchException error) {
            if (error instanceof PrefetchNetworkException) {
                // Isolates network layer or server-side HTTP anomalies
                int code = ((PrefetchNetworkException) error).httpStatusCode;
                // Facilitates rapid diagnosis of 4xx or 5xx server responses
            } else {
                // Catches generalized execution failures and system constraints
            }
        }
    }
);

מחזור החיים של חטיפת מסירה

בקשת האחזור מראש של WebView משנה את התזמון והאופן שבהם מופעלת shouldInterceptRequest() הקריאה החוזרת. ההבנה של מחזור החיים בן שני השלבים היא קריטית, כי הוא משפיע ישירות על השימוש המוצלח בתוכן שאוחזר מראש:

1. השלב הספקולטיבי (בקשת שליפה מראש)

כשמפעילים את prefetchUrlAsync(), ‏ WebView מוריד את משאב ה-HTML הראשי ברקע. הבקשה הזו ברקע מדלגת לחלוטין על shouldInterceptRequest(). לוגיקה מותאמת אישית, טוקנים של הרשאות או הוספות של כותרות שבדרך כלל מטופלים בתוך ה-interceptor לא מוחלים על משאב ה-HTML שנשלף מראש.

2. שלב הניווט (הפעלה על ידי המשתמש)

כשהאפליקציה מנווטת באופן מפורש לכתובת ה-URL (לדוגמה, באמצעות WebViewCompat.navigate או loadUrl) או כשהמשתמש לוחץ על קישור תואם, WebView קובע אם אפשר להשתמש במטמון שאוחזר מראש:

• הערכת ה-HTML הראשי: בשלב הזה, WebView יפעיל את shouldInterceptRequest() עבור ה-HTML הראשי. כדי שהדף יוצג בהצלחה ממטמון האחזור המקדים, ה-interceptor צריך להחזיר את הערך null. אם מחזירים WebResourceResponse מותאם אישית, WebView מכבד את ה-interceptor ומדלג לחלוטין על מטמון האחזור מראש.

• הערכת משאבי משנה: אחרי שמתקבל אישור לשימוש ב-HTML שנשלף מראש, shouldInterceptRequest() מופעל בדרך כלל לכל משאבי המשנה הבאים (כמו תמונות, סקריפטים ו-CSS) שנדרשים כדי לסיים את הרינדור של הדף.

התנהגויות מרכזיות

המאפיינים התפעוליים והבדיקות הבאים של הזכאות קובעים איך WebView יוזם ומנהל בקשות לאחזור מראש:

• בטיחות השרשור: אפשר לשלוח בקשות מכל שרשור.
• דרישות הסף: לפני הפעלת האחזור, WebView מוודא שהבקשה בטוחה ומתאימה מבחינת ההקשר על ידי בדיקת הנקודות הבאות:
  • קובצי Cookie קיימים: כדי להגן על פרטיות המשתמשים ולמנוע תופעות לוואי דומות ל-CSRF, יכול להיות ש-WebView ידלג על אחזור מראש אם הבקשה דורשת קובצי Cookie מאומתים ספציפיים שיכולים להפעיל שינוי מצב בשרת.
  • קובץ שירות (service worker) קיים: אם קובץ שירות כבר שולט בטווח של כתובת ה-URL, ‏ WebView יכול להעביר את הטיפול למטפל בשליפה של קובץ השירות במקום ליזום שליפה מראש רגילה מהרשת.
  • זמינות שרת ה-proxy: כדי למנוע כשל בבקשות ספקולטיביות בתצורות רשת מורכבות, WebView מוודא שנתיב הרשת הנוכחי (כולל שרתי proxy מוגדרים) יציב.
• אם לא מתבצעת אחזור מראש (גם אם הפרמטרים תקינים), זה קורה בדרך כלל כי WebView קבע שבקשת רקע עלולה להפריע לסשן הנוכחי של המשתמש או למצב האבטחה.
• ביטול: משתמשים ב-CancellationSignal כדי להפסיק בקשה שנמצאת בתהליך ולמנוע את השמירה שלה במטמון.

רינדור מראש של דפים

הרינדור המקדים יוצר 'תוכן אינטרנט' מוסתר כדי לרנדר דף באופן מלא ברקע, כולל הפעלת סקריפטים ואחזור משאבי משנה. הטכנולוגיה של רינדור מראש מסתמכת על אותה תשתית בסיסית כמו שליפה מראש (prefetch). אם אפליקציה מתחילה טרום-עיבוד, WebView מבצע קודם אחזור מראש של התגובה כדי להציג את הניווט של הטרום-עיבוד, וכך נמנעת פעילות מיותרת ברשת.

הטמעה

רינדור מראש הוא פעולה ברמת המופע של WebView. התקשרות אל prerenderUrlAsync() באמצעות WebViewCompat משרשור UI.

WebViewCompat.prerenderUrlAsync(
    webView,
    url,
    cancellationSignal,
    executor,
    params,
    object : PrerenderOperationCallback {
        override fun onPrerenderActivated() {
            // Called when the user navigates to the URL and the hidden page is swapped in
        }

        override fun onError(exception: Throwable) {
            // exception is an instance of PrerenderException
            // Handle prerender failure (for example, memory pressure or disallowed JavaScript APIs)
        }
    }
)

WebViewCompat.prerenderUrlAsync(webView, url, cancellationSignal, executor, params, new PrerenderOperationCallback() {
    @Override
    public void onPrerenderActivated() {
        // Called when the user navigates to the URL and the hidden page is swapped in.
    }

    @Override
    public void onError(@NonNull Throwable exception) {
        // Handle prerender failure (for example, resource constraints or disallowed APIs).
    }
});

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

מגבלות טכניות

כדי לאזן בין ניווט מיידי לבין תקינות המערכת, WebView אוכף את האילוצים הבאים בזמן הריצה:

• עומס על הזיכרון: אם במכשיר יש מעט זיכרון RAM,‏ WebView מבטל כתובות URL שעברו רינדור מראש.
• ממשקי API אסורים: כל ניסיון של JavaScript לגשת לממשקי API מסוימים (לדוגמה, הפעלת אודיו, התראות) בהקשר של רקע יגרום להפסקת הטרום-עיבוד באופן מיידי.
• מגבלת מופעים: יש מגבלה על מספר כתובות ה-URL הפעילות שעברו רינדור מראש שמותרות לכל WebView.

התאמה של כתובות URL ו-No-Vary-Search ‏ (NVS)

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

התאמה מדויקת לעומת התאמה לגרסה קרובה

כברירת מחדל, כדי להשתמש בטכנולוגיות של אחזור מראש וטרום-עיבוד, צריך שתהיה התאמה מדויקת של כתובת ה-URL. אם כתובת ה-URL שאליה מועברים זהה לכתובת ה-URL שנטענה מראש, היא מוגשת מהמטמון באופן מיידי. אם פרמטרים של שאילתות שונים, WebView משתמש בכללי No-Vary-Search (NVS) הבאים:

• ההצעה: המפתחים מספקים הצעה setExpectedNoVarySearchHeader() במהלך ההפעלה. אם כתובת ה-URL שאליה מנווטים תואמת לכתובת ה-URL של הבקשה ללא הפרמטרים של הרמזים, WebView נחסם לזמן קצר כדי להמתין לכותרות בפועל של השרת.
• כותרת השרת: כותרת התגובה של NVS מהשרת היא הסמכות הסופית. אם השרת מאשר שצריך להתעלם מההבדלים בשאילתה, התאמה מוגשת מהמטמון. אם לא, WebView חוזר לטעינה קרה של הרשת.

התכונה No-Vary-Search (NVS) מיועדת לשימוש מתקדם, ורוב המפתחים לא צריכים אותה כי הם מעבירים את אותה כתובת URL בדיוק גם לשליפה מראש וגם לניווט (WebViewCompat.navigate או loadUrl). ההנחיות האלה נחוצות רק אם יש הבדלים בפרמטרים של השאילתה בין כתובת ה-URL של השליפה מראש לבין כתובת ה-URL של הניווט.

הגדרות כלליות

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

// Configure prefetch cache limits
profile.prefetchCache.setMaxPrefetches(10)
profile.prefetchCache.setPrefetchTtlSeconds(60)

// Reset to system defaults when needed
profile.prefetchCache.clearMaxPrefetches()

// Configure maximum active prerenders
profile.setMaxPrerenders(2)

// Configure prefetch cache limits
PrefetchCache prefetchCache = profile.getPrefetchCache();
prefetchCache.setMaxPrefetches(10);
prefetchCache.setPrefetchTtlSeconds(60);

// Reset to system defaults when needed
prefetchCache.clearMaxPrefetches();

// Configure maximum active prerenders
profile.setMaxPrerenders(2);

טיפול בשגיאות ובחריגות

בפעולות ספקולטיביות נעשה שימוש ב-OutcomeReceiverCompat או ב-PrerenderOperationCallback כדי לדווח על התוצאות.

חריגים ראשיים

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

• ‫PrefetchException: מחלקת הבסיס לכל השגיאות של טעינה מראש אסינכרונית.
• ‫PrefetchNetworkException: מציין כשל ברמת הרשת או השרת. הוא יכול לכלול שדה httpStatusCode (למשל 404 או 503) שיעזור לאבחן בעיות בצד השרת.
• ‫PrerenderException: מחלקת העל של כל השגיאות שקשורות לעיבוד מראש, כמו כשלים בגלל עומס על הזיכרון או שימוש בממשקי API אסורים (כמו הפעלת אודיו) ברקע.

אסטרטגיות אופטימיזציה

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

• התחלה מוקדמת: מתחילים את האחזור מראש במהלך הפעלת האפליקציה או ברגע שסביר להניח שיוצג יעד ניווט.
• שילוב של רמזים ל-QUIC עם חימום מראש של חיבורים: קוראים ל-addQuicHints() לפני הפעלת preconnect(), prefetchUrlAsync() או ניווטים רגילים כדי לוודא ש-WebView מנסה ליצור חיבורים באמצעות HTTP/3.
• שיטה משולבת: אם מבצעים טרום-עיבוד של כתובת URL שכבר נמצאת במטמון של טרום-הבאות, הניווט של טרום-העיבוד מוגש מהמטמון הזה, וכך נמנעות בקשות רשת מיותרות.
• מעקב אחרי מכסות: טרום-עיבוד צורך הרבה משאבים. מומלץ להשתמש בשליפה מראש (prefetch) של כמה מועמדים סבירים ולשמור את הטכניקה של רינדור מראש לניווט הסביר ביותר.
• תמיכה בסכימה: חשוב לוודא שכל כתובות ה-URL משתמשות בסכימת HTTPS שהיא חובה. תוכניות לא תקינות או קלט ריק מפעילים IllegalArgumentException סינכרוני.

מקורות מידע נוספים

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

• ניווט משופר בדפים באמצעות השיטה WebViewCompat.navigate
• ניפוי באגים באפליקציות אינטרנט
• אופטימיזציה של הפעלת WebView
• טיפול בסיום של תהליך העיבוד של WebView