Xamarin Forms、MVVMCross 和 SkiaSharp：跨平台應用程序開發的三位一體

談論設定高期望。 神聖的三位一體，僅此而已！

事實是，當您面向多個平台時，移動應用程序的開發成本很高，因為沒有共享代碼。 Apple 要求您使用 Objective-C 或 Swift 編寫代碼，Android 要求您使用 Java 編寫代碼，而 WinPhone 要求您使用 .NET（通常是 C#）進行開發。 再加上每個平台提供的用於處理地圖、繪圖、圖片或 GPS 的大量庫——構建單個移動應用程序需要大量的時間和知識。

不用說，大多數初創公司都負擔不起三倍的開支，即使是老牌企業也很難證明進入移動領域的價格是合理的。

在本文中，您將了解 Xamarin Forms 如何與 MVVMCross 和 SkiaSharp 相結合，成為構建跨平台移動應用程序的可行方式，而不會影響熟悉度、性能和獨特性。 本文將回顧這三種技術，以及它們如何通過允許跨多個移動平台最大限度地重用代碼來降低開發成本。

一個重要的問題

跨平台移動應用程序開發的問題是真實存在的，因此，多年來出現了許多不同的解決方案，通過在平台之間共享代碼來降低開發成本。 例如，在視頻遊戲行業，所有主要的遊戲引擎都提供了跨平台的解決方案，甚至 Unreal 和 Unity 都針對手機和平板電腦。

在應用程序方面，多年來，人們多次嘗試引領這個跨平台市場。 許多人功虧一簣，迷失在深淵中，但其中一些人在多年後仍然倖存下來。 其中包括 Xamarin，它是唯一支持所有三個移動平台的 .NET 解決方案。

不管是不是本地人，我來了

所以在不同的解決方案之間有一場戰爭，誰說戰爭就是宣傳！

這場戰爭主要是在大N的前面進行的：本土化！ 你需要對這個詞保持警惕，因為它沒有明確的含義。 它是當今移動開發世界中使用最多的詞，並且非常流行。 事實是，沒有人同意它的實際含義。

在選擇跨平台框架時，所有“本地”選項都不相同，因此請注意，您可能會將蘋果與橙子進行比較。 對於一些人來說，這是關於編程語言，對於其他人來說，是關於能夠使用硬件功能，其他人認為這是關於平台 API/UI 的使用，而且通常只是關於不是一個網絡應用程序。

辯論的每一方都有爭論，我不會深入挖掘，因為它沒有用。 為什麼沒用？ 好吧，讓我告訴你一個難以接受的事實：你的最終用戶不在乎！

是的，你沒看錯，只有你的程序員在乎。 您的最終用戶永遠不會因為底層技術而選擇您的應用程序：他們會選擇您的應用程序，因為它可以解決他們的問題並提供良好的體驗。

因此，讓我們看看 Xamarin 如何提供一種有效的方式來為您的用戶提供他們關心的內容，而不是爭論一個詞的含義。

聖父、聖子和聖靈

在我們繼續之前，讓我們先澄清一下構成我們解決跨平台開發問題的三個要素。

父親：Xamarin

如前所述，Xamarin 是用於移動和桌面應用程序開發的 .NET 解決方案。 它於 2016 年被微軟收購，但可以追溯到大約四年前的 Mono 項目。 如今，它具有三種解決方案：Xamarin.iOS、Xamarin.Android 和 Xamarin.Mac。 其他平台已經默認處理 .NET 應用程序，即 Microsoft 解決方案。 簡而言之，Xamarin 提供了到 .NET 中平台 API 的直接鏈接。 因此，您可以使用 .NET 應用程序的本機功能。 Xamarin 還有一個名為 Forms 的擴展模塊，它為 UI 提供了一個抽象層。

兒子：SkiaSharp

SkiaSharp 是 Google 的 Skia 矢量圖形庫的 .NET 包裝器。 Skia 是 Android、Chrome、ChromeOS 和 Firefox 的原生渲染引擎。 使用 SkiaSharp，您可以在您的 .NET 應用程序中使用該庫來使其跨平台。 這意味著你的設計師所說的“將使你的應用程序變得更好”的簡潔陰影可以只編碼一次，而不是針對每個目標平台重複。 就我個人而言，我認為它的最佳功能是能夠以一種方式呈現 SVG 圖形，從而使您能夠防止各種形式因素的重複，同時保持清晰、像素完美的渲染。

