スキップしてメイン コンテンツに移動

Objective-Cのメモリー管理

最近はJavaをまずプログラム言語として始める人が多いだろうから、Objective-Cを使いだした際メモリー管理でつまずくことが多いだろう。わたし自身もすっかりJavaな人になっていたので同様に最初のころハマった。一応メモリー管理についてまとめておこう。

Objective-Cでは10.5からは今時の言語っぽくGabage Collectionが導入されので、Java同様あまりメモリー管理を気にする必要はなくなった。だが、パフォーマンスの問題からなのかXCodeのデフォルトの設定ではオフになっていたりするので、一応レガシィなメモリー管理のお手前も知っておこう。

リファレンスカウンタ、retain/release

さすがに大昔のC++のようにnew/deleteで自身で管理ということはなくて、リファレンスカウンタという割と一般的な手法でメモリー管理はなされている。これはある変数について参照が増えるたびにカウントアップ、参照がなくなるごとにカウントダウンしていき、参照カウンタがゼロになった時点でオブジェクトが削除されるという管理方法。Objective-Cの場合、この仕組みが言語でなくCocoaのライブラリレベルで実現されている。

リファレンスカウンタは生成時点で1に、その後 retainメッセージを送るごとに一つ増え、releaseするごとに減る。オブジェクトにretainCountというメッセージを送ると現在の参照カウンタを返してくれる。以下のようなコードでテストすると、


    ObjectA* objA = [[ObjectA alloc] init];
    ObjectA* obj_copy;
    NSMutableArray* array1 = [NSMutableArray array];
    printf("After initializing        : %i\n,[objA retainCount]);
    obj_copy = objA;
    printf("After assignment          : %i\n,[objA retainCount]);
    [objA retain];    printf("After retain              : %i\n,[objA retainCount]);
    [array1 addObject:objA]; 
   printf("After adding to array     : %i\n,[objA retainCount]);
    [array1 removeAllObjects];
    printf("After removing from array : %i\n,[objA retainCount]);
    [objA release]; 
   printf("After release             : %i\n,[objA retainCount]);

結果は、

    After initializing        : 1
    After assignment          : 1
    After retain              : 2
    After adding to array     : 3
    After removing from array : 2
    After release             : 1

となる。
生成した際にリファレンスカウンタは1になる。別の変数に代入した際にリファレンスカウンタを増やしたければ代入するだけではだめで明示的にretainをかけてやる必要がある。NSMutableArrayに加えたときリファレンスカウンタが増えるのはオブジェクトを集合に追加する際retainをかけてくれているから。Cocoaで提供されているコレクションフレームワークは内部でretainをかけており、removeする際releaseをかけているので注意が必要だ。

AutoreleasePool

しかし、こうやってすべてのオブジェクトを管理するのは面倒だというので、AutoRelasePoolという仕組みが用意されている。このプールにオブジェクトを登録しておけば、リファレンスカウンタに関係なくプールが存在する間はオブジェクトのインスタンスも保証され、Poolの削除とともにオブジェクトも破棄されるという仕組み。Cocoaのクラスはこの仕組みが前提になっているケースが多いので、Foundationのクラスを使うターミナルのプログラムでも以下のようなコードがメイン関数に追加されている。

    NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];    // User code    ObjectA* objA = [[[ObjectA alloc] init] autorelease];    .....    [pool drain];

このように プールを作成しオブジェクトにautoreleaseメッセージを投げることでプールに登録することができる。オブジェクトはプログラムでreleaseせずとも[pool drain]で破棄される。仕組み的には[pool drain]で登録されたオブジェクトに一斉にreleaseを投げているだけのようだ。逆に言うとプールに登録したオブジェクトといえど、リファレンスカウンタで制御されていてretain/releaseの回数のつじつまはあっていなければならない。「リファレンスカウンタに関係なく」と書いたが、実際にはプールに登録したオブジェクトに関しては「プログラム上でリファレンスカウンタに関係してはならない」が正解か。

また、NSAutoreleasePoolは複数生成することができる。


    NSAutoreleasePool* pool1 = [[NSAutoreleasePool alloc] init];
    printf("Pool1 is created\n");
    ObjectA objA = [[ObjectA alloc] initWithString:@"objA"];
    [objA autorelease];    printf("Pool2 is created\n"); 
   NSAutoreleasePool* pool2 = [[NSAutoreleasePool alloc] init];
    ObjectA objB = [[ObjectA alloc] initWithString:@"objB"];
    [objB autorelease];    printf("Pool2 is drained\n");
    [pool2 drain];    printf("Pool1 is drained\n"); 
   [pool1 drain];

結果は

    Pool1 is created.    Pool2 is created.    Pool2 is drained.    objB is released.    Pool1 is drained.    objA is released.

つまりオブジェクトは直近に生成されたプールにより制御される。一つのプールに依存すると、プログラムが終了するまで多量のインスタンスを抱えることになりかねない。多くのメモリーを消費するクラスや多量のインスタンスを生成する処理では、対象のインスタンスを使用するスコープでNSAutoreleasePoolを生成し不要となったら破棄するのがベター。

Objecitve-Cにおけるretain/release/autoreleaseの方針

実は、このAutoreleasePoolがあるので最初にObjective-Cを書こうと思ったときこのメモリー管理で訳が分からなくなる。上記は簡単な例で説明したが、通常はオブジェクトはインスタンス変数に別のオブジェクトの参照を持っておりそれぞれのライフサイクルが異なっているのは普通で、しかもそれぞれ自身でretain/releaseをかけていたり、AutoreleasePoolで管理されていたりと管理方法もバラバラになってしまう。で、結局retain/releaseのバランスが崩れて、二重解放してしまったり解放されないオブジェクトができたりする。

いくつかの実験とWebサイトなどの情報をまとめると、以下のような方針がよいようだ。

  1. 自身が生成したオブジェクトは自分で解放する。つまり、alloc-initでオブジェクトを生成したメソッド、またはクラスは自身の責任はreleaseをかけるか、生成時にautoreleaseを投げておく。
  2. CocoaのFrameworkでは、クラス名が先頭についた生成メソッドはautoreleaseがかかっている。例えば、NSArrayにおける+arrayWithObjectsや、NSStringにおける+stringWithCStringなど。これらについては、積極的にこれらの生成メソッドを使用しalloc - init***で生成しない。
  3. 同様に自作のクラスについては、CocoaのFrameworkに習いなるべく+クラス名の生成メソッドを用意しその中でautoreleaseをかけるなどして、自身のオブジェクトのライフサイクルに関しては自身で責任を取る。
  4. インスタンス変数については、そのオブジェクトの由来に関わらずretainをかけ、deallocの中でreleaseを入れる。こうすれば、例えばAutoreleasePoolに登録されているオブジェクトでも辻褄は合う。
  5. 局所的に多量のインスタンスを生成する場合(特にループ内など)は、全体のNSAutoreleasePoolの制御に任せるとメモリーをどんどん消費していくので、大量の一時的インスタンスを生成するようなメソッドやループ内ではローカルのNSAutoreleaseaPoolを適用する。

 

コメント

このブログの人気の投稿

W-ZERO3 カスタマイズ関連

Advanced/W-ZERO3[es]のカスタマイズのメモ。 いろいろインストールしているうちに何をどこから持ってきたのかわからなくなりそうなので、メモを残しておく。 ctrlwapmini テンキー関連の文字入力方式を改善するソフト。 キーマップの作成で携帯電話風の入力方式を利用できたりする。わたしはAuのカシオ系に慣れてしまったので、 w42ca風のキーマップ を拾ってきて利用している。 入手先: http://hp.vector.co.jp/authors/VA004474/wince/wince.html gsgetfile.dll 標準のファイル選択ダイアログを置換するDLL。 My Documents以外のフォルダにアクセスするために作成されたものらしい。いろんなソフトで前提になっているので、とりあえず導入しておく。 入手先: http://www.geocities.co.jp/SiliconValley-Cupertino/2039/ Multi Key Hook 標準では一つしか使えないキーフックを複数のアプリに割当で着るようにするソフト。 入手先をダウンロードし、Windowsフォルダにぶち込んでおく。 入手先: http://geocities.yahoo.co.jp/gl/hou ming 2/view/20070906/1189012118 DefaultMailer advanced/W-ZERO3[es]には、W-ZERO3メールとOutlookメールが入っているが標準MUAをどちらにするか切り替えるソフト。 標準ではOutlookとなっているが実際にはW-ZERO3メールを使うことの方が多いので、todayCompactなどから起動する際、このソフトを利用してW-ZERO3メールが起動するように調整。 入手先: Andante:DefaultMailer version 0.1.0.0リリース KeyLockSuspender 側面のキーロックスイッチの動作をカスタマイズできるソフト。 これでキーロックに連動して、画面のオンオフ、サスペンドなどを強制的に行いバッテリーの不要な消耗を防ぐ。 入手先からダウンロードして適当なフォルダに展開したら、ショートカットを作成してスタートアップに入れておく。 入手先: KeyLockSuspend...

スターシップ・トゥルーパーズ

『スターシップ・トゥルーパーズ』を見る。 1997年の作品で15年近く昔の映画だからか? いや、制作にかかわってるフィル・ティペットが関わった『ジェラシック・パーク』は1993年のはずだ。原作がヘボなのか? いや、原作はハイラインの『宇宙の戦士』のはずだ、あれは昔、俺も読んだぞ…… なんだろう? このやるせなさは。 CGもそんなに古さを感じさせないし、ストーリーもまぁ設定がベタなところはあるが構想はでかい。うーん 問題なのは脚本と演出と演技か。見てる印象は、アホで安直なアメリカンな80年代以前の古くさいSF映画だ。それがもしかしたら狙った演出なのかと思う節もあるが、狙いも分からん。質のいい大阪漫才を観たあとで、くそ下手なボケにラフトラック無理矢理入れたシットコムを見せられた気分だ。 たとえば、こんな具合…… 宇宙戦艦に巨大アステロイドが急接近。未来の宇宙戦艦がそんな急接近されるまで気付かず、パイロットが目視で発見というところは許そう。今にも衝突しそうで警報がバンバン鳴っている中、回避操作に取り掛かったヒロインのセリフが「緊急回避、3、2、1、ゴー!」…… 数えてないで、早くハンドル切ってよ。 揚げ句の艦橋上部がへし折れて宇宙の大海原で通信機能が失われおそらく何名か亡くなっているのに、館長のセリフが「助かったわ、パイロットのおかげよ、ナイスジョブ」…… いや、あの3秒がなければ無傷だったと思うよ、戦艦も。 このヒロインは常にこんな調子。 戦艦が爆発しかけて脱出ボートも次々の火に巻き込まれていくなか、脱出ボートに乗り込んで礼儀正しくヘルメットして「用意はいい、いくわよ」、「ガァーーーーーーーーーーーーーーー(キャノピーを閉める音)」「発射!」…… 早く逃げろよ、イライラする。 まぁ、こういう楽しみ方をするならお勧めです。 敵が「虫」なのだが、地上から攻撃出来る対宇宙戦艦の屁をこく虫がいるとか、相手が虫なのに死んでもいない主人公を死んだことにして諜報戦でもやってるつもりの歩兵隊とか…… スターシップ・トゥルーパーズ [DVD] posted with ama...

iOS5に上げたらやっておくべきこと

忘備録。 今さらながら、iOS5にバージョンアップしたときにやっておくべきことを書き出しておこう。わたし自身はiPhone4持ちですが、3Sでも結構動いている模様なので、参考にどうぞ。 通知関連 iOS5になって通知機能が充実してMobile機器としてさらに使いやすくなったが、反面バッテリーを食う原因ともなっているようだ。不用なアプリの通知については個別にオフに設定したほうがよいだろう。 また、「緊急地震速報」はバージョンアップした場合はデフォルトではオフになっています。但し書きに「設定をオンにした場合バッテリーも持ち時間が短くなる場合があります」と書かれている。今沖縄住まいなのでとりあえずオフのままにしておこう。 位置情報サービス 先日報告されたiPhone 4Sのバッテリー異常消費の原因とも見なされている機能だが、ネットではこのシステムサービスの設定が原因とささやかれていたものだ。まずはアプリの一覧が表示されているが、位置情報が不用と思われるアプリについてはセキュリティの観点からもオフにしておきましょう。 さて、一番下にある「システムサービス」だが、コンパスの調整以外はすべてオフでよいと思われる。ちなみに「位置情報に基づくiAd」は無料アプリに表示される広告に位置情報が加味されるサービス。「携帯電話通信網検索」はキャリアは固定だろうからあまり意味がない。「時間帯の設定」は海外旅行に頻繁に行く人しか意味がない。「渋滞状況」は日本ではサービスが始まっていない。 「システムサービス」の「診断/使用状況」はAppleに自動送信されている情報に位置情報を含めるための設定。Appleには悪けれど、そうでなくてもAppleにたくさんお布施をしている我が身なればさらに通信費まで負担して貢献する気持ちにはなれない。よって、「診断/使用情報」を送る設定自体をオフにしちゃいましょう。変更は「設定」> 「情報」> 「診断/使用状況」 で「送信しない」を選択すればよい。 Spotlight検索 インデックス構築にバッテリーが消費されるらしいので不用なものはチェックを外そう。「設定」>「一般」>「Spotlight検索」で。わたし自身ほとんど利用しないので全部外してしまった。 キーボード設定 不用なキーボードをオフっておくのはこれまで通りだが、今回日本語に入力でこれまでの「かな入力」の他に...