Thời gian chạy Windows 8 (ứng dụng WinRT / Windows Store / Windows 10 Universal) so với Silverlight và WPF như thế nào? [đóng cửa]

Tôi đang cố gắng hoàn thành Windows 8 Runtime mới được sử dụng để tạo các ứng dụng kiểu Metro . Tôi biết bạn có thể sử dụng nó với XAML và nó dựa trên .NET vì vậy C # và VB.NET có thể được sử dụng để viết các ứng dụng, nhưng sau đó nó dường như có liên quan đến HTML, CSS, DOM và JavaScript.

Ai đó có thể giải thích nó là gì trong một vài đoạn, theo thuật ngữ mà một lập trình viên UI UI có thể hiểu được không? (Tôi đang thiếu một thứ gì đó, chính là khóa cần thiết để hiểu nó.)

Chúng ta đều biết rằng WPF, Silverlight , Windows Forms , v.v. sẽ tiếp tục hoạt động trong Windows 8 (và Windows 10) ít nhất trên các hệ thống Intel, vì vậy xin đừng nói với tôi rằng ...

Ở cấp độ thấp nhất, WinRT là một mô hình đối tượng được xác định ở cấp độ ABI. Nó sử dụng COM làm cơ sở (vì vậy mọi đối tượng WinRT đều thực hiện IUnknownvà thực hiện đếm lại) và xây dựng từ đó. Nó bổ sung khá nhiều khái niệm mới so với COM cũ, hầu hết trong số đó đến trực tiếp từ .NET - ví dụ, mô hình đối tượng WinRT có các đại biểu và các sự kiện được thực hiện theo kiểu .NET (với các đại biểu và thêm / xóa thuê bao phương thức, một cho mỗi sự kiện) chứ không phải mô hình COM cũ của nguồn và sự kiện chìm. Trong số những điều đáng chú ý khác, WinRT cũng có giao diện ("chung").

Một thay đổi lớn khác là tất cả các thành phần WinRT đều có sẵn siêu dữ liệu cho chúng, giống như các cụm .NET. Trong COM, bạn có thể sử dụng typelibs, nhưng không phải thành phần COM nào cũng có chúng. Đối với WinRT, siêu dữ liệu được chứa trong các tệp .winmd - hãy xem bên trong "C: \ Program Files (x86) \ Windows Kits \ 8.0 \ Windows Metadata \" trong Bản xem trước dành cho nhà phát triển. Nếu bạn chọc ngoáy, bạn sẽ thấy rằng chúng thực sự là các cụm CLI không có mã, chỉ là các bảng siêu dữ liệu. Thực tế, bạn có thể mở chúng bằng ILDASM. Lưu ý, điều này không có nghĩa là chính WinRT được quản lý - nó chỉ đơn giản là sử dụng lại định dạng tệp.

Sau đó, có một số thư viện được triển khai theo mô hình đối tượng đó - xác định các giao diện và lớp WinRT. Một lần nữa, hãy xem thư mục "Siêu dữ liệu Windows" được đề cập ở trên để xem những gì ở đó; hoặc chỉ cần kích hoạt Trình duyệt đối tượng trong VS và chọn "Windows 8.0" trong bộ chọn khung, để xem những gì được bảo hiểm. Có rất nhiều ở đó, và nó không giải quyết một mình với UI - bạn cũng có được các không gian tên như Windows.Data.Json, hoặc Windows.Graphics.Printing, hoặc Windows.Networking.Sockets.

Sau đó, bạn nhận được một số thư viện, giao dịch cụ thể với UI - chủ yếu là các không gian tên khác nhau trong Windows.UIhoặc Windows.UI.Xaml. Rất nhiều trong số chúng rất giống với không gian tên WPF / Silverlight - ví dụ như Windows.UI.Xaml.Controlsđược kết hợp chặt chẽ System.Windows.Controls; ditto cho Windows.UI.Xaml.Documentsvv

Bây giờ, .NET có khả năng tham chiếu trực tiếp các thành phần WinRT như thể chúng là các cụm .NET. Điều này hoạt động khác với COM Interop - bạn không cần bất kỳ tạo phẩm trung gian nào, chẳng hạn như tập hợp interop, bạn chỉ cần /rmột tệp .winmd và tất cả các loại và các thành viên của chúng trong siêu dữ liệu của nó sẽ hiển thị với bạn như thể chúng là các đối tượng .NET. Lưu ý rằng bản thân các thư viện WinRT là bản địa hoàn toàn (và vì vậy các chương trình C ++ bản địa sử dụng WinRT hoàn toàn không yêu cầu CLR) - phép thuật phơi bày tất cả những thứ được quản lý nằm trong chính CLR và ở mức khá thấp. Nếu bạn cài đặt chương trình .NET tham chiếu đến .winmd, bạn sẽ thấy rằng nó thực sự trông giống như một tài liệu tham khảo lắp ráp bên ngoài - không có trò lừa bịp nào như kiểu nhúng ở đó.

Đây cũng không phải là một ánh xạ cùn - CLR cố gắng điều chỉnh các loại WinRT thành tương đương với chúng, nếu có thể. Vì vậy, ví dụ GUID, ngày và URI trở thành System.Guid, System.DateTimevà System.Uri, tương ứng; Các giao diện thu thập WinRT như IIterable<T>và IVector<T>trở thành IEnumerable<T>và IList<T>; và như thế. Điều này diễn ra theo cả hai cách - nếu bạn có một đối tượng .NET thực hiện IEnumerable<T>và chuyển nó trở lại WinRT, nó sẽ thấy nó như là IIterable<T>.

