2021年为什么这么多人劝退Android开发，学习正确姿势是什么？

最新推荐文章于 2025-10-06 12:41:33 发布

原创最新推荐文章于 2025-10-06 12:41:33 发布 · 3.1k 阅读

6 ·

CC 4.0 BY-SA版权

文章标签：

#android #java #apache #移动开发 #安卓

Andorid进阶专栏收录该内容

311 篇文章

订阅专栏

本文分析了为何有人劝退Android开发，指出移动红利期已过，技术趋向成熟，岗位需求减少。然而，Android仍有发展空间，如JetPack框架的使用，包括ViewBinding和DataBinding等。建议根据业务需求选择适当开发方式，如MVC、MVVM，以及学习Flutter、NDK等技术。同时，提升架构师技能，关注大厂内部调优方案，以应对技术行业的变革。

前言

刚来的也别害怕，其实这也是内卷的一种形式，把你吓跑了，行业内的人就能多点时间休息，不然内卷就会加剧，自己的日子也就越来越难混；还有些不思进取所谓的Android前辈，被自己同事屌，被老板屌，能留在公司都是老板施舍，转头就怪起行业来，实在是可笑。

不过话说回来，Android开发之所以会被劝退，还有以下几个原因：

移动红利期已过。现在需要真才实学，门槛高了不少，不再是当年培训班出来都可以月入一万多的年代了；
业界技术导向。国外巨头由Mobile First转为AI First，国内培训班第一时间跟进，国内各大公司及时跟进，Android岗位HC不断缩减，现在都喜欢3-5年有经验有潜力能力强的人，对初级选手不够友好；
贩卖焦虑。关于『Android失业』的震惊体自媒体文多次在朋友圈出现，『落魄的Android开发』等自黑表情包广泛传阅，导致很多人以为Android真的不行了。2018年GMTC也从移动端大会转型为大前端大会，技术人关注Android的越来越少；
技术趋于成熟。各大公司都有自己的移动端体系，对外分享的部分相对较少，很多东西没有说出来，新技术较少，19年大家在移动端关注较多的应该就是Flutter了。导致大家对Android开发的热情下降，在下降的同时，也会劝退一些想要入行的人。

Android 作为后辈，可以说从2012年以来一路摸爬滚打，也沿着前端开发的路总结出了自己的 MVC 到 MVVM 道路。

刚开始的时候，由于工程结构简单，许多公司处于业务起步，开发模式大多沿用 findViewById 的形式，简单粗暴，但是效率很高，不易出错，MVC 分层思想也很实用。

随着业务的不断扩展，页面也不断增加，那么每个页面都进行 id 的查找操作，就产生很多冗余代码。这时候通过注解方式，在编译时候动态生成代码的框架层出不穷，以 Butter Knife 为代表。这大大减少了查找 id带来的麻烦，同时编译时运行的机制对运行效率也不会有影响。但是开发模式大多仍是 MVC 或 MVP。

看着开发业内百发齐放的框架层出不穷，Google 老大看不下去了，推出了官方推荐的开发框架JetPack 。这个框架包含很多基础类库，并且到目前仍在不断迭代，其中 ViewBinding 和DataBinding 的开发方式，不管是配合框架还是自己单独使用，都是非常方便的。

ViewBinding，有点类似自动查找 id，省去了手动 findViewById 或者手动进行注解的麻烦。通过 gradle 插件，在编译时自动将 view 和 xml 布局文件进行了关联，生成了xxx_binding 的类。这种方式效率很高，不易出错，值得推荐。可以随便网上搜一下使用方法即可。

DataBinding 就有点类似 React 或者其他的数据驱动方式了。通过固有的 xml dsl 编写，把数据传进 xml，实现 view 和数据关联，并随数据变化而自动变化，和 MVVM 的框架思路一致。这种方式比较现代，也是编译时通过 gradle 插件生成代码实现，对效率基本无影响。但是我在使用中发现它有一个问题，有时候工程需要手动 clean ，以确保是使用了最新生成的代码或是解决莫名的找不到代码的错误。同时当你的 view 莫名其妙的变化与预期不符的时候，你需要仔细排查触发事件的源头，比较难通过代码调试出来。

所以当前Android正确的开发姿势是什么？

如果你的工程简单，只是 hybrid 的形式，用 findViewById 配合 MVC 没什么不好。简单粗暴，却清晰易懂。

如果页面不断增多，懒得写这些，用 Butter Knife ，甚至连注解也懒得写，用 ViewBinding。

