企业官网建设流程全解析

1. 线程保活到底在保什么

1.1 从一个真实崩溃场景说起

做过iOS开发的朋友大概率遇到过这样一种情况：App在某个页面启动了一个后台线程，用来做轮询、日志上报或者长连接维护，结果用户在这个页面停留时间一长，线程莫名其妙就没了，回调不执行，数据断了，甚至偶尔还会因为线程被回收导致野指针崩溃。更诡异的是，这个问题在开发阶段用Xcode连着调试时几乎复现不了，一上真机跑一段时间就必现。

这个问题的根源，就藏在RunLoop和线程生命周期的关系里。很多人对线程的理解停留在“创建了就一直在”这个层面，实际上在iOS/macOS这套体系下，一个线程执行完它的入口函数（比如NSThread的main方法，或者pthread的启动函数）之后，如果没有额外的机制让它“停在那里”，它就会直接退出，被系统回收。你后续再往这个线程上派发任务，要么石沉大海，要么直接崩溃。

线程保活要解决的核心问题就是：让一个线程在完成初始化工作后不退出，持续驻留在内存中，随时准备接收并处理后续派发过来的任务。听起来简单，但真正落地时会牵扯到RunLoop的启动模式、事件源、退出控制、内存管理等一系列细节，稍有不慎就会踩坑。

1.2 为什么偏偏是RunLoop

你可能会问，让线程不退出，直接写个while(true){}死循环不就行了？理论上确实能让线程不退出，但这样做有两个致命问题。第一，死循环会持续占用CPU时间片，哪怕没有任何任务要处理，CPU也在空转，耗电、发热、被系统降频，用户体验直接崩掉。第二，死循环里的线程无法响应外部事件，你没法优雅地让它停下来，也没法在循环里高效地等待任务到来。

RunLoop的价值就在这里。它本质上是一个事件驱动的循环，当有事件源（Source）、定时器（Timer）或者观察者（Observer）需要处理时，它才从休眠状态被唤醒去干活；没有事件时，它会让线程进入休眠，把CPU让出去。这就像一个值班室，没人来办事的时候值班员在打盹，有人按铃了才起来处理，处理完继续打盹。这种机制既保证了线程存活，又不会浪费系统资源。

所以线程保活的标准姿势就是：给线程绑定一个RunLoop，往RunLoop里添加至少一个事件源或定时器，然后启动RunLoop。只要RunLoop里有东西可等，它就不会返回，线程自然也就一直活着。

1.3 谁需要认真对待这件事

线程保活不是一个“炫技”的知识点，它在很多真实业务场景里是刚需。比如：

• 常驻后台服务：需要在独立线程上维护一个长连接或者定时轮询任务，主线程不能阻塞，子线程又不能退出。
• 串行任务队列：希望所有耗时任务都在同一个线程上串行执行，避免多线程竞争，同时这个线程要一直待命。
• 第三方SDK内部实现：很多网络库、日志库、监控SDK内部都会维护一个常驻线程来接收回调。
• 自定义线程池：需要控制线程数量，复用已有线程而不是频繁创建销毁。

如果你正在做上述任何一类事情，那线程保活就是你绕不过去的一道坎。下面我会从设计思路、核心原理、完整实现、常见坑四个维度，把这件事彻底讲透。

2. 核心原理拆解：RunLoop与线程的绑定关系

2.1 RunLoop和线程是一一对应的

先明确一个基础事实：每个线程都有且只有一个与之对应的RunLoop对象。这个RunLoop对象在第一次被获取时创建，在线程结束时销毁。主线程的RunLoop在App启动时由系统自动创建并启动，而子线程的RunLoop默认是“懒加载”的——你不去获取它，它就不存在；你不去启动它，它就不会跑起来。

这个“懒加载”特性非常关键。很多新手以为创建了NSThread并start之后，线程就自带一个跑着的RunLoop，这是错的。子线程的RunLoop需要你手动获取并手动启动，否则线程执行完入口函数就直接退出了。

获取RunLoop的方式很简单：

NSRunLoop *runLoop = [NSRunLoop currentRunLoop];

或者用更底层的CF接口：

CFRunLoopRef runLoop = CFRunLoopGetCurrent();

这两者拿到的是同一个RunLoop对象，只是封装层级不同。NSRunLoop是CFRunLoopRef的Objective-C封装，底层实现完全一致。

2.2 RunLoop不启动等于没有

拿到RunLoop对象只是第一步，真正让它“活”起来的是启动操作。启动RunLoop的常见方式有几种：

