WebView में अनुमान के हिसाब से यूआरएल लोड होने की सुविधा

नेविगेशन में लगने वाला समय, उपयोगकर्ता के अनुभव के लिए एक अहम मेट्रिक है. डेवलपर को इस इंतज़ार के समय को कम करने में मदद करने के लिए, WebView में अनुमान के हिसाब से यूआरएल लोड होने की सुविधा के लिए एपीआई उपलब्ध हैं. इनकी मदद से, आपका ऐप्लिकेशन, उपयोगकर्ता के किसी कॉन्टेंट या पेज पर जाने से पहले ही उसे फ़ेच या रेंडर कर सकता है.

वेबव्यू में, अनुमान के हिसाब से यूआरएल लोड होने की सुविधा के तीन मुख्य टाइप उपलब्ध हैं: पहले से कनेक्ट करना, प्रीफ़ेच करना, और पहले से रेंडर करना.

अनुमान के हिसाब से यूआरएल लोड होने की सुविधा की रणनीति लागू करके, ये फ़ायदे पाए जा सकते हैं:

• वेब कॉन्टेंट लोड होने में लगने वाले समय में काफ़ी कमी: नेटवर्क शुरू होने का समय, ऐप्लिकेशन की लाइफ़साइकल में पहले ही सेट करें.
• नेविगेशन की सफलता दर ज़्यादा होना: नेटवर्क और कैश मेमोरी को पहले से तैयार करके रखने पर, नेटवर्क से जुड़ी अस्थायी समस्याओं की वजह से नेविगेशन के फ़ेल होने की संभावना कम हो जाती है.
• बेहतर रिस्पॉन्सिवनेस: खास तौर पर, प्रीरेंडरिंग की सुविधा से, तुरंत ट्रांज़िशन किए जा सकते हैं. इससे ऐप्लिकेशन की स्पीड काफ़ी बढ़ जाती है.

अनुमान के हिसाब से यूआरएल लोड होने की सुविधा की रणनीति चुनें

इन रणनीतियों के बीच मुख्य अंतर, इनके स्कोप में है: Preconnect API, ऑरिजिन पर आधारित है. इसका मतलब है कि इसके लिए सिर्फ़ टारगेट डोमेन की ज़रूरत होती है. Prefetch और Prerender API, यूआरएल पर आधारित हैं. इसका मतलब है कि इनके लिए वेबपेज का सटीक पाथ ज़रूरी है.

Preconnect, ऑरिजिन लेवल पर काम करता है. इसलिए, इसे ऐप्लिकेशन की लाइफ़साइकल में पहले ही शुरू किया जा सकता है. यहां तक कि आपको यह पता होने से पहले कि उपयोगकर्ता किस कॉन्टेंट या पेज पर जाएगा.

नीचे दी गई टेबल में, इन तीनों रणनीतियों की तुलना की गई है. इससे आपको अपने इस्तेमाल के हिसाब से सही रणनीति चुनने में मदद मिलेगी:

ऑरिजिन से पहले से कनेक्ट करना

पहले से कनेक्ट करने की सुविधा, किसी तय ऑरिजिन के लिए डीएनएस लुकअप और टीसीपी/टीएलएस हैंडशेक पहले से करके, आने वाले समय में लोड होने की स्पीड बढ़ाती है.

Prefetch और Prerender के उलट, जिनके लिए डेस्टिनेशन का सटीक यूआरएल ज़रूरी है, Preconnect पूरी तरह से ऑरिजिन पर आधारित है. इससे, Prefetch और Prerender की तुलना में, Preconnect कॉल को पहले ही किया जा सकता है.

प्रोफ़ाइल लेवल की यह रणनीति, कम संसाधनों का इस्तेमाल करती है. इससे, उस प्रोफ़ाइल को शेयर करने वाले किसी भी वेबव्यू के लिए, शुरुआती समय में लगने वाले समय को कम किया जा सकता है. हालांकि, इसके लिए यह ज़रूरी है कि ऑरिजिन पर पहले से विज़िट न किया गया हो. कनेक्शन करीब 30 सेकंड तक खुला रहता है. इससे, बाद के सभी क्रॉस-ऑरिजिन एचटीटीपी अनुरोधों, नेविगेशन या सब-रिसॉर्स को फ़ायदा मिलता है, क्योंकि इसमें हैंडशेक ओवरहेड नहीं होता.

लागू करना