聖靈：MVVMCross

為了保持一切良好分離和松耦合，我們神聖的解決方案將依賴 MVVMCross。 這個框架實現了一個 MVVM (Model-View-ViewModel) 基礎設施，這樣一切都可以保持獨立。 無需太技術化，應用程序通常分為三個部分：

1. 模型：我們數據的內存表示
2. 視圖：我們的 UI，向用戶展示數據和操作
3. ViewModel：將我們的模型綁定到我們的視圖的層，反之亦然

在軟件工程中，我們始終努力將視圖與 ViewModel 分開，以便即使我們更改視覺表示也可以重用應用程序邏輯（在 ViewModel 中）。 MVVMCross 通過處理數據綁定並為平台抽象提供模式和工具來幫助我們實現這一目標。

最終用戶關心什麼

回顧一下，成功的應用程序與糟糕的應用程序有不同的區別。 一個成功的應用程序：

1. 解決了現實生活中的問題
2. 提供愉快的體驗

第 1 點顯然與您選擇的框架無關。 因此，讓我們專注於第 2 點。有三個主要方面有助於您的應用程序的樂趣：

1. 熟悉度
2. 表現
3. 獨特性

熟悉度

熟悉度與易用性和快速找到應用程序有關。

換句話說，它是以系統範圍內的連貫方式使用平台的不同用戶界面範例。 例如，按鈕位置、列表上下文操作或導航等簡單的事情都有助於您的應用程序的熟悉度。

熟悉度是基於 Web 界面的 Web 應用程序或框架的主要弱點。 另一方面，Xamarin Forms 提供到供應商提供的 UI 元素的跨平台映射。

因此，您的用戶將獲得符合平台總體外觀和感覺的體驗，因此他們會直觀地在您的應用程序中感到輕鬆自在。

表現

坦率地說，在你的營銷宣傳中提到“原生”毫無意義。 以 Jasonette 為例，它是“native over HTTP”。 UI 存儲在 Web 服務器上……你好往返和減速，所以我們看到不一定假定原生意味著更好的性能！

因此，消除了這個神話，在查看現實生活基準時，Xamarin 成為性能方面最全面的解決方案。 Xamarin Forms 不需要更多的上下文切換，提供與本機語言應用程序相當的性能。

我的結論是，您的實現選擇會減慢您的應用程序，而不是 Xamarin 與本機語言。 其他選項在性能方面明顯處於劣勢。

獨特性

如果您想提供可能的最佳用戶體驗並讓您的應用與眾不同，那麼您的設計師創建外觀獨特的應用的可能性也非常重要。

很多時候，獨特性意味著創建自定義外觀控件、動畫或手勢。 當它在 Xamarin 中不可用時，您可以使用 SkiaSharp（圍繞 Google 的 Skia 矢量圖形渲染庫的包裝器）並利用 Xamarin Forms 的自定義渲染器概念盡可能接近硬件，同時始終在單個代碼中進行編碼語言，這是其他解決方案無法提供的。

作為企業，您關心什麼

此時，您很可能認為框架的選擇也是一項業務決策。 除了本文範圍之外的因素（例如人力資源可用性）之外，Xamarin 還可以提供很多功能，尤其是在與 MVVMCross 結合使用時。 我將詳細說明您在決定中要考慮的四個方面：

1. 價格和開發成本
2. 代碼重用
3. 組件可用性
4. 支持和社區

價格和開發成本

讓我們解決這個問題。 自今年早些時候以來，Xamarin 對自由職業者和初創公司等小型企業免費（使用 Visual Studio 社區版）。 對於較大的組織，它“免費”附帶您可能已經擁有的 Visual Studio 許可證。 Xamarin Forms、MVVMCross 和 SkiaSharp 也是免費和開源的！

正如我已經提到的，使用 Xamarin 走 .Net 路線可以讓您從頭到尾以單一語言開發您的應用程序。 大多數其他解決方案都要求您的程序員了解不同的語言。 以 Cordova 為例，如果您需要訪問沒有可用插件的供應商 API，您不僅需要精通 HTML、Javascript、CSS，還可能需要精通 Objective-C、Java 和/或 C# .

