Lời mở đầu: Tôi rất yêu thích Unity! Bài viết này hoàn toàn không nhằm mục đích chỉ trích Unity, mà là những chia sẻ thực tế từ góc nhìn phát triển ứng dụng.

Bạn có đang cảm thấy kiệt sức khi phải cố gắng tích hợp đồ họa 3D vào các ứng dụng doanh nghiệp (business applications)? Khi cần xử lý 3D trên ứng dụng desktop, nhiều nhà phát triển thường chọn Unity theo phản xạ tự nhiên. Tuy nhiên, đó có thực sự là "giải pháp tối ưu nhất"?

Unity từng được coi là một nền tảng vững chắc, nhưng hiện tại, việc áp dụng nó vào các ứng dụng phi trò chơi đang vấp phải những thách thức lớn không thể ngó lơ.

Những thách thức lớn khi dùng Unity cho ứng dụng doanh nghiệp

1. Rủi ro về chính sách cấp phép và sự bất ổn

Vào năm 2023, việc Unity công bố áp dụng chính sách "Runtime Fee" (thu phí dựa trên số lượt cài đặt) đã gây chấn động cộng đồng nhà phát triển toàn cầu. Dù sau đó họ đã hủy bỏ và điều chỉnh chính sách này, sự việc đã làm lộ rõ một rủi ro lớn: "Vendor lock-in" (bị phụ thuộc hoàn toàn vào nhà cung cấp). Mô hình kinh doanh của bạn có thể bị thay đổi bất cứ lúc nào theo ý muốn đơn phương của nền tảng.

2. Bộ cài đặt (Runtime) quá nặng

Ngay cả khi bạn chỉ cần hiển thị một mô hình 3D đơn giản, Unity vẫn đóng gói toàn bộ các tính năng của một game engine vào sản phẩm. Kết quả là file cài đặt lên đến hàng trăm MB, làm chậm tốc độ khởi động và tiêu tốn nhiều bộ nhớ — điều khó chấp nhận đối với một ứng dụng doanh nghiệp chuyên nghiệp.

3. Khó khăn trong việc xây dựng giao diện (UI)

Các công cụ xây dựng UI của Unity (uGUI hay UI Toolkit) vốn được thiết kế riêng cho game. Khi cần làm các giao diện chuẩn doanh nghiệp như: hệ thống form nhập liệu lớn, bảng dữ liệu phức tạp hay các tính năng hỗ trợ tiếp cận (accessibility), nhà phát triển phải mất rất nhiều thời gian và công sức. Trong khi đó, nếu sử dụng công nghệ Web, những giao diện này chỉ tốn vài dòng code.

4. Kém tương thích trong kỷ nguyên AI

Đây là vấn đề mang tính thời đại lớn nhất. Các ứng dụng sử dụng LLM (mô hình ngôn ngữ lớn) hoặc AI agent đòi hỏi khả năng hiển thị text streaming, render Markdown và thay đổi layout một cách linh hoạt. Việc xử lý những tác vụ này bên trong một "hộp đen" được build sẵn như Unity là cực kỳ khó khăn. Hơn nữa, nếu bạn muốn chạy các tiến trình AI dưới dạng "Headless" (không màn hình) ở phía backend, một engine nặng nề như Unity sẽ trở thành một rào cản lớn.

Vậy giải pháp thay thế là gì?

Từ những trăn trở trên, trong vài năm qua, tôi đã thực hiện một hành trình dài để tìm kiếm phương pháp phát triển ứng dụng 3D doanh nghiệp mà không bị lệ thuộc vào Unity. Những chia sẻ dưới đây là kết quả của hành trình đó — một kiến trúc tối giản, lược bỏ những phần không cần thiết để giải thoát khỏi những rắc rối cũ.

Tại sao chuyển sang .NET thôi là chưa đủ?

Nhiều người sẽ nghĩ: Cách đơn giản nhất để rời Unity là chuyển sang dùng .NET, vì chúng ta có thể tiếp tục sử dụng ngôn ngữ C#. Ban đầu tôi cũng lạc quan như vậy. Việc dùng .NET về cơ bản là hướng đi đúng, nhưng .NET lại gặp một vấn đề nghiêm trọng: Nó không có một thư viện render 3D tiêu chuẩn chuyên dụng. Do đó, chúng ta phải tự tìm kiếm một giải pháp render 3D có thể kết hợp với .NET.

Kết luận: Three.js là lựa chọn tối ưu nhất

Nếu không tính Unity và Unreal Engine, Three.js là thư viện duy nhất có hệ sinh thái mạnh mẽ và được kiểm chứng qua vô số dự án thực tế. Xét về quy mô cộng đồng, Three.js vượt trội hơn hẳn các nền tảng khác. Vì vậy, bước đầu tiên để từ bỏ Unity chính là tìm cách tiếp cận và làm việc với Three.js.

