别再写面条代码了：用 React 状态机拯救你崩溃的 Android 模拟器调试

各位好。

今天我们不谈什么高深莫测的算法，也不聊什么晦涩难懂的架构模式。今天我们聊点硬核、带点“火药味”，甚至可能让你半夜三点在工位上拍大腿的事儿——Android 模拟器 ADB 指令分发。

想象一下这个场景：你正在开发一个基于 React 的跨端自动化工具，或者是一个可视化的 ADB 调试面板。你的用户（或者你自己）坐在屏幕前，像个暴君一样点击按钮：“安装应用！”、“截图！”、“发日志！”、“重启设备！”。

与此同时，后台的 Android 模拟器正在思考人生，或者干脆死机了。你的代码呢？你的回调函数是不是像俄罗斯套娃一样，一层套一层，深不见底？

今天，我们要讲的不是怎么写更快的 React 组件，而是怎么用 状态机 这把“手术刀”，把那一团乱麻的 ADB 指令分发逻辑，切得整整齐齐。

准备好了吗？咱们开始。

---

第一章：ADB 的“后院”很乱

在动手写代码之前，咱们得先认清现实。ADB（Android Debug Bridge）是个好东西，它是上帝视角。但上帝视角往往意味着混乱。

为什么说 ADB 指令分发是“地狱级”的？

1. 异步与回调地狱：adb install app.apk 这句话说完，它不会立马告诉你成功还是失败。它可能需要 5 秒，也可能需要 5 分钟，或者直接报错。如果你用了 setTimeout 或者 Promise.then 的嵌套，你很快就会发现，你的代码已经变成了意大利面。
2. 多设备并发：你有一台真机，两台模拟器。你想把指令发给模拟器 1，结果手一抖发到了模拟器 2，或者同时发给了两个。这就像对着两个吵架的人同时下达指令，结果谁都没听懂。
3. 状态的不确定性：模拟器没启动？命令执行中？文件传输中断？这些状态不是线性的。你不能简单地“下一步、下一步”，因为“下一步”可能是个错误。

传统的 React 处理方式通常是 useState 堆砌：loading, error, data, success。但这在小规模时还行，一旦指令流变复杂，你的组件就会变成一个巨大的 if-else 堆肥场。

这时候，状态机登场了。

---

第二章：把“混乱”抽象为“状态”

状态机，简单来说，就是给你脑子里的混乱画个框框。在这个框框里，系统只能处于几种特定的状态之一，并且只能通过特定的动作（事件）从一个状态跳到另一个状态。

对于 ADB 调度器，我们的状态大概是这样的：

• IDLE（空闲）：一切风平浪静，等待你的指令。
• CHECKING_DEVICES（设备检查）：就像相亲前先去查户口，正在跑 adb devices 看看谁在线。
• CONNECTING（连接中）：正在建立长连接，或者尝试连接某个特定的端口。
• EXECUTING_COMMAND（指令执行中）：比如正在安装 APK，或者正在拖拽文件。
• STREAMING_LOGS（日志流式传输）：这是最骚气的状态。你要监听 logcat，数据是源源不断涌上来的，不是一次性的。
• ERROR（报错）：模拟器挂了，或者权限被拒。
• SUCCESS（成功）：任务圆满完成。

一旦我们把这些状态定义清楚，React 就不需要去猜“现在发生了什么”，它只需要问：“嘿，机器现在在哪个状态？”

为了在 React 里优雅地使用这个概念，我们得请出一位重量级嘉宾——XState。它是状态机界的泰斗，专门用来处理这种复杂的、有副作用的逻辑。

---

第三章：架构设计——让 React 保持干净

这里有一个非常重要的设计原则：UI（React）不应该直接操作 ADB 原生命令。

React 是声明式的，它是 UI 的主宰。而 ADB 是命令式的，它是操作系统的底层暴徒。如果你让 React 直接去调用 exec('adb ...')，你很快就会把 React 的 useEffect 弄成一座坟墓，里面埋葬着各种 setTimeout 和手动清理函数。

正确的姿势是：

1. React 只负责画 UI，显示“加载中…”、“Error 404”，并监听状态变化。
2. Service（后端服务）：一个基于 Node.js 的微服务（或者就在 Electron 主进程中）。它负责执行真正的 ADB 命令，维护状态机，并把结果推送给 React。

咱们用 XState 来定义这个服务的行为。

3.1 定义机器（Machine Definition）

import { setup, assign, fromPromise } from 'xstate';

// 模拟一个 ADB 命令执行器（Node.js 环境）
const adbExecutor = fromPromise(async ({ input }: { input: { command: string[], deviceId?: string } }) => {
  const { command, deviceId } = input;

  // 拼接命令：如果指定了 deviceId，加上 -s 参数，就像给快递员写上门地址
  const finalCmd = deviceId ? ['adb', '-s', deviceId, ...command] : ['adb', ...command];

  return new Promise((resolve, reject) => {
    // 这里是 Node.js 的 child_process.exec，实际项目中可能会用到 spawn 处理流
    const child = require('child_process').exec(finalCmd.join(' '));

    let output = '';
    let error = '';

    child.stdout.on('data', (data) => output += data);
    child.stderr.on('data', (data) => error += data);

    child.on('close', (code) => {
      if (code === 0) {
        resolve({ output, code });
      } else {
        reject(new Error(`ADB exited with code ${code}: ${error}`));
      }
    });
  });
});

// 定义状态机
const adbMachine = setup({
  types: {
    context: {} as {
      status: string;
      logs: string[];
      lastError: string | null;
      deviceList: string[];
      currentDevice: string | null;
    },
    events: {} as 
      | { type: 'CONNECT_DEVICES' }
      | { type: 'SELECT_DEVICE', deviceId: string }
      | { type: 'RUN_COMMAND', command: string[] }
      | { type: 'RESET' };
  },
  actors: {
    listDevices: fromPromise(async () => {
      // 这里稍微写点正则来解析 'List of devices attachedntemulator-5554tdevice'
      const { execSync } = require('child_process');
      const output = execSync('adb devices').toString();
      const lines = output.split('n').slice(1); // 去掉表头
      return lines
        .map(line => line.trim())
        .filter(line => line !== '' && line.includes('device'))
        .map(line => line.split('t')[0]);
    }),
    executeCommand: adbExecutor
  }
}).createMachine({
  id: 'adbController',
  initial: 'idle',
  context: {
    status: '准备就绪',
    logs: [],
    lastError: null,
    deviceList: [],
    currentDevice: null
  },
  states: {
    idle: {
      on: {
        CONNECT_DEVICES: 'listing_devices'
      }
    },
    listing_devices: {
      entry: assign({
        status: '正在扫描设备...'
      }),
      invoke: {
        src: 'listDevices',
        onDone: {
          target: 'idle',
          actions: assign({
            deviceList: ({ event }) => event.output,
            status: ({ event }) => `发现 ${event.output.length} 个设备`
          })
        },
        onError: {
          target: 'error',
          actions: assign({
            lastError: ({ event }) => event.error.message,
            status: '设备扫描失败'
          })
        }
      }
    },
    selected_device: {
      initial: 'ready',
      states: {
        ready: {
          on: {
            RUN_COMMAND: {
              target: 'executing',
              actions: assign({
                status: '执行指令中...'
              })
            }
          }
        },
        executing: {
          invoke: {
            src: 'executeCommand',
            input: ({ context, event }) => ({
              command: event.command,
              deviceId: context.currentDevice
            }),
            onDone: {
              target: 'ready',
              actions: assign({
                status: '指令执行成功',
                logs: ({ context, event }) => [...context.logs, `> ${event.output.output}`]
              })
            },
            onError: {
              target: 'error',
              actions: assign({
                status: '指令执行失败',
                lastError: ({ event }) => event.error.message
              })
            }
          }
        }
      }
    },
    error: {
      on: {
        RESET: 'idle'
      }
    }
  }
});

这段代码看起来挺长的，对吧？但请注意它的简洁性。我们没有写 if (loading) return，没有写 try-catch 包裹整个组件。所有的逻辑都封装在机器里。

---

第四章：React 组件——UI 的圣洁之地

现在，我们的 Service 已经能干活了。接下来，我们来看看 React 组件。它应该像一张白纸一样干净。

import React, { useEffect } from 'react';
import { useMachine } from '@xstate/react';
import { adbMachine } from './adbMachine';

