目录

• 一、响应式编程基础
• 二、iOS响应式状态管理
• 三、Flutter响应式状态管理
• 四、React响应式状态管理
• 五、React Native响应式状态管理
• 六、鸿蒙响应式状态管理
• 七、性能优化与对比
• 八、最佳实践与架构选型

一、响应式编程基础

1.1 核心概念

响应式编程是一种编程范式，其核心思想是：

• 数据驱动UI：UI是数据的函数 UI = f(state)
• 自动更新：当数据变化时，UI自动更新
• 声明式：只关注”是什么”，不关注”怎么做”

状态管理是响应式编程的核心，解决的问题包括：

• 状态的存储和访问
• 状态变化的检测和通知
• 副作用的处理
• 状态的持久化

1.2 响应式系统的基本构成

一个完整的响应式系统通常包含以下组件：

二、iOS响应式状态管理

2.1 传统KVO机制

核心原理：

• 键值观察（Key-Value Observing）是iOS的原生响应式机制
• 基于运行时的动态方法替换
• 使用isa-swizzling技术实现属性观察

实现机制：

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

// 1. 注册观察者
[object addObserver:self 
         forKeyPath:@"propertyName" 
            options:NSKeyValueObservingOptionNew 
            context:NULL];

// 2. 实现观察回调
- (void)observeValueForKeyPath:(NSString *)keyPath 
                      ofObject:(id)object 
                        change:(NSDictionary *)change 
                       context:(void *)context {
    if ([keyPath isEqualToString:@"propertyName"]) {
        id newValue = change[NSKeyValueChangeNewKey];
        // 更新UI
    }
}

// 3. 移除观察者
- (void)dealloc {
    [object removeObserver:self forKeyPath:@"propertyName"];
}

技术深度：

• KVO通过动态创建子类实现，当对象被观察时，系统会：
  1. 创建一个继承自原类的子类
  2. 重写被观察属性的setter方法
  3. 替换对象的isa指针指向新子类
  4. 在setter中通知观察者

2.2 Combine框架

核心原理：

• Apple在iOS 13+推出的响应式编程框架
• 基于Publisher-Subscriber模式
• 支持函数式的响应式操作

实现机制：

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

// 1. 创建Publisher
let subject = PassthroughSubject<String, Never>()

// 2. 订阅
let cancellable = subject
    .map { $0.uppercased() }
    .filter { $0.count > 3 }
    .sink {
        print("Received: \($0)")
    }

// 3. 发送值
subject.send("Hello")
subject.send("World")

// 4. 取消订阅
cancellable.cancel()

技术深度：

• Combine使用协议和泛型实现类型安全
• Publisher：数据源，负责发送值
• Subscriber：订阅者，接收并处理值
• Operator：操作符，对数据流进行转换
• Cancellable：管理订阅生命周期

2.3 SwiftUI状态管理

核心原理：

• 声明式UI框架，与响应式状态管理深度集成
• 使用属性包装器简化状态管理
• 基于依赖追踪的更新机制

实现机制：

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

// 1. @State - 本地状态
struct ContentView: View {
    @State private var count = 0
    
    var body: some View {
        VStack {
            Text("Count: \(count)")
            Button("Increment") {
                count += 1
            }
        }
    }
}

// 2. @ObservableObject - 可观察对象
class UserViewModel: ObservableObject {
    @Published var name: String
    
    init(name: String) {
        self.name = name
    }
}

struct UserView: View {
    @ObservedObject var viewModel: UserViewModel
    
    var body: some View {
        Text("Name: \(viewModel.name)")
    }
}

技术深度：

• @State：使用值类型的引用包装，支持本地状态
• @Published：使用属性包装器实现自动通知
• @ObservedObject：使用弱引用避免循环引用
• @EnvironmentObject：通过环境传递共享状态

三、Flutter响应式状态管理

3.1 基础状态管理（setState）

核心原理：

• 基于StatefulWidget和setState的基础状态管理
• 脏检查机制触发重建
• Element树的差异化更新

实现机制：

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

class CounterWidget extends StatefulWidget {
  @override
  _CounterWidgetState createState() => _CounterWidgetState();
}

class _CounterWidgetState extends State<CounterWidget> {
  int _count = 0;
  
  void _increment() {
    setState(() {
      _count++;
    });
  }
  
  @override
  Widget build(BuildContext context) {
    return Column(
      children: [
        Text('Count: $_count'),
        ElevatedButton(
          onPressed: _increment,
          child: Text('Increment'),
        ),
      ],
    );
  }
}

技术深度：

• setState：标记Element为dirty，触发下一帧重建
• Widget树：不可变的配置树
• Element树：管理生命周期和状态
• RenderObject树：负责布局和渲染