पहले से कनेक्शन शुरू करने के लिए, Profile इंस्टेंस पर preconnect(String url) को कॉल करें. इस एपीआई को यूज़र इंटरफ़ेस (यूआई) थ्रेड पर कॉल किया जाना चाहिए. साथ ही, इसके लिए WebViewFeature.PRECONNECT की सुविधा उपलब्ध होनी चाहिए.

एपीआई, ऑरिजिन पर काम करता है. हालांकि, सुविधा के लिए पूरा यूआरएल दिया जा सकता है जैसे, https://www.example.com/index.html. इसे अपने-आप ऑरिजिन पर कॉल माना जाता है. जैसे, 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
}

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

सामान्य कॉन्फ़िगरेशन: PrefetchParameters और PrerenderParameters

Prefetch और Prerender, दोनों ही अनुरोध को पसंद के मुताबिक बनाने के लिए, PrefetchParameters या PrerenderParameters का इस्तेमाल करते हैं. इन क्लास की मदद से, यूआरएल मैचिंग के लिए अतिरिक्त हेडर और हिंट दिए जा सकते हैं. जैसे, 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();

कॉन्टेंट को प्रीफ़ेच करना

प्रीफ़ेच करने की सुविधा, किसी यूआरएल के मुख्य एचटीएमएल संसाधन को डाउनलोड करती है और उसे प्रोफ़ाइल की नेटवर्क कैश मेमोरी में सेव करती है. WebView में, Profile ब्राउज़र डेटा के लिए कंटेनर के तौर पर काम करता है. इसमें कुकी, एचटीटीपी कैश मेमोरी, और सर्विस वर्कर शामिल होते हैं. प्रीफ़ेच, प्रोफ़ाइल लेवल का ऑपरेशन है. इसलिए, उस प्रोफ़ाइल से जुड़ा कोई भी WebView, कैश मेमोरी में सेव किए गए रिस्पॉन्स का इस्तेमाल कर सकता है.

लागू करना

प्रीफ़ेच करने की सुविधा शुरू करने के लिए, Profile इंस्टेंस पर prefetchUrlAsync() को कॉल करें. यह ऑपरेशन सिर्फ़ एचटीटीपीएस स्कीम के साथ काम करता है.

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 बैकग्राउंड में मुख्य एचटीएमएल संसाधन डाउनलोड करता है. बैकग्राउंड में किए गए इस अनुरोध के लिए, shouldInterceptRequest() को पूरी तरह से स्किप कर दिया जाता है. प्रीफ़ेच किए गए एचटीएमएल संसाधन पर, कोई भी कस्टम लॉजिक, अनुमति के टोकन या हेडर इंजेक्शन लागू नहीं होते. आम तौर पर, इन्हें इंटरसेप्टर में मैनेज किया जाता है.

2. नेविगेशन का फ़ेज़ (उपयोगकर्ता की कार्रवाई)

जब ऐप्लिकेशन, यूआरएल पर जाता है (उदाहरण के लिए, loadUrl() का इस्तेमाल करके) या उपयोगकर्ता, मेल खाने वाले लिंक पर क्लिक करता है, तो WebView यह तय करता है कि वह प्रीफ़ेच की गई कैश मेमोरी का इस्तेमाल कर सकता है या नहीं:

• मुख्य एचटीएमएल का आकलन: इस समय, WebView मुख्य एचटीएमएल के लिए shouldInterceptRequest() को ट्रिगर करेगा. प्रीफ़ेच की गई कैश मेमोरी से पेज को दिखाने के लिए, आपके इंटरसेप्टर को null दिखाना होगा. अगर आपने कस्टम WebResourceResponse दिखाया है, तो WebView आपके इंटरसेप्टर का पालन करता है और प्रीफ़ेच की गई कैश मेमोरी को पूरी तरह से बाईपास कर देता है.

• सब-रिसॉर्स का आकलन: प्रीफ़ेच किए गए एचटीएमएल का इस्तेमाल करने के बाद, पेज को रेंडर करने के लिए ज़रूरी सभी सब-रिसॉर्स (जैसे, इमेज, स्क्रिप्ट, और सीएसएस) के लिए, shouldInterceptRequest() सामान्य तौर पर ट्रिगर होता है.

मुख्य व्यवहार

WebView, प्रीफ़ेच अनुरोधों को कैसे शुरू और मैनेज करता है, यह इन चीज़ों पर निर्भर करता है: ऑपरेशन से जुड़ी विशेषताएं और ज़रूरी शर्तें:

