一文读懂字节跳动自研移动研发工具链 MBox

每一个研发团队都有着自己的研发流水线（评审、开发、构建、测试、修复、发布），在提升研发效能的实践中我们往往会提供丰富的研发工具供研发人员在这些流程节点中使用，但这些工具真的有合理地融入到我们的研发流程中，形成一条完整的工具链吗？

真实情况是，我们在实践中常常过多地关注单一指标，例如通过对工具链的改造提升项目的工程化程度，工程化确实能带来可维护性、工程质量等指标的提升，但是在其他环节中，如新人上手成本提升、依赖管理难度提高、代码合入时间拉长、Bug 复现困难等方面也带来了负面影响。

方案

–

我们对上述的现状与问题进行了分析，并结合在移动端研发工具相关实践经验，最终决定开发一款面向移动端开发者的研发工具链产品 MBox。

如上图所见，MBox 最终所呈现的产品形态是一款包含 GUI (Graphical User Interface) 与 CLI (Command-Line Interface) 的 Navtive App。

理念

全覆盖 All-in-one

我们期望开发一款能够对研发流程做到全场景覆盖的工具链产品，用户能够在 MBox 中获取所有需要的研发信息，并完成相应的研发工作，同时确保在整个研发链路中拥有一致的研发体验。

可视化 Visualized

在最初迭代 CLI 版本的过程中，我们渐渐发现可视化的交互方式可以解决一些在 CLI 交互中难以解决的问题，尽管 GUI  相比 CLI 在编程实现上会复杂很多，但我们坚信用户体验的重要性，因此 MBox 为用户提供了 GUI 与 CLI 两种可供选择的交互方式。

极简化 Simple

这里的 Simple 并不是指简单，而是交互设计上的简约，在这里本质上是可用性的体现。我们认为研发工具应该是为用户解决困难而不是制造困难的，任何无关的或是分散研发人员注意的信息都是不必要的，简单好用是对一款研发工具的最美称赞。

可扩展 Extensible

通常意义下 All-in-one 的工具链往往会导致可定制性变差，MBox 通过插件化技术在最大程度上满足了用户在横向与纵向上扩展性需求。

架构

上文中提到通常情况下我们的研发流程是一条流水线式的模型，多数研发工具都会从这条流水线中找到一个切入点来提供服务，协助用户完成某个节点的工作。而 MBox 在架构设计上则更多关注的是整个研发流程运转的效率，这不仅体现在单个节点的高效，同样体现在不同节点之间流转的高效。

MBox 在功能上并没有按照研发流程进行划分，而是将整条研发链路贯穿到所有的功能设计中，根据功能的种类分成四大板块：Environment、Workspace、Workflow、Tool。

核心功能

Environment

Environment 即研发环境，直觉告诉我们环境部署只是研发环节中较为前置的一个环节，但在实际开发实践中，Environment 要解决的不仅仅是部署（Deployment）的问题，其中还包含了环境统一（Consistency）、环境升级（Upgrade）和环境隔离（Isolation）这三个问题，而上述的四个问题却是贯穿于整个研发流程的。

我们认为在一个良好的研发体验中，研发人员无须关注绝大部分与环境相关的问题，应该把更多的关注度放在业务上，产生更多有效的价值。MBox 实现了整个过程的自动化，在任意时刻，无感知地为研发人员提前完成环境相关的部署、隔离与升级工作，同时还解决了项目研发环境一致性的问题。

上图展示了 GUI 下的环境功能模块，除了上文中提到的全自动化能力，MBox 同样支持用户手动控制。

Workspace

Workspace 是我们代码仓库存放的空间，也被认为是研发人员工作的核心。我们首先可以回顾一下，通常情况我们是如何管理代码的？在这过程中我们又遇到了哪些问题？

下文将阐述我们在实践过程中遇到的困难以及对应的解决方案。

挑战 1：跨项目开发 Multiple Projects

在一些研发团队中（常见于中台部门），常常需要在多个项目之间同时进行开发，每一个项目的代码仓库与研发环境往往是迥异的，研发在切换项目的过程中常常疲于解决各种仓库与环境问题，导致效率降低。MBox 采用沙盒化 Sandbox 技术，将不同项目的代码仓库与环境隔离开来，我们将这样的沙盒称之为 MBox Workspace（以下简称 Workspace），在这样的机制下，研发人员只需要明确当前自己需要开发哪个项目而无需关注这个项目背后的问题。