使用的語言種類繁多，需要更多的上下文切換和更多的工具來掌握，從而降低效率。 另一方面，Xamarin 是一個一體化解決方案：您可以通過 Visual Studio 在所有平台上構建、部署和調試。

儘管它與 Xamarin 沒有直接關係，但您還可以通過選擇 .Net 解決方案獲得 C# 中的許多加快開發速度的功能。 也就是說，您將受益於 C# 4.5+ 中的強大功能，例如使用 async/await、閉包和反射的簡單多線程，所有這些都已被證明可以提高效率。

代碼重用

您可能已經考慮過代碼重用，並且很可能您認為所有解決方案在這方面都有些等價。 對不起，伙計，但你錯了！

你們當中的程序員可能想知道為什麼我會建議在 Forms 中內置的 MVVM 層上使用 MVVMCross？ 好吧，這裡有一點需要考慮：你真的只開發移動應用程序嗎？

通過使用 MVVMCross 隔離您的應用程序邏輯並使用它提供的控制反轉，您可以在移動設備上重用最大數量的代碼，也可以在 Windows 和 Mac 上重用（因為 Xamarin.Mac 是您的朋友）。

它不僅可以為您節省資金，還可以提出良好的工程實踐，從而降低您的代碼維護成本。

組件可用性

也許你不像我，但我討厭重新發明輪子。 因此，訪問可以輕鬆集成到應用程序中的現有組件對於加快上市時間至關重要，而且通常同時會降低成本。

選擇 Xamarin 和 MVVMCross 為您提供了兩種選擇現有組件的選項。 首先，越來越多的組件可用於帶有或不帶有 Forms 的 Xamarin。 Xamarin 在 Visual Studio 中集成了一個組件商店，您可以在其中找到常見應用程序問題的各種解決方案，並且其他公司直接銷售，因此請務必在開始編寫自己的組件之前進行搜索（或考慮在構建後銷售這些組件）。

其次，您需要搜索 Nuget 包，因為很可能有人已經編寫了代碼來滿足您的需求。 在這些軟件包中，您會發現一個不錯的跨平台 MVVMCross 插件列表，它們將解決電子郵件、GPS 或本地化等常見問題。

如果您已經使用過 C#，那麼您可能擁有自己喜歡的組件。 當然，你不想讓他們走，他們覺得很舒服。 請放心，您可以為現有組件創建 C# 綁定，然後像我們與 Xamarin 捆綁一樣使用它們，即使在自定義渲染器的幫助下在表單中也是如此。

說到這一點，您可能想在創建自己的之前查看 Xamarin 綁定 Github 存儲庫。

支持和社區

最後，獲得支持和示例是選擇框架的一個非常重要的因素。 Xamarin 已經存在了一段時間，所以今天的社區規模相當大。

在 Google 上查找信息通常會找到相當多的答案（提示：也可以嘗試搜索 monotouch 和 monodroid，Xamarin 的祖先），Xamarin 在他們的網站上提供了很多示例和出色的文檔。

此外，由於 Xamarin 確實只是對供應商 API 的綁定，Apple 和 Google 的文檔始終是相關的，並且會回答您的許多問題。 然後，您可以創建自己的 MVVMCross 服務來抽象共享代碼中的供應商 API。

至於 Xamarin 的未來，在去年 3 月被微軟收購後，我敢打賭，除了向前發展，它不會有任何進展。 自從那次銷售和匹配轉向免費模式以來，社區不斷擴大，支持得到改善，產品甚至可能以更快的速度不斷改進！

Xamarin 的未來看起來一片光明。

讓我們準備開始吧。讓我們準備開戰吧！

我意識到我可能會用這篇文章打開一罐蠕蟲。 現在不要誤會我的意思，還有其他值得考慮的選擇，我邀請您這樣做，因為我的擔憂可能與您的不同。

請記住，如果您有六週的時間表，而四個月後您仍然沒有準備好應用程序，那麼您就沒有獲勝。 這將留下兩個半月的時間和大量資金來培訓內部人員或僱用知識淵博的人。 在那一點上堅持構建一個“原生”應用程序可能對你的項目的命運非常不利。

Xamarin 和這些配套技術提供了您的用戶所關心的和您需要的。 我希望這篇文章能幫助您對下一個移動應用程序可能選擇的框架做出明智的決定。