5 questions to consider before choosing Xamarin

1 是否需要跨平台？

根据公司情况、团队大小。如果每个平台有足够的开发人员，那么就不需要跨平台了。如果一共也就那么一两个人，需要开发安卓、iOS app，那么跨平台可能是一个比较好的选择。如果还要开发uwp程序，Xamarin就又有优势了。

如果不需要跨平台，就不必选用Xamarin了。

2 是否同时还要开发桌面程序，Windows？ Mac？

如果同时还需要开发桌面程序（Windows或Mac），跨平台的概念也就更大了。这时Xamarin会是个比较好的选择。因为Xamarin的xaml和Windows很接近，和Windows 10 UWP中Xaml更接近。而且Xamarin还有支持wpf的计划，Xamarin在mac上的预览版也已经出来。详见 Glimpse the Future of Xamarin Forms 3.0

所以如果还跨平台到Windows Mac，Xamarin的优势就彻底发挥出来了。

当然这里还得提一下JavaScript的的electron。

3 已有的技术储备是什么，熟悉什么编程语言平台？

有的人说编程语言不重要，2个星期任何语言都搞定。这里说的是泛义上的编程语言，包括它的各种lib支持，思考方式。各种模块是否已经有成熟的实现，网上是否有各种例子。真正熟悉到相关的编程生态，2-3年不为过。

如果是从c#过来的，和Xamarin会天生好感，里面async await用的很溜啊。网上各种跨平台的c#库也很多。如果还有很多既有的模块是c#开发的，比如通讯协议，商业逻辑，那么选Xamarin想都不用想。

如果是从web技术过来的，熟悉javacript，react native倒是个不错的选择。好像javascript老是被提及啊？是的。javaScript在问题1 2 3 4里都是个不错的选项，就看你喜不喜欢这个语言了。

从java过来的呢？老老实实研究android专一平台，就不要趟跨平台的水了。研究kotlin也行啊。

c++过来的呢？回到第一个问题，先回答那个问题。

python 和 go呢？这么高大上的，往AI、cloud看看吧，别走弯路了。

那么Xamarin适合谁呢？熟悉或者愿意学习c#语言的，大多也就是原Windows程序员或asp.net程序员，团队不大，必须跨平台开发。现有一些c#开发的代码或者库可以复用。

下面还有两个问题，可以考虑一下。如果有共鸣，也算加分项。

4 Declarative UI

什么是declarative ui呢？就是UI的编写是申明一样的。Android的axml/xml是，web中的html、css都是；MFC严格的说不算，wpf的xaml算；iOS里面那个啥storyboard， xcode的Interface Builder都不算。qt的qml算。

其实UI的发展，web是走在前面的，wpf android qt都跟上了，xcode原地踏步，听说很多人都是用代码直接写UI的，高手啊。

Xamarin.Forms是用的xaml, 编写的时候是申明式的，后台会用原生的控件来显示。这也是为什么Xamarin强调自己是native app的原因之一。

另外，使用Xamarin，不一定要用Xamarin.Forms，完全可以用native的Xamarin，继续使用Android的xml文件来写UI，或者继续用interface builder。这种情况下，Xamarin只起到了一个编译语言的作用，然后把java class/api搞了一个一一对应的c#版本。熟悉Android api的可以用这种方式写。一一对应的哪种程度呢？看文档查好java api，直接写Xamarin c#代码没任何问题。objective c麻烦一点，swift的api文档转c#基本可以看懂。

iOS写UI是最烦的，没有之一，比mfc还烦。最敬仰iOS里写UI的大拿们。

如果UI需要更复杂一些，甚至每个版本都要变，就像常用的jd taobao，用web技术的react native就有优势了。

5 MVVM

没听说过的可能不知道它的强大，一旦熟练使用后，在更换任何一个技术时都会查一下新技术是不是支持mvvm。它和declarative UI是同时发威的，利用bingding，把ViewModel独立出来更好的跨平台，简化UI的编写工作，是跨平台程序写平台无关代码的利器。

MVVM由wpf开创，Xamarin.Forms很好的继承了这一点。现在Android也在学data binding哦。

选一门技术，要分析要开发的产品的特点，如何提高开发效率。不同的选择，可能是成倍的效率差别。Xamarin可以在某些场合是个不错的选择。