前言

我的Android开发之路

我从事Android开发工作已经7年有余，这些年我不断地思考，写了数十篇文章和近百篇日记，在这个过程中我对Android开发的认识逐渐深入。我想是时候做一个总结了。

入行至今的一些关键节点

2014—2015年：踏上Android开发之旅

我与Android的邂逅，源自一场意外。大学期间，我加入了西安电子科技大学金山俱乐部，当时俱乐部里有很多技术小组：后端、前端、Android开发、Windows Phone开发等。由于我当时使用的手机搭载了 Windows Phone系统，所以我就选了Windows Phone开发小组。

2014年，iOS、Android、Windows Phone、塞班四强并立，Windows Phone的磁贴式设计我非常喜欢，加上使用该系统的设备操作流畅、分辨率高，一度让我觉得它可能会“统治”手机操作系统市场。

没想到的是，不到2个月，我的手机因为意外进水，无法使用了！当时我非常难过，一方面因为手机坏了需要重买；另一方面因为无法继续做Windows Phone开发让我感到遗憾。对当时的我来说，再换一台Windows Phone手机过于昂贵，我只好换了一台便宜的Android手机，也因此转向学习Android开发。

几年后，手机操作系统市场的发展超出了我的预料。Windows Phone由于缺乏良好的开发生态，支持的App很少，因此用户也少。用户少导致开发者更少，形成恶性循环。如今Windows Phone 的全球市场份额已经低于10%。

当时我还做了一个目前看来非常重要的决定：我开始写博客，记录自己的所学所得。

在开发项目时，我经常去网上搜索解决方案，后来搜索次数多了，觉得不能一直都是索取，我也要尝试去分享。于是我在CSDN注册了账号，并于2014年10月发布了我的第一篇原创文章。

后来在工作、学习中学到新知识时，我都会尽可能地把它转换成别人看得懂的内容，写到博客里。这个不起眼的开始，让我逐渐有了解决问题后及时沉淀、分享的习惯，令我受益匪浅。

2015—2017年：明白项目迭代的全流程

在学习Android开发时，我先看了明日科技编写的《Android从入门到精通》，然后看了校内网的一些视频，逐渐可以开发一些简单的App。Android开发“所见即所得”的特点，让我很快就可以得到反馈。后来我又去参加了一些地方性的Android开发比赛，获得了名次，让我逐渐增强了从事Android开发工作的信心。

2015年，我偶然参加了一家公司的招聘会，在面试时，面试官问了我一些简单的与Java、Android和算法有关的问题。其中令我印象最深的就是问我会不会使用四大组件和ListView。

到公司实习后，我感触很多：之前我都是自己拍脑袋写一些简单的功能代码，没有参照开发规范，也没有进行工程结构设计、系统设计，更没有考虑性能是否有问题。真正参与商业项目开发后，我发现了自己的不足。

因此在完成工作的同时，我观察并记录了项目迭代的各个流程，对自己的知识结构查漏补缺，创作了有关Java 源代码分析、Android开发进阶、设计模式的文章。我逐渐养成了定期复盘的习惯，每当回顾过去时，我都会想想自己的成长历程。

2017—2020年：提升复杂项目的架构能力和做事意识

在开发第一个项目时，我基本掌握了从0到1开发一个Android App的流程，但对Android项目架构的认识还只停留在表面，没有足够多的实践。

2017年，我开始接触喜马拉雅直播项目，喜马拉雅在当时已经有多年的技术积累，加上直播业务比较复杂，开发团队在架构设计、编译加速、快速迭代等方面都做了比较多的工作，让我大开眼界。

为了能够提升自己的技术，在这期间我学习了很多框架的源代码，通过分析这些框架的优缺点、核心机制、架构层级、设计模式，我对如何开发一个框架有了基本的认识，也创作了一些文章，比如“Android 进阶之路：深入理解常用框架实现原理”。

