‫Google برای ترجمه محتوا به زبان ترجیحی شما از فناوری هوشواره استفاده می‌کند. ترجمه‌های هوشواره‌ای ممکن است اشتباه داشته باشند.

بار کردن حدسی در «وب‌نما»

تأخیر در پیمایش سنجه‌ای حیاتی برای تجربه کاربری است. «وب‌نما» برای کمک به توسعه‌دهندگان در کاهش این تأخیر، میاناهای برنامه‌سازی کاربردی برای بار کردن حدسی و بهینه‌سازی اتصال ارائه می‌دهد که به برنامه شما امکان می‌دهد محتوا را قبل‌از اینکه کاربر به‌طور صریح به آن پیمایش کند واکشی یا پرداز کند.

«وب‌نما» از سه نوع اصلی بار کردن حدسی پشتیبانی می‌کند: «پیش‌اتصال»، «پیش‌دریافت»، و «پیش‌رندر»، به‌همراه نشانه‌های QUIC برای بهینه‌سازی مذاکره پروتکل.

با پیاده‌سازی استراتژی بار کردن حدسی، می‌توانید به موارد زیر دست یابید:

کاهش قابل‌توجه در تأخیر بار کردن محتوای وب: زمان شروع شبکه را به اوایل چرخه عمر برنامه منتقل کنید و از پروتکل‌های سریع‌تر مثل HTTP/3 استفاده کنید.
نرخ موفقیت بالاتر در پیمایش: با پیش‌گرم کردن شبکه و حافظه نهان، پیمایش‌ها کمتر به‌دلیل مشکلات شبکه موقت ناموفق می‌شوند.
واکنش‌گرایی بهتر درک‌شده: پیش‌پرداز به‌ویژه امکان انتقال‌های فوری را فراهم می‌کند که باعث می‌شود برنامه به‌طور قابل‌توجهی سریع‌تر به‌نظر برسد.

انتخاب استراتژی بار کردن حدسی

تفاوت اصلی بین این استراتژی‌ها در محدوده آن‌ها است: «میاناهای برنامه‌سازی کاربردی» پیش‌اتصال و نشانه‌های QUIC مبدأمحور هستند، یعنی فقط به دامنه مقصد نیاز دارند. «میاناهای برنامه‌سازی کاربردی پیش‌دریافت و پیش‌پرداز» براساس نشانی وب هستند، یعنی به مسیر دقیق صفحه وب نیاز دارند.

ازآنجایی‌که اشاره‌های «پیش‌اتصال» و QUIC در سطح مبدأ عمل می‌کنند، می‌توانید آن‌ها را قبل‌از اینکه بدانید کاربر به کدام محتوا یا صفحه خاص پیمایش خواهد کرد فراخوانی کنید.

جدول زیر این سه استراتژی را مقایسه می‌کند تا به شما کمک کند استراتژی مناسب را برای مورد استفاده خود انتخاب کنید:

ویژگی	پیش‌اتصال	پیش‌واکشی	پیش‌پرداززنی
هدف اصلی	گرم کردن اتصال	فقط HTML را در حافظه نهان ذخیره کنید (بدون جاوا اسکریپت یا CSS)	پیش‌پرداز کل صفحه
Scope	سطح نمایه (در سراسر WebViews هم‌رسانی می‌شود)	سطح نمایه (در سراسر WebViews هم‌رسانی می‌شود)	سطح «وب‌نما» (مربوط به «وب‌نمای» خاص)
Jetpack WebKit API	`androidx.webkit.Profile`	`androidx.webkit.Profile`	`androidx.webkit.WebViewCompat`
روش‌های اصلی میانای برنامه‌سازی کاربردی	`preconnect(...)`	`prefetchUrlAsync(...)`	`prerenderUrlAsync(...)`
پیکربندی	موجود نیست	`PrefetchCache.setMaxPrefetches()` `PrefetchCache.setPrefetchTtlSeconds()`	`setMaxPrerenders()`
استفاده از منبع	کم (شبکه)	متوسط (شبکه، حافظه)	بالا (واحد پردازش مرکزی، حافظه، شبکه)
زمان استفاده	وقتی مبدأ هدف مشخص است، اما نشانی وب خاص هنوز تعیین نشده است.	وقتی نشانی وب دقیق مشخص باشد و پیمایش محتمل باشد، با حافظه نهان هم‌رسانی‌شده در سراسر «نمای وب».	وقتی نشانی وب دقیق مشخص باشد و پیمایش در «وب‌نمای» خاصی بسیار مطمئن باشد.
مزایا	راه‌اندازی اتصال سریع‌تر برای هر نشانی وب در مبدأ	بار شبکه سریع‌تر برای نشانی‌های وب منطبق	ناوبری واقعاً فوری پس‌از فعال‌سازی

