【C#】XobotOS　総合

1 ：2012/05/07 〜 最終レス ：2013/06/02

Xamarinは、AndroidのJavaで書かれた部分をC#に移植した「XobotOS」をGitHubで公開した。
XobotOSはJavaをC#に変換する「Sharpen」と呼ばれるツールを使用して移植された。
ホストOSと統合する部分のコードと、Java JNIからCで書かれたネイティブコードを呼び出
すコードを手作業で置き換えた以外は、Sharpenにより自動変換されている。
XobotOSではAndroidがMono上で動作し、Dalvik VM上と比べて大幅にパフォーマンスが
向上するという。
また、C#と.NET VMはECMAで標準化されており、Javaのような特許問題が発生しない点も
メリットといえる。
http://linux.slashdot.jp/article.pl?sid=12/05/05/0546247
■パフォーマンス比較
http://tirania.org/s/71de890b.png
■Xamarinのブログ記事 http://blog.xamarin.com/2012/05/01/android-in-c-sharp/
■XobotOS-GitHub https://github.com/xamarin/XobotOS
■atsushieno氏のブログ記事　http://d.hatena.ne.jp/atsushieno/20120502/p1

2 ：

Androidを全面的にC#で書き直したXobotOS公開、ICSとの性能差が酷すぎる　
http://engawa.2ch.net/test/read.cgi/poverty/1336353765/

3 ：

>>1
乙

4 ：

カスタムROMはよ

5 ：

【消しゴム】MONOを使ってみるスレ4【じゃない】
http://toro.2ch.net/test/read.cgi/tech/1329023778/

6 ：

とりあえずまずはGNで動くカスロムを作ってください

7 ：

乞食端末持ちはお帰り下さい

8 ：

プログラムのことは素人だけと、XobotOSの狙いは何なの?
AndroidOSをまともなものにしようって取り組みなの?

9 ：

>>8
仕組みを大幅に変更してレスポンスを向上させようっていう試み。

10 ：

>>8
Oracle訴訟を解決しようという試みでもある

11 ：

>>9-10
ということはやはり
性能上がるしJava?使わないから訴訟もかわせますよ
GoogleさんAndroidにこれを採用しませんか?っていうプレゼン的なものでおk?

12 ：

>>11
Javaはアプリで使うことになるだろうから完全排除は無理かな。

13 ：

マルチポストやめろ

14 ：

あっちこっちにここのURL貼ってる人がいてうざいです。
責任もってここで引き取ってください。

15 ：

Android も標準言語をC#にしよう。

16 ：

で、これが載ったスマホはいつ出るの？

17 ：

>>16
自分で入れなよ

18 ：

詳しくないから分からないんだけどこれに対応したカスタムROMができたとして今までのアプリは問題なく動くの？？

19 ：

>>1
▼プログラム板
http://toro.2ch.net/tech/
▼プログラマー板
http://kohada.2ch.net/prog/
▼ゲ製作技術
http://toro.2ch.net/gamedev/
▼CG板
http://toro.2ch.net/cg/
▼ハード・業界
http://anago.2ch.net/ghard/
▼スマートフォン
http://anago.2ch.net/smartphone/
▼スマホアプリ
http://anago.2ch.net/applism/

20 ：

>>18
Java VMが無いのに動くわけ無いでしょ

21 ：

>>17
どうやって？

22 ：

>>21
君ががんばって

23 ：

>>20
だから詳しくねぇって断ってんだろうがよ
ちょっと知識あるからっていきがってんじゃけぇよ

24 ：

>>23

25 ：

>>23
教えてもらったのに怒るなら聞かんでもええじゃろうて

26 ：

怖すぎワロタ

27 ：

すいません取り乱してしまいました

28 ：

>>12
何言ってんだよ
アプリをjavaで動かしてたのはiアプリ（笑）だろ

29 ：

正直最初からネイティブでやってくれればよかったのにな…
>>1のブログ見るとなんでjavaにしたんだ、と思ってしまうな

30 ：

