Android智能指针RefBase/sp/wp底层原理与避坑指南

做Android系统开发这些年，最常打交道的一套内存工具就是平台自带的智能指针：RefBase、sp、wp。跟纯C++项目里习惯性用std::shared_ptr不同，Android在Framework、Binder、图形栈等大量native模块里都坚持用这套自研智能指针，这背后有历史原因，也有现实的性能考量。很多刚开始啃AOSP源码的同行会有一个共同疑问：项目里明明可以用C++11标准库，为什么还要维护一套sp/wp？这篇就把Android智能指针的使用方法、底层计数模型、常见坑点集中拆一遍，适合准备啃Framework源码的开发者，也适合已经在写native模块但被生命周期问题折磨过的人。

这篇文章不会只讲API怎么调，我会把“为什么这么设计”也讲清楚。比如强引用和弱引用为什么是两套计数、wp怎么安全地提升回sp、析构为什么一定要走sp而不是手动delete，这些细节搞明白之后，再去看系统源码会轻松很多。后面还会附上我实际调试中踩过的几个典型崩溃案例，以及一套相对好用的排查思路。

1. 先搞明白：Android 自研智能指针想解决什么问题

1.1 native层对象生命周期为什么这么难管

Android系统里大量核心服务都是用C++实现的。一个native对象可能被创建它的模块使用，也可能被注册进某个回调接口，再被另一个线程甚至另一个进程的Binder调用持有。这个过程中对象的创建点和释放点经常隔着十万八千里，单纯靠“谁new谁delete”的约定很难不出事。

举个最常见的场景：一个图形缓冲区对象被生产者创建后，要交给消费者异步使用。生产者线程已经把这个对象从自己的逻辑里移除，但消费者线程还握着一份指针，正准备做渲染。如果生产端提前把对象delete了，消费端就会拿到一个悬空指针，轻则读到垃圾数据，重则直接崩溃在native层。这类问题在早期Android版本里是稳定性事故的主要来源之一。

裸指针最大的问题在于它不携带任何所有权信息。没有人知道当前这个指针背后，到底还有谁在引用这个对象。传统C++项目解决这个问题靠的是定规矩，比如“这个模块只管创建，那个模块负责释放”，但规矩在跨模块、跨线程、跨进程的复杂调用链里很容易被打破。于是智能指针成了必然选择，它把“谁负责释放”这件最难的事交给编译器，靠引用计数自动完成。

1.2 为什么有标准库智能指针还不用

C++11之后标准库提供了shared_ptr和weak_ptr，理论上能覆盖大部分场景。可Android在C++11普及之前就已经建立了一套RefBase体系，而且系统代码规模极其庞大，迁移成本根本不是一个小工程。更重要的是，Android这套智能指针有一些标准库替代不了的设计点。

最典型的差异是引用计数的存储方式。shared_ptr的控制块是独立的堆上结构，与对象本身分离；而Android的sp要求在对象内部嵌入一套计数信息，也就是对象必须继承RefBase。这样做的好处是对象和计数永远在一起，缓存局部性好，也方便系统在对象生命周期结束时做一些自动清理动作。Binder框架正是依赖这种设计来联动服务端对象的强弱引用状态。

另外，Android对“弱引用提升”的需求比普通应用强烈得多。Binder回调、观察者模式、跨进程代理绑定这些场景，经常需要一个不增加引用计数的“观察位”，等真正要用的时候再尝试提升为强引用。wp的存在就是为了满足这个需求，而且提升时机、失败判定都做得很细。标准库weak_ptr当然也能做类似的事，但在Android整个生态里，把这套逻辑内建到RefBase里，跟系统组件配合起来更顺畅。

1.3 认识几个主角：RefBase、sp、wp、LightRefBase

简单梳理一下这套智能指针家族的关系。RefBase是所有需要被sp管理的对象的基类，它内部维护了强弱两套引用计数。sp是强引用智能指针，作用类似shared_ptr；wp是弱引用智能指针，作用类似weak_ptr；LightRefBase是RefBase的轻量版本，只有强引用计数，没有弱引用能力，适合那些生命周期非常简单、不想背弱引用包袱的对象。