// 方式一：默认模式，永久运行，直到被显式停止 [[NSRunLoop currentRunLoop] run]; // 方式二：指定时间，到点自动退出 [[NSRunLoop currentRunLoop] runUntilDate:[NSDate distantFuture]]; // 方式三：指定具体日期 [[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]];

这里有个非常重要的细节：如果RunLoop里没有任何事件源、定时器或观察者，run方法会立即返回。也就是说，你光调用run是没用的，必须在此之前往RunLoop里塞点“东西”，让它有理由继续等待。

这个“东西”通常是一个NSPort、一个NSTimer，或者一个自定义的CFRunLoopSource。最常用、最轻量的做法是添加一个空的NSPort：

[[NSRunLoop currentRunLoop] addPort:[NSPort port] forMode:NSDefaultRunLoopMode];

这行代码的作用是给RunLoop添加一个输入源，让它有事件可等，从而不会立即返回。NSPort本身不做什么实际工作，纯粹是“占位”，保证RunLoop能持续运行。

2.3 为什么用Port而不是Timer

有人会问，用NSTimer也能让RunLoop不退出，为什么偏偏推荐NSPort？原因有几点：

第一，NSTimer会周期性触发，哪怕你设置的时间间隔很长，它也会在某个时刻唤醒RunLoop执行回调，造成不必要的CPU唤醒。而NSPort是纯事件驱动的，没有事件时完全静默。

第二，NSTimer的回调会占用RunLoop的处理时间，如果回调里做了耗时操作，还会影响其他任务的响应。NSPort没有这个问题。

第三，NSTimer在某些RunLoop模式下可能不触发，导致RunLoop意外退出，而NSPort作为输入源更稳定。

所以业界的标准做法就是：添加一个空的NSPort作为占位输入源，然后启动RunLoop。这是经过大量实践验证的最优解。

2.4 RunLoop的退出控制

RunLoop一旦跑起来，怎么让它停下来？这是线程保活的另一个关键点。你不能直接“杀死”RunLoop，只能通过移除所有事件源和定时器，或者调用CFRunLoopStop来让它退出。

// 停止指定RunLoop CFRunLoopStop(CFRunLoopGetCurrent());

但这里有个坑：CFRunLoopStop只会让RunLoop退出当前这一次run调用，如果你的代码是在一个循环里反复调用run，那它退出后又会重新跑起来。所以正确的停止逻辑需要配合一个标志位：

- (void)stop { self.shouldKeepRunning = NO; CFRunLoopStop(CFRunLoopGetCurrent()); }

然后在RunLoop的启动逻辑里判断这个标志位，决定是否继续。这个细节后面会在完整实现里详细展开。

3. 完整实现：手把手写一个常驻线程

3.1 方案选型：NSThread还是pthread

实现常驻线程，底层可以用NSThread，也可以用pthread。两者各有优劣：

对于绝大多数iOS/macOS业务场景，NSThread完全够用，而且代码更简洁、更易维护。除非你有极致的性能要求或者需要跨平台，否则没必要上pthread。下面我以NSThread为例，给出一个生产级别的实现。

3.2 基础版实现

先看一个最基础的版本，理解核心逻辑：

