タグ

関連タグで絞り込む (1)

タグの絞り込みを解除

最適化とObjective-Cに関するfakestar0826のブックマーク (6)

  • パフォーマンスチューニングに関するアップルのドキュメント - その後のその後

    アップルの『 iOSアプリケーションプログラミングガイド(英語版)』に、『パフォーマンスと応答性のチューニング』という章があって、これが今読むとかなり参考になったので、引用します。 個人的には、「リソースをあらかじめロードしておくと高速化になりそうだけど、メモリの無駄遣いになって結果的に遅くなるので絶対にやるな」というのが一番ささりました。 画像ファイルはUIImage化しておくと使うときに速そうだなーとか考えてたところだったので。 他にも個人的にためになった部分を太字にしてあります。 メインスレッドを妨害しない アプリケーションのメインスレッド上で実行する処理のタイプを必ず制限します。メインスレッドは、アプリケーションがタッチイベントやその他のユーザ入力を処理する場所です。 アプリケーションが常にユーザに応答することを保証するには、時間のかかるタスクの実行や際限なく続く可能性のあるタスク

    パフォーマンスチューニングに関するアップルのドキュメント - その後のその後
  • そうだ、プログラミングしよう  メモリ使用量をログに出す

    Objective-CやCocoa touchのTIPSを書いていきます。目的はiOSアプリ開発です。 自分のアプリはiPhone/iPadでどれくらいのメモリを使っているのか調べたい。 Allocations を使えばメモリ使用量を調べることはできる。 ここでは、NSLogを使ってメモリ使用量を表示してみる。 #import <mach/mach.h> // これを import するのを忘れずに @interface MemoryInfo : NSObject { } + (struct task_basic_info)used; @end @implementationMemoryInfo + (struct task_basic_info)used{ struct task_basic_info basicInfo; mach_msg_type_number_t basicInfo

  • アプリのメモリ使用量をリアルタイムに表示するクラスを公開しました - Over&Out その後

    なるべくUIViewを使わず描画するとか、nibを使わないとか、iOSアプリの動作を軽快にするためのTipsは数あれど、実際どれぐらい効果あるんだろう、ってことを調べたい、でもInstrumentsはめんどくさい、ってことでメモリ消費量やUIViewの数など、「負荷を示すパラメータ」をリアルタイム表示するクラスを作りました。 (イメージとしてはAS3でいうところのStats) 同梱のサンプルコードを実行すると、こんな感じで表示されます。(左上の黒いラベルがStats) パラメータ内訳は後述しますが、メモリを約16MB使用し、ビューが合計5つ(UIView、UIButton、UIButton上のUILabel、UIImageView、Stats)になっていることがわかります。 また、draw imageボタンを連打するとCPU負荷の値が若干上がることも確認できます。 ※シミュレータでの実行結

    アプリのメモリ使用量をリアルタイムに表示するクラスを公開しました - Over&Out その後
  • 【iPhone】メモリ不足時のシミュレートとデバッグ | iphoneアプリで稼げるのか

    iPachiで起きていた不具合なのですが、 特定の画面を表示中にメモリ不足に陥り didReceiveMemoryWarningを受け取ると アプリがクラッシュするという問題をついに 解消しました。 didReceiveMemoryWarning後にクラッシュするので メモリ管理でどこかがおかしくなっているのだろうとは 予想がつくのですが、いかんせん貧弱なエラーメッセージの ため、まったく発生元がつかめませんでした。 EXC_BAD_ACCESSとか言われてもさっぱりわからんです。 が、すばらしい記事をみつけました。 NSDebugEnabled これでクラッシュをおこしているオブジェクトの生成場所を 特定できるので、格段にデバッグ効率があがります。 というわけで、エミュレータでのメモリ不足時のシミュレートと デバッグのための設定をまとめます。 エミュレータでのメモリ

  • iPhoneアプリケーション開発: Objective-Cにおけるメモリ管理

    メモリ管理の大まかな原則 C言語と共通の部分について、メモリ管理で気をつけることは特にありません。Cで気をつけることと共通です。 自分がmalloc()で確保したメモリは忘れずfree()で開放しましょうということだけです。従って、多くの場合に問題になるのはObjective-C固有の部分です。 Objective-Cのオブジェクトはretain countというものを持っています。生成すると0から1になります。 そのオブジェクトに関連付けられている変数名でretainをすれば、カウントが1増えます。 releaseをするとカウントが1減ります。run loopと呼ばれるシステムへの応答処理へ入った時、 このカウントが0になっているものはメモリ上から消えるようになっています。 autoreleaseとした場合には、適当と思われる部分で自動的に開放されるので、自分でreleaseを行う必要は

  • リファクタリング講座メモ - その後のその後

    5/29にRainbowApps卒業生の方が主催された合宿に参加した際、そこでバスケさんが話されていた「公開リファクタリング講座」が非常にためになる内容だったので、そのときのメモを公開しておきます。 メモリまわりのデバッグ/リファクタリング leaksが有名なのでそればかり使いがちだが、memory allocationやzombiesでも見てみること live bytesが使用中のメモリ量 1.5Mぐらいなら画像使用してるアプリなら多くない 13Mになると、初代ipadなら落ちる可能性ある live bytesでソートすると、今一番メモリくってるオブジェクトタイプがわかる breakpointを右クリックでエディットできる アクションの設定・・・10回通った後で止まる、とか。 バンドルからplistを読み込む動作は重い(一時オブジェクトが生成されるのでメモリ空間も汚れる)ので基的には1

    リファクタリング講座メモ - その後のその後
  • 1