FC2ブログ

鈴の音情報局blog

携帯関連の将来や最新の技術情報や業界の行く末などを適当に綴るblogです。 内容の信憑性は?余り信じない方がいいと思います。
本家の鈴の音情報局はこちら→http://suzunone.0g0.jp:8800/
スマホ・携帯端末アクセス[ランキング][アクセスシェア(グラフ)] (毎年10/1にログをクリア)

携帯のOSがもっさりになったり不安定になる話

最近のARROWSの話。

無線にゃん氏のこの記事の中でARROWS Zを利用してみてAndroid OS駄目駄目な所が書かれている。
私がAndroidを使っていて「多分こうじゃないか?」と思っている事を書いてみる。

OSの中には色んなデータを保存している領域が有り、Windowsなら設定ファイルやレジストリがそれです。

Androidではレジストリの欠点は既に大きく知られているので採用されたのはSQLiteというDatabaseです。
こちらは設定などだけではなく、アプリのデータまで保存できるスペースも取れる優れもの。
SQLという汎用に開かれたもので設定やデータを保存できるようにしたOSの設計は私は素晴らしいと
感じました。

しかしデータベースは普通に扱えば厄介な問題が噴出する部分を引き受けるプログラム。
使っているうちにぐちゃぐちゃになってしまうのはよく知られた問題です。

私はAndroid OSを採用した端末が使い込むともっさりしてくる理由の一つにこのデータベースが
理由じゃないかと考えています。

しかし私が普段使っているXperia arcは氏が言っているほど不安定になったという印象は有りません。
そこにはOSを扱う上での細かくテクニックが有るのかも知れません。
まあユーザー側の扱いも大いに関係有ると思いますけど。


でですね。
このSQLite、採用しているのは何もAndroidだけでは有りません。
OSの設計ではPCの頃から経験が有り、OSの設計の先輩格であるアップルのiOSでも採用されています。
ちなみにiOSでも使い込めばもっさりになるし、不安定になって初期化というのは別に珍しい話では
ありません。現在の複雑化したOSが持つ現在病です。どんどんともっさり化や不安定化していくのは
何もAndroidを採用した端末だけでは有りません。大きなデータを扱い削除を繰り返すとよりもっさりと
不安定が加速します。

氏が取り上げているWindowsだって同じことです。
レジストリや設定ファイル、それらがファイルシステムの中でフラグメント化がましていきますと
もっさりとしてしまうのです。OSがもっさりしてしまうのは殆どがファイルシステムの遅延分が
ユーザーに倍倍ゲームで届いてしまうことが原因ですが、その倍倍ゲームを作り出してしまう構造が
OS内の仕組みで違うわけです。

AndroidやiOSが採用しているSQLiteの手法ももっさりや不安定を招いてしまっているので万全では
ないという事なのでしょう。



ちなみにこのSQLiteですが、ほったらかして置くと未仕様になった部分もそのまま放置したりして
無駄な部分が出来てしまいます。また通常の読み書きでもちょっとデータを追加して削除しても
ファイルサイズが増えていってしまいます。SQLLiteでは(というか通常データベースでは)削除
してもファイル容量は小さくはならず、一方的に容量が増えていくだけです。なので、普通に
つかっているとどんどんと容量を食いつぶし、「特に悪い事をやっていないのに」ファイルシステムを
食い荒らしていきます。

早い話SQLiteも結構悪人なんです。


しかしこれを解決する有力な方法も有ります。
それはSQLの"vacuum"というコマンドです。

Sqliteのvacuum ~ よい加減

空き領域の開放 ~ DBOnline

[Firefox] places.sqliteはvacuumしてreindexする ~ めも

AndroidやiOSを使っている人でSQLを知り尽くしている人はごく少数しかいないと思いますが、
しかしながらほんの一部の人達は構造を知り尽くしてこうして手を打っています。

