由浅入深，从基本概念到源码解析，带你全面掌握 React Native 在 iOS 平台的开发与应用

一、什么是 React Native？为什么选择它？

1.1 从 Hybrid 到 React Native

移动开发经历了从纯原生（Native）到 Hybrid（WebView）再到跨平台框架的演进：

React Native (RN) 由 Meta 于 2015 年开源，核心理念是：用 JavaScript 编写逻辑，用原生组件渲染 UI，而不是在 WebView 中渲染。

1
2

传统 Hybrid：    JS/HTML → WebView 渲染 → 间接调用原生 API
React Native：   JS/React → 虚拟 DOM → 原生组件（UILabel、UIView 等）直接渲染

1.2 为什么 iOS 开发者要学 React Native？

• 业务需要：公司采用 RN 做跨端，需要维护/扩展原生能力
• 原生桥接：RN 依赖大量原生模块（相机、蓝牙、支付等），需要 iOS 侧配合开发
• 性能优化：理解 RN 与原生通信机制，才能做性能调优和问题排查
• 新架构：新架构大量使用 C++、JSI，与 iOS 底层结合更紧密

1.3 RN 与 Flutter 的简要对比

二、核心概念与架构

2.1 三层架构概览

1
2
3
4
5
6
7
8
9
10
11
12
13
14

┌─────────────────────────────────────────────────────────┐
│                    JavaScript 层                         │
│   React 组件、业务逻辑、状态管理、事件处理                 │
└──────────────────────────┬──────────────────────────────┘
                           │ Bridge / JSI
┌──────────────────────────▼──────────────────────────────┐
│                    C++ 层（新架构）                       │
│   JSI、Fabric 渲染、TurboModules 调度                     │
└──────────────────────────┬──────────────────────────────┘
                           │ FFI / Objective-C++
┌──────────────────────────▼──────────────────────────────┐
│                    Native 层（iOS）                       │
│   UIKit、系统 API、自定义原生模块                         │
└─────────────────────────────────────────────────────────┘

2.2 关键概念

2.3 旧架构 vs 新架构

三、环境搭建与项目创建

3.1 环境要求

• Node.js：建议 LTS 版本（18+）
• Xcode：最新稳定版
• CocoaPods：gem install cocoapods
• Watchman（可选）：brew install watchman，用于文件监听

3.2 创建新项目

1
2
3
4
5
6
7
8
9
10
11

# 使用 React Native CLI
npx @react-native-community/cli init MyApp

# 进入 iOS 目录
cd MyApp/ios

# 安装 CocoaPods 依赖
pod install

# 返回根目录，启动 Metro
cd .. && npx react-native start

另开终端运行 iOS：

1
2
3

npx react-native run-ios
# 或指定模拟器
npx react-native run-ios --simulator="iPhone 15"

3.3 项目结构（iOS 侧）

1
2
3
4
5
6
7
8
9
10
11
12
13
14

MyApp/
├── ios/
│   ├── MyApp/                 # 原生 iOS 工程
│   │   ├── AppDelegate.mm     # 入口，加载 RN 根视图
│   │   ├── Info.plist
│   │   └── ...
│   ├── Podfile                # CocoaPods 配置
│   ├── Podfile.lock
│   └── MyApp.xcworkspace      # 用此打开工程
├── android/
├── src/                       # JS 源码
├── node_modules/
├── package.json
└── metro.config.js

3.4 AppDelegate 与 RN 加载

典型的 AppDelegate.mm 中加载 RN 的流程：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

#import <React/RCTBundleURLProvider.h>
#import <React/RCTRootView.h>

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
  NSURL *jsCodeLocation = [[RCTBundleURLProvider sharedSettings] jsBundleURLForBundleRoot:@"index"];
  
  RCTRootView *rootView = [[RCTRootView alloc] initWithBundleURL:jsCodeLocation
                                                      moduleName:@"MyApp"
                                               initialProperties:nil
                                                   launchOptions:launchOptions];
  
  self.window.rootViewController = [[UIViewController alloc] init];
  self.window.rootViewController.view = rootView;
  [self.window makeKeyAndVisible];
  return YES;
}

RCTRootView 负责加载 JS Bundle、创建 Bridge、挂载 React 组件树。

四、JS 与 Native 通信原理

4.1 旧架构：Bridge 模型

旧架构下，JS 与 Native 通过 异步 Bridge 通信：

1
2
3
4
5
6
7

JS 层发起调用
    │
    ├─ 将参数序列化为 JSON
    │
    ├─ 通过 Bridge 发送到 Native 队列
    │
    └─ Native 解析 JSON，执行对应模块方法，再序列化结果回传 JS

特点：

• 异步：所有跨端调用都是异步的
• 序列化：参数和返回值需要 JSON 序列化，有性能开销
• 全量加载：所有 Native Modules 在启动时注册

4.2 旧架构模块注册流程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

// 1. 实现 RCTBridgeModule 协议
@interface MyNativeModule : NSObject <RCTBridgeModule>
@end

@implementation MyNativeModule

RCT_EXPORT_MODULE();  // 导出模块名，默认类名

RCT_EXPORT_METHOD(getDeviceId:(RCTPromiseResolveBlock)resolve
                  reject:(RCTPromiseRejectBlock)reject) {
  NSString *id = [[UIDevice currentDevice] identifierForVendor].UUIDString;
  resolve(id);
}

@end

JS 端调用：

1
2
3
4

import { NativeModules } from 'react-native';
const { MyNativeModule } = NativeModules;

const id = await MyNativeModule.getDeviceId();

4.3 新架构：JSI 直接调用

JSI 允许 JavaScript 直接持有 C++ 对象的引用，无需经过 Bridge 序列化：

1
2
3
4
5
6
7
8

// C++ 侧：通过 JSI 暴露方法
jsi::Function getDeviceId = jsi::Function::createFromHostFunction(
  runtime,
  jsi::PropNameID::forAscii(runtime, "getDeviceId"),
  0,
  [](jsi::Runtime& rt, const jsi::Value&, const jsi::Value*, size_t) {
    return jsi::String::createFromUtf8(rt, getNativeDeviceId());
  });

JS 可直接同步调用，无需 Promise 包装。

五、新架构：JSI、Fabric、TurboModules

5.1 JSI（JavaScript Interface）

JSI 是 C++ 实现的薄封装层，让 JS 引擎（Hermes/JSC）能够：

• 调用 C++ 函数
• 读取/写入 C++ 对象属性
• 在 C++ 中执行 JS 回调

1
2
3
4
5
6
7
8
9

// 简化示意：HostObject 暴露给 JS 的对象
class DeviceModule : public jsi::HostObject {
  jsi::Value get(jsi::Runtime& rt, const jsi::PropNameID& name) override {
    if (name.utf8(rt) == "getDeviceId") {
      return jsi::Function::createFromHostFunction(...);
    }
    return jsi::Value::undefined();
  }
};

5.2 Fabric 渲染管线

Fabric 将 React 的渲染逻辑从各平台分别实现，统一到 C++：

1
2
3
4
5
6
7
8
9
10
11
12
13

React 组件树
    │
    ▼
Shadow Tree（C++ 中的布局树）
    │
    ▼
布局计算（Yoga）
    │
    ▼
提交到原生层（Mount）
    │
    ▼
iOS UIView 创建/更新

优势：减少跨 Bridge 的序列化、支持同步布局、更好的并发与优先级调度。

5.3 TurboModules

TurboModules 的特性：

• 懒加载：只在首次被 JS 引用时初始化
• 类型安全：通过 Codegen 从 TypeScript 定义生成 C++ 和 ObjC 代码
• 同步能力：通过 JSI 可实现同步调用

定义原生模块的规范（新架构）：

1
2
3
4
5
6
7
8
9
10

// NativeMyModule.ts (Codegen 规范)
import type { TurboModule } from 'react-native';
import { TurboModuleRegistry } from 'react-native';

export interface Spec extends TurboModule {
  getDeviceId(): Promise<string>;
  multiply(a: number, b: number): number;
}

export default TurboModuleRegistry.getEnforcing<Spec>('MyNativeModule');

六、原生模块开发（Native Modules）

6.1 旧架构：RCT_EXPORT_MODULE

完整示例：实现一个获取设备信息的原生模块。

Objective-C：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

// DeviceInfoModule.h
#import <React/RCTBridgeModule.h>

@interface DeviceInfoModule : NSObject <RCTBridgeModule>
@end

// DeviceInfoModule.m
#import "DeviceInfoModule.h"
#import <React/RCTLog.h>
#import <UIKit/UIKit.h>

@implementation DeviceInfoModule

RCT_EXPORT_MODULE(DeviceInfo)

RCT_EXPORT_METHOD(getDeviceInfo:(RCTPromiseResolveBlock)resolve
                  reject:(RCTPromiseRejectBlock)reject) {
  dispatch_async(dispatch_get_main_queue(), ^{
    NSDictionary *info = @{
      @"model": [[UIDevice currentDevice] model],
      @"systemVersion": [[UIDevice currentDevice] systemVersion],
      @"name": [[UIDevice currentDevice] name],
    };
    resolve(info);
  });
}

@end

JavaScript：

1
2
3
4
5
6
7
8
9
10
11
12

import { NativeModules } from 'react-native';

const { DeviceInfo } = NativeModules;

async function loadDeviceInfo() {
  try {
    const info = await DeviceInfo.getDeviceInfo();
    console.log(info);
  } catch (e) {
    console.error(e);
  }
}

6.2 新架构：TurboModule + Swift

新架构推荐用 Swift 实现业务逻辑，用 ObjC++ 做 JSI 胶水层。

Swift 实现：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

// DeviceInfoModule.swift
import Foundation

@objc(DeviceInfoModule)
class DeviceInfoModule: NSObject {
  @objc
  static func requiresMainQueueSetup() -> Bool {
    return false
  }
  
