从1月10号第一篇文章开始,到现在过去了4个月又20天,陆续写下了性能优化系列文章共计十二篇,大概一个月三篇的节奏。本篇文章是性能系列文章的最后一篇,没有新的大方向优化,讲一下写性能优化系列文章的些许事情:初心,过程,所得。
故事发生在去年年底:某版本上线前当我打开App,唯一的体验就是那如同乌龟爬行般的启动速度。不仅被竞品碾压,更是碾压了我的技术荣辱心:自己做出的App表现差,就是自己差!这是我下定决心要对项目做性能优化的起因。
既然要实践性能优化,而我自己也有知识整理的习惯,那么写系列文章自然是水到渠成,顺便是对自己的一个督促。但还有一个原因:
那既然我要做性能优化,就挑战下这个优秀且全面。也留下好的参考文章给后来的人!
性能优化的过程是一个非常困难的过程,需要你对优化的方向不仅有知识上的充足储备还要有对现存业务上的了解。拿第一篇App启动优化来举例:
难点在于中间三步:
而整理文章的过程更是难上加难,发布出来文章就是自己的一种承诺,既要具备专业性、又要通俗易懂;既要有深度,优化的招数又要尽可能的全面。因此查文档、翻源码是家常便饭。而平时工作也较忙,因此对于一个月三篇的节奏我甚至觉得有点高产(捂脸)。
谈到性能优化,相信各位开发Android的老司机和新司机,都能说上几句。而在面试过程中性能优化也是必问的姿势。但人人都能说几句并不代表对性能优化的理解有多少,不信看几个问题:
相信不少司机肯定说不全,但这条估计要让崇尚“背诵记忆准则”的小伙伴们笑了:我不理解原理,但也能说出几条优化的规则,你安能说我不懂性能优化?诚然性能优化有很多经验、准则可以参考借鉴,但是性能优化却不应该是背诵记忆的机械动作。如果不理解原理,对性能优化的认识、理解不足,任何场景都拿统一的套路生搬硬套,那优化的深度、全面性、适用性一定会大打折扣。
那么在这个并不轻松的性能优化过程中,我得到了什么?
性能优化看似是个纯技术的事情,但是实际上和业务密不可分,毕竟任何技术都是在具体的业务场景下实践应用。因此不熟悉模块业务、具体实现而生搬硬套的话,性能优化工作往往无从下手。
性能优化不是一块孤立的知识,对性能优化的深入理解需要方方面面的技术为辅助,此处仍然以第一篇启动优化为例。
尤其是第三点:每一项都有可能导致性能的瓶颈,而每一项都可以展开阐述,这个过程使你的技术能力得以强化。
大多数情况下,我们都不创造知识而只是知识的搬运工,一般做的就是对知识的搜集和整合。那对我们决胜就是快速的汲取知识以及完成对知识的判断及整合,知道什么地方会有权威、靠谱的资料,判断知识的使用场景等。
而写文章过程中的各种痛苦也不是无用功,经历过不知道怎么写文章的窘迫,才会知道怎么确定文章主题、主线、丰富文章,才会锻炼到自己的表达能力、文字组织能力。
四个字:防微杜渐。很多性能方面的问题都不是一朝一夕产生的,例如OOM,导致OOM发生的代码可能只是压死骆驼的最后一根稻草,前面很多地方已经埋下了隐患,只等最后一个地方点燃。还有很多代码本身并没有错,确实实现了功能,但是放错了位置。
模块开发之前最好对技术方案进行评审,从实现上(源头)尽早规避低性能的实现方式;最好在功能完成之后,使用工具进行性能的分析,进行针对性的优化。