回想这六年里 Android 开发的发展历程，现如今的 Android 已经拥有了成熟的开发体系，技术框架也是经历了一代一代的更新：
HttpClient、Volley、OkHttp、Retrofit；ImageLoader、Picasso、Fresco、Glide；OrmLite、LitePal、GreenDao、Realm、Room；
除了熟悉的网络、图片和数据库 “三大件” 外，还有像 xUtils 、 EventBus 、 Dagger 、 RxJava 、 MultiType 等等，它们对于老 Android 来说，可以说是贯穿了整个 “青春期” 的回忆。
从一开始的 MVC 到 MVP 再到 MVVM 乃至官方提供的 AAC 架构，Android 的技术栈一直在 “刷新”，而随着 Kotlin 的扶正还有 Android Jetpack 的提出，新一代的完善开发体系也给老开发们带来了一些额外的 “烦躁”。
“AS 2.3 又不是不能用？！”
” 项目还要继续兼容 4.4 版本？！！”
“RxJava 都还没用上就开始吹协程？！！！”
因为旧项目的维护或者工作环境的影响，很多时候其实没有新框架落地的条件，甚至于 Flutter 的出现都会被贩卖一波焦虑。
那就让我们聊聊这种焦虑或者不安。放心，后面没有 “防不胜防”！
# “没用过” 的焦虑
对于老 Android 来说，有一种 “焦虑” 情绪来自于 “我还没用过”，因为新生的框架和技术在不断迭代，而 “没有用过就跟不上时代” 的情绪，会在每次技术更新迭代时被反复放大，这大概就是部分 Android 焦虑的来源。
例如现在的
Android Jetpack、协程、Jetpack Compose、Flutter等，每次看到这些字眼时就会莫名地出现 “焦虑”，犹如当年一开始听到Dagger、RxJava、React Native一样。
那要怎么样缓（tao）解（bi）这种焦虑呢？这就要先理解下这些 “新技术” 名词不断出现地原因，我把这种 “我还没用过” 的焦虑理解为 “扳手升级副作用”。
这里举一个有趣的例子，如下图所示是不同阶段扳手，可以看到：
- 从 1 到 2 用户拧螺母需要准备的扳手数量减少了；
- 从 2 到 3 扳手变得更加帅气有力，并且附带的 “攻击力” 也有所上升；
那问题来了：
一、既然有 2 这样便捷的扳手，那 1 这种扳手还有必要存在吗？
- 答案是有的，因为 1 中的扳手性价比更高，在特点的场景下会更轻便。
二、那扳手 2 既然都满足大部分场景了，扳手 3 有必要存在吗？
- 答案也是有的，因为 3 中的扳手更加帅气，同时从健壮的角度更可靠。
这里扯了这两个问题其实是想表达：正在情况下随着技术的发展，新生框架和技术是为了让开发变成更便捷，同时降低开发门槛方便后来者入坑。
所以作为老 Android 开发，在经历了开发项目需要准备 “一堆扳手” 的手动挡时代，如今在这个只要一个 “扳手” 就能干活的半自动挡时代，怎么可能会拧不动螺母？
过去的日子我们拧了无数的螺母，现在只不过要需要换个 “扳手”，而这个扳手是可能是 3 ，第一次拿起来也许会 “太重”，扭动的开关也不熟练，但是曾经的螺母需要 “拧多深” 和 “卡什么体位”，这些对我们来说其实和之前没太大区别。
所以只要还是 “拧螺母”，我们不应该因为担心 “扳手” 的品类太多而焦虑，或者还应该 “庆幸” 这个领域仍在健康发展。
技术的健康演进只会让它越来越容易被理解和使用，让开发的门槛变得越来越低：
- 从
RxJava1到RxJava2的变化； - 从
Dagger到现在官方的Koin； - 从 Java 的
AsyncTask到 Kotlin 的协程； - 从
ButterKnife到KTX；
所以用新的 "扳手" 肯定比用旧的一堆 "扳手" 方便，实际上开发者需要维护的代码和逻辑会越来越少，这是一个社区越来越成熟的表现，进而开发的门槛也就越来越低了。
而对于新技术的无法落地到项目的焦虑，我们可以换个思路：没有条件落地，但是可以去尝试理解这个新框架或技术的本质是什么，从而缓解对未知的恐惧。
比如 Dagger 说白了就是基于注解和模板生成代码，所以如果看不懂各种 "生涩" 的注解，那可以直接看生成的代码，理解 Dagger 是如何用 “臃肿” 的代码来为我们解耦。
另外在接下来的 Android Studio 4.1 下，已经开始支持了 Dagger 类的直接跳转，我们可以轻松地在 Dagger 的关联代码间进行导航。
所以换一个 “扳手” 的学习成本并不高，只要你扭螺母的功底还在。“现在还没用过” 也不用慌，也许等等技术还能更成熟更方便学习，何况再等等还能白嫖大佬的文章不是么？
当然这里还有一个有趣的误解：
扳手 2 升级后比扳手 1 牛逼了，所以作为使用扳手 2 的我比使用扳手 1 的牛逼？
然而真相是：牛逼的是扳手的制造者，而作为使用者，直接使用 OkHttp 的可能还不如使用 HttpClient 的开发对网络请求的理解 "深刻"。
框架降低了开发的门槛，提高了代码的可维护性，但是作为使用者的我们在享受便捷的同时，要变牛逼的根本不在于用，而在于需要理解框架为什么好用！
比如 OkHttp 好用在于它优秀的拦截器设计，而 Retrofit 通过注解生成模板代码提高了开发效率，但是 Retrofit 本身网络请求部分还是需要 OkHttp 等去支持。
把框架优秀的部分吃下去，那么你才会变牛逼，
OkHttp的设计就在 Flutter 中就被Dio框架完美复现，而Dio框架也成为了 Flutter 下热门的网络请求封装之一。
# 竞争力的焦虑
还有一种就是竞争力的焦虑，我们时不时会把自己和年轻一代的开发们做比较，明显年轻人更便宜更耐 C 也更有体力，这让即将成为后浪的我们产生了职业生涯的焦虑。
因为开发体系的成熟带来了的门槛的降低，开发 Android 应用的要求确实没以前高，但是 “能用” 和 “好用” 那是两个故事！
对比年轻人我们存在一些劣势，但是作为老开发在竞争力上还是有着一些其他的优势，比如：对业务的理解和落地能力。
简单举个例子，在 Android 上产品提出了一个需求：
“增加一个播放功能，效果和爱奇艺差不多就行。”
多么 “合理” 的需求，这时候 “吃过盐” 的老 Android 相信都会 “心头一颤 “，在心里默默 “问候” 产品的同时，开始思考开发前需要讨论的 “坑位”：
- 视频是否需要规定好编码格式，比如
H264/AAC、MPEG/MP3？ - 封装协议用
MP4还是M3U8？ - 码率和帧率是否需要适应网络？
- 用软解码
FFMPEG还是MediaCodec？ - 视频是否需要支持
AES128加密？ - 本地是否要增加离线缓存？
- 是否要支持断线重连？
- 后续是否要支持直播和广告的拓展？
虽说不考虑以上部分写的代码也能用，也有一些开源项目提供 “保姆式” 支持，但是当你遇到坑后还能不能继续推进项目，并且如何在项目周期内合理避坑，这些都很考验一个开发的综合能力。
这个综合能力自然不只包括代码，而是需要时间慢慢去养成和踩坑来得到。
是的，在我的角度而言开发不只是写代码，我们的竞争力也不只在于代码，比如业务落地的能力就是长期的经验累积而成，比如：
- 一个工单的发起到结束流程会经历什么；
- 一个购物订单从发起到售后的流转需要考虑什么；
- 一个订房系统在并发时需要关注的什么；
- 一个直播系统需要怎么样的技术栈去支撑；
这些业务在具体场景下需要面对哪些坑？为什么这个业务要这么写？甚至是你在知道这样设计是不合理的情况下，要如何组织代码去避免后期频繁修改带来的负担。
毕竟好的代码千百万，坏的代码都是在业务高压下多次无情的修改摧残出来。
瞎扯了这么多，其实就是想表达：作为普通人的我们，一般情况下技术并不会成为我们的壁垒，因为现在的 IT 行业很多岗位把脑力密集型变成了体力密集型，996 和 007 需要体力，更需要圆滑的心态去站稳脚跟，年轻气盛的是少年，而行业经验能让我们更好地保存体力去面对职场的 “风起云涌”。
当然，如果职业几年来都是深水摸鱼，那也无 fuck 可说了～
所以我也一直有个建议：在条件允许的情况下，尽量选择一个行业，不要今年搞教育、明年干餐饮、后年跳物联网这样跨界。
常年的 “跨界” 可能到哪都只是 “大头兵”，一个行业内的人脉是资源，我们可能不擅长交际，但是我们一直说 xxx 圈子很小，或者我们能力不是特别出众，但是干的久了认识的圈内人也就多了。
到了 35 岁之后，10 年的电商行业经验或者会比 10 年的移动开发经验更有用一点点。
当然这属于站着说要不腰疼，条件允许是指经济压力不大的情况下，不管什么狗屁理论，活下去就是第一要素。
# 最后
回归主题，从 2018 Android 提出的 Jetpack 看，到了 2020 年的现在变化其实也不大，也就多了像 ViewPager2 、 CameraX 、 Motionlayout 等的更新 (最近还有 Hilt 、 Paging 3 、 App Startup )，并且在 Android 10 和 Android 11 开始着重隐私和 Scoped Storage 分区等，这大概也是 Android 开发在趋向成熟和稳定的表现。
所以 Android 现在已经拥有十分成熟的开发体系，成熟也说明了这个系统的带来的开发红利消退了，说通俗点就是可以跳槽岗位少了。
而作为非技术大佬的我，就会选择一些其他的东西来尝试突破，比如前端、 RN 、 Flutter 等其他技术领域做尝试。
当然每个人的理念和选择可能不同，也许我的方式就并不适合你，这里只是想表达一下：当你觉得自己处于 “瓶颈” 而焦虑时，或者可以选择从别的方向去折腾下。
另外友情提醒，不要给自己随便定计划，如要 "周更多少文章" 或者 "月读多少书"，定了就要尽可能去完成，不然因为完成不了计划的 “自作孽” 而增加焦虑也是够够的。
最后，这里大多属于一家之言，仅供参考，主要也是有感而发，希望能对你有点帮助，让开发的日常也能够继续安心摸鱼！
