Android程序员在遇到性能优化相关问题时该怎么回答？

一直以来，Android性能优化都是面试过程中考察的热点题目。

相关的技术博客也层不出穷，我们总是能找到很多这样的文章，

从一个应用的各个层面开始分析，优化的种种手段，取得的种种效果。

往往篇幅越长，讲得越细，越受欢迎。

但在面试的时候，问这类问题时，候选人经常答得不尽人意，大部分人会把自己能想起来的优化措施，给背一遍。

背得越多越好，对于候选人自己说，内心也发虚，背完之后面试官毫无表情，因为这并不是他们想要的答案。

我们不妨从面试官的角度来思考。

性能优化有哪些难题

难点一：性能表现差

性能优化的第一个难题是APP的自身性能表现差，这是从APP自身性能使用来说的：

第一种问题是用户可以直观的感受到，比如说：APP启动慢、卡顿、丢桢等，用户肯定会报怨手机太卡了！
第二种问题是用户虽然不会直观的感受到，比如说：内存占用高，抖动频繁，但是这种隐藏的问题可能会导致内存溢出，从而影响程序的正常运行
此外性能问题还有应用耗电、网络请求慢、崩溃率和异常率高

其中崩溃率和异常率属于稳定性的范畴，崩溃率比较好理解需要注意的是应用异常率。异常是指APP不能正常的作出反应，比如说我们点击了一个按钮，它并没有正确的跳转到下一个界面，此时APP并没有崩溃，但是同样它也处于不可用的状态，带来的非常不好的用户体验。

在这里插入图片描述

难点二：线上问题无法排查

线上问题排查困难对于很多Android程序员来说就是个烧（tuo）脑（fa）的问题，下面来说说线上问题排查的主要难点！

在这里插入图片描述

性能优化的第一个难题是线上问题无从排查，这是从排查问题的视角来说，通俗来讲的是耽误线上出现了异常时我们如何才能够保证较高的异常感知灵敏度。

当我们发布了一个新版本或者上线了一个新功能没有用户反馈，我们也千万不能够认为已经成功上线了，因为仅仅依赖于用户反馈这个单一的渠道非常容易错过异常出现的第一时间，等到有用户不堪忍受来反馈造成的损失已经太大，而且也已经错过最好的处理时机。

线上问题排查的第二个难点：如何复原案发现场，假设用户给了我们反馈但是此刻我们也不能够高兴过早。因为用户有反馈不代表我们一定能够复现，很多问题并不是所有用户都会发生，发生了这种特殊问题的用户，他可能是使用了特殊的设备或者是他的账户处于特定的异常状态。等到我们在公司用自己的设备和自己的账户去复现他的问题的时候很有可能会因为条件不足而无法复现，自然也就没有办法快速解决。

线上问题的第三个难点：如何快速修复成功，针对线上问题而言时间就是生命必须尽早的成功修复。在我们修复之后，为了保险起见一般都会开放部分小流量用户或者找特定用户来进行测试。但是如果说我们的手段是连续用户重新安装然后等待结果，这样的解决方案它的周期实在是太长，而且多次下来后用户也会有些反感，最终可能找不到配合你要用户。

综上所述性能优化都是难以定位和解决的，那么如何在面试官面前脱颖而出呢？

这时候一线互联网大厂性能优化项目实战便成为了Android开发工程师参考的重点对象，从问题中找出自己的缺陷，吸取更多项目经验，提升自身的技能知识。因此在这分享这份《Android性能优化实战篇》，让每一个想进入 Android 系统开发和优化这个领域的人,能通过这份笔记手册快速入门，同时也算是对知识的一个梳理,查漏补缺,终身学习（文末直接获取）。