Có nên chuyển hẳn sang dùng TypeScript?

Đối với nhiều dự án, việc xây dựng ứng dụng 3D hoàn chỉnh bằng TypeScript và Three.js kết hợp với framework như Electron là hoàn toàn khả thi. Nếu ứng dụng của bạn có 90% tính năng tập trung vào hiển thị 3D và thao tác UI, không cần can thiệp sâu vào phần cứng hay tận dụng tài nguyên C# có sẵn, thì Electron sẽ là lựa chọn giúp tiết kiệm công sức nhất. Thực tế, tôi cũng đã phát triển nhiều ứng dụng theo cách này.

Ngay cả với những ai muốn phát triển các tựa game casual, sự kết hợp giữa TypeScript + Three.js vẫn hoàn toàn đáp ứng tốt, thậm chí có thể tận dụng ngay cho các quảng cáo tương tác (playable ads).

Nhìn lại những thế mạnh cốt lõi của .NET

Tuy nhiên, đối với các hệ thống lớn và phức tạp, .NET vẫn chứng minh được sức mạnh vượt trội so với JS/TS trong việc xử lý các tác vụ nặng:

Tính toán nặng bằng "Multi-threading thực sự"JavaScript hoạt động trên cơ chế single-thread (đơn luồng). Ngược lại, C# là chuyên gia trong việc xử lý song song, có thể huy động toàn bộ các core của CPU. Bằng cách sử dụng Parallel.For hoặc Task, bạn có thể xử lý tính toán hàng triệu điểm đỉnh (vertices), mô phỏng vật lý phức tạp hoặc xử lý lượng lớn hình ảnh đồng thời trên các CPU 8 core hay 16 core.
Giao tiếp trực tiếp với phần cứng và cảm biếnNếu ứng dụng của bạn cần kết nối với các thiết bị ngoại vi (hệ thống PLC trong nhà máy, giao tiếp qua cổng RS-232C, các thiết bị USB chuyên dụng, camera y tế...), .NET là lựa chọn hàng đầu nhờ hệ thống thư viện chuẩn (BCL) và các bộ SDK chính thức từ nhà sản xuất hoạt động rất ổn định.
Kiểm soát chính xác việc quản lý bộ nhớTrong ứng dụng 3D, điều đáng sợ nhất là hiện tượng giật lag khung hình do cơ chế Garbage Collection (GC) của JavaScript tự động kích hoạt mà nhà phát triển không thể kiểm soát. Với các phiên bản .NET hiện đại, các tính năng như Span<T>, Memory<T> hoặc cơ chế biên dịch Native AOT giúp hệ thống tính toán liên tục mà không làm ảnh hưởng đến bộ nhớ, đảm bảo duy trì tốc độ 60 frame/giây ổn định.
Hỗ trợ hệ thống định nghĩa phức tạp và đồ sộLogic trong không gian 3D bao gồm rất nhiều vector, ma trận, quaternion và xử lý va chạm. Hệ thống type của C# nghiêm ngặt hơn TypeScript, kết hợp với các tính năng toán học nâng cao giúp quản lý mã nguồn của các engine vật lý lớn một cách gọn gàng, giảm thiểu tối đa các bug phát sinh.

Giải pháp kiến trúc: .NET + Three.js

Từ những phân tích trên, mô hình lý tưởng chính là: Dùng C# (.NET) để xử lý logic cốt lõi và dùng Three.js (TypeScript) thuần túy cho việc hiển thị đồ họa.

Hệ thống sẽ tính toán mọi dữ liệu lớn trong C#, sau đó chỉ gửi dữ liệu mesh 3D đã được tinh gọn sang phía Three.js để render.

Cách tối ưu hóa kết nối giữa Three.js và .NET

Để tránh việc JavaScript Garbage Collection tạo ra nút thắt cổ chai khi nhận dữ liệu từ C#, chúng ta không sử dụng cách tuần tự hóa dữ liệu thông thường (như JSON.stringify). Thay vào đó, chúng ta áp dụng các phương pháp như Shared Array Buffer hoặc truyền bộ nhớ trực tiếp. Trong WebView2, bộ nhớ chia sẻ từ phía C# có thể được tham chiếu trực tiếp dưới dạng TypedArray phía JS, giúp giảm thiểu chi phí shadow copy và bỏ qua việc quản lý bộ nhớ của JS.

Bằng cách biến Three.js thành một lớp bọc hiển thị mỏng (Thin Wrapper) nhận dữ liệu nhị phân trực tiếp xuống GPU và để C# đảm nhận toàn bộ phần tính toán vật lý, chúng ta sẽ loại bỏ được các độ trễ không mong muốn của JavaScript. Hơn nữa, việc Three.js hỗ trợ WebGPU giúp giao tiếp trực tiếp với GPU tốt hơn, giảm đáng kể chi phí xử lý ở tầng driver.

