問題タブ [instruments]

通常の使用では問題なく動作するように見えるアプリがあります。Clang Static Analyzer も問題を報告しません。Instruments で実行しようとすると、認識されないセレクタ例外で失敗します。

問題のある行は、次の形式の単純なプロパティ セッターです。

何が起こっているのかを把握するために、そのすぐ上に NSLog() 呼び出しを追加しました。

エミュレーター (Instruments なし) とデバイスでは、これはまさに私が期待するものを示しています。

クラス = Foo 応答 = 1

Instrumentsで実行すると、次のようになります。

クラス = Foo 応答 = 0

何がこれを引き起こす可能性があるのか​​ 、私は困惑しています。おそらく、Instruments 環境にあるときに、別のメモリ ロケーションが踏みにじられているのでしょうか? これをデバッグする方法を誰かが提案できますか?

Cocos2D-iphoneフレームワークを使用して開発しているiPhoneゲームを最適化しようとしています。

Sharkを使用してパフォーマンスを測定したいのですが、XCodeで「Run-> Start with Performance Tool-> Shark」が無効になっています（Instruments Leaksは正常に機能します）。「プロファイリングコードを生成する」ようにビルドを構成し、デバイスとシミュレーターの両方のビルドを試みましたが、運が悪かったため、sharkはまだ無効のままです。

また、Sharkを手動で（XCodeの外で）起動しようとしましたが、同様に効果がありませんでした。[サンプリング]->[ネットワーク/iPhoneサンプリング]で、[共有コンピューターのネットワークプロファイリングを制御する]ラジオボタンを選択し、リストされたデバイスの横にあるチェックボックスをオンにします。スタートを押しても何も起こりませんでした。

Sharkはデスクトップアプリで正常に機能します。Shark 4.7.0（244.4）とXCode3.1.3を使用しています。SDKver2.2.1でiphoneアプリをビルドしています。

Sharkを動作させるためにiPhoneにインストールする必要のあるアプリはありますか、それとも他に何か足りないものがありますか？

iPhone アプリケーションの起動後、メモリ リークが 3 回発生しました。アプリで何をしても、これらは一定のままです（リークはもうありません）。

私のネット オブジェクト割り当ては増え続けています。特に、GeneralBlock-24 と GeneralBlock-48 の 2 つのブロックがあります。

ブロック 48 は、プログラムが使用されているときに特に悪くなり、メガバイトのメモリを消費します。両方のブロックにオブジェクトを割り当てていると思われるライブラリは QuartzCore です。

アプリには QuartzCore フレームワークへの参照がありましたが、それへのすべての参照を削除しました。

ps: これはシミュレーターではなく、すべてデバイス上にあります

私はiPhoneアプリを開発していますが、これまでのところすべて正常に動作しています。シミュレーターでアプリをビルドして起動できます。しかし、Instruments を使用してアプリを起動すると、エラーが発生しました。

私はグーグルで検索しましたが、解決策が見つかりませんでした。

誰かが私を助けてくれることを願っています。どうも

iPhone アプリの Instruments でメモリ プロファイルを作成していて、左下にある [フル スクリーン] ボタンを押しました。画面が真っ暗になり、他に何もすることができません。ボックスの電源を入れ直すと、スプラッシュ スクリーンが表示された後、黒に戻ります。助けてください。

左下のボタンを示すドキュメントを次に示します。"全画面表示"

http://developer.apple.com/iphone/library/documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/ViewingandAnalyzingData/ViewingandAnalyzingData.html#//apple_ref/doc/uid/TP40004652-CH5-SW6

iPhoneアプリケーションでレンダリングできる1秒あたりの三角形の数を増やすために、OpenGL ESのパフォーマンスの最適化を実行しようとしていますが、壁にぶつかりました。OpenGL ESデータ型を固定小数点から浮動小数点に変換し（ Appleの推奨に従って）、頂点バッファーオブジェクトをインターリーブし、描画状態の変化を最小限に抑えようとしましたが、これらの変更によってレンダリング速度に違いはありませんでした。とにかく、3.0OSを実行しているiPhone3Gで、アプリケーションを320,000の三角形/秒より上にプッシュできないようです。このベンチマークによると、私が使用している滑らかなシェーディングで、このハードウェアで687,000の三角形/秒を打つことができるはずです。

私のテストでは、実行中のデバイスに対してInstrumentsでOpenGL ESパフォーマンスツールを実行すると、ベンチマークをレンダリングするときに統計「TilerUtilization」がほぼ100％に達するのがわかりますが、「RendererUtilization」は約30にしか達していません。 ％。これは、表示プロセスのボトルネックが何であるかについての手がかりを提供している可能性がありますが、これらの値が何を意味するのかわかりません。また、それらに関するドキュメントも見つかりませんでした。誰かがiPhoneOpenGLES機器のこれと他の統計が何を表すのかについての良い説明を持っていますか？iPhone3GのPowerVRMBXLiteがタイルベースの遅延レンダラーであることは知っていますが、そのアーキテクチャのレンダラーとタイラーの違いはわかりません。

何らかの形で役立つ場合は、このアプリケーションの（BSDライセンスの）ソースコードをダウンロードして自分でテストすることをお勧めします。現在の構成では、新しい分子構造をロードするたびに小さなベンチマークが開始され、三角形/秒がコンソールに出力されます。

私のアプリケーションでは、このメソッドはメモリ リークを示しています。リークを削除するにはどうすればよいですか?

この方法もリークを示しています...この方法の何が問題なのですか?

}

代替テキスト http://www.freeimagehosting.net/uploads/5b8120982c.png

電話帳のiPhoneアプリケーションでコードをクリーンアップしていますが、InstrumentsのリークツールからNSCFStringオブジェクトがリークしていると報告されています。これが私がフォローしているパターンです：

アプリケーションにPersonクラスがあり、ローカルNSStringメンバーと、名前、名前などの関連プロパティしかありません。

私のビューコントローラーには、searchBarSearchButtonClickedイベントでSQLiteデータベースから入力されるNSMutableArrayプロパティがあります。このNSMutableArrayには、テーブルビューコントロールに入力するために使用されるPersonオブジェクトが入力されます。また、ユーザーがビュー内の人物をクリックすると、その人物オブジェクトが詳細ビューに渡され、名前だけでなく追加情報が表示されます。

最初のルックアップを実行して結果を表示するとき、メモリリークはありません。

ここで、2回目のルックアップを実行するときに、理想的にはNSMutableArrayをクリアして、メモリリークなしで新しい結果セットをリロードしたいと思います。したがって、これを行うには、personListプロパティでremoveAllObjectsを呼び出してから、データベースを呼び出して、以下に示すようにpersonListNSMutableArrayを再設定します。

removeAllObjectを呼び出すことにより、Personオブジェクトに関連付けられていた以前のリークを取り除きました。ただし、現在、個々のPersonオブジェクトのプロパティから残っているNSStringオブジェクトをリークしているようです。

これは可能ですか？

私はInstrumentsツールを初めて使用しますが、NCSFStringリークの1つにドリルダウンしたときに拡張詳細からわかることは、スタック内のコードの最後の行が、プロパティの@synthesizeコード行を指していることが多いということです。なので：

したがって、これらのNSStringがクリーンアップされていないと思うのはそのためです。メモリリークを発生させない、これを行うためのより良い方法はありますか？

16バイトはかなり小さいですよね？アプリで作成した UIImage はどれもそれほど小さいものではありませんが、Leaks Instrument は 16 バイトのサイズのリークされた UIimage を報告しています...これが何であるかの手がかりはありますか? ちなみに、リークされた48バイトのCALayerオブジェクトもありました...