Giờ đây, việc chuyển các tác vụ nặng sang luồng nền trở nên dễ dàng hơn nhờ các mô-đun JavaScript trong trình chạy web.
JavaScript là đơn luồng, tức là chỉ có thể thực hiện một thao tác tại một thời điểm. Điều này rất trực quan và hoạt động hiệu quả trong nhiều trường hợp trên web, nhưng có thể gây ra vấn đề khi chúng ta cần thực hiện các tác vụ nặng như xử lý dữ liệu, phân tích cú pháp, tính toán hoặc phân tích. Khi ngày càng có nhiều ứng dụng phức tạp được phân phối trên web, nhu cầu xử lý đa luồng cũng tăng lên.
Trên nền tảng web, thành phần gốc chính cho luồng và tính song song là Web Workers API. Worker là một lớp trừu tượng gọn nhẹ trên luồng hệ điều hành, hiển thị một API truyền thông báo để giao tiếp giữa các luồng. Điều này có thể cực kỳ hữu ích khi thực hiện các phép tính tốn kém hoặc hoạt động trên các tập dữ liệu lớn, cho phép luồng chính chạy mượt mà trong khi thực hiện các thao tác tốn kém trên một hoặc nhiều luồng nền.
Dưới đây là ví dụ điển hình về cách sử dụng worker, trong đó tập lệnh worker lắng nghe thông báo từ luồng chính và phản hồi bằng cách gửi lại thông báo của chính nó:
page.js:
const worker = new Worker('worker.js');
worker.addEventListener('message', e => {
console.log(e.data);
});
worker.postMessage('hello');
worker.js:
addEventListener('message', e => {
if (e.data === 'hello') {
postMessage('world');
}
});
Web Worker API đã có mặt trên hầu hết các trình duyệt trong hơn 10 năm qua. Mặc dù điều này có nghĩa là trình chạy có khả năng hỗ trợ trình duyệt tuyệt vời và được tối ưu hoá tốt, nhưng cũng có nghĩa là trình chạy đã có từ lâu trước khi có mô-đun JavaScript. Vì không có hệ thống mô-đun khi trình chạy được thiết kế, nên API để tải mã vào trình chạy và soạn tập lệnh vẫn tương tự như các phương pháp tải tập lệnh đồng bộ phổ biến vào năm 2009.
Nhật ký: Trình chạy cổ điển
Hàm khởi tạo Worker lấy URL tập lệnh cổ điển, tương ứng với URL tài liệu. Hàm này ngay lập tức trả về một tệp đối chiếu cho thực thể worker mới, hiển thị giao diện nhắn tin cũng như phương thức terminate() ngay lập tức dừng và huỷ worker.
const worker = new Worker('worker.js');
Hàm importScripts() có sẵn trong trình chạy web để tải thêm mã, nhưng hàm này tạm dừng thực thi trình chạy để tìm nạp và đánh giá từng tập lệnh. Thẻ này cũng thực thi các tập lệnh trong phạm vi toàn cục như thẻ <script> thông thường, tức là các biến trong một tập lệnh có thể bị ghi đè bằng các biến trong một tập lệnh khác.
worker.js:
importScripts('greet.js');
// ^ could block for seconds
addEventListener('message', e => {
postMessage(sayHello());
});
greet.js:
// global to the whole worker
function sayHello() {
return 'world';
}
Vì lý do này, trình chạy web trước đây đã áp đặt một hiệu ứng quá lớn đối với cấu trúc của một ứng dụng. Nhà phát triển phải tạo ra các công cụ và giải pháp thông minh để có thể sử dụng trình chạy web mà không cần từ bỏ các phương pháp phát triển hiện đại. Ví dụ: các trình đóng gói như webpack nhúng một phương thức triển khai trình tải mô-đun nhỏ vào mã được tạo, sử dụng importScripts() để tải mã, nhưng gói các mô-đun trong các hàm để tránh xung đột biến và mô phỏng việc nhập và xuất phần phụ thuộc.
Nhập worker mô-đun
Một chế độ mới dành cho trình chạy web có các lợi ích về hiệu suất và tính tiện dụng của mô-đun JavaScript sẽ được cung cấp trong Chrome 80, được gọi là trình chạy mô-đun. Hàm khởi tạo Worker hiện chấp nhận một tuỳ chọn {type:"module"} mới, giúp thay đổi cách tải và thực thi tập lệnh cho phù hợp với <script type="module">.
const worker = new Worker('worker.js', {
type: 'module'
});
Vì trình chạy mô-đun là mô-đun JavaScript chuẩn, nên chúng có thể sử dụng câu lệnh nhập và xuất. Giống như tất cả các mô-đun JavaScript, các phần phụ thuộc chỉ được thực thi một lần trong một ngữ cảnh nhất định (luồng chính, worker, v.v.) và tất cả các lần nhập trong tương lai đều tham chiếu đến thực thể mô-đun đã thực thi. Trình duyệt cũng tối ưu hoá việc tải và thực thi các mô-đun JavaScript. Bạn có thể tải các phần phụ thuộc của mô-đun trước khi thực thi mô-đun, nhờ đó có thể tải toàn bộ cây mô-đun song song. Quá trình tải mô-đun cũng lưu mã đã phân tích cú pháp vào bộ nhớ đệm, tức là các mô-đun được dùng trên luồng chính và trong một worker chỉ cần được phân tích cú pháp một lần.
Việc chuyển sang mô-đun JavaScript cũng cho phép sử dụng nhập động để tải chậm mã mà không chặn quá trình thực thi của worker. Tính năng nhập động rõ ràng hơn nhiều so với việc sử dụng importScripts() để tải các phần phụ thuộc, vì các tệp xuất của mô-đun đã nhập được trả về thay vì dựa vào các biến toàn cục.
worker.js:
import { sayHello } from './greet.js';
addEventListener('message', e => {
postMessage(sayHello());
});
greet.js:
import greetings from './data.js';
export function sayHello() {
return greetings.hello;
}
Để đảm bảo hiệu suất cao, phương thức importScripts() cũ không hoạt động trong trình chạy mô-đun. Việc chuyển đổi worker sang sử dụng mô-đun JavaScript có nghĩa là tất cả mã đều được tải ở chế độ nghiêm ngặt. Một thay đổi đáng chú ý khác là giá trị của this trong phạm vi cấp cao nhất của mô-đun JavaScript là undefined, trong khi ở trình chạy thông thường, giá trị này là phạm vi chung của trình chạy. May mắn là luôn có một self toàn cục cung cấp thông tin tham chiếu đến phạm vi toàn cục. API này có trong tất cả các loại trình chạy, bao gồm cả trình chạy dịch vụ, cũng như trong DOM.
Tải trước worker bằng modulepreload
Một điểm cải thiện đáng kể về hiệu suất đi kèm với trình chạy mô-đun là khả năng tải trước trình chạy và các phần phụ thuộc của trình chạy. Với trình chạy mô-đun, tập lệnh được tải và thực thi dưới dạng mô-đun JavaScript chuẩn, tức là chúng có thể được tải trước và thậm chí được phân tích cú pháp trước bằng modulepreload:
<!-- preloads worker.js and its dependencies: -->
<link rel="modulepreload" href="worker.js">
<script>
addEventListener('load', () => {
// our worker code is likely already parsed and ready to execute!
const worker = new Worker('worker.js', { type: 'module' });
});
</script>
Cả luồng chính và trình chạy mô-đun đều có thể sử dụng các mô-đun được tải trước. Điều này hữu ích cho các mô-đun được nhập trong cả hai ngữ cảnh hoặc trong trường hợp không thể biết trước liệu một mô-đun sẽ được sử dụng trên luồng chính hay trong một worker.
Trước đây, các lựa chọn có sẵn để tải trước tập lệnh trình chạy web bị hạn chế và không nhất thiết phải đáng tin cậy. Worker cổ điển có loại tài nguyên "worker" riêng để tải trước, nhưng không có trình duyệt nào triển khai <link rel="preload" as="worker">. Do đó, kỹ thuật chính
để tải trước trình chạy web là sử dụng <link rel="prefetch">, hoàn toàn dựa vào
bộ nhớ đệm HTTP. Khi được sử dụng kết hợp với các tiêu đề lưu vào bộ nhớ đệm chính xác, điều này giúp
tránh việc tạo thực thể worker phải chờ tải tập lệnh worker xuống. Tuy nhiên, không giống như modulepreload, kỹ thuật này không hỗ trợ tải trước các phần phụ thuộc hoặc phân tích cú pháp trước.
Còn trình chạy dùng chung thì sao?
Trình chạy dùng chung đã được cập nhật để hỗ trợ các mô-đun JavaScript kể từ Chrome 83. Giống như trình chạy chuyên dụng,
việc tạo trình chạy dùng chung bằng tuỳ chọn {type:"module"} hiện sẽ tải tập lệnh trình chạy dưới dạng
mô-đun thay vì tập lệnh thông thường:
const worker = new SharedWorker('/worker.js', {
type: 'module'
});
Trước khi hỗ trợ các mô-đun JavaScript, hàm khởi tạo SharedWorker() chỉ yêu cầu một URL và một đối số name không bắt buộc. Cách này sẽ tiếp tục hoạt động đối với việc sử dụng trình chạy dùng chung cổ điển; tuy nhiên, việc tạo trình chạy dùng chung mô-đun yêu cầu sử dụng đối số options mới. Các tuỳ chọn có sẵn cũng giống như các tuỳ chọn cho worker chuyên dụng, bao gồm cả tuỳ chọn name thay thế đối số name trước đó.
Còn trình chạy dịch vụ thì sao?
Thông số kỹ thuật của trình chạy dịch vụ đã được cập nhật để hỗ trợ việc chấp nhận mô-đun JavaScript làm điểm truy cập, sử dụng cùng một tuỳ chọn {type:"module"} làm trình chạy mô-đun, tuy nhiên, thay đổi này vẫn chưa được triển khai trong trình duyệt. Khi điều đó xảy ra, bạn có thể tạo thực thể cho một trình chạy dịch vụ bằng mô-đun JavaScript bằng mã sau:
navigator.serviceWorker.register('/sw.js', {
type: 'module'
});
Giờ đây, khi thông số kỹ thuật đã được cập nhật, các trình duyệt đang bắt đầu triển khai hành vi mới. Việc này cần có thời gian vì có một số vấn đề phức tạp khác liên quan đến việc đưa các mô-đun JavaScript vào trình chạy dịch vụ. Quá trình đăng ký trình chạy dịch vụ cần so sánh các tập lệnh đã nhập với phiên bản đã lưu vào bộ nhớ đệm trước đó khi xác định xem có kích hoạt bản cập nhật hay không. Điều này cần được triển khai cho các mô-đun JavaScript khi dùng cho trình chạy dịch vụ. Ngoài ra, trình chạy dịch vụ cần có khả năng bỏ qua bộ nhớ đệm cho các tập lệnh trong một số trường hợp nhất định khi kiểm tra bản cập nhật.