React Native+MQTT+Redux+HOC：智能家居App架构实战复盘

智能家居React NativeMQTT
于 2026-10-02 08:54:12 修改
·本内容遵循CC 4.0 BY-SA版权协议

1. 智能家居模块整体架构与选型思路

智能家居这个方向，我从早期用单片机加继电器板子做本地控制，到后来接WiFi模块走HTTP轮询，再到最近两年稳定用MQTT做设备间通信，中间踩过的坑实在不少。这次拿一个实际交付过的智能家居模块项目来复盘，重点聊React Native做移动端、MQTT做设备通信、Redux管状态、HOC做逻辑复用这套组合拳的落地细节。整套方案适合有一定React Native基础、想往IoT方向延伸的移动端开发者，也适合做嵌入式但需要配套App的硬件工程师参考。

1.1 为什么是React Native而不是原生开发

这个项目最初的需求很明确：一套App要同时覆盖iOS和Android，控制灯光、窗帘、空调、温湿度传感器这几类设备，后续还要加摄像头和门锁。团队只有两个移动端人手，如果走原生双端，光是UI同步和状态管理就能把工期拖垮。

选React Native的核心理由有三个。第一是热更新能力，智能家居App的设备协议和UI布局经常要跟着硬件固件调整，原生发版审核周期太长，RN的CodePush可以在不发版的情况下更新业务逻辑。第二是组件生态成熟，像react-native-vector-icons、react-native-svg这些库拿来就能用，做设备卡片、仪表盘、开关控件省了大量时间。第三是团队技术栈统一，前端同学直接上手，不需要额外招iOS和Android各一人。

但RN在智能家居场景有个天然短板：蓝牙和局域网直连能力弱。所以这个项目里，设备发现和配网阶段我们用了原生模块桥接，日常控制全部走MQTT走云端转发，避开了RN在底层通信上的不足。

1.2 MQTT为什么比HTTP更适合设备通信

一开始我们试过HTTP轮询，App每3秒向服务器请求一次设备状态。问题很快就暴露了：20个设备同时在线时，服务器QPS直接飙到几百，而且状态更新有延迟，用户按了开关要等一两秒界面才变。

换成MQTT之后，整个通信模型从“拉”变成了“推”。设备状态一变，Broker立刻推给订阅了对应Topic的App，延迟降到200ms以内。更关键的是长连接复用，一个App只维持一条TCP连接，不管控制多少设备，带宽和服务器压力都是常数级。

MQTT在这个项目里的角色可以这样理解：Broker是邮局，Topic是信箱编号，设备往自己的信箱投信，App订阅了哪个信箱就能收到哪个信箱的信。发布者和订阅者完全解耦，设备不需要知道谁在控制它，App也不需要知道设备在哪。

1.3 Redux在设备状态管理中的定位

智能家居App的状态比普通App复杂得多。一个页面上可能同时展示温度、湿度、灯光开关、窗帘开合度、空调模式，每个状态都可能被MQTT消息、用户操作、定时任务三个来源修改。如果直接用组件内部state，跨页面同步会变成灾难。

Redux在这里解决的是单一数据源问题。所有设备状态存在store里，MQTT消息到达后dispatch一个action，所有订阅了该设备的组件自动更新。配合redux-persist，App重启后还能恢复上次的设备状态，用户体验连贯。

但Redux不是没有代价。设备数量多的时候，每次消息到达都触发整个store的diff，性能会下降。所以后面我们引入了reselect做记忆化选择器，只让真正变化的组件重渲染。

1.4 HOC在权限与设备类型复用中的价值

项目里有三种角色：管理员、普通用户、访客。管理员能控制所有设备，普通用户只能控制自己房间的，访客只能看不能控。如果每个设备组件里都写一遍权限判断，代码会臃肿到无法维护。

HOC（高阶组件）在这里的作用是横切关注点抽离。我们写了withPermission、withDeviceStatus、withLoading三个HOC，设备组件只需要关心自己怎么渲染，权限校验、状态订阅、加载态全部由HOC注入。这样新增一种设备类型时，只需要写一个纯展示组件，套上HOC就能用。