export const ADBDashboard: React.FC = () => {
  const [state, send] = useMachine(adbMachine);

  // 监听状态变化，更新 UI
  useEffect(() => {
    console.log('Current State:', state.value);
  }, [state]);

  return (
    <div style={{ padding: '20px', fontFamily: 'monospace', maxWidth: '600px', margin: '0 auto' }}>
      <h1>ADB 控制台</h1>

      <div style={{ border: '1px solid #ccc', padding: '10px', marginBottom: '20px', borderRadius: '5px' }}>
        <h2>状态监控</h2>
        <p>当前状态: <strong>{state.context.status}</strong></p>
        <p>当前设备: <strong>{state.context.currentDevice || '未选择'}</strong></p>
        {state.context.lastError && (
          <div style={{ color: 'red', background: '#ffeeee', padding: '5px' }}>
            错误: {state.context.lastError}
          </div>
        )}
      </div>

      <div style={{ border: '1px solid #ccc', padding: '10px', height: '300px', overflow: 'auto', marginBottom: '20px' }}>
        <h2>日志输出</h2>
        {state.context.logs.map((log, idx) => (
          <div key={idx}>{log}</div>
        ))}
      </div>

      <div style={{ display: 'flex', gap: '10px' }}>
        {/* 1. 扫描设备 */}
        <button 
          onClick={() => send({ type: 'CONNECT_DEVICES' })}
          disabled={state.matches('listing_devices')}
        >
          {state.matches('listing_devices') ? '扫描中...' : '刷新设备列表'}
        </button>

        {/* 2. 选择设备（假设列表不为空） */}
        {state.context.deviceList.length > 0 && (
          <select 
            onChange={(e) => send({ type: 'SELECT_DEVICE', deviceId: e.target.value })}
            value={state.context.currentDevice || ''}
            style={{ padding: '5px' }}
          >
            <option value="">请选择模拟器...</option>
            {state.context.deviceList.map((id) => (
              <option key={id} value={id}>{id}</option>
            ))}
          </select>
        )}

        {/* 3. 执行命令 */}
        {state.context.currentDevice && (
          <button 
            onClick={() => send({ type: 'RUN_COMMAND', command: ['shell', 'getprop', 'ro.build.version.release'] })}
            disabled={state.matches('executing')}
          >
            {state.matches('executing') ? '运行中...' : '获取系统版本'}
          </button>
        )}
      </div>
    </div>
  );
};

看到了吗？这就是 React 的美妙之处。组件里的代码读起来就像对话：
“如果状态是 executing，就禁用按钮”。
“如果选择了设备，就显示下拉菜单”。
“如果报错了，就显示红色的错误框”。

所有的“脏活累活”（解析 ADB 输出、处理超时、等待回调）都在 XState 的 invoke 和 actors 里完成了。React 只需要负责响应。

---

第五章：处理“并发”与“流”——状态机的进阶

这就够了吗？不够，我们的目标是用状态机处理“复杂”场景。

场景 A：连续指令

用户很暴躁，他点了一个“卸载”按钮，然后紧接着点了一个“重启”按钮。
如果是传统的回调，第二个按钮会覆盖第一个，或者两者冲突。
但在我们的状态机里，我们可以通过状态嵌套来解决。

如果你回想一下上面的代码，我们在 selected_device 下面有一个子状态 ready，还有一个子状态 executing。

selected_device/executing 状态会阻塞 selected_device/ready 状态。也就是说，当你点击“重启”按钮时，由于机器正在 executing 状态，它根本不会接收到 RUN_COMMAND 事件。

这就是状态机的保护机制：互斥。

场景 B：ADB Logcat 流

这是最棘手的。adb logcat 是一个流（Stream）。它不会像 install 那样执行完就给你一个结果。它会一直吐出日志，直到你杀掉进程。

这时候，我们需要一个特殊的状态：Stream。