پیش‌اتصال به مبدأها

پیش‌اتصال با انجام پیش‌دستانه جستجوهای DNS و دست‌دهی‌های TCP/TLS یا QUIC برای مبدأ مشخص‌شده، بارگذاری‌های آینده را سرعت می‌بخشد.

برخلاف «واکشی اولیه» و «پیش‌پرداززنی» که به نشانی وب مقصد دقیق نیاز دارند، «پیش‌اتصال» کاملاً مبدأمحور است. این کار به شما امکان می‌دهد قبل‌از اینکه نشانی وب دقیق را بدانید، با «پیش‌اتصال» تماس بگیرید. برای راهنمایی درباره زمان فراخوانی آن، نکته موجود در بخش پیاده‌سازی را ببینید.

این استراتژی سطح «نمایه» با منابع کم، تأخیر اولیه را برای هر هم‌رسانی «نمای وب» که «نمایه» ارائه می‌دهد کاهش می‌دهد، به‌شرطی که قبلاً از مبدأ بازدید نشده باشد. اتصال تقریباً ۳۰ ثانیه باز می‌ماند و با حذف سربار دست دادن، به هرگونه درخواست HTTP بین مبدأ، پیمایش، یا منبع فرعی بعدی سود می‌رساند. نتیجه جستجوی ساناد برای مدت طولانی‌تری نسبت به اتصال ذخیره می‌شود، بنابراین درخواست‌های بعدی به مبدأ همچنان می‌توانند پس‌از بسته شدن اتصال از جستجو صرف‌نظر کنند.

پیاده‌سازی

برای شروع پیش‌اتصال، با preconnect(String url) در نمونه Profile تماس بگیرید. این «میانای برنامه‌سازی کاربردی» باید در رشته رابط کاربری فراخوانی شود و به پشتیبانی از 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
  }

با نشانه‌های QUIC، پشتیبانی از پروتکل QUIC را نشان دهید

‫HTTP/3 (که روی پروتکل انتقال QUIC اجرا می‌شود) نسبت‌به HTTP/2 بهبودهای قابل‌توجهی در تأخیر ارائه می‌دهد، ازجمله دست‌دهی ۰-RTT، بهبود انعطاف‌پذیری اتصال، و حذف مسدودسازی سرخط درطول ازدست رفتن بسته.

به‌طور پیش‌فرض، «وب‌نما» فقط درصورتی اتصال QUIC را امتحان می‌کند که نشانه‌ای داشته باشد که مبدأ از QUIC پشتیبانی می‌کند، مثلاً از سرصفحه Alt-Svc یا گزارش HTTPS ساناد از تعامل قبلی. بدون این دانش قبلی، WebView از HTTP/2 یا HTTP/1.1 برای اتصال اولیه استفاده می‌کند.

فراخوانی addQuicHints اطلاعات پشتیبانی از این پروتکل را ازقبل تکمیل می‌کند و به WebView اجازه می‌دهد تا در اولین اتصال به مبدأهای مشخص‌شده، بلافاصله بااستفاده از QUIC متصل شود.

پیش‌اتصال با اشاره‌های QUIC

اگرچه هر دو اشاره Preconnect و QUIC بهینه‌سازی‌های سطح مبدأ در Profile هستند، نقش‌های متمایز و مکملی دارند:

preconnect: اتصال شبکه (جستجوی ساناد و دست دادن TCP/TLS یا QUIC) را به‌طور فعال باز و برای تقریباً ۳۰ ثانیه حفظ می‌کند. چون اتصالات شبکه فعال باز را نگه می‌دارد، از منابع دستگاه و شبکه استفاده می‌کند و باید برای مبدأهای هدف با احتمال بالا رزرو شود.
addQuicHints: ترافیک شبکه فوری صفر را متحمل می‌شود. این ویژگی خصوصیت‌های سرور در حافظه پشته شبکه Profile را به‌روز می‌کند تا پشتیبانی از پروتکل را ثبت کند. ازآنجایی‌که سربار آن ناچیز است، می‌توانید اشاره‌های QUIC را درطول راه‌اندازی برنامه برای همه مبدأهای شناخته‌شده دارای قابلیت HTTP/3 به‌طور ایمن پیکربندی کنید.

