(lldb) bt
* thread #1, queue = 'MainQueue: -[DBGLLDBSession processProfileDataString:]_block_invoke', stop reason = breakpoint 1.1* frame #0: 0x00007fffcaef1897 AppKit`-[NSControl setStringValue:]frame #1: 0x0000000125f5b305 DebuggerUI`__54-[DBGGaugeMemoryEditor _setupTopSectionComponentViews]_block_invoke + 955frame #2: 0x0000000106e49e36 DVTFoundation`-[DVTObservingBlockToken observeValueForKeyPath:ofObject:change:context:] + 610frame #3: 0x00007fffced5035d Foundation`NSKeyValueNotifyObserver + 350frame #4: 0x00007fffced4fbf4 Foundation`NSKeyValueDidChange + 486frame #5: 0x00007fffcee8e867 Foundation`-[NSObject(NSKeyValueObservingPrivate) _changeValueForKeys:count:maybeOldValuesDict:usingBlock:] + 944frame #6: 0x00007fffced1395d Foundation`-[NSObject(NSKeyValueObservingPrivate) _changeValueForKey:key:key:usingBlock:] + 60frame #7: 0x00007fffced7c23b Foundation`_NSSetObjectValueAndNotify + 261frame #8: 0x0000000106e8a742 DVTFoundation`__DVTDispatchAsync_block_invoke + 97frame #9: 0x00007fffe2a77524 libdispatch.dylib`_dispatch_call_block_and_release + 12frame #10: 0x00007fffe2a6e8fc libdispatch.dylib`_dispatch_client_callout + 8frame #11: 0x00007fffe2a849a0 libdispatch.dylib`_dispatch_queue_serial_drain + 896frame #12: 0x00007fffe2a77306 libdispatch.dylib`_dispatch_queue_invoke + 1046frame #13: 0x00007fffe2a7b908 libdispatch.dylib`_dispatch_main_queue_callback_4CF + 505frame #14: 0x00007fffcd35bbc9 CoreFoundation`__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9frame #15: 0x00007fffcd31cc0d CoreFoundation`__CFRunLoopRun + 2205frame #16: 0x00007fffcd31c114 CoreFoundation`CFRunLoopRunSpecific + 420frame #17: 0x00007fffcc87cebc HIToolbox`RunCurrentEventLoopInMode + 240frame #18: 0x00007fffcc87ccf1 HIToolbox`ReceiveNextEventCommon + 432frame #19: 0x00007fffcc87cb26 HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 71frame #20: 0x00007fffcae15a54 AppKit`_DPSNextEvent + 1120frame #21: 0x00007fffcb5917ee AppKit`-[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 2796frame #22: 0x000000010743d98e DVTKit`-[DVTApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 390frame #23: 0x00007fffcae0a3db AppKit`-[NSApplication run] + 926frame #24: 0x00007fffcadd4e0e AppKit`NSApplicationMain + 1237frame #25: 0x00007fffe2aa4235 libdyld.dylib`start + 1frame #26: 0x00007fffe2aa4235 libdyld.dylib`start + 1

从函数调用栈上，我们可以看出，NSTextField值的变化是通过kvo某个值实现的。image lookup -rn '[DBGGaugeMemoryEditor\，可以发现它位于/Applications/Xcode.app/Contents/PlugIns/DebuggerUI.ideplugin/Contents/MacOS/DebuggerUI, 把二进制文件拖到hooper里看一下-[DBGGaugeMemoryEditor _setupTopSectionComponentViews]_block_invoke的实现。

通过查看相应的实现，可以知道是它通过debugSession实例获取相关信息的，再结合调用栈信息，debugSession肯定就是DBGLLDBSession。同样的，通过lldb，我们可以找到DBGLLDBSession位于/Applications/Xcode.app/Contents/PlugIns/DebuggerLLDB.ideplugin/Contents/MacOS/DebuggerLLDB，企图通过hooper看看它的实现，然而并没看出啥有用信息。只能继续尝试lldb断点。po $rdx打印它的参数，似乎出了一串奇怪的字符串？！