挑战 2：仓库繁多 Too Many Repos

随着团队增长，工程化、组件化不断深入，理想状态下每个业务团队只需要关注自己开发的组件，代码以仓库为级别进行隔离，这样做确实也会带来不少在缓存、二进制、安全风控等方面的优势，但这也可能会导致一个常见问题，即仓库数量庞大而变得难以维护。

在 MBox 中研发人员可以轻松地将远程或者本地的仓库添加到 Workspace 中进行统一管理，同时在同一 Workspace 中我们还利用缓存技术加速用户添加仓库的过程，让仓库的增删变得更加方便快捷。

除了仓库的增删，研发人员们最常用的还是 Git 仓库操作，MBox 参考了业内成熟的方案并结合自己的实践经验，以 CLI 与 GUI 两种方式为研发人员提供了多仓库批量操作的支持。

上面展示了 GUI 下多仓库提交的过程，在终端下用户可使用 mbox git xxx 命令来完成多仓批量操作。

挑战 3：需求多变 Change of Requirements

大多数研发人员常常面临需求变化的问题，比如同时开发多个需求或者临时的 Bug 修复，在 GitFlow 模型下，研发人员需要根据当前需求来回切换对应分支，尤其是在多仓开发中，频繁的需求变化会给研发人员增加大量成本。

MBox 通过简化 GitFlow 模型，提出 Feature Mode 概念，每一个需求的元数据（即仓库、分支、代码）被抽象成为了一个 Feature，每个 Feature 之间相互独立互不影响，允许研发人员可以在多个需求之间快速轮转。

从上图中可以看到，当前 Workspace 存在 3 个 Feature，分别是 feature1 feature2 bugfix，每个 Feature 拥有各自对应的同名分支。除此以外 MBox 还存在 Free Mode 的状态，在该状态下研发人员可以对仓库进行任意的操作，作为切换到 Feature Mode 的前置准备。

挑战 4：依赖复杂 Complex Dependency

在移动端的本地开发中，我们常常需要将某个组件依赖替换成本地仓库中的源码版本，同时还需要小心地维护着本地仓库的代码版本，以确保和集成版本一致。

MBox 具备一套完整的依赖管理方案，结合不同的包管理工具特点，利用多种技术实现了对依赖包的本地重定向，研发人员只需要一行命令或者点击几个按钮即可完成该操作，尽可能减少研发人员重复的机械性工作。

与此同时，通过一套抽象的依赖管理方案我们在一定程度上抹平了依赖管理工具之间的一些差异性，即便是在跨端开发中，研发人员依旧可以获得较为一致的研发体验。例如在组件化研发场景中，我们需要依赖本地的源码版本的组件 A，Flutter 和 iOS 平台上常用的包管理工具对应的 CLI 命令分别是

• Flutter

$ mbox add component_A

$ mbox pub get

• iOS

$ mbox add component_A

$ mbox pod install

挑战 5：协作困难 Collaboration

随着团队的扩大，团队成员之间的协作变得更加紧密，但与此同时项目的复杂程度同样会随着团队的增长而增长。如何将自己的研发进度及时且完整地同步给其他人，成为了提升团队协作效率所必须要解决的问题。

上文中已经提到 Feature Mode 的抽象过程，其实 Feature 不仅可以使得单个研发人员快速切换工作上下文，也允许不同研发人员共享自己当前状态下的所有代码仓库及其研发环境。

我们还可以发挥更多的想象力，如果将这一功能扩展至云平台，比如异常监控平台，由服务端构造出会发生某个崩溃 case 的 Feature ，研发人员将其导入本地，即可快速在本地复现出 Bug 出现的场景。

Workspace 的优势

结合上述的五个挑战中，我们分别提出了与之相对应的解决思路，即利用沙盒化技术解决跨项目开发问题，利用多仓管理技术解决仓库数量膨胀问题，提出 Feature 概念解决多需求并行问题，利用依赖管理技术解决依赖控制低效的问题，最后提出了同步 Feature 来解决多人协作困难的问题

Workflow

研发流程相关的云服务

在大型工程团队中，为了提升研发质量和效率，会推出很多与研发流程相关的云服务，这些服务的一般是通过前端页面或是命令脚本对外提供服务。但很多云服务都面临着同样的问题，无法及时地触达每个研发人员，落地往往都需要一定的时间，同时研发人员也需要付出一定的学习成本。我们一直在思考，如何帮助那些优秀的云服务发挥出最大的价值？

