今天一口气解决了两个没那么简单的问题，从上周开始紧皱的眉头终于可以松一些了，趁热赶紧记录一下。
第一个问题
第一个问题是 React Native 0.72 版本上的 JS Debug 功能崩溃问题。
今年公司在做 RN 版本升级，从 0.63 版本升级到 0.72，中间有不少变更点，加上业务需要自定义了很多功能，升级起来成本不少。
变更点可以看这篇文章：# React Native 各版本（0.64~0.72）特性及 Breaking Changes
上周前端同学反馈：在新版本的包上使用 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 性能优化入门与实战》出版了，上周排到了京东计算机类图书第五名，有兴趣的朋友可以了解一下～
推荐阅读:
