上司がXamarinを使用しても高速にならないようにするにはどうすればよいですか

Question

私は仕事で唯一のモバイル開発者です。私が雇われる前に、私の現在の上司は、マーケティングが共有コードとネイティブの言葉で言っているように、Xamarinの使用を考えていました。大規模な情報システムを構築しているので、私は自分を高度なAndroid開発者と考えています。現在、1週間で完了することができるシンプルなアプリに取り組んでいますが、Xamarinはバグが多すぎるため頭痛の種です。再利用可能なコードは約10％で、iOSに簡単にコピー/ペーストできます10％のコードを共有できますが、場合によってはコンパイルディレクティブ#if / #endifを使用する必要があります。

JavaとObjective-Cの両方の言語をすでに知っているので、私にとっては何の利点もありません。 iOSとAndroid SDKの両方でCore Dataを使用したSQLiteおよびデータストレージの豊富な知識を既に持っているので、Xamarinを学習すると遅くなります。

共有できるコードはごくわずかなので、Xamarinを使わないように話をしようとしましたが、理解していないようです。

彼らにそれを買わないように説得する良い議論が必要です。それで、私は仕事をより生産的でより速い方法で行うことができます。前もって感謝します。

Pancho · Accepted Answer

Lee Whitneyのブログ：モバイル開発にXamarinを推奨しない理由：

アプリのオーバーヘッド

Xamarinベースのアプリにはオーバーヘッドが組み込まれているため、平均して大きくなります。これは、デバイスで使用されるダウンロード時間とストレージに影響します。追加の最小サイズは通常数メガバイトであり、コードがより多くのAPIを使用するにつれて比例して大きくなる可能性があります。これは、アセンブリが参照されるときに、.NETアセンブリのコードが（ネイティブコードとして）アプリに静的にリンクされる方法によるものです。 On Android OS固有の理由によりアプリの起動遅延もあります。Xamarinの信用によると、このオーバーヘッドは以前よりも大きく、会社はそれを大幅に削減しました。しかし、影響アプリのユーザーは引き続き測定可能です。

iOSとAndroid間でのUIコードの共有の制限

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

Xamarinは、非常に異なるプラットフォーム間でUI APIを抽象化しようとすると、不必要な複雑さを生み出したり、LCD（最小公分母）デザインでユーザーエクスペリエンスが低下する可能性があると主張します。 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のバグですか？）。別の例は、微妙に異なる方法で動作するデータ構造とジェネリックです（ http://docs.xamarin.com/guides/ios/advanced_topics/limitations ）。これらは、実際に新しいプラットフォームを採用する前に見るのが難しいタイプの問題であるため、特別な考慮に値します。

その他の可動部品

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

これらのバグの履歴記録は、Xamarinのバグトラッカー（ https://bugzilla.xamarin.com ）を使用して確認できます。

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

概要

最後に、Xamarinなどの開発抽象化の利点を、他の抽象化やネイティブ開発よりも試して定量化する必要があります。 C＃はObjective-Cより優れていますか？はい、私の意見では断然ですが、それはただ一つの要因です。すべてを追加すると、モバイル開発に対する他のアプローチを支持して、スケールがXamarinから遠ざかります。 2013年の時点で（このようなものはすぐに変更される可能性があります）、ネイティブコードソリューションまたはHTML5/Cordovaソリューションを選択する傾向があります。私はさまざまな理由で両方が好きで、別の記事で決定要因のいくつかを説明しようとします。