一个对象如果希望被Android智能指针体系管理，通常要继承RefBase。sp持有对象时会自动增加强引用计数，析构时自动减少；wp持有对象时会增加弱引用计数，但它不保证对象仍然活着，想通过wp拿到可用的sp，必须走promote流程。这套设计与标准库虽然表面上相似，但底层行为有差异，后面章节会详细拆解。

实际源码里还会看到很多单独用sp 声明变量的情况，比如Framework服务端的Binder对象、Surface、BufferQueue消费者等，几乎都是这套体系。理解这几个基础类型之间的关系，再看这些代码就不会一头雾水。

2. 核心机制拆解：sp、wp 的引用计数与 promote 提升

2.1 RefBase内部强弱计数模型

RefBase对象内部不是简单维护一个int，而是维护了一个weakref_type内部对象。这个内部对象管理两个计数器：mStrong是强引用计数，mWeak是弱引用计数，再加上一个生命周期策略标志mFlags。可以把这个内部对象想象成贴在对象身上的一个“控制面板”，sp每持有一份就点亮一个强引用灯，wp每持有一份就点亮一个弱引用灯。

mFlags用于控制对象在什么条件下可以析构。默认情况是OBJECT_LIFETIME_STRONG，意思是只要强引用计数降到0，对象就立刻析构，不管还有没有弱引用。另一种常用策略是OBJECT_LIFETIME_WEAK，这种情况下强引用降为0时对象不急着销毁，而是等弱引用计数也降为0再销毁。这个设计让对象可以在危险期被wp临时“赎”回来，也就是promote成功，这是标准库weak_ptr做不到的。

生命周期策略一般在构造函数里调用extendObjectLifetime来设置。这个机制对解决一些特别复杂的异步场景很有用，但也容易埋雷——如果对象长期处于弱引用被延迟析构的状态，资源释放会比你预想的晚，排查时不容易发现。所以在我看来，非必要不要改默认策略，保持和标准库行为一致反而省心。

2.2 sp的incStrong与decStrong执行路径

sp模板类内部只保存一个T* m_ptr。构造sp (new T())时，sp会调用m_ptr->incStrong(this)，把强引用计数加1；析构时调用m_ptr->decStrong(this)，把强引用计数减1。这一加一减的关系是所有引用计数逻辑的基础。

decStrong内部会检查强引用计数减到0之后，根据mFlags决定怎么处理。默认STRONG策略下，会直接delete这个RefBase对象。由于RefBase的析构是virtual，即便是通过基类指针触发delete，最终也会正确调用到真实子类的析构函数。这也是为什么很多RefBase子类会把析构函数声明为protected：外面不敢直接delete裸指针，但sp内部的decStrong却可以通过基类虚析构把对象干净地清掉。

sp还有一个容易被忽略的点：拷贝赋值不是摧毁旧指针就完事。当sp从别的sp拷贝过来时，要先对新的m_ptr做incStrong，再对旧的m_ptr做decStrong，顺序反了可能在新指针计数还没增加时就被另一个线程减到零销毁。实际Android实现里这部分会有对应的处理逻辑，但作为使用者，我们最好也养成“先加后减”的心智模型。

sp没有裸指针那么灵活，但正因为它把inc和dec都封装好了，才能做到“只要sp还活着，对象一定还活着”。用sp管理对象之后，最忌讳的就是再手动调用delete，那等于绕过了计数器，直接摧毁所有权机制，大概率引发双重释放。

2.3 wp的promote提升到底做了什么

wp内部不会直接调用incStrong，而是通过createWeak获取并操作weakref_type。wp只增加弱引用计数，不影响对象是否会被析构。要从wp安全拿回sp，必须调用promote。promote内部会尝试执行attemptIncStrong——这名字已经说明态度：只是“尝试”把强引用计数加上去，不一定成功。

attemptIncStrong会判断当前对象是否还有效。默认STRONG策略下，如果强引用计数已经是0，那说明对象已经析构，promote失败，返回空的sp；如果强引用计数还大于0，说明对象还活着，就把强引用计数加1并返回一个有效的sp。在WEAK策略下，即使强引用计数是0，只要弱引用还控制着对象，promote也可能成功，等于把对象从“待销毁”状态重新拉回“存活”状态。

所以wp.promote()返回的sp必须判空。很多新手把wp当普通shared_ptr用，以为它持有的对象肯定还在，结果promote返回空之后没有检查就直接调方法，照样崩溃。记住一个原则：wp是一个观察者，不是所有者，任何从观察者到所有者的转换都伴随着失败的可能。