• थ्रेड की सुरक्षा: अनुरोध किसी भी थ्रेड से शुरू किए जा सकते हैं.
• ज़रूरी शर्तें: फ़ेच करने की सुविधा शुरू करने से पहले, WebView यह पक्का करता है कि अनुरोध सुरक्षित हो और कॉन्टेक्स्ट के हिसाब से सही हो. इसके लिए, वह इन चीज़ों की जांच करता है:
  • मौजूदा कुकी: उपयोगकर्ता की निजता की सुरक्षा करने और सीएसआरएफ़ जैसे साइड इफ़ेक्ट को रोकने के लिए, WebView प्रीफ़ेच करने की सुविधा को स्किप कर सकता है. ऐसा तब होता है, जब अनुरोध के लिए पुष्टि की गई खास कुकी की ज़रूरत होती है. इससे सर्वर पर स्थिति में बदलाव हो सकता है.
  • सर्विस वर्कर की मौजूदगी: अगर कोई सर्विस वर्कर, यूआरएल के स्कोप को पहले से कंट्रोल कर रहा है, तो WebView, स्टैंडर्ड नेटवर्क प्रीफ़ेच शुरू करने के बजाय, सर्विस वर्कर के फ़ेच हैंडलर पर निर्भर कर सकता है.
  • प्रॉक्सी की उपलब्धता: WebView यह पुष्टि करता है कि मौजूदा नेटवर्क पाथ (कॉन्फ़िगर की गई प्रॉक्सी भी शामिल है) स्थिर है, ताकि नेटवर्क के जटिल कॉन्फ़िगरेशन में, अनुमान के आधार पर किए गए अनुरोध फ़ेल न हों.
• अगर मान्य पैरामीटर होने के बावजूद, प्रीफ़ेच करने की सुविधा शुरू नहीं हो पाती है, तो इसकी वजह अक्सर यह होती है कि WebView ने यह तय किया है कि बैकग्राउंड में किया गया अनुरोध, उपयोगकर्ता के मौजूदा सेशन या सुरक्षा की स्थिति में दखल दे सकता है.
• रद्द करना: किसी अनुरोध को बीच में ही खत्म करने और उसे कैश मेमोरी में सेव होने से रोकने के लिए, CancellationSignal का इस्तेमाल करें.

पेजों को पहले से रेंडर करना

प्रीरेंडरिंग, बैकग्राउंड में किसी पेज को पूरी तरह से रेंडर करने के लिए, छिपे हुए "वेब कॉन्टेंट" बनाती है. इसमें स्क्रिप्ट का एक्ज़ीक्यूशन और सब-रिसॉर्स को फ़ेच करना शामिल है. पहले से रेंडर करने की सुविधा, प्रीफ़ेच करने की सुविधा के लिए इस्तेमाल किए जाने वाले इन्फ़्रास्ट्रक्चर पर निर्भर करती है. अगर कोई ऐप्लिकेशन, पहले से रेंडर करने की सुविधा शुरू करता है, तो WebView पहले रिस्पॉन्स को प्रीफ़ेच करता है, ताकि पहले से रेंडर किए गए नेविगेशन को दिखाया जा सके. इससे नेटवर्क की गतिविधि को बार-बार करने से बचा जा सकता है.

लागू करना

प्रीरेंडरिंग, WebView इंस्टेंस-लेवल का ऑपरेशन है. यूज़र इंटरफ़ेस (यूआई) थ्रेड से, WebViewCompat का इस्तेमाल करके prerenderUrlAsync() को कॉल करें.

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 पहले से रेंडर किए गए यूआरएल को रद्द कर देता है.
• अनुमति न दिए गए एपीआई: अगर JavaScript, बैकग्राउंड कॉन्टेक्स्ट में कुछ एपीआई (उदाहरण के लिए, ऑडियो चलाने, अलर्ट) को ऐक्सेस करने की कोशिश करता है, तो पहले से रेंडर करने की सुविधा तुरंत बंद हो जाएगी.
• इंस्टेंस की सीमा: हर WebView के लिए, पहले से रेंडर किए गए यूआरएल की संख्या की एक सीमा होती है.

यूआरएल मैचिंग और No-Vary-Search (NVS)

WebView को, मैचिंग के भरोसेमंद एल्गोरिदम की ज़रूरत होती है, ताकि यह पक्का किया जा सके कि पहले से लोड किया गया संसाधन, सिर्फ़ उसके लिए तय किए गए नेविगेशन के लिए दिखाया जाए.

एग्ज़ैक्ट मैच बनाम NVS मैच