WindowsマシンでもHDDのデフラグを行って中身を整理すれば驚くほど高速化されることもしばしば。
しかし昔のMS-DOSの頃のような究極のファイルシステムの整理が出来るわけではないので、昔の
半分具合の効果しか見込めません。

ファイルシステムに手をつけてない以上、vacuumに期待できる効果はそれほど過大なものでは
ないかもしれませんが、私の知る限りvacuumで「安定化した」「高速化した」という声が聞かれる
のは間違いなく有ります。


3つのリンクの最後の分はAndroidが対象では有りませんが、vacuumして更にreindexするという
ことで大きな効果が期待できることを表していると思います。


複雑奇怪なマルチタスクOSの負荷は相当なものです。
WindowsもAndroidもiOSもそこで苦労しており、何時までも安定動作し続けるということを
担保する事を出来ていません。

フィーチャーホンならという方は確かにいますが、よーく観察していると機種によりはしますが
使い込むとちゃんともっさりする端末は少なくないです。限られた環境なのでもっさりども
今ほどではなく、気づきにくいかも知れませんが構造を知っているともっさりするという理由は
あっても、もっさりしないという理由が有りません。良くも悪くも高級なOSとはそういうものです。

それを完璧に避けるにはMS-DOSを使ってエコロジーやノートンの割と複雑化していない所期のほうの
バージョン辺りで定期的にHDDの整理をするぐらいしか手はないと思います。1ファイルづつOSの
システムファイルまで含めて前からきっちり並べてくれますから、ちゃんと元に戻ります。

高級化した複雑なOSは「『理由が分からない』『端末それぞれの理由で』動作速度の低下や
不安定さ」が起こると多くの人が言いますが、私は余りそう思いません。

確かに原因は使っている端末それぞれでしょう。しかし多くは内部データの保持とアクセスが
原因で少しづつ壊れてくるからです。マルチタスクがその破壊に拍車をかけました。
そこはセマフォやらなにやらで無理に同期を取りますが、そのセマフォも不意の破壊を
引き起こす原因にもなっていたりします。

なんと言っても「俺が言いというまで絶対ここは通さない」という機構なんですから。
例えばトイレの前でもう漏れそうな人相手でもセマフォは冷酷です。
まあお行儀がいいプログラム相手ばかりならいいのですが、中には「ある程度」で
セマフォが開通することを期待してエラー処理をしていないものも有ったりする訳です。

正常な処理が出来ていなかったり返り値が返ってきていなかったり、そういう細かい所から
綻びは生まれていきます。OSの不安定さが生まれていくのはそういう事の積み重ねなんですよ。


例えば排他処理を要求されることが多いと言えばやはりハードウエア回り。
デバイスドライバーをいい加減に書けば、想定が甘いドライバーを書いていればどうなるのか。
冒頭のネタに戻ってARROWS Zがアアアッな血を引き継ぐ理由ってそこしか無いように思います。

一見コードを目で追いかけるだけでは見えてこないタイミングの妙なんて事も有りますしね。
案外チップセットのデータシートを取り寄せてユーザー側でドライバーを書けば優秀な端末に
生まれ変わる可能性だって有るかも・・・なんて思うのですが。

カーネル作者の方の中にはもしかすると猛者がいてarmの16進コードを生編集して安定化させら
れる人がいるかもいないかも・・・とか思ったりするわけですが、GalaxyやHTC、Xperia等の
グローバル端末向けにはとんでもない猛者揃いの世界ですが、国産端末向けには精々紐付きや
紐なしroot取りをするのが精一杯の状況でこんな事を言うのは馬鹿げてますね。



まあ不安定やもっさりにもしっかりした理屈どおりの理由があるって訳です。
でも複雑すぎることと製品サイクルが半年毎なので完全な安定化なんて絶対無理ですよって
いう古い時代の時代遅れのソフト技術者の意見を言って終わりです。
関連記事
  1. 2012/06/13(水) 19:57:53|
  2. 携帯
  3. | トラックバック:1
  4. | コメント:3
<<スマートホンヲタの飲み会 | ホーム | ドコモ、固定→携帯通話料を値下げ>>

