iPhoneアプリ開発時のメモリ管理で気をつけること(マルチスレッド編) - A Day In The Life
以前iPhoneアプリ開発時のメモリ管理で気をつけることという記事を書いたのですがマルチスレッド時のメモリ管理に関して全く触れてなかったのでまとめてみました。 NSAutoreleasePool はスレッドごとに作成する 処理を別スレッドで実行する場合、スレッドごとに NSAutoreleasePool が必要になります。NSAutoreleasePool の作成を忘れるとメモリリークします。 以下のように main 関数から Sample クラスのインスタンスを生成してメソッドを呼び出している場合、シングルスレッドの場合とマルチスレッドの場合で NSAutoreleasePool の作成タイミングが異なります。 @interface Sample { } - (void)hoge; - (void)foo; - (void)bar; - (void)baz; @end int main(
メモリ管理 - かみやんの技術者ブログ
iPhone開発で、メモリ管理の基礎を社員に伝えることが増えてきたので、エントリとして書こう。 Objective-C基礎 メモリ管理の前にObjCの基礎として、メソッド呼び出しの話。 クラスのインスタンスaがmethodAをコールするときは、 [a methodA] と書く。このとき、aがnilだったときは、エラーではなく、コールされない。methodAに戻り値があるときは、それは、0やnilやNOが返る。ObjCでは、 void dealloc { if(a!=nil){ [a release]; } [super dealloc]; } は、気持ち悪いので、nilチェックはやめましょう。 なお、ObjCでは、動的にメソッドを差し替えることができ、コールの度にメソッドが存在しているかも確認しています。そのため、LL言語(ライトウェイト言語、スクリプト）のように柔軟な記述が可能です。そし
iOS Viewライフサイクルまとめ、iOS6での変更点 – Zero4Racer PRO Developer's Blog
TwitterでViewライフサイクルについて話題になったので、まとめてみました。 @tomohisa @gaolay @replicantnexus6 @t_okada これまではiOS5では呼ばれてましたね。5ではwillUnloadっていう使いドコロのわからないメソッドも追加されてそれも呼ばれてましたし。 — kishikawa katsumiさん (@k_katsumi) 9月 20, 2012 シングルビューの動作 こちらが基本となります。よく勘違いされているのは、ViewDidUnloadは、いつもViewが閉じるときに呼ばれるというものですが、これは間違いで、通常、ViewDidUnloadは呼ばれません。 モーダルビューが呼ばれたとき モーダルビューが呼ばれたときの注意点は、裏にあるビューは、一度UIWindowから削除されて、ViewDidDisappearが走るという点
releaseの使いどころ : As Sloth As Possible
俺もメモリ管理を間違えて頻繁にアプリを落としてしまうゆとりプログラマなのであんまり偉そうなことも言えないのだけど、「releaseの使いどころ。メモリの辺りがどうしてもわからない。」を読んでいくつか思ったところがあるので書いときます。 「何度もinit」はしない 既に確保されているハズの変数を二度initするのはメモリリークだよね？ 解放されている変数は、 if (obj == nil) では判別できないのだろうか。 ボタン押下時などに、同じロジックを走ることが多くて、何度もinitをしてしまうことが多いのだが。。。。 具体的なコードを見てないので間違ってるかもだけど、多分これ「何度もinitしちゃう」じゃなくて「開放してないオブジェクトを参照してる変数に、何度も新しいオブジェクトをつっこんじゃう」ってことだと思って話を進める(そうすると、どこからも参照が辿れないのにメモリが開放されてない
[iPhone] UIWebView のリリース前に delegate に nil をセットする必要がある | Sun Limited Mt.
UIWebView のインスタンスに delegate を指定している場合は以下のように release する前に delegate に nil をセットする必要があります。 - (void) viewDidLoad { webView = [[UIWebView alloc] init]; webView.delegate = self; .... } - (void)dealloc { webView.delegate = nil; [webView release]; } アップルのマニュアルにも以下のように書かれています。 Important: Before releasing an instance of UIWebView for which you have set a delegate, you must first set its delegate property to
メモリ管理を理解する（前編）
メモリ管理を理解する（前編）：Cocoaの素、Objective-Cを知ろう（7）（1/2 ページ） iPhone用アプリケーション開発で注目を集める言語「Objective-C」。C++とは異なるC言語の拡張を目指したこの言語の基本を理解しよう（編集部） あらゆるアプリケーションは、システムのメモリ上に展開されて動作します。 メモリは限られた資源なので、アプリケーションは資源を無駄に消費しないよう自己管理しながら動作する必要があります。この動作を実現するのが、開発者によるメモリ管理の実装です。 新しく登場した言語のなかにはメモリ管理が自動で行われる（言語のエンジン部分で暗黙的にメモリ管理がされている）ものが多いため、開発者がメモリ管理を意識することが少なくなっています。 実際、Objective-Cでも、Objective-C 2.0から（Mac OS X 10.5 から）はガベージコレ
viva Cocoa / Objective-C 入門
Objective-Cの学習においてメモリ管理はひとつの壁であると言えます。そこでその対応策としてAppleはObjective-C 2.0においてガベージコレクションと呼ばれる「メモリ管理をプログラマが一切しなくて良い機能」を搭載しました。しかし残念なことにiPhoneアプリケーション開発用のObjective-Cではまだガベージコレクションが使えません。これはガベージコレクションがCPUのパワーをある程度必要とするからで携帯電話に搭載されているCPUには少し荷が重たいからです。しかし今後iPhone用アプリケーションの開発を考えておられる方は多いと思います。そこで本書では第12章までは基本的にガベージコレクションを使わずにiPhoneアプリケーション開発にも使える従来のメモリ管理方法のリファレンスカウンタ方式を使って学習を進めていきたいと思います。 なおリファレンスカウンタ方式からガベ
iOSアプリ開発のメモリ管理で気をつけること - A Day In The Life
Objective-C での開発にだいぶ慣れてきたのですが、いまだメモリ管理まわりでハマることが多いのでまとめてみました。 メモリを確保してから解放するまでの流れ メモリを確保してから解放するまでの流れは以下の図のようになります(図はアップルのサイトから引用)。 alloc または init すると参照カウントが1になります alloc または init 系メソッドを呼ぶと参照カウントが1になります。 このように書いたのは、クラスの仕様によって alloc メソッドで retainCount が1になるオブジェクトと init 系のメソッドで retainCount が1になるオブジェクトがあるためです。alloc と init はセットで呼ばれることがほとんどなのでこの違いが問題になることはないと思いますが念のため。 int main() { /* allocで参照カウント1 */ NS
iOS 開発で、EXC_BAD_ACCESS とさよならするための６つのルール – Zero4Racer PRO Developer's Blog
2012/3/22 いくつか修正、加筆しました。 追記もご覧下さい：iOS 開発で、EXC_BAD_ACCESS とさよならするための６つのルール [追記] カプセル化について « Zero4Racer PRO Developer’s Blog 対象がiOS4以上の場合は、ARCを使用するのもオススメです。iOS 5 公開記念！ Objective-Cのメモリ管理の革命、 ARC 超入門（サンプルはgitHubに公開） « Zero4Racer PRO Developer’s Blog をご覧下さい。 @Awaresoft さんのこの記事が、ほとんどすべての疑問に答えています。とてもよい記事なので合わせてご覧下さい。プロパティに対応するインスタンス変数の命名規則について – Awaresoft iOS プログラミングでのメモリ管理の基本 iPhone開発で主に使用される言語は、Object
【 iOS 開発 Tips】あなたも気付いていないかもしれないメモリリークの恐怖
こんにちは、共同開発部 iOS アプリ開発担当の図子です。 iOS 開発をしている皆さんはメモリリークのチェックを行っていると思います。どのような方法で確認していますか？おそらく以下のような方法で行っていると思います。 ・Static Analyzer を使う ・Instruments の Leaks テンプレート でも、これだけでは見つからないメモリリークが起こりうることをご存じでしょうか？ addSubview: で何枚もの View を貼っていないか？ 実際にメモリリークと呼べるかどうかは微妙かも知れませんが、開発者の意図しない不要なメモリがドンドン確保される可能性があるのでここではメモリリークと書かせていただきます。 非常に気付きにくいメモリリークとは view に addSubview: する際に起こりやすいのです。 以下のコードを見てください。ある UIViewControll
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