2. MQTT通信层核心细节与实操要点

MQTT这部分是整个项目最容易出问题的环节。协议本身不复杂，但Topic设计、QoS选择、断线重连、消息去重这几个点如果没处理好，线上会出现设备状态不同步、指令丢失、App卡死等各种诡异现象。

2.1 Topic命名规范与设备寻址

Topic设计是MQTT落地的第一道坎。我们最初用device/001/status这种扁平结构，设备一多就乱了。后来改成层级结构：

TEXT
home/{homeId}/room/{roomId}/device/{deviceId}/status
home/{homeId}/room/{roomId}/device/{deviceId}/command
home/{homeId}/room/{roomId}/device/{deviceId}/event

这样设计的好处是通配符订阅非常方便。App进入某个房间时，只需要订阅home/123/room/456/device/+/status，就能收到该房间所有设备的状态更新。+是单层通配符，#是多层通配符，但#要慎用，订阅home/#会把所有消息都拉过来，设备多了之后App处理不过来。

注意：Topic里不要用中文和特殊字符，虽然MQTT协议本身允许UTF-8，但某些Broker和客户端库对中文Topic支持不一致，排查起来很痛苦。

2.2 QoS等级选择与消息可靠性

MQTT有三个QoS等级，选错了要么丢消息要么性能差。

QoS等级 语义 适用场景 本项目选择
QoS 0 最多一次 高频传感器数据 温湿度上报
QoS 1 至少一次 控制指令 开关、调节指令
QoS 2 恰好一次 计费、关键操作 门锁状态变更

温湿度数据我们用QoS 0，因为丢一两条无所谓，下一秒又来了。控制指令用QoS 1，确保设备收到，但可能重复，所以设备端做了指令去重，每条指令带一个msgId，收到重复的直接丢弃。门锁这种涉及安全的用QoS 2，虽然开销大，但绝不能出错。

2.3 断线重连与心跳参数调优

移动端网络切换频繁，4G切WiFi、进电梯断网都是常态。MQTT客户端的重连策略直接决定用户体验。

我们用的是mqtt.js，关键配置如下：

JAVASCRIPT
const client = mqtt.connect('wss://broker.example.com:8084/mqtt', {
clientId: `app_${userId}_${Date.now()}`,
keepalive: 30,
clean: false,
reconnectPeriod: 2000,
connectTimeout: 10000,
resubscribe: true,
will: {
topic: `home/${homeId}/app/${userId}/offline`,
payload: 'offline',
qos: 1,
retain: true
}
})

keepalive: 30表示30秒没发心跳就认为断线，这个值不能太小，移动端频繁发心跳耗电；也不能太大，断线发现不及时。clean: false配合固定的clientId，可以让Broker保留会话，重连后自动收到断线期间的消息。will消息用于App异常退出时通知服务器，服务器再推送给其他家庭成员。

实操心得：reconnectPeriod设成2000ms是经过测试的。设500ms会在弱网下疯狂重连耗电，设5000ms用户感觉恢复太慢。另外重连成功后一定要重新订阅Topic，虽然resubscribe: true会自动处理，但某些Broker版本有bug，手动再订阅一次更保险。

2.4 消息去重与顺序保证

QoS 1会导致消息重复，QoS 0可能乱序。我们在应用层做了两层处理。

第一层是消息ID去重。每条消息payload里带msgId，App维护一个最近100条msgId的Set，收到重复的直接忽略。第二层是时间戳排序。设备状态消息带timestamp，Redux reducer里比较新旧时间戳，旧消息不覆盖新状态。

JAVASCRIPT
// reducer片段
case 'DEVICE_STATUS_UPDATE':
const existing = state.devices[action.payload.deviceId]
if (existing && existing.timestamp >= action.payload.timestamp) {
return state
}
return {
...state,
devices: {
...state.devices,
[action.payload.deviceId]: action.payload
}
}