ん‥どこまでC#に移植したのかがよくわかんねぇんだけど、Dalvik消したらAndroidに何が残るん？

31 ：

monoで。

32 ：

>>30
カーネルとライブラリw
たぶんアプリケーションフレームワークとシステムアプリまではC#化したんじゃないのかな？
>>1のブログ全部読んだらわかるかも！ざっと見た感じ書いてない気がするけど！

33 ：

>>28
NDKで作られてない限りJavaだろ。

34 ：

あーでもjavaのライブラリを差し替えるから完全に移植できないのかな？でも自動でできるとか言ってるし…
javaしか知らないし、javaもよくしらないおれは結局よくわからん…

35 ：

>>34
Javaアプリ変換ツールとか出来ればいいんだがな。

36 ：

>>35
なんかそんなのをリリースするみたいなことをブログに書いてた気がする…
ほんとにざっと見ただけだから、正確に訳してないんだが…
てかNDKって結局javaと組み合わせないと使えないと理解してたんだが…間違ってる？
だから勝手にjavaを完全に排除して、開発環境ごと総入れ換えかな？と思ってた

37 ：

泥井戸再生計画ktkr
これで勝つる！

38 ：

むしろ、日本メーカーこれ買って覇権とれや

39 ：

Xperiaは載せて来そう

40 ：

>>39
そうかな？googleがホンカクテキニ採用しない限りCMとかMIUI的な扱いになりそう…
でも全部自動でバグ少なく移行できるなら採用しない手はないよなー
さぁー寝れん寝るー！

41 ：

>>40
PSSでmono採用してるし、アプリの互換さえなんとかなれば載せて来そうな気がする

42 ：

>>41
アプリの互換って結局VM上で動作させるってことでしょ？
そしたら性能変わんなくない？　
もしくはほとんどのアプリを自動移行させるってことだよね？
それにはgoogleの本格採用いるくない？
ぺリアファンとしては来てほしい限りだけど

43 ：

>>40
個人的にはCMに組み込んで欲しい
メーカーは下手なことしなくていい

44 ：

　　　　　　　　　　　　　メモリ消費　　メモリ確保　　実行時間
　　　　　　　　　　　　　　　バイト　　　　　ミリ秒　　　　ミリ秒
-------------------------------------------------
DalvikVM 　クラス　　　9817240　　　　 5388　　　　3013
MonoVM 　クラス.　　　7376896　　　　　933　　　　　167
JavaVM.　　クラス　　 10438176　　　　　319　　　　　211
MonoVM　　構造体.　　 2007040.　　　　　 12　　　　　107
http://www.koushikdutta.com/2009/01/dalvik-vs-mono.html
実のところOracle Java VMとXamarin Mono VMは勝ったり負けたりな結果だったりする。
つまりGoogleがOracleにゴメンナサイしてDalvik VMの代わりにJava VMを積めばみんな嬉しい。
あとC#の構造体は鬼最適化が効く。
MonoはまだまだだがMS VMだとVC++より速いという不思議なことになる。
ただクラスと違って使い勝手はクソ悪い。

45 ：

>>44
C#の値型はそもそもクラスの代替じゃないから問題なし

46 ：

>>44
Oracleの高額なライセンス料がユーザーかメーカーに
跳ね返ってきて結果的にアンハッピーだろうけどな

47 ：

>>36
確かにNDKもJavaとの組み合わせだ。
でもそこに書かれているJavaを理解するのにVMはいらないと思う。

48 ：

>>42
でもandroid自体は軽くなる。

49 ：

>>46
こまけえこたあいいんだよ！

50 ：

>>43
そんなんじゃ結局アプリの速度は変わらないし意味ねーよカス

51 ：

>>46
高額といってもガラケーと同じになるだけだけどね

52 ：

>>47
そうなんだ、勉強になります
とりあえずはやくカスロムがきていじってみたいなー

53 ：

>>50
だから勝手にメーカーがXperiaに導入したってアプリの速度は変わらないんだからいれる必要ないだろ
Googleが採用しない限りメーカーから出ることはないんだからカスタムROMで自分でアプリも変換していじる程度の遊びにしかならないよね

