การโหลดแบบคาดเดาใน WebView

เวลาแฝงในการนำทางเป็นเมตริกที่สำคัญสำหรับประสบการณ์ของผู้ใช้ WebView มี API สำหรับการโหลดแบบคาดเดาเพื่อช่วยให้นักพัฒนาแอปสามารถลดเวลาแฝงนี้ได้ โดยจะช่วยให้แอปดึงหรือแสดงเนื้อหาก่อนที่ผู้ใช้จะไปยังเนื้อหานั้นอย่างชัดเจน

WebView รองรับการโหลดแบบคาดเดา 3 ประเภทหลัก ได้แก่ การเชื่อมต่อล่วงหน้า การดึงข้อมูลล่วงหน้า และการแสดงผลล่วงหน้า

การใช้กลยุทธ์การโหลดแบบคาดเดาจะช่วยให้คุณทำสิ่งต่อไปนี้ได้

  • ลดเวลาแฝงในการโหลดเนื้อหาเว็บลงอย่างมาก: ย้ายเวลาเริ่มต้นของเครือข่ายไปไว้ในช่วงต้นของวงจรการใช้งานแอป
  • อัตราความสำเร็จในการนำทางสูงขึ้น: การเตรียมเครือข่ายและแคชไว้ล่วงหน้าจะช่วยลดโอกาสที่การนำทางจะล้มเหลวเนื่องจากปัญหาเครือข่ายชั่วคราว
  • การตอบสนองที่รับรู้ได้ดีขึ้น: โดยเฉพาะอย่างยิ่งการแสดงผลล่วงหน้าจะช่วยให้การเปลี่ยนผ่านเกิดขึ้นได้ทันที ซึ่งทำให้แอปดูเร็วขึ้นอย่างมาก

เลือกกลยุทธ์การโหลดแบบคาดเดา

ความแตกต่างที่สำคัญระหว่างกลยุทธ์เหล่านี้อยู่ที่ขอบเขตการทำงาน โดย API การเชื่อมต่อล่วงหน้าจะอิงตามต้นทาง ซึ่งหมายความว่าต้องใช้เพียงโดเมนเป้าหมาย ส่วน API การดึงข้อมูลล่วงหน้าและการแสดงผลล่วงหน้าจะอิงตาม URL ซึ่งหมายความว่าต้องใช้เส้นทางหน้าเว็บที่แน่นอน

เนื่องจากการเชื่อมต่อล่วงหน้าทำงานที่ระดับต้นทาง จึงสามารถเริ่มต้นได้เร็วกว่ามากในวงจรการใช้งานแอป แม้ว่าคุณจะยังไม่ทราบเนื้อหาหรือหน้าที่เฉพาะเจาะจงที่ผู้ใช้จะไปยังก็ตาม

ตารางต่อไปนี้เปรียบเทียบกลยุทธ์ทั้ง 3 แบบนี้เพื่อช่วยให้คุณเลือกกลยุทธ์ที่เหมาะสมกับกรณีการใช้งานของคุณ

ฟีเจอร์ การเชื่อมต่อล่วงหน้า การดึงข้อมูลล่วงหน้า การแสดงผลล่วงหน้า
เป้าหมายหลัก เตรียมการเชื่อมต่อไว้ล่วงหน้า แคชเฉพาะ HTML (ไม่มี JavaScript หรือ CSS) แสดงผลทั้งหน้าล่วงหน้า
ขอบเขต ระดับโปรไฟล์ (แชร์ใน WebView) ระดับโปรไฟล์ (แชร์ใน WebView) ระดับ WebView (ผูกกับ WebView ที่เฉพาะเจาะจง)
Jetpack WebKit API androidx.webkit.Profile androidx.webkit.Profile androidx.webkit.WebViewCompat
เมธอด API หลัก preconnect(...) prefetchUrlAsync(...) prerenderUrlAsync(...)
การกำหนดค่า ไม่มี PrefetchCache.setMaxPrefetches()
PrefetchCache.setPrefetchTtlSeconds()
setMaxPrerenders()
การใช้ทรัพยากร ต่ำ (เครือข่าย) ปานกลาง (เครือข่าย หน่วยความจำ) สูง (CPU, หน่วยความจำ, เครือข่าย)
กรณีที่ควรใช้ เมื่อทราบต้นทางเป้าหมาย แต่ยังไม่ได้กำหนด URL ที่เฉพาะเจาะจง เมื่อทราบ URL ที่แน่นอนและมีแนวโน้มที่จะมีการนำทาง โดยมีการแชร์แคชใน WebView เมื่อทราบ URL ที่แน่นอนและมั่นใจว่าจะมีการนำทางภายใน WebView ที่เฉพาะเจาะจง
สิทธิประโยชน์ ตั้งค่าการเชื่อมต่อได้เร็วขึ้นสำหรับ URL ใดก็ตามในต้นทาง โหลดเครือข่ายได้เร็วขึ้นสำหรับ URL ที่ตรงกัน การนำทางเกิดขึ้นได้ทันทีเมื่อเปิดใช้งาน

