2013-07-02 8 views
10

Xamarin documentationは少し不明です。ビルド設定で腕立て伏せしたarmeabiだけでアプリケーションをビルドすれば、私のアプリはarmeabiのみで構築されたアプリケーションは、armeabi-v7aデバイスで実行できますか?

  1. となるでしょうか?Playストアのv7aデバイスで利用できますか?
  2. v7aデバイスで実行しますか?

実行されている場合、予期しない動作やクラッシュにつながるスレッドの使用などの機能はありますか?

私は単純なアプリを持っていて、それを小さく保つようにしています。また、私は素早い実験を行うためのv7aデバイスを持っていません。

明確化:

(この優れた記事を参照してください。Why use armeabi-v7a code over armeabi code?を)のみamreabiライブラリとAndroidアプリをコンパイルするために、「安全、しかしそれほどパフォーマンスではない」であることは明らかで受け入れがあるように思えますが、私は自分のライブラリ.soのコンパイルに適用されると仮定していることXamarin docs on CPU architecture、次のように述べています

Xamarin.Androidで使用armeabiランタイムは、スレッドセーフであることを覚えておくことが重要です。 armeabi がサポートされているアプリケーションがarmeabi-v7aデバイスにデプロイされていると、多くの奇妙なものと の説明できない例外が発生します。

私はこれまで、v7aデバイスでarmeabiでコンパイルしたアプリをテストできましたが、「奇妙で説明できない例外」はありません。

更新

はXamarinのドキュメントのように見える以来更新されており、現在(2014年7月14日)は、読み取ります

armeabiランタイムが が使用することを覚えておくことが重要ですXamarin.Androidはスレッドセーフでないです armeabiサポートを持つアプリケーションをarmeabi-v7aデバイスにデプロイすると、多くの奇妙な と説明できない例外が発生します。

+5

Xamarinが何かをねじ止めしない限り、armeabiコードはARM v7aデバイスで正常に動作します。確かに、通常のAndroid NDK開発ではそうです。 – CommonsWare

答えて

8

XamarinのAndroidのドキュメントによると、armeavi-v7デバイスでarmeabiコードが予期せずクラッシュします。

http://docs.xamarin.com/guides/android/advanced_topics/cpu_architecture

セクション1.1

注Xamarin.Androidのarmeabiコードがスレッドセーフでないと が(後述)、マルチCPU armeabi-v7aデバイスで使用すべきではありません。シングルコアのarmeabi-v7aデバイスに aremabiコードを使用することは安全です。

armamabi-v7aをXamarin Androidに組み込む必要がある理由は、スレッドセーフなメモリアクセスと関係があります。 armeabi命令セットには、SMPデバイス上のメモリを安全にロックするのに必要な命令が欠落しています。

問題の最も徹底的な議論は、このバグレポートに記載されています。私の知る限りはできる限りhttps://bugzilla.xamarin.com/show_bug.cgi?id=7013

ジョナサン・プライアー2012年9月20日11時41分45秒EDT

SMP armeabi-v7aデバイスでarmeabi ライブラリを安全に使用することは(ほぼ)不可能であると判断します。これは、armeabiがSMPデバイス上のデータを安全にロックするためにCPU 命令が不足しているためです。したがって、armeabi ライブラリに複数の スレッドからのアクセスから保護する必要があるデータが含まれていると、libmonodroid.soがそのようなライブラリです。これは のlibymodroid.soを作成することで解決できます。libmonodroid.soは動的にランタイム CPUを決定し、それに応じてarmeabiまたはarmeabi-v7aロック命令 を使用することができますが、まだ実行されておらず、実装時間枠 は不明です。

したがって、アプリがSMPハードウェア上で実行される場合は、 armeabi-v7aランタイムをアプリに含める必要があります。これは、Project Options ダイアログで行うことができます。

これらのクラッシュはまれですが、壊滅的で、ランダムなメモリの破損やセグメンテーションの障害が発生すると、デバッグが非常に困難です。

私はGalaxy S3で問題を確実に再現できました。クラッシュを示していくつかのサンプルコードでは、このバグレポートである:https://bugzilla.xamarin.com/show_bug.cgi?id=7167


それは、このバグは、Android上の他のNDKのアプリケーションに影響を与えるか否かを不明です。しかし確かにXamarin Androidに影響します。

+0

優秀な、権威ある主題の光、Jared。どうもありがとう。 –

0

はい。

armeabiは、一般的な塩基であるとarmeabi-v7aはarmeabi命令セットには見出されないいくつかの追加の命令を含みます。 v7aはハードウェア浮動小数点演算をサポートしているため、浮動小数点演算を実行している場合にコードを非常に高速にすることができます。 Androidは最初にarmeabi-v7aライブラリを読み込もうとしますが、ハードウェアがそれをサポートしていれば、armeabiバージョンに戻ってしまいます。

+0

これはどうやって分かりますか、ニック?私の説明を参照してください。 –

+0

Xamarinのコメントは、コードがスレッドセーフではない可能性があることを暗示しています。それにもかかわらず、彼らはアーキテクチャとx86の両方のために.soを出荷するべきである(SHOULD)。 –

3

http://www.arm.com/products/processors/instruction-set-architectures/index.php

あなたは、この図を見れば、それは、ARMプロセッサ設計の理念を説明しています。 ARM Design

