每日一遍，BUG再见！程序员bug修复宝典重现天日！

• bug出现的必要条件（环境）和恢复途径

• bug修复后的预期效果

• bug对应的模块或者关联bug

有了以上的内容之后，相信程序员能够很快地了解这个bug，定位出bug产生的原因并予以解决。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-4gsQTUzh-1615192179158)(https://upload-images.jianshu.io/upload_images/25266384-7fa4b97bb5afb0ff.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)]

2.2 复现bug

如果你在第一步了解bug中获得了良好的bug报告的话，则此部分可以很容易。你只需要按照bug报告中的bug复现步骤，按顺序操作即可稳定复现bug。

当然，很多时候往往并不是一帆风顺的，即使你手握bug报告，做了非常详细的调查工作，然而bug就是无法复现，那么这个时候我们应该怎么做呢？

2.2.1 重新了解bug

此时为了能够复现bug，你可能需要回到上一步，重现去了解bug。因为你之前对bug的理解可能产生偏差，又或者你第一步并没有做好才导致了bug未能复现。这个时候带着疑问去重现了解bug，可能你会发现新的大陆。

2.2.2 将偶现bug转为必现bug

偶现bug算是bug家族中最调皮的一个了。它们以没有规律，难以复现等特性，经常能把以一个好好的程序员给逼疯。

但是既然是要复现bug，那么肯定要找到bug稳定复现的路径，这样才能方便下面bug的定位。这里我推荐大家的一个做法就是想办法把偶现的bug转化为必现的bug。因为即使是偶现的bug，很多也是特定条件下必现的bug，只不过此时你还没发现这个特定条件而已。

那么怎样才能将偶现bug转为必现bug呢？这里我简单介绍一下我常用的技巧：

• 1.对比法：观察并对比复现和不复现的各方面条件，找到那个必现的特定条件。

• 2.注释（删除）代码法：对怀疑的代码进行注释（删除），直到彻底将偶现bug转变为必现bug。

2.3 定位bug

一旦我们找到了bug稳定复现的步骤之后，下面的工作就是开始定位bug产生的地方了。

这一步可以说是解决bug的关键环节，这一步骤的难易程度一般取决于以下几个因素：

• 1.程序员自身的代码量（工作经验）

• 2.对项目代码（业务）的熟悉程度。

• 3.分析问题和解决问题的能力

那么我们如何才能更快地定位出bug产生的位置呢？下面我提供一些思路供大家参考：

• 1.断点调试法。这是程序员通用，同时也是最有效的定位问题的方式。一个不会断点调试的程序员和瞎子没有本质上的区别。

• 2.日志分析法。其实并不是所有bug都可以进行断点调试的。比如在一些循环调用或者业务较为复杂的场景下，打日志分析定位是较为适合的方式。

• 3.排除法。如果一个bug产生的原因可能有多种情况的时候，这个时候采取排除法的方式是最优的。你可以把可能导致bug产生的代码块都打上日志或者断点，然后重现一下bug进行问题的定位。

• 4.代码回滚法。如果你这个bug在之前的版本是好的，但是在现在版本上又出现了，这个时候就可以使用代码回滚大法。把你的代码回滚到你怀疑的版本，运行看bug是否消失，然后对两个版本之前代码有何区别，最终定位出bug产生的位置。这里我们可以使用二分法来提高代码的回滚效率。

• 5.注释（删除）代码法。这个我在上一个步骤中也提到过。对于一些难以理解和定位的bug，我们可以使用这个方法进行尝试。不过这个方法使用起来有一定的风险，因为可能你删除的那一串代码虽然能够解决bug，但是却不是bug产生的根源，这个时候你可能会将必现bug改成了偶现bug，让问题变得更加复杂。

• 6.源码分析法。有的时候有些bug可能并不是你的代码导致的问题。可能是第三方库本身的bug，又或者是系统本身的bug，又或者是你误用api导致的问题，这个时候就需要你拥有源码分析的能力。深入源码中，一层层分析直到最终找到bug产生的原因。

• 7.联想法。通过一些类似的bug修改经验从而联想猜测出bug产生的位置。这个方法对使用者本身有较高的要求。需要使用者对项目代码和业务逻辑非常熟悉，同时对问题分析的能力有较高的要求。这就是我们常说的牛人能够一眼就能看出问题，他们常用的就是这种方式。

• 8.场外支援法。这是实在定位不出bug才采取的下下策。因为它并不能提高你定位bug的能力，同时请别人帮忙定位bug，你就需要把你之前所做的工作都要全盘地向他表述一遍，这样不仅会降低bug修复的效率，同时还不一定能保证定位出bug产生的位置，它取决于你表述问题的能力和帮你的人分析和解决问题的能力。

（看了这么久，看看美女放松下吧！）

2.4 确认bug

在我们定位出bug产生的位置后，下面的工作就是分析bug产生的根源了。

这一步可以说是bug修复6个步骤中最为关键的一步。这一步直接决定了这个bug能否被彻底地解决，同时也是最能体现bug修复艺术的步骤。

但是很遗憾的是，这一步往往被很多人给忽视了。我为什么会这样说呢？因为很多时候我们修复bug的时候，都会受到各方面的限制：

• 1.自身经验水平的限制：一些初入项目的程序员经常因为修复一个bug而导致了另一个bug，又或者只是看到了bug的表象却不能感知到bug产生更深层次的原因，所以10种产生bug的情况他可能只改了一种，将必现问题改成了偶现问题，让bug变得更加复杂。

• 2.时间限制：这是我们程序员经常碰到的限制。这在互联网企业非常普遍，通常解决一个bug是有时间限制的，例如：这个项目明天就要上线了，并强制要求你今晚就得想办法解决。这个时候你可能就被逼无奈，采取硬编码的方式去临时把这个bug给按住。其实这样虽然bug是被临时解决了，但是却会让这个bug变得愈加复杂。很多公司出现的那些祖传代码就是在这种情况下产生的，动一下就可能产生无数未知的bug，令人绝望。

• 3.业务限制：很多时候导致代码逻辑非常复杂难懂的罪魁祸首就是这种业务限制。我们在修复一个bug的时候，很多时候就是因为这种业务的限制，导致bug的修复一种不能从根源上予以解决，只要业务一调整就可能导致这个bug反复地出现。

说了这么多限制，那么我们如何才能找到问题的根源呢？

• 1.多积累经验，提升自身的水平：这是打破自身经验水平的限制。

• 2.及时处理bug：在收到bug报告的第一时间就去处理，尽可能打破时间的限制。

• 3.多熟悉业务：有时间就多去了解和梳理业务，深入研究项目代码。这样我们在解决bug的时候也不会因为对业务不熟悉而无法分析出bug产生的根源。

• 4.准确定位bug：bug定位的准确性直接决定了你能否分析出bug产生的根源。因此你需要仔细分析和定位bug，使用我上面介绍的8种方式去定位bug。

2.5 修复bug

其实前面的四步都是为这一步所做的铺垫。有了前面四步的工作，相信到这儿也是相对微不足道的了，剩下的就是如何优美地解决这个bug了。

到了这个阶段，bug通常不需要大的修改来修复，因此这一步往往会非常快，当然也就没有什么好的技巧啦。

2.6 验证bug

作为bug修复的最后一步，它是确保bug被真正修复的最后保障。

在这里需要我们着重注意以下几点：

• 1.重复之前复现bug的步骤来验证bug是否被彻底解决。

• 2.验证bug修复可能改动到的相关模块是否正常，保证bug修复不引入新的bug。

如果上述有任何一点没有达到的话，请返回步骤四和步骤五，重新修复bug！

3.如何提高bug修复的效率

---

上文我们着重讲解了解决bug的艺术，为的是能够更好地解决bug。但是如何才能保证既有效，又快速地修复bug，提高bug修复的效率呢？

通过上面对于解决bug的艺术的讲解，我们可以总结出以下影响bug修复效率的几个关键点：

• 1.bug信息收集的效率以及有效性。

• 2.时间限制的压力。

• 3.人员对项目代码（业务）的熟悉程度。

• 4.人员自身经验和分析问题的能力。

以上4点可以说直接决定了bug修复的效率。那么如何才能提高bug修复的效率呢？下面我将一一给出我的看法。

3.1 建立健全的信息收集机制

bug信息的收集可以说是修复bug过程中最为耗时的环节。提升bug信息收集的效率以及有效性可以大幅度地提升我们修复bug的效率。

那么我们应该如何建立健全的信息收集机制呢？这里我给出我的几点建议：

3.1.1 提供优秀的bug报告模板

上文我们在了解bug一步中提到过：一份优秀的bug报告模板，可以让程序员直接跳过bug修复的前三步，直接进入到确认bug步骤，从而能够极大地提高bug修复的效率。

这里我再次重复一步，一份优秀的bug报告模板应当具备哪些内容：

• bug的标题和问题描述

• 出现bug的应用版本

• 出现bug的设备信息（型号、版本等）

• bug产生相关的视频、截图和错误日志

• bug复现的步骤

• bug出现的必要条件（环境）和恢复途径

• bug修复后的预期效果

• bug对应的模块或者关联bug

3.1.2 建立完备的日志体系

一套完备的日志体系，可以让我们更加清晰地知道用户到底做了什么才导致bug的出现。

在项目的初期，我们可能为了赶工期而常常忽视了日志打印的重要性，这很可能就会导致该项目日后的维护将非常得艰难。

那么我们为什么要建立一套完备的日志体系呢？

• 1.并不是所有的用户（测试）都能够给你描述清楚bug产生的信息。

• 2.即使用户（测试）给你描述了bug产生相关的信息，但是他们并不理解你的代码逻辑，他们只能根据bug出现的现象告诉你问题，可能他们的表述和你的理解不在一个频道。

如果你有这么一套完备的日志体系，那么你就可以在用户（测试）不用开口的情况下，直接get到用户的操作行为以及对于的代码逻辑。同时，可能一句关键点的报错日志就可以帮你直接定位到bug产生的位置，从而直接进入第四步确认bug。

说了这么多，我们应该如何打印高效的日志呢？

• 1.在异常分支返回前打印日志。

• 2.在复杂业务流程的关键点打印日志。

• 3.在对外交互或者模块交互点打印日志。

• 4.在用户交互或者生命周期的关键点打印日志。

• 5.对重要的信息点打印日志，记录用户画像。

• 6.按重要性分等级打印日志。

• 7.禁止在循环中打印日志，禁止打印无效的日志。

• 8.禁止打印用户隐私相关的信息。

3.2 建立自动化测试机制

建立自动化测试机制,可以让突破时间限制成为可能。

3.2.1 更早地发现bug

很多时候来自时间限制的压力，往往是测试不充分导致的。很多bug直到产品临近上线或者交付的时候才被发现，这个时候唯一解决问题的方式就是在时间上做出限制，无情压迫我们这些活在公司权力最底层的程序员们。

如果这个时候能有一套自动化测试机制，每天下班后都进行自动测试的话，那样很多bug就能被提前发现，从而为我们修复bug预留了不少宝贵的时间。

3.2.2 节约bug验证的时间

对于一些复杂难解、偶现的bug，我们往往会在确认bug到验证bug之间花费大量的时间。这个时候如果有一套自动化测试机制或者工具帮助我们验证bug的话，就可以极大地缩减我们修复bug的时间。

3.3 提高项目代码（业务）的熟悉程度

提高人员对项目代码（业务）的熟悉程度，这样就可以极大地提高人员定位bug的效率。

3.3.1 建立丰富的知识库体系

建立一套丰富的知识库体系，可以帮助我们加深对自己责任内项目代码（业务）的理解，同时还能帮助我们快速了解我们所不了解的业务模块。

那么如何才能建立起丰富的知识库体系呢？下面我给出我的几点建议：

• 1.对知识进行分类。

• 2.定期添加和更新知识库的内容。

• 3.提高知识库的检索效率。

• 4.定期组织知识的分享。

• 5.激励贡献知识库的人员。

3.3.2 建立责任田划分机制

划分责任田的目的就是：让专业的人做专业的事情。

划分责任田的好处：

• 1.专业的人做专业的事情。划分完责任田后，田主需要对自己负责的模块负责，这就必然要求其对模块内的代码（业务）更加熟悉。

• 2.责任到人利于追责和bug跟踪。

当然责任田也不是想象中的那么完美，它也存在一定的缺陷：

• 1.职责明确之后可能导致缺少全局视野。一些复杂的bug可能是几个模块共同作用下才产生的，对于这类bug的定位势必会大大增加难度。

• 2.划分责任田之后，可能导致踢皮球的情况。

责任田划分机制，它是一把双刃剑。所以是否需要建立责任田划分机制，还是需要结合企业自身的情况而定的。

4.打铁还需自身硬

---

bug是永远都写不完的，而且程序员留在代码里不仅仅只有bug，还有时光。在解决一个有一个bug的同时，相应的自己能力有没有也得到提升呢？下次遇到同样的问题，会不会又是一脸蒙逼？简而言之，对于程序员而言，技术才是王道。应对bug最好的方法，还是不断的提升自己的技术！我自己作为一个Android开发者，应该能给你一些这样的帮助！

• 4.1 架构师筑基必备技能

目前Android APP开发主流语言就是Java语言，Java语言最大的特性就是提高了软件的交互可能性，可以说安卓手机几乎所有应用程序都是利用Java语言来进行编写的。

知识要点：

1、深入理解Java泛型

2、注解深入浅出

3、并发编程

4、数据传输与序列化

5、Java虚拟机原理

6、高效IO

• 4.2 设计思想解读开源框架

随着互联网企业的不断发展，产品项目中的模块越来越多，用户体验要求也越来越高，想实现小步快跑、快速迭代的目的越来越难，插件化技术应用而生。如果没有插件化技术，美团、淘宝这些集成了大量“app”的应用，可能会有几个g那么大。

所以，当今的Android移动开发，不会热修复、插件化、组件化，80%以上的面试都过不了。

知识要点：

**1、热修复设计

2、插件化框架设计

3、组件化框架设计

4、图片加载框架

5、网络访问框架设计

6、RXJava响应式编程框架设计**

• 4.3 360°全方位性能调优

在不同层次的开发工程师手里，因为技术水平的参差不齐，即使很多手机在跑分软件性能非常高，打开应用依然存在卡顿现象。

另外，随着产品内容迭代，功能越来越复杂，UI页面也越来越丰富，也成为流畅运行的一种阻碍。综上所述，对APP进行性能优化已成为开发者该有的一种综合素质，也是开发者能够完成高质量应用程序作品的保证。

1、设计思想与代码质量优化

2、程序性能优化

• 启动速度与执行效率优化

• 布局检测与优化

• 内存优化

• 耗电优化

• 网络传输与数据储存优化

• APK大小优化

3、开发效率优化

• 分布式版本控制系统Git

• 自动化构建系统Gradle

4、项目实战

• 启动速度

• 流畅度

• 抖音在APK包大小资源优化的实践

• 优酷响应式布局技术全解析

• 网络优化

• 手机淘宝双十一性能优化项目揭秘

• 高德APP全链路源码依赖分析

• 彻底干掉OOM的实战经验分享

• 微信Android终端内存优化实践

• 4.4 Android框架体系架构

Android框架体系架构（高级UI+FrameWork源码） 这块知识是现今使用者最多的，我们称之Android2013~2016年的技术。

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则近万的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：Android）

总结

Android架构学习进阶是一条漫长而艰苦的道路，不能靠一时激情，更不是熬几天几夜就能学好的，必须养成平时努力学习的习惯。所以：贵在坚持！

上面分享的字节跳动公司2021年的面试真题解析大全，笔者还把一线互联网企业主流面试技术要点整理成了视频和PDF（实际上比预期多花了不少精力），包含知识脉络 + 诸多细节。

【Android高级架构视频学习资源】

Android部分精讲视频领取学习后更加是如虎添翼！进军BATJ大厂等（备战）！现在都说互联网寒冬，其实无非就是你上错了车，且穿的少（技能），要是你上对车，自身技术能力够强，公司换掉的代价大，怎么可能会被裁掉，都是淘汰末端的业务Curd而已！现如今市场上初级程序员泛滥，这套教程针对Android开发工程师1-6年的人员、正处于瓶颈期，想要年后突破自己涨薪的，进阶Android中高级、架构师对你更是如鱼得水，赶快领取吧！

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！

" />

总结

Android架构学习进阶是一条漫长而艰苦的道路，不能靠一时激情，更不是熬几天几夜就能学好的，必须养成平时努力学习的习惯。所以：贵在坚持！

上面分享的字节跳动公司2021年的面试真题解析大全，笔者还把一线互联网企业主流面试技术要点整理成了视频和PDF（实际上比预期多花了不少精力），包含知识脉络 + 诸多细节。
[外链图片转存中…(img-VYi6B0Vh-1713675297987)]

【Android高级架构视频学习资源】

Android部分精讲视频领取学习后更加是如虎添翼！进军BATJ大厂等（备战）！现在都说互联网寒冬，其实无非就是你上错了车，且穿的少（技能），要是你上对车，自身技术能力够强，公司换掉的代价大，怎么可能会被裁掉，都是淘汰末端的业务Curd而已！现如今市场上初级程序员泛滥，这套教程针对Android开发工程师1-6年的人员、正处于瓶颈期，想要年后突破自己涨薪的，进阶Android中高级、架构师对你更是如鱼得水，赶快领取吧！

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！