เชื่อมต่อกับต้นทางล่วงหน้า

การเชื่อมต่อล่วงหน้าจะช่วยเร่งการโหลดในอนาคตด้วยการดำเนินการ DNS Lookup และการแฮนด์เชค TCP/TLS ล่วงหน้าสำหรับต้นทางที่ระบุ

การเชื่อมต่อล่วงหน้าจะอิงตามต้นทางอย่างเคร่งครัด ซึ่งแตกต่างจากการดึงข้อมูลล่วงหน้าและการแสดงผลล่วงหน้าที่ต้องใช้ URL ปลายทางที่แน่นอน การดำเนินการนี้ช่วยให้คุณเรียกการเชื่อมต่อล่วงหน้าได้เร็วกว่าการดึงข้อมูลล่วงหน้าและการแสดงผลล่วงหน้า

กลยุทธ์ระดับโปรไฟล์ที่ใช้ทรัพยากรต่ำนี้จะช่วยลดเวลาแฝงเริ่มต้นสำหรับ WebView ใดก็ตามที่แชร์โปรไฟล์นั้น ตราบใดที่ยังไม่เคยเข้าชมต้นทาง การเชื่อมต่อจะยังคงเปิดอยู่ประมาณ 30 วินาที ซึ่งเป็นประโยชน์ต่อคำขอ HTTP แบบข้ามต้นทาง การนำทาง หรือทรัพยากรย่อยที่ตามมาด้วยการลดค่าใช้จ่ายในการแฮนด์เชค

การใช้งาน

หากต้องการเริ่มการเชื่อมต่อล่วงหน้า ให้เรียก preconnect(String url) ในอินสแตนซ์ Profile API นี้ต้องเรียกใช้ในเธรด UI และต้องรองรับ WebViewFeature.PRECONNECT

API จะทำงานในต้นทาง แต่คุณสามารถระบุ URL แบบเต็ม (เช่น https://www.example.com/index.html) เพื่อความสะดวก ระบบจะถือว่าเป็นการเรียกไปยังต้นทางโดยอัตโนมัติ (เช่น https://www.example.com) คุณสามารถเชื่อมต่อกับต้นทางหลายรายการได้ โดยการเรียก API นี้หลายครั้ง

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
}

การกำหนดค่าทั่วไป: PrefetchParameters และ PrerenderParameters

ทั้งการดึงข้อมูลล่วงหน้าและการแสดงผลล่วงหน้าใช้ 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 และ Service Worker เนื่องจากการดึงข้อมูลล่วงหน้าเป็นการดำเนินการระดับโปรไฟล์ 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() เนื่องจากคำขอนี้ส่งผลโดยตรงต่อความสำเร็จในการใช้เนื้อหาที่ดึงข้อมูลล่วงหน้า คุณจึงต้องทำความเข้าใจวงจรการใช้งาน 2 ขั้นตอนต่อไปนี้

แผนภาพแสดงวงจรการสกัดกั้นการดึงข้อมูลล่วงหน้าของ WebView แบบ 2 ขั้นตอน
  ในระหว่างเฟสการคาดการณ์และการนำทาง
รูปที่ 1 วงจรการใช้งานการสกัดกั้น 2 ขั้นตอนสำหรับคำขอดึงข้อมูลล่วงหน้า และการนำทางของ 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 อาจข้ามการดึงข้อมูลล่วงหน้าหากคำขอต้องใช้คุกกี้ที่ตรวจสอบสิทธิ์แล้วที่เฉพาะเจาะจงซึ่งอาจทริกเกอร์การเปลี่ยนแปลงสถานะในเซิร์ฟเวอร์
    • การมีอยู่ของ Service Worker: หาก Service Worker ควบคุมขอบเขตของ URL อยู่แล้ว WebView อาจเลื่อนการจัดการคำขอการดึงข้อมูลของ Service Worker แทนที่จะเริ่มการดึงข้อมูลล่วงหน้าของเครือข่ายมาตรฐาน
    • ความพร้อมใช้งานของพร็อกซี: WebView จะตรวจสอบว่าเส้นทางเครือข่ายปัจจุบัน (รวมถึงพร็อกซีที่กำหนดค่าไว้) มีเสถียรภาพเพื่อหลีกเลี่ยงไม่ให้คำขอแบบคาดการณ์ล่วงหน้าล้มเหลวภายใต้การกำหนดค่าเครือข่ายที่ซับซ้อน
  • หากการดึงข้อมูลล่วงหน้าเริ่มต้นไม่สำเร็จ (แม้จะมีพารามิเตอร์ที่ถูกต้อง) มักเป็นเพราะ WebView กำหนดว่าคำขอเบื้องหลังอาจรบกวนเซสชันปัจจุบันหรือสถานะความปลอดภัยของผู้ใช้
  • การยกเลิก: ใช้ CancellationSignal เพื่อยกเลิกคำขอที่อยู่ระหว่างดำเนินการและป้องกันไม่ให้แคชคำขอนั้น

การแสดงผลหน้าล่วงหน้า

