التحميل المبني على توقُّع في WebView

وقت استجابة التنقّل هو مقياس مهم لتجربة المستخدم. لمساعدة المطوّرين في تقليل وقت الاستجابة هذا، توفّر WebView واجهات برمجة تطبيقات للتحميل المبني على توقّع وتحسين الاتصال، ما يسمح لتطبيقك باسترداد المحتوى أو عرضه قبل أن ينتقل إليه المستخدم بشكل صريح.

يتوافق WebView مع ثلاثة أنواع أساسية من التحميل التخميني: Preconnect وPrefetch وPrerender، بالإضافة إلى تلميحات QUIC لتحسين عملية التفاوض على البروتوكول.

من خلال تنفيذ استراتيجية التحميل المبني على توقُّع، يمكنك تحقيق ما يلي:

  • تقليل كبير في وقت استجابة تحميل محتوى الويب: يمكنك نقل وقت بدء الشبكة إلى وقت أبكر في دورة حياة التطبيق واستخدام بروتوكولات أسرع مثل HTTP/3.
  • معدّلات نجاح أعلى في التنقّل: من خلال التسخين المُسبَق للشبكة وذاكرة التخزين المؤقت، يصبح من غير المرجّح أن يتعذّر التنقّل بسبب مشاكل عابرة في الشبكة.
  • سرعة استجابة أفضل: يتيح العرض المسبق، على وجه الخصوص، عمليات انتقال فورية تجعل التطبيق يبدو أسرع بكثير.

اختيار استراتيجية تحميل مبني على توقّع

يتمثّل الفرق الأساسي بين هاتين الاستراتيجيتين في نطاقهما: تستند واجهات برمجة التطبيقات الخاصة بتلميحات Preconnect وQUIC إلى المصدر، ما يعني أنّها تتطلّب النطاق المستهدف فقط. تستند واجهات برمجة التطبيقات الخاصة بجلب البيانات مسبقًا والعرض المسبق إلى عناوين URL، ما يعني أنّها تتطلّب مسار صفحة الويب الدقيق.

بما أنّ تلميحات Preconnect وQUIC تعمل على مستوى المصدر، يمكنك طلبها قبل معرفة المحتوى أو الصفحة المحدّدة التي سينتقل إليها المستخدم.

يقارن الجدول التالي بين هذه الاستراتيجيات الثلاث لمساعدتك في اختيار الاستراتيجية المناسبة لحالة الاستخدام:

الميزة الاتصال المُسبَق الجلب المُسبَق العرض المُسبَق
الهدف الأساسي تجهيز الاتصال تخزين ملف HTML مؤقتًا فقط (بدون JavaScript أو CSS) العرض المسبق للصفحة بأكملها
النطاق مستوى الملف الشخصي (تتم مشاركته في جميع عروض الويب) مستوى الملف الشخصي (تتم مشاركته في جميع عروض الويب) مستوى WebView (مرتبط بمكوّن WebView معيّن)
Jetpack WebKit API androidx.webkit.Profile androidx.webkit.Profile androidx.webkit.WebViewCompat
طُرق واجهة برمجة التطبيقات الأساسية preconnect(...) prefetchUrlAsync(...) prerenderUrlAsync(...)
الإعداد لا ينطبق PrefetchCache.setMaxPrefetches()
PrefetchCache.setPrefetchTtlSeconds()
setMaxPrerenders()
استخدام الموارد منخفض (الشبكة) متوسط (الشبكة والذاكرة) عالية (وحدة المعالجة المركزية والذاكرة والشبكة)
حالات الاستخدام عندما يكون المصدر المستهدف معروفًا، ولكن لم يتم تحديد عنوان URL المحدّد بعد. عندما يكون عنوان URL الدقيق معروفًا ومن المحتمل أن يتم الانتقال إليه، مع مشاركة التخزين المؤقت بين WebViews عندما يكون عنوان URL الدقيق معروفًا ويكون التنقّل مؤكّدًا إلى حد كبير ضِمن WebView معيّن
المزايا إعداد اتصال أسرع لأي عنوان URL على المصدر تحميل أسرع للشبكة لعناوين URL المطابقة تنقّل فوري عند التفعيل

إنشاء اتصال مُسبَق بالمصادر

