背景：
两年前，那时候工作量还只是正常的2倍左右，没有自我提升的时间，疯狂做业务没有任何技术提升，反倒越做越焦虑。简单的容易出成绩的东西也轮不到我（例如接个SDK），找了一圈发现一个没人要的调试工具，基本处于一个无人维护的废弃状态，仅能切换个环境。平时开发测试阶段很多场景下都需要针对性的提效赋能工具，这...大有可为！方向确定后花了点时间规划好细节就向领导申请能排点工时支持下，口头答应后就是不排时间···
经过几个迭代的软磨硬泡终于在某个迭代给排了2pd（后来给插了个紧急需求占用了）。时间没要到，倒是给了个要求“必须使用Flutter”。
本文仅作为回顾总结
- TTI 页面可交互时间监控
- Flutter FPS 监控
- 颜色标尺
- 组件抓手（待填坑）
- 录屏分析
- (本文)调试工具重构
现状与目标
一套独立的纯Native实现的工具集，个别正常功能需要保留（环境切换、线上Mock），领导强制要求使用Flutter，自己也想用点非公司技术栈的东西。结合工具现状分析下来大概分为几个方面：
- 重构整体架构
- 兼容最新版本的编译打包方式
- 兼容C++、Swift，并使用Flutter开发与系统非强相关的功能
- 设计&开发数十款覆盖迭代全流程全工种的工具集
- 容灾-支持新老两个工具的切换
这里对第5点展开说一下，最开始也有犹豫“一个已经基本废弃的非线上工具有必要容灾么？”，事后证明“非常有必要”，倒不是重构后的工具本身有什么问题，问题就出现在打包上，要么是基础部门乱改依赖，要么是有权限的人员不给你配置。
整体架构
- 数据层
对原本使用的WCDB进行了升级适配，新老工具均使用一套持久层。当时的新版本Xcode已开始废弃老的编译链接方式，除了对工具库进行了必要的适配，还需兼容公司的老爷打包机，手动将WCDB中的WCDBObjc、sqlcipher提取再整合，重新生成了xcframework。
当时重新生成xcframework时主要使用的命令：
【查看架构信息】
$ lipo -info 'xxxx/xxxxx/name.framework/name'
【移除framework中的指定架构】
$ lipo -remove 架构名(i386) 'Framework.framework/FrameworkName' -o 'Framework.framework/FrameworkName'
【生成xcframework（整合framework）】
$ xcodebuild -create-xcframework \ -framework ‘../…/…/name.framework' \ -framework '../…/…/.../name.framework' \ -output ’name.xcframework'
- 系统层
系统层以Native为主。调试工具的场景比较独立，系统层主要分为“路由”、“服务”、“基础功能”三个核心模块。
- RouterCenter（路由）：打通不同技术栈之间的页面跳转
- ServiceCenter（服务）：系统层级的一些服务，例如与数据持久层交互的Data，与flutter交互的channel都在该模块下
- BaseTools（工具）：基础功能更偏向业务使用，例如性能监控工具、hook工具
通过主控制器去分发事件的方式来与核心模块进行交互，限制外部交互方式。RouterCenter与ServiceCenter均为对已有功能进行最小化的重构封装，保证了新老工具系统层级的统一性。
- 应用层
这一层是各类工具应用，包含老版本可复用部分，应用之间较为独立，具体功能上可参考文章开头的系列文章，就不展开了。放一个主要工具的图：
每款应用都可分为三个步骤“分析&调研-设计&开发-优化”
- 分析&调研：针对需要提效的场景进行具体分析找到真正阻塞效率的节点，并通过询问的方式搜集各方的痛点与意见
- 设计&开发：秉持着简洁易用的原则进行设计，利用可复用的数据/功能避免冗余开发
- 优化：发布后，对使用人群进行抽样回访，针对性的优化
总结
未深入重构的细节，一方面是时间过去较久，二是没有过多通用的参考价值，三是尽快把这个系列的坑填了，仅对整体进行简要概述。
利用非工作时间断断续续搞了两个月，从整体的重构，到十几款小工具全部完成正式投入使用，花费了不少心血。后因打包问题新版本被强制屏蔽时，很多同学来咨询新版无法使用也算是得到了大家的认可。