  @objc
  func getDeviceInfo(_ resolve: @escaping RCTPromiseResolveBlock,
                     reject: @escaping RCTPromiseRejectBlock) {
    let info: [String: Any] = [
      "model": UIDevice.current.model,
      "systemVersion": UIDevice.current.systemVersion
    ]
    resolve(info)
  }
}

通过 RCT_EXTERN_MODULE 导出给 ObjC：

1
2
3
4
5
6
7
8
9

// DeviceInfoModule.m（桥接）
#import <React/RCTBridgeModule.h>

@interface RCT_EXTERN_MODULE(DeviceInfoModule, NSObject)

RCT_EXTERN_METHOD(getDeviceInfo:(RCTPromiseResolveBlock)resolve
                  reject:(RCTPromiseRejectBlock)reject)

@end

6.3 事件发送：从 Native 到 JS

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

// 在原生模块中
#import <React/RCTEventEmitter.h>

@interface MyModule : RCTEventEmitter <RCTBridgeModule>
@end

@implementation MyModule

RCT_EXPORT_MODULE()

- (NSArray<NSString *> *)supportedEvents {
  return @[@"onScanResult"];
}

- (void)sendScanResult:(NSString *)result {
  [self sendEventWithName:@"onScanResult" body:@{@"result": result}];
}

@end

1
2
3
4
5
6

import { NativeEventEmitter, NativeModules } from 'react-native';

const emitter = new NativeEventEmitter(NativeModules.MyModule);
emitter.addListener('onScanResult', (event) => {
  console.log(event.result);
});

七、原生 UI 组件（Native UI Components）

7.1 使用 ViewManager 封装 UIView

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

// MyCustomViewManager.h
#import <React/RCTViewManager.h>

@interface MyCustomViewManager : RCTViewManager
@end

// MyCustomViewManager.m
#import "MyCustomViewManager.h"
#import "MyCustomView.h"

@implementation MyCustomViewManager

RCT_EXPORT_MODULE(MyCustomView)

- (UIView *)view {
  return [[MyCustomView alloc] init];
}

RCT_EXPORT_VIEW_PROPERTY(title, NSString)
RCT_EXPORT_VIEW_PROPERTY(onPress, RCTBubblingEventBlock)

@end

1
2
3
4
5

// MyCustomView.h
@interface MyCustomView : UIView
@property (nonatomic, copy) NSString *title;
@property (nonatomic, copy) RCTBubblingEventBlock onPress;
@end

7.2 JS 侧使用

1
2
3
4
5
6
7
8
9
10
11
12

import { requireNativeComponent } from 'react-native';

const MyCustomView = requireNativeComponent('MyCustomView');

export default function Screen() {
  return (
    <MyCustomView
      title="Hello"
      onPress={(e) => console.log(e.nativeEvent)}
    />
  );
}

7.3 新架构：Fabric 组件

新架构下，通过 Codegen 定义 Props 和事件，生成 C++ 与各平台代码，实现类型安全和更好的性能。

八、源码解析

8.1 初始化流程（iOS）

1
2
3
4
5
6
7
8
9
10
11
12

main()
  └─ UIApplicationMain
       └─ AppDelegate didFinishLaunchingWithOptions
            └─ RCTRootView initWithBundleURL:moduleName:...
                 ├─ 创建 RCTBridge
                 │    ├─ 加载 JavaScript Bundle
                 │    ├─ 初始化 JS 引擎（Hermes/JSC）
                 │    ├─ 注册所有 Native Modules
                 │    └─ 执行 JS 入口（AppRegistry.runApplication）
                 │
                 └─ 创建 RCTRootContentView
                      └─ 挂载 React 根组件，触发首次渲染

8.2 Bridge 核心结构（旧架构）

1
2
3
4
5
6
7
8
9
10
11
12

// 简化示意
@interface RCTBridge : NSObject
@property (nonatomic, strong) RCTBridge *batchedBridge;  // 实际执行 Bridge
@end

// 模块调用流程
// JS: NativeModules.DeviceInfo.getDeviceInfo()
//   -> __callFunction(moduleName, methodName, args)
//   -> 序列化为 JSON，通过 RCTBridge 发送
//   -> Native: RCTModuleData 根据 moduleName 找到模块实例
//   -> 反序列化参数，invoke 对应方法
//   -> 结果序列化回传 JS

8.3 新架构关键路径

• JSI：ReactCommon/jsi/，提供 jsi::Runtime、HostObject 等
• Fabric：ReactCommon/react/renderer/，Shadow Tree、Mount、Component 定义
• TurboModules：ReactCommon/react/nativemodule/，模块注册与调用

可参考官方仓库：
https://github.com/facebook/react-native

九、实战示例

9.1 调用系统分享

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

// ShareModule.m
RCT_EXPORT_METHOD(share:(NSDictionary *)options
                  resolve:(RCTPromiseResolveBlock)resolve
                  reject:(RCTPromiseRejectBlock)reject) {
  dispatch_async(dispatch_get_main_queue(), ^{
    NSString *title = options[@"title"] ?: @"";
    NSString *url = options[@"url"] ?: @"";

    UIActivityViewController *activityVC = [[UIActivityViewController alloc]
      initWithActivityItems:@[title, [NSURL URLWithString:url]]
      applicationActivities:nil];

    UIViewController *rootVC = [UIApplication sharedApplication]
      .keyWindow.rootViewController;
    [rootVC presentViewController:activityVC animated:YES completion:nil];
    resolve(@YES);
  });
}

9.2 封装原生 TabBar

在 RN 中嵌入 UITabBarController 的容器，通过 Native Module 控制 Tab 切换，实现与原生 TabBar 一致的外观和动效。

9.3 列表性能优化：FlashList

1
2
3
4
5
6
7
8
9
10
11
12
13

import { FlashList } from '@shopify/flash-list';

function ProductList({ data }) {
  const renderItem = ({ item }) => <ProductCard item={item} />;

  return (
    <FlashList
      data={data}
      renderItem={renderItem}
      estimatedItemSize={100}
    />
  );
}

FlashList 使用按需渲染和复用，比 FlatList 更适合长列表场景。

十、实际项目中的应用案例

10.1 电商 App：商品详情混合栈

• Native：顶部 Banner 轮播、视频播放、复杂动效
• RN：评价列表、推荐列表、加购/下单逻辑

通过 RCTRootView 嵌入到 UIViewController 的指定区域，实现「上原生、下 RN」的混合页面。

10.2 金融 App：安全键盘

输入密码时使用 Native 自定义键盘（避免 RN 侧键盘被截屏/录屏），通过 Native Module 将输入结果回传 JS：

1
2
3
4
5
6
7
8

RCT_EXPORT_METHOD(showSecureKeyboard:(RCTPromiseResolveBlock)resolve
                  reject:(RCTPromiseRejectBlock)reject) {
  SecureKeyboardViewController *vc = [[SecureKeyboardViewController alloc]
    initWithCompletion:^(NSString *pin) {
      resolve(pin);
    }];
  [self presentVC:vc];
}

10.3 地图与 LBS

地图、路径规划、定位等使用 Native SDK，通过 Native UI Component 和 Native Module 暴露给 RN，兼顾性能与功能完整性。

10.4 OTA 热更新

将打包好的 JS Bundle 下发到本地，启动时优先加载本地 Bundle，实现不发版即可更新业务逻辑（需注意各应用市场的合规要求）。

十一、常见问题与最佳实践

11.1 主线程与 UI 更新

原生模块中涉及 UI 的操作必须回到主线程：

1
2
3

dispatch_async(dispatch_get_main_queue(), ^{
  [self presentViewController:vc animated:YES completion:nil];
});

11.2 避免内存泄漏

• 使用 RCTEventEmitter 时正确实现 invalidate
• Block 中使用 weakSelf 避免循环引用
• 大对象及时释放，避免长期持有

11.3 调试技巧

1
2
3
4
5
6
7
8

# 查看 Metro 日志
npx react-native start

# 真机调试
npx react-native run-ios --device

# 查看原生日志
# Xcode -> Debug -> Open System Log，或使用 Console.app

11.4 性能建议

• 长列表使用 FlashList 或优化 FlatList 的 getItemLayout
• 复杂动画考虑 react-native-reanimated
• 新项目尽量启用新架构（Fabric + TurboModules）
• 图片使用 FastImage 或自定义 Native 图片组件做缓存

11.5 启用新架构

在 ios/Podfile 中：

1

ENV['RCT_NEW_ARCH_ENABLED'] = '1'

执行 pod install 后重新编译。

十二、总结

React Native 在 iOS 上的核心价值是：用 React 生态统一业务逻辑，用原生能力保证体验与性能。理解 Bridge/JSI、Fabric、TurboModules 的演进，有助于在混合栈项目中做出更合适的架构与实现选择。

从基础概念到实战应用，系统梳理 iOS 架构演进之路

一、基础概念

1.1 为什么需要架构优化？

随着业务迭代，单体 App 会遇到诸多问题：

1.2 三种架构模式辨析

1
2
3
4
5
6
7
8
9
10
11
12

┌─────────────────────────────────────────────────────────────────┐
│                        架构演进路径                               │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│   单体架构 ──► 模块化 ──► 组件化 ──► 插件化                        │
│      │           │          │           │                         │
│      │           │          │           │                         │
│      ▼           ▼          ▼           ▼                         │
│   按功能拆分   物理隔离   独立仓库     运行时动态加载                 │
│   代码目录     组件解耦   CocoaPods    热更新/按需加载               │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

模块化（Modularization）

• 定义：按业务功能将代码拆分为独立的「模块」，每个模块有清晰的边界
• 特点：逻辑划分、职责单一，通常仍在同一工程内
• 粒度：中等，如「用户模块」「订单模块」「支付模块」

组件化（Componentization）

• 定义：将模块进一步拆分为可独立编译、可复用的「组件」，通过依赖注入解耦
• 特点：物理隔离、独立仓库、独立编译、协议解耦
• 粒度： finer，如「登录组件」「分享组件」「埋点组件」

插件化（Pluginization）

• 定义：组件可动态加载、热更新，主 App 与插件解耦到运行时
• 特点：运行时动态、按需加载、可热修复
• 粒度：动态 Bundle/Framework

二、模块化原理与实践

2.1 模块化的核心原则

1. 单一职责：每个模块只负责一块业务
2. 接口隔离：模块间通过 Protocol 通信，不暴露实现细节
3. 依赖倒置：依赖抽象（协议）而非具体实现

2.2 目录结构示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

MyApp/
├── App/                    # 主工程壳
│   ├── AppDelegate
│   └── Main
├── Modules/
│   ├── ModuleA_User/       # 用户模块
│   │   ├── Services/
│   │   ├── Views/
│   │   └── Models/
│   ├── ModuleB_Order/      # 订单模块
│   └── ModuleC_Payment/    # 支付模块
├── Common/                 # 公共基础库
│   ├── Network/
│   ├── Utils/
│   └── BaseClasses/
└── Router/                 # 路由层（模块间通信枢纽）

2.3 模块间通信：Protocol + 依赖注入

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

// 1. 定义协议（放在公共层或 Protocol 模块）
protocol UserServiceProtocol: AnyObject {
    func getCurrentUser() -> User?
    func logout()
}

// 2. 模块实现协议
// UserModule/UserService.swift
class UserService: UserServiceProtocol {
    func getCurrentUser() -> User? { /* ... */ }
    func logout() { /* ... */ }
}

// 3. 依赖注入（App 启动时或 ServiceLocator）
class ServiceLocator {
    static let shared = ServiceLocator()
    var userService: UserServiceProtocol?
}

// 4. 其他模块通过协议调用
class OrderViewController: UIViewController {
    var userService: UserServiceProtocol?
    
    func showUserInfo() {
        guard let user = userService?.getCurrentUser() else { return }
        // ...
    }
}

三、组件化原理与实现

3.1 组件化架构图

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

                ┌──────────────────┐
                │     App Shell    │
                │  (主工程/壳工程)   │
                └────────┬─────────┘
                         │
          ┌──────────────┼──────────────┐
          │              │              │
          ▼              ▼              ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│  用户组件    │ │  订单组件    │ │  支付组件    │
│  (Pod)      │ │  (Pod)      │ │  (Pod)      │
└──────┬──────┘ └──────┬──────┘ └──────┬──────┘
       │               │               │
       └───────────────┼───────────────┘
                       │
                ┌──────▼──────┐
                │ 路由/中间层  │
                │ (URL/Mediator)│
                └──────┬──────┘
                       │
                ┌──────▼──────┐
                │  基础组件    │
                │ (网络/缓存/UI)│
                └─────────────┘

3.2 路由方案对比

3.3 Mediator 模式源码实现

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

// CTMediator 核心实现（简化版，源自 Casa 的 CTMediator）
import UIKit

public class CTMediator: NSObject {
    public static let shared = CTMediator()
    
    // 缓存 Target 实例，避免重复创建
    private var targetCache = [String: NSObject]()
    
    /// 通过 Target-Action 调用
    /// - Parameters:
    ///   - targetName: 目标类名，如 "Order"
    ///   - actionName: 方法名，如 "orderListViewController"
    ///   - params: 参数字典
    public func perform(target targetName: String,
                        action actionName: String,
                        params: [String: Any]? = nil) -> Any? {
        let targetClassString = "Target_\(targetName)"
        let actionString = "Action_\(actionName):"
        
        // 1. 获取 Target 类
        guard let targetClass = NSClassFromString(targetClassString) as? NSObject.Type else {
            return nil
        }
        
        // 2. 获取或创建 Target 实例
        var target = targetCache[targetClassString]
        if target == nil {
            target = targetClass.init()
            targetCache[targetClassString] = target
        }
        
        // 3. 通过 NSInvocation 或 perform 调用
        let selector = NSSelectorFromString(actionString)
        guard (target?.responds(to: selector)) ?? false else {
            return nil
        }
        
        return target?.perform(selector, with: params)?.takeUnretainedValue()
    }
}

// ========== 组件端：Order 模块 ==========
// 在 Order 组件内定义 Target_Order
class Target_Order: NSObject {
    @objc func Action_orderListViewController(_ params: [String: Any]?) -> UIViewController {
        let userId = params?["userId"] as? String ?? ""
        let vc = OrderListViewController(userId: userId)
        return vc
    }
}

// ========== 调用端：任意模块 ==========
let vc = CTMediator.shared.perform(
    target: "Order",
    action: "orderListViewController",
    params: ["userId": "12345"]
) as? UIViewController
navigationController?.pushViewController(vc!, animated: true)

3.4 依赖关系设计

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

# Podfile 示例
target 'MainApp' do
  # 业务组件（同层，互不依赖）
  pod 'UserModule'
  pod 'OrderModule'
  pod 'PaymentModule'
  
  # 中间层
  pod 'Mediator'
  pod 'Mediator/Order'   # Category，扩展 Order 的便捷方法
  pod 'Mediator/User'
end

# 各业务组件的 Podspec 只依赖基础库
# OrderModule.podspec
Pod::Spec.new do |s|
  s.name = 'OrderModule'
  s.dependency 'Mediator'
  s.dependency 'BaseNetwork'
  s.dependency 'BaseUI'
end

关键点：业务组件之间不直接依赖，都通过 Mediator 间接通信。

四、插件化原理与实现

4.1 插件化的应用场景

• 热更新：修复线上 Bug 无需发版
• 按需加载：减少包体积，冷启动只加载核心
• 动态能力：运营活动插件、A/B 测试模块
• 多端复用：同一套插件可被主 App、Widget、Watch 加载

4.2 iOS 插件化技术选型

注意：苹果审核禁止下载执行任意代码，真正「从网络下载插件并执行」的纯插件化在 App Store 场景不可行。实际做法多为：预置多个 Framework/Bundle，运行时按需加载，或通过 JS 引擎 + 离线包 实现业务热更新。

4.3 动态 Framework 加载示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

import UIKit

class PluginManager {
    static let shared = PluginManager()
    private var loadedBundles: [String: Bundle] = [:]
    
    /// 加载动态 Framework（需预置在 App 内）
    func loadPlugin(named pluginName: String) -> Bool {
        guard let path = Bundle.main.path(
            forResource: pluginName,
            ofType: "framework",
            inDirectory: "Frameworks"
        ) else { return false }
        
        guard let bundle = Bundle(path: path), bundle.load() else {
            return false
        }
        
        loadedBundles[pluginName] = bundle
        return true
    }
    
    /// 通过反射获取插件内的类并调用
    func instantiateViewController(fromPlugin pluginName: String,
                                   className: String) -> UIViewController? {
        guard let bundle = loadedBundles[pluginName] ?? {
            loadPlugin(named: pluginName) ? loadedBundles[pluginName] : nil
        }() else { return nil }
        
        guard let pluginClass = bundle.classNamed(className) as? UIViewController.Type else {
            return nil
        }
        
        return pluginClass.init()
    }
}

// 使用
if PluginManager.shared.loadPlugin(named: "ActivityPlugin") {
    let vc = PluginManager.shared.instantiateViewController(
        fromPlugin: "ActivityPlugin",
        className: "ActivityPlugin.ActivityViewController"
    )
    present(vc!, animated: true)
}

4.4 基于 Runtime 的模块注册

1
2
3
4
5
6
7
8
9
10
11
12

// 插件自注册：通过 +load 在加载时注册到中心
// PluginModule.m
+ (void)load {
    [[PluginRegistry shared] registerPlugin:@"Activity"
                                withClass:[ActivityPlugin class]];
}

// PluginRegistry 管理所有插件
@interface PluginRegistry : NSObject
- (void)registerPlugin:(NSString *)name withClass:(Class)cls;
- (id)createInstanceForPlugin:(NSString *)name;
@end

五、BeeHive 框架源码解析

BeeHive 是阿里开源的 iOS 模块化框架，结合了 Protocol 注册 与 Module 生命周期。

5.1 架构概览

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

┌────────────────────────────────────────────────────────┐
│                    BHContext (上下文)                    │
│  - 配置信息、环境变量、共享数据                           │
└────────────────────────────────────────────────────────┘
                          │
┌─────────────────────────┴─────────────────────────────┐
│                  BHModuleManager                       │
│  - 管理 Module 注册、加载、生命周期                      │
└────────────────────────────────────────────────────────┘
                          │
        ┌─────────────────┼─────────────────┐
        ▼                 ▼                 ▼
┌──────────────┐  ┌──────────────┐  ┌──────────────┐
│ BHService    │  │ BHModule     │  │ BHConfig     │
│ (协议-实现)   │  │ (模块基类)   │  │ (配置)        │
└──────────────┘  └──────────────┘  └──────────────┘

5.2 核心类：BHModuleManager

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

// 简化版核心逻辑
@implementation BHModuleManager

- (void)registerDynamicModule:(Class)moduleClass {
    if ([moduleClass conformsToProtocol:@protocol(BHModuleProtocol)]) {
        BHModuleInfo *info = [[BHModuleInfo alloc] initWithModuleClass:moduleClass];
        [self.modules addObject:info];
        [self.modules sortUsingComparator:^NSComparisonResult(BHModuleInfo *m1, BHModuleInfo *m2) {
            return m1.priority < m2.priority;  // 按优先级排序
        }];
    }
}

- (void)triggerEvent:(NSInteger)eventType {
    for (BHModuleInfo *info in self.modules) {
        id<BHModuleProtocol> instance = [info moduleInstance];
        switch (eventType) {
            case BHMSetupEvent:
                [instance modSetUp:nil];
                break;
            case BHMInitEvent:
                [instance modInit:nil];
                break;
            case BHMSplashEvent:
                [instance modSplash:nil];
                break;
            // ... 更多生命周期事件
        }
    }
}

@end

5.3 Protocol 注册与查找

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

// BHServiceManager：Protocol -> 实现类 映射
- (void)registerService:(Protocol *)protocol implClass:(Class)implClass {
    NSString *key = NSStringFromProtocol(protocol);
    self.services[key] = implClass;
}

