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

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

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

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

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

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

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

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

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

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

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

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

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

הטמעה

כדי ליזום חיבור מראש, מתקשרים אל 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 או מרשומה HTTPS של DNS מאינטראקציה קודמת. בלי הידע המוקדם הזה, WebView משתמש ב-HTTP/2 או ב-HTTP/1.1 לחיבור הראשוני.

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

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

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

• ‫preconnect: פותח באופן פעיל חיבור לרשת ושומר עליו (חיפוש DNS ולחיצת יד (handshake) ב-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

גם Prefetch וגם Prerender משתמשים ב-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();

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

טעינה מראש מורידה את משאב ה-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() callback. ההבנה של מחזור החיים הדו-שלבי הזה היא קריטית, כי הוא משפיע ישירות על השימוש המוצלח בתוכן שאוחזר מראש.

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: אם Service Worker כבר שולט בהיקף של כתובת ה-URL, ‏ WebView יכול לדחות את הטיפול בבקשת השליפה ל-Service Worker במקום ליזום שליפה מראש רגילה מהרשת.
  • זמינות שרת 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() משרשור ממשק המשתמש.

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

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

• עומס על הזיכרון: WebView מבטל כתובות URL שעברו רינדור מראש אם כמות ה-RAM במכשיר נמוכה.
• ממשקי 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 שהיא חובה. סכימות לא תקינות או קלט null מפעילים IllegalArgumentException סינכרוני.

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

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

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