Swift 从获取所有 NSObject 对象聊起：ObjC、汇编语言以及底层方法调用链（一）

概览

Swift 语言给我们的印象是：简洁、现代化和可以"心安神泰"的完全信赖。不过，在一些特殊情况下我们唯有进入 Swift 底层的动态世界方能真正地"随遇而安"。

保安局"刘局长"曾语重心长的教导过我们："非常时期，用非常方法！ "。所以，这里就让我们彻底沉浸到 Swift 那深不见底的"千尺冰寒"中，来探寻 Objective-C 和汇编语言的奇妙世界吧！

在本篇博文中，您将学到以下内容：

概览
[1. 获取当前所有 NSObject 对象的基本原理](#1. 获取当前所有 NSObject 对象的基本原理)
[2. NSObject.init() 里面到底做了啥？](#2. NSObject.init() 里面到底做了啥？)
[3. 啥都不做也不行？你们是要闹哪样？](#3. 啥都不做也不行？你们是要闹哪样？)
总结

在下一篇博文中，我们将继续本次冒险之旅来进一步揭秘：为什么在 NSObject 构造器 init 方法上做钩子会如此"命运坎坷"，以及"逆天改命"的各种黑魔法！

好了，废话少叙！让我们马上开始奇妙的底层探险吧！

Let's Dive in！！！😉

1. 获取当前所有 NSObject 对象的基本原理

首先第一个问题是：为什么要获取 App 当前运行时所有的 NSObject 对象？

答案有两个：

好玩！
方便对它们做钩子（Hook）从而进一步实现自己的"天马行空"之梦想。

从 Xcode 的调试内存图（Debug Memory Graph）中，我们可以可以大致领略到 App 运行中那星罗棋布的海量对象实例：

那么第二个问题是：我们怎样才能像 Xcode 那样在运行时探查所有 NSObject 对象的实例呢？

一种方案是"古老"的 SWIZZ 方法，它存在于 Objective-C 语言的"远古"时代。

所谓 SWIZZ 是一种对系统的"欺骗"，一种运行时的"诡计"。它是利用 Swift 底层 ObjC 语言的动态特性实现在 App 进程活跃时修改 ObjC 运行时（Runtime）内容的方法。

SWIZZ 的一种常见应用就是钩子（Hook）。所谓钩子就是在 App 运行时动态的"勾住"（截获）对象方法从而起到监视、记录甚至修改对象原有方法的目的。

我们知道 NSObject 对象的诞生都必须经过 NSObject 类实例的构造器，也就是 NSObject.init() 方法来完成。那么如果我们在该方法上设置一个钩子，那么不就可以得偿所愿监控到所有 NSObject 对象了吗？

以下是我们的第一次尝试：

swift 复制代码

class func tryHookNSObjectInit() {
    let oldInitSel = #selector(NSObject.init)
    let oldInitMethod = class_getInstanceMethod(NSObject.self, oldInitSel)!
    
    let closure = {obj, sel in
        print(obj)
    } as @convention(block) (NSObject, Selector) -> Void
    
    let closureObject = unsafeBitCast(closure, to: AnyObject.self)
    let closureImp = imp_implementationWithBlock(closureObject)
    method_setImplementation(oldInitMethod, closureImp)
}

如上所示，我们通过 SWIZZ 机制将 NSObject 构造器 init() 方法非常 easy 的替换成了自己的 closure 闭包。

不过，假若你胆敢运行上面的代码，你绝对会"死得很惨"：

因为你可能还不知道，你此时正"命犯天煞孤星"：多处"隐秘"陷阱正在一起合计着准备把你撕扯的体无完肤。

也许有些小伙伴们会认为崩溃的原因很"一目了然"：因为我们没有在钩子方法中调用原来的 NSObject 构造器。

真相果真如此吗？

为了解答这个问题，我们先要来看看在 NSObject 的构造器里到底做了些神马？

2. NSObject.init() 里面到底做了啥？

首先，清除之前的钩子代码。然后在 Xcode 中新建符号断点（Symbolic Breakpoint），姑且就中断在 NSObject.init() 方法的第一行吧：

运行 App，系统会在某个 NSObject 对象创建时立即中断下来。

在我测试的例子里，中断会发生在一个线程（NSThread）对象创建时：

进入 NSObject 构造器 init 方法，你会发现里面其实只有一条返回指令（ret）真的是"空空如也"！

所以说，在钩子方法中没有调用原来的 NSObject 构造器这并不算一个问题，因为确切的说默认的 NSObject 构造器方法里"空无一物"，调不调用几乎是无所谓的事。

3. 啥都不做也不行？你们是要闹哪样？

为了充分发挥小伙伴们那名侦探般"灵气逼人"的洞察力，我们现在改变策略：不打印对象本身，而是尝试打印对象的地址试试。

swift 复制代码

let closure = {obj, sel in
    let address = Unmanaged.passRetained(obj).toOpaque()
    print(address)
} as @convention(block) (NSObject, Selector) -> Void

运行可以发现，我们在打印出第一个对象的地址后就很快又"GG"了：

看来打印对象地址这种"信手拈来"的简单操作也不行，那请允许我们退"一万步"：将钩子方法替换为一个"空"闭包总行了吧？

swift 复制代码

let closure = {obj, sel in
    // 空空如也！            
} as @convention(block) (Any, Selector) -> Void

不幸的是，结果和之前几乎如出一辙：你还是"死"了，而且同样"死"的很快！

现在小伙伴们可能有点意识到了：不是我们钩子代码的问题，而是整个调用体系的问题！

你们真是冰雪聪明！

不过，在揭秘真正的问题之前让我们先"站在巨人肩膀之上"来尝试另一种完全不同的解决方案吧！

在下一篇博文中，我们将再接再厉用第三方 Hook 包 SwiftHook 来重新探寻一番，期待吧！

总结

在本篇博文中，我们讨论了为什么要在 App 运行时"捕获"所有 NSObject 对象的实例、介绍了 NSObject 默认构造器方法里都做了神马事情，以及初步探讨了实现这一目的的基本原理。

虽然，眼前的团团迷雾让我们暂时还无法得偿所愿，但相信只要怀有坚定的信念，胜利就在眼前！

让我们在下篇继续跟随初心，拨开迷雾见青天吧！再会！😎