在实践中，我们发现云服务在结合了 MBox 的 Native 优势后，不仅大幅降低了用户的学习成本，同时也能够扩展云服务使用的场景。

上文中提及的 MBox 与异常监控平台的联动，就是一个很好的应用场景，监控平台通过 MBox 直接为研发人员创建了本地开发环境，将云服务的应用场景扩展至研发人员本地。云平台通过 MBox 可以实现与研发人员本地机器的联动，研发人员也能通过 MBox 直接使用线上的云服务，可以说 Native 解决了云服务工具“触达用户最后一公里”的问题，同时也为这些云服务带来了更大的想象空间。

智能错误诊断

在移动研发中，相当一部分的工具链是运行在研发人员本地机器上的，导致我们无法实时获取研发人员本地的运行状态，这也加大了排查问题的难度。另外，研发人员在研发流程中遇到报错或者疑问时，也缺少自我排查的方法，多数情况只能求助身边同事或者发起 Oncall。

MBox 借助自身作为一款 All-in-one 研发工具的优势，收集研发人员在各个流程中遇到的错误日志，进行分析和归类，在第一时间为研发人员推送问题的解决方案，尽可能地减少工具问题对研发效率的影响。作为工具链开发者，可以通过不断补充解决方案来优化错误诊断的流程 ，沉淀出通用问题的知识库来提升人工 Oncall 的前置拦截率。

Tools

MBox 不仅仅是一个研发工具，它更像是一个可以承载更多研发工具的平台 ，MBox 开放了所有的核心能力，所有开发者都可以通过插件的形式对它进行二次开发，将好用的工具分享给更多的开发者。

为什么是 Native App?

核心功能介绍完了，最后还是想谈谈为什么我们要做一款 Native App。

多数传统实践中我们常常利用“工具+平台+文档”三者的紧密配合来保障整个研发流程的运转，然而正是这种过于紧密的关系容易导致三者之间相互影响而阻塞开发。顺着这个思路，既然这三者存在着如此紧密的联系，那么是否可以存在这样一个载体将这三者统一成一个整体，满足研发人员在研发流程中的所有需求，确保研发这条流水线的高效运转。

既然作为 Native 开发者，为什么不为自己开发一款称手的研发工具来提升自己的工作效率？

这个很酷的想法就应运而生了，像做产品一样来做工具，核心围绕移动端本地研发。将产品思维应用到工具开发中，持续不断提升工具的可用性，我们坚信只有可用性高的研发工具产品才能真正起到提升研发效能的作用。同时在产品思维的驱动下，我们还可以利用 MBox 建立了效能度量数据指标，发现研发流程的关键问题，进行针对性开发和优化，形成使用产品 -> 收集数据 -> 改进产品的闭环。

尼尔森对产品可用性的认识：易用性、交互效率、易记性、容错性、用户满意度

开放性

开放性赋予了工具链强大生命力。

能力开放

MBox 在设计之初就使用了插件化的架构，自底向上完全遵循插件化开发的思路，尽可能地将所有能力开放出来，用户通过 MBox 提供的开发者套件来开发自定义插件，实现定制化能力。正因为有了如此开放的自定义能力，MBox 对研发流程支持的广度和深度将持续不断地进化。
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则近万的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：Android）

总结

作为一名从事Android的开发者，很多人最近都在和我吐槽Android是不是快要凉了？而在我看来这正是市场成熟的表现，所有的市场都是温水煮青蛙，永远会淘汰掉不愿意学习改变，安于现状的那批人，希望所有的人能在大浪淘沙中留下来，因为对于市场的逐渐成熟，平凡并不是我们唯一的答案！

《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门即可获取！

img2.imgtp.com/2024/03/13/H4lCoPEF.jpg" />

总结

作为一名从事Android的开发者，很多人最近都在和我吐槽Android是不是快要凉了？而在我看来这正是市场成熟的表现，所有的市场都是温水煮青蛙，永远会淘汰掉不愿意学习改变，安于现状的那批人，希望所有的人能在大浪淘沙中留下来，因为对于市场的逐渐成熟，平凡并不是我们唯一的答案！

[外链图片转存中…(img-g1vqiJ60-1712337881451)]
[外链图片转存中…(img-VtHrNUQf-1712337881452)]

《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门即可获取！