SysStats Liteの「測定できない領域」は、わかりにくいものですよね。
iPhoneのメモリが足りない？ パワーリンゴ/ウェブリブログ
うーん、空きが非常に少ないのと、測定できない領域の多さが気になります。今までも使い込むとこのような円グラフになることはありましたが、今回は再起動からあまり時間が経っていません。
iPhoneのメモリが足りない？ パワーリンゴ/ウェブリブログ
SysStats Liteの測定できない領域が、今ひとつわかりにくいかもしれませんね。
以下に、アプリの中に入れてある説明文の抜粋を示します。
メモリ使用状況
メモリの使用状況を、数値と円グラフで表示します。表示されている数値は、
host_statistics()関数のHOST_VM_INFOで 取得し た、vm_statistics構造体メンバの値をメガバイトに換算したものです。
空き free_count 固定中 wire_count 現在使用中 active_count 現在非使用中 inactive_count 確保中 wire_count + active_count + inactive_count 測定可能値合計 空き + 確保中 測定できない領域 物理メモリサイズと測定可能値合計の差分です。これも、使用中の領域として考える必要があります。 物理メモリサイズは、
sysctl()関数のCTL_HW + HW_MEMSIZE(hw.memsize)で取得した値を使用しています。
実際の値は、常に、116MBのようです。
これでも、ちょっとプログラミング視点の説明なので、わかりにくいかもしれません。少し補足します。
本来、ここで取得される、空き、固定中、現在使用中、現在非使用中の合計が、物理メモリサイズと限りなく一致するはずですが、実際にはそうはなりません。
そこで発生する差分を「測定できない領域」として表現しています。それが実際にどのようなものであるのかについては、残念ながら判明していませんが、見た目からは、例えば、以下のような場合に、「測定できない領域」が増えるように思います。
iPhoneを再起動してからの経過時間よりも、使い方による影響の方が大きいと思われます。
そして、それらのアプリケーションのプロセスを終了させると、「測定できない領域」が減って、空きが増えます。
個別にそれらのプロセスを終了させるのもいいですが、時間に余裕があるときには、iPhone自体を再起動するのが確実でしょう。
あと、iPhone 3G Sでは、RAM容量が倍増するので、メモリ不足が起こる可能性は、激減するのではと思います。(個人的には、これにかなり期待しています)
※ 「測定できない領域」については、特にApple社の資料等で説明されているものはありません。見た目の現象から推測している部分が多いので、表現が曖昧になってしまっていることを、ご理解いただければと思います。
iPhone3GSのRAMは、噂通り倍増したみたいです
今日の日中に、iPhone abonnement kopen? Bestel de 5s, 5c of 4s bij T-Mobileで、iPhone3GSのスペックが公開されていたのですが、今見たらCPUやRAMに関する情報が削除されてしまったようです。やはり、本来見せてはいけない情報だったんでしょうね。
とりあえず、そのスナップショットが残っている記事を見つけました(消される可能性を、ちゃんと予見していたんですね)。
公開しているのはT-mobile社のオランダサイトで、それによれば、プロセッサーは16GB/32GB共に600MHZ動作、またシステムメモリも両者共に256MB搭載であると記載されています。
http://blog.sohaya.com/2009/06/10/iphone-3g-s-600mhz-processor-256mb-ram/
ちなみに、現行のiPhone3Gは、400MHz CPU / 128MB RAMなので、事前の噂の通り、RAMは倍増です。
個人的には、この「倍増したRAM」だけでも、乗り換える価値は大きいと思います。現在、メモリ不足でアプリが異常終了したりフリーズすることが多いですが、そういうことが激減することが期待できます！
SysStats Liteには、物理メモリサイズを表示する機能があります。もしも、3GSを早く手に入れることができた方は、ぜひお試しいただき、数字で「倍増したRAM」を実感*1してみていただければと思います。
*1:実際に表示される値は、VRAMとして使われる分が差し引かれるので、256MBより若干小さい値になると予想されます。
待ち受け状態のiPhoneが熱くなったときの対処例
先ほど、待ち受け状態で、何もアプリを動かしていないiPhoneが突然熱を持っていたので、SysStats Liteを使って状況を確認してみました。
【5/24 追記】 一点、大事なことを書き忘れていました。このときには、iPhoneの再起動だけでは、問題は解決されず、再起動後に、ここで説明した処置をしたことによって、解決されました。
なぜか、CPU使用率が100%に張り付いたままになっていました。具体的に、どのプロセスがCPUを多く使っているかを調べたいところですが、残念ながら、SysStats Liteでは、そこまで見ることはできません。
iPhoneをMacに接続して、iPhone SDKに付属のInstruments*1というツールを使うことで、プロセスごとのCPU使用率を見ることができます。
赤枠で囲んだ部分が、CPU使用率が最も高いプロセスですが、実際には、標準のメールアプリケーションでした。とりあえず、そのプロセスを終了させてみることが、まずは得策だと考え、メールアプリケーション起動したところ、CPU使用率が急激に下がり、平常な状態に戻りました。本当は、このあとにホームボタン長押しで終了させようと思っていたのですが、それは必要ありませんでした。起動するという割り込みが入ったことで、CPUを多く使っていた(暴走していた??)処理が終了してくれたのかもしれませんね。
結局、「メールアプリケーションが暴走していたようだ」という見た目の事象以上のことはわかりませんが、とりあえず解決したので、この場はよしとすることにしました。
もしも、似たような状況に遭遇した時は、この方法で解決する可能性もあるので、よろしければお試しください。
あと、やはり、iPhone SDKがないとプロセスの状況を見れないのだとすると、ちょっと不便ですね。
もしも、各プロセスの状態を取得することができるのであれば、SysStats Liteにその機能を組み込みたいのですが、今はその方法がわからないため、実現できていません。(取得できないように制限がかけられている可能性もありますが、真偽は不明です)
いずれにせよ、何らかの形で、そのあたりの情報を見ることができるようになればいいなと思っています。
*1:詳細は、Instruments User Guide: About Instrumentsを参照してください。
Malloc Simulatorはリジェクトされました。
ここしばらく、別のアプリケーションの開発に重点を置いていたため、報告が遅れましたが、別途申請していたMalloc Simulatorが、今月初めにリジェクトされました。理由は、「iPhoneに対する不的確な診断情報を提供するので、ユーザを混乱させる」というものでした。決して、誤った情報を提供してるつもりはなかったのですが、一般のユーザには誤解を与えると解釈される面はあったかもしれません。
さらに、SysStats Liteで、レビューの長期化を回避するために、実装を取りやめた「メモリ解放機能」とともに共通している点が1つあります。それは、意図的にメモリ不足の状況を作り出し、そのときに起こる内部動作が見えるようにしているということです。
わざと異常な状況を作り出して、その副作用を利用することを目的にしたことが、レビューの長期化やリジェクトに繋がったのではと、自分なりに理解しています。
Malloc Simulatorに関しては、問題を修正して再申請するのは不可能なので、残念なことですが、お蔵入りとなります。
その一方で、これらの過程でいろいろと得られたこともあります。過去に、この日記で説明したことと重複する部分もありますが、ここでもう一度整理してみたいと思います。
SafariやMailなどを終了させる処理について
すでにいろいろなところで説明されていますが、SafariやMailなどのバックグラウンドプロセスとして動き続けるアプリが、RAMを大きく消費しています。それらのプロセスを終了させれば、空きメモリが増えるのは自明ですが、iPhoneOSでは、システムコールを使ってプロセスを終了させることは許可されていません。ところが、何もしていないのに、それらのプロセスがいつのまにか終了していることがあります。いろいろ調べているうちに、フォアグラウンドで動いているアプリがメモリを確保しようとして空きメモリが不足していると、SpringBoardがSafariやMailなどを終了させて、空きメモリを作ろうとすることがわかりました。仮想メモリがないので、swapoutする代わりに終了させるという意味で、それは妥当なことでしょう。
SysStats Liteの「メモリ解放機能」は、その状況をわざと作り出したことによる副作用を利用して、バックグラウンドプロセスを終了させるという方法で実装していました。このときに、一度に確保するサイズが大きすぎたり、メモリを確保するペースが速すぎると、フリーズしたり異常終了するので、ゆっくり少しずつ確保して行くようにしていました。
空きメモリがかなり少なくても異常を起こさないアプリがあるのはなぜか?
当然のことですが、空きメモリサイズより大きなメモリを一気に確保しようとしたり、少しずつであっても、速いペースでメモリを確保してしまうと、異常を起こす確率は高くなります。
空きメモリが少なくても問題なく動くアプリでは、「メモリ解放機能」でやったことと同じような状況が内部で起きていると考えられます。裏を返せば、そういう実装になっているアプリは、異常を起こしにくいと言えるかもしれません。
最後に
実は、Malloc Simulatorは、このあたりのことを説明することを目的に作ったものでしたが、AppStoreに並べるのは適切ではなかったかもしれません。
あと、これらの振る舞いは、ドキュメントで説明されておらず、あくまでも観察した結果をまとめたものになります。将来に渡ってこの通りに動く保証はなく、iPhoneOS 3.0では、変わる可能性もあります、また調べてみたいとも思いますが、開発者の立場から言わせてもらうと、このあたりの標準的な振る舞いは、正式なドキュメントで説明されているとありがたいですね。。。
とりあえず、ここで書いたことが、みなさんの参考になれば幸いです。
SysStats Lite 1.1のダウンロード数推移
Ver.1.1がリリースされてから、日本のAppStoreでの順位が下がり続けています。すでに、かなり多くの方にダウンロードしていただいているので、当然のことと思います。たくさんダウンロードしていただいたことは、自分の励みにもなり、本当に感謝しています。
全世界のダウンロード数合計でみると、何とか横ばいをキープしています。というか、ここに来て、なぜか海外のダウンロード数の比率が高まってきました。これは、今までには見られなかった傾向です。
ここから、今後の教訓になることが得られればいいのですが、残念ながら、なぜこういう状況になっているのかがわかっていません。14日は米国でのダウンロード数が増えたということが、唯一の手がかりです。イースターとか関係あるのでしょうかね。。。
そもそも、ダウンロード数自体が、傾向を測れるほど多いわけではないので、ちょっとした偶然の変化でも、比率は大きく変わります。なので、あまり考えても仕方がないかもしれないですが。。。
もう少し様子を見つつ、また、考えてみたいと思います。
iPhoneに付属のメールアプリを自動起動させないようにする方法
もしかすると、ご存知の方も多いかもしれませんが、説明されているドキュメントや記事が見つからなかったので、書いておきます。
iPhoneに標準で付属しているメールアプリケーションが、ホーム画面のアイコンをタップしなくても、勝手に起動されていることがあると思います。その場合、ホームボタンの長押しをして終了させても、いつのまにか、再起動されています。
(実際に自動起動されているかどうかは、SysStats Liteの「稼働中のアプリケーション」画面で、メールアプリケーションの起動時刻を見ることで確認できます)
私が試してみたところでは、「設定」→ 「データの取得方法」画面の設定値によって、そのあたりの動きが決まるようです。以下のように、「データの取得方法」が「オフ」になるよう設定すると、自動起動されなくなります。
ただし、このように設定してしまうと、メールの受信やMobileMeとの同期を、すべて手動で行うことになり、利便性は損なわれることになります。
ちなみに私は、
- プッシュ: オン
- フェッチ: 15分ごと
の、自動受信派です。
購入時の初期設定がどうなっていたのかは、残念ながら覚えていないです。
空きメモリサイズを大きくすることを、優先的に考えるという方は、一度、確認してみるといいかもしれません。
Apps Coreさんが紹介してくれてます。
いつも、的確に紹介していただき、感謝しています。