Giới hạn nào cho giải pháp này?

Kiến trúc này đáp ứng được hầu hết các dự án 3D thông thường. Tuy nhiên, bạn nên cân nhắc sử dụng C# native (như Stride hoặc Silk.NET) hoặc C++ trong các trường hợp sau:

Dữ liệu CAD siêu lớn (hàng chục triệu polygon): Dễ vượt quá giới hạn bộ nhớ của trình duyệt (thường khoảng 4GB).
Đồng bộ hóa ở mức micro giây (như ứng dụng VR): Yêu cầu độ trễ cực thấp dưới 1ms để tránh gây chóng mặt cho người dùng. Đối với VR, việc tiếp tục phụ thuộc vào các game engine như Unity hay Unreal vẫn là lựa chọn an toàn nhất.

Kết nối siêu mỏng: Kiến trúc lỏng lẻo (Loose Coupling) từ Photino

Một lợi ích khác khi không dùng Unity là việc phát triển UI trở nên dễ dàng hơn nhờ tận dụng được sức mạnh của HTML/CSS và hệ sinh thái của các nhà thiết kế Web.

Để kết nối .NET với công nghệ Web, thay vì dùng Blazor Hybrid (vốn áp đặt một tư duy framework cụ thể), tôi thử nghiệm áp dụng Photino.NET. Đây là một giải pháp kết nối rất mỏng và nhẹ. Phần Web chỉ đóng vai trò hiển thị độc lập, còn .NET sẽ đưa ra chỉ thị dựa trên cơ chế hướng sự kiện (event-driven). Kiến trúc lỏng lẻo này giúp việc thay đổi hoặc nâng cấp công nghệ trong tương lai trở nên rất dễ dàng.

Các phương án thay thế khác đã được cân nhắc

Trong quá trình tìm kiếm giải pháp, tôi cũng đã thử nghiệm qua các công nghệ khác nhưng chưa đạt được kết quả như kỳ vọng cho ứng dụng doanh nghiệp:

GodotĐiểm khiến tôi chưa thoải mái khi thử nghiệm Godot là sự xuất hiện của các file .uid (khá giống với các file .meta phiền toái của Unity). Ngoài ra, việc phải học thêm một hệ thống quản lý UI đặc thù và riêng biệt của Godot đòi hỏi nhiều thời gian, nhưng lợi ích mang lại cho ứng dụng doanh nghiệp chưa thực sự tương xứng.
.NET + Stride 3DĐây là một engine mã nguồn mở viết bằng C# rất tiềm năng cho cộng đồng .NET. Tuy nhiên, thực tế thử nghiệm cho thấy Stride phụ thuộc nhiều vào DirectX, khiến việc hỗ trợ ổn định cho macOS và iOS (sử dụng Metal) hiện tại gặp nhiều hạn chế. Việc bị giới hạn trong môi trường Windows là một điểm bất lợi khi cần phát triển đa nền tảng.Đặc biệt, Stride chưa hỗ trợ tốt Blendshape (Morph Targets) — tính năng bắt buộc phải có để xử lý biểu cảm khuôn mặt và hát nhép (lip-sync) cho các avatar hoặc AI agent hiện đại ngày nay.

(Lưu ý: Nếu dự án của bạn không cần đến các tính năng như Blendshape và chỉ chạy trên Windows, Stride vẫn là một lựa chọn tốt để hoàn thiện cả logic và 3D thuần C#).

Kết luận: Chúng ta hoàn toàn có thể chuyển dịch khỏi Unity

Kiến trúc tối giản mà tôi đang áp dụng cho các ứng dụng 3D doanh nghiệp hiện tại bao gồm:

🧠 Tính toán (Compute): .NET
🎨 Hiển thị (Render): Three.js (TypeScript)
🔗 Kết nối (Bridge): Photino.NET

Giải pháp này giúp loại bỏ sự phụ thuộc vào một hộp đen công nghệ lớn. Mục tiêu cốt lõi không phải là bài trừ Unity, mà là tìm ra công cụ phù hợp nhất cho từng dự án — cho dù đó là Electron, .NET hay Stride — để giữ được sự linh hoạt cao nhất.

Nếu bạn đang tìm kiếm giải pháp xây dựng các ứng dụng 3D mạnh mẽ, có tính chịu tải cao cho doanh nghiệp bên ngoài môi trường Unity, hãy liên hệ với chúng tôi để cùng thảo luận và nhận được sự hỗ trợ tốt nhất.

Vitalify Asia Blog

Từ bỏ Unity: Nhìn lại tương lai phát triển ứng dụng từ kinh nghiệm 10 năm làm việc với Unity