コメント

勉強不足でちょっとよくわかりません。

Windowsの場合、レジストリという1つの箱に
OSもアプリケーションも書き込んでいって肥大化や断片化して最終的にOSが重くなるっていう論理は分かります。

しかしSQLiteの場合、
アプリケーションがそれぞれの個別に用意したSQLiteデータベースファイルに対して書き込んでいくものと認識していまして、
そこでその個別のデータベースファイルが肥大化や断片化した場合、
そのファイルを使用しているアプリケーション自身が重くなることはあっても、
OSはそのデータベースファイルを使っていないので影響しないと思っていたのですが、間違いでしょうか?

AndroidやiOSのOS自身が設定等を保存するためにSQLiteを使っているということなら分からなくもないのですが、
そのソースを見つけることができませんでした。

アプリケーションが重くなってOSが重く見えるっていうことはあると思うのですが、
無線にゃん氏の記事ではアプリケーションを入れて消してを繰り返してたら重くなったということなので
それとはちょっと違うのかなと思っています。
  1. URL |
  2. 2012/06/15(金) 01:04:36 |
  3. やす #TQgt9FFg
  4. [ 編集]

>やすさん
Androidって(iOSもそうなのかも知れませんが)SQLiteになんらデータを書いていないのですか?
それは知りませんでした。ソースコードを読んでSQLコマンドを発行していない事を確認なされた
って解釈でいいのですよね?私は2GBものソースコードを読める程時間も体力も無いので
出来ませんが、氏の努力には頭が下がります。

ちなみにSQLiteがどうファイルを管理しているのかまでは私は知らないんですが、
どんな管理手法を取っても速度低下は起こりますよ。逆に速度に対して影響を全く与えない
データベースの構築法が存在するのなら知りたいです。
個別ファイルを用意してデータを管理する方法は目的のデータにたどり着くまでのデータツリーの
追いかけ方を有る程度までファイルシステムに任せて、ファイルにたどり着いてからはデータベースの
プログラム側で追いかけるという手法ですが、確かにファイルシステムに有る程度任せておきますと
OSのキャッシュやら何やらでリードタイムを軽減する為の機構が利いてくることが有ります。
しかしどれだけデータの蓄積量を増やしても遅延が一向に増えないという事は有りません。
この辺りは自力で大量のデータ管理をするプログラムを組んだことがある方なら理解できると思います。
私はMS-DOSの頃にこれを嫌と言うほどやってきました。

要はどうデータを置く構造をとっても目的のデータにたどり着くまでのツリーの追いかけ方が変わる
だけで時間が変わらないとかそういう事は無いのです。しかもデータは逐次書いて削除してと
繰り返せばどんどんフラグメント化が進んでいきます。

それはデータベース内でも、OSのファイルシステム内でもそうです。
シリコンドライブならシーク待ちが無いからフラグメント化しても関係ないだろと思う人も
いるかもしれませんが、そう話は簡単ではないですよ。

高速読み出しにはルールがあって、そのルールを外れると沢山のウエイトやレイテンシが
かかってきます。フラッシュメモリのシーケンシャルアクセスとランダムアクセスの速度は
同じでは有りません。

その辺が複雑に絡み合って動作速度が決まるのですが、私はファイルシステムの
フラグメント化が大きな要因と考えています。それを加速するのがSQLiteの書いて
削除しての繰り返しでSQL内でのフラグメント化も大きな要因になっているだろうなと
思っています。

無線にゃん氏の書いていた「インストールして削除して」はこのフラグメント化を大きく
促進させてしまうことだと思うのですよね。

フラッシュメモリって、書き換え回数の限界が有るので、一見HDD等の様なファイル管理を
されているようでも、実は全く違う管理をされています。同じ場所の書き換え回数を出来る限り
最小にする為にメモリ内全体を巡回するようにぐるぐる回って利用するようにコントローラが
操っています。それが更に事をややこしくするんですよ。