2.4 Android智能指针与标准库的对照

shared_ptr和weak_ptr在绝大多数C++工程里已经是标配，Android这套体系也常被拿来跟标准库做对比。搞清楚它们的异同，能帮你判断自己手里的项目到底适合用哪套。

从功能上看，两套体系解决的问题高度重合。但Android这套与系统服务、Binder机制有天然耦合，比如Binder相关类本身就继承自RefBase，服务端常利用onLastStrongRef回调来做资源收尾。而标准库智能指针胜在通用和可移植，不依赖任何Android内部库。两种工具不是替代关系，更多是各就各位、各管一摊。

3. 实操演示：写一个基于 RefBase 的 native 模块

3.1 RefBase子类的基本定义规范

定义一个被智能指针管理的类，第一件事就是继承RefBase。下面是一个典型的例子，我会在主逻辑里展示怎么创建、传递、降级观察。注意析构函数我特意设为protected，这是为了避免外部直接delete裸指针。

#include <utils/RefBase.h> #include <utils/StrongPointer.h> #include <utils/WeakPointer.h> #include <cstdio> class Worker : public RefBase { public: Worker() { printf("Worker created\n"); // 默认生命周期策略是OBJECT_LIFETIME_STRONG } void doWork() { printf("Worker is working, strong count = %d\n", getStrongCount()); } protected: // 设置为protected，防止外部直接delete virtual ~Worker() { printf("Worker destroyed\n"); } private: int mJobId = 0; };

构造函数我这里保持public，方便直接new出来交给sp；析构保护起来，让所有销毁动作统一从sp的decStrong路径走。getStrongCount()是RefBase提供的接口，可用来观察当前强引用计数，适合调试时打日志。incref和decref相关的调用都不用自己操心，交给sp和wp就行。

3.2 创建、拷贝与传参：始终围绕sp操作

最正确的创建方式是先裸new，然后立刻交到sp变量里。

sp<Worker> worker = new Worker(); worker->doWork();

这一步的语义是：对象刚诞生的那一刻，所有权就交给sp了。从此时起，不要再想着手动delete这个Worker指针，也不要把裸指针存到某个成员变量里长期保管。后面如果想在另一个函数里使用同一个对象，直接传递sp即可，sp拷贝时引用计数会自动增加，函数结束时自动减少。

参数传递时如果不需要修改对象所有权，可以用const sp<Worker>&传入，避免无谓的拷贝计数开销；如果函数需要异步持有这个对象，再按值传递sp，让它持有一份强引用直到任务完成。这个习惯跟shared_ptr几乎一致，熟悉标准库的人很容易迁移。

有一点需要特别提醒：不要用一个裸指针去初始化两个sp。比如同一个原始指针，一处交给sp1，另一处又交给sp2，两个sp都认为自己是唯一所有者，引用计数会混乱。虽然两个sp各自递增递减不会立刻崩，但一旦中间又混入原始指针delete，问题就会瞬间爆发。

3.3 wp弱引用的正确姿势：缓存、回调、观察者

弱引用最常见的用途是缓存和回调。A模块想记住B模块的对象，但又不希望自己的持有导致B模块永远无法释放，这时就该用wp而不是sp。下面的例子模拟了一个数据消费者持有生产者的弱引用，每次要用的时候才promote。