// 修改我们的机器定义
const adbMachine = setup({...}).createMachine({
  id: 'adbController',
  initial: 'idle',
  context: { ... },
  states: {
    idle: { on: { CONNECT_DEVICES: 'listing_devices' } },
    listing_devices: { ... },

    // 新增：监听日志流
    streaming_logs: {
      invoke: {
        src: 'startLogStream', // 自定义 actor，开启一个后台流
        onDone: 'idle', // 或者流结束，回到 idle
        onError: 'error'
      },
      on: {
        STOP_LOGS: 'idle'
      }
    },

    selected_device: {
      initial: 'ready',
      states: {
        ready: {
          on: {
            START_LOGS: 'streaming_logs',
            RUN_COMMAND: 'executing'
          }
        },
        executing: { ... },
        // 在流式传输状态下，如果用户想发指令，应该怎么办？
        // 这是一个设计决策。
        // 方案1：禁止发指令（推荐，因为 Logcat 占用 IO）
        // 方案2：允许发指令，但可能影响日志抓取。
        // 这里我们选择方案1：
        executing: { on: { START_LOGS: 'streaming_logs' } } 
      }
    },
    error: { ... }
  }
});

在这里，streaming_logs 是一个长驻状态。它意味着“别点任何按钮，我正在疯狂打印日志”。这给用户极其清晰的 UI 反馈。

---

第六章：错误处理的艺术——如何优雅地翻车

在 ADB 操作中，翻车是常态。模拟器卡死、权限被拒、网络延迟、文件路径不对。

在状态机中，错误不仅仅是异常，它是一个状态。

看看我们的 error 状态：

error: {
  on: {
    RESET: 'idle'
  }
}

当发生错误时，机器会跳转到 error 状态。
在 React 组件中，你可以根据 state.matches('error') 渲染一个友好的模态框。

但是，我们还可以做得更好。给错误注入上下文。

// 在 xstate setup 中
const adbMachine = setup({
  actors: {
    executeCommand: fromPromise(async ({ input }) => {
       // ... 执行逻辑
    }).onError(({ event, context, spawn }) => {
       // 这是一个关键点！
       // 当发生错误时，我们可以 spawn 一个临时的错误日志 actor，或者在 context 里记录堆栈
       spawn({ type: 'LOG_ERROR', payload: event.error.message });
    })
  }
}).createMachine({
  // ...
  context: {
    errorLogs: []
  },
  states: {
    error: {
      // 我们可以从 context 中读取错误信息
      // 但更好的做法是直接跳转到一个 'show_error' 子状态
    }
  }
});

我们之前在代码里看到了 assign({ lastError: ... })。这确保了即使机器回到了 idle 状态，错误信息也不会丢失，因为它们被存在了 context 里。这就像给系统装了一个“黑匣子”。

---

第七章：UI 交互的微操——让用户不再困惑

光有逻辑不行，还得有好的 UI。

状态机给了我们一种叫 “状态驱动的 UI” 的能力。

假设你要做一个“应用安装”按钮。

1. 初始状态：按钮是灰色的（不可用）。
2. 扫描设备中：按钮变成“正在扫描…”（禁用）。
3. 选中设备：按钮变亮（可用）。
4. 点击安装：按钮变成“安装中…”，并且开始转圈（禁用）。中间弹出一个进度条。
5. 成功：按钮变回“安装”，旁边出现绿色的对勾。
6. 失败：按钮变回“安装”，旁边出现红色的感叹号。

在 React 中，这段逻辑如果用原生 JS 写，大概需要写 50 行 className 的条件判断。但在 XState 中，你只需要写一次：

<button disabled={state.matches('executing') || state.matches('listing_devices')}>
  {state.matches('listing_devices') ? '扫描中...' : 
   state.matches('executing') ? '安装中...' : 
   '安装应用'}
</button>

再看那个进度条：

{state.matches('executing') && (
  <div className="progress-bar">
    <div style={{ width: `${(state.context.progress || 0) * 100}%` }}></div>
  </div>
)}

注意那个 state.context.progress。如果我们想要更高级的功能，比如显示安装进度百分比，我们可以扩展机器：

const adbMachine = setup({...}).createMachine({
  context: {
    progress: 0, // 新增：进度 0-1
    // ...
  },
  states: {
    executing: {
      invoke: {
        src: 'executeCommand',
        onDone: {
          actions: assign({ progress: 1 })
        },
        onError: {
          actions: assign({ progress: 0 })
        }
        // 这里我们还没写具体的监听进度输出的逻辑，但这展示了状态如何驱动数据
      }
    }
  }
});

---

第八章：实战演练——一个完整的“分发”逻辑

现在，让我们把所有东西串起来，做一个稍微完整点的逻辑：指令分发器。

这个分发器需要知道：

1. 在哪个设备上跑？
2. 哪条指令？
3. 如果指令是 logcat，开启流。
4. 如果指令是 install，等待安装完成。
5. 如果指令是 pull（拉取文件），显示进度。