(lldb) b -[DBGLLDBSession processProfileDataString:]
Breakpoint 3: where = DebuggerLLDB`-[DBGLLDBSession processProfileDataString:], address = 0x0000000115f99c52
(lldb) c
Process 4489 resuming
Process 4489 stopped
* thread #30, name = '<DBGLLDBSessionThread (pid=51274)>', stop reason = breakpoint 3.1frame #0: 0x0000000115f99c52 DebuggerLLDB`-[DBGLLDBSession processProfileDataString:]
DebuggerLLDB`-[DBGLLDBSession processProfileDataString:]:
->  0x115f99c52 <+0>: push   rbp0x115f99c53 <+1>: mov    rbp, rsp0x115f99c56 <+4>: push   r150x115f99c58 <+6>: push   r14
Target 0: (Xcode) stopped.
(lldb) po $rdi
<DBGLLDBSession: 0x7f9c998bec90>(lldb) po $rdx
num_cpu:8;host_user_ticks:3332988;host_sys_ticks:2148237;host_idle_ticks:23546214;elapsed_usec:1513647973058229;task_used_usec:43128;thread_used_id:1;thread_used_usec:841463;thread_used_name:;thread_used_id:4;thread_used_usec:595;thread_used_name:;thread_used_id:5;thread_used_usec:2130;thread_used_name:576562546872656164;thread_used_id:6;thread_used_usec:3012;thread_used_name:636f6d2e6170706c652e75696b69742e6576656e7466657463682d746872656164;thread_used_id:11;thread_used_usec:255;thread_used_name:;total:17179869184;used:14274596864;rprvt:0;purgeable:0;anonymous:57823232;energy:98435210380;

google大法，lldb源码查看
随便抽了一个关键字host_sys_ticks，google了一下，发现这串字符，竟然来自lldb项目里的debugserver！先查看了一下本机的lldb版本（lldb-900.0.45），在apple open source的官网上没找到这个版本的lldb。无奈下只能去lldb官网clone了一份最新的代码，虽然不知道apple是基于哪个lldb版本开发的，但是看最新的实现总不会错~

通过查看debugserver源码，可以发现前面那串字符串是在std::string MachTask::GetProfileData(DNBProfileDataScanType scanType)生成的，里面有各种profile信息，比如cpu，memory等。

大胆猜想一下，Xcode的内存监控正是定时通过获取debugserver的这个方法的信息来展示的！！！

另外，关于debugserver，可以看这里的介绍。简单来说，它是运行在ios上的一个可以接受lldb前端命令的『远程调试』服务器。在越狱设备上，可以通过它做很多trick，这里暂且不表。

验证
初步
扒出memory profile的代码实现如下：

static void GetPurgeableAndAnonymous(task_t task, uint64_t &purgeable,uint64_t &anonymous) {
#if defined(TASK_VM_INFO) && TASK_VM_INFO >= 22kern_return_t kr;mach_msg_type_number_t info_count;task_vm_info_data_t vm_info;info_count = TASK_VM_INFO_COUNT;kr = task_info(task, TASK_VM_INFO_PURGEABLE, (task_info_t)&vm_info,&info_count);if (kr == KERN_SUCCESS) {purgeable = vm_info.purgeable_volatile_resident;anonymous =vm_info.internal + vm_info.compressed - vm_info.purgeable_volatile_pmap;}#endif
}

再看看前面获取的anonymous的字节值，57823232对应的正是55.1445007MB，即debug内存面板展示的值！

这里再附上同事发现的WebKit内存计算公式，可以比较一下理解，具体参看这里，搜索一下phys_footprint便知。

phys_footprint = (internal - alternate_accounting) + (internal_compressed - alternate_accounting_compressed) + iokit_mapped + purgeable_nonvolatile + purgeable_nonvolatile_compressed + page_table