3.2 InheritedWidget机制

核心原理：

• 基于继承的状态传递机制
• 利用Element树的层级关系
• 实现跨组件的状态共享

实现机制：

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

class AppState extends InheritedWidget {
  final int count;
  final VoidCallback increment;
  
  const AppState({
    Key? key,
    required this.count,
    required this.increment,
    required Widget child,
  }) : super(key: key, child: child);
  
  static AppState of(BuildContext context) {
    return context.dependOnInheritedWidgetOfExactType<AppState>()!;
  }
  
  @override
  bool updateShouldNotify(AppState oldWidget) {
    return oldWidget.count != count;
  }
}

// 使用
class MyApp extends StatefulWidget {
  @override
  _MyAppState createState() => _MyAppState();
}

class _MyAppState extends State<MyApp> {
  int _count = 0;
  
  void _increment() {
    setState(() => _count++);
  }
  
  @override
  Widget build(BuildContext context) {
    return AppState(
      count: _count,
      increment: _increment,
      child: MaterialApp(
        home: HomePage(),
      ),
    );
  }
}

class HomePage extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    final appState = AppState.of(context);
    return Column(
      children: [
        Text('Count: ${appState.count}'),
        ElevatedButton(
          onPressed: appState.increment,
          child: Text('Increment'),
        ),
      ],
    );
  }
}

技术深度：

• dependOnInheritedWidgetOfExactType：建立依赖关系
• updateShouldNotify：决定是否通知子组件
• Element依赖追踪：当InheritedWidget变化时，自动重建依赖的子组件

3.3 第三方状态管理库

Provider

核心原理：

• 基于InheritedWidget的轻量级状态管理
• 使用ChangeNotifier实现状态通知
• 支持依赖注入和状态监听

实现机制：

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

// 1. 定义模型
class CounterModel extends ChangeNotifier {
  int _count = 0;
  int get count => _count;
  
  void increment() {
    _count++;
    notifyListeners();
  }
}

// 2. 提供状态
void main() {
  runApp(
    ChangeNotifierProvider(
      create: (context) => CounterModel(),
      child: MyApp(),
    ),
  );
}

// 3. 消费状态
class HomePage extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Consumer<CounterModel>(
      builder: (context, counter, child) {
        return Column(
          children: [
            Text('Count: ${counter.count}'),
            ElevatedButton(
              onPressed: counter.increment,
              child: Text('Increment'),
            ),
          ],
        );
      },
    );
  }
}

技术深度：

• ChangeNotifier：实现观察者模式
• Consumer：订阅状态变化，只重建必要的Widget
• Selector：更精确的依赖选择，避免不必要的重建

Riverpod

核心原理：

• 解决Provider的依赖注入和测试问题
• 基于ProviderContainer的状态管理
• 支持编译时安全和懒加载

实现机制：

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

// 1. 定义Provider
final counterProvider = StateProvider<int>((ref) => 0);

// 2. 使用Provider
class HomePage extends ConsumerWidget {
  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final count = ref.watch(counterProvider);
    
    return Column(
      children: [
        Text('Count: $count'),
        ElevatedButton(
          onPressed: () => ref.read(counterProvider.notifier).state++,
          child: Text('Increment'),
        ),
      ],
    );
  }
}

// 3. 组合Provider
final userProvider = Provider<User>((ref) {
  final userId = ref.watch(userIdProvider);
  return User(id: userId);
});

技术深度：

• ProviderScope：状态容器，支持测试和隔离
• AutoDispose：自动清理不再使用的状态
• Family：参数化Provider，支持动态创建
• FutureProvider：处理异步状态
• StreamProvider：处理流式状态

四、React响应式状态管理

4.1 基础状态管理（setState）

核心原理：

• 基于Component和setState的状态管理
• 虚拟DOM的差异化更新
• 批处理优化性能

实现机制：

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

class Counter extends React.Component {
  constructor(props) {
    super(props);
    this.state = {
      count: 0
    };
  }
  
  increment() {
    this.setState(prevState => ({
      count: prevState.count + 1
    }));
  }
  
  render() {
    return (
      <div>
        <p>Count: {this.state.count}</p>
        <button onClick={() => this.increment()}>Increment</button>
      </div>
    );
  }
}

技术深度：

• setState：异步更新，支持函数式更新
• shouldComponentUpdate：手动优化渲染
• PureComponent：浅比较优化
• forceUpdate：强制更新

4.2 Hooks状态管理

核心原理：

• React 16.8+引入的函数组件状态管理
• 基于闭包和链表的Hook实现
• 支持自定义Hook复用逻辑

实现机制：

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

