聊聊 Android 开发的现状和思考

最近和一些跳槽的 “老 Androd” 闲（mo）聊（yu）后很有感触，从事 Android 开发这么多年，你们都开始从新思考将来的发展，或多或少都在为职业生涯的“瓶颈”而烦恼，都有一种“待不住”的情绪在心头徘徊。

回想这六年里 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 扳手变得更加帅气有力，而且附带的“攻击力”也有所上升；

那问题来了：

1、既然有 2 这样便捷的扳手，那 1 这种扳手还有必要存在吗？

• 答案是有的，由于 1 中的扳手性价比更高，在特色的场景下会更轻便。

2、那扳手 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 等其余技术领域作尝试。

固然每一个人的理念和选择可能不一样，也许个人方式就并不适合你，这里只是想表达一下：当你以为本身处于“瓶颈”而焦虑时，或者能够选择从别的方向去折腾下。

另外友情提醒，不要给本身随便定计划，如要"周更多少文章"或者"月读多少书"，定了就要尽量去完成，否则由于完成不了计划的“自做孽”而增长焦虑也是够够的。

最后，这里大多属于一家之言，仅供参考，主要也是有感而发，但愿能对你有点帮助，让开发的平常也可以继续安心摸鱼！