Trước đây, mỗi ứng dụng bạn tạo bằng ứng dụng WebCatalog trên máy tính chiếm khoảng 320 MB dung lượng đĩa trên macOS. Điều này không lạ đối với một ứng dụng dựa trên Electron, nhưng WebCatalog được thiết kế cho những người dùng nhiều ứng dụng web dưới dạng ứng dụng máy tính. Cài đặt mười ứng dụng như vậy có thể tốn hơn 3 GB, dù phần lớn dữ liệu bên trong chúng hoàn toàn giống nhau.
Gần đây, chúng tôi đã thay đổi cách ứng dụng WebCatalog trên máy tính tạo ứng dụng trên macOS. Ứng dụng đầu tiên hiện dùng khoảng 340 MB dung lượng đĩa thực tế, bao gồm một bản sao của bộ máy ứng dụng đã được chuẩn bị và lưu trên máy. Sau đó, mỗi ứng dụng bổ sung thường chỉ làm tăng 1–2 MB dung lượng đĩa thực tế. Trong thử nghiệm của chúng tôi, mười ứng dụng đã giảm từ hơn 3 GB xuống khoảng 360 MB.
Chúng tôi làm được điều này nhờ một tính năng có sẵn trong macOS: bản sao APFS. Điểm đáng chú ý không chỉ là sao chép tệp, mà là khiến cơ chế này hoạt động trong khi mỗi ứng dụng vẫn độc lập, được ký mã đúng cách và hoạt động tương đương ứng dụng được tạo bằng quy trình cũ.
Vì sao mỗi ứng dụng lại tốn thêm 320 MB
Ứng dụng WebCatalog trên máy tính biến các trang web thành ứng dụng máy tính độc lập. Mỗi ứng dụng bạn tạo đều chạy trên Photon, bộ máy ứng dụng của chúng tôi được xây dựng trên Electron. Trên macOS, mỗi ứng dụng là một gói .app thông thường, chứa Electron (Chromium và Node.js), Photon cùng các tệp dành riêng cho ứng dụng đó.
Lấy hai ứng dụng Slack và Discord làm ví dụ. Tên, biểu tượng, mã định danh gói và cấu hình của chúng khác nhau, nhưng bộ framework Electron lớn và phần lớn Photon thì giống hệt nhau.
Trước đây, mỗi ứng dụng được tạo thành một bản sao hoàn toàn riêng biệt.
Slack.app
Electron
Photon
Các tệp riêng của Slack
Discord.app
Electron
Photon
Các tệp riêng của Discord
Framework Electron và Photon có thể giống hệt nhau đến từng byte trong cả hai ứng dụng, nhưng macOS vẫn lưu thêm một bản sao vật lý cho mỗi ứng dụng. Vì vậy, mười ứng dụng đồng nghĩa với khoảng mười bản sao của những gói ứng dụng 320 MB gần như giống hệt nhau.
Kiến trúc đó có một đặc tính mà chúng tôi muốn giữ lại: mỗi ứng dụng hoàn toàn độc lập. Xóa một ứng dụng không thể ảnh hưởng đến ứng dụng khác, và các ứng dụng đã cài đặt không phụ thuộc vào việc ứng dụng WebCatalog trên máy tính có còn trên hệ thống hay không.
Điều chúng tôi muốn loại bỏ là sự trùng lặp không cần thiết ở bên dưới.
APFS đã có sẵn cơ chế nền tảng mà chúng tôi cần
Các máy Mac hiện đại sử dụng hệ thống tệp APFS của Apple. APFS hỗ trợ tạo bản sao, một cơ chế sao chép khi ghi cho phép hai tệp độc lập dùng chung dữ liệu vật lý cho đến khi một trong hai thay đổi.
Hãy hình dung bạn sao chép một tệp 300 MB. Với cách sao chép thông thường, macOS ghi thêm 300 MB xuống đĩa, nên hai tệp chiếm tổng cộng khoảng 600 MB.
Với bản sao APFS, tệp mới vẫn trông và hoạt động như một tệp 300 MB hoàn chỉnh, nhưng ban đầu nó tham chiếu đến cùng các khối vật lý với tệp gốc.
Tệp A ─────┐
├── các khối vật lý dùng chung
Tệp B ─────┘
Nếu sau này một phần của Tệp B thay đổi, APFS chỉ ghi các khối mới cho dữ liệu đã thay đổi. Mọi phần vẫn giống nhau có thể tiếp tục dùng chung các khối gốc.
Tệp A ───────── các khối dùng chung
Tệp B ───────── các khối dùng chung
└──────── các khối đã thay đổi
Từ góc nhìn của ứng dụng, Tệp A và Tệp B là hai tệp riêng biệt. Từ góc nhìn của ổ SSD, dữ liệu giống nhau chỉ cần được lưu một lần.
Đó gần như chính xác là điều chúng tôi cần.
Tạo ứng dụng từ một bản nền chung
Ứng dụng WebCatalog trên máy tính hiện chuẩn bị một bản nền cho mỗi tổ hợp phiên bản Electron và Photon. Ứng dụng Photon nền chứa những phần giống nhau giữa các ứng dụng, bao gồm Electron, Photon, cấu trúc framework và các chữ ký dùng chung.
Khi tạo một ứng dụng khác sử dụng cùng các phiên bản đó, ứng dụng trên máy tính không còn giải nén và tạo một bản sao hoàn chỉnh khác từ đầu. Thay vào đó, nó tạo một bản sao APFS của ứng dụng Photon nền và chỉ tùy chỉnh những phần cần khác biệt.
Các phần đó bao gồm tên ứng dụng, biểu tượng, mã định danh gói, cài đặt, tên tệp thực thi, mã định danh bản dựng và những siêu dữ liệu khác dành riêng cho ứng dụng.
Vì phần lớn gói ứng dụng không thay đổi, APFS tiếp tục dùng chung các khối vật lý chứa Electron và Photon. Chỉ lượng dữ liệu tương đối nhỏ dành riêng cho ứng dụng mới chiếm thêm dung lượng.
Sao không dùng chung Electron?
Một cách có vẻ hiển nhiên hơn là cài Electron một lần rồi để mọi ứng dụng cùng trỏ đến nó.
Chúng tôi đã cân nhắc cách này, nhưng nó sẽ thay đổi căn bản mức độ tin cậy của hệ thống. Nếu bản cài đặt Electron dùng chung biến mất, mọi ứng dụng phụ thuộc vào nó có thể ngừng hoạt động. Một công cụ dọn bộ nhớ đệm có thể xóa nó; việc gỡ cài đặt ứng dụng WebCatalog trên máy tính cũng có thể xóa nó; còn việc di chuyển hoặc khôi phục từng ứng dụng sẽ trở nên phức tạp hơn.
Cách đó cũng đòi hỏi phải theo dõi ứng dụng đã cài đặt nào phụ thuộc vào phiên bản môi trường chạy nào để có thể dọn dẹp các phiên bản cũ một cách an toàn.
Tính năng ký mã của macOS còn gây ra một vấn đề khác. Quy trình xác minh chữ ký nghiêm ngặt từ chối các liên kết tượng trưng trỏ ra ngoài gói ứng dụng.
Bản sao APFS đem lại lợi ích của việc dùng chung mà không tạo ra sự phụ thuộc đó. Các ứng dụng đã cài đặt có thể dùng chung các khối đĩa vật lý mà vẫn là những gói ứng dụng đầy đủ, độc lập.
Xóa ứng dụng Photon nền không làm hỏng các ứng dụng được tạo từ nó. Xóa một ứng dụng đã cài đặt cũng không ảnh hưởng đến ứng dụng khác. Hệ thống tệp xử lý việc dùng chung, trong khi kiến trúc ứng dụng vẫn độc lập.
Việc ký mã suýt khiến lợi ích tiết kiệm dung lượng biến mất
Tạo bản sao ứng dụng chỉ giải quyết một phần vấn đề. Ứng dụng macOS còn cần được ký mã.
Quy trình tạo ứng dụng cũ của chúng tôi ký lại toàn bộ gói ứng dụng theo chiều sâu sau khi tùy chỉnh. Với một bản sao thông thường, điều đó không thành vấn đề. Nhưng với cơ chế lưu trữ sao chép khi ghi, việc sửa đổi một tệp nhị phân lớn có thể khiến APFS cấp phát các khối vật lý mới cho tệp đó.
Trong quá trình phát triển, chúng tôi đo được việc ký lại framework Electron làm tăng khoảng 194 MB dung lượng lưu trữ vật lý cho mỗi ứng dụng. Chúng tôi đã tránh sao chép Electron khi tạo ứng dụng, rồi lại nhân đôi phần lớn dữ liệu của nó ở bước ký mã.
Vì vậy, quy trình ký mã cũng phải thay đổi.
Framework lớn dùng chung giờ được ký trong ứng dụng Photon nền. Khi ứng dụng trên máy tính tạo bản sao từ bản nền đó, chúng tôi tránh sửa đổi các tệp nhị phân lớn đang được dùng chung và chỉ ký lại những phần nhỏ hơn thực sự cần khác nhau giữa các ứng dụng.
Sau khi hoàn tất ứng dụng, chúng tôi chạy quy trình xác minh chữ ký nghiêm ngặt trên gói ứng dụng cuối cùng để bảo đảm mọi thứ vẫn hợp lệ.
Nhờ đó, chúng tôi vừa duy trì được các bảo đảm về ký mã của macOS, vừa giữ được lợi ích tiết kiệm dung lượng từ APFS.
Khi yêu cầu Node.js tạo bản sao nhưng thực tế nó không làm vậy
Chúng tôi còn gặp một vấn đề bất ngờ khác: chính thao tác tạo bản sao.
Node.js cung cấp các cờ sao chép nhằm yêu cầu cơ chế sao chép khi ghi, bao gồm COPYFILE_FICLONE và COPYFILE_FICLONE_FORCE. Trên lý thuyết, chúng có vẻ chính là các API chúng tôi cần.
Trong thử nghiệm với Node.js 24, chúng tôi sao chép cùng một ứng dụng Electron 288 MB bằng nhiều cách và đo lượng dung lượng đĩa vật lý tăng thêm sau mỗi thao tác:
fs.cpSync +288 MB
fs.cpSync + COPYFILE_FICLONE +288 MB
fs.cpSync + COPYFILE_FICLONE_FORCE +288 MB
/bin/cp -c -R ~0 MB
Trong thử nghiệm của chúng tôi, cả hai chế độ tạo bản sao của Node.js vẫn tạo ra một bản sao vật lý đầy đủ. Ngay cả biến thể FORCE cũng không báo lỗi khi việc tạo bản sao như mong đợi không diễn ra.
Lệnh cp -c gốc của macOS hoạt động đúng như mong đợi, nên ứng dụng WebCatalog trên máy tính sử dụng trực tiếp cơ chế đó.
Đây cũng là lời nhắc hữu ích rằng cần kiểm chứng các tối ưu hóa hệ thống tệp bằng cách đo đạc chính hệ thống tệp. Gọi một API yêu cầu sao chép khi ghi không nhất thiết có nghĩa là các tệp tạo ra thực sự dùng chung dung lượng lưu trữ vật lý.
Bảo đảm tối ưu hóa có thể thất bại một cách an toàn
Tiết kiệm dung lượng đĩa là một bước tối ưu hóa. Cài đặt ứng dụng thành công thì không phải thứ có thể đánh đổi.
Chúng tôi thiết kế quy trình mới để việc tạo bản sao có thể thất bại mà không làm hỏng quá trình cài đặt ứng dụng. Nếu việc chuẩn bị ứng dụng Photon nền thất bại, bản nền trong bộ nhớ đệm bị hỏng, thao tác tạo bản sao thất bại hoặc quá trình xác minh chữ ký không đạt, ứng dụng trên máy tính sẽ quay về quy trình tạo ứng dụng trước đây, với việc giải nén và ký mã đầy đủ.
Vì vậy, trường hợp xấu nhất là ứng dụng dùng lượng dung lượng đĩa như trước, chứ không phải cài đặt thất bại.
Chúng tôi cũng phải tính đến việc xử lý đồng thời. Ứng dụng Photon nền trước tiên được chuẩn bị trong một thư mục tạm và chỉ được chuyển đến vị trí cuối cùng sau khi hoàn tất. Nhờ đó, hai quá trình tạo ứng dụng diễn ra cùng lúc không thể vô tình sử dụng một bản nền chưa được tạo xong.
Các bản nền cũ cũng có thể được xóa an toàn. Một bản sao APFS đã cài đặt không phụ thuộc vào việc bản nền gốc còn tồn tại hay không. Nếu bản nền bị xóa, bản sao vẫn giữ lại các khối vật lý mà nó đang dùng.
Cơ chế này hoạt động trên APFS, hệ thống tệp mặc định của mọi máy Mac hiện đại. Nếu ứng dụng của bạn nằm trên một ổ đĩa không hỗ trợ tạo bản sao, chẳng hạn ổ HFS+ hoặc exFAT gắn ngoài, ứng dụng WebCatalog trên máy tính sẽ chuyển sang sao chép thông thường. Khi đó, ứng dụng vẫn hoạt động như trước nhưng không tiết kiệm dung lượng. Hiện tại, Windows và Linux không có gì thay đổi.
Dung lượng logic và dung lượng vật lý không giống nhau
Một tác dụng phụ có thể gây nhầm lẫn là Finder vẫn có thể báo mỗi ứng dụng chiếm khoảng 320 MB.
Con số đó thể hiện dung lượng logic của ứng dụng. Ứng dụng thực sự chứa các tệp có tổng dung lượng khoảng 320 MB; nếu sao chép những tệp đó đến nơi khác mà không dùng cơ chế tạo bản sao, thì đó cũng gần bằng lượng dữ liệu cần ghi.
Điều thay đổi là dung lượng vật lý, tức số khối riêng biệt mà các tệp đó thực sự chiếm trên đĩa.
Nếu hai ứng dụng cùng chứa một framework 300 MB và APFS cho phép chúng dùng chung các khối vật lý bên dưới, mỗi ứng dụng vẫn có thể chứa 300 MB về mặt logic, trong khi ứng dụng thứ hai hầu như không làm tăng lượng dữ liệu vật lý.
Mục Get Info của Finder và các công cụ như du không nhất thiết thể hiện rõ việc dùng chung này. Lợi ích tiết kiệm thể hiện rõ nhất qua lượng dung lượng trống thực tế còn lại trên đĩa.
Chúng tôi đã kiểm chứng điều này với bảy ứng dụng thực tế: Discord, Facebook, Instagram, Messenger, TikTok và hai ứng dụng tùy chỉnh. Được tạo theo cách này, chúng tiết kiệm khoảng 1,9 GB dung lượng đĩa so với quy trình cũ.
Chúng tôi cũng kiểm tra vị trí vật lý của dữ liệu trên đĩa và xác nhận rằng các ứng dụng dùng chung dữ liệu Electron và Photon ở cấp độ khối. Một ứng dụng được tạo bằng quy trình cũ không dùng chung khối nào trong số đó, qua đó cung cấp một trường hợp đối chiếu hữu ích.
Kết quả
Với người chỉ tạo một ứng dụng bằng WebCatalog trên máy tính, khác biệt không lớn. Ứng dụng đầu tiên thực tế dùng nhiều dung lượng đĩa hơn trước một chút, vì ứng dụng trên máy tính còn lưu ứng dụng Photon nền để tạo các bản sao tiếp theo.
Sau đó, lợi ích tăng lên nhanh chóng.
Trước đây
1 ứng dụng ~320 MB
10 ứng dụng >3 GB
Với cơ chế tạo bản sao APFS:
Hiện nay
1 ứng dụng ~340 MB
10 ứng dụng ~360 MB
Sau khi bản nền ban đầu được tạo, mỗi ứng dụng bổ sung thường chỉ làm tăng 1–2 MB dung lượng đĩa vật lý.
Điều quan trọng là chúng tôi đạt được kết quả này mà không tạo ra sự phụ thuộc vào một môi trường chạy dùng chung. Mỗi ứng dụng vẫn là một ứng dụng macOS thông thường, đầy đủ và độc lập, trong khi APFS chỉ lưu dữ liệu Electron và Photon giống nhau một lần. Với khoảng mười ứng dụng được cài đặt, cách này có thể giảm dung lượng đĩa thực tế sử dụng xuống hơn tám lần.
Tính năng này có trong phiên bản mới nhất của ứng dụng WebCatalog trên máy tính dành cho macOS. Bạn không cần bật gì cả: các ứng dụng mới sẽ tự động sử dụng tính năng này, còn các ứng dụng bạn đã có sẽ giảm dung lượng vào lần cập nhật tiếp theo.