タグ

debugとxcodeに関するy-kobayashiのブックマーク (17)

  • Custom Instrumentsのインストール方法 - Qiita

    iPhoneターゲットでArchive Built Productsでexport *.instrdst をダブルクリックしてインストール 以下、共通で使う *.tracetemplate を作成する方法 (すでにある場合は不要) Instrumentsを開き、最初はBlankを選択 右上のプルダウンにインストールしたpackageがある 必要なものと合わせてtraceviewに追加する。 File => Save as Template 保存したTemplateをダブルクリックでいつでも上記で選択した設定でProfileが開始できる repositoryにコミットするのがオススメ *.instrpkg *.tracetemplate チームで共有できる。各メンバーごとに上記packageのインストールは必要そう。 *.instrdst (archive&exportした成果物) をコミッ

    Custom Instrumentsのインストール方法 - Qiita
  • AbemaTV iOSチームのエンジニアが教える、Signpostを用いたプロファイリング

    2018年12月12日、株式会社サイバーエージェントにて「CA.swift」の 第7回が開催されました。AbemaTVやAmeba、AWAなどを担当しているiOSエンジニアが登壇し、それぞれのチームの開発ノウハウを惜しみなく語るイベント。今回は、『iOSアプリ設計パターン入門』の著者2名を含む5人のエンジニアが、iOS開発における知見を披露します。プレゼンテーション「Profiling using signpost」に登壇したのは、株式会社AbemaTVの鈴木俊裕氏。講演資料はこちら Siginpostを用いたプロファイリング 鈴木俊裕氏:「Profiling using signpost」というタイトルで発表します。 AbemaTVでiOSチームと、Streaming Clientっていう動画ドメインに特化したチームに所属しています。チームでは「トッシー」とか呼ばれてるんで、適当に呼んで

    AbemaTV iOSチームのエンジニアが教える、Signpostを用いたプロファイリング
  • Xcode + LLDBで再ビルドなしにデバッグする - Qiita

    概要 TwitterのタイムラインでLLDBの話を見かけた時にこんなことを書きました。 LLDBといえば今年のWWDCでAppleのXcodeエンジニアリングマネージャによるこのLLDBデバッグ芸がめちゃくちゃ盛り上がってました。Xcode+LLDBを駆使したデバッグの凄さをわかりやすく伝えていて面白いので、printデバッグで十分でしょ?っていう人に見せるとよいかもw #swtwshttps://t.co/LtbIWmr52e — kazuhiro4949 (@kazuhiro494949) 2018年7月14日 こちらのセッションになるのですが、特に「話がうまいなー」と感じたのは前半部分です。 Advanced Debugging with Xcode and LLDB ポイントは「Xcode + LLDBはちゃんと使えば再ビルドなしにアプリを書き換えながらデバッグできるよ」っていう所

    Xcode + LLDBで再ビルドなしにデバッグする - Qiita
  • XCodeのビルド時間を算出する - Qiita

    ビルドの時間の算出にはBuildTimeAnalyzerというmacのアプリを使います。 導入後このアプリを立ち上げたままいつも通りアプリをビルドだけでビルド時間が出力される便利なツールでリファクラリングに一役買ってくれます。 ツールの取得 まずは下記のGitHubからcloneもしくはzipファイルをダウンロードします。 GitHub 設定 取得してきたファイルを開くとpopupで手順を示してくれます。 が、ちょっと英語難しかったのでこちらで紹介します。 ビルド時間を算出したいアプリを立ち上げ、 TARGETのBuild SettingsからOther Swift Flagsという項目を探しだし、 Debugの欄に下記テキストを追加します。 設定後一度クリーンしてからアプリをビルドしてください。 BuildTimeAnalyzerが立ち上がり、 メソッドごと、ファイルごとのビルド時間が出

    XCodeのビルド時間を算出する - Qiita
  • libimobiledevice · A cross-platform FOSS library written in C to communicate with iOS devices natively.

    A cross-platform FOSS library written in C to communicate with iOS devices natively. ... and a bunch of libraries and command-line utilities. Get Started Native Protocols The library implements the native protocols needed to communicate with services running on iOS devices. Due to the reimplemention it does not depend on using or bundling any existing libraries from Apple. Cross-Platform The C pro

    libimobiledevice · A cross-platform FOSS library written in C to communicate with iOS devices natively.
  • iPhoneの実機ログを確認する方法 - Qiita

    通常アプリのログを確認するときにはXcodeのデバッグモードでログ出力を行いますが、AdHoc版であったり、リリース版でもログを確認したいときがあります。 そういう時のログ出力をして確認する方法を紹介したいと思います。 Xcodeのログ出力機能を使用する まず、iPhoneMacに接続します。 そして、Xcodeを起動して、Devices画面(ツールバー・Window > Devices)を表示します。 Devicesの画面下部のところにあるこのボタンをタップします。 すると、ログがこのように出力されます。 NSLogで出力されるログはもちろんですが、それ以外にもシステムメッセージなども表示されます。 アプリのエラーなどを確認するときにはアプリのBundle IDで検索すれば、該当のアプリのメッセージを抽出できるかと思います。 ログ出力アプリ「iOS Console」を使う Xcodeを

    iPhoneの実機ログを確認する方法 - Qiita
  • Xcode8のDebug Memory Graphでメモリリークをビジュアル化 - Qiita

    概要 Xcode8から追加された「Debug Memory Graph」機能を用いてメモリリークをビジュアル化してみました。 想定したケース 一覧画面・詳細画面の2画面構成 詳細画面でAPI呼び出しを行う API呼び出しクラスが呼び出し元のViewControllerのあるメソッドを呼ぶ設計になっている 詳細画面のViewControllerクラスと、API呼び出しクラスが強参照で相互参照している プログラム作成 メモリリークが発生するプログラムを作成します。 Storyboard 一覧画面・詳細画面の2画面を作成しています。 一覧画面 一覧画面は単純にTableViewで1行セルを表示し、セルをタップすると詳細画面に遷移するだけです。 遷移はStoryboard上でSegueを利用しています。 (例なので、値・Identifierは固定とし、force unwrapして表示させています。

    Xcode8のDebug Memory Graphでメモリリークをビジュアル化 - Qiita
  • Load the Reveal Server via an Xcode Breakpoint / Getting Started / Knowledge Base - Reveal Support

  • ZombieObjectとは何か - Qiita

    Effective Objective-C 2.0の中に、ZombieObjectの事が書いてあり面白かったので、自分なりにまとめてみました。 ZombieObjectの話の前に、解放されたオブジェクトにアクセスするとどうなるのか?の話をします。 解放されたオブジェクトにアクセスするとどうなるのか? 使い終わり解放されたオブジェクトにアクセスすると、普通はクラッシュします。ARCの登場以前は、呼吸をするようにクラッシュしてましたが、ARC以後はその頻度も減りました。でもまだクラッシュするときはします。ニンゲンダモノ。シカタガナイネ。 このとき、「偶然にもクラッシュしない」場合が発生します。これは、オブジェクトを解放後、そのアドレスでアクセスした場合に、ゴミデータにアクセスできてしまったり、別オブジェクトがそこに割り当てられていたりなど、いろいろな原因があり得ます。 ↑の例では、_assig

    ZombieObjectとは何か - Qiita
  • Xcode で快適なデバッグライフを追い求める

    iOSDC https://iosdc.jp/2016/c/node/116 僕は怠惰な人間です。プログラミングの大半はデバッグに時間を費やすと思っているので、なるべく早く原因に辿りついたり効率のよいデバッグライフを送りたいと常々思っています。 プリントデバッグもいいのですが Xcode には便…

    Xcode で快適なデバッグライフを追い求める
  • XcodeのBreakPointで式の評価値を確認してデバッグに革命を起こす! - Qiita

    Xcodeでの開発中、BreakPointでとりあえず処理を止めてみたはいいけど、 見たい値が見れずにもどかしい経験をしたことはなかろうか? わざわざ評価したい式を使いもしないのに変数に入れて確認したり、printしたり…。 でももうそんな日々とはおさらば!そう、この方法を使えばね。 方法 とりあえず適当にBreakPointを仕込んでみる。 そして Debug Area でメニューを開き、Add Expressionを選択。 式を入力してDoneを押すと… 今まで見られなかったviewのframeのパラメータが!見える!見えるぞ!! 補足 関数や演算子も使える。 値を変更するような式を入れてしまうと、当に値が変わってしまうので注意。 BreakPointを外しても入力した式を覚えていてくれるので、再度BreakPointを設定すると復活できる。

    XcodeのBreakPointで式の評価値を確認してデバッグに革命を起こす! - Qiita
  • 【iOS】 Xcode開発Tips初級編 -ブレークポイント(BreakPoint)あれこれ8つほど- - @kitano_ow 's blog

    入門編と初級編の差は何かと申し上げますと、それはただの気分だとしか説明しようがないわけですが、そのあたりについては、さらっとスルーしていただきまして。 以下三つほど書いてきました。 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 ブレークポ

  • LemonJar - iOS Console

    Have you ever wished for new world order? How about a better way to view iOS console logs? Well, iOS Console can help with at-least one of these! iOS Console allows you to view iOS console logs directly from your Mac, and now with built in textual filtering, finding a specific log message has never been easier! iOS Console is freeware and currently in beta. We reserve the right to make a pro versi

    LemonJar - iOS Console
  • バグのことは嫌いになってもXcodeのことは嫌いにならないでください。

    ROPPONGI.swift 第5回の登壇資料になります。 https://visits.connpass.com/event/96594/ この資料で紹介しているサンプル: https://github.com/fumiyasac/ReduxSampleSwift アプリのアーキテクチャの選択においても、注目を浴びているRedux。 複雑になりがちなアプリの状態管理を扱いやすくできる点やデータの流れの見通しをよくする点などのメリットがあり、私自身もとてもその点を興味深く感じています。 今回はアプリ自体は簡単ではあるものの、サンプルと一緒に基的な部分や概念とUIに関する処理との組み合わせ方についてお話できればと思います。

    バグのことは嫌いになってもXcodeのことは嫌いにならないでください。
  • Xcodeでデバッグ実行中にクラッシュした時に捗るブレークポイント設定 - Qiita

    ずばりこの設定です。 ExceptionはAllでも良いですが、実際の動作に問題無い内部例外に反応しちゃったりするのでObjective-Cにしてます。 po $arg1について気になると思いますが、そこだけ見たい方はこちら 通常、クラッシュするとここでブレークしちゃうため、 左下の+ボタンから、これを追加しておくとクラッシュ時に原因箇所で止まって捗るテクはそこそこ有名だと思います。 このようにブレークする場所が分かりやすくなる: po $arg1について さらに、こちらは有名じゃないと思いますが、Debugger Commandアクションに以下を入力しておくと、 このようにブレークすると同時に自動的に原因のログを出力してくれます。 無設定だと、1回目にブレークした時点ではクラッシュについてのログは何も出ていなくて、1・2回デバッグcontinueボタンを押すと、ログが吐き出されます。 即

    Xcodeでデバッグ実行中にクラッシュした時に捗るブレークポイント設定 - Qiita
  • LumberjackConsoleでどこでもログを確認できるようにする! | DevelopersIO

    実機でログを確認したい! 以前、iOSで使える柔軟なログフレームワーク〜CocoaLumberjack | Developers.IOで紹介したCocoaLumberjackは出力先や出力レベルの設定が行える柔軟なログフレームワークですが、実機で確認するときにPCに接続しなければログが確認できませんでした。実機を持ち歩きながらログを確認できたら便利ですよね。 そういうときはLumberjackConsoleを使いましょう! LumberjackConsoleを有効にすると、アプリの画面に専用のコンソール画面が追加されます。そこから直接実行中のログを確認することができ、更に検索やフィルタまでできちゃいます!便利! それでは、実際に使ってみましょう。 尚、以下の環境を前提に解説します。 Mac OS X 10.9 Xcode 5.0.2 iOS 7 今回は短いですよー。 インストール インスト

    LumberjackConsoleでどこでもログを確認できるようにする! | DevelopersIO
  • Xcodeのコンソール出力に色をつけて見やすくしよう〜XcodeColorsとCocoaLumberjack〜 | DevelopersIO

    NSLogでコンソールにログを出力してデバッグすることは良くあることだと思います。でもその出力が大量になるとすごく見づらいですよね。というわけで今回はコンソールに出力されるログに色をつけて見やすくしよう!的なことを書きたいと思います。 XcodeのプラグインXcodeColors 実は標準だとXcodeのコンソールに出力されるログに色をつけるのが結構難しいらしいです(やったことないですが)。そこで登場するのがXcodeColorsです。XcodeColorsはXcodeのプラグインで、インストールするだけで簡単にログに色を付けることができます! XcodeColorsのインストール まずは以下のURLからXcodeColors.xcplugin.zipをダウンロードします。 Downloads · robbiehanson/XcodeColors XcodeColors.xcplugin.

  • 1