有了这些积累，再去实现复杂业务需求、基础框架抽取、内部SDK（Software Development Kit，软件开发工具包）和性能优化，就容易多了。

在实现一些需求或者遇到复杂的问题时，我会先想想之前看的第三方框架或者系统源代码里有没有类似的情况，它们是怎么处理的。

除了技术上的提升，在这几年里，我的项目全局思考能力也提升很多。

由于我的沟通能力较强，领导让我担任一个10人小组的组长，负责跟进项目的需求提出、开发、测试、上线、运营等各个环节，保证项目及时交付并快速迭代。

一开始我有一些不习惯，因为写代码时总是被打断，比如被产品需求评审、测试 bug 反馈、运营反馈线上数据有问题等事情打断，也经常刚想清楚代码怎么写，正准备动手，就被叫去开会，回来后只能重新寻找思路。

后来在和领导沟通、看一些书和文章后，我逐渐对写代码和做事情有了不同的认识。代码只是中间产物，最终我们还是要设计出对用户有价值的产品，要做到这个，除了关注代码，还需要关注其他很多方面。

2020年至今：深入理解底层技术

在进入字节跳动做基础技术开发后，我的技术视野再一次得以拓宽。

字节跳动有多款亿级用户的产品，其中复杂的业务常常会产生各种令人意想不到的问题，这些问题需要技术人员深入理解底层技术，对Android系统的整个架构都比较熟悉，才能够解决。

问题驱动是非常好的学习方式。每次帮助业务方解决一个新问题，我的知识库都会丰富一些，这让我非常兴奋。之前我不知道学来干什么的Linux编程、Android虚拟机，后来终于在实际问题中弄清楚了它们的使用场景，继续深入学习的效率也高了很多。

对软件开发的认识

前面讲了个人的一些经历，接下来讲我从这些经历中沉淀出的有价值的结论，主要包括对下面两点的认识。

● 职业发展的不同阶段。

● 技术的价值。

职业发展的不同阶段

我们在工作时，要对自己做的事有清晰的认识，包括它大概属于哪一个阶段，怎样可以做得更好。结合我这些年的工作内容和业内“大佬”所做的事情，我把软件开发者的职业发展分为以下几个阶段。

第一个阶段就是使用某个技术方向的一个点完成业务需求。比如Android开发者可以使用Android SDK自定义布局，完成产品要求的界面功能。这个阶段的工作内容比较简单，开发者只要能仔细学习官方文档或者看一些书就可胜任。

第二个阶段开发者做的项目更加复杂，会涉及某个技术方向的多个点，这时开发者需要把这些点连起来，提供一个更加体系化的解决方案。

比如Android开发者在自定义布局时，发现页面卡顿，要解决这个问题，开发者就要去了解这个自定义View的哪些代码影响了这个页面的刷新速度。这时开发者需要去研究渲染的基本原理，开发分析卡顿的工具，找到卡顿的原因，进行优化。在这个过程中，开发者会对流畅性有整体的认识，能够对相关问题有比较全面的分析思路、解决手段，从而可以开发相关的分析工具或优化库。如果能做到这一点，开发者基本上就是一名高级工程师了，不仅能做一个模块，还能够负责一个具体细分方向的工作。

第三个阶段是掌握某个技术方向的通用知识，有多个线的实践，能够连线为面，同时给工作做中长期的技术规划。

拿Android开发者来说，刚才提到通过解决卡顿问题，在流畅性方面开发者会有比较多的实践；如果又发现内存有问题，开发者会去了解内存分配、回收原理，开发出内存分析优化工具，这样就有了内存的体系化的实践；再积累一些针对启动速度、包大小等的优化经验。把这些线连起来，就得到了一个性能监控平台，这就是把多条线连成一个面。

再往前发展就不是只做技术，而是要更多地思考业务。技术最终都是为业务服务的。职业发展的第四个阶段，就是不局限于某个技术方向，能够从产品的业务规划、业务指标出发，为产品提供技术支持。

