xamarin开发_移动开发堆栈：本机vs Xamarin vs Xamarin形式

xamarin开发

平台支援 (Platform Support)

If you’re building a new smartphone or tablet app, the question you’ve likely pondered upon was which platforms (and form factors) are you going to support.

如果您要构建新的智能手机或平板电脑应用程序，那么您可能会思考的问题是，您将要支持哪些平台(和外形尺寸)。

Whether you are building one platform for both phone and tablet, or two platforms just for phone, or even whether the phone and tablet versions should be different, this choice should be made carefully in case your mind changes later. According to YAGNI, you don’t want to over-engineer, but in choosing a development stack you also don’t want to settle on a path that will prevent you from being able to share code in future work.

无论您是为手机和平板电脑都构建一个平台，还是仅为手机构建两个平台，甚至手机和平板电脑的版本都应该不同，都应谨慎选择此选项，以防日后改变主意。 根据YAGNI的说法，您不想过度设计，但是在选择开发堆栈时，您也不想确定会阻碍您在将来的工作中共享代码的道路。

After you conclude on this, the next is to decide on which stack you’re going to be developing it under. This choice can lock you into commitments you may not have even thought of yet, so choose with forethought. There isn’t a universally wrong answer, but each has its tradeoffs that you have to be okay with.

总结完之后，下一步就是确定要在哪个堆栈下进行开发。 这种选择可以将您锁定在您可能尚未想到的承诺中，因此请慎重选择。 没有一个普遍错误的答案，但是每个答案都有其必须权衡的问题。

纯本地堆栈 (The Purely Native Stack)

This is the happy path for each platform, so things should just work. You will have the most support here, and any question you can think of has already been answered. You can take full advantage of the platforms’ features and have confidence that your toolkit is as the OS developers intended.

这是每个平台的理想之路，因此事情应该正常进行。 您将在这里获得最多的支持，您能想到的任何问题都已得到解答。 您可以充分利用平台的功能，并确信您的工具包符合OS开发人员的预期。

However, you don’t get to share any code. Not unless most of your functionality uses WebServices, or if your shared business logic is written in C or C++. If you are using C/C++ code, the native development stacks have full support for it.

但是，您不必共享任何代码。 除非您的大多数功能都使用WebServices，或者您的共享业务逻辑是用C或C ++编写的，否则不会这样。 如果您使用的是C / C ++代码，则本机开发堆栈会完全支持它。

与C / C ++接口 (Interfacing with C/C++)

For iOS, you can use Objective-C++ which is a superset of Objective-C that allows you to write C++ directly inside Objective-C-like code. If you’re coding your app in Swift, you can setup Swift to Objective-C interfaces, which is compatible with Objective-C++.

对于iOS，您可以使用Objective-C ++ ，它是Objective-C的超集，可让您直接在类似于Objective-C的代码中编写C ++。 如果您使用Swift编写应用程序，则可以将Swift设置为与Objective-C ++兼容的Objective-C接口。

On Android, you need the NDK to compile C++ and you will also need to write JNI (Java Native Interface) bindings to call into the native code and marshal values between the two languages. A tool called SWIG can help with generating these.

在Android上，您需要NDK来编译C ++，并且还需要编写JNI(Java本机接口)绑定以调用本机代码并封送两种语言之间的值。 称为SWIG的工具可以帮助生成这些信息。

On Windows UWP, you can still use C# to P/Invoke to C/C++ code, however there may be some restrictions to using native Win32 code, but there are ways to get around it. Also, if you have C++ source, you can manage to get it to compile into a compatible native binary.

在Windows UWP上，您仍然可以使用C＃ P / Invoke到C / C ++代码，但是使用本机Win32代码可能会有一些限制，但是有一些解决方法。 另外，如果您具有C ++源代码，则可以设法将其编译为兼容的本机二进制文件。

用户界面 (User Interface)

For the UI/UX side of things, the native development stack will be the easiest to customize, and will also have more established third-party UI libraries you can use when the default widgets aren’t providing the User Experience that is trending at the time.