让我们用伪代码/TypeScript 结合的方式，展示一下这种逻辑是如何流动的：

const ADBDispatcher = () => {
  const [state, send] = useMachine(adbMachine);

  // 指令路由逻辑
  const handleCommand = (cmd: string) => {
    // 清空之前的日志
    send({ type: 'CLEAR_LOGS' });

    if (cmd.startsWith('logcat')) {
      send({ type: 'START_LOGS' });
    } else if (cmd.startsWith('install')) {
      send({ type: 'RUN_COMMAND', command: ['install', cmd.replace('install ', '')] });
    } else if (cmd.startsWith('screencap')) {
      send({ type: 'RUN_COMMAND', command: ['shell', cmd] });
    } else {
      // 通用 shell 命令
      send({ type: 'RUN_COMMAND', command: ['shell', cmd] });
    }
  };

  return (
    <div className="dispatcher-ui">
      {/* 设备选择器 */}
      <SelectDevice 
        devices={state.context.deviceList} 
        onSelect={(id) => send({ type: 'SELECT_DEVICE', deviceId: id })}
      />

      {/* 指令输入区 */}
      <Input 
        placeholder="输入指令 (例如: logcat, install app.apk)..."
        onSend={handleCommand}
        disabled={state.matches('streaming_logs')}
      />

      {/* 状态指示器 */}
      <StatusIndicator state={state.value} />

      {/* 日志窗口 */}
      <LogViewer logs={state.context.logs} />
    </div>
  );
};

看到了吗？handleCommand 函数非常纯粹。它只是一个路由器。它根据用户输入的字符串，把事件发送给状态机。

真正复杂的逻辑（比如把 logcat 转换成流监听，比如解析 adb devices 的输出）全部封装在 adbMachine 里面了。

---

第九章：关于“跨端”与“复杂度”的思考

回到题目：React 状态机处理复杂的 Android 模拟器 ADB 跨端指令分发。

所谓的“跨端”，在这里指的是用户界面（Web/Mobile）与底层系统（Android/ADB）之间的边界。

当指令分发变得复杂时，你会面临两个极端：

1. UI 极其臃肿：为了处理各种状态，组件里全是 if-else，可读性极差。
2. 逻辑极其脆弱：一个回调没写好，整个流程就断了。

使用状态机，本质上是引入了显式建模。

你不再是去猜“代码会怎么跑”，而是去设计“系统应该怎么跑”。
你定义了 IDLE，你就强制自己处理了“空闲时的行为”。
你定义了 ERROR，你就强制自己处理了“意外情况”。

这就像是给你的代码上了保险。

---

第十章：最后，给新手的一点建议

如果你是 React 新手，听到“状态机”可能会觉得吓人，觉得“是不是又要学一个新的库了？XState 会不会很复杂？”

其实不是的。

你可以先用最简单的状态机思想来改造你的代码。

不要这样写：

// 坏习惯
const App = () => {
  const [loading, setLoading] = useState(false);
  const [data, setData] = useState(null);
  const [error, setError] = useState(null);

  const doSomething = () => {
    setLoading(true);
    fetch('/api').then(res => res.json())
      .then(data => { setData(data); setLoading(false); })
      .catch(err => { setError(err); setLoading(false); });
  }
  // ...
}

试着把 loading, data, error 这三个状态看作是机器的核心，把 doSomething 看作是触发转换的事件。

虽然入门阶段手写状态机比较繁琐，但当你面对 50 多个 ADB 指令，需要处理并发、超时、重试、流式传输时，你会感谢那个在深夜里坚持定义状态图的自己。

记住：状态机不是一种工具，它是一种思维方式。

---

结语

写代码就像调戏 Android 模拟器，有时候你觉得自己是上帝，有时候你觉得自己是条狗。

但有了 React 和状态机，至少你在面对那一堆乱七八糟的 ADB 指令时，不再是那个只会喊“报错”的文盲，而是一个手握权杖、运筹帷幄的调度官。

去试试吧。哪怕只是把你的 useEffect 拆分成一个状态机，你的代码都会变得整洁得让你想哭。

好了，今天的讲座就到这里。希望你的 ADB 指令都能精准下发，愿你的模拟器永不崩溃。下课！