class Consumer : public RefBase { public: void setProducer(const sp<Worker>& producer) { mProducer = producer; // wp从sp构造，只增加弱引用 } void refresh() { sp<Worker> locked = mProducer.promote(); if (locked != nullptr) { locked->doWork(); } else { printf("producer is already gone\n"); } } private: wp<Worker> mProducer; };

Consumer持有的是wp，所以即使生产者被外界所有强引用释放，Consumer也不会阻止它析构。refresh每次调用时都尝试promote，成功说明生产者还活着，可以安全执行任务；失败则说明对象已销毁，做一次降级处理，比如重新获取生产者或者上报一个空状态。

这里promote返回的空sp必须判断。我不止一次见过有同学拿到空sp直接解引用，在release版本上出现极其隐蔽的native crash。另外，wp本身也可以用来判断两个观察者是否指向同一个对象，这在管理缓存表时很方便。

3.4 与Binder、回调和跨模块对象打交道的常见要点

在AOSP的Framework层，Binder相关的核心类普遍继承自RefBase，例如服务端的Binder服务类自身。服务对象被创建后，通常用sp先持有一份，保证在客户端仍持有binder引用时服务对象不会提前销毁。当服务端最后一个强引用被释放，RefBase会回调onLastStrongRef，这是做资源收尾的好位置。

在跨模块传递对象时，尽量不要暴露裸指针接口。对外接口定义成sp 入参或返回值，内部一致使用智能指针管理。这样能保证所有使用者都走同一套引用计数规则。如果必须传递裸指针给某个系统接口，出参时要格外小心，调用方只把它当成“借用”，不得擅自delete，更不得在异步场景长期保存。

回调场景也一样。如果某个回调对象可能晚于生命周期结束，回调的持有方最好使用wp保存观察者。等到事件真的到来时再promote，如果已经失效就跳过回调，避免通过悬空裸指针调用一个已经析构的对象。这比让观察者自己清理注册状态要省心得多。

3.5 工程配置与依赖小提示

在AOSP或系统源码环境里，使用这套智能指针不需要额外下载依赖，直接#include <utils/RefBase.h>这类头文件即可。模块的Android.bp或Android.mk里通常已经链了libutils，sp和wp都在这条依赖链里。如果你只是写一个独立NDK库，并不依赖Android系统组件，那我建议直接使用标准库智能指针，省去对环境依赖的管理成本。

还有一种情况是只想在NDK里用到sp的便利性，但又不想链接整套libutils。这个时候可以选择只包含头文件性质的LightRefBase，或者干脆封装一个轻量引用计数基类。这个取舍取决于你的项目约束，没有绝对答案。多数非AOSP项目，用标准库是更稳妥的选择。

4. 避坑实录：sp/wp 常见的几类崩溃与排查经验

4.1 栈上对象和手动delete引发的release问题

最常见的一个低级错误就是把栈上对象交给sp管理。比如：

Worker stackWorker; sp<Worker> spWorker(&stackWorker);

sp析构时会调用decStrong，最终走到delete。可stackWorker不是堆上new出来的，delete一个栈对象会让进程直接崩溃，而且崩溃现场往往非常奇怪。RefBase体系的设计意图非常明确：对象只在堆上创建，然后交给sp。在栈上使用智能指针管理，从一开始就违背了基本原则，别这么用。

另一个高频错误是sp已经接管对象所有权之后，又手动delete原始指针：

Worker* raw = new Worker(); sp<Worker> spWorker(raw); delete raw; // 错误：所有权已转移给sp

delete raw之后，spWorker内部还保留着这个裸指针，等到spWorker析构时第二次delete，双重释放就来了。这类错误在code review阶段其实很容易发现，只要看到“有关系指向RefBase子类的裸指针出参”就要拉响警报。

我的建议是：凡是继承RefBase的对象，所有权语义必须高度明确。谁第一次把它包进sp，谁就是这一生命周期的接管者。其他模块想用，拿到的是sp或wp副本，而不是裸指针。如果确实为了系统接口不得不裸指针过一道，那也必须是“借用”语义，用完立刻丢弃，禁止保存。

4.2 多线程场景下的引用计数黑锅

很多人以为sp的计数是原子的，就认为整个对象都线程安全了。这部分要区分清楚：计数本身的增减确实是原子操作，但对象内部的数据成员不会自动得到保护。两个线程同时调用同一个Worker的方法修改成员，仍然需要自己加锁，sp并不会帮你做任何同步。

还有一种更隐蔽的情况：一个线程正在通过sp调用对象方法，另一个线程把最后一个sp释放了，导致对象析构。这时候前一个线程的方法还在执行中，可能会访问到free之后的内部状态。要避免这类问题，通常要把“正在使用”的持续时间段持有一份sp变量，而不是在使用期间只靠裸指针临时取数。

// 推荐：在整个使用区间持有sp auto locked = mWeakRef.promote(); if (locked != nullptr) { locked->doWork(); // 这里locked一直有效 }

有些系统代码会用一个sp局部变量来“钉住”对象，这个方法本身没问题，关键是要保证提升成功以及作用域覆盖完整。如果业务逻辑非常复杂，对象内部多个成员需要协同访问，还是老老实实加锁，再合理安排锁的粒度，别指望智能指针能解决并发正确性。

4.3 promote空指针和时间窗问题

wp.promote()返回空sp的时机常常被低估。对象可能在promote调用之前已经析构，也可能在检查完之后、真正使用前被迫析构，后者是一个经典的时间窗问题。标准库weak_ptr也面临类似的竞争窗口，没有彻底消灭的办法，只能通过使用方式降低风险。

在实际项目中，我习惯把“promote + 使用”放进同一个临界区或者同一段执行流内，尽量不跨线程异步操作提升后的sp。如果某个任务必须在另一个线程执行，就把提升后的sp作为任务参数传递进去，让任务自己持有强引用，而不是在任务内部再对wp做二次promote。二次promote意味着从“强引用”又退回“弱引用”，把生命周期风险重新引入进来。

排查这类问题时，一个比较直接的方法是打印每次promote前后的强引用计数。结合日志判断对象是在哪个阶段消失的。如果崩溃现场出现在wp对应的类析构里，还可以检查是不是有谁把wp对象跨越线程边界传递了，导致内部计数器状态孤岛。

4.4 实用排查手段：日志、计数与Sanitizer

排查native智能指针问题，我通常按顺序做三件事。第一，在构造和析构函数里加上唯一的LOG，确认对象创建和销毁的时机。引用计数问题最怕看不出“谁多delete了一次”，有了构造析构日志，至少能先确认对象是否提前释放。

第二，需要时打印getStrongCount()，观察强引用数量变化是否符合预期。如果某个操作之后计数没有回到0，说明还有sp残留，往上游找谁多保存了一份；如果计数出现负数，那基本可以肯定是有人手动delete或者栈对象参与导致计数错乱。

第三，针对疑似内存越界或悬空，用AddressSanitizer/LSan这类工具在调试版本上跑一遍。AOSP的模块支持配置sanitizer，跑起来往往能直接定位到错误的释放点。不过要注意，智能指针本身会生成很多临时对象，Sanitizer报出的某些“heap-use-after-free”可能需要结合构造析构日志一起看，才能判断是真实问题还是误报。

5. 选型建议：sp/wp 与标准库智能指针怎么搭档

5.1 一张表快速决策

如果项目代码已经跑在AOSP环境，你写的是系统组件、Framework服务、HIDL/AIDL实现或与Binder深度耦合的模块，那么跟随原生生态用sp/wp是最省事的选择。好处是跟系统库的接口风格一致，也方便利用RefBase内置的弱引用和生命周期回调。

如果项目是独立NDK库、纯算法、SDK或者可移植中间件，那么标准库智能指针更合适。它不依赖libutils，跨平台编译顺畅，团队成员也更容易用shared_ptr的心智去理解代码。强行在独立库中引入sp，反而会带来依赖和交付上的麻烦。

5.2 新代码的推荐姿势

新写AOSP模块时，我自己的习惯是：核心生命周期对象默认继承RefBase，用sp持有；外部间接引用全部用wp；对外API只暴露sp和wp，隐藏一切裸指针。这样虽然代码里多了一些类型约束，但长期维护成本显著降低，因为对象的生老病死都统一走同一套规则。

如果是纯业务native库，我反而会尽量控制动态内存的暴露面。能用unique_ptr解决的，就不用shared_ptr；能用值语义解决的，就不搞指针。引用计数是工具而不是教条，一个对象如果确实只有唯一所有者，强行上shared_ptr或sp都只会引入不必要的复杂度。

还有一个值得推荐的做法：在RefBase子类里重写onLastStrongRef回调，把对外资源的释放、监听器的注销放进去。这样就算多个模块引用同一个对象，也不需要靠某个人记着“最后一把锁在哪里释放”，系统自动在最合适的时机通知你做收尾。这个方法在管理缓存、窗口句柄、文件描述符时尤其好用。

结合我自己这些年写native代码的经验，最实用的一条建议是：不要混合记忆两套智能指针的细节，写系统模块时干脆忘掉shared_ptr那套；写独立库时忘了sp和省事。其实它们的内核都是“计数+适时释放”，区别主要在控制块的位置和生命周期策略的灵活度上。真正决定代码稳不稳的，永远是所有权边界是否清晰，是不是有人偷偷拿了裸指针又把责任推给智能指针。写代码的时候心里先画一张生命周期图，再决定手上该拿sp、wp还是unique_ptr，大多内存问题都不会出现。