Xamarin を使っても仕事が速くならないことを上司にどう伝えたらいいでしょうか [closed] 質問する

いくつかの良い点Lee Whitney のブログ: モバイル開発に Xamarin を推奨しない理由:

アプリのオーバーヘッド

Xamarin ベースのアプリには、オーバーヘッドが組み込まれているため、平均してサイズが大きくなります。これは、ダウンロード時間とデバイスで使用されるストレージに影響します。追加される最小サイズは通常数メガバイトで、コードがより多くの API を使用するにつれて、比例して大きくなります。これは、アセンブリが参照されるときに、.NET アセンブリのコードがアプリに静的に (ネイティブ コードとして) リンクされる方法によるものです。Android では、OS 固有の理由により、アプリの起動に余分な遅延が発生します。Xamarin の功績として、このオーバーヘッドは以前ははるかに大きく、同社はそれを減らすために大きな進歩を遂げました。ただし、アプリ ユーザーへの影響は依然として測定可能です。

iOS と Android 間での UI コードの共有は限定的

ユーザー インターフェースの開発は、iOS と Android 間で移植できません。
つまり、API、イベント ロジック、ウィジェット、デザイナーは、プラットフォームごとに異なる方法で使用およびコーディングする必要があります。一般的な低レベルの操作については、これにいくつかの例外があります。

Xamarin は、非常に異なるプラットフォーム間で UI API を抽象化しようとすると、不必要な複雑さが生じたり、LCD (最小公分母) デザインでユーザー エクスペリエンスが低下したりする可能性があると主張します。彼らの主張はもっともです。Titanium は部分的にこれを実行しようとしており、その結果、一貫性のない、または予測できない結果に多くの開発者が不満を抱いています。HTML5 アプリは、LCD デザインを強制せずにこの UI 抽象化を実現することに成功していますが、Xamarin のようなネイティブ パフォーマンスはありません。

UI の問題は、モバイル アプリの開発において最も時間のかかる側面の 1 つです。十分な根拠があるにもかかわらず、重要なポイントは、多くのモバイル UI の問題において、Xamarin では開発者や設計者の時間を節約できないということです。

Xamarin 外でのコードの共有は制限されています

Xamarin では、独自の環境外で再利用可能なコンポーネントやモジュールを作成することはできません。たとえば、Xamarin で記述されたコードは、ネイティブ アプリや HTML5 アプリでは使用できません。つまり、Xamarin を使用するチームによって開発されたコードは、iOS や Android 用の他のツールを使用するチームと共有したり再利用したりすることはできません。これがどの程度重要になるかは状況によって異なりますが、開発の問題は、すべての状況を予測できないことです。そのため、最初からこのような制限があると不便です。

エコシステムとコミュニティ

これは、Xamarin のせいではありません。Apple、Google、HTML5 に匹敵するモバイル エコシステムを持つ企業はどこにあるでしょうか。しかし、これは重要なことです。開発者が Web で問題を検索したときに結果が見つかる可能性が 10 倍高くなると、生産性に直接影響します。利用可能なサポート、サービス、サード パーティ コンポーネント、および関連ツールのエコシステムは、ネイティブ アプリや HTML5 ベースのアプリに比べて大幅に小さく、今後も小さくなることは間違いありません。

第三の学習曲線

いくつかの概念とテクニックは、Xamarin 環境に特有の特別な知識を必要とします。これにより、開発者にとってプログラミング言語とネイティブ API の他に、実質的に第 3 の学習曲線が追加されます。たとえば、開発者は Xamarin のガベージ コレクションの問題を回避するために iOS の参照カウントを理解する必要があります (これは MonoTouch GC のバグでしょうか?）。もう1つの例は、データ構造とジェネリックが微妙に異なる方法で動作することです（http://docs.xamarin.com/guides/ios/advanced_topics/limitationsこれらは、実際に新しいプラットフォームを導入する前には確認するのが難しいタイプの問題であるため、特別な考慮が必要です。

可動部品の増加

Xamarin は、製品の品質と開発者の生産性に影響を与える独自のバグを導入します。問題は、Xamarin の製品が悪いということではなく、アプリ ツールチェーンに大規模または複雑なシステムを追加すると、ネイティブ アプリには存在しない問題やバグが発生することです。

これらのバグの履歴は、Xamarinのバグトラッカー（参考文献）。

はい、すべてのソフトウェアにはバグがあります。重要なのは、新しいツールを追加することの利点を測定するときに、新しい問題の欠点を考慮に入れる必要があるということです。

まとめ

結局、Xamarin のような開発抽象化が他の抽象化やネイティブ開発に比べてどれだけ有利なのかを定量化する必要があります。C# は Objective-C より優れているのでしょうか? はい、私の意見では断然優れていますが、それは 1 つの要因にすぎません。すべてを合計すると、モバイル開発に対する他のアプローチが有利になり、Xamarin は不利になります。2013 年現在 (このことはすぐに変わる可能性があります)、私はネイティブ コード ソリューションまたは HTML5/Cordova ソリューションを選択する傾向があります。どちらも異なる理由で気に入っていますが、別の記事で決定要因のいくつかを説明しようと思います。