เผยแพร่: 5 กรกฎาคม 2021
Progressive Web App นำฟีเจอร์มากมายที่ก่อนหน้านี้สงวนไว้สำหรับแอปพลิเคชันเนทีฟ มาสู่เว็บ ฟีเจอร์ที่โดดเด่นที่สุดอย่างหนึ่งที่เชื่อมโยงกับ PWA คือประสบการณ์การใช้งานแบบออฟไลน์
และจะดียิ่งขึ้นไปอีกหากมีประสบการณ์การสตรีมสื่อแบบออฟไลน์ ซึ่งเป็น การเพิ่มประสิทธิภาพที่คุณสามารถมอบให้แก่ผู้ใช้ได้หลายวิธี อย่างไรก็ตาม ปัญหานี้เป็นปัญหาที่เฉพาะเจาะจงอย่างแท้จริง นั่นคือไฟล์สื่ออาจมีขนาดใหญ่มาก ดังนั้น คุณอาจสงสัยว่า
- ฉันจะดาวน์โหลดและจัดเก็บไฟล์วิดีโอขนาดใหญ่ได้อย่างไร
- และฉันจะแสดงต่อผู้ใช้ได้อย่างไร
ในบทความนี้ เราจะพูดถึงคำตอบของคำถามเหล่านี้ พร้อมทั้งอ้างอิงถึง PWA สาธิตของ Kino ที่เราสร้างขึ้น ซึ่งจะแสดงตัวอย่างในทางปฏิบัติเกี่ยวกับวิธีที่คุณจะนำประสบการณ์การสตรีมสื่อแบบออฟไลน์ไปใช้ได้โดยไม่ต้องใช้เฟรมเวิร์กเชิงฟังก์ชันหรือเชิงนำเสนอ ตัวอย่างต่อไปนี้มีไว้เพื่อวัตถุประสงค์ด้านการศึกษาเป็นหลัก เนื่องจากในกรณีส่วนใหญ่ คุณควรใช้กรอบงานสื่อที่มีอยู่เพื่อให้บริการฟีเจอร์เหล่านี้
การสร้าง PWA ที่มีการสตรีมแบบออฟไลน์นั้นมีความท้าทาย เว้นแต่คุณจะมีเหตุผลทางธุรกิจที่สมควรในการพัฒนา PWA ของคุณเอง ในบทความนี้ คุณจะได้เรียนรู้เกี่ยวกับ API และเทคนิคที่ใช้เพื่อมอบประสบการณ์การใช้งานสื่อแบบออฟไลน์คุณภาพสูง แก่ผู้ใช้
การดาวน์โหลดและจัดเก็บไฟล์สื่อขนาดใหญ่
โดยปกติแล้ว Progressive Web App จะใช้ Cache API ที่สะดวกเพื่อดาวน์โหลดและจัดเก็บชิ้นงานที่จำเป็นต่อการมอบประสบการณ์การใช้งานแบบออฟไลน์ ได้แก่ เอกสาร สไตล์ชีต รูปภาพ และอื่นๆ
ตัวอย่างพื้นฐานของการใช้ Cache API ภายใน Service Worker มีดังนี้
const cacheStorageName = 'v1';
this.addEventListener('install', function(event) {
event.waitUntil(
caches.open(cacheStorageName).then(function(cache) {
return cache.addAll([
'index.html',
'style.css',
'scripts.js',
// Don't do this.
'very-large-video.mp4',
]);
})
);
});
แม้ว่าตัวอย่างข้างต้นจะใช้งานได้ในทางเทคนิค แต่การใช้ Cache API ก็มีข้อจำกัดหลายประการ ซึ่งทำให้การใช้กับไฟล์ขนาดใหญ่ไม่สะดวก
ตัวอย่างเช่น Cache API จะไม่ทำสิ่งต่อไปนี้
- ช่วยให้คุณหยุดชั่วคราวและกลับมาดาวน์โหลดต่อได้อย่างง่ายดาย
- ช่วยให้คุณติดตามความคืบหน้าของการดาวน์โหลดได้
- มีวิธีตอบสนองต่อคำขอช่วง HTTP อย่างถูกต้อง
ปัญหาทั้งหมดนี้เป็นข้อจำกัดที่ค่อนข้างร้ายแรงสำหรับแอปพลิเคชันวิดีโอ มาดูตัวเลือกอื่นๆ ที่อาจเหมาะสมกว่ากัน
ปัจจุบัน Fetch API เป็นวิธีเข้าถึงไฟล์ระยะไกลแบบไม่พร้อมกันในเบราว์เซอร์ต่างๆ ในกรณีการใช้งานของเรา ฟีเจอร์นี้ช่วยให้คุณเข้าถึงไฟล์วิดีโอขนาดใหญ่เป็นสตรีมและ จัดเก็บไฟล์เหล่านั้นทีละส่วนโดยใช้คำขอช่วง HTTP
ตอนนี้คุณอ่านกลุ่มข้อมูลด้วย Fetch API ได้แล้ว คุณจึงต้องจัดเก็บข้อมูลเหล่านั้นด้วย มีโอกาสสูงที่จะมีข้อมูลเมตาจำนวนมากที่เชื่อมโยงกับไฟล์สื่อ เช่น ชื่อ คำอธิบาย ความยาวรันไทม์ หมวดหมู่ ฯลฯ
คุณไม่ได้จัดเก็บเพียงไฟล์สื่อเดียว แต่กำลังจัดเก็บออบเจ็กต์ที่มีโครงสร้าง และไฟล์สื่อเป็นเพียงพร็อพเพอร์ตี้หนึ่งของออบเจ็กต์นั้น
ในกรณีนี้ IndexedDB API เป็นโซลูชันที่ยอดเยี่ยมในการจัดเก็บทั้งข้อมูลสื่อและข้อมูลเมตา โดยสามารถจัดเก็บข้อมูลไบนารีจํานวนมากได้อย่างง่ายดาย และยังมีดัชนีที่ช่วยให้คุณค้นหาข้อมูลได้อย่างรวดเร็ว
การดาวน์โหลดไฟล์สื่อโดยใช้ Fetch API
เราได้สร้างฟีเจอร์ที่น่าสนใจ 2-3 อย่างเกี่ยวกับ Fetch API ใน PWA สาธิต ซึ่งเราตั้งชื่อว่า Kino โดยซอร์สโค้ดเป็นแบบสาธารณะ คุณจึงตรวจสอบได้ตามต้องการ
- ความสามารถในการหยุดชั่วคราวและกลับมาดาวน์โหลดต่อในภายหลัง
- บัฟเฟอร์ที่กำหนดเองสำหรับจัดเก็บกลุ่มข้อมูลในฐานข้อมูล
ก่อนที่จะแสดงวิธีใช้ฟีเจอร์เหล่านั้น เราจะมา ทบทวนสั้นๆ เกี่ยวกับวิธีใช้ Fetch API เพื่อดาวน์โหลดไฟล์กันก่อน
/**
* Downloads a single file.
*
* @param {string} url URL of the file to be downloaded.
*/
async function downloadFile(url) {
const response = await fetch(url);
const reader = response.body.getReader();
do {
const { done, dataChunk } = await reader.read();
// Store the `dataChunk` to IndexedDB.
} while (!done);
}
สังเกตไหมว่า await reader.read()
อยู่ในลูป วิธีนี้จะช่วยให้คุณได้รับข้อมูลเป็นกลุ่ม
จากสตรีมที่อ่านได้เมื่อข้อมูลมาถึงจากเครือข่าย ลองพิจารณาดูว่า
สิ่งนี้มีประโยชน์อย่างไร คุณสามารถเริ่มประมวลผลข้อมูลได้แม้ว่าข้อมูลทั้งหมดจะยังมาไม่ถึง
จากเครือข่ายก็ตาม
การดาวน์โหลดต่อ
เมื่อการดาวน์โหลดหยุดชั่วคราวหรือถูกขัดจังหวะ ระบบจะจัดเก็บกลุ่มข้อมูลที่ได้รับไว้ในฐานข้อมูล IndexedDB อย่างปลอดภัย จากนั้นคุณจะแสดงปุ่มเพื่อ ดาวน์โหลดต่อในแอปพลิเคชันได้ เนื่องจากเซิร์ฟเวอร์ PWA สาธิตของ Kino รองรับคำขอช่วง HTTP การดาวน์โหลดต่อจึงค่อนข้างตรงไปตรงมา
async downloadFile() {
// this.currentFileMeta contains data from IndexedDB.
const { bytesDownloaded, url, downloadUrl } = this.currentFileMeta;
const fetchOpts = {};
// If we already have some data downloaded,
// request everything from that position on.
if (bytesDownloaded) {
fetchOpts.headers = {
Range: `bytes=${bytesDownloaded}-`,
};
}
const response = await fetch(downloadUrl, fetchOpts);
const reader = response.body.getReader();
let dataChunk;
do {
dataChunk = await reader.read();
if (!dataChunk.done) this.buffer.add(dataChunk.value);
} while (!dataChunk.done && !this.paused);
}
บัฟเฟอร์การเขียนที่กำหนดเองสำหรับ IndexedDB
ในทางทฤษฎี กระบวนการเขียนค่า dataChunk
ลงในฐานข้อมูล IndexedDB
นั้นง่าย ค่าเหล่านั้นเป็นอินสแตนซ์ ArrayBuffer
อยู่แล้ว ซึ่งจัดเก็บได้
ใน IndexedDB โดยตรง ดังนั้นเราจึงสร้างออบเจ็กต์ที่มีรูปร่างที่เหมาะสม
และจัดเก็บได้เลย
const dataItem = {
url: fileUrl,
rangeStart: dataStartByte,
rangeEnd: dataEndByte,
data: dataChunk,
}
// Name of the store that will hold your data.
const storeName = 'fileChunksStorage'
// `db` is an instance of `IDBDatabase`.
const transaction = db.transaction([storeName], 'readwrite');
const store = transaction.objectStore(storeName);
const putRequest = store.put(data);
putRequest.onsuccess = () => { ... }
แม้ว่าวิธีนี้จะใช้ได้ แต่คุณอาจพบว่าการเขียน IndexedDB ช้ากว่าการดาวน์โหลดมาก สาเหตุไม่ได้เป็นเพราะการเขียน IndexedDB ช้า แต่เป็นเพราะเราเพิ่มค่าใช้จ่ายในการทำธุรกรรมจำนวนมากโดยการสร้างธุรกรรมใหม่สำหรับทุกๆ ก้อนข้อมูลที่เราได้รับจากเครือข่าย
โดยแต่ละก้อนที่ดาวน์โหลดจะมีขนาดเล็กมากและสตรีมจะส่งก้อนเหล่านี้ออกมา อย่างรวดเร็ว คุณต้องจำกัดอัตราการเขียน IndexedDB ใน PWA ของเดโม Kino เราทำเช่นนี้โดยการใช้บัฟเฟอร์การเขียนตัวกลาง
เมื่อได้รับก้อนข้อมูลจากเครือข่าย เราจะต่อท้ายก้อนข้อมูลเหล่านั้นในบัฟเฟอร์ก่อน หากข้อมูลขาเข้าไม่พอ เราจะล้างบัฟเฟอร์ทั้งหมดลงในฐานข้อมูลและ ล้างบัฟเฟอร์ก่อนที่จะต่อท้ายข้อมูลที่เหลือ ด้วยเหตุนี้ การเขียน IndexedDB จึงเกิดขึ้นน้อยลง ซึ่งส่งผลให้ประสิทธิภาพการเขียน ดีขึ้นอย่างมาก
การแสดงไฟล์สื่อจากพื้นที่เก็บข้อมูลออฟไลน์
เมื่อดาวน์โหลดไฟล์สื่อแล้ว คุณอาจต้องการให้ Service Worker แสดงไฟล์จาก IndexedDB แทนที่จะดึงไฟล์จากเครือข่าย
/**
* The main service worker fetch handler.
*
* @param {FetchEvent} event Fetch event.
*/
const fetchHandler = async (event) => {
const getResponse = async () => {
// Omitted Cache API code used to serve static assets.
const videoResponse = await getVideoResponse(event);
if (videoResponse) return videoResponse;
// Fallback to network.
return fetch(event.request);
};
event.respondWith(getResponse());
};
self.addEventListener('fetch', fetchHandler);
ดังนั้นสิ่งที่คุณต้องทำใน getVideoResponse()
คืออะไร
เมธอด
event.respondWith()
คาดหวังออบเจ็กต์Response
เป็นพารามิเตอร์ตัวสร้าง Response() บอกเราว่ามีออบเจ็กต์หลายประเภทที่เรา ใช้เพื่อสร้างอินสแตนซ์ออบเจ็กต์
Response
ได้ เช่นBlob
,BufferSource
,ReadableStream
และอื่นๆเราต้องการออบเจ็กต์ที่ไม่เก็บข้อมูลทั้งหมดไว้ในหน่วยความจำ ดังนั้นเราจึงอาจต้องเลือก
ReadableStream
นอกจากนี้ เนื่องจากเราต้องจัดการกับไฟล์ขนาดใหญ่ และต้องการอนุญาตให้เบราว์เซอร์ขอเฉพาะส่วนของไฟล์ที่ต้องการในขณะนั้น เราจึงต้องรองรับคำขอช่วง HTTP ขั้นพื้นฐาน
/**
* Respond to a request to fetch offline video file and construct a response
* stream.
*
* Includes support for `Range` requests.
*
* @param {Request} request Request object.
* @param {Object} fileMeta File meta object.
*
* @returns {Response} Response object.
*/
const getVideoResponse = (request, fileMeta) => {
const rangeRequest = request.headers.get('range') || '';
const byteRanges = rangeRequest.match(/bytes=(?<from>[0-9]+)?-(?<to>[0-9]+)?/);
// Using the optional chaining here to access properties of
// possibly nullish objects.
const rangeFrom = Number(byteRanges?.groups?.from || 0);
const rangeTo = Number(byteRanges?.groups?.to || fileMeta.bytesTotal - 1);
// Omitting implementation for brevity.
const streamSource = {
pull(controller) {
// Read file data here and call `controller.enqueue`
// with every retrieved chunk, then `controller.close`
// once all data is read.
}
}
const stream = new ReadableStream(streamSource);
// Make sure to set proper headers when supporting range requests.
const responseOpts = {
status: rangeRequest ? 206 : 200,
statusText: rangeRequest ? 'Partial Content' : 'OK',
headers: {
'Accept-Ranges': 'bytes',
'Content-Length': rangeTo - rangeFrom + 1,
},
};
if (rangeRequest) {
responseOpts.headers['Content-Range'] = `bytes ${rangeFrom}-${rangeTo}/${fileMeta.bytesTotal}`;
}
const response = new Response(stream, responseOpts);
return response;
คุณสามารถดูKino เพื่อดูวิธีที่เราอ่านข้อมูลไฟล์จาก IndexedDB และสร้างสตรีมในแอปพลิเคชันจริง
ข้อควรพิจารณาอื่นๆ
เมื่ออุปสรรคหลักหมดไปแล้ว ตอนนี้คุณก็เริ่มเพิ่มฟีเจอร์ที่ มีไว้ก็ดีลงในแอปพลิเคชันวิดีโอได้แล้ว ตัวอย่างฟีเจอร์ที่คุณจะเห็นใน PWA สาธิตของ Kino มีดังนี้
- การผสานรวม Media Session API ที่ช่วยให้ผู้ใช้ควบคุมการเล่นสื่อได้โดยใช้ปุ่มสื่อบนฮาร์ดแวร์โดยเฉพาะหรือจากป๊อปอัปการแจ้งเตือนสื่อ
- การแคชเนื้อหาอื่นๆ ที่เชื่อมโยงกับไฟล์สื่อ เช่น คำบรรยาย และ รูปภาพโปสเตอร์โดยใช้ Cache API แบบเดิม
- รองรับการดาวน์โหลดสตรีมวิดีโอ (DASH, HLS) ภายในแอป เนื่องจากโดยทั่วไปแล้วไฟล์ Manifest ของสตรีมจะประกาศแหล่งที่มาหลายแหล่งที่มีอัตราบิตแตกต่างกัน คุณจึงต้องแปลงไฟล์ Manifest และดาวน์โหลดเฉพาะสื่อเวอร์ชันเดียวเท่านั้นก่อนจัดเก็บเพื่อดูแบบออฟไลน์
ถัดไป คุณจะได้เรียนรู้เกี่ยวกับการเล่นอย่างรวดเร็วพร้อมการโหลดเสียงและวิดีโอล่วงหน้า