@interface KeepAliveThread : NSObject @property (nonatomic, strong) NSThread *thread; @property (nonatomic, assign) BOOL shouldKeepRunning; - (void)start; - (void)stop; - (void)executeTask:(void (^)(void))task; @end @implementation KeepAliveThread - (instancetype)init { self = [super init]; if (self) { _shouldKeepRunning = YES; _thread = [[NSThread alloc] initWithTarget:self selector:@selector(threadEntryPoint) object:nil]; _thread.name = @"com.example.keepalive"; } return self; } - (void)start { [self.thread start]; } - (void)threadEntryPoint { @autoreleasepool { // 添加占位输入源，防止RunLoop立即退出 [[NSRunLoop currentRunLoop] addPort:[NSPort port] forMode:NSDefaultRunLoopMode]; // 循环启动RunLoop，直到标志位被置为NO while (self.shouldKeepRunning) { [[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]]; } } } - (void)stop { self.shouldKeepRunning = NO; // 在目标线程上停止RunLoop [self performSelector:@selector(stopRunLoop) onThread:self.thread withObject:nil waitUntilDone:YES]; } - (void)stopRunLoop { CFRunLoopStop(CFRunLoopGetCurrent()); } - (void)executeTask:(void (^)(void))task { if (!task) return; [self performSelector:@selector(runTask:) onThread:self.thread withObject:task waitUntilDone:NO]; } - (void)runTask:(void (^)(void))task { task(); } @end

这段代码看起来不长，但每一行都有讲究。我逐个拆解关键点。

3.3 关键细节逐行解析

占位输入源的添加时机：必须在RunLoop启动之前添加，而且必须在目标线程内部添加。如果你在外部线程调用addPort，加的是外部线程的RunLoop，完全无效。这是新手最容易犯的错误之一。

while循环的必要性：runMode:beforeDate:方法在RunLoop退出后会返回，如果不用while包起来，线程就会继续往下执行然后结束。加上while循环，配合shouldKeepRunning标志位，才能实现“可控制的持续运行”。

stop方法的线程安全：CFRunLoopStop必须在目标线程上调用才有效。如果你在外部线程直接调用，停的是外部线程的RunLoop。所以这里用performSelector:onThread:把停止操作派发到目标线程执行，并且waitUntilDone:YES保证停止完成后再返回。

executeTask的派发方式：用performSelector:onThread:把任务派发到常驻线程执行，waitUntilDone:NO表示异步执行，不阻塞调用方。如果任务之间有顺序要求，这个方式天然保证串行执行，因为RunLoop是单线程处理的。

3.4 进阶版：支持任务队列和状态回调

基础版能满足大部分需求，但在实际项目中，我们往往还需要更多能力：任务排队、执行状态回调、线程销毁通知等。下面是一个增强版的设计思路。

typedef void(^KeepAliveTask)(void); typedef void(^KeepAliveCompletion)(void); @interface AdvancedKeepAliveThread : NSObject @property (nonatomic, copy) KeepAliveCompletion onStart; @property (nonatomic, copy) KeepAliveCompletion onStop; - (void)start; - (void)stop; - (void)asyncExecute:(KeepAliveTask)task; - (void)syncExecute:(KeepAliveTask)task; @end

asyncExecute和syncExecute的区别在于是否等待任务完成。同步执行适合需要拿到结果的场景，异步执行适合纯通知类任务。实现上，同步执行用waitUntilDone:YES，异步执行用waitUntilDone:NO。

这里有个细节要注意：同步执行如果任务本身又派发任务到同一个线程，会造成死锁。因为RunLoop是单线程串行处理的，当前任务没执行完，新任务就排不进去，而当前任务又在等新任务完成，互相等待。所以同步执行要慎用，尤其是任务内部可能再次派发的情况。

3.5 参数选择与性能考量

线程保活涉及几个关键参数，选错了会影响性能和稳定性：

RunLoop模式的选择：默认用NSDefaultRunLoopMode就够了。如果你的任务需要在UI滚动时也能执行，可以考虑NSRunLoopCommonModes，但要注意CommonModes会包含Tracking模式，可能导致任务在用户交互时被频繁唤醒，增加耗电。

beforeDate的设置：用[NSDate distantFuture]表示“一直等到有事件为止”，这是最省电的做法。如果设置成具体时间，RunLoop会到点自动醒来，造成不必要的CPU唤醒。除非你有周期性任务需求，否则一律用distantFuture。

线程优先级：通过[NSThread setThreadPriority:]可以调整线程优先级，但一般不建议动。默认优先级已经能满足绝大多数场景，乱调可能导致线程饥饿或者抢占主线程资源。

栈大小：NSThread默认栈大小是512KB，如果任务涉及大量递归或者大数组操作，可以通过setStackSize:调整。但要注意，栈大小设置必须在start之前，启动后修改无效。

4. 常见问题与排查技巧实录

4.1 线程启动后立即退出

这是最高频的问题。现象是线程创建并start之后，入口函数执行完就结束了，后续派发的任务全部丢失。

根本原因：RunLoop没有启动，或者启动了但里面没有任何事件源，导致run方法立即返回。

排查步骤：

1. 确认在目标线程内部调用了[NSRunLoop currentRunLoop]获取RunLoop。
2. 确认在启动RunLoop之前添加了NSPort或其他输入源。
3. 确认启动RunLoop的代码在入口函数内，而不是在外部线程。

快速验证方法：在入口函数里加日志，打印RunLoop启动前后的状态。如果启动后立即打印了“RunLoop退出”，说明没有事件源。

4.2 停止线程时崩溃或卡死

停止常驻线程时出现崩溃，通常是因为在错误的线程上调用了CFRunLoopStop，或者停止时还有任务在执行。

排查思路：

• 确认CFRunLoopStop是在目标线程上执行的，用performSelector:onThread:派发。
• 确认停止前没有未完成的任务，必要时加一个“等待所有任务完成”的逻辑。
• 确认shouldKeepRunning标志位的读写是线程安全的，必要时加锁。

避坑技巧：停止操作最好设计成“优雅停止”——先置标志位，再停止RunLoop，最后等待线程真正结束。不要直接强杀，容易留下资源泄漏。

4.3 任务派发后不执行

任务派发出去了，但目标线程没反应。这种情况通常是RunLoop模式不匹配导致的。

原因分析：RunLoop有多个模式，performSelector:onThread:默认派发到NSDefaultRunLoopMode。如果你的RunLoop当前跑在UITrackingRunLoopMode（比如用户正在滚动列表），默认模式的任务就不会被执行，要等滚动结束才处理。

解决方案：如果任务需要实时响应，把RunLoop跑在NSRunLoopCommonModes下，或者把输入源添加到CommonModes。但要注意CommonModes的性能开销。

4.4 内存泄漏与循环引用

常驻线程如果持有self，而self又持有线程，很容易形成循环引用，导致对象无法释放。

典型错误写法：

_thread = [[NSThread alloc] initWithTarget:self selector:@selector(run) object:nil];

这里NSThread会强引用target（也就是self），如果self又强引用_thread，就循环引用了。

正确做法：用block方式创建线程，并在block里用weakSelf，或者把线程逻辑抽到一个独立的类里，避免和业务对象互相持有。

__weak typeof(self) weakSelf = self; _thread = [[NSThread alloc] initWithBlock:^{ __strong typeof(weakSelf) strongSelf = weakSelf; if (!strongSelf) return; [strongSelf threadEntryPoint]; }];

4.5 常见问题速查表

4.6 几个只有踩过坑才知道的细节

细节一：autoreleasepool不能省。常驻线程的入口函数里必须包一个@autoreleasepool，否则线程运行期间产生的临时对象无法及时释放，内存会持续增长。虽然RunLoop每次处理事件时会自动创建和销毁autoreleasepool，但入口函数本身产生的对象需要手动管理。

细节二：线程名称要设置。给线程设置一个有意义的名字（比如com.example.keepalive），在调试和崩溃日志分析时能快速定位问题。这个习惯在多人协作的项目里尤其重要。

细节三：不要在常驻线程里做重活。常驻线程的核心价值是“待命”，不是“干活”。如果某个任务特别耗时，应该再开一个临时线程去处理，常驻线程只负责接收和派发。否则常驻线程被阻塞，后续所有任务都会排队等待。

细节四：注意RunLoop的嵌套。如果在RunLoop的回调里又启动了新的RunLoop，会形成嵌套，退出逻辑会变得非常复杂。尽量避免这种设计，保持RunLoop扁平化。

细节五：测试要覆盖真机场景。模拟器和真机在RunLoop行为上基本一致，但真机的后台策略、内存压力、CPU调度更复杂。线程保活的问题往往在真机长时间运行后才暴露，所以测试时一定要在真机上跑足够长的时间。

5. 线程保活的替代方案与选型建议

5.1 GCD常驻队列能不能替代

很多人会问，用GCD的串行队列不也能实现“任务串行执行”吗，为什么还要费劲搞RunLoop线程保活？

这是个好问题。GCD的串行队列确实能保证任务串行执行，而且系统会自动管理线程的创建和销毁，用起来更省心。但它和RunLoop常驻线程有几个本质区别：

第一，GCD不保证任务在同一个线程上执行。串行队列只保证任务按顺序执行，但底层可能在不同线程之间切换。如果你的任务依赖线程局部存储（Thread Local Storage）或者需要绑定特定线程的资源（比如某些C库的上下文），GCD就不适用。

第二，GCD无法精细控制线程生命周期。你没法知道GCD什么时候创建线程、什么时候销毁线程，也没法在任务执行前后插入自定义逻辑。而RunLoop常驻线程完全由你掌控。

第三，GCD的队列优先级和QoS管理更复杂。虽然GCD提供了QoS机制，但在某些场景下不如直接控制线程优先级来得直观。

所以选型建议是：如果只是简单的任务串行执行，用GCD串行队列就够了；如果需要绑定特定线程、需要精细控制生命周期、或者需要和RunLoop生态深度集成，那就用RunLoop常驻线程。

5.2 OperationQueue的适用场景

NSOperationQueue是另一套并发方案，它比GCD更面向对象，支持任务依赖、取消、优先级等高级特性。但它的线程管理同样是系统托管的，你无法保证任务在固定线程上执行。

如果你的需求是“任务有依赖关系、需要取消、需要控制并发数”，NSOperationQueue是更好的选择。但如果需求是“固定线程、常驻待命”，还是得回到RunLoop方案。

5.3 选型决策表

6. 生产环境下的稳定性加固

6.1 异常捕获与恢复

常驻线程一旦崩溃，整个线程就没了，后续任务全部失效。所以在生产环境里，必须给常驻线程加上异常捕获机制。

- (void)threadEntryPoint { @autoreleasepool { [[NSRunLoop currentRunLoop] addPort:[NSPort port] forMode:NSDefaultRunLoopMode]; while (self.shouldKeepRunning) { @try { [[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]]; } @catch (NSException *exception) { // 记录异常日志，但不退出循环 NSLog(@"KeepAlive thread exception: %@", exception); } } } }

注意，@try-@catch只能捕获Objective-C异常，捕获不了底层C++异常或者信号量崩溃。对于后者，需要用信号处理或者更底层的机制，但那已经超出常规业务开发的范畴了。

6.2 心跳检测与自动重启

更稳妥的做法是加一个心跳检测机制：定期检查常驻线程是否还活着，如果发现线程已退出，自动重新创建。

- (void)startHeartbeat { self.heartbeatTimer = [NSTimer scheduledTimerWithTimeInterval:5.0 target:self selector:@selector(checkThreadAlive) userInfo:nil repeats:YES]; } - (void)checkThreadAlive { if (!self.thread || self.thread.isFinished) { NSLog(@"KeepAlive thread died, restarting..."); [self restart]; } }

这个机制在长时间运行的服务里非常有必要，能大幅提升稳定性。

6.3 日志埋点与监控

生产环境里，你没法直接调试，只能靠日志。建议在常驻线程的关键节点都加上埋点：线程启动、线程停止、任务派发、任务完成、异常发生。这些日志在排查线上问题时是救命稻草。

埋点要注意不要过于频繁，否则日志量太大会影响性能。一般记录状态变更和异常就够了，正常任务执行可以采样记录。

6.4 资源清理与优雅退出

App进入后台或者即将退出时，常驻线程需要优雅停止，释放资源。在applicationDidEnterBackground或者applicationWillTerminate里调用停止逻辑，确保线程正常退出，避免被系统强杀导致数据丢失。

- (void)applicationWillTerminate:(UIApplication *)application { [[KeepAliveThreadManager sharedInstance] stopAllThreads]; }

停止时要给线程留出处理收尾工作的时间，不要立即强杀。可以设置一个超时，超时后再强制停止。

7. 一些实战中的经验体会

线程保活这个技术点，看起来简单，真正做好做稳其实需要不少经验积累。我自己在项目里踩过的坑，总结下来有这么几条。

第一，不要为了保活而保活。有些场景其实用GCD就能解决，硬上RunLoop常驻线程反而增加了复杂度和维护成本。每次决定用常驻线程之前，先问自己：真的需要固定线程吗？真的需要精细控制生命周期吗？如果答案是否定的，用GCD更省事。

第二，停止逻辑比启动逻辑更重要。启动一个常驻线程很简单，但优雅地停止它、确保资源不泄漏、确保没有任务丢失，这些才是难点。设计的时候要把停止逻辑想清楚，不要等到出问题了再补。

第三，测试要充分。常驻线程的问题往往在长时间运行、高频派发、异常场景下才暴露。单元测试覆盖不了这些，必须做集成测试和压力测试。我一般会写一个脚本，模拟连续派发几万个任务，观察内存、CPU、线程状态的变化。

第四，监控要到位。线上环境你没法调试，只能靠监控。线程存活状态、任务队列长度、异常次数，这些指标都要采集。一旦发现异常，能第一时间告警和定位。

第五，保持简单。常驻线程的实现方案有很多种，但越简单越稳定。不要过度设计，不要引入不必要的依赖。一个NSPort加一个while循环，能解决90%的问题。

最后分享一个小技巧：如果你不确定RunLoop是否真的在跑，可以在入口函数里加一个定时打印，每隔几秒输出一次当前线程状态。如果日志持续输出，说明RunLoop活着；如果日志停了，说明RunLoop退出了。这个土办法在排查问题时特别管用。

线程保活这个知识点，往浅了说就是“加个NSPort启动RunLoop”，往深了说涉及到RunLoop的运行机制、线程生命周期管理、内存管理、异常处理等多个层面。希望这篇内容能帮你把这件事彻底搞明白，在实际项目里少踩几个坑。