Как получить ЛЮБУЮ информацию для uiview (необработанный адрес, сообщаемый визуальным отладчиком) - PullRequest
0 голосов
/ 08 апреля 2019

У меня есть дерево UIViews, которое я пытаюсь понять: UIPageViewController height - это слишком высокая высота строки состояния, и каким-то образом нижняя часть foobar где-то в иерархии опускается ниже высоты окна недвижимости.Вот хроника моих бед с lldb:

(lldb) p (*(UIView*)0x83fcc6d0).accessibilityIdentifier
error: 'UIView' does not have a member named 'accessibilityIdentifier'
(lldb) p ((UIView*)0x83fcc6d0).accessibilityIdentifier
error: property 'accessibilityIdentifier' not found on object of type 'UIView *'
(lldb) p ((UIView*)0x83fcc6d0)->accessibilityIdentifier
error: 'UIView' does not have a member named 'accessibilityIdentifier'
(lldb) p (*(UIView*)0x83fcc6d0).superview
error: 'UIView' does not have a member named 'superview'
(lldb) p (*(UIView*)0x83fcc6d0).superView
\error: 'UIView' does not have a member named 'superView'
(lldb) v (*(UIView*)0x83fcc6d0).superView
(lldb) po (*(UIView*)0x83fcc6d0).superView
error: 'UIView' does not have a member named 'superView'

Ответы [ 2 ]

1 голос
/ 08 апреля 2019
  1. У вас слишком много звездочек.

  2. Нельзя использовать нотацию свойства.

  3. Вынужно использовать po.

Так, например, это должно сработать:

po [((UIView*)0x83fcc6d0) accessibilityIdentifier]

Тем не менее, техника, которую я предпочитаю использовать, это говорить Swift:

expr -l Swift -- import UIKit
expr -l Swift -- let $v = unsafeBitCast(0x83fcc6d0, to: UIView.self)
expr -l Swift -- print($v.accessibilityIdentifier)
0 голосов
/ 09 апреля 2019

Остановившись в viewDidLoad ViewController, вы можете получить доступ к свойству «view» так же, как в коде:

(lldb) expr self.view
(UIView *) $0 = 0x0000000100615150

Теперь у нас есть адрес UIView, давайте попробуем получить доступ к его свойствам:

(lldb) expr ((UIView *) 0x0000000100615150).frame
(CGRect) $5 = (origin = (x = 0, y = 0), size = (width = 768, height = 1024))

Собственность vrs.Обозначение метода «следует» просто автоматическая замена в компиляторе.Однако, когда мы не знаем тип свойства, использование доступа к свойству в синтаксическом анализаторе выражений отладчика может привести к проблемам, особенно при объединении свойств.

Причина этого в том, что на самом деле небезопасно (может испортить стек отладчика), если lldb вызывает функцию, возвращающую struct (например, свойство "frame" в UIView), используя скалярное соглашение о вызовах.Таким образом, lldb очень осторожен, чтобы знать типы элементов в выражении перед его вызовом.Если lldb не может понять это из отладочной информации, может потребоваться дополнительное приведение, чтобы осчастливить средство проверки типов.

Обратите внимание, lldb делает одно исключение из требования, что мы знаем типы в выражениях, которые могут учитыватьразличия вы упомянули.Если мы увидим:

[<some expression whose type we don't know> someSelector]

как выражение или подвыражение, мы перепишем это как:

[(id) <some expression whose type we don't know> someSelector]

Это казалось разумным подспорьем, поскольку единственное, что имеет смыслотправить сообщение ObjC на это «id».Так что любая ошибка будет бессмысленной и, как мы надеемся, менее вероятной.Это означает, что цепочка обращений к методу, что все возвращаемые "id" будут разрешены, когда эквивалент.форма не сможет выполнить проверку типов.

Это все грязные углы работы с неполной информацией о типах во время отладки.Обратите внимание, что многие из этих проблем решаются либо сборкой вашей программы с использованием модулей (-fmodule и -gmodule), либо эквивалентным образом путем выдачи:

(lldb) выражения @import UIKit

как частивашего сеанса отладки.Тогда lldb узнает все типы из UIKit, и синтаксический анализатор выражений сможет сделать лучше.

...