- (id)createService:(Protocol *)protocol {
    Class implClass = self.services[NSStringFromProtocol(protocol)];
    return [[implClass alloc] init];
}

// 使用
@protocol UserServiceProtocol <NSObject>
- (User *)currentUser;
@end

// 注册
[[BHServiceManager sharedManager] registerService:@protocol(UserServiceProtocol)
                                       implClass:[UserServiceImpl class]];

// 获取
id<UserServiceProtocol> service = [[BHServiceManager sharedManager] createService:@protocol(UserServiceProtocol)];

六、实际项目应用案例

6.1 某电商 App 组件化拆分

1
2
3
4
5
6
7
8
9
10
11

MainApp (壳工程)
├── HomeModule          # 首页
├── ProductModule       # 商品详情
├── CartModule          # 购物车
├── OrderModule         # 订单
├── UserModule          # 用户中心
├── PaymentModule       # 支付
├── ShareModule         # 分享（可复用）
├── AnalyticsModule     # 埋点（可复用）
├── Mediator            # 路由中间层
└── BasePods            # 网络/缓存/UI 基础库

收益：

• 编译时间：全量 8min → 单模块 1.5min
• 4 个业务线可并行开发，Git 冲突减少 70%
• ShareModule、AnalyticsModule 复用到多个 App

6.2 路由设计实战

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

// Mediator+Order.swift (Mediator 的 Category)
extension CTMediator {
    func orderListViewController(userId: String) -> UIViewController? {
        return perform(target: "Order",
                       action: "orderListViewController",
                       params: ["userId": userId]) as? UIViewController
    }
    
    func orderDetailViewController(orderId: String) -> UIViewController? {
        return perform(target: "Order",
                       action: "orderDetailViewController",
                       params: ["orderId": orderId]) as? UIViewController
    }
}

// 调用处：无需关心 Order 模块内部实现
if let vc = CTMediator.shared.orderListViewController(userId: "123") {
    navigationController?.pushViewController(vc, animated: true)
}

6.3 解耦实践：避免循环依赖

错误示例：

1
2

OrderModule -> UserModule (获取用户信息)
UserModule  -> OrderModule (跳转订单列表)

形成循环依赖，无法独立编译。

正确做法：

1
2

OrderModule -> Mediator
UserModule  -> Mediator

需要「用户信息」时，Order 通过 Mediator 获取 UserServiceProtocol；需要「跳转订单」时，User 通过 Mediator 获取 OrderListViewController。Mediator 依赖各模块的 Target 类（可通过 Category 按需引入）。

七、最佳实践与注意事项

7.1 模块拆分原则

• 高内聚低耦合：模块内聚度高，模块间依赖少
• 按业务边界拆分：参考 DDD 的 Bounded Context
• 基础组件下沉：网络、缓存、日志等抽成独立 Pod
• 渐进式演进：先模块化再组件化，避免一步到位导致成本过高

7.2 常见坑与规避

7.3 架构演进路线图

1
2
3
4
5
6
7
8
9
10
11
12
13
14

Phase 1: 模块化
├── 按功能拆分目录
├── 引入 Protocol 解耦
└── 建立 ServiceLocator

Phase 2: 组件化
├── 拆分为独立 Pod
├── 引入 Mediator/路由
└── 独立编译、独立开发

Phase 3: 插件化（可选）
├── 非核心模块动态加载
├── 预置多套业务 Bundle
└── 或引入 RN/Flutter 做动态化

八、总结

架构没有银弹，需结合团队规模、业务复杂度、迭代节奏选择合适方案。建议从模块化起步，随着复杂度提升再逐步演进到组件化，插件化则按实际需求谨慎引入。

参考资源

• CTMediator - Casa Taloyum
• BeeHive - Alibaba
• iOS 应用架构谈 组件化方案 - Casa
• 蘑菇街 App 的组件化之路

由浅入深，从基本概念到源码解析，带你全面掌握 iOS 热更新的原理、方案与实战理、方案与实战

一、什么是热更新？为什么需要它？

1.1 从「发版周期」说起

传统原生 iOS 开发的痛点：

• 审核周期长：App Store 审核通常需要 1～3 天，紧急 Bug 无法及时修复
• 版本割裂：用户更新率有限，线上可能同时存在多个旧版本
• 迭代成本高：每次改动都要重新打包、提审、等待上线

热更新（Hot Update） 的核心诉求是：在不发新版本、不通过 App Store 审核的前提下，动态更新应用逻辑与资源。

1.2 热更新的分类

1.3 热更新能解决什么问题？

• 紧急 Bug 修复：线上崩溃、逻辑错误，可快速下发补丁
• 业务快速迭代：活动页、营销逻辑，无需等审核
• 灰度与回滚：小范围验证后全量，出问题可秒级回滚

二、核心原理

2.1 动态执行：热更新的基础

iOS 支持多种「运行时执行代码」的方式，这是热更新的技术前提：

1
2
3
4
5
6
7

┌─────────────────────────────────────────────────────────────┐
│                    热更新技术栈层次                           │
├─────────────────────────────────────────────────────────────┤
│  应用层      │  下发 JS/Lua/配置 → 解释执行 / 加载资源         │
│  中间层      │  JavaScriptCore / Lua VM / 自研解释器          │
│  系统层      │  Runtime、dlopen、performSelector 等           │
└─────────────────────────────────────────────────────────────┘

不同方案对「动态执行」的依赖程度不同，也决定了其合规性。

2.2 两类热更新思路

2.3 Apple 3.3.2 条款与审核边界

Apple 开发者协议 3.3.2 明确规定：

应用不得包含、提供或使用未包含在应用中的可执行代码的下载、安装或执行机制。

被严格禁止的：

• 下载并执行任意原生代码（如通过 dlopen、dlsym 动态加载）
• 使用可调用原生 API 的脚本引擎（如 JSPatch 通过 JS 调用 performSelector:、修改 IMP）
• 绕过审核、改变应用主要功能或目的的动态能力

允许的例外：

• 使用 WebKit 或 JavaScriptCore 执行脚本
• 前提：不改变应用的主要功能或目的，与提交版本及宣传描述相符
• 典型：React Native 的 JS Bundle 热更新、游戏内 Lua 脚本（在引擎容器内运行）

核心差异：Apple 禁止的是「能绕过审核、调用私有 API、实质改变应用功能」的方案，而非热更新本身。使用系统 JS 引擎、仅更新业务逻辑（不修改原生层）的方案，在合理范围内通常可接受。

三、主流方案概览

3.1 方案对比

3.2 选型建议

四、React Native OTA 热更新

4.1 基本原理

RN 的 UI 与业务逻辑运行在 JavaScript 中，而 JS 可由 JavaScriptCore（或 Hermes）在运行时执行。因此，只需将新的 JS Bundle 下发到设备，启动时优先加载该 Bundle，即可实现热更新，无需修改原生代码。

1
2
3
4
5
6
7
8

┌─────────────────────────────────────────────────────────────┐
│                    RN 热更新流程                              │
├─────────────────────────────────────────────────────────────┤
│  1. 服务端：打包 JS Bundle（含业务逻辑）                       │
│  2. 下发：通过 HTTP/CDN 将 Bundle 下发到客户端                 │
│  3. 客户端：存储到本地（如 Document 目录）                     │
│  4. 启动：RCTBridge 优先加载本地 Bundle，而非打包进 App 的     │
└─────────────────────────────────────────────────────────────┘

4.2 CodePush 架构

CodePush 是微软推出的 RN 热更新方案，由三部分组成：

版本策略：支持 semver 约束，例如 ^1.2.3 表示 >=1.2.3 <2.0.0 的原生版本可收到该更新。

4.3 集成示例

1
2
3

# 安装
npm install --save react-native-code-push
cd ios && pod install

1
2
3
4
5
6
7
8
9
10
11

// AppDelegate.m - 指定 Bundle 加载路径
#import <CodePush/CodePush.h>

- (NSURL *)sourceURLForBridge:(RCTBridge *)bridge
{
#if DEBUG
  return [[RCTBundleURLProvider sharedSettings] jsBundleURLForBundleRoot:@"index"];
#else
  return [CodePush bundleURL];  // 生产环境从 CodePush 获取
#endif
}

1
2
3
4
5
6
7

// 检查更新
import codePush from 'react-native-code-push';

codePush.sync({
  updateDialog: { title: '发现新版本' },
  installMode: codePush.InstallMode.IMMEDIATE,
});

4.4 自建 OTA 简要思路

若不使用 CodePush，可自建：

1. 服务端：提供接口，根据 appVersion、binaryVersion 返回可用的 Bundle 信息（URL、hash、是否强制）
2. 客户端：启动时请求接口，若有新版本则下载到本地
3. 加载：修改 RCTRootView 的 bridge 初始化，优先从本地路径加载 JS Bundle

五、JSPatch 原理与源码解析（历史与教育意义）

⚠️ JSPatch 已被 Apple 明确禁止，此处仅作原理与源码层面的学习参考。

5.1 核心思想

JSPatch 通过 JavaScript 调用 Objective-C，利用 OC 的 Runtime 动态性，实现：

1. 用 JS 写「补丁逻辑」
2. 下发 JS 到客户端
3. 在 JavaScriptCore 中执行
4. JS 通过桥接层调用 OC Runtime，替换方法实现（IMP）

5.2 JS 调用 OC 的底层机制

OC 是「消息型」语言，方法调用本质是 objc_msgSend(receiver, selector, ...)。JSPatch 的做法是：

• JS 侧：调用 require('UIView').alloc().init()
• 桥接层：将 UIView、alloc、init 等字符串传给 OC
• OC 侧：通过 NSClassFromString、class_getInstanceMethod 等 Runtime API 获取类和方法，用 objc_msgSend 或 NSInvocation 完成调用

1
2
3
4
5
6
7
8
9
10
11

JS: UIView.alloc().init()
       │
       ▼
JPEngine: 解析调用链 → 获取 Class、SEL
       │
       ▼
Runtime: objc_msgSend([UIView class], @selector(alloc))
         objc_msgSend(allocResult, @selector(init))
       │
       ▼