空きが広ければまだいいのですが、半分以上埋まっているような環境で、SQLiteのように
ドライブの利用が一方的に膨らむようなものが含まれていると更に事が酷くなっていくのです。

あまり細かく書くと本一冊できてしまうので端折りますが、カクカクシカジカの事情で
重くなるんだと私は書いていたという事で納得していただけますでしょうか?
勿論それは絶対ではないですが、しかしそれで絶対遅くならないという事も無いのですよ。

データベースがそんなに簡単なものならこんなに何種類もデータベースプログラムは出て
きてないでしょうし、何よりもそんなものを使わずに自前で管理する人も多いと思いますよ。
  1. URL |
  2. 2012/06/16(土) 03:56:00 |
  3. 鈴 #GpEwlVdw
  4. [ 編集]

>鈴さん
わかりにくくてすみません。

私が言ったソースとは情報元のことで、ソースコードではありません。
情報元が見つけられなかったってことです。

たくさんコメント書いて頂いたのですが、私はそんなに難しく考えていません。

Microsoft Accessって使われたことあります?
あれって目的、アプリケーション毎に1つのMDBファイルを作って、そのファイルに対してSQLを発行などします。
(SQLiteも同じです。目的、アプリケーション毎にファイルを作って、そのファイルに対してSQLを発行などします。)

MDBファイルが肥大化してアプリケーションからのアクセスが遅くなることはよくあります。

ただその程度のことがOSに影響するの??と単純に思ったんです。

昔WindowsのFirefoxのSQLiteファイルが500メガぐらいになってFirefoxが重いってこともありました。
あれもかなり肥大化して断片化していたと思います(vacuumしてreindexしましたがw)
それでもFirefoxが重いってだけでOSは別に遅くなかったです。

WindowsとAndroid、HDDとフラッシュメモリ、また、ストレージの相対的な規模の違いで
例としては事情がちょっと違うかもしれません。
程度の問題だとは思うのですが、これまでのWindowsでの経験的にSQLiteがファイルシステムのフラグメント化の元凶っていうのはどうなのかな?
って思っただけです。

あとちょっと関係無いですが、
>無線にゃん氏の書いていた「インストールして削除して」はこのフラグメント化を大きく促進させてしまうことだと思うのですよね。
というコメントを読んで思ったのですが、SQLiteのvacuumってSQLite的には最適化されると思いますが、
ファイルシステム的にはフラグメント化しません?
大きなファイルを小さくして綺麗にする、また大きくなったのを小さくして綺麗にする、その繰り返しをすると
ファイルシステム的にフラグメント化する気がします。これってアプリケーション的には良いことだけど、OS的には悪いこと?
  1. URL |
  2. 2012/06/16(土) 09:55:18 |
  3. やす #TQgt9FFg
  4. [ 編集]

コメントの投稿(投稿時には必ず何らかの名前を付けてください)


管理者にだけ表示を許可する

(名前を入れないとクリックできません)

トラックバック

トラックバックURLはこちら
http://suzunonejh.blog15.fc2.com/tb.php/2593-f9d7f0cf
この記事にトラックバックする(FC2ブログユーザー)

まとめtyaiました【携帯のOSがもっさりになったり不安定になる話】

最近のARROWSの話。無線にゃん氏のこの記事の中でARROWS Zを利用してみてAndroid OS駄目駄目な所が書かれている。私がAndroidを使っていて「多分こうじゃないか?」と思っている事を書いてみる。OSの中には色んなデータを保存している領域が有り、Windowsなら設定ファイル...
  1. 2012/06/19(火) 00:28:35 |
  2. まとめwoネタ速neo

最近の記事

機能リンク

最近のコメント

カテゴリー

ブログ内検索

ブログリンク

RSSフィード

QRコード

QR

月別アーカイブ



メールフォーム

お問い合わせ・ご質問はこちらから。

名前:
メール:
件名:
本文:

suzunone.m(あっと)gmail.com に
直メでもOKです。