新しい反復が基本機能セットを拡張し、それを変更しないでください。 NEONとSIMDを直接参照して使用する必要があるため、ARMv5バイナリから参照することはできません。あなたのバイナリが巨大でない限り(それはAPK全体ではなく実際の実行可能ファイルです)、私は両方をコンパイルして両方の世界のベストを得るでしょう。詳細は、this questionを参照してください。

Xamarinに連絡して、若干読み込まれた「説明不能な例外」の説明を明確にしたいと思います。複数のプロセッサで実行されているコードで問題が認識された場合、コアの数に関係なく、コードは本質的にスレッドセーフではありません。

+0

ダニーに感謝します。すべてのベースライブラリを完全に保存して互換性を持たせると、非常に簡単でコンパクトなコンパイル済みアプリケーションは8Mbより大きくなります。私は何か小さいものを出版するというリスクを負っているし、あなたの答えがもう少し軽いものを投げかけている間に、私の恐れや疑念を和らげない。 –

+0

これはXamarinの上にあなたのアプリを置く性質です。私は恐れています。彼らが複数の.soを提供しておらず、あなたがXamarinの特定の機能に含める必要があるものを伝えたら、これはアプリの肥大化につながります。基本的には、プラットフォームのバンドル方法のためにアプリが必要としないコードがたくさん含まれています。 –

7

私はクリックしてXamarinのコメントを読んだ。それらを読んで、あなたは間違った質問をしていると思う。あなたが尋ねた質問に対する答えは(コモンズウェアが彼のコメントで述べているように)「はい、Xamarinが何かをねじにしない限り」です。残念なことに、彼らの文書は、間違いなく、何かをねじ込んだと思っていることを示しています。ドキュメントには、あるものを混乱させるいくつかのタイプミスがあります。具体的には、「スレッドセーフではありません」と明示的に言ったときに、「スレッドセーフです」という1つの場所(1.1節)です。彼らは、セクション1.2で正しくこれを言い換える:

注:Xamarin.Androidのarmeabiコードはスレッドセーフではなく、 が(後述)、マルチCPU armeabi-v7aデバイス上で使用すべきではありません。シングルコアのarmeabi-v7aデバイスに aremabiコードを使用することは安全です。

セクション1.2と1.1の情報を組み合わせると、Xamarinがあなたに伝えていることが明らかになります。明確にするために、私は彼らの文書が何を述べているかを再記述しているだけで、彼らの文書の真実性について何の主張もしていない。つまり、armeabi libs(スレッドセーフではない)がマルチコアまたはマルチプロセッサーデバイスにロードされる場合、悪いことが起こる可能性があります。このケースは、ICS(4.0.0-4.0.3)のバグのために発生する可能性があります。したがって:ここ

Xamarin.Android 4.2以下を使用して構築されたアプリケーションが明示的に唯一のARMベースとしてarmeabi-v7aを特定すべきであるABI

は(フォーマットが追加された)それらのドキュメントからの実際の情報であります第Xa:第1.2.1項

ノートから

:それは明確に役立つかもしれ順に並べ替えアンドロイドのArmeabiコードはスレッドセーフではありませんマルチCPU armeabi-v7aデバイス(下記参照)で使用しないでください。シングルコアのarmeabi-v7aデバイスでのaremabiコードの使用は安全です。

セクション1.1から

ためのAndroid 4.0.0、4.0.1、4.0.2のバグ、および4.0.3に、ネイティブライブラリは、たとえそこarmeabiディレクトリからピックアップされますarmeabi-v7aディレクトリがあり、デバイスはarmeabi-v7aデバイスです。

注:これらの理由から、Xamarin.Android 4.2以下を使用して構築されたアプリケーションでは、armeabi-v7aを唯一のARMベースのABIとして明示的に指定する必要があります。

私はドキュメントの残りの部分に基づいて、これはセクション1の最初の段落と考えています。図1は、(太字編集はわたしのもの)を言う必要があります。

アプリケーションバイナリインタフェースは、以下に詳細に説明する

、 Xamarin.Androidで使用armeabiランタイムはない、スレッドセーフであることを覚えておくことが重要です。 armeabi がサポートされているアプリケーションをマルチCPU armeabi-v7aデバイスに展開すると、多くの奇妙なメッセージと 説明できない例外が発生します。

+0

偉大な解釈とかなり説得力があります。どうもありがとう! –

+0

コアの数はスレッドの安全性に影響を与えてはなりません。 Androidは1つのコアデバイスであってもいつでもスレッドを切り替えることができ、これはメモリ書き込みの途中である可能性があります。上記の記述は、ハードウェア上のXamarinの安定性について私に自信を与えるものではありません。 –

+0

これは、私の答えは、Xamarinのドキュメントが伝えようとしている情報を明確にすることを目的としていることを指摘している理由の1つであり、ドキュメントの正確さについては何の主張もしていません。 1.3.2節の終わり近くまで読んだ場合、これは「ArmeabiがSMPに対して安全でないため、実行時エラーが不明確になることもあります」と示しています。 JannieTの質問に対する私の読書は、「このXamarinの医者が私に教えようとしていることは何ですか?確かにXamarinが問題を見つけてユーザーにそれについて(弱く)警告しようとしているように思えるので、私の意図は文書の解釈を助けることでした。 – ajh158

関連する問題