返回 OC 对象给 JS（封装为 JPBoxing 等结构）

5.3 方法替换（热修复）实现

热修复的关键是「替换方法的 IMP」：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

// 伪代码：JSPatch 方法替换思路
// 原方法：- (void)originalMethod;
// 新实现：在 JS 中定义，通过桥接调用

static void (^jsImplementation)(id, ...) = ...; // 从 JS 传过来的 block

IMP newIMP = imp_implementationWithBlock(^(id self, ...) {
    // 调用 JS 定义的逻辑
    jsImplementation(self, ...);
});

// 替换
Method m = class_getInstanceMethod(cls, @selector(originalMethod));
method_setImplementation(m, newIMP);

5.4 为何被禁止

JSPatch 能让 JS 间接调用任意 OC 方法，包括：

• performSelector:
• class_replaceMethod、method_setImplementation
• 私有 API、系统内部方法

这相当于 绕过了 App Store 审核，可动态改变应用行为，因此被 Apple 明确列入违规。

六、TTDFKit / TTPatch 与 libffi

6.1 简介

TTDFKit（原 TTPatch）是基于 libffi 的 iOS 热修复方案，不依赖 JSPatch，但能力类似：

• 方法替换、动态创建方法
• 添加属性、支持 Block
• 支持 JavaScript 脚本下发

6.2 libffi 的作用

libffi（Foreign Function Interface）用于在运行时根据函数签名动态调用 C 函数。OC 方法本质上也是 C 函数（带 self、_cmd 等参数），通过 libffi 可以：

1. 根据 NSMethodSignature 得到参数类型、返回值类型
2. 构造 ffi_cif（调用约定）
3. 使用 ffi_call 调用目标 IMP

从而实现「用动态生成的逻辑替换原方法」。

6.3 合规性说明

TTDFKit 同样具备「动态修改原生方法」的能力，在正式上架 App Store 的包中使用的合规风险与 JSPatch 类似，更适用于企业内部或内测分发场景。

七、实战示例：RN 自建 OTA

7.1 服务端接口设计（简化）

1
2
3
4
5
6
7
8

// GET /api/ota/check?platform=ios&version=1.2.3&build=10
{
  "hasUpdate": true,
  "downloadUrl": "https://cdn.example.com/bundle/1.2.3.10.jsbundle",
  "hash": "abc123",
  "forceUpdate": false,
  "minVersion": "1.2.0"
}

7.2 客户端核心逻辑（示例）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

// OTAManager.m
- (void)checkUpdate {
  NSString *url = [NSString stringWithFormat:
    @"https://api.example.com/ota/check?platform=ios&version=%@&build=%@",
    appVersion, buildNumber];
  // 发起请求，解析 hasUpdate、downloadUrl、forceUpdate
  // 若 hasUpdate，则下载到 Document/OTA/bundle.js
}

- (NSURL *)bundleURL {
  NSString *otaPath = [self otaBundlePath];
  if ([[NSFileManager defaultManager] fileExistsAtPath:otaPath]) {
    return [NSURL fileURLWithPath:otaPath];
  }
  return [[NSBundle mainBundle] URLForResource:@"main" withExtension:@"jsbundle"];
}

7.3 启动时加载

1
2
3
4

// AppDelegate.m
- (NSURL *)sourceURLForBridge:(RCTBridge *)bridge {
  return [[OTAManager shared] bundleURL];
}

八、实际项目中的应用案例

8.1 电商 App：活动页热更新

场景：大促活动页面布局、规则频繁调整，无法每次发版。

方案：使用 React Native 搭建活动页，通过 CodePush 下发 JS Bundle。活动开始前发布新版本，用户打开即可看到最新逻辑，无需等 App Store 审核。

效果：活动页迭代周期从 1～3 天缩短到几分钟，支持灰度与秒级回滚。

8.2 金融 App：合规前提下的热更新

场景：需要快速修复展示类 Bug（如文案错误、接口字段变更），但不能修改核心交易逻辑。

方案：

• 交易、支付等核心流程保持纯原生，不热更
• 非核心页面（资讯、活动、设置）采用 RN，通过 OTA 更新
• 严格控制热更范围，符合「不改变应用主要功能」的审核边界

8.3 游戏：Lua 热更新

场景：Unity / Unreal / Cocos 等引擎，游戏逻辑用 Lua 编写。

方案：Lua 脚本存在服务端，启动时或进入场景时下载到本地，由引擎内嵌的 Lua VM 执行。不涉及原生代码动态替换，符合平台规则。

8.4 企业内包：JSPatch 替代方案

场景：内部分发、不通过 App Store，需要紧急修复原生 Bug。

方案：使用 TTDFKit 或 BuglyHotfix，下发 JS 补丁，替换有问题的 OC 方法。需注意仅用于内部分发场景，避免用于正式上架版本。

九、最佳实践与注意事项

9.1 合规优先

• 上架 App Store 的应用：优先使用 RN OTA、CodePush 等脚本热更新，避免 JSPatch 类方案
• 热更范围：尽量限制在业务逻辑、UI 展示，不触及支付、权限等敏感能力
• 文档与描述：确保应用功能与审核描述一致，避免「隐藏能力」引起拒审

9.2 版本与兼容

• 使用 语义化版本 约束可更新范围，避免旧版本收到不兼容的 Bundle
• 做好 灰度：先小流量验证，再全量
• 设计 回滚：保留上一版本 Bundle，出错时快速切回

9.3 安全与校验

• 对 Bundle 做 哈希校验，防止篡改
• 使用 HTTPS 下发，避免中间人攻击
• 敏感逻辑不宜完全依赖热更，核心安全校验应留在原生

9.4 性能与体验

• 启动时异步检查更新，不阻塞首屏
• 大 Bundle 可做 差分更新，减少下载量
• 明确 强制更新 与 静默更新 策略，平衡体验与覆盖率

十、总结

热更新能显著提升迭代效率，但必须在 合规、安全、可维护 的前提下使用。理解原理与边界，才能做出正确的技术选型与实现。

由浅入深，从基本概念到源码解析，带你全面理解 iOS 事件循环机制

一、什么是 RunLoop？

1.1 从 Event Loop 说起

通常，一个线程一次只能执行一个任务，任务完成后线程就会退出。但在 GUI 应用中，我们需要一种机制：线程能够随时处理事件或消息，并且在空闲时不会退出。这种机制称为 Event Loop（事件循环）。

1
2
3
4
5
6
7

function main
    initialize()
    while message != quit
        message := get_next_message()
        process_message(message)
    end while
end function

Event Loop 的核心问题是：

• 如何管理事件/消息
• 如何让线程在没有任务时休眠，避免 CPU 空转
• 如何在事件到来时唤醒线程处理

1.2 RunLoop 是什么？

RunLoop 是苹果在 OSX/iOS 上对 Event Loop 的实现。它是一个对象，负责：

• 管理需要处理的事件/消息
• 提供入口函数执行「接收消息 → 等待 → 处理」的循环
• 在没有事件时让线程休眠，有事件时唤醒并分发处理

RunLoop 从 Input Sources 和 Timer Sources 接收事件，然后在线程中执行对应的 Handler。

1.3 NSRunLoop 与 CFRunLoop

苹果提供了两层 API：

日常开发多用 NSRunLoop，底层和性能相关则直接用 CFRunLoop。

二、RunLoop 与线程

2.1 一一对应关系

• RunLoop 和线程是 一一对应 的
• 每个线程（含主线程）都有唯一的 RunLoop
• RunLoop 在 首次获取 时创建，线程结束时 销毁
• 只能在 对应线程内部 获取该线程的 RunLoop（主线程除外）

1
2
3
4
5

// 获取当前线程的 RunLoop
let runLoop = RunLoop.current

// 获取主线程 RunLoop（任意线程可调用）
let mainRunLoop = RunLoop.main

2.2 主线程 vs 子线程

• 主线程：应用启动时，主线程 RunLoop 自动创建并运行
• 子线程：默认不启动 RunLoop，需要主动调用 run 才会进入事件循环

1
2
3
4
5
6
7

// 主线程 RunLoop 自动运行，无需手动启动
// 子线程 RunLoop 默认不运行
Thread.detachNewThread {
    let runLoop = RunLoop.current
    runLoop.add(Port(), forMode: .default)  // 必须有 source，否则 run 会立即退出
    runLoop.run()
}

三、核心组件

3.1 Run Loop Source（事件源）

RunLoop 从两类 Source 接收事件：

1
2

Source0：用户事件、自定义事件 → 需外部调用 CFRunLoopSourceSignal 标记
Source1：系统 Port 事件 → 内核可主动唤醒线程

3.2 Run Loop Timer（定时器）

Timer 本质是 基于 Port 的 Source，所有 Timer 共用同一个「Mode Timer Port」。常见实现如 NSTimer、CADisplayLink。

3.3 Run Loop Observer（观察者）

Observer 不处理事件，而是 观察 RunLoop 的状态变化，可监控以下活动：

1
2
3
4
5
6
7
8
9

// CFRunLoopActivity 定义
typedef CF_OPTIONS(CFOptionFlags, CFRunLoopActivity) {
    kCFRunLoopEntry         = (1UL << 0),  // 即将进入 Loop
    kCFRunLoopBeforeTimers  = (1UL << 1),  // 即将处理 Timer
    kCFRunLoopBeforeSources = (1UL << 2),  // 即将处理 Source
    kCFRunLoopBeforeWaiting = (1UL << 5),  // 即将进入休眠
    kCFRunLoopAfterWaiting  = (1UL << 6),  // 刚从休眠中唤醒
    kCFRunLoopExit          = (1UL << 7),  // 即将退出 Loop
}

四、Run Loop Mode

4.1 什么是 Mode？

Mode 是 RunLoop 的「工作模式」。一个 RunLoop 包含多个 Mode，每个 Mode 下有各自的 Source、Timer、Observer。同一时刻 RunLoop 只运行在一个 Mode 下，只处理该 Mode 里的 Source/Timer/Observer。

