今天一口气解决了两个没那么简单的问题，从上周开始紧皱的眉头终于可以松一些了，趁热赶紧记录一下。
第一个问题
第一个问题是 React Native 0.72 版本上的 JS Debug 功能崩溃问题。
今年公司在做 RN 版本升级，从 0.63 版本升级到 0.72，中间有不少变更点，加上业务需要自定义了很多功能，升级起来成本不少。
上周前端同学反馈：在新版本的包上使用 RN 的 JS Debug 功能会闪退。
这个问题虽然不是线上 crash，但对开发业务需求的效率还是有不少影响，所以还是值得研究一下。
首先，什么是 JS Debug 功能呢？
如上图所示，在开发 RN 业务时我们可以唤起一个调试功能弹窗，在弹窗的最底部有一个「Debug」按钮，点击以后会在 Chrome 打开一个调试页面：http://localhost:8081/debugger-ui/
在这个调试页面里，我们可以查看 JS 里的日志和断点调试代码。
因此，简单的讲，JS Debug 功能就是在 Chrome 浏览器里调试 RN JS 代码。
知道了功能的作用后，接下来我逐渐丰富了相关源码里的日志，最后终于定位到，崩溃是因为在 Debug 时使用的 JS 引擎有问题，会导致底层获取 runtime 为空
。
因此在相关路径上做好兜底处理即可，比如这样：
第二个问题
第二个是折叠屏上 RN Text 组件的行号计算问题。
上周前端同事反馈 RN Text 组件在荣耀 MagicV2 上展示有问题，明明只有一行的文字，实际高度却有两行。
普通手机都好好的，只有这款折叠屏出了问题，无语，最关键的是有个大领导使用的这款机型
一开始我以为是 Android TextView 问题，后来测试完发现 TextView 没毛病，那就是 RN 自己的问题。
打开 RN 的文字组件代码，一看几百行的函数，我的心态都崩了，这也太复杂了，有的逻辑注释就好几行，感觉很难啃的样子
。
心态崩了以后，我始终静不下心来仔细看逻辑，上周搞了半天都没有个结论。
今天解决完上个问题，感觉自己很在状态
，趁热打铁仔细研读了一俩小时相关代码，经过反复 debug，终于发现：在这款折叠屏上，RN 对 《 这种特殊字符的宽度计算的结果和实际占用的不一样，导致最终算出的行数比实际展示多。
伟大领袖果然说的对：事在人为，一切问题都是纸老虎。
解决问题的心得
最近工作里有至少一半精力都在解决问题，骨头啃惯了，有时候真的想吃点软的，吃软的多省力啊，但转念一想，天天吃软饭就废了，那些厉害的大佬不都是这么过来的么。
印象里因为解决问题成长最快的是阿里的 P10 大佬毕玄，他年轻的时候各种做救火队，因而得到了异于常人的锻炼，虽然如今没有这种环境，但能锻炼还是要多锻炼。
解决问题有什么通用方法呢？
1.首先确定问题范围，到底是哪一环节出了问题。比如今天解决的第二个问题，是系统 TextView 问题还是 RN 处理的不对，两者的解决方案截然不同。
2.其次是查资料，需要用对关键字。我们遇到的问题很多时候都有别人遇到过（这也是不要使用冷门技术的原因之一），因此不要一上来就撸起袖子研究，先拿到问题的关键字和核心代码去 Google 一下，可能会节省很多时间。
3.自己分析的时候，首先调整心态。相信自己可能解决，而不是盲目求助、搜索。有些人遇到问题就慌张，没头没脑的在各个群里提问，结果浪费半天时间没什么效果，反而自己研究一下很快就有眉目。
4.然后构建容易测试的环境，磨刀不误砍柴工。有些复杂的问题可能要排查很久，验证的链路越短，解决的成功率越高。
5.最后就是动手环节，理清链路，补充日志，逐步缩小范围圈。这个阶段需要留出大片时间，频繁切换上下文会极大影响效率。
总结
OK，这就是我今天解决的两个问题，不知道这些零碎的内容大家感不感兴趣。
一直以来，我在写文章上都有一种情结：要写别人没怎么写过、结构化的内容。
这种想法导致五分钟的灵感，最后成文要花三五个小时以上，写的不够好不敢发表。
忙起来没有这么大块时间，拖着拖着很多灵感都胎死腹中，扼杀了很多可能性。
最近看到王小二大佬的公众号，每天简单记录一些小点，自己开心读者看着也舒服。
向他学习，记录生活，有感就发，不再端着。
最后，很高兴的向大家宣布，我的新书《Android 性能优化入门与实战》出版了，上周排到了京东计算机类图书第五名，有兴趣的朋友可以了解一下～
添加微信并备注“入群”，交流本书阅读感受～
推荐阅读:
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