import React, { useState, useEffect } from 'react';

function Counter() {
  const [count, setCount] = useState(0);
  
  useEffect(() => {
    document.title = `Count: ${count}`;
  }, [count]);
  
  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount(count + 1)}>Increment</button>
    </div>
  );
}

技术深度：

• useState：基于Dispatcher的状态管理
• useEffect：处理副作用，依赖数组控制执行时机
• useContext：跨组件状态共享
• useReducer：复杂状态逻辑管理
• useMemo/useCallback：性能优化

4.3 Redux状态管理

核心原理：

• 基于Flux架构的状态管理
• 单一数据源和不可变状态
• Reducer纯函数处理状态更新

实现机制：

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

// 1. 定义Action
const INCREMENT = 'INCREMENT';
const DECREMENT = 'DECREMENT';

// 2. 定义Reducer
function counterReducer(state = { count: 0 }, action) {
  switch (action.type) {
    case INCREMENT:
      return { count: state.count + 1 };
    case DECREMENT:
      return { count: state.count - 1 };
    default:
      return state;
  }
}

// 3. 创建Store
const store = createStore(counterReducer);

// 4. 订阅状态
store.subscribe(() => {
  console.log('Current state:', store.getState());
});

// 5. 分发Action
store.dispatch({ type: INCREMENT });

// 6. 在React中使用
import { connect } from 'react-redux';

function Counter({ count, increment, decrement }) {
  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={increment}>Increment</button>
      <button onClick={decrement}>Decrement</button>
    </div>
  );
}

const mapStateToProps = state => ({
  count: state.count
});

const mapDispatchToProps = dispatch => ({
  increment: () => dispatch({ type: INCREMENT }),
  decrement: () => dispatch({ type: DECREMENT })
});

export default connect(mapStateToProps, mapDispatchToProps)(Counter);

技术深度：

• Store：单一数据源，持有应用状态
• Action：描述状态变化的对象
• Reducer：纯函数，根据Action计算新状态
• Middleware：处理异步Action和副作用
• CombineReducers：拆分状态逻辑

五、React Native响应式状态管理

5.1 原生状态管理

核心原理：

• 与React相同的状态管理机制
• 针对移动平台的优化
• 支持原生模块的状态同步

实现机制：

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

import React, { useState } from 'react';
import { View, Text, TouchableOpacity } from 'react-native';

function Counter() {
  const [count, setCount] = useState(0);
  
  return (
    <View style={{ flex: 1, justifyContent: 'center', alignItems: 'center' }}>
      <Text style={{ fontSize: 24 }}>Count: {count}</Text>
      <TouchableOpacity
        style={{ marginTop: 20, padding: 10, backgroundColor: '#007AFF' }}
        onPress={() => setCount(count + 1)}
      >
        <Text style={{ color: 'white' }}>Increment</Text>
      </TouchableOpacity>
    </View>
  );
}

技术深度：

• Bridge：JavaScript与原生通信
• Shadow Tree：虚拟DOM在RN中的实现
• Batched Updates：批量更新优化
• Native Modules：原生功能集成

5.2 第三方状态管理库

Redux

核心原理：

• 与React Redux相同的架构
• 针对移动场景的优化
• 支持持久化和中间件

实现机制：

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

// 与Web React Redux相同
import { createStore, applyMiddleware } from 'redux';
import thunk from 'redux-thunk';
import rootReducer from './reducers';

const store = createStore(
  rootReducer,
  applyMiddleware(thunk)
);

// 在App中使用
import { Provider } from 'react-redux';

export default function App() {
  return (
    <Provider store={store}>
      <Counter />
    </Provider>
  );
}

MobX

核心原理：

• 基于观察者模式的状态管理
• 响应式代理自动追踪依赖
• 装饰器简化状态定义

实现机制：

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

import { observable, action } from 'mobx';
import { observer } from 'mobx-react';

// 定义Store
class CounterStore {
  @observable count = 0;
  
  @action increment() {
    this.count++;
  }
  
  @action decrement() {
    this.count--;
  }
}

const counterStore = new CounterStore();

// 使用Store
@observer
class Counter extends React.Component {
  render() {
    return (
      <View>
        <Text>Count: {counterStore.count}</Text>
        <TouchableOpacity onPress={() => counterStore.increment()}>
          <Text>Increment</Text>
        </TouchableOpacity>
      </View>
    );
  }
}

技术深度：

• observable：创建响应式状态
• action：修改状态的方法
• computed：派生状态
• reaction：副作用处理

Context API

核心原理：

• React 16.3+的Context API
• 简化跨组件状态共享
• 替代Redux的轻量级方案

实现机制：

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

import React, { createContext, useContext, useState } from 'react';

// 创建Context
const CounterContext = createContext();

// 提供Context
function CounterProvider({ children }) {
  const [count, setCount] = useState(0);
  
  const value = {
    count,
    increment: () => setCount(count + 1),
    decrement: () => setCount(count - 1)
  };
  
  return (
    <CounterContext.Provider value={value}>
      {children}
    </CounterContext.Provider>
  );
}

// 使用Context
function Counter() {
  const { count, increment, decrement } = useContext(CounterContext);
  
  return (
    <View>
      <Text>Count: {count}</Text>
      <TouchableOpacity onPress={increment}>
        <Text>Increment</Text>
      </TouchableOpacity>
      <TouchableOpacity onPress={decrement}>
        <Text>Decrement</Text>
      </TouchableOpacity>
    </View>
  );
}

// 在App中使用
function App() {
  return (
    <CounterProvider>
      <Counter />
    </CounterProvider>
  );
}

六、鸿蒙响应式状态管理

6.1 ArkUI状态管理

核心原理：

• 鸿蒙ArkUI框架的响应式状态管理
• 基于数据驱动的UI更新
• 支持声明式和命令式编程

实现机制：

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

// 1. 基本状态管理
@Entry
@Component
struct Counter {
  @State count: number = 0;
  
  build() {
    Column() {
      Text(`Count: ${this.count}`)
        .fontSize(24)
      Button('Increment')
        .onClick(() => {
          this.count++;
        })
    }
    .width('100%')
    .height('100%')
    .justifyContent(FlexAlign.Center)
    .alignItems(HorizontalAlign.Center)
  }
}

// 2. 全局状态管理
@StorageLink('count')
let globalCount: number = 0;

@Entry
@Component
struct GlobalCounter {
  build() {
    Column() {
      Text(`Global Count: ${globalCount}`)
        .fontSize(24)
      Button('Increment')
        .onClick(() => {
          globalCount++;
        })
    }
  }
}

技术深度：

• @State：组件级状态，局部更新
• @Prop：父组件传递的状态，单向数据流
• @Link：双向绑定状态
• @StorageLink：全局存储状态
• @Provide/@Consume：跨组件状态共享

6.2 状态管理最佳实践

核心原理：

• 结合MVVM架构
• 使用状态管理器统一管理状态
• 支持异步操作和副作用处理

实现机制：

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

// 定义状态管理器
class CounterStore {
  private _count: number = 0;
  private _observers: Set<() => void> = new Set();
  
  get count(): number {
    return this._count;
  }
  
  increment(): void {
    this._count++;
    this.notifyObservers();
  }
  
  decrement(): void {
    this._count--;
    this.notifyObservers();
  }
  
  subscribe(observer: () => void): void {
    this._observers.add(observer);
  }
  
  unsubscribe(observer: () => void): void {
    this._observers.delete(observer);
  }
  
  private notifyObservers(): void {
    this._observers.forEach(observer => observer());
  }
}

// 使用状态管理器
const counterStore = new CounterStore();

@Entry
@Component
struct Counter {
  @State count: number = counterStore.count;
  
  aboutToAppear(): void {
    counterStore.subscribe(() => {
      this.count = counterStore.count;
    });
  }
  
  build() {
    Column() {
      Text(`Count: ${this.count}`)
        .fontSize(24)
      Button('Increment')
        .onClick(() => {
          counterStore.increment();
        })
    }
  }
}

技术深度：

• 单向数据流：状态变化 → UI更新
• 可观测性：状态变化自动通知
• 模块化：状态逻辑与UI分离
• 可测试性：纯函数状态更新

七、性能优化与对比

7.1 性能优化策略

7.2 平台对比

7.3 性能瓶颈分析

iOS：

• KVO的运行时开销
• Combine的内存管理
• SwiftUI的重建机制

Flutter：

• Widget重建开销
• 状态管理的性能开销
• 渲染管线的优化

React：

• 虚拟DOM的diff开销
• 重渲染的性能损耗
• 状态管理的复杂性

React Native：

• JSBridge的通信开销
• 原生模块的调用延迟
• 渲染性能的限制

鸿蒙：

• 状态管理的同步问题
• 组件生命周期的管理
• 性能优化的复杂度

八、最佳实践与架构选型

8.1 架构选型指南

8.2 最佳实践

1. 状态管理分层

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

应用架构
┌─────────────────────────┐
│  UI Layer              │
│  (View/Widget/Component) │
├─────────────────────────┤
│  State Management Layer │
│  (Store/Provider/Context) │
├─────────────────────────┤
│  Business Logic Layer   │
│  (UseCase/Service)      │
├─────────────────────────┤
│  Data Layer            │
│  (Repository/API)      │
└─────────────────────────┘

