Các trang web bên trong một ứng dụng native

Một ứng dụng máy tính để bàn có động cơ web tích hợp chạy các trang của nó trong một tiến trình riêng, bị cô lập. Cơ chế native bao phủ ứng dụng và dừng lại ở ranh giới đó - nên cửa sổ chuyển sang ngày bạn yêu cầu còn bảng điều khiển bên trong nó thì không. Phần này lấp khoảng trống đó.

Thất bại trông giống như thành công

Rất nhiều ứng dụng Windows là native ở bên ngoài và là một trang web ở bên trong. Một màn hình cài đặt, một bảng điều khiển, một khung xem báo cáo, một bảng giấy phép - xây một lần bằng HTML và được lưu trữ trong WebView2 hoặc Qt WebEngine thay vì viết hai lần.

Động cơ chạy các trang đó trong tiến trình riêng của nó, và tiến trình đó bị cô lập. Một thư viện được chèn vào ứng dụng không vào được đó. Mọi thứ ứng dụng hỏi Windows đều chuyển sang ngày của phiên, còn mọi thứ trang hỏi JavaScript thì không:

Thanh tiêu đề, nhật ký và tệp đều nói 2038.
Bảng điều khiển trong cùng cửa sổ nói hôm nay.
Không có lỗi, không có cảnh báo, và cả hai nửa trông đều tự tin như nhau.

Đây là phiên bản tốn kém của lỗi này, vì bài kiểm thử dường như đã chạy. Hành vi cũ báo một phiên như vậy là qua sạch sẽ, một khẳng định mà công cụ không thể chứng minh.

Thay vào đó phiên làm gì

Phiên chạy cả hai cơ chế cùng lúc. Hook native đi vào ứng dụng như thường lệ, còn các trang được tiếp cận theo cách duy nhất để chạm đến một renderer bị cô lập: hỏi chính động cơ.

Khi khởi chạy, ứng dụng kế thừa hai biến môi trường yêu cầu động cơ của nó mở một cổng gỡ lỗi cục bộ. Chúng được nối thêm vào các công tắc mà ứng dụng vốn đã truyền, chứ không thay thế chúng. Sau đó phiên theo dõi các tiến trình của chính nó cho đến khi cổng đó xuất hiện, và khi nó xuất hiện, mọi trang và mọi worker phía sau chuyển sang cùng đồng hồ với ứng dụng.

Một điểm bắt đầu, một tốc độ, một dòng thời gian. Một thay đổi tốc độ hay một bước nhảy đến ứng dụng và các trang của nó cùng lúc, và bộ hẹn giờ của các trang chạy theo nhịp của ứng dụng chứ không theo nhịp riêng.

Nó được bật theo mặc định và tắt bằng một công tắc, công tắc đó không mở cổng nào cả và để các trang chạy theo đồng hồ thật.

# Không có gì cần cấu hình - động cơ được tìm thấy nếu có
chrono run "C:\Program Files\YourApp\YourApp.exe" --at 2038-01-01T00:00:00 --mode x60

# Hoặc để yên các trang, và không mở cổng nào
chrono run "C:\Program Files\YourApp\YourApp.exe" --at 2038-01-01T00:00:00 --no-embedded

Báo cáo nói gì về các trang

Các trang không bị gộp vào số liệu của riêng ứng dụng. Chúng được đếm như những đơn vị riêng, vì một tiến trình và một trang là hai thứ khác nhau, và cộng chúng lại sẽ bịa ra một con số vô nghĩa:

Dòng tiêu đề đếm cả hai - processes: 4, contexts: 1.
Mỗi trang có các dòng riêng, chẳng hạn context 1: page Date.now (12 calls) trên dòng lệnh và page Date.now - fake clock trong bảng kiểm toán của cửa sổ.
Động cơ đã tiếp cận được nêu tên cùng cổng của nó, để bạn có thể trỏ DevTools của chính mình vào đúng các trang mà phiên đang điều khiển.

Một lần chạy thử (dry run) cho biết các trang có được tiếp cận không trước khi bất cứ gì được khởi động. Các kết luận có nghĩa là gì →

Ba giới hạn đáng biết trước khi bắt đầu

Một cổng gỡ lỗi mở suốt khi động cơ còn chạy.

Nó chỉ lắng nghe trên máy này, nhưng nó mở với bất kỳ chương trình nào trên máy này chừng nào động cơ còn chạy, và bất cứ thứ gì với tới được nó đều có thể điều khiển các trang đó. Phiên cảnh báo điều này mỗi lần một cổng được mở, và nêu tên cổng chứ không nhắc chung chung. Trên máy dùng chung hoặc không đáng tin, hãy dùng công tắc không mở gì cả.

Ứng dụng chạy với quyền nâng cao thì ngoài tầm với.

Một động cơ do ứng dụng chạy quyền nâng cao lưu trữ sẽ bỏ qua các biến mà phiên đặt, nên các trang của nó vẫn ở đồng hồ thật. Đây là quy tắc riêng của động cơ, không phải một thiết lập, và không có cách nào vượt qua từ bên ngoài.

Một phiên như vậy báo PARTIAL, và đó là câu trả lời trung thực.

Các tiến trình phụ trợ của động cơ, và các lệnh gọi thời gian native của chính renderer, vẫn ở đồng hồ thật. Các trang ở đồng hồ phiên còn phần còn lại của nhóm thì không, nên kết luận nói một phần và nêu tên những gì bị bỏ sót, thay vì làm tròn lên thành đạt.

Hai điều nhỏ hơn, nói thẳng. Các trang đọc múi giờ của phiên như một độ lệch cố định, nên Intl gọi nó bằng độ lệch, ví dụ GMT+02:00, chứ không phải tên thành phố. Và một bộ hẹn giờ đã được lên lịch trước khi phiên đến được trang giữ nguyên nhịp cũ, giống hệt như trong một phiên Chromium thuần - phiên cảnh báo thay vì để bạn kết luận rằng không có gì xảy ra.

Nếu động cơ được cấu hình qua chính sách đối số trình duyệt trong registry, biến của phiên được ưu tiên trong suốt thời gian phiên, và báo cáo nói rõ điều đó - vì một cổng gỡ lỗi bạn thiết lập ở đó sẽ không được áp dụng.

Được kiểm thử tốt đến đâu

Thử nghiệm, với cùng nghĩa xác định như ở các chỗ khác trên trang này: nó hoạt động trên các mục tiêu mà nó được xây dựng để chống lại, chưa được kiểm thử rộng rãi, và kiểm toán tích hợp sẵn là nguồn chân lý của bạn chứ không phải trang này. Nó được đo thủ công trên một máy chủ WebView2 và một máy chủ Qt WebEngine chạy Windows 64-bit, không phải bằng bộ kiểm thử tự động. Trong các lần chạy đó, các trang đọc năm của phiên với tốc độ của phiên và theo kịp một bước nhảy.

Trên Windows 32-bit có một điểm rắc rối đáng biết hơn là phải tự khám phá: runtime WebView2 là 64-bit ngay cả khi ứng dụng lưu trữ nó là 32-bit, nên một phiên 32-bit không thể nêu tên các tiến trình của động cơ hay vai trò của chúng. Kênh đến các trang vẫn hoạt động. Báo cáo chỉ kém cụ thể hơn về những gì nó không nhận diện được, và nói rõ đó là trường hợp nào trong hai.

Dùng thử

Tải về cho Windows Đọc FAQ