9

したがって、Appleは現在UDIDにアクセスするアプリを拒否しているため、当社の現在のプロジェクトでは、このプロパティを呼び出すすべてのAPIを削除する必要があります。

[[UIDevice currentDevice] uniqueIdentifier]

独自のコードですべての呼び出しを削除しましたが、使用している多くの外部ライブラリがこのプロパティを呼び出していないことを確認する必要があります。

ライブラリがこのプロパティを呼び出しているかどうかを判断するための最も信頼できる方法は何ですか?

前もって感謝します!

4

3 に答える 3

14

otx(不安定になっているように見える)を使用する以外に、 1つのオプションは、そのメソッドにシンボリックブレークポイントを設定してから、アプリをしばらく実行して、ヒットするかどうかを確認することです。

そのメソッドのシンボリックブレークポイントの構成は次のようになります。

ここに画像の説明を入力してください

そのブレークポイントに到達した場合は、デバッガコンソールを開いて、と入力することで、誰がブレークポイントを呼び出したかを確認できますbt。この場合、電話は私から来ましたが、誰が電話application:didFinishLaunchingWithOptions:したかに関係なく機能します。

(lldb) bt
* thread #1: tid = 0x1c03, 0x001f4690 UIKit`-[UIDevice uniqueIdentifier], stop reason = breakpoint 1.1
frame #0: 0x001f4690 UIKit`-[UIDevice uniqueIdentifier]
frame #1: 0x0000212e MyApp`-[AppDelegate application:didFinishLaunchingWithOptions:](self=0x0747fcb0, _cmd=0x005aec21, application=0x08366300, launchOptions=0x00000000) + 702 at AppDelegate.m:37
frame #2: 0x00015157 UIKit`-[UIApplication _handleDelegateCallbacksWithOptions:isSuspended:restoreState:] + 266
frame #3: 0x00015747 UIKit`-[UIApplication _callInitializationDelegatesForURL:payload:suspended:] + 1248
frame #4: 0x0001694b UIKit`-[UIApplication _runWithURL:payload:launchOrientation:statusBarStyle:statusBarHidden:] + 805
frame #5: 0x00027cb5 UIKit`-[UIApplication handleEvent:withNewEvent:] + 1022
frame #6: 0x00028beb UIKit`-[UIApplication sendEvent:] + 85
frame #7: 0x0001a698 UIKit`_UIApplicationHandleEvent + 9874
frame #8: 0x01f01df9 GraphicsServices`_PurpleEventCallback + 339
frame #9: 0x01f01ad0 GraphicsServices`PurpleEventCallback + 46
frame #10: 0x01f1bbf5 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 53
frame #11: 0x01f1b962 CoreFoundation`__CFRunLoopDoSource1 + 146
frame #12: 0x01f4cbb6 CoreFoundation`__CFRunLoopRun + 2118
frame #13: 0x01f4bf44 CoreFoundation`CFRunLoopRunSpecific + 276
frame #14: 0x01f4be1b CoreFoundation`CFRunLoopRunInMode + 123
frame #15: 0x0001617a UIKit`-[UIApplication _run] + 774
frame #16: 0x00017ffc UIKit`UIApplicationMain + 1211
frame #17: 0x00001d42 MyApp`main(argc=1, argv=0xbffff3f8) + 130 at main.m:16
于 2013-03-25T23:57:05.803 に答える
3

クインの答えを拡張するには:

  • stringsコンパイルされたオブジェクトまたはライブラリ内のすべてのシンボルを、クラスごとに最初に表示された順に一覧表示します。出力に表示uniqueIdentifierされている場合は、その名前で他のメソッドを呼び出している可能性があります。しかしcurrentDevice、出力の直後にが続くuniqueIdentifier場合は、ほぼ確実にを呼び出しています[[UIDevice currentDevice] uniqueIdentifier]。ライブラリがファイルの前の方で呼び出している場合は、2行が連続していない可能性がcurrentDeviceあります。
  • otool -ovライブラリ内のすべてのクラス、メソッド、およびインポートを一覧表示します。リストされている場合uniqueIdentifierは、ライブラリがその名前で独自のメソッドを定義している可能性があります。文脈の中で参照を見てください。各クラスの下部にContents of (__DATA,__objc_classrefs) section、インポートを一覧表示するようなセクションが表示されます。_OBJC_CLASS_$_UIDeviceが参照していることがわかったクラスのインポートの中にリストされている場合uniqueIdentifier、そのクラスがを呼び出している可能性があり-[UIDevice uniqueIdentifier]ます。
  • の出力は、この目的の場合nmと同様です。otool具体的には、へuniqueIdentifierの呼び出しは表示されませんが、インポートするクラスは表示されますUIDevice
于 2013-05-15T21:26:38.543 に答える
2

クローズドソースライブラリが実際にメソッドを呼び出しているかどうかを確実に判断するのは難しい場合がありますが、次のようになっている可能性があるかどうかを確認する方法がいくつかあります。

  • 文字列を使用して、使用方法に関係なく、ライブラリに「uniqueIdentifier」が表示されるかどうかを確認します。

    $ strings libFoo.a | grep uniqueIdentifier

  • nmまたはotoolを使用する(この回答を参照)

  • otxの使用(この回答を参照)

これらのアプローチは、ブレークポイントの設定が見逃す可能性のある潜在的な呼び出しを見つけるのに役立ちます。

于 2013-05-15T13:20:23.677 に答える