54 ：

>>53
たぶんソースコードがないと勝手に変換はできないよ
googleが採用ってのが一番だよね
もしくはosをサポートっていう形で、play storeでサポートしてほしいな
メーカーが内蔵osに選択肢をあたえてくれるようになる、とかデュアルブートとか妄想してたら嬉しくなってきたw

55 ：

>>44
プロセスの分離がきいてないoracle jvmもどうかと思う。
zygoteの仕組みは評価してあげたい。
zygoteはxobotでどうなっているのやら

56 ：

これプレステと関係あんの？

57 ：

で、クソ泥が生まれ変わるのは何年後よ?
(ﾟσ・ﾟ）

58 ：

GoogleによるJava著作権侵害裁判、ほぼOracleの勝ちが確定、崖っぷちAndroid、どうするコマンド？
http://engawa.2ch.net/test/read.cgi/poverty/1336439613/
みごとなタイミングでGoogleに迷ってる猶予はなくなった

59 ：

＞Dalvik VMの代わりにJava VMを積めばみんな嬉しい。
結局これでFA?

60 ：

JavaVMは起動が絶望的に遅い
とてもでないが使い物にならない

61 ：

>>58
お金払って和解するしかないんだろうなあ・・・。

62 ：

>>59
プロセス毎にvm起動させた場合のフットプリントがj2meはでかいから、一概にそうとはいえない

63 ：

>>59
バイトコードが別物のVMを乗っけてどうする。

64 ：

>>1
怪しいなあ。Xamarinって、あのクソなGNOMEプロジェクト創始、
Nautilsファイルマネージャ、無謀なMONOプロジェクト等
役立たずなモノばかり作ってLinux界を引っ掻き回してきた連中じゃん
Androidの速度がパッとしない世間の不満を利用して、
詐欺紛いの技術でまた儲けようと企んでるんじゃないの？
これだけ差があるなら比較動画くらいありそうなのにねえし

65 ：

Googleも大変だナァ。
もう少し早ければCMが実験して実用レベルまで品質上げてくれてたかもしれないのに。
Oracleごと買い取っちゃいなYO

66 ：

Googleなんて褒められたもんじゃねーよ
プライバシーポリシー糞だし

67 ：

なんでmonoとかMS周辺とかはこういう煽り方するんだろう。
C#のECMA標準化にしたって2.0まででしょ？
今回のもマイクロベンチマークだしそのままモバイルに持っていけるのか？
structとかreified genericsとかで実際に何倍も差が出んのか？

68 ：

>>66
Twitterの規約読んでくるといいよ。

69 ：

iosでいうなら
std::vector<int>とNSMutableArray+NSNumberの比較

70 ：

XamarinがMSの手先なら、
目的はAndroidの開発に携わる人間の分断が目的だろーな

71 ：

アプリ開発者としては、単純に C# で、というか VisualStudio で開発できるのはかなり嬉しいけどね

72 ：

>>64
Monoが速いんじゃない。
Dalvikが遅すぎるんだ・・・
Dalvik vs NDK では5000倍以上の差が付くことすらあるだぜ・・・
>>1どこの騒ぎじゃない
＞ Android NDKを使用してJava言語とC言語で速度比較をする
＞ http://labs.techfirm.co.jp/android/iguchi/1782
＞
＞ Javaは45825ミリ秒、Nativeは9ミリ秒・・・・早い。早すぎる。

73 ：

Javaでintの動的配列を高速化したいんだったら
int[]使ったクラスでも作りゃいいじゃんか。
そして速さがJITによるものだったらスマホで使えるかは怪しい。
Dalvikが遅いのは最適化してないから。VM使うC#に変えても同じ。
最適化がんばるとメモリと計算時間と電力使う。

74 ：

>>72
5000倍はどう考えても単純な計算のコンパイル時最適化じゃないですかー。
みんなマイクロベンチばっかり。まあ実際のアプリで測るのは難しいけど。

75 ：

>>73
随分無理のある主張だなw
そんな無茶苦茶なことやってる奴なんてデータベース界隈くらいにしかいないだろ。汎用性がなさ過ぎる。

76 ：

>>73
dalvikは低フットプリントのluaにすら負けてるの。フットプリントやバッテリーを言い訳にするのは苦しい。
monoはスマートフォン向けクロスプラットフォーム環境としてはシェアトップで実際に問題無くjit動いてるしaotも可能(お値段の問題があるが...)
値型によってスタックからのオブジェクト割り付けもできる。
> int[]使ったクラスでも作りゃいいじゃんか
スタック領域って知ってる？値型って知ってる？ボクシングって知ってる？
List<int>に限定した話にしてしまってるのは>>73だけ。それ以前に出てた話はものの例えにすぎん。
長さが固定長ならそれはListではないし...

77 ：

みんな忘れてるのかもしれんが、すでに Dalvik って JIT つかってんだよ。
2.1 から 2.2 で、ほとんどのアプリで数倍パフォーマンスよくなったでしょ。
Mono はJITあるからなんてのは言い訳にならんよ。

78 ：

DalvikのJITは最適かかかってないんで、
単にネイティブにコンパイルしてもそんなに速くならない。

79 ：

>>78
そりゃ実行時の最適化を難しくするようなアーキテクチャにしちゃったからだろ？
本家JavaVM も.NET もスタックマシン選んだのは、実行時に局所性と並列化するヒントをもたせたり、機械的に判断できるようにするため。（ほかにも理由はあるだろうけど）
あえて実行時の推測が難しくなるレジスタマシンに変えて JIT化のメリットがあまり無いって方向でアーキテクチャ設計しちゃったんだから仕方ない。
成功してる先例を無視して、あえて遅くなる自前のアーキテクチャにこだわった結果がコレ

80 ：

大先生が煽りあいしてる(´・ω・`)

81 ：

勉強になるなぁw見てて楽しいw

82 ：

まーアプリの開発にasync、await使えたらcollback周辺で幸せになる向きも多いんじゃなかろか。
LINQとか移植できるんかしらんけど。
つーか実機で動くイメージをビルドできた外人ってどっか居るんかねぇ

83 ：

酷いtypoをした

84 ：

>>82
monoに入るのはまだまだ先だろw
本家でさえ正式リリースになってないというのに

85 ：

仮に接木できたとしても jni とか jna その辺のターゲット環境のデバイスハードに
依存にする部分は別途書き直さないといけないとかそれなりに面倒だろうなぁ…
って>>1に書いてあるか…自動変換も万能じゃないよね･･･

86 ：

>>85
でも現実的にはjniまわりの変更部分はインターフェース部分だけだろ
あとandroidでjna動かせたって例はきいたことない。

87 ：

動画もないのかよ
うそくせー

88 ：

pics or it didn't happen か

89 ：

>>86
https://github.com/twall
７日前くらいに Timothy さんがコンパイルとリンクに成功したそうな
リンクまで進めてるなら jna も一年以内に動くようになるようななら
ないような気がしないでもない…

90 ：

完成度低すぎ
実機に移植できるのはまだまだ先だな

91 ：

もたもたしてたらAndroid死んでしまうやん！

92 ：

android死なず！

93 ：

とりあえずOracleの特許侵害とか難癖付けられてた件が解決しそうで何より

94 ：

んだな

95 ：

んだんだ

96 ：

まだもうちょっとだけ続くんじゃ

97 ：

age

98 ：

>>96
亀仙人乙

99 ：

ほしゅ。

100 ：

ほしゅ。

101 ：

同じアプリでもiOSより劣化するのが多いからなぁ・・・

102 ：

ほしゅ。

103 ：

ホシュー

104 ：

ほしゅ。

105 ：

ないんだろうなー

106 ：

保守

107 ：

保守

108 ：

これをMSが新型WindowsPhoneとして売ればいいだろｗ

109 ：2013/06/02

保守