こんにちは、共同開発部 iOS アプリ開発担当の図子です。 iOS 開発をしている皆さんはメモリリークのチェックを行っていると思います。どのような方法で確認していますか？おそらく以下のような方法で行っていると思います。 ・Static Analyzer を使う ・Instruments の Leaks テンプレート でも、これだけでは見つからないメモリリークが起こりうることをご存じでしょうか？ addSubview: で何枚もの View を貼っていないか？ 実際にメモリリークと呼べるかどうかは微妙かも知れませんが、開発者の意図しない不要なメモリがドンドン確保される可能性があるのでここではメモリリークと書かせていただきます。 非常に気付きにくいメモリリークとは view に addSubview: する際に起こりやすいのです。 以下のコードを見てください。ある UIViewControll
Adobe のヘルプサイトに、Flash Platform 用コンテンツのパフォーマンス最適化のドキュメント （ベータ版） が公開されています。（Optimizing Performance for the Flash Platform） Flash Player 10.1 における変更点も詳しく説明されています。 もう直ぐ内容のより充実した正式なドキュメントが日本語版として公開されると思いますが、とりあえず概要だけでも紹介しておきたいと思います。 なお、このドキュメントかなり細かいです。通常のコンテンツではここまで気にしなくてもよいのでは、というくらい些細な違いも取り上げられています。今後、iPhone や Andoroid 携帯などリソースの限られたプラットフォームを扱う人は知ってた方がよいかもですが。 まず、メモリ管理関連のトピックからです。 Display Object 以下の 3
先日、開発環境構築の手順を公開しましたが、ローカルサーバとしての使い方とは別に、VMを立ち上げたり、最近PHP開発に使えそうか試しているeclipseを起動していたり、はたまた動画を見たりしてマシンを痛めつけているので、少し闘魂注入の意味でメモリ増設してあげる事にしました。 というか、このunibody MacBookを買った時は、対応するDDR3のメモリが2GBで7900円と微妙に高い状態で手が出なかったんですね。で、激安メモリで有名な上海問屋を除いてみたら最安の上海問屋セレクトが2GBで2980円とういところまで値下がっていたので、思い切って4GB買ってみました。 注文したのは昨日の早朝4時（寝落ちして起きた時）ボケボケしながらだったのですが、なんと今日届いちゃいました。つまり翌日配達ですよ。発送まで２〜３日、メール便にしたので届くまでさらに２〜３日と書いてあったので届くのは１週間後か
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
主にFlashのガベコレで脳が弛緩してる、ゆとりiPhoneプログラマ向けのメモリ管理術。しち面倒なRetainCountの管理を30秒で解決するよ。 1:とりあえず NSMutableDictionary を１個作る。このDictionaryはプロパティとして保持する。 2:alloc / init でインスタンスを作るときは、[[[ClassName alloc]init]autorelease] と必ずオートリリースをつける。 3:[NSString stringWith〜] のように、allocとinitを経ずにインスタンスを作る場合は、自分で勝手にretainをしない。 4:作成したインスタンスは持続的に必要な場合、NSMutableDictionary に突っ込む。 5:必要なくなったインスタンスは、NSMutableDictionary から remove する。 こうすると
↓ trace((2811-421)/(10000-1000)) //0.265555555555556 trace((2811-190)/(10000-100)) //0.264747474747475 trace((421-190)/(1000-100)) //0.256666666666667 1変数あたりのコストは、257Byte ～ 266Byte intのつもりでもデータ部分に 256Byte 変数名テーブル内に数Byteの割り当てな感じ。 先に書いた400個のMCだと、256Byte*400 = 100KB で推定できる。 ちなみに
最近、開発中のアプリを使っているとよく落ちるようになったので、静的解析ツールを試してみました。さくっと入るかなと思ったのですが、思いがけず色々はまったのでまとめておきます。 インストールから実行まで 1. LLVM/Clang Static Analyzerから最新版(checker-0.202.tar.bz2)を取得します。 2. 適当な場所に置いてパスを通します。 mv checker-0.202 /usr/local/checker export PATH=$PATH:/usr/local/checker3. 実行します。 cd iPhoneProjectDir scan-build --view xcodebuildと、ここでエラーがいくつかでました。 arm-apple-darwin9-gcc-4.0.1 arm-apple-darwin9-gcc-4.0.1がないというエラーが
サボっていた早朝ジョギング＠駒沢公園を再開して2週間たち、やっと抜かれる数より抜く数の方が増えてきたmikioです。今回は、PerlやRubyのハッシュの代用としてTokyo Cabinetを使うことでメモリ使用量を激減させられることを説明します。 抽象データベースAPI Tokyo Cabinetには抽象データベースという機構があり、先日、そのPerlとRubyのバインディングをリリースしました。それを使うと、各種言語のハッシュとほぼ同じような共通したインターフェイスで、以下のデータ構造を利用することができます。 オンメモリハッシュ：各種言語に標準のハッシュと同じく、メモリ上でkey/valueの関係を表現する。 オンメモリツリー：メモリ上の二分探索木としてkey/valueの関係を表現する。 ファイルハッシュ：いわゆるDBMとして、ファイル上でkey/valueの関係を表現する。 ファ
今日帰ってきたら先日トイコムで注文していたiMac用のメモリが届いていた。 Macを買う前までは2G×2のデュアルチャンネルで4Gのメモリを積もうと思っていたが、触ってみて標準搭載の1Gでもそれほど不自由しない程度の動作であったため増設は2Gだけすることにした。軽く調べてみたらデュアルチャンネルの効果なんて普通に使う分にはわからない程度らしいし、これなら標準搭載の1Gがそのまま使えるし、とりあえずは3Gでいくことにした。おそらくこれでもう増設することはないだろう。 で、早速増設作業を行った。 ネジは一本だけで一般的なプラスドライバーがあれば可能。軽くまわすだけであけることができた。 左側が標準で刺さっている1Gメモリ。で、今回は2Gを追加なので右側に刺す。 わりと力を入れて差し込まないとなかなか入らない。あとはふたを閉じてメモリの増設作業は完了。所要時間は約5分。びっくりす
Macのメモリ交換の方法 ［PR］ハードディスクのデータを復旧致します！（障害レベル2）データ復旧 1GB以内 Macのメモリ交換を説明してくれているサイトの方々 最近のMacの世界ではノートタイプやMac miniなどの小型のデスクトップが主流となってきている。 私もそうだが、初心者にとって、これらのMacのメモリの増設やハードディスクの交換は結構難関なのである。 中古などで買って何の説明もないiBookなどの場合はお手上げのこともある。 そんなわけで、写真つきでMacのメモリ交換を解説しているサイトをリンクしておく。 これを見る限り、最近のMacBookなどはかなりメモリ交換が簡単になっているようだ。 iBook G3 はじめてのiBook http://www.midokoro.net/ibook/memo
iPhoneやiPod touchでWebを見ていると次第に動作が重くなる事ありませんか？ これは空きのメモリ領域が少なくなっているので動作に必要なメモリが足りなくなっている事が原因の一つにあります。（上の画像の様に...） そんな時僕は空きのメモリ領域を作るのですが、メモリを解放する時「Memory Status」（App Storeにリンクしています）を使って強制的に解放するか、iPhone（iPod touch）を再起動させています。 ホームボタン長押しで強制的に終了させれば完全にプロセスを終了させる事が出来るのですが、この状態でiTunesと同期するとログファイルにクラッシュログが残ります。 ただ、このやり方だと面倒というか余計にiPhoneに負荷を掛けているというかバッテリーを無駄に食うというか... そこで偶然に発見した小ネタがあります。（後で調べたら既にやっている人が結構居ま
Firefoxはページのブラウジングを快適にするため、パソコンに搭載されているメモリを使いまくるという仕様になっています。ふつうの一般ピープルであればだからといってどうということもないのですが、Firefoxを好んで使う人のブラウジングスタイルだと異常なほどのメモリを消費し、もっさりしてきたり、快適さが損なわれてしまうように感じるのもまた事実。 なんとかならないものかとみんなあれこれ試行錯誤しているわけですが、そういう対策で一番お手軽で快適さが損なわれない方法を1つ、ピックアップしておきます。 なお、この対策方法はFirefox、Thunderbird、Mozillaで動作確認しています。 ■最小化したときにメモリ消費量を減らす メモリ消費量を抑える一番簡単な方法です。やり方もとっても簡単。 1. アドレスバーに「about:config」と入力してEnterキーを押す 2. 開いたページ
おっ。エラーが出なくなった。と。 いろいろ調べてみると [NSDate date]がautoreleaseされるインスタンスを 返していることが原因でした。 これにはobjective-cのメモリ管理方法の理解が必要なのでまとめます。 retainとrelease objective-cでは参照カウンタ方式というメモリ管理を行っています。 インスタンスの参照が増えるとカウンタが１、２、３、、、 と増えていき、参照が減るとカウンタ３、２、１、、、 と減り、参照カウンタが０になるとdeallocメソッドが呼ばれます。 参照が減るのは[obj release]のようにreleaseが呼ばれた時と、 [[[NSDate] init] ]autorelease]のようなautoreleaseされる インスタンスが自動でreleaseされた時。 autoreleaseされるインスタンスは基
まずは公式のObjectiveCのメモリ管理を読むべきである。（読まないと始まらない） http://developer.apple.com/jp/documentation/cocoa/Conceptual/ObjectiveC/4objc_runtime_overview/chapter_8_section_2.html そして、この辺が具体的なサンプルコードもあってよくまとまってる http://wwwa.dcns.ne.jp/~nito/CocoaClub/article01.html http://wwwa.dcns.ne.jp/~nito/CocoaClub/article02.html http://wwwa.dcns.ne.jp/~nito/CocoaClub/article03.html http://wwwa.dcns.ne.jp/~nito/CocoaClub/art
３つめのコードがちょっと違います。 でもって本題ですが、Objective-CにはretainCountって物があって、それが０になると解放されるみたいです。(未だに良く理解してない) そしてretainCountはalloc, init, retainなどで増えて、releaseで減るみたいです。 だいたい見つけた使い方等は以下の３つ。スーパーpreがおかしい...? HOGE *hoge = [[HOGE alloc] init]; /* . . . */ [hoge release]; HOGE *hoge = [[[HOGE alloc] init] autorelease]; NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; HOGE *hoge = [[HOGE alloc] init]; FOO *foo
お題は「あるプロセスがどの程度の物理メモリを利用したかを知りたい」です。 手っとりばやく知りたいときは top や ps などで調べると良いでしょうか。例えば手元の coLinux で top して M キーでソートすると emacs のプロセスが最もメモリを使っているようです。 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1923 naoya 18 0 23120 19m 3096 S 0.0 2.0 0:55.40 emacsメモリサイズは VIRT と RES がありますが、VIRT は Virtual の略で仮想メモリ領域のサイズ、RES が Resident の略で、実際に使用している物理メモリ領域のサイズ。19MB ほど使っているようです。この emacs のプロセスが利用するメモリ領域はざっくり 20MB 程度と
Track Memory Usage in Your Flex Application
Track Memory Usage in Your Flex Application July 18, 2008 in Flex | Tags: code, development A simple way to track memory usage in your Flex application is to create a Label that displays the System.totalMemory property and updates it on render events. This isn’t anything fancy, but it’s useful when checking for memory leaks and helps you avoid making mistakes when dealing with memory intensive app
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
