เวลาแฝงในการนำทางเป็นเมตริกที่สำคัญสำหรับประสบการณ์ของผู้ใช้ 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 ขั้นตอนต่อไปนี้
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 และการจัดการการสิ้นสุดกระบวนการแสดงผลได้ที่แหล่งข้อมูลต่อไปนี้
- การนำทางหน้าเว็บที่ปรับปรุงแล้วด้วยเมธอด
WebViewCompat.navigate - แก้ไขข้อบกพร่องของเว็บแอป
- เพิ่มประสิทธิภาพการเริ่มต้น WebView
- จัดการการสิ้นสุดกระบวนการแสดงผลของ WebView