تؤدي عملية الربط المُسبَق إلى تسريع عمليات التحميل المستقبلية من خلال إجراء عمليات بحث نظام أسماء النطاقات (DNS) وعمليات تأكيد اتصال بروتوكول TCP/TLS أو QUIC بشكل استباقي لمصدر محدّد.

على عكس ميزتَي "الجلب المُسبَق" و"العرض المُسبَق" اللتين تتطلّبان عنوان URL دقيقًا للوجهة، تستند ميزة "الاتصال المُسبَق" إلى المصدر فقط. يتيح لك ذلك طلب Preconnect قبل معرفة عنوان URL الدقيق. للحصول على إرشادات حول وقت استدعاء هذه الدالة، اطّلِع على النصيحة في قسم التنفيذ.

تؤدي هذه الاستراتيجية التي لا تستهلك الكثير من الموارد وعلى مستوى الملف الشخصي إلى تقليل وقت الاستجابة الأوّلي لأي مشاركة في WebView لهذا الملف الشخصي، شرط ألا يكون قد تم الانتقال إلى المصدر من قبل. يبقى الاتصال مفتوحًا لمدة 30 ثانية تقريبًا، ما يتيح الاستفادة من أي طلبات HTTP أو عمليات تنقّل أو موارد فرعية لاحقة متعدّدة المصادر من خلال إلغاء عبء عملية المصافحة. يتم تخزين نتيجة بحث نظام أسماء النطاقات مؤقتًا لمدة أطول من مدة الاتصال، لذا يمكن للطلبات اللاحقة إلى المصدر تخطّي البحث حتى بعد إغلاق الاتصال.

التنفيذ

لبدء عملية ربط مسبق، اتّصِل بـ preconnect(String url) على مثيل Profile. يجب طلب البيانات من واجهة برمجة التطبيقات هذه في سلسلة التعليمات الخاصة بواجهة المستخدم، ويجب أن تكون السمة WebViewFeature.PRECONNECT متاحة.

