iOS対Android、クラッシュするアプリが多いのはどっち？ 79
ストーリー by hylom
ハードにも依りそうだが 部門より
ハードにも依りそうだが 部門より
あるAnonymous Coward 曰く、
ForbesのライターTomio Geron氏がiOSとAndroidの両プラットフォームについて、アプリケーションのクラッシュ率を比較する記事を書いている（Forbes、本家/.）。
Crittercismは2011年11月から12月にかけて、両プラットフォームにおける2億1400万回のアプリケーション立ち上げを分析した。iOSアプリケーションはAndroidと比較して3倍の立ち上げ回数が記録されたが、分析では各アプリケーションのクラッシュ率を求めたとのことで、立ち上げ回数の差は問題とならないとのこと。
アプリケーションはその人気ごとに4つに分類されて分析された。人気上位4分の1に属するアプリケーションにおいて、iOSでのクラッシュ率は0.51%、Androidは0.15%であった。次の4分の1に属するアプリではそれぞれ1.47%および0.73%、さらにその次の4分の1においては3.66%および2.97%であり、どの層においてもiOSの方がクラッシュ率が高かったという。
人気上位25％のアプリではクラッシュ率はどちらも1%を大きく下回っているため差はほとんどど無いとも言えるが、一方でiOSアプリの方がクラッシュ率が3倍以上高いとの見方もできるとのことだ。
調査が行われたのはiOS 5リリースから間もなくの時期であり、これがiOSアプリのクラッシュ率の高さに影響している可能性もあるとのこと。またAndroidの場合は開発者がいつでもアップデート版を公開できるが、iOSの場合はアップデートが利用できるようになるまで数日から1週間かかることもあり、この間にクラッシュが発生しているとも考えられるとのことだ。
審査する方がバグが増えるという矛盾 (スコア:3)
むしろこれが全てじゃないでしょうか。
言い換えると、iOSのほうがクラッシュ率が高いのはAppleが「審査しているから」です。
Androidは審査の無い分いい加減なエンバグが入り込む確率が高い、と仮に予想してみても
その修正も迅速に行われるためアプリ全体における「ある一瞬を切り取った時点のバグ率」では低く抑えられるはず。
実際にバグが多く含まれていたかどうかという継続的観点でなく、現時点で修正済みのバグはバグとカウントしない、という観点なのがポイント。
どうしても審査の時間だけタイムラグが発生してしまうので
審査方式というのはバグの生存期間を上げる効果を持ってしまうんですね。
だから開発ツールが良い悪いとか開発者のレベルどうとかじゃなく
配布システムとしてそういうもの、ということなんだと思いますよ。
Re: (スコア:0)
一つ気になるのですけどAppleってバージョンアップの時にも審査をしているのですか?
最初に審査をしたらバージョンアップはアプリの開発元が勝手にやっているという方が普通なのですけど。
Re: (スコア:0)
バージョンアップでも一から審査だったと思う。
バグ修正アップデートで、以前は通ってた箇所が審査にひっかかって通らなくなった、って話聞いたことあるような。
Re: (スコア:0)
VerUP時の審査が無ければ、初版でさし障りのないアプリを通しておいて「バグ修正」でエロアプリに変身させることが自由にできます。
どの程度のクラッシュ (スコア:2)
iOSでアプリが起動即終了するのは見たことあるけどOS自体がクラッシュするものもありそうな気がします（一応そうならないようにOSが作られてるとはいえ）。
この辺の深刻度も加味して統計を取るとどうなるんでしょうね？
Re:どの程度のクラッシュ (スコア:1)
5年前の携帯使ってるので
そろそろスマフォを、
と下調べしてるのですが
アプリどころか本体の不具合ばかり目につきます。
今はまだWin95くらいなんですかねぇ？
Win98くらいになるまで待とうかなぁ
Re: (スコア:0)
Androidのたとえば2.3に関して言えば、
今はWin98SEくらいですかね。
OSの構成もアプリもしっかり吟味すれば意外にもほぼ安定。
でもOSになんか問題があったり、
変なアプリが入ってくるとやはり不安定に直結しがち、な。
Re: (スコア:0)
その変なアプリが、有名＆人気だったりする。
os2.3.3更新で某ime利用者だけ落ちまくったようだ。
サンドボックス化されてるのにosごと落ちるのもダメだが
Re: (スコア:0)
>OSの構成もアプリもしっかり吟味すれば意外にもほぼ安定。
その割にはGoogleMAP辺りが頻繁に異常終了するのですけどこれって私だけですか?
Re:どの程度のクラッシュ (スコア:2)
ワタシもデス。
マップの表示をズームかけて、
モザイクがとれて見えそうになるトコで
強制終了。
＃エロ仕様？
Re:どの程度のクラッシュ (スコア:1)
ペアレンタルコントロールですね。
Re: (スコア:0)
Re: (スコア:0)
メーカのカスタマイズやOSに含まれる領域のドライバ周りで「OSになんか問題があったり」するのでは？
Re: (スコア:0)
半分はFlash、残りの半分はSkypeが原因だ。
Re: (スコア:0)
Skypeは、bodyの電話番号をSkypeボタンに置き換えるアドインを無効にすると安定する。
＃いつまで引きずってるんだ、このバグは。
Re: (スコア:0)
Win98レベルじゃメタメタですよ
Win2kレベルになるまで待つべきです
Re:どの程度のクラッシュ (スコア:1)
OS自体がクラッシュというか、固まったり再起動したりなら経験的にAndroidはiOSより1桁か2桁位多い気がする。特に国産Android機の場合、「一日に一回は勝手に再起動」とか酷いのが結構ある。iOS機が再起動はOSバージョンアップの時位しか用が無いのと比べると安定性にちょっと差があり過ぎる。
あとあまり表に出ないけどGPSやbluetoothのサービスが知らない間にコケていて、結局再起動するまで使えなかったというようなのは圧倒的にAndroid機の方が多いね。
Androidってファイルやフォルダ管理の様なところが見えてPCに慣れている人には判りやすいけど、安定性まで一昔前のPC並のような感じで、純粋に携帯電話機として考えるとどうなんだろう? と思う事が多いよ。
Re:どの程度のクラッシュ (スコア:2)
AndroidのOS自体がクラッシュというか、固まったり再起動したりしたことがない。
なので、あなたがはずれを引いたんでしょう。
国産機群に当たりが入っているかは知りません :-)
Re: (スコア:0)
スマートフォン展開を焦った国産のAndroidは安定性に欠けている印象が私もあります。
一昔前のWindowsをメモリが足りていない環境で動作させた時の感覚に近い。
不安定が過ぎて着信するとよく再起動がかかるのには呆れました。
ただ、余計なカスタマイズされていない&ハードウェアのスペックが高い最近のAndroidはちゃんと安定していますよ。
Re: (スコア:0)
とりあえず機種名を明確に挙げるのと、
「それってAndroidそのものの話なのか？」
を明確にした方がいいでしょうね。
でないと、
「iOS5にしたらやたら不安定になった状態」
とかまで含めないとiOSと比較できなくなります。
Re: (スコア:0)
統計データ出してる記事へのコメントで、「経験的に」ですか。
他の人のコメントにもあるように、具体的な機種名と、再現手順も出さずに「経験的に」ですか。
おもしろいですね。
この記事はFUD (スコア:2, おもしろおかしい)
Appleがきちんとテストしてるんだから、野放しのAndroidアプリより悪いわけがない。
最後に書いてあるように出たばかりのiOS5に軽微な問題があっただけですよ。
それに、たとえクラッシュ率がちょっと高かったぐらいでなんだと。
そんなことで、Appleのすばらしさが曇ったりしない。
Re: (スコア:0)
こんなところも、監視してるのか。
大変だな。
Re: (スコア:0)
iOS5はきちんとテストしてなかったのか
などと真っ向から釣られてみる
Re:この記事はFUD (スコア:1)
＞iOS5はきちんとテストしてなかったのか
きちんとテストしてたOSって今まであったのか。
とか言うとフレームの素っぽいけど、完全なものって今までもこれからも無いんだろうなぁ。
#と思ってるのはどこのペシミストだい？
1%未満で (スコア:2)
平均的な確率を比較されてもあんまり意味が無い。最低限、発生頻度のヒストグラムがないと評価にならないと思う。
発生するケースでは毎日起こるのだろうし、起こらないケースでは起こらないんでしょ？
OS自体の不定動作が支配的で、ほとんどのバグがOSの不定動作を踏んでいることに起因しているならともかく、きっとそうじゃない。
stacktrace (スコア:1)
androidの場合は、どうもstacktrace付きでのバグレポートが送れるみたいなんですが(というか、機器が多様なandroidだと、こういう仕掛けでもないと話にならないのでしょうけど)、iOSの場合は落ちたら落ちっぱなしですよね。
このへんの設計の差がどの程度デバッグに効いてるか、両方で開発経験がある方に伺ってみたいです。
Re: (スコア:0)
クラッシュ数よりそっちのほうが興味深いですね。
1企業が全部開発しているわけじゃないので単純にクラッシュ数や％だけ比較してもいまいち
Androidは機種のスペック差が激しすぎて (スコア:1)
アプリの評価の低スコア付けてる人が悉く低スペック機だったりする事もあるので、推奨スペックの指標になるようなものが欲しいですね。（Windows7のエクスペリエンスインデックスのような・・ ）
Re:Androidは機種のスペック差が激しすぎて (スコア:2)
せめて画面の縦横ピクセル数だけでも規格作って欲しいよ・・(>_<)
欲しいですよね。何を基準にして決めたらいいのかものすごく悩みます。
普通にフルスクリーンにすると、CG チームから駄目だし食らうし、かといって最低解像度に合わせるわけにもいかないし…と、かなり悩むところです。
Re:Androidは機種のスペック差が激しすぎて (スコア:2)
解像度を固定すると端末のフォームファクタを縛るので、それはそれで
デメリットでしょう。
Windows Phone 7.5は解像度が1種類しかなく「ドット単位できめ細かい
レイアウトができる」ことを開発者向けイベントでアピールしてましたが、
次のWindows Phoneでは3種類の解像度をサポートするというので
決め打ちでレイアウトしたアプリがどうなるのか興味あるとこですね。
iPhoneもこのまま解像度を変えない訳にはいかないでしょうから
次の世代か次の次か知りませんが、いずれ変えてくるだろうなと。
Androidはいろいろ面倒とはいえ、LayoutManagerを使ったり解像度ごとの
レイアウトを用意したりと対応できなくも無い仕組みは用意されてるので
それで頑張るしか無いでしょう。その代償として自由なフォームファクタが
あるわけで、何事もトレードオフです。
Re:Androidは機種のスペック差が激しすぎて (スコア:1)
iPhone(iOS)は既に解像度をｒetina採用で変更してますし、読み込むイメージリソースの自動切り替えとか、フリーズームでないだけでそれなりに対応する仕組みはありますよ?
Re:Androidは機種のスペック差が激しすぎて (スコア:2)
なるほど。iPhoneというかiOSのプラットフォームも既にいろいろあるし
解像度を変える仕組みは持ってるでしょうね。
同じようにAndroidにもあるので、解像度がいろいろあるから駄目的なことは
無いと思うんですけどね。面倒ではあるのは確かだけど。
Re:Androidは機種のスペック差が激しすぎて (スコア:1)
解像度の中もでも縦横比が違うってのはかなり頭が痛くなると思いますよ。
ただ単に拡大では駄目で、旨くレイアウトしなおさなければ画面からはみ出すとかになりかねません。
その点、iPhoneなんかは解像度上がってもアスペクト比は変わってないので比較的マシかと。
Windows向けでも、普通に4:3(800x600,1024x768)、5:4(1280x1024)、16:9(1280x720,1980x1080)、16:10(1980x1200)とか最低でも有りますし。
Windows8も16:9推奨ですが、4:3や16:10とか、縦横の回転時にどうしようと悩んで試行錯誤してたりします。 [msdn.com]
Re:Androidは機種のスペック差が激しすぎて（オフトピ） (スコア:1)
見事なTypoでした・・・orz
Re:Androidは機種のスペック差が激しすぎて (スコア:2, 参考になる)
アプリ開発者側で定義するマニフェストファイルで
配布対象とする解像度は制限できますよ。
それをしていないなら、開発者自身が
「低い解像度の端末でも動くようにしてます」
と宣言してるわけです。
Re:Androidは機種のスペック差が激しすぎて (スコア:2)
> 画面の縦横ピクセル数
Andoroid3.2以降は端末の画面にアプリの解像度をあわせる機能ついてます。小さい画面のアプリを拡大するような用途。まぁうまくいったりいかなかったりで無いよりマシ程度。
アプリ作る時にフレキシブルに画面にあわせてUIの要素を変えれる仕組みもあります。複雑すぎない画面であれば作者が意識して作ればわりと簡単に対応出来ます。
>スペックの指標
中華パッドとかありますしね。高スペックでも裏でいっぱい動かせば遅くなるし。iOS4以前のシングルタスクはその辺は上手いこといってますよね。Andoroidは使うほうにある程度使い方を求めらているのかもしれませんね。タスクをなるべく落とすとか、アプリを入れすぎたら遅くなるとか。
日曜プログラマ (スコア:1)
アプリ開発の敷居やハードルの高さの違いなんじゃないの？ 知らんけど。
プログラミングに慣れていない人が思いついてちょっと勉強して作って公開、
そんな感じのアプリがiOSの方が多いとかそういうことじゃないのかな。
自分のところで動いてりゃ他でも動くでしょ的な軽い気持ちで公開。
Androidアプリの開発者って、他の環境での開発経験もあるイメージ。
Re:日曜プログラマ (スコア:4, すばらしい洞察)
敷居は圧倒的にiOSの方が高いですよ。MacOSが要るだけじゃなく、他では余り使われない
Objective-Cとかやんないとならないし。Objective-CなんてMacOSかiOSの開発しないんだったら
ほぼ接する機会はない言語ですからねえ。
Androidは良くも悪くも、そこいらで使われてるJavaだし、Windows、Mac、Linuxで開発できる。
ちょいと始める人もAndroidの方がずっと多いでしょうね、タダでできるし。DalvikVMは標準の
JavaVMと違うとか、フレームワークが標準のJavaと違うとか細かなことはあっても、
Java知ってればなんとかなるレベル。
その割にクラッシュ率が低いという調査が本当なら、いろいろ諸説出てるけど、
単純にJavaインタープリタ上で動いてるからじゃないのかなー、と。
なんだかんだ言ってもネイティブよりバグ出ししやすいし。VM上で大暴れするのにも限度があるし
ネイティブコードとはいろいろ違う。
Re:日曜プログラマ (スコア:1)
てきとーなPCさえあれば開発できるandroidと少なくともMacが必要なiOSでは、前者の方が敷居は圧倒的に低いでしょ。
しかも他で使い道のないObjective-C覚えなきゃいけないとか。
iOSには自動テストツールとか無いの？ (スコア:1)
Windows Phoneの場合、開発者の開発環境でも実行可能な自動テスト [microsoft.com]があって論外なバグはそもそも公開不能だったりしますが。
Androidでクラッシュが問題になるのは (スコア:0)
Androidでクラッシュが問題になるのは、アプリよりドライバーの方の気がするね。
実際よくクラッシュするという人によると、アプリよりもOS自体に問題が（OSよりもドライバーやハード？）あることが多いから
有名メーカーならまだましかもしれないけど、あまり売れてないメーカーや、あまり経験のないメーカーの初期ロットだと
いろいろこなれてなくて問題続出もよくあることだからね。
Re: (スコア:0)
スマフォのユーザーにとって原因がアプリかドライバーかなんて完璧にどうでもいい。それどころかハードウェア起因とソフトウェア起因の違いさえ「壊れた」という言葉のもと一緒くたにされる。
Re:Androidでクラッシュが問題になるのは (スコア:1)
たしかに、PCの様に一度に複数台所持したり、することが少なければ
原因の切り分けがしにくいですから、そういう意味では、どっちも大差ないのかもしれませんね。
ですけど、いまはWebで知識の共有が盛んですので、機種特有の現象や不具合情報の共有もそれなりにできてるんではないでしょうか？
>アプリかドライバーかなんて完璧にどうでもいい
でもこれは、特定のアプリの時か、特定の機能を使ったときにおきるかで、大体の原因が分かる気がします。
そしてこの違いは、対処方法を調べるときにも重要になってくるので、一緒くたにして良いものではない気がします。
>ハードウェア起因とソフトウェア起因の違いさえ「壊れた」という言葉のもと一緒くたにされる。
うーん、ちょっと違うなぁ。Androidは分かりませんが、iPhoneのiOSの場合にはソフトウェア的な破損や齟齬があってもOSの再インストールという手段もあります。
ユーザーにとって、自分で修復できる範囲かそうでないかは結構違います。
Re:Androidでクラッシュが問題になるのは (スコア:1)
コメの言いたかった事はそうではなく、一般ユーザーからしてみれば一様に「壊れた」という状態だということでは？
OS標準アプリのクラッシュ (スコア:0)
初代iPad(iOS5)で最近Safariのクラッシュ遭遇回数が増えてます。
Flashを載せないのはクラッシュ原因になるからという話がありましたがなくても頻繁に落ちるじゃないかと。
# iPad2ならそんなこと起きない、とか噛みつかれるんだろうな。
Re:OS標準アプリのクラッシュ (スコア:1)
4SでもSafariは落ちるのでiPad2でも変わらないんじゃないですか。
ハードよりもiOS5の品質に問題ありそうですが。
Re:OS標準アプリのクラッシュ (スコア:1)
具体的な指標はないですが、
iPad2でもSafariは落ちますよ。
複数タブ開いているときか、その状態からタブを閉じ始めるとポロっと落ちます。
(メモリ開放処理に問題があるのかも)
Re: (スコア:0)
初代も2も両方使ってるけど初代の方が圧倒的に落ちやすい
Re: (スコア:0)
噛み付くわけではありませんがiOSでのSafariは（恐らく）メモリ不足でよく落ちますね．
iPadやiPod touchは256MBしかRAMを積んでいないのでiPad2やiPhone4ならば落ちない場面でもメモリが足りなくなりがちです．