这样可以把不同场景的事件隔离，例如：

• 默认模式下处理普通事件
• 滑动 ScrollView 时切到 UITrackingRunLoopMode，只处理触摸，保证滑动流畅

4.2 常见 Mode

NSRunLoopCommonModes 默认包含 NSDefaultRunLoopMode 和 UITrackingRunLoopMode。把 Timer/Source 加到 CommonModes，会在上述两种模式切换时都得到回调。

4.3 常见问题：Timer 滑动时失效

1
2
3
4
5
6
7
8

// 仅加入 DefaultMode：滑动 UITableView 时 Timer 暂停
let timer = Timer.scheduledTimer(withTimeInterval: 1.0, repeats: true) { _ in
    print("tick")
}
RunLoop.main.add(timer, forMode: .default)

// 加入 CommonModes：滑动时 Timer 继续触发
RunLoop.main.add(timer, forMode: .common)

4.4 数据结构示意

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

struct __CFRunLoopMode {
    CFStringRef _name;            // Mode 名称，如 @"kCFRunLoopDefaultMode"
    CFMutableSetRef _sources0;    // Source0 集合
    CFMutableSetRef _sources1;    // Source1 集合
    CFMutableArrayRef _observers; // Observer 数组
    CFMutableArrayRef _timers;    // Timer 数组
    ...
};

struct __CFRunLoop {
    CFMutableSetRef _commonModes;     // 标记为 Common 的 Mode 集合
    CFMutableSetRef _commonModeItems; // 加到 Common 的 Source/Timer/Observer
    CFRunLoopModeRef _currentMode;    // 当前 Mode
    CFMutableSetRef _modes;           // 所有 Mode
    ...
};

commonModeItems 会被自动同步到所有 Common Mode 中，这就是把 Timer 加到 .common 能解决滑动暂停的原因。

五、RunLoop 工作流程（源码级）

5.1 整体流程

CFRunLoopRun 的简化调用链：

1
2
3

void CFRunLoopRun(void) {
    CFRunLoopRunSpecific(CFRunLoopGetCurrent(), kCFRunLoopDefaultMode, 1.0e10, false);
}

核心逻辑在 CFRunLoopRunSpecific 里，内部是一个 do-while 循环，大致步骤如下：

5.2 核心源码流程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57

int CFRunLoopRunSpecific(runloop, modeName, seconds, stopAfterHandle) {
    CFRunLoopModeRef currentMode = __CFRunLoopFindMode(runloop, modeName, false);
    if (__CFRunLoopModeIsEmpty(currentMode)) return;  // Mode 为空则直接返回

    // 1. 通知 Observers：即将进入 Loop
    __CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopEntry);

    __CFRunLoopRun(runloop, currentMode, seconds, returnAfterSourceHandled) {
        do {
            // 2. 通知 Observers：即将处理 Timer
            __CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeTimers);

            // 3. 通知 Observers：即将处理 Source0
            __CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeSources);

            // 4. 执行被加入的 Block
            __CFRunLoopDoBlocks(runloop, currentMode);

            // 5. 处理 Source0
            sourceHandledThisLoop = __CFRunLoopDoSources0(runloop, currentMode, stopAfterHandle);
            __CFRunLoopDoBlocks(runloop, currentMode);

            // 6. 若有 Source1 就绪，处理 Source1 消息
            if (__Source0DidDispatchPortLastTime) {
                if (__CFRunLoopServiceMachPort(dispatchPort, &msg))
                    goto handle_msg;
            }

            // 7. 通知 Observers：即将进入休眠
            if (!sourceHandledThisLoop) {
                __CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeWaiting);
            }

            // 8. 调用 mach_msg 等待消息，线程休眠，直到被唤醒
            __CFRunLoopServiceMachPort(waitSet, &msg, ...);
            // 唤醒条件：Port 事件、Timer 到期、超时、手动唤醒

            // 9. 通知 Observers：刚刚被唤醒
            __CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopAfterWaiting);

        handle_msg:
            if (msg_is_timer) {
                __CFRunLoopDoTimers(runloop, currentMode, mach_absolute_time());
            } else if (msg_is_dispatch) {
                __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__(msg);  // GCD 主队列
            } else {
                __CFRunLoopDoSource1(runloop, currentMode, source1, msg);  // Source1
            }

            __CFRunLoopDoBlocks(runloop, currentMode);

        } while (retVal == 0);  // 根据 retVal 决定是否继续循环
    }

    // 10. 通知 Observers：即将退出 Loop
    __CFRunLoopDoObservers(rl, currentMode, kCFRunLoopExit);
}

5.3 流程简图

1
2
3
4
5
6

Entry → BeforeTimers → BeforeSources → DoBlocks → DoSources0
                                                    ↓
Exit  ← BeforeExit   ← AfterWaiting  ← mach_msg 等待
       ↑                           ↓
       └──────── handle_msg ───────┘
                 (Timer / Source1 / Dispatch)

六、基于 RunLoop 的系统功能

6.1 AutoreleasePool

主线程 RunLoop 中注册了两个 Observer，回调都是 _wrapRunLoopWithAutoreleasePoolHandler：

因此主线程上的事件回调、Timer 回调等都会在 AutoreleasePool 包裹下执行，一般无需手动创建。

6.2 事件响应链路

1. 硬件事件（触摸、按键等）→ IOKit 生成 IOHIDEvent
2. SpringBoard 接收，通过 Mach Port 转发给 App
3. 主线程 RunLoop 的 Source1 回调 __IOHIDEventSystemClientQueueCallback
4. 内部调用 _UIApplicationHandleEventQueue() 包装成 UIEvent
5. 经 hitTest、响应链，最终到达对应 Target-Action 或 touches 方法

6.3 手势识别

• _UIApplicationHandleEventQueue() 识别到手势时，会打断 touches 序列
• 将 UIGestureRecognizer 标记为待处理
• 在 kCFRunLoopBeforeWaiting 的 Observer _UIGestureRecognizerUpdateObserver 中统一执行手势回调

6.4 界面更新

• 调用 setNeedsLayout / setNeedsDisplay 后，视图被标记为待更新
• 在 kCFRunLoopBeforeWaiting 和 kCFRunLoopExit 的 Observer 中，Core Animation 执行实际布局和绘制

6.5 PerformSelector

performSelector:afterDelay: 和 performSelector:onThread: 内部都会创建 Timer 并加入对应线程的 RunLoop。若该线程没有 RunLoop 或 RunLoop 未运行，这些方法不会生效。

七、实战示例

7.1 常驻线程（如 AFNetworking）

子线程默认不跑 RunLoop，需要手动添加 Source 并 run：

1
2
3
4
5
6
7
8
9
10

class NetworkThread: Thread {
    override func main() {
        autoreleasepool {
            self.name = "AFNetworking"
            let runLoop = RunLoop.current
            runLoop.add(Port(), forMode: .default)  // 添加 Port 作为 Source，否则 run 会立即退出
            runLoop.run()
        }
    }
}

1
2
3
4
5
6
7
8
9

// AFNetworking 2.x 的经典实现
+ (void)networkRequestThreadEntryPoint:(id)__unused object {
    @autoreleasepool {
        [[NSThread currentThread] setName:@"AFNetworking"];
        NSRunLoop *runLoop = [NSRunLoop currentRunLoop];
        [runLoop addPort:[NSMachPort port] forMode:NSDefaultRunLoopMode];
        [runLoop run];
    }
}

7.2 使用 Observer 监控卡顿

通过观察主线程 RunLoop 状态，检测某个阶段耗时是否过长：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68

import UIKit

class RunLoopMonitor {
    private var observer: CFRunLoopObserver?
    private var semaphore: DispatchSemaphore
    private var timeout = true
    private let timeoutCount: Int = 5
    private var count = 0

    init() {
        semaphore = DispatchSemaphore(value: 0)
    }

    func start() {
        let activities: CFRunLoopActivity = [.beforeWaiting, .afterWaiting]
        var context = CFRunLoopObserverContext(
            version: 0,
            info: Unmanaged.passUnretained(self).toOpaque(),
            retain: nil,
            release: nil,
            copyDescription: nil
        )

        observer = CFRunLoopObserverCreate(
            kCFAllocatorDefault,
            activities.rawValue,
            true,
            0,
            { _, activity, info in
                guard let info = info else { return }
                let monitor = Unmanaged<RunLoopMonitor>.fromOpaque(info).takeUnretainedValue()
                monitor.handleObserverCallback(activity)
            },
            &context
        )

        CFRunLoopAddObserver(CFRunLoopGetMain(), observer, .commonModes)

        DispatchQueue.global().async { [weak self] in
            self?.monitor()
        }
    }

    private func handleObserverCallback(_ activity: CFRunLoopActivity) {
        if activity == .beforeWaiting || activity == .afterWaiting {
            count = 0
            timeout = false
        }
        semaphore.signal()
    }

    private func monitor() {
        while true {
            let result = semaphore.wait(timeout: .now() + 1)
            if result == .timedOut {
                if timeout {
                    count += 1
                    if count >= timeoutCount {
                        print("⚠️ 主线程可能发生卡顿")
                    }
                } else {
                    timeout = true
                    count = 0
                }
            }
        }
    }
}

7.3 在指定 RunLoop 模式执行任务

1
2
3
4
5
6
7
8

