你好，我是千里马，是一个程序员，软件工程师，我负责owo相簿所有相关产品的开发以及维护工作，最近这两天我遇到了一个棘手的问题，莫名其妙，相簿相关安卓端react native应用没办法完成轻量化编译，为此我进行一部分研究，但大多无济于事。

这是一个涉及技术生态面非常广泛的错误，因为react native框架的原因，bug的涉及范围非常广泛，不仅涵盖到h5系生态，而且横跨到安卓sdk生态，以及c系列生态，属于那种不常见的错误，甚至有一定代表性，所以也值得写一个技术博客记录一下。

首先没办法轻量化编译肯定不行，没办法轻量化编译就导致没办法即时修改方便开发工作，也方便测试，没有轻量化编译会给开发工作带来极大的困难。所以这个bug必须得到解决。

第一天

所以先看看bug的实际表现，未知原因，未知修改，运行npm run android轻量化打包发布就会无法编译，爆出来自于react-native-screens的c++编译问题。

开始的时候我让人工智能分析分析，人工智能给出的解释是因为windows路径字符数量最大范围限制导致的编译失败，挺有道理，我也为此扩大了windows文件路径，但是无济于事，问题无法解决。

没办法轻量编译那么可以完整编译吗，一般可以完整编译就代表没什么大问题，如果完整编译也不能成功，我们就针对完整编译报出的一切错误进行依次分析就可以了，结果是完整编译可以通过，甚至于没有爆出cxx问题，这点就说明工程本身没什么问题，主要问题就是出在环境层面，但是我只要轻量化编译就必定会爆出cxx问题。这也是比较奇怪的事情。

遇到这种情况我首先觉得主要问题出在缓存，所以我清理缓存，首先安卓编译缓存，react-native-screens编译cxx缓存，安卓本身缓存，最后甚至于把构建临时下载的缓存也都删了，但都无济于事，cxx错误依然存在。

也说明问题不在缓存，到底问题是什么呢？我这时其实我也属实是没什么办法了，而如果重建呢，我不太想重建，因为重建太费力气，不仅技术投入大，而且很多包库还得重新下载支持，而最关键的我们在中国大陆，网不太好，下载美国服务器文件网速会很慢。另外重建我的硬盘也不太行，我电脑的c盘空间不多了，没办法支持的好再新开一台虚拟机去完成重建这件事。所以我这时选择不要重建，毕竟考虑到现实原因嘛

这时我也确实是没什么好办法了，只能用一个以前备份工程，换包实现看了，目前只有这一种办法。我知道react native这个环境不太好搞，所以当时做全局安全备份的时候就把rn环境也备份了一份，感谢曾经的我，火速从冷备份盘里面找出来虚拟机文件，进行测试功能是否正常，如果也出cxx编译问题就说明是我们的版本太老了，属于外部原因，有一些包通过网络自动更新了，而如果没出问题呢说明是我自己的工程原因，而测试结果没问题轻量化编译和完整编译都可以。说明是我自己的工程原因，所以我选择了换包方案，老版本工程换包到新版本，换包其实相对来说比较轻松。

因此问题也得到了解决，我进行了换包落地，把缺乏的包都安装上，把程序功能也都对应到新版本，先进行轻量编译，然后进行完整编译，没问题，也就是趁现在完好的状态对react native工程再备份一份防止未来工作再出相关问题污染。

因此做好了第一天的cxx编译错误的修复工作。

第二天

第二天我进行的工作是一个处理兔宝系统cmd令牌统一化的微小工作，这个微小工作涉及到了出现cxx编译问题的安卓工程，为了方便工作所以我进行对其轻量化编译，根本想不到，轻量化编译又出现了cxx编译问题！！！

这时候我就觉得肯定不是我的工程问题了，这纯粹就是网络问题，他会自动更新，昨天还错怪了我自己，毕竟我的react native版本也有一些老了，2023年时候创建的工程，有一些服务的自动更新可以理解嘛（为什么昨天没出问题是个疑点，说明还是我们工程的问题）。这我也没什么办法，不过我尽可能锚定版本吧，如果适配新版本会耗费很大力气。

这时相对昨天来说简单了不少，因为昨天的备份所以我有了样本，没问题的样本和错误的样本。这就应该很好搞了，不过我先进行断网在没问题的样本中测试一下，看看是不是网络原因，我们已经确定没问题样本可以编译，断网情况下如果不能编译说明这是怪事，能编译的话说明就是网络问题锤实了。

结果是不能编译依然报cxx编译错误。这是怪事，我就在想问题出在哪里呢？不太可能是windows系统吧，我比较相信系统怎么会管你一个应用里面的包的处理呢，也可能是虚拟机问题，这问题范围太大了原因就是任何问题，因此也回到了这次debug的起点。

结果就是任何问题，不过我相信系统绝对没问题吧，问题只能是出在程序编译过程或者某个不知名的自动化关联修改，触发而导致的问题上。或者说编译的过程中就出现问题了，或者编译本身就有问题，毕竟我们这个工程比较老了。