这两层处理之后，线上再没出现过状态回跳的问题。

3. React Native端实操过程与核心环节实现

移动端这部分我按实际开发顺序来拆，从项目初始化到MQTT接入、Redux配置、HOC封装、UI实现，每一步都给出可直接参考的代码和配置。

3.1 项目初始化与关键依赖安装

初始化用React Native CLI，不用Expo，因为后面要桥接原生模块做蓝牙配网。

BASH
npx react-native init SmartHomeApp --template react-native-template-typescript
cd SmartHomeApp
npm install mqtt redux react-redux redux-thunk reselect redux-persist
npm install @react-native-async-storage/async-storage
npm install react-native-vector-icons react-native-svg

TypeScript是必须的，设备状态结构复杂，没有类型提示写起来很容易出错。redux-persist配合AsyncStorage做状态持久化，reselect做选择器记忆化。

3.2 MQTT客户端封装与生命周期管理

不要在组件里直接创建MQTT连接，否则组件卸载重连会导致多个连接。我们封装了一个单例的MqttService：

TYPESCRIPT
class MqttService {
private client: MqttClient | null = null
private subscriptions: Map<string, (topic: string, payload: any) => void> = new Map()
 
connect(config: MqttConfig) {
if (this.client?.connected) return
this.client = mqtt.connect(config.url, {
clientId: config.clientId,
keepalive: 30,
clean: false,
reconnectPeriod: 2000,
will: config.will
})
 
this.client.on('connect', () => {
console.log('MQTT connected')
this.resubscribeAll()
})
 
this.client.on('message', (topic, message) => {
const handler = this.findHandler(topic)
if (handler) {
try {
handler(topic, JSON.parse(message.toString()))
} catch (e) {
console.error('MQTT message parse error', topic, e)
}
}
})
 
this.client.on('error', (err) => {
console.error('MQTT error', err)
})
}
 
subscribe(topic: string, handler: (topic: string, payload: any) => void) {
this.subscriptions.set(topic, handler)
this.client?.subscribe(topic, { qos: 1 })
}
 
publish(topic: string, payload: object, qos: 0 | 1 | 2 = 1) {
this.client?.publish(topic, JSON.stringify(payload), { qos })
}
}

这个Service在App启动时初始化，在App.tsx的useEffect里调用connect，在卸载时end。所有设备组件通过Redux action触发publish，通过MQTT message触发dispatch，组件本身不直接碰MQTT。

3.3 Redux store结构设计与持久化配置

store结构直接决定了后续开发顺不顺手。我们的设计原则是按领域分片，不按页面分片：

TYPESCRIPT
interface RootState {
auth: {
userId: string
homeId: string
role: 'admin' | 'user' | 'guest'
token: string
}
devices: {
[deviceId: string]: {
id: string
type: 'light' | 'curtain' | 'ac' | 'sensor' | 'lock'
name: string
roomId: string
online: boolean
status: Record<string, any>
timestamp: number
}
}
rooms: {
[roomId: string]: {
id: string
name: string
deviceIds: string[]
}
}
ui: {
loading: boolean
error: string | null
}
}

持久化只持久化auth和devices的静态部分，online状态和ui不持久化，因为重启后这些会重新从MQTT获取。

TYPESCRIPT
const persistConfig = {
key: 'root',
storage: AsyncStorage,
whitelist: ['auth', 'devices'],
blacklist: ['ui']
}

注意：devices持久化时要把online字段过滤掉，否则App重启后所有设备都显示在线，实际可能已经离线。我们在redux-persist的transform里做了处理。

3.4 HOC封装：withDeviceStatus与withPermission

先看withDeviceStatus，它的职责是订阅设备状态并注入props：

TYPESCRIPT
function withDeviceStatus<T extends { deviceId: string }>(
WrappedComponent: React.ComponentType<T & { device: Device }>
) {
return function WithDeviceStatus(props: T) {
const device = useSelector((state: RootState) =>
state.devices[props.deviceId]
)
if (!device) return null
return <WrappedComponent {...props} device={device} />
}
}

