从 Android 回调到 C 接口：函数指针 + void* self 的一次彻底理解

一、为什么学 C 回调会觉得“抽象”？

很多 Android / Java 开发者在第一次接触 C 回调时，都会被下面这种代码劝退：

typedef struct { void (*open)(void* self); void (*close)(void* self); } Ops;

看起来既不像函数，也不像类，更不像接口。

但当我真正理解它之后，才发现：

这套写法，本质上和 Android 的接口回调是完全一致的，只是语法层面更底层。

二、从 Android 的 setOnClickListener 说起

在 Android 中，我们非常熟悉这种写法：

button.setOnClickListener(listener);

这里发生了三件事：

1. listener是一个对象实例

2. 它实现了OnClickListener接口

3. 系统在合适的时机回调：

listener.onClick(view);

关键点在于：

• 系统并不关心 listener 的具体类型

• 只关心：你有没有实现规定的方法

三、C 语言里没有接口，那怎么办？

C 语言没有：

• class
• interface
• this

但系统级代码同样需要：

• 回调
• 解耦
• 多态

于是 C 选择了一种“手工实现接口”的方式：

struct + 函数指针

四、Ops：C 里的“接口定义”

typedef struct { void (*open)(void* self); void (*close)(void* self); } Ops;

这段代码不是在实现逻辑，而是在做一件事：

定义一组能力约定（接口）

可以直接在脑子里翻译成 Java：

interface Ops { void open(); void close(); }

区别只有一个：

• Java 有隐式this
• C 需要显式传self

五、void* self 是什么？

void* self的本质是：

C 版的 this / Context / 上下文对象

因为 C 没有对象模型，所以：

• 谁在调用

• 状态在哪里

都必须由调用方手动传入。

void file_open(void* self) { File* f = (File*)self; printf("%d\n", f->fd); }

这和 Java 里的：

void open() { System.out.println(this.fd); }

在“角色”上是完全等价的。

六、接口是怎么“绑定实现”的？

很多人会问：

file_open为什么会成为open的实现？

答案不在函数名，而在赋值：

Ops file_ops = { .open = file_open, .close = file_close };

这一刻发生了绑定：

• file_ops.open指向file_open

• file_ops.close指向file_close

之后的调用：

file_ops.open(&f);

等价于：

file_open(&f);

七、file_ops 是什么角色？

可以非常准确地说：

file_ops是一个“接口实例 / 方法表 / 回调对象”

它就像 Android 里的：

OnClickListener listener = new MyClickListener();

只不过在 C 里：

• 方法表（Ops）

• 对象实例（self）

被拆开保存。

八、一句话总结构成完整模型

**C 的接口回调 = struct（接口定义）

• 函数指针（方法）

• void* self（this / Context）**

这并不是“奇怪的 C 写法”，而是：

在没有语言级支持的情况下，手工实现的面向对象与接口机制。

九、写在最后

当我把 C 的这套回调模型和 Android 的接口机制对齐之后，才真正意识到：

语言不同，但工程思想是完全相通的。