Xamarin Forms,MVVMCross和SkiaSharp:跨平台应用程序开发的三位一体

本文概述

谈论设定高期望。三位一体, 无外乎!

事实是, 当你面向多个平台时, 移动应用程序开发的成本很高, 因为没有共享代码。 Apple要求你使用Objective-C或Swift进行编码, Android要求你使用Java进行编码, WinPhone要求你使用.NET(通常为C#)进行开发。此外, 每个平台都提供了大量用于处理地图, 绘图, 图片或GPS的库-构建单个移动应用程序需要大量的时间和知识。

使用Xamarin Forms,MVVMCross和SkiaSharp进行跨平台应用程序开发

不用说, 大多数初创公司负担不起三倍的费用, 即使是成熟的企业也很难证明进入移动空间的价格合理。

在本文中, 你将学习Xamarin Forms与MVVMCross和SkiaSharp的结合如何成为构建跨平台移动应用程序的可行方法, 同时又不影响熟悉度, 性能和独特性。本文将回顾这三种技术, 以及它们如何通过允许跨多个移动平台最大程度地重复使用代码来降低开发成本。

一个重要的问题

跨平台移动应用程序开发的问题是真实存在的, 因此, 多年来出现了许多不同的解决方案, 以通过在平台之间共享代码来降低开发成本。例如, 在视频游戏行业中, 所有主要的游戏引擎都提供了跨平台的解决方案, 甚至虚幻和Unity都针对手机和平板电脑。

在应用程序方面, 这些年来, 已经进行了多次尝试来领导这个跨平台市场的尝试。许多没有达到目标并迷失在深渊中, 但其中一些仍然可以在多年后生存。其中包括Xamarin, 这是唯一支持所有三个移动平台的.NET解决方案。

本地人与否, 我来了

因此, 不同的解决方案之间会发生战争, 谁说战争意味着宣传!

这场战争主要是在大N阵线进行的:本土化!你需要提防这个词, 因为它没有明确的含义。这是当今移动开发世界中使用最广泛的单词, 而且非常流行。事实是, 没有人同意这实际上意味着什么。

选择跨平台框架时, 所有”本机”选项都不相同, 因此请当心, 你可能会将苹果与桔子进行比较。对于某些人来说, 它是关于编程语言的, 对于其他人来说, 是关于能够使用硬件的功能, 对于其他人而言, 这是关于平台API / UI的使用, 并且通常只是关于不成为Web应用程序。

辩论的各个方面都有争论, 我将不深入探讨, 因为它没有用。为什么没用?好吧, 让我告诉你一个难以理解的事实:你的最终用户不在乎!

是的, 你没看错, 只有程序员在乎。最终用户永远不会因为基础技术而选择你的应用程序:他们会选择你的应用程序, 因为它可以解决他们的问题并提供良好的体验。

因此, 让我们看看Xamarin如何为你的用户提供他们关心的事情的有效方法, 而不是争夺一个词的含义。

父亲, 儿子和圣灵

在继续之前, 我们只需要澄清构成我们对跨平台开发问题的解决方案的三个要素。

父亲:Xamarin

如前所述, Xamarin是用于移动和桌面应用程序开发的.NET解决方案。它于2016年被Microsoft购买, 但可以追溯到大约四年前的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(模型-视图-视图模型)基础结构, 因此所有内容都可以保持独立。无需太过技术, 应用程序通常分为三个部分:

  1. 模型:数据的内存表示
  2. 视图:我们的用户界面, 向用户展示数据和操作
  3. ViewModel:将模型绑定到View的层, 反之亦然

在软件工程中, 我们始终努力将视图与ViewModel分开, 以便即使更改视觉表示也可以重用应用程序逻辑(在ViewModel中)。 MVVMCross通过处理数据绑定并提供平台抽象的模式和工具来帮助我们实现这一目标。

最终用户关心什么

回顾一下, 有很多不同的东西将成功的应用程序与不好的应用程序区分开。成功的应用程序:

  1. 解决现实生活中的问题
  2. 提供愉快的体验

第1点显然与你选择的框架无关。因此, 让我们专注于第2点。有三个主要方面有助于提高应用程序的趣味性:

  1. 熟识
  2. 性能
  3. 独特性

熟识

熟悉度与易用性以及通过应用程序快速找到自己的方式有关。

换句话说, 它是关于在系统范围内一致使用平台的不同用户界面范例。例如, 简单的事情(例如按钮位置, 列表上下文操作或导航)都有助于提高应用程序的熟悉度。

熟悉是基于Web界面的Web应用程序或框架的主要弱点。另一方面, Xamarin Forms提供了到供应商提供的UI元素的跨平台映射。

因此, 你的用户将获得符合平台总体外观的体验, 从而可以直观地在你的应用中感到放心。

性能

坦白说, 在你的营销宣传中提及”本地人”没有任何意义。以Jasonette为例, 它是” HTTP上的本机”。用户界面存储在Web服务器上……你好, 来回往返和速度变慢, 因此我们看到不一定可以将本机假定为暗示更好的性能!

因此, 有了这个神话, 在查看现实生活中的基准测试时, Xamarin成为性能方面最全面的解决方案。 Xamarin Forms不需要太多上下文切换, 可提供与本地语言应用程序相当的性能。

我的结论是, 你的实现选择会减慢你的应用程序的速度, 而不是Xamarin和本机语言。在性能方面, 其他选择显然处于劣势。

独特性

如果你想提供最佳的用户体验并让你的应用与众不同, 那么设计师是否可以创建外观独特的应用也非常重要。

很多时候, 唯一性意味着创建自定义外观的控件, 动画或手势。当Xamarin中尚不可用它时, 你可以使用SkiaSharp(围绕Google Skia矢量图形渲染库的包装器), 并利用Xamarin Forms的自定义渲染器概念尽可能接近硬件, 同时始终以单个代码进行编码语言, 这是其他解决方案无法提供的。

你所关心的企业

在这一点上, 你最有可能认为选择框架也是一项业务决策。除了本文讨论范围之外的因素(例如人力资源可用性)之外, Xamarin还可以提供很多功能, 尤其是与MVVMCross结合使用时。我将详细说明你在决定时要考虑的四个方面:

  1. 价格和开发成本
  2. 代码重用
  3. 组件可用性
  4. 支持与社区

价格和开发成本

让我们摆脱这个。从今年年初开始, Xamarin免费提供给自由职业者和小型企业, 例如创业公司(使用Visual Studio Community Edition)。对于较大的组织, 它”免费”附带你可能已经拥有的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+中的强大功能中受益, 例如带有异步/等待, 关闭和反射的轻松多线程功能, 这些功能均已被证明可以提高效率。

代码重用

你可能已经考虑过代码重用, 并且很可能你认为所有解决方案在这方面都相当。不好意思说伴侣, 但是你错了!

你们当中的程序员可能想知道为什么我会建议在Forms内置的MVVM层上使用MVVMCross?好吧, 这里有一些需要考虑的问题:你真的只在构建移动应用程序吗?

通过使用MVVMCross隔离应用程序逻辑并使用其提供的控制反转, 你可以在移动设备上重用最大数量的代码, 在Windows和Mac上也可以重用(因为Xamarin.Mac是你的朋友)。

它不仅可以节省你的钱, 而且还提出了良好的工程实践, 可以降低代码维护成本。

组件可用性

也许你不喜欢我, 但我讨厌重新发明轮子。因此, 访问可轻松集成到应用程序中的现有组件对于加快产品上市时间至关重要, 而且通常这会同时降低成本。

选择Xamarin和MVVMCross为你提供了两个选择, 以从中选择现有组件。首先, 越来越多的组件可用于带有或不带有Forms的Xamarin。 Xamarin在Visual Studio中集成了一个组件商店, 你可以在其中找到各种常见应用程序问题的解决方案, 而其他公司也可以直接销售, 因此请务必在开始编写自己的组件之前进行搜索(或考虑在构建完这些组件后出售)。

其次, 你将要搜索Nuget软件包, 因为很可能有人已经编写了代码来执行所需的操作。在这些软件包中, 你会找到一个不错的跨平台MVVMCross插件列表, 该插件可以解决电子邮件, GPS或本地化等常见问题。

如果你已经有C#的使用经验, 那么你可能会拥有首选的组件。当然, 你不想让他们离开, 他们会觉得很舒服。请放心, 你可以为现有组件创建C#绑定, 然后将它们像我们与Xamarin捆绑在一起一样使用, 即使在Forms中也需要自定义渲染器的帮助。

说到这, 你可能需要先创建Xamarin绑定Github存储库。

支持与社区

最后, 获得支持和示例是选择框架的重要因素。 Xamarin已经存在了一段时间, 所以今天的社区规模相当大。

在Google上查找信息通常会得到很多答案(提示:也可以尝试搜索Xamarin的祖先monotouch和monodroid), Xamarin在其网站上提供了很多示例和出色的文档。

此外, 由于Xamarin实际上只是对供应商API的绑定, 因此Apple和Google的文档始终具有相关性, 可以回答你的许多问题。然后, 你可以创建自己的MVVMCross服务, 以在共享代码中抽象供应商API。

至于Xamarin的未来, 随着微软于去年3月对其的收购, 我敢打赌, 除了前进, 它不会走得更远。自那次销售以来, 以及相应的向自由模式的转变, 社区仅在增长, 支持得到了改善, 并且产品甚至可能以更快的速度不断改善!

Xamarin的前景一片光明。

让我们准备开始吧。让我们准备开战吧!

我意识到我可能会在本文中打开一罐蠕虫。现在不要误会我的意思, 还有其他值得考虑的选择, 我邀请你这样做, 因为我的担心可能与你的不同。

请记住, 如果你有六个星期的时间表, 而四个月后仍没有准备好应用程序, 那你就不会赢了。这将花费两个半月的时间和大量金钱来培训内部人员或雇用有知识的人员。那时坚持构建”本机”应用程序可能对项目的命运不利。

Xamarin和这些辅助技术可准确提供你的用户关心的内容和所需的内容。我希望本文能帮助你对下一个移动应用程序可能选择的框架做出明智的决定。

相关:使用带有干净架构的MVVM的更好的Android应用

微信公众号
手机浏览(小程序)
0
分享到:
没有账号? 忘记密码?