डिफ़ॉल्ट रूप से, प्रीफ़ेच और पहले से रेंडर करने की सुविधा के लिए, यूआरएल का सटीक मैच होना ज़रूरी है. अगर नेविगेट किया गया यूआरएल, पहले से लोड किए गए यूआरएल जैसा ही है, तो उसे तुरंत कैश मेमोरी से दिखाया जाता है. अगर क्वेरी पैरामीटर अलग-अलग हैं, तो WebView, No-Vary-Search (NVS) के इन नियमों का इस्तेमाल करता है:

• हिंट: डेवलपर, शुरुआत के दौरान setExpectedNoVarySearchHeader() हिंट देते हैं. अगर नेविगेट किया गया यूआरएल, अनुरोध किए गए यूआरएल से मेल खाता है, लेकिन उसमें हिंट किए गए पैरामीटर शामिल नहीं हैं, तो WebView कुछ समय के लिए ब्लॉक हो जाता है, ताकि सर्वर के असली हेडर का इंतज़ार किया जा सके.
• सर्वर हेडर: सर्वर से मिला NVS रिस्पॉन्स हेडर, सबसे अहम होता है. अगर सर्वर पुष्टि करता है कि क्वेरी में अंतर को अनदेखा किया जाना चाहिए, तो मैच को कैश मेमोरी से दिखाया जाता है. अगर ऐसा नहीं होता है, तो WebView, नेटवर्क लोड पर वापस आ जाता है.

No-Vary-Search (NVS) का इस्तेमाल, ज़्यादा बेहतर तरीके से किया जाता है. ज़्यादातर डेवलपर को इसकी ज़रूरत नहीं होती, क्योंकि वे प्रीफ़ेच और loadUrl() दोनों के लिए एक ही यूआरएल पास करते हैं. यह दिशा-निर्देश सिर्फ़ तब ज़रूरी है, जब प्रीफ़ेच यूआरएल और loadUrl() यूआरएल के बीच क्वेरी पैरामीटर में अंतर हो.

ग्लोबल कॉन्फ़िगरेशन

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: यह पहले से रेंडर करने से जुड़ी सभी गड़बड़ियों के लिए सुपरक्लास है. जैसे, मेमोरी पर दबाव की वजह से या बैकग्राउंड में अनुमति न दिए गए एपीआई (जैसे, ऑडियो चलाने) का इस्तेमाल करने की वजह से होने वाली गड़बड़ियां.

ऑप्टिमाइज़ेशन की रणनीतियां

सिस्टम के संसाधनों को बचाते हुए, अनुमान के हिसाब से यूआरएल लोड होने की सुविधा के ज़्यादा से ज़्यादा फ़ायदे पाने के लिए, इन सुझावों का पालन करें:

• जल्दी शुरू करें: ऐप्लिकेशन शुरू होने के दौरान या नेविगेशन डेस्टिनेशन की संभावना होने पर, प्रीफ़ेच करने की सुविधा शुरू करें.
• इंटिग्रेटेड रणनीति: अगर आपने किसी ऐसे यूआरएल को पहले से रेंडर किया है जो पहले से ही प्रीफ़ेच की गई कैश मेमोरी में मौजूद है, तो पहले से रेंडर किया गया नेविगेशन, उस कैश मेमोरी से दिखाया जाता है. इससे नेटवर्क के अनुरोधों को बार-बार करने से बचा जा सकता है.
• कोटा की निगरानी करें: पहले से रेंडर करने की सुविधा में, ज़्यादा संसाधनों का इस्तेमाल होता है. कई संभावित यूआरएल के लिए, प्रीफ़ेच करने की सुविधा का इस्तेमाल करें. साथ ही, पहले से रेंडर करने की सुविधा को सिर्फ़ सबसे ज़्यादा संभावित नेविगेशन के लिए रिज़र्व करें.
• स्कीम की सुविधा: पक्का करें कि सभी यूआरएल, ज़रूरी एचटीटीपीएस स्कीम का इस्तेमाल करें. अमान्य स्कीम या नल इनपुट से, सिंक्रोनस IllegalArgumentException ट्रिगर होता है.

अन्य संसाधन

वेब ऐप्लिकेशन को डीबग करने, WebView के स्टार्टअप की परफ़ॉर्मेंस को ऑप्टिमाइज़ करने, और रेंडरर प्रोसेस के खत्म होने की समस्या को ठीक करने के बारे में ज़्यादा जानने के लिए, ये संसाधन देखें:

• वेब ऐप्लिकेशन डीबग करना
• WebView के स्टार्टअप को ऑप्टिमाइज़ करना
• WebView रेंडरर प्रोसेस के खत्म होने की समस्या को ठीक करना