android - 我如何告诉我的老板使用 Xamarin 不会让它更快

Question

已结束。此问题不符合 Stack Overflow guidelines .它目前不接受答案。

---

这个问题似乎与 help center 中定义的范围内的编程无关。 .

关闭 8 年前。

Improve this question

我是我工作中唯一的移动开发人员。在我被录用之前，我现在的老板正在考虑使用 Xamarin，因为他们的营销人员使用了 Shared code 和 native 这两个词。自从我构建了大型信息系统以来，我认为自己是一名高级 Android 开发人员。现在我正在开发可以在一周内完成的简单应用程序，但 Xamarin 让我很头疼，因为它的 bug 太多，而且可重用的代码大约 10% 可以轻松复制/粘贴到 iOS，尽管您可以共享那 10% 的代码，但有时您仍然必须使用编译指令 #if/#endif。

我的意思是，这对我来说没有任何优势，因为我已经知道 Java 和 Objective-C 两种语言。我已经对 iOS 和 Android SDK 上的 SQLite 和使用 Core Data 的数据存储有广泛的了解，因此学习 Xamarin 会使其变慢。

我已经尝试说服他们不要使用 Xamarin，因为它只能分享一小段代码，但他们似乎也不理解。

我需要一些很好的论据来说服他们不要购买它，这样我才能以更有效率和更快的方式完成我的工作。提前谢谢你。

Answer 1

Lee Whitney's Blog: Why I Don’t Recommend Xamarin for Mobile Development 中的一些优点:

App Overhead

Xamarin based apps have a built in overhead that makes them larger on average. This affects download time and storage used on a device. The minimum additional size is usually a few megabytes and can grow proportionately as the code uses more of the APIs. This is due to the way code from .NET assemblies is statically linked (as native code) into apps as the assemblies are referenced. On Android there is also an extra startup delay for apps for OS specific reasons. To Xamarin’s credit this overhead used to be much greater and the company has made great strides in reducing it. However, the impact on app users is still measureable.

Limited Sharing of UI Code Across iOS and Android

User Interface development is not portable between iOS and Android.
This means APIs, event logic, widgets, and designers must be used and coded differently for each platform. There are a few exceptions to this for common, low level operations.

Xamarin would argue that trying to abstract UI APIs across very different platforms can create unnecessary complexity or lead to a poor user experience with an LCD (lowest common denominator) design. They have a point here. Titanium tries to do this partially, and the result has made many developers unhappy with the inconsistent or unpredictable results. HTML5 apps are more successful at pulling off this UI abstraction without forcing an LCD design, but they do not have the native performance of Xamarin.

UI problems can be some of the most time consuming aspects of developing mobile apps. Despite having a good justification, the important takeaway is that for many mobile UI problems, Xamarin will not save developers or designers time.

Limited Sharing of Code Outside of Xamarin

Xamarin does not allow creation of reusable components or modules outside of it’s own environment. For example, code written in Xamarin cannot be used in native or HTML5 apps. This means any code developed by a team using Xamarin cannot be shared or reused with teams using any other tooling for iOS and Android. How much this matters depends on the situation, but the problem with development is we can’t predict all of our situations. So it’s an uncomfortable limitation to have right out of the gate.

Ecosystem and Community

This is something that is not really Xamarin’s fault. What company has a mobile ecosystem that matches Apple, Google, or HTML5? However, it matters. When developers are 10 times more likely to find results when searching the web about an issue, it directly impacts productivity. The ecosystem of available support, services, and 3rd party components, and related tooling is, and will continue to be, significantly smaller than for native or HTML5 based apps.

The Third Learning Curve

Some concepts and techniques require special knowledge specific to the Xamarin environment. This effectively adds a third learning curve for developers beyond programming language and native APIs. For example, developers having to understand iOS reference counting to avoid problems with Xamarin’s garbage collection (Is this a bug in MonoTouch GC?). Another example is data structures and generics working in subtly different ways (http://docs.xamarin.com/guides/ios/advanced_topics/limitations). These are the types of issues that are hard to see before you actually adopt a new platform, so they merit special consideration.

More Moving Parts

Xamarin introduces it’s own set of bugs that affect product quality and developer productivity. The problem is not that Xamarin has a bad product, but that adding any large or complex system to the app toolchain comes with problems and bugs that do not exist in native apps.

The historical record of these bugs can be reviewed using Xamarin’s bug tracker (https://bugzilla.xamarin.com).

Yes, all software has bugs. The point is when you measure the advantage of adding new tools; the disadvantage of new problems must be factored in.

Summary

In the end we have to try and quantify the benefits of a development abstraction like Xamarin over other abstractions, or over native development. Is C# better than Objective-C? Yes, by far in my opinion, but that’s only one factor. When you add everything up it tips the scales away from Xamarin in favor of other approaches to mobile development. As of 2013 (this stuff can change quickly) I tend to choose a native code solution or an HTML5/Cordova solution. I like both for different reasons and will try to explain some of the decision factors in another article.