サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
instrumentsのプロファイラなどを使ってCall Treeを表示しても、メソッド名が表示されなくてどのメソッドで時間がかかっているのかわからん・・・という場合。 以下手順でメソッド名を表示出来る。 ・instrumentsをStop ・メニューのFile>Re-Symbolicate Document...を選択 ・デバッグ中のバイナリを選択 ・LocateボタンをクリックしてdSYMファイルを選択 ・Symbolicateをクリック これ自動でできないのかな。。 参考：debug symbols - Xcode 4 Instruments doesn't show sourcelines - Stack Overflow
I don’t remember where I first saw this mentioned so I cannot give propercredit but this is an interesting tip to try if you have five minutes. Open SourceBuilds of the Clang Analyzer The Clang Static Analyzer has long been integrated with Xcode and provides powerful source code analysis to detect bugs in C,C++ and Objective-C code. The analyzer is fully open source and part of the larger Clang
Xcode 5から導入された、デバッグ時の Quick Look機能、デバッグ時にオブジェクトの情報をグラフィカルに見ることができてとっても便利ですよね。 Xcode 5.1からは、システムクラスに加えて、カスタムクラスのQuick Look機能も使えるようになっているので、さっそく使ってみました。 普通の Quick Look 普通のってなんだよって感じですが、いわゆる、組み込みのシステムクラスのQuick Look。 何も特別な設定をしなくても使えるQuick Lookです。 使い方は簡単。 オブジェクトの上にマウスオーバーすると、ツールチップのような小さいダイアログが表示されます。 そのツールチップの上の、「目」のように見えるアイコンをクリックします。 すると、こんな感じでオブジェクトの中身がグラフィカルに見れるようになります。 なお、iOSのシステムクラスで Quick Lookに
NSDictionaryやNSArrayのdescriptionはそれとなく見やすいフォーマットで出力されますが、JSONで欲しくなる場合があります。 しかも、デバッグ中に欲しくなったりします。 XcodeのLLDBは~/.lldbinit-Xcodeに独自のコマンドを定義することができるので、 pretty printedなJSONを吐くコマンドを定義してカジュアルにJSONを得られるようにしてみました。 1 command regex pj 's/^(.+)$/po [[NSString alloc] initWithData:[NSJSONSerialization dataWithJSONObject:%1 options:1error:nil] encoding:4]/' ここで定義したpjコマンドを使うと以下のようなNSDictionaryから 1 2 3 NSDiction
原因がよくわからないのですが、iOSアプリをデバッグ中にNSExceptionが発生してアプリがクラッシュしてしまった時、その詳細がXcodeのコンソール上に表示されなくなってしまいました。普通はデフォルトのexception handlerがうまい具合にやってくれるのですが、何らかの理由でそれがうまくいかない場合があるようです。自分でスレッド立ててるとかでしょうか・・・ 上図のように、例外が発生している箇所にブレークポイントをおいてどこで発生したのかを知ることはできるのですが、実際には発生箇所がわかっても発生原因がさっぱりわからないというケースもあります。例えばiOSのシステムが例外を発生させたときや、コードが公開されていないライブラリが例外を発生させたときなどです。 さて、このようなときは発生しているNSExceptionのdescriptionを直接読めれば便利そうです。というわけで
iOS 7とともに登場したXcode 5ではデバッグ機能が強化がされています。 今回は新たに追加された"Debug gauges"という機能を試してみます。 Debug gaugesとは プログラムの実行がエラーなどで中断した場合や、意図的にプログラムを一時停止させた場合に、「デバッグナビゲータ」にその時点でのプログラム実行の履歴が表示されますが、Xcode 5からはデバッグナビゲータにCPU、メモリなどのリソースの消費状況も表示されるようになりました。 実機の場合、iOS 7が動作するデバイスでのみ表示されます(iOSシミュレータは未確認)。 実際に使ってみた。 iOS 7が動作する端末で実際に試してみます。MapViewの表示であればCPUやメモリに負荷がかかりそうだと思ったので、単にMapViewを表示するサンプルアプリを作って動かしてみました。MapView表示時 デバッグナビ
![[Xcode 5] Xcode 5のデバッグ機能 “Debug gauges” | DevelopersIO](/image.pl?url=https%3a%2f%2fcdn-ak-scissors.b.st-hatena.com%2fimage%2fsquare%2fd6d42bb8eb763a9d4914eebb951bc5e3e7718d03%2fheight%3d288%3bversion%3d1%3bwidth%3d512%2fhttps%253A%252F%252Fdevio2023-media.developers.io%252Fwp-content%252Fuploads%252F2013%252F09%252Fios7_logo_xcode5.png&f=jpg&w=240){kind=logo}
入門編と初級編の差は何かと申し上げますと、それはただの気分だとしか説明しようがないわけですが、そのあたりについては、さらっとスルーしていただきまして。 以下三つほど書いてきました。 iOS向け Xcode開発Tips初級編 -とりあえず最初にやってること- iOS向け Xcode開発Tips初級編その2 -ちょっと便利なショートカットキー8つ- 【iOS】 Xcode開発Tips入門編その3 -NSLogあれこれ3つほど- で、今回はブレークポイントを。 ある程度ご存知の方もいらっしゃるかと思いますので目次を 目次 1.ブレークポイントの追加及び削除もろもろ 2.ブレークポイントで停止してから変数を編集 3.Step Over / Step into / Step out もろもろ 4 ブレークポイントの編集 - 条件指定 - 5 ブレークポイントの編集 - オプション - 6 ブレークポ
前回は、例外の発生した場所を特定する方法として、「NSSetUncaughtExceptionHandler」を使った方法を紹介しました。 今回は、Xcodeの機能の「ExceptionBreakpoint」を使用して、例外の発生した場所を特定してみます。 （前回のブログで頂いたコメントを参考にしました。ありがとうございました。） 環境は、Xcode 4.5 を使用します。 例外を発生させる処理は前回と同じなので省略します。 以下、手順です。 ①Breakpointアイコンのボタンをクリックして、「Breakpoint Navigator」を開きます。（ショートカットは、「⌘」+「6」） ② 「+」ボタンをクリックします。 ③ 「Add ExceptionBreakpoint...」をクリックします。 ④ 「Done」ボタンをクリックします。 設定はこれで終わりです。 では、実行して
Unrecognized Selectorのようにどこのメソッドが実行された際に発生したか判り難いエラーの場合、以下のシンボリック・ブレークポイントを作ってやることで、直接的にどこでエラーが発生したかが分かり易くなる。 -[NSObject doesNotRecognizeSelector:]NSObject-doesNotRecognizeSelector:メソッドはランタイムにレシーバであるオブジェクトが応答出来ないメッセージを受信した時にこのメソッドを呼び出すので、このシンボルに対してブレークポイントを設定することで同エラーを検出できる訳だ。。 追加の仕方は、ブレークポイントナビゲータ(cmd + 6)の左下の+ボタンから"Add SymbolicBreakpoint"を選択して、その後ダイアログにシンボルを入力すれば良い。(ライブラリィやブレークした場合のアクションも指定できるが
Xcode4.2 エラー画面 Xcode4になってから、いまいちデバッグがうまくいかない理由に、止まってしまう場所が、 returnUIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class])); の行で止まってしまう場合が多いのがありますよね。この時に、どこで止まったのか分かるときはいいですが、いろいろな画面の中でどこで止まったか分からないときはデバッグ困りますよね。その対策法を見つけたので書いておきます。 試しに、エラーが起こるプロジェクトを作ってみました。 - (void)viewDidLoad { NSMutableArray *arrray = [NSMutableArray arrayWithCapacity:0]; [arrray objectAtIndex:10]; [super vie
iOSの開発を行う上でメモリリークが非常に気になるところです。 Objective-Cの参照カウンタの仕掛けでいづれは開放されるとしてもdeallocが走るタイミングは検知しておきたいものです。 Xcodeには便利なbreakpointの機能が用意してあり、deallocの確認にオススメしたいのはサウンドアクションの設定です。（※Xcode4で説明しています）breakpointを右クリックし「editbreakpoint」を選択します。 Actionを「Sound」に設定し、音の種類を選びます。 ソースの実行を途中で止めたくない場合はOptionsにチェックを入れておきます。 （※音がなるだけでストップしない） 絶対にリークさせたくないオブジェクトなどに適宜設定しておくとよいです。 音の種類も１０種類以上あるので使い分けも行えると思います。
What do you do if your app doesn’t behave asit should, or even crashes? Answer A: Post your problem injust about everyprogramming forum. Answer B: Use the Xcode Debugger to analyze what’sgoing wrong. Since most of you already know how to do A I’ll focus on B in this Xcode 4 Debugging Crash-Course.It’s kind ofaimed at beginning Xcode developers but that’sjust because I hope - against better
1リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Debugging in XCode 4.x