การแสดงผลล่วงหน้าจะสร้าง "เนื้อหาเว็บ" ที่ซ่อนไว้เพื่อแสดงผลหน้าอย่างสมบูรณ์ในเบื้องหลัง ซึ่งรวมถึงการเรียกใช้สคริปต์และการดึงข้อมูลทรัพยากรย่อย การแสดงผลล่วงหน้าใช้โครงสร้างพื้นฐานเดียวกันกับการดึงข้อมูลล่วงหน้า หากแอปเริ่มการแสดงผลล่วงหน้า WebView จะดึงข้อมูลการตอบกลับล่วงหน้าก่อนเพื่อแสดงผลการนำทางแบบแสดงผลล่วงหน้า ซึ่งจะช่วยหลีกเลี่ยงกิจกรรมเครือข่ายที่ซ้ำซ้อน

การใช้งาน

การแสดงผลล่วงหน้าเป็นการดำเนินการระดับอินสแตนซ์ WebView เรียก prerenderUrlAsync() โดยใช้ WebViewCompat จากเธรด UI

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() จากเธรด UI

ข้อจำกัดทางเทคนิค

WebView บังคับใช้ข้อจำกัดรันไทม์ต่อไปนี้เพื่อสร้างสมดุลระหว่างการนำทางแบบทันทีกับสถานะของระบบ

  • หน่วยความจำเหลือน้อย: WebView จะยกเลิก URL ที่แสดงผลล่วงหน้าหากอุปกรณ์มี RAM เหลือน้อย
  • API ที่ไม่อนุญาต: การพยายามเข้าถึง API บางรายการ (เช่น การเล่นเสียง การแสดงข้อความแจ้ง) โดย JavaScript ในบริบทเบื้องหลังจะยกเลิกการแสดงผลล่วงหน้าทันที
  • ขีดจำกัดอินสแตนซ์: จำนวน URL ที่แสดงผลล่วงหน้าที่ใช้งานอยู่ซึ่งอนุญาตต่อ WebView มีจำกัด

การจับคู่ URL และ No-Vary-Search (NVS)

WebView ต้องใช้อัลกอริทึมการจับคู่ที่เชื่อถือได้เพื่อให้แน่ใจว่าระบบจะแสดงทรัพยากรที่โหลดไว้ล่วงหน้าสำหรับการนำทางที่ต้องการเท่านั้น

การจับคู่แบบตรงทั้งหมดกับการจับคู่ NVS

โดยค่าเริ่มต้น การดึงข้อมูลล่วงหน้าและการแสดงผลล่วงหน้าต้องมีการจับคู่ URL แบบตรงทั้งหมด หาก 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: คลาสระดับบนสำหรับข้อผิดพลาดทั้งหมดที่เกี่ยวข้องกับการแสดงผลล่วงหน้า เช่น ข้อผิดพลาดเนื่องจากหน่วยความจำเหลือน้อยหรือการใช้ API ที่ไม่อนุญาต (เช่น การเล่นเสียง) ในเบื้องหลัง

กลยุทธ์การเพิ่มประสิทธิภาพ

ทำตามคำแนะนำต่อไปนี้เพื่อเพิ่มประโยชน์สูงสุดจากการโหลดแบบคาดการณ์ล่วงหน้าพร้อมกับประหยัดทรัพยากรของระบบ

  • เริ่มต้นเร็ว: เริ่มการดึงข้อมูลล่วงหน้าระหว่างการเริ่มต้นแอปหรือทันทีที่มีแนวโน้มว่าจะมีการนำทางไปยังปลายทาง
  • กลยุทธ์แบบบูรณาการ: หากคุณแสดงผล URL ล่วงหน้าซึ่งอยู่ในแคชที่ดึงข้อมูลล่วงหน้าแล้ว ระบบจะแสดงผลการนำทางแบบแสดงผลล่วงหน้าจากแคชนั้น ซึ่งจะช่วยหลีกเลี่ยงคำขอเครือข่ายที่ซ้ำซ้อน
  • ตรวจสอบโควต้า: การแสดงผลล่วงหน้าใช้ทรัพยากรจำนวนมาก เราขอแนะนำให้ดึงข้อมูลล่วงหน้าสำหรับตัวเลือกที่มีแนวโน้มหลายรายการ และสงวนการแสดงผลล่วงหน้าไว้สำหรับการนำทางที่มีแนวโน้มมากที่สุดเพียงรายการเดียว
  • การรองรับ Scheme: ตรวจสอบว่า URL ทั้งหมดใช้ HTTPS Scheme ที่บังคับ Scheme ที่ไม่ถูกต้องหรืออินพุตเป็นค่าว่างจะทริกเกอร์ IllegalArgumentException แบบซิงโครนัส

แหล่งข้อมูลเพิ่มเติม

ดูข้อมูลเพิ่มเติมเกี่ยวกับการแก้ไขข้อบกพร่องของเว็บแอป การเพิ่มประสิทธิภาพการเริ่มต้น WebView และการจัดการการสิ้นสุดกระบวนการแสดงผลได้ที่แหล่งข้อมูลต่อไปนี้