Luna：你想要的 React Native 调试工具

本文首发于微信公众号“Shopee技术团队”。

1. 背景

React Native（以下简称 RN）目前在 Shopee 前端团队得到大量应用。RN 虽然有很多优势，但是其开发和调试流程与 Mobile Web 相比却不那么友好，特别是在运行时的调试。

在开发模式下，虽然 RN 提供了官方的调试工具，但是相比纯前端的浏览器 Devtool，它的功能比较弱；而非开发模式下，例如 Test 和 UAT 环境，RN 代码被打包成了一个 Bundle，这个时候官方调试工具也派不上用场了，这不仅对测试同学的问题复现产生阻碍，也使开发同学的问题定位变得更加困难。

目前业界对于 RN 的调试虽然有工具，但或多或少都存在缺陷（如下图所示），而且这些工具都是针对开发模式下的调试，对于打包后的生产环境的调试往往还是需要靠人肉去做，效率比较低下。

因此一款能够帮助在非开发环境定位问题的工具显得尤为重要，Luna 就此应运而生，本文将介绍这款 RN 工具关键技术的设计以及实现。

2. 功能介绍

先通过下面几张图了解一下 Luna：


从图片可以看出来，Luna 是一款 RN 的应用内调试工具，更偏向于解决生产环境调试的痛点。

Luna 由一个橙色的触发按钮以及占据半屏的本体组成。本体包含了 Log、Network、Redux 和 Shopee 这四个版块，分别承载了日志记录、网络请求查看、Redux 树查看以及 Shopee 相关信息查看的功能。

其中，Log 和 Network 作为核心模块存在，而 Shopee 和 Redux 则是作为 Luna 提供的公共插件引入进来的。这种 Core-Plugin 模式就是 Luna 现在的运行模式：默认提供 Log、Network 等功能，也支持使用者编写自定义模块导入到 Luna。

四大版块的功能如下：

1）Log 版块

Log 版块接管了 console.log，将所有 Log 和未捕获的错误收集到 Luna ，然后倒序展示出来。它支持按 Log 的类型进行过滤，也支持对 Log 进行模糊查找。如下图所示：

2）Network 版块

Network 版块收集了页面发出的请求信息，包含了请求状态、请求耗费时长、请求头、请求体以及响应头和响应体等等，用户可以方便地查看 API 请求。

3）Shopee 版块

Shopee 版块提供了一些 Shopee App 相关的功能，比如便捷的翻译文案切换、Cookies 查看、DataStore 存储查看与删除，还有用户 ID / 名字与设备系统信息，以及版本号相关的信息查看。这些功能可以帮助开发者更方便地调试应用，也便于 QA 更快地复现与定位 bug。

4）Redux 版块

Redux 版块展示了 Store（共享数据存储仓库）树，方便用户查看整个 Store 的状态。

3. 方案设计

3.1 整体设计

Luna 作为一个 monorepo 多包单仓库架构的项目，包含了 Core、Shopee Plugin 和 Redux Plugin 三个包模块。

其中，Core 核心模块包含了三大部分：Log 日志版块、Network 网络版块、Plugins 插件接入版块。下文将一一介绍每个模块的设计。

3.2 Core

Core 模块是 Luna 的核心模块，作为一个单独的 npm 包存在，提供了最基本的功能与插件接入的能力。Core 模块作为一个 Provider 嵌套在组件树的根部，接受业务代码，并将 Luna 插入进去。Core 使用 mobx 作为存储，维护了 Log 日志和 Network 记录的收集与展示、以及自定义插件的控制等等功能。

3.2.1 接入方案

Luna 的灵感源自于 Web 端开源的 vConsole 和 Eruda 这两款调试工具，但在 Luna 的接入方案选择中，我们碰到了在 Mobile Web 中从未碰到过的难题：在现代化 Web 开发中，不论是 Vue 还是 React，只要是单页应用，都会有一个用于挂载的根节点，以这个根节点为起点构建整个组件树。所以调试工具也只需要挂在某一根节点下，即可感知整个应用的状态：

而在 React Native 中，每个页面（View）都有自己的根节点（如下图所示），不同的页面之间并没有一个公共的祖先节点，如果要保证每个页面都能访问到 Luna，就得在每个页面都单独进行一次注入，不仅接入成本陡增，而且数据的保留也成了一大难题。