withPermission负责权限校验：

TYPESCRIPT
function withPermission<T extends { deviceId: string }>(
WrappedComponent: React.ComponentType<T>,
requiredRole: 'admin' | 'user' | 'guest'
) {
return function WithPermission(props: T) {
const role = useSelector((state: RootState) => state.auth.role)
const device = useSelector((state: RootState) =>
state.devices[props.deviceId]
)
const roleLevel = { admin: 3, user: 2, guest: 1 }
if (roleLevel[role] < roleLevel[requiredRole]) {
return <NoPermissionView />
}
if (role === 'user' && device?.roomId !== getUserRoom()) {
return <NoPermissionView />
}
return <WrappedComponent {...props} />
}
}

使用的时候组合起来：

TYPESCRIPT
const LightCard = withPermission(
withDeviceStatus(LightCardBase),
'user'
)

这样LightCardBase只需要关心灯光怎么渲染，权限和状态全部由HOC处理。新增设备类型时，写一个Base组件，套上同样的HOC就能用。

3.5 设备控制指令的发送与状态确认

用户点击开关后，不能立刻改本地状态，否则设备没收到指令时会出现“界面开了但灯没亮”的情况。我们的流程是：

  1. 用户点击开关
  2. dispatch一个DEVICE_COMMAND_PENDING action，UI显示loading
  3. 通过MQTT publish指令到command topic
  4. 设备执行后publish新状态到status topic
  5. App收到status消息，dispatch DEVICE_STATUS_UPDATE，UI更新
  6. 如果3秒内没收到status更新，dispatch DEVICE_COMMAND_TIMEOUT，UI回滚并提示
TYPESCRIPT
const sendCommand = (deviceId: string, command: object) => async (dispatch, getState) => {
const state = getState()
const device = state.devices[deviceId]
const msgId = `${Date.now()}_${Math.random().toString(36).slice(2)}`
dispatch({ type: 'DEVICE_COMMAND_PENDING', payload: { deviceId, msgId } })
MqttService.publish(
`home/${state.auth.homeId}/room/${device.roomId}/device/${deviceId}/command`,
{ ...command, msgId, timestamp: Date.now() },
1
)
setTimeout(() => {
const current = getState().devices[deviceId]
if (current?.lastMsgId !== msgId) {
dispatch({ type: 'DEVICE_COMMAND_TIMEOUT', payload: { deviceId } })
}
}, 3000)
}

这个超时回滚机制上线后，用户投诉“点了没反应”的量下降了90%以上。

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

这部分是我在实际开发和运维中真实遇到的问题，按出现频率排序，每个都给出排查思路和解决方案。

4.1 App启动白屏问题

React Native启动白屏是老生常谈的问题，在智能家居App里尤其明显，因为启动时要初始化MQTT、恢复Redux状态、拉取设备列表，任何一个环节卡住都会白屏。

排查步骤：

  1. 先确认是JS层白屏还是原生层白屏。用adb logcat看有没有ReactNativeJS的报错。
  2. 如果是JS层，在index.js里加AppRegistry.registerComponent前后的日志，看卡在哪一步。
  3. 常见原因是redux-persist恢复状态时异步操作没处理好，PersistGate的loading属性设成了null，导致一直不渲染。

解决方案：

TYPESCRIPT
const App = () => {
const [ready, setReady] = useState(false)
useEffect(() => {
const init = async () => {
await MqttService.connect(mqttConfig)
await restorePersistedState()
setReady(true)
}
init()
}, [])
if (!ready) return <SplashScreen />
return <MainNavigator />
}

用一个显式的ready状态控制，比PersistGate更可控。SplashScreen显示品牌Logo和加载动画，用户感知上比白屏好很多。

4.2 MQTT订阅收不到消息

这个问题排查起来最耗时，因为涉及Broker、网络、客户端三方。我整理了一个速查表：