تعمل واجهة برمجة التطبيقات على المصدر، ولكن لتسهيل الأمر، يمكن تقديم عنوان URL كامل (مثل https://www.example.com/index.html). ويتم تلقائيًا التعامل مع هذا العنوان على أنّه طلب بيانات من المصدر (على سبيل المثال، https://www.example.com). ويمكن ربط مصادر متعددة من خلال طلب بيانات من واجهة برمجة التطبيقات هذه عدة مرات.

Kotlin

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

Java

// 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، بما في ذلك عمليات المصافحة التي لا تستغرق وقتًا، وتحسين مرونة الاتصال، وإزالة الحظر في مقدّمة الصف أثناء فقدان الحِزم.

بشكلٍ تلقائي، لا يحاول WebView إنشاء اتصال QUIC إلا إذا كان لديه إشارة إلى أنّ المصدر يتيح استخدام QUIC، مثل عنوان Alt-Svc أو سجل HTTPS لنظام أسماء النطاقات (DNS) من تفاعل سابق. وبدون هذه المعرفة المسبقة، يستخدم 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. يجب استدعاء واجهة برمجة التطبيقات هذه في سلسلة التعليمات الخاصة بواجهة المستخدم والتأكّد من أنّ WebView تتوافق مع ميزة WebViewFeature.ADD_QUIC_HINTS_V1.

على غرار preconnect، تعمل addQuicHints على المصادر، ولكن يمكن تقديم عناوين URL كاملة (مثل https://www.example.com/index.html) ويتم تلقائيًا تحويلها إلى مصدرها (https://www.example.com).

الطريقة مضافة: يؤدي استدعاؤها عدة مرات إلى دمج المصادر المقدَّمة في جميع Profile.

Kotlin

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

Java

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

Kotlin

// 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()

Java

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 كحاوية لبيانات المتصفّح، بما في ذلك ملفات تعريف الارتباط وذاكرة التخزين المؤقت لبروتوكول HTTP وخدمات الخلفية. بما أنّ عملية الجلب المسبق تتم على مستوى الملف الشخصي، يمكن لأي WebView مرتبط بهذا الملف الشخصي الاستفادة من الرد المخزّن مؤقتًا.

التنفيذ

لبدء عملية الجلب المسبق، استدعِ الدالة prefetchUrlAsync() على مثيل Profile. لا تتوافق هذه العملية إلا مع مخطّط HTTPS.

Kotlin

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

Java

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() الدالة التنفيذية. بما أنّ ذلك يؤثر بشكل مباشر في إمكانية استخدام المحتوى الذي تم جلبه مسبقًا بنجاح، من المهم فهم دورة الحياة المكوّنة من خطوتَين:

مخطّط بياني يوضّح دورة حياة اعتراض جلب البيانات المسبق في WebView على خطوتَين
  أثناء مرحلتَي التخمين والتنقّل
الشكل 1. دورة حياة الاعتراض المكوّنة من خطوتَين لطلبات الجلب المسبق وعمليات التنقّل في WebView

1. مرحلة التخمين (طلب الجلب المسبق)

عند استدعاء prefetchUrlAsync()، ينزّل WebView مورد HTML الرئيسي في الخلفية. يتم تخطّي shouldInterceptRequest() بالكامل لهذا الطلب الذي يتم تنفيذه في الخلفية. لا يتم تطبيق أي منطق مخصّص أو رموز مميّزة للتفويض أو عمليات إدخال في الرأس يتم عادةً التعامل معها داخل أداة الاعتراض على مصدر HTML الذي تم جلبه مسبقًا.

2. مرحلة التنقّل (تفعيل المستخدم)

عندما ينتقل التطبيق صراحةً إلى عنوان URL (على سبيل المثال، باستخدام WebViewCompat.navigate أو loadUrl) أو ينقر المستخدم على رابط مطابق، يحدّد WebView ما إذا كان بإمكانه استخدام ذاكرة التخزين المؤقت التي تم جلبها مسبقًا:

  • تقييم ملف HTML الرئيسي: سيؤدي WebView إلى تشغيل shouldInterceptRequest() لملف HTML الرئيسي في هذه المرحلة. لعرض الصفحة بنجاح من ذاكرة التخزين المؤقت للجلب المسبق، يجب أن يعرض برنامج الاعتراض null. في حال إرجاع WebResourceResponse، يحترم WebView أداة الاعتراض ويتجاهل تمامًا ذاكرة التخزين المؤقت المسبق.

  • تقييم الموارد الفرعية: بعد إزالة علامة الحظر عن رمز HTML الذي تمّت جلب بياناته مسبقًا، يتم تشغيل shouldInterceptRequest() بشكل طبيعي لجميع الموارد الفرعية اللاحقة (مثل الصور والنصوص البرمجية وCSS) المطلوبة لإنهاء عرض الصفحة.

السلوكيات الرئيسية

تتحكّم الخصائص التشغيلية وعمليات التحقّق من الأهلية التالية في طريقة بدء WebView لطلبات الجلب المسبق وإدارتها:

  • أمان سلاسل المحادثات: يمكن بدء الطلبات من أي سلسلة محادثات.
  • الأهلية: قبل بدء عملية الجلب، تتأكّد WebView من أنّ الطلب آمن ومناسب سياقيًا من خلال التحقّق من ما يلي:
    • ملفات تعريف الارتباط الحالية: لحماية خصوصية المستخدم ومنع الآثار الجانبية المشابهة لهجمات CSRF، قد تتخطى WebView عملية الجلب المسبق إذا كان الطلب يتطلّب ملفات تعريف ارتباط محدّدة مصادَق عليها يمكن أن تؤدي إلى تغيير الحالة على الخادم.
    • توفّر مشغّل الخدمات: إذا كان مشغّل الخدمات يتحكّم حاليًا في نطاق عنوان URL، يمكن أن يؤجّل WebView عملية الجلب إلى معالج الجلب الخاص بمشغّل الخدمات بدلاً من بدء عملية جلب مسبق عادية من الشبكة.
    • توفر الخادم الوكيل: تتحقّق WebView من أنّ مسار الشبكة الحالي (بما في ذلك أي خوادم وكيلة تم إعدادها) ثابت لتجنُّب تعذُّر الطلبات التخمينية في إعدادات الشبكة المعقّدة.
  • إذا تعذّر بدء عملية الجلب المسبق (حتى مع توفّر مَعلمات صالحة)، يكون السبب غالبًا أنّ WebView قد حدّد أنّ طلبًا في الخلفية قد يتعارض مع جلسة المستخدم الحالية أو حالة الأمان.
  • الإلغاء: استخدِم CancellationSignal لإنهاء طلب قيد التنفيذ ومنع تخزينه مؤقتًا.

العرض المُسبَق للصفحات

تؤدي عملية العرض المسبق إلى إنشاء "محتوى ويب" مخفي لعرض صفحة بالكامل في الخلفية، بما في ذلك تنفيذ النصوص البرمجية واسترداد الموارد الفرعية. تعتمد عملية العرض المسبق على البنية الأساسية نفسها التي تعتمد عليها عملية الجلب المسبق. إذا بدأ تطبيق عملية العرض المسبق، سيجري WebView أولاً عملية جلب مسبق للردّ من أجل عرض عملية التنقّل المسبق، ما يؤدي إلى تجنُّب النشاط المتكرّر على الشبكة.

التنفيذ

التحميل المسبق هو عملية على مستوى مثيل WebView. استدعِ الدالة prerenderUrlAsync() باستخدام WebViewCompat من سلسلة التعليمات الخاصة بواجهة المستخدم.

Kotlin

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

Java

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) في الجهاز منخفضة.
  • واجهات برمجة التطبيقات غير المسموح بها: أي محاولات من JavaScript للوصول إلى واجهات برمجة تطبيقات معيّنة (مثل تشغيل الصوت والتنبيهات) في سياق الخلفية ستؤدي فورًا إلى إنهاء عملية العرض المسبق.
  • الحدّ الأقصى لعدد المثيلات: هناك حدّ أقصى لعدد عناوين URL النشطة التي تم عرضها مسبقًا والمسموح بها لكل WebView.

مطابقة عناوين URL وNo-Vary-Search (NVS)

تتطلّب WebView خوارزمية مطابقة موثوقة لضمان عدم عرض المورد المحمَّل مسبقًا إلا عند التنقّل إلى الصفحة المقصودة.

المطابقة التامة مقابل المطابقة مع NVS

بشكلٍ تلقائي، تتطلّب ميزتا "الجلب المسبق" و"العرض المسبق" مطابقة تامة لعنوان 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 الحدود والحد الأقصى لعمليات العرض المسبق. يمكنك أيضًا إعادة ضبط حدود الجلب المسبق المخصّصة إلى الإعدادات التلقائية للنظام:

Kotlin

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

Java

// 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: الفئة الرئيسية لجميع الأخطاء ذات الصلة بالعرض المسبق، مثل حالات التعذّر بسبب ضغط الذاكرة أو استخدام واجهات برمجة تطبيقات غير مسموح بها (مثل تشغيل الصوت) في الخلفية.

استراتيجيات التحسين

اتّبِع هذه الاقتراحات للاستفادة إلى أقصى حدّ من مزايا التحميل المبني على توقّع مع الحفاظ على موارد النظام:

  • البدء مبكرًا: ابدأ في الجلب المسبق للبيانات أثناء بدء تشغيل التطبيق أو بمجرد أن تصبح وجهة التنقّل محتملة.
  • إقران تلميحات QUIC بعملية التسخين المُسبَق للاتصال: استدعِ addQuicHints() قبل بدء عمليات التنقّل preconnect() أو prefetchUrlAsync() أو عمليات التنقّل العادية لضمان محاولة WebView إنشاء اتصالات باستخدام HTTP/3.
  • استراتيجية مدمجة: إذا كنت تجري عملية العرض المسبق لعنوان URL سبق أن تم تخزينه في ذاكرة التخزين المؤقت للجلب المسبق، سيتم عرض عملية التنقّل التي تم عرضها مسبقًا من ذاكرة التخزين المؤقت هذه، ما يؤدي إلى تجنُّب طلبات الشبكة المكرّرة.
  • مراقبة الحصص: تتطلّب عملية العرض المسبق الكثير من الموارد. يُفضَّل استخدام ميزة &quot;الجلب المسبق&quot; لعدة صفحات محتملة، واستخدام ميزة &quot;العرض المسبق&quot; لصفحة واحدة فقط من المرجّح الانتقال إليها.
  • التوافق مع نظام العناوين: تأكَّد من أنّ جميع عناوين URL تستخدم نظام HTTPS الإلزامي. تؤدي المخططات غير الصالحة أو المدخلات الفارغة إلى تشغيل IllegalArgumentException متزامن.

مراجع إضافية

لمزيد من المعلومات حول تصحيح أخطاء تطبيقات الويب وتحسين أداء بدء تشغيل WebView والتعامل مع إنهاء عملية العرض، يُرجى الاطّلاع على المراجع التالية: