背景
近来有一些framework老司机粉丝朋友发来了一些framework工作中的一些疑问，具体描述如下：
这个同学遇到的问题，其实就是大部分framework开发者工作比较久后遇到的一个上升瓶颈问题。
具体总结有以下几个瓶颈问题
1、framework属于系统核心框架部分，整体要求稳定性高，可变性小，aosp本身已经把framework比较完善，所以framework不会像app开发那样，有每半个月一次的迭代周期，所以不断的修改一些交互功能和需求。因为framework需求相对比较少，导致大家心里可能比焦虑，怎么没有和以前一样写很多代码啊？即第一个瓶颈就是：framework需求不那么多，修改代码量不大，认为没有写很多代码就是自己能力不好上升有瓶颈
2、framework因为稳定性要求高，所以经常的工作任务都是解bug大于做需求，这个其实大部分公司都是一样的。但是bug都是一些疑难问题，比如anr，crash，黑屏，闪黑等，还是偶现的，只有日志等分析起来比较困难，所以这类问题的解决效率比较低，bug的收敛速度也慢，再也没有app那种bug多，修复也多。即第二个瓶颈：framework的bug很多是复杂而且低概率的bug，修复起来难度大，所以导致修复率比较低，成就感很低，即有bug修复的瓶颈。
如何突破以上一些瓶颈
1、 针对需求较少这个瓶颈问题，我这边给出以下一些建议：
1 针对自己业务相关的任何需求，自查有没有不理解或不知道原理的，可以去尝试搞懂剖析，这样以后产品或者其他同事提出的任何和自己相关的业务技术问题都可以迅速自信的回答出来
2 自己业务相关的功能，不能只局限于公司的功能，需要自己敏锐的去市场上挖掘竞品相关新功能，调研人家新的功能，看看人家怎么实现，如果自己做这个竞品新是否可以做出来，应该怎么做，可以自己经常去尝试demo新功能开发
3 时刻关注google在自己业务一些更新patch提交，紧跟google的更新节奏等，把握新的动态和发展
总结一下针对需求较少的瓶颈部分解决突破方法就是：不断剖析陌生模块或者功能、调研竞品相关功能实现demo，紧跟google更新提交布局
2、如何突破framework一些bug解决效率问题
1 针对一些不是必现的低概率bug，这个需要评估好这类bug的出现频率和严重程度，比如可以从测试提出问题多少，日志上可以归类是不是一类低概率问题，这样就可以知到频率和严重程度，哪怕低概率也需要认真分析，要自己找测试人员集中进行复现。如果日志不够，或者需要其他的dump等信息，需要自己添加上去，慢慢多个版本追踪，因为有新的日志慢慢缩小bug范围，也可以自己日志中有怀疑点，分析出相关的必现步骤等方式即把偶现变成必现。
总结：认真分析日志，找测试人员多进行复现测试，添加更多辅助日志或dump，复现后有更多证据，可以尝试修改一些代码把偶现变成必现
2 针对一些常见类型偶现bug，只有日志分析可能作用不大，可以自己编写一些工具辅助等工具，在出现问题后的几秒钟可以触发相关按键，比如截图按键等，来触发自己的一些导出相关系统运行的变量或者数据，日志，trace等，这样可以大大提高偶现类问题出现时候老是因为抓取的分析证据不足而导致一直无法推进。也可以多关注google的一些日志工具的改进思路，比如google做出的winscope，proto日志等，这些作为便利的bug分析依据工具，大家是否可以考虑针对自己业务模块也搞出一个类似工具进行提高bug的分析效率。
3、端正态度，不以转出bug为目的
经常在公司里面可能有bug率的指标压力，这种情况下可能会导致很多同学会存在分析问题时候不那么全面，只要发现和自己模块不相关直接就转给相关业务模块，就比如经典问题anr这种，很多同学一看到某个第三方app应用anr，那么故障就直接给第三方应用，其实很多anr都不是app自己问题，很可能系统卡了或者什么的导致的app才anr，这时候如果系统工程师完全不看直接转的话，说实话自己系统应用可能还有负责，第三方应用可能没人负责，那么就会导致错过一些系统存在的bug。
所以，建议大家看到和自己业务模块相关的bug时候，第一时间想到的不是尽快转给下一个模块，而是先分析好，把自己模块的逻辑等整理好，确定自己模块没问题在考虑转出
4、经常学习大神大佬
公司里面总有一些公认大佬或者大神，这个时候大家可能都想和大佬学习，但是也不可能天天去请教人家问题，因为大佬每天也很忙，老是问人家问题也不合适占用人家时间。
所以给出以下几点向大佬学习的方法：
4.1 大佬的名下的故障，你可以尝试也去帮大佬解bug，然后解不出来的看看大佬是怎么解的
4.2 多和大佬讨论技术，努力学习分析一些东西给大佬，让大佬觉得你确确实实很认真的，和你交流技术是真的讨论大佬自己也有进步，而不仅仅是你请教告诉
4.3 问大佬问题一定要多考虑充分，准备充分，思路明确，切勿和人家大佬讨论问题，大佬提到个相关的模块，发现你啥也不懂，这个时候大佬可能就没办法和你再聊了，可能就是让你去看看xxx
4.4 多看看大佬的gerrit代码需求的提交，看看人家是怎么实现一些较难的需求，这里大家注意最好不要让大佬发现你在review人家代码，或者征求人家意见去学习人家代码
4.5 也可以去互联网寻找一些干货技术文章等，或者付费学习等，这里说实话马哥也有不擅长的技术，也经常会付费学习一些自己陌生的技术，这样最重要可以帮我节省大量时间而且进步很快。
总结
上面提到的几点就是我这边给一些framework的老工程师在公司工作过程中遇到瓶颈如何提高的方法，相信按上面的方法做了以后你一定可以突破瓶颈，找出新的方向，技术上升一个档次哈。
更多framework详细代码和资料参考如下链接
hal+perfetto+surfaceflinger
https://mp.weixin.qq.com/s/LbVLnu1udqExHVKxd74ILg
其他课程七件套专题：
点击这里
https://mp.weixin.qq.com/s/Qv8zjgQ0CkalKmvi8tMGaw
视频试看：
https://www.bilibili.com/video/BV1wc41117L4/
参考相关链接：
https://blog.csdn.net/zhimokf/article/details/137958615