现象 可能原因 排查方法 解决方案
完全收不到 Topic写错 用MQTTX工具订阅同一Topic 核对Topic层级和通配符
偶尔收不到 QoS不匹配 检查publish和subscribe的QoS 统一用QoS 1
重连后收不到 会话未恢复 检查clean和clientId clean设false，clientId固定
特定设备收不到 设备未发布 抓包看设备是否publish 检查设备端MQTT配置
消息延迟大 Broker负载高 看Broker监控 扩容或优化Topic设计

实操心得：调试MQTT一定要用MQTTX或MQTT Explorer这类图形化工具，先确认Broker层面消息是通的，再排查App端。我见过好几次是设备端根本没发消息，结果在App端查了半天。

4.3 Redux状态更新但组件不重渲染

这是React Redux的经典问题。原因通常是mapStateToProps返回了新对象，导致浅比较失败。

错误写法：

TYPESCRIPT
const mapStateToProps = (state) => ({
device: {
...state.devices[deviceId],
roomName: state.rooms[state.devices[deviceId].roomId].name
}
})

每次返回新对象，connect的浅比较永远为false，组件每次都重渲染。

正确写法是用reselect：

TYPESCRIPT
const selectDeviceWithRoom = createSelector(
[(state, deviceId) => state.devices[deviceId],
(state) => state.rooms],
(device, rooms) => device ? {
...device,
roomName: rooms[device.roomId]?.name
} : null
)

reselect会缓存计算结果，只有依赖的state变化时才重新计算，返回的引用不变，组件就不重渲染。

4.4 设备指令下发后状态不同步

这个问题的根源通常是设备端和App端对状态的理解不一致。比如空调，App发的是{ mode: 'cool', temp: 26 }，设备端可能只认{ mode: 1, temp: 260 }，需要做一层映射。

我们的解决方案是在MQTT消息和Redux action之间加一个适配层：

TYPESCRIPT
const deviceAdapters = {
ac: {
toDevice: (status) => ({
mode: { cool: 1, heat: 2, fan: 3 }[status.mode],
temp: status.temp * 10
}),
fromDevice: (raw) => ({
mode: { 1: 'cool', 2: 'heat', 3: 'fan' }[raw.mode],
temp: raw.temp / 10
})
}
}

所有设备类型都定义自己的adapter，MQTT消息进来先过fromDevice，指令出去先过toDevice。这样设备端协议变了，只需要改adapter，不用动业务逻辑。

4.5 弱网环境下指令丢失

移动端在弱网下，MQTT publish可能失败但不会报错。我们的处理是指令队列+重试：

TYPESCRIPT
class CommandQueue {
private queue: Command[] = []
private retryCount = 0
private maxRetry = 3
 
async send(command: Command) {
this.queue.push(command)
await this.flush()
}
 
private async flush() {
while (this.queue.length > 0) {
const cmd = this.queue[0]
try {
await MqttService.publishAsync(cmd.topic, cmd.payload, 1)
this.queue.shift()
this.retryCount = 0
} catch (e) {
this.retryCount++
if (this.retryCount >= this.maxRetry) {
this.queue.shift()
notifyUser('指令发送失败，请检查网络')
} else {
await sleep(1000 * this.retryCount)
}
}
}
}
}

配合MQTT的QoS 1，指令到达率能到99.9%以上。

4.6 内存泄漏与连接未释放

React Native里MQTT连接如果没在组件卸载时清理，会导致内存泄漏和重复订阅。我们的做法是所有MQTT订阅都在Service层统一管理，组件通过Redux action触发订阅，组件卸载时dispatch UNSUBSCRIBE action，Service层根据引用计数决定是否真正取消订阅。

TYPESCRIPT
class SubscriptionManager {
private refCounts: Map<string, number> = new Map()
 
subscribe(topic: string) {
const count = this.refCounts.get(topic) || 0
if (count === 0) {
MqttService.subscribe(topic, this.handleMessage)
}
this.refCounts.set(topic, count + 1)
}
 
unsubscribe(topic: string) {
const count = this.refCounts.get(topic) || 0
if (count <= 1) {
MqttService.unsubscribe(topic)
this.refCounts.delete(topic)
} else {
this.refCounts.set(topic, count - 1)
}
}
}

这样多个组件订阅同一个Topic时，只有最后一个组件卸载才会真正取消订阅，避免了重复订阅和过早取消的问题。

5. 性能优化与线上稳定性经验

项目上线半年，日活从几百涨到几万，中间做了几轮性能优化，这里把有效的几招分享出来。

5.1 设备列表虚拟化与分页加载

一个家庭可能有几十个设备，全部渲染会卡顿。我们用FlatList做虚拟化，配合getItemLayout固定行高，滚动帧率从30fps提升到55fps以上。

TYPESCRIPT
<FlatList
data={deviceIds}
renderItem={({ item }) => <DeviceCard deviceId={item} />}
keyExtractor={(item) => item}
getItemLayout={(_, index) => ({
length: CARD_HEIGHT,
offset: CARD_HEIGHT * index,
index
})}
initialNumToRender={8}
maxToRenderPerBatch={4}
windowSize={5}
removeClippedSubviews={true}
/>

removeClippedSubviews在Android上效果明显，但iOS上偶有闪烁，我们做了平台判断。

5.2 MQTT消息批量处理

设备状态更新频繁时，每条消息都dispatch会导致Redux频繁更新。我们做了消息缓冲，100ms内的消息合并成一次dispatch：

TYPESCRIPT
const messageBuffer: Message[] = []
let flushTimer: NodeJS.Timeout | null = null
 
function bufferMessage(msg: Message) {
messageBuffer.push(msg)
if (!flushTimer) {
flushTimer = setTimeout(() => {
store.dispatch(batchUpdateDevices(messageBuffer))
messageBuffer.length = 0
flushTimer = null
}, 100)
}
}

这个优化让Redux的action数量下降了70%，UI卡顿明显减少。

5.3 线上错误监控与日志上报

智能家居App的问题往往和具体设备、网络环境相关，没有日志根本没法排查。我们接入了错误监控，关键节点都打点：

  • MQTT连接成功/失败/重连
  • 指令发送/超时/失败
  • 设备状态更新
  • 页面渲染耗时

日志上报做了采样和脱敏，正常情况只上报1%的日志，错误情况100%上报。脱敏方面，设备ID和用户ID都做了哈希处理，不涉及隐私。

5.4 灰度发布与回滚机制

RN的CodePush支持灰度发布，我们按用户ID哈希分成10%、50%、100%三批推送。每批观察24小时，重点看崩溃率和MQTT连接成功率两个指标。一旦异常，立即回滚到上一个版本。

这个机制救过我们一次：有个版本在特定Android机型上MQTT连接会失败，灰度10%时发现，回滚后只影响了少量用户。

6. 后续扩展方向与个人体会

这套架构目前支撑了灯光、窗帘、空调、传感器、门锁五类设备，后续要加摄像头和场景联动，架构上不需要大改。摄像头走WebRTC做视频流，场景联动在Redux里加一个scenes分片，用中间件监听设备状态变化触发场景动作。

我个人在实际操作中的体会是，智能家居项目最难的不是技术选型，而是设备协议的碎片化。每个厂商的MQTT Topic设计、payload格式、QoS策略都不一样，适配层会越写越厚。所以前期一定要把adapter模式设计好，把设备差异隔离在adapter里，业务层保持干净。另外，MQTT的调试工具一定要提前准备好，MQTTX和MQTT Explorer这两个我几乎每天都在用，没有它们排查问题效率会低很多。

最后分享一个小技巧：设备状态的时间戳一定要用设备端的时间，不要用App端的时间。App端时间可能因为用户改系统时间而不准，设备端时间虽然也可能不准，但至少是单调递增的，做状态排序更可靠。如果设备端没有RTC，可以用Broker的server timestamp，在消息里带一个brokerTs字段作为兜底。