对于UI / UX而言，本机开发堆栈将最易于自定义，并且还将拥有更多已建立的第三方UI库，当默认小部件未提供用户体验时，可以使用这些第三方UI库。时间。

C＃跨平台 (Cross Platform with C#)

Close to two decades ago, I recall that a certain megalith’s selling point of .Net being cross-platform was being able to run on all versions of Windows (98/ME and 2000/XP), on x86 or ia64 chips. Hardly groundbreaking I thought, as C# came after Java, which was already running on Windows, Mac, Linux and all the other Unices and processor architectures at the time.

大约在二十年前，我记得某个跨平台的.NET卖点已经可以在x86或ia64芯片的所有Windows版本(98 / ME 和 2000 / XP)上运行。 我认为这几乎没有突破性的进展，因为C＃紧随Java，而Java当时已经在Windows，Mac，Linux以及所有其他Unices和处理器体系结构上运行。

Some short years after the .Net announcement, the Mono project had released an Open Source C# compiler and runtime. Given the rumours of anti-Linux sentiments from earlier said megalith at the time, it would take an open mind or a visionary to really see the purpose of this effort. Miguel de Icaza and his team did not fail to see the possibilities of an Open Source .Net implementation.

.Net发布后的短短几年， Mono项目发布了一个开源C＃编译器和运行时。 鉴于当时早先所说的巨石反Linux情绪的传言，要真正看到这项工作的目的，需要一个开放的胸怀或有远见的人。 Miguel de Icaza和他的团队没有看到开放源.Net实现的可能性。

This was the beginning of a C# platform beyond Windows, beyond desktop computers, that would eventually come full circle back to said megalith. Acquiring Xamarin could easily have been Microsoft’s best move in staying relevant in the mobile software space. Oh, how the times have changed.

这是超越Windows，超越台式机的C＃平台的开始，最终又回到了巨石。 收购Xamarin可能很容易成为Microsoft在移动软件领域保持相关性的最佳举措。 哦，时代变了。

Xamarin (Xamarin)

If you are targeting both Android and iOS, there are different ways you can use Xamarin, and there is generally not a “wrong” approach from the following, but rather better ways depending on your product and the circumstances. How much code you want to share, if any is also a deciding factor.

如果您同时针对Android和iOS，则可以使用Xamarin的方式不同，以下通常不是“错误”的方法，而是取决于产品和环境的更好的方法。 您希望共享多少代码(如果有)也是决定因素。

Xamarin本机堆栈 (Xamarin Native Stack)

At the API level, Xamarin.iOS and Xamarin.Android can be looked at as a C# wrapper to the iOS and Android native stacks, respectively. This wrapper is so thin that calling it an abstraction would be wildly and completely inaccurate. All of the native API calls exist, just in different syntax. And some of C#’s syntactic sugar does make things smoother and cleaner (such as .Net events as opposed to the delegate patterns used in Objective-C and Java). The performance difference with this additional layer is negligible for the most part, but there might be some exceptions.

在API级别，可以将Xamarin.iOS和Xamarin.Android分别视为iOS和Android本机堆栈的C＃包装。 这个包装器是如此之薄，以至于将其称为抽象将是完全错误的。 所有本机API调用都存在，只是语法不同。 而且C＃的某些语法糖确实使事情变得更加顺畅和整洁(例如.Net事件，而不是Objective-C和Java中使用的委托模式)。 与该附加层的性能差异在大多数情况下可以忽略不计，但是可能会有一些例外。

Using this stack, you can share most of your business/domain logic, but there are platform-specific ways to access hardware and OS features; you will have to be smart at abstracting the platform-specific code from the platform-agnostic code in a way that is maintainable. If you can follow SOLID design principles, support some rendition of MVC, and properly organize your Visual Studio build targets, then coming up with a reusable pattern shouldn’t be much of a problem.

使用此堆栈，您可以共享大多数业务/域逻辑，但是有特定于平台的方法可以访问硬件和操作系统功能； 您将必须以一种可维护的方式聪明地从与平台无关的代码中提取特定于平台的代码。 如果您可以遵循SOLID设计原则 ，支持MVC的某种格式并正确地组织Visual Studio构建目标，那么提出一个可重用的模式就不成问题了。

The User Interface is another area that will have to be implemented separately between platforms, but you can share the code that talks to the UI. Ensuring your concrete Views implement a common “ISomethingView” interface that your MVC Controller speaks with can help code reuse. Your View interfaces should have a definition of commands and events which are communicated in meaningful, yet platform-agnostic terms.

用户界面是另一个必须在平台之间单独实现的区域，但是您可以共享与UI对话的代码。 确保您的具体视图实现了与MVC Controller交谈的通用“ ISomethingView”界面，可以帮助代码重用。 您的View界面应具有以有意义但与平台无关的方式传达的命令和事件的定义。

One challenge would be sharing code for things which are conceptually different between the Mobile platforms. If one platform doesn’t have an equivalent, or is solving a problem in a completely different manner, then it may not be a simple 1:1 Liskov substitution.

挑战之一是共享在移动平台之间概念上不同的事物的代码。 如果一个平台没有等效产品，或者以完全不同的方式解决问题，那么它可能不是简单的1：1 Liskov替代。

If you are using third-party libraries, Xamarin has mechanisms to use both native Android libraries or native iOS libraries. If you have some code in C++, you may also use P/Invoke (presumably generated by SWIG) to wrap it in C# for Xamarin consumption; the Xamarin.iOS and Xamarin.Android linkers will allow you to hook them into the final native binary.

如果您使用的是第三方库，则Xamarin具有可以使用本机Android库或本机iOS库的机制。 如果您使用C ++编写了一些代码，则还可以使用P / Invoke(大概由SWIG生成)将其包装在C＃中以用于Xamarin的使用。 Xamarin.iOS和Xamarin.Android链接器将允许您将它们挂接到最终的本机二进制文件中。

Xamarin表格堆栈 (Xamarin Forms Stack)

Xamarin Forms takes the Xamarin stack further and allows you to share your UI code between Android, iOS and Windows UWP apps through a high level of abstraction. The caveat to this, is that only UI components which are common between all 3 platforms are going to be abstracted — anything unique will have to be customized. It is because of this that you might find the out-of-the-box UI widget set to be lacking certain functionality available in their native counterpart. This is remedied by the following concepts…

Xamarin Forms使Xamarin堆栈更进一步，并允许您通过高度抽象在Android，iOS和Windows UWP应用之间共享UI代码。 需要注意的是，只有在这三个平台之间通用的UI组件才需要抽象—任何独特的东西都必须自定义。 因此，您可能会发现开箱即用的UI小部件集缺少本机对应的某些可用功能。 通过以下概念可以解决此问题……

Xamarin Forms has built-in support for you to define your own cross-platform controls, layouts and templated view components. Or to drop down even lower you can access the Xamarin native APIs for the platform-specific bits via “Custom Renderers”. This means that any User Interface APIs which are available from a native development stack is also available, in C# form. In the spirit of sharable code I believe this can be done sparingly, when possible, as there are other techniques to use (such as Effects) to avoid having to resort to this. Custom Renderers are not completely avoidable, but there comes a point if you are finding yourself writing more renderers than shared UI code, then maybe native Xamarin is a better choice, but also likely you need to re-visit how you’re approaching your User Interface design.

Xamarin Forms内置支持您定义自己的跨平台控件，布局和模板化视图组件。 或者要降低到更低的水平，您可以通过“ 自定义渲染器 ”访问Xamarin本机API，以获取平台特定的位。 这意味着从本机开发堆栈中可用的任何用户界面API也都可以C＃形式提供。 本着共享代码的精神，我相信在可能的情况下可以做到这一点，因为还有其他一些技术可以使用(例如Effects )来避免诉诸于此。 自定义渲染器并不是完全可以避免的，但有一点是，如果您发现自己编写的渲染器比共享UI代码多，那么本机Xamarin可能是更好的选择，但您可能还需要重新考虑如何接近用户界面设计。

Xamarin Forms controls can also be inserted into Xamarin native projects to some extent and vice-versa. This allows some flexibility if you need to Frankencode up a solution.

Xamarin Forms控件也可以在某种程度上插入Xamarin本机项目中，反之亦然。 如果需要对解决方案进行Frankencode编码，则可以提供一定的灵活性。

Xamarin Forms UI is normally defined in XAML with C# code-behinds and uses the MVVM paradigm, which is very similar to WPF or the Windows Metro/Modern UI. If you don’t want to take advantage of the prescribed framework and patterns, there’s nothing stopping you from writing all of your UI in C# and using MVC or a pattern of your choice, but XAML makes the view hierarchy much easier to read.

Xamarin Forms UI通常在带有C＃代码的XAML中定义，并使用MVVM范例，这与WPF或Windows Metro / Modern UI非常相似。 如果您不想利用规定的框架和模式，没有什么可以阻止您使用C＃编写所有UI并使用MVC或您选择的模式，但是XAML使视图层次结构更易于阅读。

In addition to UI code, Xamarin Forms also allows you to create a more platform-agnostic application shell for your Visual Studio solution, with the abstraction of hooks of the mobile application lifecycle. This also includes APIs for running background tasks and executing blocks back on the UI thread, so you can do some cleaner looking async work without the worry of how the OS needs to deal with it.

除了UI代码之外，Xamarin Forms还允许您通过对移动应用程序生命周期的钩子进行抽象，为Visual Studio解决方案创建与平台无关的应用程序外壳。 它还包括用于在UI线程上运行后台任务和执行块的API，因此您可以做一些更简洁的异步工作，而不必担心OS如何处理它。

Xamarin之上的UI框架 (UI Frameworks on Top of Xamarin)

There is nothing stopping you from building your own UI framework on top of Xamarin or even on top of the foundation for Xamarin Forms, if Xamarin Forms doesn’t suit your fancy for UI code re-use.

如果Xamarin Forms不适合您重用UI代码，那么没有什么可以阻止您在Xamarin甚至Xamarin Forms的基础上构建自己的UI框架。

If you choose to go this way, you will be very far off the happy path, and I wouldn’t recommend it if UI frameworks isn’t your core competency or if you’re not also an expert in the native mobile UI concepts. The initial work is a full time job, and the maintenance will be ongoing indefinitely, so if you have other business problems to solve then taking this on can be a slippery slope.

如果您选择这种方式，那么您将走得很开心，如果UI框架不是您的核心能力，或者您也不是本机移动UI概念的专家，我也不建议您这样做。 最初的工作是一项全职工作，并且维护将无限期进行，因此，如果您要解决其他业务问题，那么进行此工作可能会很困难。

结论 (Conclusion)

Code sharing between Android and iOS, and even UWP, is easily within reach when using Xamarin. The C# language is modern and has advanced gracefully over the years, is fun to play with, and is still very easy to pickup.

使用Xamarin时，可以轻松实现Android和iOS甚至UWP之间的代码共享。 C＃语言是现代的，并且经过多年的优雅发展，很有趣，并且仍然很容易使用。

Using the Xamarin stack alone will open up code reuse but in order to maximize reuse, you must use good judgment in both code architecture and in your overall solution structure. These concepts don’t come naturally by throwing code together, but come with experience and planning.

单独使用Xamarin堆栈将开放代码重用，但是为了最大化重用，您必须在代码体系结构和整体解决方案结构中都做出良好的判断。 这些概念不是自然而然地将代码组合在一起，而是伴随着经验和计划。

A software development shop with mostly C# experience might be keen to choose Xamarin to share code with their legacy applications. Use this choice with caution however, as I’ve outlined in my other article that sharing desktop code has its caveats.

一位主要具有C＃经验的软件开发商店可能希望选择Xamarin与他们的旧应用程序共享代码。 但是，请谨慎使用此选择，正如我在另一篇文章中概述的那样，共享桌面代码有一些警告。

翻译自: https://medium.com/@jeffreybakker/mobile-development-stack-native-vs-xamarin-vs-xamarin-forms-309af0e11ae6

xamarin开发