如果业务逻辑复杂，还要考虑分层，从 MVC 向 MVP 转变。

当然，如果你开发熟练了，不会被一些错误搞得不知所措，那你可以用 DataBinding。

可以根据业务情况参考使用 JetPack 的部分模块去优化工程，减少出错，比较常用的比如 ViewModel，Livedata，LifeCycle 这种。

不管做任何技术行业，都必须要面对技术革新来做出一系列应对方式，比如刻苦学习新技术，转行，直接努努力当个管理，我这里说的并不是真正意义上的内卷，内卷是什么，简单提一嘴：

以前高中都是4点半放学，省排名前60的同学有机会上清华。

现在高中晚上10点半放学，节假日压缩，还是省排名前60的同学能上清华。

成本提高，但是原本就属于自己的收益却没有提高，这便是让职业人闻风丧胆的“内卷”

与其无意义的内卷，想要逃离这个圈子，就必须把自己武装起来，形成自己的技术壁垒，你放心，多的是人每天加班就是划水，你只需要付出一点点努力就能超越一大部分人了。

技术方向的选择

以下的Android技术方向以及其包含的知识点，都整理了一份笔记，有需要的可以找我拿：

获取地址：Android技术交流

架构师筑基必备技能

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

JAVA知识要点：
1、 Java序列化、泛型与反射
2、虚拟机底层原理
3、Android内存原理
4、 Java高级并发原理详解
5、编译时技术掌握与实战
6、JDK高级动态代理
7、高级数据结构与算法
8、 Java IO操作
9、
。。。。

Android R FrameWork源码与UI

在Android中，Framework泛指系统架构层。Framework的中文意思是“框架”，在软件开发中通常指开发框架，在一个系统中处于内核层之上，为顶层应用提供接口，被设计用来帮助开发者快速开发顶层应用，而不必关心系统内核运行机制，通常Framework都会隐藏main函数等应用程序必须的组件，开发人员只需把精力放在功能代码的实现上。说简单点，Framework具体的工作也就是为android应用开发的开发人员提供了一系列的服务和API的接口。

UI其实并不是单纯指用户看到的效果。因为在Android开发中，每个控件背后都有一套深层次的体系在支撑，自然而然，会UI不单纯指的是会自定义控件，我们还应该知道自定义控件背后的执行流程，包括从Activity的创建，XML的解析，到每个控件的测量、布局、绘制。当然在中间还夹杂着比如动画、事件分发机制、嵌套滑动机制等知识点。还有谷歌提供的一些UI框架也使我们要掌握的对象，比如Jetpack组件库、Material Design等。

知识要点：
1、 FrameWork源码解析（SDK 30）
2、Android常用组件深入解析
3、JetPack全家桶
4、Android R新特性解析
。。。。。

大厂内部APP调优方案

性能优化是一个项目必须要经历的过程，你的应用好与坏都是在用户使用的过程中反映出来的，如果性能优化没有做好，对于你的应用来说影响是非常大的。尤其是现在的Android市场竞争非常激烈，如果你的应用体验没有竞品的好，那么用户流失是必然的。

性能优化不是一件简单的事情，每个应用的性能好与坏无法由一个人来决定，因为性能优化的维度有太多了，从我们项目的整体架构，到我们代码的每一个细节，再到应用使用环境的测试，只有步步为营，才能做好一个项目的优化。大部分开发者把性能优化指向与不闪退就行，但是实际上性能优化包含了很多方面，比如从简单的启动优化、 UI优化、卡顿优化、崩溃优化、安全性优化，到深层次的弱网优化、大图加载优化、储存优化、高效传输优化、极限瘦身优化，再到实际开发过程中的OOM问题原理解析、 ANR问题解析、 Crash监控方案。要想把这些优化流程做好，我们不仅从项目架构、代码规范等方面入手，还用学会利用第三方的检测工具来检测项目性能，最主要是，我们需要一套完整的性能优化方案，这正是我们所缺少的，所以我们必须要把缺少的补上，打造一套真正的完整的性能优化体系，把性能优化流程化，常态化。

1、 APP基础优化
2、APP深度优化
3、开发焦点问题优化
4、编程效率优化
5、项目实战
抖音在APK包大小资源优化的实践
优酷响应式布局技术全解析
网络优化
手机淘宝双十一性能优化项目揭秘
高德APP全链路源码依赖分析
彻底干掉OOM的实战经验分享
微信Android终端内存优化实践