Redux中间件在React和React-Native项目架构中的应用实践
本文介绍了Redux中间件在React和React-Native项目中的应用实践，详细探讨了react-redux、Store、Action、Reducer、applyMiddleware以及常用中间件如react-thunk、reselect、redux-actions和redux-saga的分析。通过实例代码，阐述了它们在项目中的作用和使用技巧，旨在帮助开发者更好地理解和应用这些概念。
天外野草
4645
React Native 实战：构建电商 App
本文详细介绍了使用React Native开发电商App的过程，包括项目初始化、路由设置、性能优化、封装组件等内容。作者强调了React Native在开发效率、热更新等方面的优势，并对比了其他技术如Weex和Flutter。课程通过实际项目演示，帮助开发者从零开始掌握React Native，打造功能完善的电商应用。
蔚1
6099
react-native-redux-toolkit-starter-app：快速启动React Native项目
本文介绍了react-native-redux-toolkit-starter-app，这是一个基于React Native的项目模板，集成Redux Toolkit和Saga，支持最新版本和Fabric架构。它采用流行技术栈，适用于快速原型、跨平台及中大型项目开发，具有最新技术支持、开箱即用等特点，能节省开发时间。
钟新骅
1034
React-Native实战二（清理app缓存＋Redux ）
本文介绍了如何在React-Native项目中使用Redux进行页面间通信和管理App缓存。通过创建store、定义action和reducer，详细阐述了Redux的工作流程，帮助理解如何在组件之间传递数据并更新状态，从而实现页面的动态刷新。
vv_小虫
9618
React Native Redux 使用指南 redux-toolkit
本文是 React Native Redux 使用指南，介绍了 Redux、React-Redux、@reduxjs/toolkit 的关系。详细说明了 @reduxjs/toolkit 的基本使用步骤，总结了 Redux Toolkit 核心概念和数据流向。还阐述了 Redux 持久化存储的配置方法，包括安装依赖、配置存储及集成 PersistGate 等。
万少-
1766
React Native集成Redux框架讲解与应用
本文详细介绍了如何在React Native项目中集成和使用Redux框架。通过创建store、action和reducer，管理全局state，解决复杂页面状态管理问题。文中以登录为例，展示了从安装依赖到连接组件的完整流程，并解释了每个部分的作用。
jjhappyforever.
7061
React-Native实战之（清理app缓存＋Redux合成）
本文介绍了在React Native应用中实现清理缓存功能的详细步骤，包括在Android和iOS平台上的实现，并探讨了如何通过Redux进行状态管理以解决跨页面数据交互的问题。作者分享了在Android中清理OkHttp和Fresco缓存的代码，并提到iOS实现的简便性。文章还提及了在JS中调用原生模块时遇到的异步操作挑战以及Redux在解决页面间数据同步中的作用。
vv_小虫
13932
React Native之Redux使用详解之Actions（29）
本文详细介绍了React Native中Redux的使用，特别是Actions的概念和作用。Actions是Store的唯一数据源，它们必须包含一个type属性，通常是字符串常量。Action Creator是创建Action的函数，可以异步执行并处理副作用。在Redux中，不直接在Action Creator中dispatch，而是通过bindActionCreators等方式绑定到dispatch。
MNLoser
6999
React Native Airbnb Clone：如何实现Redux状态管理与React Navigation集成
本文详解React Native Airbnb克隆项目中Redux状态管理与React Navigation的协同实现，涵盖Redux Store配置、Actions/Reducers设计、底部标签导航器与堆栈导航器集成，以及如何通过Redux统一管理导航状态并从组件访问该状态，突出移动应用中状态驱动导航的核心实践。
龙香令Beatrice
992
Redux 在 React Native 中的使用流程
Redux 是用于 JavaScript 应用的状态管理工具，常用于 React 和 React Native。本文介绍在 React Native 中使用 Redux 的完整流程，包括安装相关包、创建 Store、定义 Reducer 和 Actions、提供 Store、连接组件，还可选用 Redux DevTools 调试。完成这些步骤，应用就能用 Redux 管理状态。
爱lv行
1223
React Native+MQTT智能家居实战：解决白屏、连接失败与真机控制
本文详解基于React Native与原生MQTT协议构建真实智能家居客户端的全流程，涵盖树莓派Mosquitto服务部署、iOS/Android真机白屏优化、MQTT高可靠性连接设计（QoS1、指数退避重连）、Redux Toolkit状态同步及本地缓存兜底，并针对连接失败、状态不同步、服务崩溃等高频问题提供根因分析与实操解决方案。
天马行空的味道
238
React Native状态管理终极指南：Jotai与Redux实战对比解析
本文深度对比React Native中两大主流状态管理方案——Redux与Jotai。涵盖二者的设计理念、核心机制（如单状态树vs原子化）、适用场景（大型项目vs中小规模应用）、性能表现及开发体验差异，并结合Create React Native App给出集成实践建议，助力开发者依据项目复杂度、团队技术栈和维护需求作出理性选型。
柏纲墩Dean
748
将Redux添加到您的React Native App
本文详细介绍了在React Native应用中使用Redux进行状态管理的方法。包括安装React-Redux，理解Reducer和Action的概念，以及如何在组件中使用这些概念。文章还讲解了如何使用Redux-Persist保持数据持久化。
weixin_26750481
225
终极指南：如何用React Native快速构建zigbee2mqtt跨平台智能家居管理App
本文详细介绍如何使用React Native构建跨平台的zigbee2mqtt管理应用，涵盖MQTT协议通信、设备状态同步、控制组件设计及性能优化等内容。通过本教程可实现智能家居设备的高效管理，并解决传统控制方式的局限性。
申子琪
350
react-native-redux 简易教程
本文是关于React-Native的简易教程，涵盖了React-Native的介绍、环境搭建、在Android中的集成，以及深入讲解了React-Native的工程结构、生命周期、React与Redux的结合，包括Redux的安装、原理和重要概念。通过实例解析了如何在React-Native中使用Redux进行状态管理。
雨季莫忧离
2326
React Native中使用Redux
本文通过一个简单的计数器应用，详细介绍了如何使用Redux进行跨组件的状态管理。从安装必要的Redux包开始，到创建actions、reducers，再到集成React应用，最后在页面上实践，完整展示了Redux的基本工作流程。
孙先森i
2743
快速构建React Native应用的利器：react-native-redux-starter-kit
react-native-redux-starter-kit是专为React Native开发者设计的开源项目，可助其快速搭建基于React Native和Redux的移动应用。它技术栈丰富，适用于快速原型、跨平台开发等场景，具有开箱即用、状态管理强大等特点，还给出了使用步骤。
毕腾鉴Goddard
1274
揭秘react-native-test-app架构：为什么它是React Native开发者的必备工具
react-native-test-app是React Native官方推荐的跨平台测试应用工具，支持iOS、Android、Windows和macOS。其核心架构包含多平台支持层、测试框架集成层和配置管理系统，提供简化环境配置、一致跨平台体验、全流程测试支持及高度可定制化等优势，显著提升React Native开发与测试效率。
井章博Church
1113
在react native中使用redux
本文介绍了如何在React Native项目中集成Redux，包括创建项目、安装依赖、定义reducers、actions以及设置store，并在App.js中传递store到containers的Main.js页面，实现最基础的Redux集成步骤。
542
React-Redux移动端适配终极指南：React Native集成完全教程
本文详解React Native中集成React-Redux的全流程，涵盖环境准备（React 17+/RN 0.49+）、Store创建与Provider配置、useSelector/useDispatch核心Hook用法、Redux Toolkit Slice构建、性能优化（memo/shallowEqual/batch）、异步处理（createAsyncThunk）及调试工具（Redux DevTools/React Native Debugger）配置，强调移动端状态管理的最佳实践。
史多苹Thomas
708