AndroidがiPhoneに構造的に勝つのが難しい点がある。その点と比較すると、タッチパネルのレスポンスなどのユーザビリティや、アプリケーションの数、ハードウェアの薄さや、バッテリー持続時間などは表面的な優劣でしかない。
iPhoneがAndroidに対して持つ最大の長所は、アプリケーションの実行速度の速さとメモリ消費量の少なさだ。これは、iPhone(iOS)の開発言語であるObjective Cがネイティブ・コードを生成する特性に依存するため、もっと本質的な違いとなる。
1. AndroidはJavaの亜種を用いる
Androidの開発言語は、大雑把に言うとJavaだ。Java SEのサブセットで作成されたバイト・コードを、Dalvik仮想マシン用のバイト・コードに変換して使う。やや変則的な構成になっているのは、SUNに支払うJavaのライセンス料を節約したかったとも、モバイル機器向けの仮想マシンを使いたかったとも言われている。このように、法的にはJavaと呼べない開発環境ではあるが、その特性はJavaと似通っている。
2. AndroidにはJavaが必要
現在のほとんどのスマートフォンはARM系のチップだが、Androidはプロセッサのアーキテクチャには縛られないOSである。そのためプロセッサ・アーキテクチャの壁を乗り越えて、世の中にある多様なハードウェアを動かす手段が必要で、Dalvik仮想マシンが必要となっている。そして、Dalvik仮想マシンのバイト・コードを作るには、少なくとも現状ではJavaのバイト・コードが必要だ。
3. C/C++/Objective Cに比べるとJavaは遅い
最も人気のあるプログラミング言語はJavaだが、ネイティブ・コードを生成するC等と比較して、実行速度が遅く、メモリー利用量が多い点が問題になる。
どのぐらい悪いのかというと、処理する内容、CやJavaの種類、バージョン、オプションで値は大きく変化するが、実行速度が3分の1で、メモリー利用量が20倍になると言っても間違いではない(Computer Language Benchmarks Game)。
4. Android上で比較しても、Cの方が速い
互換性に問題がでるが、実はAndroidもCで開発を行う事もできる。そこで、Android 1.6でCとJavaで単純なループ処理を比較したら、13倍ほどCの方が速かったそうだ(Android Techfirm Lab)。
Android 2.2以降は、この差はぐっと縮まるはずだが、逆にメモリー利用量が増える弊害がある。
5. Objective Cは、Cに近い速度やメモリー利用量になる
iOSの開発で使われるObjective Cは、CにSmalltalk風のオブジェクト指向を追加したものなので、速度的にはCにかなり近くなる。C互換のコードだけ書いておけば、Cと同じ速度やメモリー利用量になるのがObjective Cだ。つまり、iOSで利用されているObjective Cは、Androidで利用されているJavaに対して大きなアドバンテージを持つ。
6. JavaとObjective Cの速度とメモリー利用量の差が縮まる条件
条件によっては、JavaとCの速度とメモリー利用量の差が大幅に縮まり、場合によっては逆転することが知られている。古いバージョンや不適切なオプション以外にも、次のようなときに両者の差は縮まる。JavaとObjective Cの関係にも言えるであろう。
- 6.1. 継続的な処理
- 仮想マシンを使う言語は起動が遅く、Android 2.2では特にJITと呼ばれる実行時にnativeコードに変換する技術を用いるため、立ち上がりが不利だ。逆に言うと、ずっと起動している場合や、さらに連続して処理する場合は、両者の差が縮まる傾向がある。
- 6.2. データ量が多い処理
- メモリー利用量で特に不利なのは、実行コードの部分になる。処理するデータ量が多くなると、相対的に実行コードの消費メモリーが減るため差が目立たなくなる。アプリケーションにもよるが、ゲームの類だと大半がデータで占められるケースも多い。
- 6.3. OSのAPIを呼び出す事が主な処理
- OSのAPI内部はnativeコードで高速化が図られている部分も多いため、ユーザー・アプリケーションでの処理が少なく、APIを呼び出す比率が高い場合は、速度差やメモリー利用量の差が縮まる傾向になる。
- 6.4. Objective C的なコーディング
- Objective CのCを拡張した部分は、速度的に不利になる。つまり、メソッド呼び出しやオブジェクトの生成には時間がかかるし、メモリーの自動解放(autorelease)もオーバヘッドになる。現代的なコーディングをすると、速度やメモリー利用量もJavaに近づくと言う事になる。
7. スマートフォン向けの開発言語として、Objective Cは強いアドバンテージを持つ
ハードウェアの処理速度やメモリー利用量が限られている場合、仮想マシンを使う言語に対して、Objective Cは強いアドバンテージを持つ。特に、サーバーのように継続的な処理を行うわけでは無く、扱うデータ量も限られているモバイルのアプリケーションは、上述したようにメリットを受けやすい。
もちろんハードウェアの増強でカバーする戦略もあるが、それは電力消費量の飛躍的な増加をもたらす。同世代の半導体で3倍の速度を得るためには9倍の電力を消費すると言われており、Objective Cを採用することで、iOSは消費電力の削減もできているはずだ。
また、同じプロセッサーでも処理時間が短ければアイドル時間の増加も期待でき、その分、電力消費量を抑えることができる。
8. AppleはObjective Cの重要性を認識している
技術的な特性であるため、iPhoneの愛好者は開発言語がObjective Cであることを評価しないが、スマートフォンはアプリケーションのプラットフォームであるのだから、その基本的な性能を決定するプログラミング言語はもっと評価されても良い。
Apple社CEOのジョブス氏は良く認識しているのか、Flashを嫌っている。確かに、Flashを使うとObjective Cで書かれたアプリケーションのアドバンテージが発揮されない。同社のFlash排除の方針には、技術的な理屈もあるわけだ。
9. 全体の速度やメモリー利用量を決定するものではない
もっともアプリケーション開発環境の違いが、スマートフォン全体に影響するわけではない。
Android言えども、OSやブラウザーなどはC等で書かれている。つまり、iOSの開発環境がObjective Cを採用していても、連続通話時間やブラウザーの速度には影響が無い。ウェブや動画見るのが好きなユーザーには、ほとんどアドバンテージは無いであろう。
10. AndroidがiPhoneに勝てない点
それでもObjective CがiOSにもたらす特性は、本質的で重要なものだ。
多様なハードウェアを持つAndroidにとって仮想マシンは重要で、CやC++でアプリケーションを書くのは避けるべき事になっている。iOSのObjective Cと同じような開発言語を、基本的に選択するわけにはいかない。
つまり、開発環境に起因するアプリケーションの実行速度やメモリー利用量の差が、AndroidがiPhoneに勝てない点となる。
16 コメント:
AndroidのOSソースコードを読んだことがあるなら分かると思うが、Androidのサービス群はほとんどネイティブ(C++)で書かれている。Java APIはそれらネイティブサービスの上を薄くラップしているに過ぎない。
Androidでもネイティブアプリケーションを書くことはできるし、実際ゲームの多くはネイティブで書かれている。
逆にAndroidがiOSよりも優れている点はいくらでもあって、例えばインテントやコンテントプロバイダーをはじめとするアプリケーション間通信の仕組みは非常に合理的で便利なものだ。
>> yasuyuki さん
コメントありがとうございます。ご指摘の点は、本文中で「OSのAPI内部はnativeコードで高速化が図られている」と触れております。
また、AndroidでNDKでネイティブコードを書くことができるのは承知していますが、強い必要性が無い場合は、推奨されていないと理解しています。
なお本文は、AndroidとiOSのアーキテクチャ全体の優劣を比較するものではなく、あくまで「AndroidがiPhoneに勝てない点」を、一点、述べたものです。 Androidの開発者もDalvik VMの高速化に尽力しているわけで、全てを決定するものではなくても、中間コードの実行速度は重要な課題です。
AndroidとiOSのAPIの比較も興味深いトピックです。本BLOGは技術系ではなく、一般の読み物を目指しているので、別の場所で機会があれば整理してみたいと思います。
これAndroid VS iPhoneじゃなくて
C VS Javaになってませんか?
>>隼人さん
コメントありがとうございます。
Objective CとJavaを比較する資料が見当たらなかったので、5節のところで、Objective CとCの速度はほぼ同一と見なしました。また、Objective Cは、動的型付けのオブジェクトを作ると遅い事は、6.4.節で触れておきました。
いやそういうことじゃなくて
「i-modeがiPhoneに勝てない点」ってタイトルでも
同じことになるんじゃ無いのかなって事です。
i-modeアプリもJavaですから
>>隼人さん
もちろん、今回の視点ではそうなりますね。
ちょっと誤解を招いているみたいですが、本記事はAndroidとiOSの優劣や、開発環境の優劣や、消費者に対する訴求力を議論したものではありません。
あくまでAndroidアプリ開発で主に開発に使われるJavaと、iOSアプリ開発で主に使われるObjective Cを比較したものです。
>強い必要性が無い場合は、推奨されていない
互換性をテストする必要はありますが、特に非推奨というわけではないです。
>あくまで「AndroidがiPhoneに勝てない点」を、一点、述べたものです
Androidでもネイティブ開発が出来る以上、「勝てない」とは全く思えません。
さらに指摘するなら、XCode+Objective CよりもEclipse+Javaの方がプログラマーにとっての生産性は上である、と言うこともできます。あなたの論理でいけば、これをもって「iOSがAndroidに勝てない理由」とすることもできますね。
>>yasuyuki さん
以下のように不必要なときは使うなとあるので、非推奨だと考えています。
http://developer.android.com/sdk/ndk/overview.html
> In general, you should only use native code if it is essential to your application, not just because you prefer to program in C/C++.
また、大部分のアプリはDalvik VMで動く事になるので、今回の記事ではネイティブ・コードが基本のiPhoneアプリと比較して、動作速度が「勝てない点」だと主張しました。
> あなたの論理でいけば、これをもって「iOSがAndroidに勝てない理由」とすることもできますね。
勝てない理由とは、一言も申し上げていません。
勝てない『点』を指摘しただけです。もし他の側面から見れば、iOSがAndroidに勝てない点もありますね。
別エントリーで、「iPhoneがAndroidに勝てない点」という記事も書いたので、お読みいただけると嬉しいです。
「iPhoneがAndroidに勝てない点」の記事はスカスカで技術的な内容はゼロですよね。動的コード生成が出来ない点とか、マルチタスクの制約とか、他のアプリケーションとの連携(content providerのような仕組み)がない点とか、iPhoneが技術的にAndroidに勝てない点については全く触れていないわけで、これで「こっちも見てね」というのは詭弁にしか見えないのではないかと思います。
あとdalvikのJITがメモリを食うというのはずいぶんいい加減ですよね。100KB程度しか消費しないそうですが。 http://www.slideshare.net/tetsu.koba/froyo-jit-20100605 もしかしてデスクトップの(しかもSunの)JITとandroidのJITが同じだと思っているのではありませんか? dalvikではないJavaに基づくlanguage shootoutの結果を引用されていたりしますし。
ついでに言えば、↑の資料の内容から考えて、「大部分のアプリはDalvik VMで動く」という認識も正しくないですね。実際、Java APIはネイティブコードの単なるエントリポイントでしかないことも多く、そこにかかるオーバーヘッドは実際の処理に比べて些少なものです。
あとJNIが非推奨という認識も誤解ですね。前のコメントで引用されている部分は、「iPhone開発では基本的にCocoaTouchで提供されたAPIを使ってObjective-Cで開発することを推奨します」というのと本質的には同じ事を言っています。
>>Atsushi Enoさん
以下のように不必要なときは使うなとあるので、NDKは非推奨だと考えています。
http://developer.android.com/sdk/ndk/overview.html
> In general, you should only use native code if it is essential to your application, not just because you prefer to program in C/C++.
開発者のBLOGによると、JITで増加するメモリー量はJIT自身で100KB弱、追加して各プロセスで100KB程度とされていますが、メモリー利用量が増加するのに変わりはありませんね。
なお、次のエントリー『AndroidがiPhoneを押しのけて市場を制す』で「190MB~450MB程度のユーザー・メモリーが利用できるAndroid端末では問題は無い。」と、端末全体に与える影響を評しています。
なお、このエントリーはタイトルの通りiOSの優位点を一つピックアップしたもので、全体の優劣を議論するものではありません。
>以下のように不必要なときは使うなとあるので、NDKは非推奨だと考えています。
つまり、この記事にあるような、数百キロバイトのメモリーや計算速度が問題となる様な場合は必要だからNDKを使っても良いという事ですよね
NDKという回避策がある以上、勝てない「点」ですらないですよね
むしろ逆に、iPhoneにはガベージコレクションがありますか? っていう話になってしまいます。
ただ、実際両方のユーザーとして言わせて貰うならば
AndroidとiPhoneを比べるのはナンセンスです。
スマートフォンとNintendoDSを比べるぐらい意味がないことです
>>egsさん
コメントありがとうございます。
全てのアプリがNDKという回避策を使うのであれば良いのですが、ほとんどのアプリがDalvik VMを使っているのが現実です。ですから、全てがネイティブ・アプリのiOSと比較すると、『勝てない点』だと言えると思います。
> むしろ逆に、iPhoneにはガベージコレクションがありますか? っていう話になってしまいます。
オブジェクトの自動開放をしてくれるautoreleaseはいかがですか?
iPhone等のモバイル機器では非推奨ですけどね。
今までJAVAを使うAndroidはObjective-Cを使うiOSにパフォーマンスで勝てないと理論で攻めておきながら、
NDKの話をすると、実装としてNDKは使われていないという実装論になる。
しかし、実装論でいうと、ベンチマークではAndroidがiPhone4を上回っていることもあります。
http://juggly.cn/archives/10884.html
プログラムはネイティブコードだから早いに違いないなんて簡単な物じゃないんです。
>オブジェクトの自動開放をしてくれるautoreleaseはいかがですか?
え?少しのメモリーのオーバーヘッドも我慢できないのにメモリーバカ食いのautoreleaseは許せるんですか?
>>egsさん
AndroidをJava/Dalvik VM、iPhoneをObjective Cのネイティブ・コードで比較したのは、それぞれの推奨される開発方法であり、また大半のアプリがそれに従って書かれているからです。
なお、ご指摘頂いたページでiPhone 4がAndroid機に劣っているのは、ブラウザーのJavaScriptの実行速度であり、JavaとObjective Cで書かれたアプリの実行速度の比較ではありません。本文中に記載したとおりブラウザーはどちらもネイティブ・コードになります。
また、JavaとObjective Cの速度が逆転する可能性と条件は、本文の6節で説明させて頂きました。
> え?少しのメモリーのオーバーヘッドも我慢できないのにメモリーバカ食いのautoreleaseは許せるんですか?
本文でもコメントでも、我慢できる/できない、許せる/許せないは申し上げていません。
また、本文はAndroidとiPhoneの優劣を言及したものではありません。
それぞれの推奨される方法で開発したアプリに関し、速度とメモリー使用量の観点と、モバイル端末で利用されるという制約から、iOS(iPhone)が有利だと述べたものです。
もし、egsさんが本稿の内容をより拡大して、JavaとObjective C、さらにAndroidとiPhoneの特性をさらに議論したいのであれば、ぜひegsさんのページで詳しく解説頂ければと思います。
iOSでは未来に行けない理由
http://togetter.com/li/77111
というのを書いていますのでよろしかったらどうぞ。
技術的なことはさっぱり分からない 一般のAndroit+iOSユーザーです。
一つ確かなのは、 AndroidスマホからiphoneなどiOS系に乗り換えると 電池のモチが格段に上がります。
これは、タブレットでもスマホでも同じ実感があります。
技術的に勝ち負けどーのこーのとゴチャゴチャ言ってても、使用しててバッテリーのモチがこれほど違ってしまうと・・・iOSのほうがOSとしての完成度は格段に上かと思います。
ブラウザのスクロール時の反応や、タッチパネルの反応などトータルで商品としてみると全く相手にならないほどのサクサク感があるのですが・・・・
コメントを投稿