一般的な答え
パフォーマンスに関する MvvmCross の哲学は次のとおりです。
- 開発者がより楽しいアプリを作成できるように、開発をより便利にします
- プラットフォームの一部によってある程度のオーバーヘッドが追加されることは承知していますが、オーバーヘッドが大きくならないように懸命に取り組んできました
- 分離されたビュー、ビューモデル、およびコンポーネントを構築するためのツールを開発者に提供します。これにより、開発者はより効率的で堅牢なコンポーネントを作成できると考えています。
- 開発者が分離されたコンポーネントを構築できるようにするため、パフォーマンスの問題が発生した場合、必要な場所とタイミングを最適化できるようになると考えています。
- 再利用のためのプラットフォームを提供するため、開発者はより優れたコンポーネントを開発して使用できるようになると考えています。たとえば、開発者はテーブル/リスト アダプターを再利用できるため、アプリごとに新しいテーブル/リスト アダプターを修正して最適化する必要はありません。
- 必要に応じて後で最適化できるように、プラットフォームでほとんどすべてをオーバーライドできるように懸命に取り組んできました。アプリで IoC 登録を手動で調整したい場合は、リフレクションを使用する必要はありません。
- .Net (Microsoft バージョンと Mono バージョンの両方) も、次の方法でアプリのパフォーマンスを向上させるのに役立つと考えています。
- 効率的なメモリ管理
- linq や TPL などのライブラリ
- TPL と await/async などのコンパイラ ツールの組み合わせ
- 必要に応じて PInvoke を介してネイティブ アクセスを提供する
もちろん、どうしても 200kB 未満のパッケージ サイズ制限に達する必要がある場合は、MvvmCross を使用できません。もちろん、世界で最高のツールを使用しても、開発者はパフォーマンスの悪いアプリを作成できます... しかし、私たちは MvvmCross を配置して、優れた開発者が楽しいクロスプラットフォーム アプリを作成できるようにします。
テクニカルポイント
限られたプロセッサ能力
最新のモバイル プラットフォームには次のものがあります。
- 2 ～ 8 個の CPU コア、それぞれが 1 GHz を超える速度で動作
- 1GB 以上の高速 RAM
- 16 GB 超の超高速ストレージ (フラッシュ)
これはほとんど制限されていません。10 年前の PC よりも高速で強力です。
誰もが...反射がパフォーマンスの「悪」であることを知っています
申し訳ありませんが、あなたが正しいとは思いません。
私が一緒に働いている人々は、リフレクションがわずかなオーバーヘッドをもたらすことを認識していますが、それがパフォーマンスの考慮事項を支配するものではありません。
私は次のように言ったドナルド・クヌースにもっと同意します：
「わずかな効率については忘れるべきです。たとえば、約 97% の確率で: 時期尚早の最適化は諸悪の根源です。」
http://en.wikipedia.org/wiki/Program_optimizationから
これは、多くのリリースがあるアプリ/プロジェクト/製品の場合に特に当てはまります。密結合プロジェクトでは、v1 用に作成された小さな最適化が、プラットフォームの変更によって「古いコード」が発生する v10 または v11 に到達するまでに、重大なパフォーマンスの問題を引き起こすことがよくあります。 「新しいパターン」で実行されます。
誰かが本当にマイクロ最適化に興味がある場合は、MvvmCross が仮想とマークされた多くのメソッド、多くの小さなインターフェイス/オブジェクト、および "{0}{1}" 型パターンを使用した文字列フォーマットなどを使用していることにも注意してください。誰かが本当にしたい場合は最適化してください。