Cuối cùng, điều này có nghĩa là các ứng dụng .NET Metro của bạn có quyền truy cập vào một tập hợp con của các thư viện .NET tiêu chuẩn hiện có và cả các thư viện WinRT (bản địa), một số trong đó - đặc biệt Windows.UI- trông rất giống với Silverlight, API-khôn ngoan. Bạn vẫn có XAML để xác định giao diện người dùng của mình và bạn vẫn xử lý các khái niệm cơ bản giống như trong Silverlight - ràng buộc dữ liệu, tài nguyên, kiểu, mẫu, v.v. Trong nhiều trường hợp, có thể chuyển ứng dụng Silverlight chỉ bằng usingcác không gian tên mới, và điều chỉnh một vài vị trí trong mã nơi API được điều chỉnh.

Bản thân WinRT không liên quan gì đến HTML và CSS và nó chỉ liên quan đến JavaScript theo nghĩa là nó cũng được hiển thị ở đó, tương tự như cách nó được thực hiện cho .NET. Bạn không cần phải xử lý HTML / CSS / JS khi bạn sử dụng các thư viện UI WinRT trong ứng dụng .NET Metro của mình (vâng, tôi đoán, nếu bạn thực sự muốn, bạn có thể lưu trữ một WebViewđiều khiển ...). Tất cả các kỹ năng .NET và Silverlight của bạn vẫn có liên quan rất nhiều trong mô hình lập trình này.

Từ xây dựng chủ đạo:

Họ đang cung cấp các API phổ biến cho cả ứng dụng HTML / CSS / JavaScript và ứng dụng C # / XAML. C # và XAML sẽ được sử dụng, nhưng nó sẽ không chính xác là WPF hoặc Silverlight.

Ý tưởng chính là bây giờ có hai bài phát triển - Desktop và Metro.

• Máy tính để bàn là nơi các ứng dụng cũ sống.
• Lớp ứng dụng mới, ứng dụng Metro, có thể được xây dựng theo một số cách, bao gồm VB.NET, C # hoặc C ++. Ba tùy chọn ngôn ngữ này có thể sử dụng XAML để xây dựng giao diện người dùng. Cách khác là sử dụng JavaScript / HTML5 / CSS để phát triển cả giao diện người dùng và mã ứng dụng.

Một số điểm quan trọng:

• Windows 8 có cảm giác giống như một hệ điều hành điện thoại di động được nâng cấp.
• Trong Metro, không có cửa sổ cấp cao nhất chồng chéo, giống như không có trên điện thoại di động. Nếu bạn muốn có một ứng dụng kiểu MDI, bạn cần ở lại trên máy tính để bàn.
• Các ứng dụng kiểu Metro sẽ tự động bị treo khi không nhìn thấy. Điều này đã được thực hiện để kéo dài tuổi thọ pin. Điều này có nghĩa là sẽ không có ý nghĩa đối với nhiều ứng dụng máy tính để bàn hiện có, thực hiện xử lý nền ngay cả khi người dùng không tương tác với chúng, được chuyển sang Metro.
• Phiên bản ARM của Windows 8 sẽ không hỗ trợ các ứng dụng máy tính để bàn. Vì vậy, nếu bạn muốn viết một ứng dụng và bạn muốn nó hoạt động trên bất kỳ phiên bản Windows nào thì đó phải là một ứng dụng Metro.

Có phiên bản sửa đổi của kiến ​​trúc chắc chắn sẽ giúp bạn hiểu chính xác mọi thứ nằm ở đâu. Một trong những ninja Telerik đã trò chuyện với nhóm CLR và sửa đổi hình ảnh:

Ở đây bạn có thể thấy CLR đứng ở đâu. .NET framework hiện có hai hồ sơ

1- Hồ sơ .NET Metro (CLR liên quan đến ứng dụng Metro)

2- Cấu hình máy khách .NET (Thời gian chạy CLR cho các ứng dụng C # và VB.NET)

Tôi hy vọng điều này cung cấp cho bạn một hình ảnh rõ ràng hơn. Đọc toàn bộ bài viết trong một bức tranh xấu đáng giá cả ngàn cuộc thảo luận dài. .

Rất nhiều chi tiết từ Microsoft ở đây .

Windows Runtime được hiển thị bằng siêu dữ liệu API (tệp .winmd). Đây là định dạng tương tự được sử dụng bởi .NET framework (Ecma-335). Hợp đồng nhị phân cơ bản giúp bạn dễ dàng truy cập các API Windows Runtime trực tiếp bằng ngôn ngữ phát triển mà bạn chọn. Hình dạng và cấu trúc của API Windows Runtime có thể được hiểu bởi cả các ngôn ngữ tĩnh như C # và các ngôn ngữ động như JavaScript. IntelliSense có sẵn trong JavaScript, C #, Visual Basic và C ++.

Nói tóm lại, Windows Runtime là một bộ thư viện mới thể hiện chức năng của Windows và có sẵn cho JavaScript / C # / VB / C ++. Mỗi ngôn ngữ đã được thực hiện để hiểu và có thể gọi chúng trực tiếp thay vì phải trải qua một số lớp.

Silverlight và WPF là hương vị của XAML chạy trên CLR. Trong số các chức năng khác, Windows Runtime hiển thị một phiên bản XAML rất giống với Silverlight, nhưng thực hiện theo cách nguyên bản, không thông qua CLR. Nó có thể được truy cập từ CLR, nhưng cũng từ C ++.