2. 状态管理原则

• 单一数据源：避免状态分散
• 不可变状态：确保状态变化可预测
• 单向数据流：状态 → UI → 事件 → 状态
• 分离关注点：业务逻辑与UI分离
• 可测试性：状态管理逻辑可独立测试

3. 性能优化最佳实践

• iOS：使用Combine的调度器，避免KVO滥用
• Flutter：使用const Widget，合理使用Key，优化重建
• React：使用memo，合理设置依赖数组，避免不必要的渲染
• React Native：使用Hermes引擎，优化桥接通信
• 鸿蒙：合理使用状态注解，优化组件渲染

4. 团队协作建议

• 统一状态管理方案：团队内使用一致的状态管理库
• 文档化状态结构：清晰记录状态的结构和流转
• 代码规范：建立状态管理的代码规范
• 测试策略：为状态管理逻辑编写单元测试
• 性能监控：建立性能监控机制

总结

响应式状态管理是现代前端和移动开发的核心技术之一，不同平台有其独特的实现原理和最佳实践：

1. iOS：从KVO到Combine再到SwiftUI，逐步演进为更现代的响应式方案
2. Flutter：基于Widget树和InheritedWidget，构建了独特的响应式体系
3. React：从setState到Hooks，简化了状态管理的复杂性
4. React Native：继承了React的状态管理机制，针对移动平台进行了优化
5. 鸿蒙：基于ArkUI框架，提供了声明式的状态管理方案

选择合适的状态管理方案需要考虑：

• 应用规模：小型应用使用简单方案，大型应用使用复杂方案
• 性能要求：对性能敏感的应用需要更精细的状态管理
• 团队经验：选择团队熟悉的技术栈
• 维护成本：考虑长期维护的复杂性

通过深入理解各平台的响应式状态管理原理，开发者可以构建更高效、更可维护的应用，提升用户体验和开发效率。

按「概念 → 原理 → 源码入口 → 示例 → 案例」串起来，覆盖移动端与桌面端常见方案，并包含以 Web/React 技术辐射多端（含 Taro 等小程序方案）与桌面端 Electron 等典型选型，方便对照。

一、基本概念

1.1 什么是跨平台开发？

跨平台开发指用一套（或高度共享的）代码，同时支持多个操作系统或设备形态（如 iOS、Android、macOS、Windows、Linux、Web），从而降低开发与维护成本、加快迭代速度。

1
2
3
4
5
6
7
8
9
10
11

┌─────────────────────────────────────────────────────────────────────────┐
│                        跨平台开发的核心目标                                │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                          │
│   一套 / 共享代码  ──►  多端运行  ──►  降低人力、统一体验、快速发布          │
│                                                                          │
│   移动端：iOS + Android（+ 鸿蒙 / 其他）                                   │
│   桌面端：macOS + Windows + Linux                                         │
│   大前端：Web + 移动 + 桌面（部分方案可三端复用）                            │
│                                                                          │
└─────────────────────────────────────────────────────────────────────────┘

1.2 移动端跨平台 vs 桌面端跨平台

1.3 为什么需要跨平台？

二、跨平台的核心原理

2.1 三种主流渲染思路

跨平台方案按「谁来画 UI」可分为三类：

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

┌────────────────────────────────────────────────────────────────────────────┐
│  方式              │  谁负责渲染？        │  代表技术                         │
├────────────────────────────────────────────────────────────────────────────┤
│  原生控件映射       │  使用系统原生控件    │  React Native、Xamarin、Compose   │
│  (Native Mapping)  │  通过桥接更新属性    │  Multiplatform                    │
├────────────────────────────────────────────────────────────────────────────┤
│  Web 容器          │  内嵌 WebView/浏览器 │  Cordova、Capacitor、Electron     │
│  (WebView/Chromium)│  用 HTML/CSS/JS 画  │  (Electron 用 Chromium 做桌面壳)   │
├────────────────────────────────────────────────────────────────────────────┤
│  自绘 (Skia/Impeller)│  自己画像素/矢量   │  Flutter、Qt、.NET MAUI 部分       │
│  (Self-draw)       │  不依赖系统控件      │                                    │
└────────────────────────────────────────────────────────────────────────────┘

• 原生控件映射：体验最接近系统原生，但受限于各端控件能力与差异，需要处理平台差异。
• Web 容器：开发效率高、生态成熟，桌面端 Electron 安装体积与内存占用较大。
• 自绘：UI 一致性强、不依赖系统控件，可精细控制渲染；需要自己实现可访问性、输入法等。

2.2 架构共性：桥接与运行时