你首先要明白公司业务的核心指标是什么，比如一个短视频App，它的核心指标除了常规的日活跃用户数（以下简称日活）、用户量，还包括视频的播放率、用户的停留时长、页面渗透率等。了解这些指标以后，你要思考做什么可以有助于公司提升这些指标，结合业务的核心指标反思当前的项目中哪里存在优化空间。

总结我对职业发展的不同阶段的认识：第一个阶段只做一些具体的点；第二个阶段做多个点，需要能够连点成线；第三个阶段需要围绕这些线提炼出通用的知识，再做到对业务/技术项目有整体的认识；第四个阶段能够从业务规划、业务指标出发，为产品提供技术支持。

技术的价值

说完职业发展的不同阶段，接下来聊技术的价值。技术是为业务服务的。业务处于不同阶段时，技术的价值也有所不同。

◆业务从0到1时

我刚毕业时所在的公司业务处于确定模式阶段，业务上反复试错，项目常常推倒重来，在这个阶段我们做什么能让公司业务变得更好呢？

第一，尽可能地抽取出相似点，减少重复成本。

如果产品经理每次都对你提出相似的需求，你可以考虑如何把这些相似的需求抽象成一些可以复用的逻辑，做一个基本的框架，然后在下次开发的时候能够直接复用框架，而不是每次都从头开始开发。我平时工作中也常常问自己：“我现在做的事哪些是重复的，哪些是可以下沉的？”

第二，提供便捷的数据反馈机制。

在产品经理提需求时，我们可以问问他这个需求出于什么考虑，有没有数据支撑。比如说产品需求是将某个按钮换一个位置，那我们要清楚原因，在换完之后会使页面打开率提升吗？这种数据驱动的理念对个人和公司业务都大有裨益。

在业务从0到1这个阶段，技术对业务的价值是帮助业务快速确定模式。那在业务从1到100这个阶段技术的价值是什么呢？

◆业务从 1 到 100 时

业务正在快速扩大规模时，需要把当前跑通的业务模式复制到更多的地方，同时能够服务更多的用户。在这个阶段中，技术能够提供的价值主要有以下两点。

第一，快速迭代。

虽然快速迭代是在业务的各个阶段都需要做到的，但和业务从 0 到 1 相比，业务从 1 到 100 的阶段会有更多的挑战，除了个人速度要快，更要关注团队的速度。具体到Android项目，几十甚至上百人共同开发的项目和三两个人开发的项目相比，其复杂度可能会高几百倍。

团队人数增多后可能会出现以下几个问题。

● 多人协作编写的代码有冲突。

● 发布速度慢。

● 问题的影响大，不好定位。

针对这些问题，这个阶段我们可以做如下操作。

● 下沉基础组件，定义组件规范，收敛核心流程。

● 拆分业务模块，设计业务模板，单独维护迭代。

● 探索适合业务的新方式。

第二，提升质量。

和日活为几万的产品相比，日活上千万甚至上亿的产品，质量问题更加显著。在开发时，我们不仅要实现功能，还要能够写好功能，更要能够了解底层原理，才能应对这样大的业务量。为了避免经常在重复的问题上浪费时间，我们需要学会从问题中找到共通点，提炼出可以用于多处的解决思路，输出工具、解决方案甚至平台。

这就需要我们有意识地在问题中磨炼本领，主动站在更高的层面思考自己应该具备的能力。在解决问题的时候，除了解决当下的这个问题，更需要做的是把这个问题解构、归类，抽象出不同问题的相似点和差异，得出问题分析流程图。

结束语

有人总结了人生的多重境界：看山是山，看水是水；看山不是山，看水不是水；看山还是山，看水还是水。

我想，我对软件开发的认识还没有达到第三层，但，怕什么真理无穷，进一寸有一寸的欢喜！