心中一惊，突然想到，经过上面的推论，或者，样本本身就被污染了呢，万一没问题的样本本身就是有问题的呢？这不就精彩了吗，但是昨天存档时候就感染不太可能，当时编译流程都很好也没问题，甚至于我都在手机上面运行了。那么问题只能是，先进行轻量编译没问题，然后进行完整编译编出问题，完整编译导致了轻量编译出现问题，那时我恰巧完整编译后没有再验证一次轻量编译能不能通过。毕竟一开始轻量编译过了，什么人会再验证一次呢？

所以整理一下，轻量编译没问题>全量编译编出轻量编译出现cxx的基础>轻量编译爆出cxx编译问题。大概就是这样的逻辑。

这时候迎来当头一棒，老版本没问题的工程，没有联网，没有经过完整编译，没问题的老版本工程，不是因为外部服务器的自动更新（断网），现在开始没办法经过完整编译了，不过是一个小问题，不是cxx问题，可能和联网有关，联网才能支持下来这个老版本的完整编译。

连上网老版本成功编译了，说明还是得依赖一下联网，不过这和cxx编译问题关系应该不大，当时我其实已经脑子绕的一片混乱了....

这时候我想再确认一下新版本的工程，因为之前经历过完整编译，现在看看能不能直接编译成功上来用，因为不能完整编译对于未来也是坑，未来产品怎么发布呢，没办法发布了。这次的编译结果依然是失败的爆cxx编译错误，这就证明了前面的解决方案换包不行，换包根本解决不了这个问题，因为老版本的也不行，问题只能出在我们的版本太老了，已经不怎么支持了，所以也只能是升级版本。用最新版本的。因为锚定版本也很难搞，要不就是一直断网，现在就是啥都有问题只能说明我们的版本太老了，新版本肯定没问题吧，不太可能新版本也有问题，那react native还工作不工作了？

新版本不好搞，整了很长时间来回做，我就略过了，我换到0.8react native版本，并且创建了最基础的官方实例，心里想先创建好最新版本，后面老工程迁移过来就好了，就是迁移可能稍微有点麻烦。谁叫我是owo相簿的开发者呢？

我根本连想就没有想，绝对不可能存在一点点问题，晴天霹雳的大雷，官方版本，最简单的实例，最新的版本，给所有开发者的案例，竟然也出现了cxx编译问题，这是面向所有react native框架的问题，可能是windows导致的，也可能是虚拟机导致的，或者空气中的氧元素...好了揣摩cxx原因问题的可能性设想到此为止吧，既然新版本也有问题，而且我还不熟悉，我直接去维护老版本得了，还有记录文件存在。以及多年这个版本的开发经验。

不过整体说明我们得直面问题了，前面我的选择一直都是绕过去，我不太想处理编译逻辑，一方面我不太擅长，另一方面这件事很累，我主要属于一个h5系统的工程师，如果是h5系的话我比较熟悉，我也有把握能够刨根问底，刨到最后，但涉及到安卓生态以及c生态，可能会有点有心无力。

第一步先做一个bug问题的最简单的复现，拿上最简单的bug复现，然后去找react native官方，最简单的复现我们是怎么做的呢？创建一个工程，工程里面只包含几个核心的包，带上有问题的react-native-screens，然后用npm i 去下载一波，就用我的这个框架代码，后面框架代码再简化一波。

最简化这个工程做下来，遇到很多常规bug问题，一方面我记不住，另一方面没必要说，这些常规bug都解决了，可以完整编译，也可以轻量编译，这时候我发现，这个新的案例工程好像可以解决cxx问题，完整编译了再轻量编译也没有出现cxx编译问题。这不就是我最想要的那个吗？

这个最简工程，可能说明主要问题在于react-native-screens的一个固定版本，或者我们家的react-native-screens本身损坏了导致的问题，这就犹如一个世界的巨大可能性，瞬间缩小到了芝麻大小。

不管是版本问题，还是损坏问题，我们都按从零开始，将node_modules文件夹删除了，主要原因就是我的node_modules文件夹太老了，维护这个文件夹维护了三年多，一直没有变动过。可能是什么时候啊安装的某个依赖自动的将react-native-screens文件损坏了，或者改变了其版本。

没问题的最简化工程版本是react-native-screens30，我们当前主工程的版本是react-native-screens31，所以我删除node_modules文件夹，然后降一下版本就将这个困扰了我两天的bug成功解决了

这个bug困扰的我简直身心俱疲。耗费我两天的时间，也好在这个bug得到了解决，最终感谢一下npm包管理器吧，犹如软件工程师我在debug时的得力助手一样，npm包管理器帮我挡了一刀，最后才竭尽全力解决掉了这个bug。

全文写了3500字调试debug日志记录，现在也已经结束了，我是千里马，是一个擅长于上层应用开发的软件工程师，我们未来有机会再见。