无论哪种方式，跨平台层都要和「宿主平台」通信：

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

┌─────────────────────────────────────────────────────────────────────────┐
│  跨平台层（业务 + UI 描述）                                               │
│  ┌─────────────────────────────────────────────────────────────────┐   │
│  │  Dart / JavaScript / C# / Kotlin 等                              │   │
│  │  组件树 / 虚拟 DOM / 声明式 UI                                    │   │
│  └────────────────────────────┬────────────────────────────────────┘   │
│                               │ 桥接层 (Bridge / Channel / FFI)         │
├───────────────────────────────┼─────────────────────────────────────────┤
│  宿主 / 原生层                 ▼                                         │
│  ┌─────────────────────────────────────────────────────────────────┐   │
│  │  Native (Swift/Kotlin/C++/Rust) + 系统 API + 原生控件/自绘引擎     │   │
│  └─────────────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────────────┘

• 移动端：通常通过 Bridge / Channel（如 React Native 的 Bridge、Flutter 的 Platform Channel）做异步通信。
• 桌面端：Electron 是 主进程 + 渲染进程 的 IPC；Tauri 是 Web 前端 + Rust 核心 的 IPC/FFI，体积更小。

2.3 技术选型简表

三、代表性框架原理与源码要点

3.1 Flutter：自绘引擎与 Dart 层

3.1.1 整体架构

Flutter 的 UI 不依赖系统控件，由 Skia（或 Impeller on iOS）在画布上自绘，因此各端视觉与行为高度一致。

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

┌──────────────────────────────────────────────────────────────────┐
│  Dart 层                                                            │
│  Widget 树 → Element 树 → RenderObject 树（布局与绘制）              │
└────────────────────────────┬─────────────────────────────────────┘
                             │ Dart VM / AOT 编译
┌────────────────────────────▼─────────────────────────────────────┐
│  Flutter Engine (C++)                                              │
│  Layer 树 → Scene → Skia/Impeller 绘制 → 显示                      │
└────────────────────────────┬─────────────────────────────────────┘
                             │ 平台嵌入层 (Embedder)
┌────────────────────────────▼─────────────────────────────────────┐
│  Android (SurfaceView) / iOS (Metal) / Windows (ANGLE) / ...       │
└──────────────────────────────────────────────────────────────────┘

3.1.2 关键源码位置（概念性）

• Widget → Element → RenderObject：flutter/lib/src/widgets/framework.dart、rendering/object.dart。
  Element 持有 RenderObject，RenderObject 负责 layout、paint，最终生成 Layer 提交给引擎。
• 绘制入口：RenderView 的 compositeFrame() 将 Layer 树提交给 Window.render()，引擎再交给 Skia/Impeller。
• 平台通道：PlatformChannel 在 flutter/lib/src/services/platform_channel.dart，Dart 与原生通过 BinaryMessenger 收发序列化消息。

理解「Widget 不可变 → Element 挂载/更新 → RenderObject 布局绘制」这条链路，就抓住了 Flutter UI 的核心。

3.2 React Native：桥接与原生组件

3.2.1 新架构（Fabric + TurboModules）与旧桥

• 旧架构：JS 与原生通过 Bridge 异步传 JSON，原生侧用 UIManager 把「虚拟节点」转成原生 View。
• 新架构：
  • Fabric：C++的渲染器，Shadow 树在 C++ 中，减少跨桥次数，支持同步布局与优先级。
  • TurboModules：按需加载的 JSI 原生模块，可同步调用，不再全部在启动时塞进 Bridge。

1
2
3
4
5
6
7
8
9

┌─────────────┐     JSI (JavaScript Interface)      ┌─────────────────┐
│  JavaScript │  ◄──── 同步/异步调用 ─────────────►  │  C++ Fabric /   │
│  React 组件  │         (新架构)                     │  TurboModules   │
└─────────────┘                                      └────────┬────────┘
                                                              │
┌─────────────┐     Bridge (旧) / 序列化消息           ┌───────▼───────┐
│  Metro 打包  │  ◄──────────────────────────────►    │  Native Views │
│  JS Bundle  │                                      │  (Android/iOS)│
└─────────────┘                                      └───────────────┘

3.2.2 源码可读入口（概念性）

• React 组件到原生：新架构下 ReactFabric、FabricUIManager 等（C++），旧架构下 UIManagerModule（Java/ObjC）把「节点树」转成原生 View。
• 通信：NativeModules、NativeEventEmitter 对应到原生模块与事件发送，新架构下通过 JSI 直接调 C++ 再调原生。

3.3 Electron：多进程与 IPC

3.3.1 主进程 + 渲染进程