برای عملکرد بهینه، قبل‌از تماس با preconnect،‏ prefetchUrlAsync، یا loadUrl، با addQuicHints تماس بگیرید. این کار تضمین می‌کند که هرگونه پیش‌اتصال یا درخواست صفحه بعدی از ابتدا با HTTP/3 مذاکره کند.

پیاده‌سازی

برای پیکربندی اشاره‌های QUIC، در نمونه Profile با addQuicHints(Set<String> urls) تماس بگیرید. باید این «میانای برنامه‌سازی کاربردی» را در رشته واسط کاربر فراخوانی کنید و درستی‌سنجی کنید که WebView از ویژگی WebViewFeature.ADD_QUIC_HINTS_V1 پشتیبانی می‌کند.

مانند preconnect،‏ addQuicHints براساس مبدأ عمل می‌کند، اما نشانی‌های وب کامل را می‌توان ارائه کرد (مثل 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 برای سفارشی‌سازی درخواست استفاده می‌کنند. این کلاس‌ها به شما امکان می‌دهند سرصفحه‌های اضافی و نکته‌هایی برای مطابقت نشانی وب ارائه دهید، مثل پیکربندی‌های 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 نشانی وب را بارگیری می‌کند و آن را در حافظه نهان شبکه نمایه ذخیره می‌کند. در «وب‌نما»، Profile به‌عنوان ظرفی برای داده‌های مرورگر عمل می‌کند، ازجمله کوکی‌ها، حافظه نهان اچ‌تی‌تی‌پی، و عامل‌های خدماتی. ازآنجایی‌که پیش‌دریافت یک عمل در سطح نمایه است، هر 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() بازخوان را تغییر می‌دهد. ازآنجایی‌که این موضوع تأثیر مستقیمی بر استفاده موفقیت‌آمیز از محتوای پیش‌دریافت‌شده شما دارد، درک چرخه حیات دو مرحله‌ای بسیار مهم است:

نموداری که چرخه عمر رهگیری واکشی پیش‌از WebView دو مرحله‌ای را
درطول مراحل حدسی و ناوبری نشان می‌دهد. — **شکل ۱.** چرخه حیات رهگیری دو مرحله‌ای برای درخواست‌ها و ناوبری‌های پیش‌دریافت WebView.

۱. فاز گمانه‌زنی (درخواست واکشی اولیه)

وقتی prefetchUrlAsync() فراخوانی می‌شود، WebView منبع اصلی HTML را در پس‌زمینه بارگیری می‌کند. ‫shouldInterceptRequest() برای این درخواست پس‌زمینه‌ای به‌طور کامل رد شد. هرگونه منطق سفارشی، نشان‌های مجوز، یا تزریق سرایند که معمولاً در رهگیر شما مدیریت می‌شود، به منبع HTML پیش‌بارگیری‌شده اعمال نمی‌شود.

۲. مرحله پیمایش (فعال‌سازی کاربر)

وقتی برنامه به‌طور صریح به نشانی وب پیمایش می‌کند (برای مثال، بااستفاده از WebViewCompat.navigate یا loadUrl) یا کاربر روی پیوند مطابقی کلیک می‌کند، «وب‌نما» تعیین می‌کند که آیا می‌تواند از حافظه نهان واکشی اولیه استفاده کند یا نه:

ارزیابی اصلی HTML: در این لحظه، WebView shouldInterceptRequest() را برای HTML اصلی راه‌اندازی می‌کند. برای ارائه موفقیت‌آمیز صفحه از حافظه نهان پیش‌دریافت، میان‌گیر شما باید null را برگرداند. اگر WebResourceResponse سفارشی را برگردانید، WebView به رهگیر شما احترام می‌گذارد و به‌طور کامل از حافظه نهان واکشی اولیه عبور می‌کند.
ارزیابی منبع فرعی: پس‌از اینکه HTML پیش‌واکشی‌شده برای استفاده پاک شد، shouldInterceptRequest() به‌طور معمول برای همه منابع فرعی بعدی (مثل تصاویر، نوشتارها، و CSS) که برای تکمیل پرداز صفحه لازم است راه‌اندازی می‌شود.

رفتارهای کلیدی

ویژگی‌های عملیاتی و بررسی‌های صلاحیت زیر نحوه شروع و مدیریت درخواست‌های پیش‌دریافت توسط WebView را کنترل می‌کنند:

ایمنی رشته: درخواست‌ها می‌توانند از هر رشته‌ای آغاز شوند.
واجدشرایط بودن: قبل‌از شروع واکشی، WebView با بررسی موارد زیر مطمئن می‌شود که درخواست ایمن و ازنظر زمینه‌ای مناسب است:
- کوکی‌های موجود: برای محافظت از حریم خصوصی کاربر و جلوگیری از اثرات جانبی شبیه به CSRF، اگر درخواست به کوکی‌های اصیل‌سازی‌شده خاصی نیاز داشته باشد که بتواند تغییر وضعیت در سرور را راه‌اندازی کند، ممکن است WebView پیش‌واکشی را رد کند.
- حضور کارگر خدمات: اگر «کارگر خدمات» ازقبل کنترل حوزه نشانی وب را دراختیار داشته باشد، WebView می‌تواند به‌جای شروع کردن واکشی اولیه شبکه استاندارد، به کنترل‌کننده واکشی «کارگر خدمات» واگذار کند.
- دسترسی به پراکسی: «وب‌نما» بررسی می‌کند که مسیر شبکه فعلی (ازجمله هرگونه پراکسی پیکربندی‌شده) پایدار باشد تا از ناموفق بودن درخواست‌های حدسی تحت پیکربندی‌های شبکه پیچیده جلوگیری شود.
اگر پیش‌بار کردن (حتی با پارامترهای معتبر) شروع نشود، اغلب به این دلیل است که «وب‌نما» تشخیص داده است درخواست پس‌زمینه‌ای می‌تواند با جلسه فعلی کاربر یا وضعیت امنیتی او تداخل داشته باشد.
لغو: از CancellationSignal برای پایان دادن به درخواست درحال پرواز و جلوگیری از ذخیره آن در حافظه نهان استفاده کنید.

صفحه‌های پیش‌پرداززنی‌شده

پیش‌پرداز کردن «محتوای وب» پنهانی ایجاد می‌کند تا صفحه‌ای را به‌طور کامل در پس‌زمینه پرداز کند، ازجمله اجرای متن و واکشی منابع فرعی. پیش‌پردازش به همان زیرساخت زیربنایی پیش‌واکشی متکی است. اگر برنامه‌ای پیش‌رندر را آغاز کند، ابتدا «وب‌نما» پاسخ را پیش‌واکشی می‌کند تا ناوبری پیش‌رندر را ارائه دهد و از فعالیت شبکه اضافی جلوگیری کند.

پیاده‌سازی

پیش‌پردازشی یک عملیات سطح نمونه «وب‌نما» است. بااستفاده از 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 محدودیت‌های زمان اجرای زیر را اعمال می‌کند:

فشار حافظه: اگر دستگاه RAM کمی داشته باشد، WebView نشانی‌های وب پیش‌پردازش‌شده را لغو می‌کند.
رابط‌های برنامه‌نویسی نرم‌افزار غیرمجاز: هرگونه تلاش ازسوی جاوا اسکریپت برای دسترسی به برخی‌از رابط‌های برنامه‌نویسی نرم‌افزار (برای مثال، بازپخش صدا، هشدارها) در زمینه پس‌زمینه بلافاصله پیش‌رندر را متوقف می‌کند.
محدودیت نمونه: تعداد نشانی‌های وب فعال پیش‌رندرشده مجاز برای هر «وب‌نما» محدود است.

تطبیق نشانی وب و «جستجوی بدون تغییر» (NVS)

«وب‌نما» به الگوریتم تطبیق قابل‌اعتمادی نیاز دارد تا مطمئن شود منبع ازپیش‌بارشده فقط برای پیمایش موردنظرش ارائه می‌شود.

تطابق دقیق دربرابر تطابق NVS

به‌طور پیش‌فرض، واکشی اولیه و پیش‌پرداز به مطابقت دقیق نشانی وب نیاز دارند. اگر نشانی وب پیمایش‌شده با نشانی وب پیش‌بارگیری‌شده یکسان باشد، بلافاصله از حافظه نهان ارائه می‌شود. اگر پارامترهای پُرسمان متفاوت باشد، WebView از قوانین «جستجوی بدون تغییر» (NVS) زیر استفاده می‌کند:

راهنمایی: توسعه‌دهندگان درطول شروع، setExpectedNoVarySearchHeader() راهنمایی ارائه می‌دهند. اگر نشانی وب پیمایش‌شده با نشانی وب درخواست منهای پارامترهای اشاره‌شده مطابقت داشته باشد، WebView به‌طور موقت مسدود می‌شود تا منتظر سرایندهای واقعی سرور بماند.
سرصفحه سرور: سرصفحه پاسخ NVS از سرور مرجع نهایی است. اگر سرور تأیید کند که تفاوت‌های پُرسمان باید نادیده گرفته شود، مطابقت از حافظه نهان ارائه می‌شود. اگر این‌طور نباشد، «وب‌نما» به بار کردن شبکه سرد برمی‌گردد.

«جستجوی بدون تغییر» (NVS) برای استفاده پیشرفته است و اکثر توسعه‌دهندگان ممکن است به آن نیاز نداشته باشند زیرا نشانی وب دقیقاً یکسانی را هم به واکشی اولیه و هم به پیمایش (WebViewCompat.navigate یا 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 (مثل ۴۰۴ یا ۵۰۳) برای کمک به تشخیص مشکلات سمت سرور باشد.
PrerenderException: ابرکلاس برای همه خطاهای مربوط به پیش‌پرداز، مثل خرابی به‌دلیل فشار حافظه یا استفاده از «میاناهای برنامه‌سازی کاربردی» غیرمجاز (مثل پخش صدا) در پس‌زمینه.

استراتژی‌های بهینه‌سازی

برای به حداکثر رساندن مزایای بارگذاری پیش‌بینی‌شده ضمن حفظ منابع سیستم، این توصیه‌ها را دنبال کنید:

زود شروع کنید: پیش‌واکشی را درطول راه‌اندازی برنامه یا به‌محض اینکه مقصد پیمایش احتمالی باشد شروع کنید.
جفت کردن نشانه‌های QUIC با پیش‌گرم کردن اتصال: قبل‌از شروع preconnect()، prefetchUrlAsync()، یا پیمایش‌های استاندارد، addQuicHints() را فرابخوانید تا مطمئن شوید که WebView تلاش می‌کند بااستفاده از HTTP/3 اتصال برقرار کند.
استراتژی یکپارچه: اگر نشانی وبی را که ازقبل در حافظه نهان پیش‌واکشی وجود دارد پیش‌پرداز کنید، پیمایش پیش‌پرداز از آن حافظه نهان ارائه می‌شود و از درخواست‌های شبکه اضافی جلوگیری می‌شود.
پایش سهمیه: پیش‌پرداز کردن منابع زیادی مصرف می‌کند. پیش‌واکشی را برای چندین نامزد احتمالی ترجیح دهید و پیش‌پرداز را برای محتمل‌ترین پیمایش رزرو کنید.
پشتیبانی طرح: مطمئن شوید که همه نشانی‌های وب از طرح HTTPS اجباری استفاده می‌کنند. طرح‌های نامعتبر یا ورودی‌های تهی باعث راه‌اندازی IllegalArgumentException هم‌زمان می‌شود.

منابع بیشتر

برای کسب اطلاعات بیشتر درباره اشکال‌زدایی برنامه‌های وب، بهینه‌سازی عملکرد راه‌اندازی WebView، و مدیریت خاتمه فرایند رندرکننده، منابع زیر را ببینید:

بار کردن حدسی در «وب‌نما» با مجموعه‌ها، منظم بمانید ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.

انتخاب استراتژی بار کردن حدسی

پیش‌اتصال به مبدأها

پیاده‌سازی

کاتلین

جاوا

با نشانه‌های QUIC، پشتیبانی از پروتکل QUIC را نشان دهید

پیش‌اتصال با اشاره‌های QUIC

پیاده‌سازی

کاتلین

جاوا

پیکربندی مشترک: PrefetchParameters و PrerenderParameters

کاتلین

جاوا

پیش‌بارگیری محتوا

پیاده‌سازی

کاتلین

جاوا

چرخه حیات قطع توپ

رفتارهای کلیدی

صفحه‌های پیش‌پرداززنی‌شده

پیاده‌سازی

کاتلین

جاوا

محدودیت‌های فنی

تطبیق نشانی وب و «جستجوی بدون تغییر» (NVS)

تطابق دقیق دربرابر تطابق NVS

پیکربندی سراسری

کاتلین

جاوا

مدیریت خطا و استثناها

استثناهای اصلی

استراتژی‌های بهینه‌سازی

منابع بیشتر

بار کردن حدسی در «وب‌نما»

پیکربندی مشترک: `PrefetchParameters` و `PrerenderParameters`