// 仅在 Default 模式执行
RunLoop.current.perform(#selector(doWork), target: self, argument: nil, order: 0, modes: [.default])

// 使用 CFRunLoop 添加 Block（iOS 10+）
CFRunLoopPerformBlock(CFRunLoopGetMain(), CFRunLoopMode.defaultMode.rawValue as CFString) {
    print("在 RunLoop 当前迭代中执行")
}
CFRunLoopWakeUp(CFRunLoopGetMain())

7.4 NSTimer 与 RunLoop

1
2
3
4
5
6
7
8
9
10
11
12
13

// scheduledTimer 会自动加入当前 RunLoop 的 Default 模式
let timer = Timer.scheduledTimer(withTimeInterval: 1.0, repeats: true) { _ in
    print("tick")
}

// 若在子线程使用，需确保 RunLoop 在运行
DispatchQueue.global().async {
    let timer = Timer.scheduledTimer(withTimeInterval: 1.0, repeats: true) { _ in
        print("tick")
    }
    RunLoop.current.add(timer, forMode: .default)
    RunLoop.current.run()  // 必须 run，否则 Timer 不会触发
}

八、常见面试要点

1. RunLoop 和线程的关系：一一对应，主线程自动运行，子线程需手动启动。
2. Source0 与 Source1：Source0 需手动标记；Source1 基于 Port，可主动唤醒。
3. Mode 的作用：隔离不同场景的事件，滑动时切换到 UITrackingRunLoopMode 保证流畅。
4. CommonModes：把 Timer/Source 加到 CommonModes 可在 Default 和 Tracking 下都收到回调。
5. AutoreleasePool 与 RunLoop：主线程在 Entry、BeforeWaiting、Exit 时自动 Push/Pop。
6. 卡顿监控思路：用 CFRunLoopObserver 监听主线程，结合超时判定卡顿。

九、参考

• Apple: Run Loops
• 楚权：Run Loop 原理详解
• ibireme：深入理解 RunLoop

由浅入深，从原理到源码，全面解析 JSPatch 的设计思想、实现机制与关键技术细节

一、JSPatch 是什么？

1.1 定位与目标

JSPatch 是一个 iOS 动态更新框架，由 bang590 开源。其核心能力是：在 App 内引入极小的引擎后，用 JavaScript 调用任意 Objective-C 接口，并可替换原生方法实现，从而实现：

• 热修复：下发 JS 脚本修复线上 Bug，无需发版、无需审核
• 动态能力：为项目动态添加模块或替换原生逻辑

1.2 与 Apple 审核政策的关系

⚠️ 重要说明：Apple 开发者协议 3.3.2 明确禁止「下载、安装或执行未包含在应用中的可执行代码」。JSPatch 通过 JS 间接调用 Runtime、替换方法 IMP，被认为绕过审核、改变应用行为，已被 Apple 明确禁止上架使用。
本文仅从原理分析、技术学习与架构设计角度展开，不鼓励在正式上架 App 中接入。

1.3 技术栈位置

1
2
3
4
5
6
7

┌─────────────────────────────────────────────────────────────┐
│                    JSPatch 技术栈层次                          │
├─────────────────────────────────────────────────────────────┤
│  JS 脚本层   │  require / defineClass / 业务补丁逻辑            │
│  桥接层      │  __c() 元函数、JPEngine、JPBoxing、类型转换      │
│  系统层      │  JavaScriptCore、Objective-C Runtime           │
└─────────────────────────────────────────────────────────────┘

二、基础原理：为什么 JS 能调用 OC？

2.1 根本原因：Objective-C 的动态性

JSPatch 能通过 JS 调用和改写 OC 方法的根本原因是：Objective-C 是动态语言。在 OC 中，类与方法的查找、调用、替换都在运行时通过 Objective-C Runtime 完成，而不是在编译期写死。

因此可以：

• 通过类名/方法名字符串反射得到类和方法
• 替换某个类的方法实现（IMP）
• 动态注册新类、添加方法

1
2
3
4
5
6
7
8
9
10
11
12
13
14

// 反射调用
Class class = NSClassFromString("UIViewController");
id vc = [[class alloc] init];
SEL sel = NSSelectorFromString("viewDidLoad");
[vc performSelector:sel];

// 替换方法实现
static void newViewDidLoad(id slf, SEL sel) {}
class_replaceMethod(class, @selector(viewDidLoad), (IMP)newViewDidLoad, "v@:");

// 动态注册类
Class cls = objc_allocateClassPair(superCls, "JPObject", 0);
class_addMethod(cls, selector, implement, typedesc);
objc_registerClassPair(cls);

结论：JSPatch 的基本原理就是——JS 把类名、方法名、参数等以字符串/结构化数据传给 OC，OC 通过 Runtime 接口完成「查找类 → 查找方法 → 调用/替换」。

2.2 整体数据流

1
2
3
4
5
6
7
8
9
10
11
12
13

JS: require('UIView').alloc().init()
         │
         ▼
   __c() 元函数：解析调用链，得到 类名/方法名/参数/调用者
         │
         ▼
   OC 桥接层：JPEngine 接收参数，类型转换，构造 NSInvocation
         │
         ▼
   Runtime：objc_msgSend / NSInvocation 调用，返回结果
         │
         ▼
   结果经 JPBoxing/包装后回传 JS，继续链式调用或使用

三、方法调用：从 JS 到 OC 的完整链路

下面以一段典型代码为例，拆解「JS 调用 OC」的五个环节：

1
2
3
4

require('UIView')
var view = UIView.alloc().init()
view.setBackgroundColor(require('UIColor').grayColor())
view.setAlpha(0.5)

涉及：require 机制 → JS 接口设计 → 消息传递 → 对象持有/转换 → 类型转换。

3.1 require：在 JS 中「引入」OC 类

require('UIView') 的作用是：在 JS 全局作用域 上创建一个同名变量，指向一个表示 OC 类的 JS 对象。该对象用 __clsName 保存类名，并标记「这是 OC 类」。

1
2
3
4
5
6
7
8

var _require = function(clsName) {
  if (!global[clsName]) {
    global[clsName] = {
      __clsName: clsName
    }
  }
  return global[clsName]
}

于是 require('UIView') 之后，全局有：

1

UIView === { __clsName: "UIView" }

后续 UIView.alloc() 等调用，都基于这个对象进行。

3.2 JS 接口设计：如何让 UIView.alloc() 不报错？

3.2.1 问题：JS 没有「未定义方法」的转发机制

在 JS 中，若对象没有 alloc 属性，调用 UIView.alloc() 会直接抛错。不像 OC/Lua/Ruby 有「方法缺失 → 转发」的机制。

早期思路是：在 require 时向 OC 要该类（及父类）的全部方法名，在 JS 对象上为每个方法名挂一个函数，函数内部再调 OC。这样 JS 上就有 alloc、init 等「真实存在」的属性。

问题在于：一个类就有几百个方法，还要沿继承链汇总，内存暴涨，且要维护 OC→JS 的方法列表同步，难以接受。

3.2.2 方案：正则替换 + __c() 元函数（关键优化）

不改变「JS 语法」，但在 OC 执行 JS 脚本之前，用正则把所有方法调用统一替换成对 __c() 的调用，从而在 JS 侧实现「任意方法名 → 统一入口」的转发：

1
2
3
4
5

// 替换前
UIView.alloc().init()

// 替换后（示意）
UIView.__c('alloc')().__c('init')()

再给 JS 的 Object.prototype 增加 __c 方法，使任意对象（类对象、实例对象）都能走到同一套逻辑：

1
2
3
4
5
6
7
8
9
10

Object.defineProperty(Object.prototype, '__c', {
  value: function(methodName) {
    if (!this.__obj && !this.__clsName) return this[methodName].bind(this);
    var self = this;
    return function() {
      var args = Array.prototype.slice.call(arguments);
      return _methodFunc(self.__obj, self.__clsName, methodName, args, self.__isSuper);
    };
  }
});

• 若调用者是 OC 类（有 __clsName）：把类名、方法名、参数传给 OC，由 OC 通过 Runtime 调类方法。
• 若调用者是 OC 实例（有 __obj）：把对象指针、方法名、参数传给 OC，调实例方法。

这样不需要在 JS 上枚举任何 OC 方法，内存占用大幅下降，是 JSPatch 中最重要的一步优化。

3.3 消息传递：JS 与 OC 如何互传数据？

OC 端在启动 JSPatch 时会创建 JavaScriptCore 的 JSContext，并在 context 上挂载 OC 实现的 Block/方法。JS 调这些方法时，参数和返回值会由 JavaScriptCore 自动在 JS 与 OC 类型之间转换（如 NSArray ↔ Array、NSString ↔ string、NSNumber ↔ number 等）。

因此，_methodFunc 只需把「类名 / 对象 / 方法名 / 参数列表」通过 context 上暴露给 JS 的函数传给 OC；OC 用 Runtime 完成调用后，再把返回值通过同一机制回传给 JS。

3.4 对象持有与转换：OC 对象在 JS 侧的表示

• 类对象：在 JS 里就是 { __clsName: "UIView" }，不涉及 OC 对象生命周期。
• 实例对象：OC 的 id 若直接以指针形式交给 JS，JS 无法「理解」这个指针，但可以再把它传回 OC。
  为了在 JS 里识别「这是一个 OC 实例」，OC 在把对象返回给 JS 前会做一层包装，例如：

1
2
3

static NSDictionary *_wrapObj(id obj) {
    return @{@"__obj": obj};
}

在 JS 侧就变成：

1

{ __obj: [OC 对象指针] }

这样在 __c() 里可以通过「是否有 __obj」判断调用者是 OC 实例，并取出 __obj 与方法名、参数一起传回 OC，完成实例方法调用。

对象生命周期：当 JS 侧有变量引用该包装对象时，OC 对象引用计数 +1；JS 侧释放后 -1，由 OC/JS 共同管理。

3.5 类型转换：参数与返回值的 OC 类型

OC 侧实际调用是通过 NSInvocation 完成的。要正确调用并拿到返回值，需要：

1. 根据 OC 方法的 NSMethodSignature 得到每个参数的类型，把 JS 传过来的对象（如 NSNumber、NSDictionary）转成对应类型（如 int、float、CGRect 等）再传入。
2. 根据返回值类型从 NSInvocation 取出返回值，再包装成 JS 可用的对象（或 JPBoxing 等）传回 JS。

例如 view.setAlpha(0.5)：JS 传的是 NSNumber，OC 根据 setAlpha: 的签名得知参数是 float，于是把 NSNumber 转为 float 再调用。

四、方法替换（热修复的核心）

4.1 基础思路：替换 IMP

OC 的类方法列表里，每个方法对应一个 Method（SEL + 类型编码 + IMP）。通过 Runtime 可以：

• 保留原 IMP：给类新增一个方法（如 ORIGviewDidLoad），其 IMP 指向原来的实现。
• 替换原方法的 IMP：把 viewDidLoad 的 IMP 改成自定义函数，在自定义函数里调 JS 传入的实现，并在需要时再调 ORIGviewDidLoad。

以替换 UIViewController 的 viewDidLoad 为例（无参数情况）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

static void viewDidLoadIMP(id slf, SEL sel) {
    // 从 JS 侧取到的函数并调用
    JSValue *jsFunction = ...;
    [jsFunction callWithArguments:nil];
}

Class cls = NSClassFromString(@"UIViewController");
SEL selector = @selector(viewDidLoad);
Method method = class_getInstanceMethod(cls, selector);
IMP imp = method_getImplementation(method);
char *typeDescription = (char *)method_getTypeEncoding(method);

// 原实现保留到 ORIGviewDidLoad
class_addMethod(cls, @selector(ORIGviewDidLoad), imp, typeDescription);
// viewDidLoad 指向新实现
class_replaceMethod(cls, selector, (IMP)viewDidLoadIMP, typeDescription);

这样，所有对 viewDidLoad 的调用都会走到 viewDidLoadIMP，进而执行 JS 逻辑；JS 里可通过 self.ORIGviewDidLoad() 调回原实现。

4.2 有参数时的问题：通用 IMP 如何拿到所有参数？

需要一个通用 IMP，能对「任意方法、任意参数个数与类型」都拿到参数并传给 JS。这里就出现了 32 位与 64 位 的差异。

4.2.1 32 位：va_list 取参（已不可用于 64 位）

最初用可变参数实现：

1
2
3
4
5
6
7
8

static void commonIMP(id slf, ...) {
  va_list args;
  va_start(args, slf);
  NSMethodSignature *methodSignature = [cls instanceMethodSignatureForSelector:selector];
  // 根据 methodSignature 的 typeEncoding 用 va_arg 逐个取出参数，组成 NSArray
  // 再 [jsFunction callWithArguments:list];
  va_end(args);
}

在 arm64 上，va_list 的 ABI 与 32 位不同，无法用上述方式正确取参，会 crash，因此 64 位必须换方案。

4.2.2 64 位：利用消息转发与 NSInvocation

OC 在「找不到方法实现」时会走消息转发链路，最终会到 -forwardInvocation:，此时会拿到一个 NSInvocation，其中已经包含了本次调用的 selector、参数类型、参数值、返回值类型。因此可以：

1. 把要替换的方法的 IMP 改为 _objc_msgForward，这样一旦调用该方法，就会直接进入转发流程，最终进入 -forwardInvocation:。
2. 重写该类的 -forwardInvocation:：在实现里判断「若是我们替换的方法」，则从 NSInvocation 里解出所有参数，调用我们新增的 _JPxxx 方法（该方法内部再调 JS）；否则调原来的 ORIGforwardInvocation:，保证其他转发逻辑不受影响。
3. 新增 ORIGviewWillAppear: 与 _JPviewWillAppear:：前者指向原 IMP，后者是「从 NSInvocation 取参并调 JS」的桥接实现。

这样在 64 位上就能通用地拿到任意方法的参数并交给 JS，无需依赖 va_list。

4.3 返回值是 struct 时的注意点：_objc_msgForward_stret

部分架构下，当方法返回值是「较大的 struct」时，用的是 objc_msgSend_stret 的调用约定（返回值通过内存指针传回），若仍用 _objc_msgForward 会出错。此时需要改用 _objc_msgForward_stret。
是否「special struct return」没有公开 API，JSPatch 通过 NSMethodSignature 的 debugDescription 是否包含 "is special struct return? YES" 来判断，在非 arm64 上对这类方法使用 _objc_msgForward_stret。

4.4 新增方法、Protocol、Property

• 新增方法：OC 侧通过 class_addMethod 动态添加，参数与返回值类型先统一为 id（因为新增方法主要给 JS 用）。若类声明实现了某 Protocol，则从 Protocol 的方法描述里取类型信息，保证与 Protocol 一致（如 tableView:sectionForSectionIndexTitle:atIndex: 等）。
• Property：已有属性直接通过 getter/setter 方法在 JS 里按普通方法调用即可。动态新增成员则用 objc_setAssociatedObject / objc_getAssociatedObject 模拟（因为 class_addIvar 只能在类注册前使用，无法给已有类加 ivar）。

4.5 self 与 super

• self：在 defineClass 的实例方法执行前，把「当前实例」写入一个 JS 全局变量（如 self），方法执行完后清空，这样在 JS 里写的 self 就指向当前 OC 实例。
• super：self.super() 在 __c() 里做特殊处理，返回一个带 __isSuper: 1 标记的对象。OC 侧若发现是 super 调用，则取父类该方法的 IMP，为当前类临时加一个方法（如 SUPER_viewDidLoad）指向该 IMP，再转调该方法，从而模拟 OC 的 super 语义。

五、扩展能力：Struct 与 C 函数

5.1 Struct 支持

JS 与 OC 之间不能直接传 C struct，需要序列化/反序列化。JSPatch 的做法是：

• 内置：对常用类型如 NSRange、CGRect、CGSize、CGPoint 等做专门转换。
• 可扩展：在 JS 里通过 defineStruct 声明 struct 的「名字、类型串、字段名」，OC 根据类型串按内存布局逐字段读写，再封装成 NSDictionary 与 JS 互传。这样新增 struct 不需要改 OC 代码，只需在 JS 声明布局即可（依赖当前 ABI 下 struct 内存布局稳定）。

5.2 C 函数支持

C 函数无法通过 Runtime 反射调用，因此采用「在 JSContext 上挂 OC Block 包装」的方式：在 context 上暴露与 C 函数同名的 JS 可调接口，内部转调 C 函数，并做好指针等类型转换。为避免引擎体积和启动时一次性注册过多 C 函数，设计了 JPExtension 机制：通过 +main:(JSContext *) 和 formatJSToOC / formatOCToJS 等接口，让扩展按需注册 C 函数，JS 端通过 require('JPEngine').addExtensions(['JPMemory']) 等方式按需加载。

六、关键实现细节

6.1 JPBoxing：避免可变集合被 JavaScriptCore 自动转换

NSMutableArray / NSMutableDictionary / NSMutableString 从 OC 返回给 JS 时，JavaScriptCore 会强制转成 JS 的 Array / Object / String，导致「回到 OC 时无法再调原生的可变方法」。
解决办法：不直接返回这些对象，而是用 JPBoxing 包装一层（把 OC 对象放在 Boxing 的 property 里），返回 Boxing 实例给 JS。JS 再把这个 Boxing 传回 OC 时，OC 从 Boxing 里取出原对象，即可继续调可变方法。同时，为规则统一，NSArray/NSDictionary/NSString 也采用「默认以指针形式在 JS 侧存在，需要再调 .toJS() 转成纯 JS 类型」的策略。

6.2 nil / NSNull 的区分与链式调用

• nil 与 NSNull：JS 的 null/undefined 传到 OC 时统一变成 nil；若需要明确表示 NSNull，在 JS 里使用全局变量 nsnull，OC 侧据此区分。
• 链式调用：OC 里 [[obj returnNil] doSomething] 是安全的（对 nil 发消息不崩溃），但 JS 里 null 没有方法，无法写 require("JPObject").returnNil().hash()。JSPatch 用 false 表示 OC 返回的 nil：在 JS 里 false 也是对象可调方法，同时 if (!obj) 仍可用来判断「是否为 nil」。这样链式调用在 JS 侧也能安全进行。唯一的小坑是：若 OC 参数类型是 NSNumber* 而 JS 传 false，OC 会得到 nil 而非 NSNumber，需要业务侧注意。

6.3 下划线 _ 的歧义

OC 方法名用 : 分隔参数，JSPatch 在 JS 里用 单个下划线 _ 连接多参数方法名，例如：

• setObject:forKey: → setObject_forKey_

若 OC 方法名里本身带下划线（如 set_object:forKey:），就会与「参数分隔符」混淆。约定：OC 方法名中的字面下划线在 JS 里用双下划线 __ 表示，例如 set__object_forKey_。这样 OC 的 _ 与 JSPatch 的「参数分隔」可以区分开。

6.4 内存与 ARC

• 从 NSInvocation 取参数/返回值：若用 id arg; [invocation getArgument:&arg atIndex:i];，ARC 会在退出作用域时对 arg 做 release，但 getArgument:atIndex: 并不会自动做 retain，容易造成 double release。解决方式是用 __unsafe_unretained 或 __weak，或通过 void * + __bridge 明确所有权。
• alloc / new / copy / mutableCopy 返回值：按 OC 约定，这些方法返回的对象调用方持有，retainCount 已 +1。从 NSInvocation 取返回值时，若 selector 是这类方法，需用 __bridge_transfer 把所有权交给 ARC，否则会泄漏。

七、核心模块与源码结构

源码阅读顺序建议：JPEngine 初始化与注入 → JS 中的 __c 与 _methodFunc → OC 侧根据类名/对象/方法名调用 Runtime（含 NSInvocation）→ 方法替换（forwardInvocation + ORIG/JP 前缀）→ JPBoxing 与类型转换。

关键调用链（OC 侧）

1
2
3
4
5
6
7

JS 调用 UIView.alloc().init()
  → _methodFunc 被调用，参数 [className="UIView", methodName="alloc", args=[]]
  → 通过 JSContext 注册的桥接函数进入 OC（如 callSelector:selectorName:arguments:...）
  → JPEngine 内根据 className 取 Class，根据 selectorName 取 SEL，组装 NSInvocation
  → 设置 target、arguments，invoke
  → 返回值经 formatOCToJS / JPBoxing 包装后回传 JS
  → JS 侧得到包装对象 { __obj: 实例 }，再调用 .__c('init')() 继续链式调用

方法替换调用链（64 位）