Electron 基于 Chromium，每个窗口是一个渲染进程，主进程负责生命周期、系统 API、原生菜单等。

1
2
3
4
5
6
7
8
9
10
11

┌─────────────────────────────────────────────────────────────────────────┐
│  Main Process (Node.js)                                                   │
│  BrowserWindow、app、Menu、系统 API、原生模块 (.node)                       │
└────────────────────────────┬────────────────────────────────────────────┘
                             │  IPC (ipcMain / ipcRenderer)
│  contextBridge.exposeInMainWorld 安全暴露 API
└────────────────────────────┬────────────────────────────────────────────┘
┌────────────────────────────▼─────────────────────────────────────────────┐
│  Renderer Process (Chromium)                                               │
│  HTML / CSS / JS，类似前端 SPA；可禁用 Node 仅用 preload 暴露能力            │
└─────────────────────────────────────────────────────────────────────────┘

3.3.2 安全与 contextBridge

• 不要在渲染进程直接开 nodeIntegration: true 并把整个 Node 暴露给页面。
• 推荐：用 contextBridge.exposeInMainWorld 在 preload 里暴露有限 API，主进程通过 ipcMain 处理，渲染进程只调这些 API。

源码层面：lib/renderer/api/context-bridge.ts、lib/main/api/ipc-main.ts 等，理解「preload 注入 → contextBridge → ipcRenderer.invoke」这条链路即可。

3.4 Tauri：Rust 核心 + 前端

3.4.1 轻量从何而来

Tauri 不内嵌完整 Chromium，而是用 系统 WebView（Windows: WebView2，macOS: WKWebView，Linux: WebKitGTK），所以安装包小、内存占用低。

1
2
3
4
5
6
7
8
9

┌─────────────────────────────────────────────────────────────────────────┐
│  Frontend (任意: React / Vue / Svelte / 纯 HTML)                          │
│  运行在系统 WebView 中                                                    │
└────────────────────────────┬────────────────────────────────────────────┘
                             │  Tauri API (invoke / event)
┌────────────────────────────▼─────────────────────────────────────────────┐
│  Tauri Core (Rust)                                                        │
│  窗口、菜单、系统托盘、文件与 shell、插件；可调用任意 Rust 与系统 API        │
└─────────────────────────────────────────────────────────────────────────┘

3.4.2 命令与安全

• 前端通过 invoke('command_name', { ... }) 调用 Rust 端在 #[tauri::command] 里定义的函数。
• 权限与能力在 tauri.conf.json 的 capabilities 中声明，避免前端随意调敏感 API。
  源码可看 tauri/src/manager.rs、tauri/src/app.rs 以及命令派发与 IPC 的实现。

四、示例代码

4.1 Flutter：一个跨移动端 + 桌面的页面

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

// 同一套代码可跑在 iOS、Android、Windows、macOS、Linux
import 'package:flutter/material.dart';

void main() => runApp(const MyApp());

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Cross-Platform Demo',
      theme: ThemeData(primarySwatch: Colors.blue),
      home: const HomePage(),
    );
  }
}

class HomePage extends StatefulWidget {
  const HomePage({super.key});

  @override
  State<HomePage> createState() => _HomePageState();
}

class _HomePageState extends State<HomePage> {
  int _counter = 0;

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: const Text('Flutter 跨平台')),
      body: Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: [
            Text('点击次数: $_counter', style: Theme.of(context).textTheme.headlineMedium),
            const SizedBox(height: 24),
            FilledButton.icon(
              onPressed: () => setState(() => _counter++),
              icon: const Icon(Icons.add),
              label: const Text('增加'),
            ),
          ],
        ),
      ),
    );
  }
}

• 移动端：flutter run 选 iOS/Android 设备即可。
• 桌面端：flutter run -d windows / macos / linux（需先 flutter config --enable-*desktop）。

4.2 React Native：一个带原生能力的组件

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

// 跨 iOS + Android，调用原生模块示例
import { NativeModules, Platform, StyleSheet, Text, View, Button } from 'react-native';

const { MyNativeModule } = NativeModules; // 需在原生侧实现 MyNativeModule

export default function App() {
  const [result, setResult] = React.useState('');

  const callNative = async () => {
    try {
      const value = await MyNativeModule?.getDeviceId?.() ?? '未实现';
      setResult(value);
    } catch (e) {
      setResult(String(e));
    }
  };

  return (
    <View style={styles.container}>
      <Text style={styles.text}>平台: {Platform.OS}</Text>
      <Button title="调用原生 getDeviceId" onPress={callNative} />
      <Text style={styles.result}>{result}</Text>
    </View>
  );
}

const styles = StyleSheet.create({
  container: { flex: 1, justifyContent: 'center', alignItems: 'center', padding: 20 },
  text: { fontSize: 16, marginBottom: 12 },
  result: { marginTop: 12, color: '#333' },
});

4.3 Electron：主进程与渲染进程通信

1
2
3
4
5
6
7

// preload.js（运行在隔离上下文中，通过 contextBridge 暴露）
const { contextBridge, ipcRenderer } = require('electron');

contextBridge.exposeInMainWorld('electronAPI', {
  getAppVersion: () => ipcRenderer.invoke('get-app-version'),
  openFolder: (path) => ipcRenderer.invoke('dialog:openFolder', path),
});

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

// main.js（主进程）
const { app, BrowserWindow, ipcMain, dialog } = require('electron');
const path = require('path');

function createWindow() {
  const win = new BrowserWindow({
    width: 800,
    height: 600,
    webPreferences: {
      preload: path.join(__dirname, 'preload.js'),
      nodeIntegration: false,
      contextIsolation: true,
    },
  });
  win.loadFile('index.html');
}

app.whenReady().then(() => {
  ipcMain.handle('get-app-version', () => app.getVersion());
  ipcMain.handle('dialog:openFolder', (_, dir) =>
    dialog.showOpenDialog({ properties: ['openDirectory'] })
  );
  createWindow();
});

1
2
3
4
5
6
7
8
9

<!-- 渲染进程 (index.html 里的脚本) -->
<button id="version">获取版本</button>
<div id="out"></div>
<script>
  document.getElementById('version').onclick = async () => {
    const v = await window.electronAPI.getAppVersion();
    document.getElementById('out').textContent = 'Version: ' + v;
  };
</script>

4.4 Tauri：前端调用 Rust 命令

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

// src-tauri/src/main.rs
#![cfg_attr(not(debug_assertions), windows_subsystem = "windows")]

#[tauri::command]
fn greet(name: &str) -> String {
    format!("Hello, {}! (from Rust)", name)
}

fn main() {
    tauri::Builder::default()
        .invoke_handler(tauri::generate_handler![greet])
        .run(tauri::generate_context!())
        .expect("error while running tauri application");
}

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

// 前端 (如 React)
import { invoke } from '@tauri-apps/api/core';

function App() {
  const [msg, setMsg] = useState('');

  const sayHello = async () => {
    const result = await invoke('greet', { name: 'Tauri' });
    setMsg(result);
  };

  return (
    <div>
      <button onClick={sayHello}>Say Hello</button>
      <p>{msg}</p>
    </div>
  );
}

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

5.1 移动端跨平台

5.2 桌面端跨平台

5.3 移动 + 桌面 统一

5.4 选型时可参考的维度

• 团队技能：前端强可选 RN/Electron/Tauri；能接受 Dart 可选 Flutter 全平台。
• 体验要求：要极致接近系统原生 → 原生映射（RN）或原生开发；要强一致性、可控渲染 → Flutter/自绘。
• 桌面包体与内存：对体积和内存敏感 → Tauri 或 Flutter Desktop；优先生态与成熟度 → Electron。
• 热更新与合规：移动端需热更新且符合商店政策时，需评估各方案的热更与审核风险。
• 已有资产：已有 Web 或 React 技术栈，可优先 RN/Electron/Capacitor；已有 Rust/系统开发，可考虑 Tauri。

六、小结

• 概念：跨平台开发用一套（或共享）代码覆盖多端，降低成本、统一体验；移动端与桌面端在平台特性、交互、分发上不同，但「桥接 + 运行时」的架构思想相通。
• 原理：三种主要思路——原生控件映射、Web 容器、自绘；理解各方案的渲染模型与桥接方式，有助于选型和排坑。
• 源码：Flutter 的 Widget/Element/RenderObject 与引擎、RN 的 Fabric/TurboModules、Electron 的 IPC 与 contextBridge、Tauri 的 Rust 命令与系统 WebView，是深入时的好入口。
• 示例：同一套 Flutter 可跑移动+桌面；RN 通过 NativeModules 调原生；Electron 用 preload + contextBridge + ipcMain；Tauri 用 invoke 调 Rust 命令。
• 实战：大量商业产品已在移动端（Flutter/RN）和桌面端（Electron/Tauri/Flutter）落地，选型时结合团队、体验、体积、热更新与既有技术栈综合权衡。

之后若往下挖，可以按各节给的入口去读引擎/桥接源码；选型时把团队栈、体验目标、包体与内存、热更新与审核几条摆桌上逐项对照即可。

由浅入深，从基本概念到源码解析，带你全面掌握 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 的演进，有助于在混合栈项目中做出更合适的架构与实现选择。