聊聊 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 来说,可以说是贯穿了整个“青春期”的回忆。

聊聊 Android 开发的现状和思考

从一开始的 MVC 到 MVP 再到 MVVM 乃至官方提供的 AAC 架构,Android 的技术栈一直在“刷新”,而随着 Kotlin 的扶正还有 Android Jetpack 的提出,新一代的完善开发体系也给老开发们带来了一些额外的“烦躁”。

“AS 2.3 又不是不能用?!”
”项目还要继续兼容 4.4 版本?!!”
“RxJava 都还没用上就开始吹协程?!!!”

因为旧项目的维护或者工作环境的影响,很多时候其实没有新框架落地的条件,甚至于 Flutter 的出现都会被贩卖一波焦虑。

那就让我们聊聊这种焦虑或者不安。放心,后面没有“防不胜防”!

1

“没用过”的焦虑

对于老 Android 来说, 有一种“焦虑”情绪来自于“我还没用过” ,因为新生的框架和技术在不断迭代,而“没有用过就跟不上时代”的情绪,会在每次技术更新迭代时被反复放大,这大概就是部分 Android 焦虑的来源。

例如现在的 Android Jetpack、协程、 Jetpack Compose 、Flutter 等,每次看到这些字眼时就会莫名地出现“焦虑”,犹如当年一开始听到 Dagger、RxJava 、React Native 一样。

那要怎么样缓(tao)解(bi)这种焦虑呢?

这就要先理解下这些“新技术”名词不断出现地原因,我把这种“我还没用过”的焦虑理解为“扳手升级副作用”。

这里举一个有趣的例子,如下图所示是不同阶段扳手,可以看到:

  • 从 1 到 2 用户拧螺母需要准备的扳手数量减少了;

  • 从 2 到 3 扳手变得更加帅气有力,并且附带的“攻击力”也有所上升;

聊聊 Android 开发的现状和思考

那问题来了:

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

  • 答案是有的,因为 1 中的扳手性价比更高,在特点的场景下会更轻便。

二、那扳手 2 既然都满足大部分场景了,扳手 3 有必要存在吗?

  • 答案也是有的,因为 3 中的扳手更加帅气,同时从健壮的角度更可靠。

这里扯了这两个问题其实是想表达:

正在情况下随着技术的发展,新生框架和技术是为了让开发变成更便捷,同时降低开发门槛方便后来者入坑。

所以作为老 Android 开发,在经历了开发项目需要准备“一堆扳手”的手动挡时代, 如今在这个只要一个“扳手”就能干活的半自动挡时代,怎么可能会拧不动螺母?

过去的日子我们拧了无数的螺母,现在只不过要需要换个“扳手”,而这个扳手是可能是 3 , 第一次拿起来也许会“太重”,扭动的开关也不熟练,但是曾经的螺母需要“拧多深”和“卡什么体位”,这些对我们来说其实和之前没太大区别。

所以只要还是“拧螺母”,我们不应该因为担心“扳手”的品类太多而焦虑,或者还应该“庆幸”这个领域仍在健康发展。

聊聊 Android 开发的现状和思考

技术的健康演进只会让它越来越容易被理解和使用,让开发的门槛变得越来越低:

  • 从 RxJava1 到 RxJava2 的变化;

  • 从 Dagger 到现在官方的 Koin;

  • 从 Java 的 AsyncTask 到 Kotlin 的协程;

  • 从 ButterKnife 到 KTX ;

所以用新的"扳手"肯定比用旧的一堆"扳手"方便,实际上开发者需要维护的代码和逻辑会越来越少,这是一个社区越来越成熟的表现,进而开发的门槛也就越来越低了。

而对于新技术的无法落地到项目的焦虑,我们可以换个思路: 没有条件落地,但是可以去尝试理解这个新框架或技术的本质是什么,从而缓解对未知的恐惧。

比如 Dagger 说白了就是基于注解和模板生成代码,所以如果看不懂各种"生涩"的注解,那可以直接看生成的代码,理解 Dagger 是如何用“臃肿”的代码来为我们解耦。

另外在接下来的 Android Studio 4.1 下,已经开始支持了 Dagger 类的直接跳转,我们可以轻松地在 Dagger 的关联代码间进行导航。

聊聊 Android 开发的现状和思考

所以换一个“扳手”的学习成本并不高,只要你扭螺母的功底还在。“现在还没用过”也不用慌,也许等等技术还能更成熟更方便学习,何况再等等还能白嫖大佬的文章不是么?

当然这里还有一个有趣的误解:

扳手 2 升级后比扳手 1 牛逼了,所以作为使用扳手 2 的我比使用扳手 1 的牛逼?

然而真相是:牛逼的是扳手的制造者,而作为使用者,直接使用 OkHttp 的可能还不如使用 HttpClient 的开发对网络请求的理解"深刻"。

框架降低了开发的门槛,提高了代码的可维护性,但是作为使用者的我们在享受便捷的同时,要变牛逼的根本不在于用,而在于需要理解框架为什么好用!

比如 OkHttp 好用在于它优秀的拦截器设计,而 Retrofit 通过注解生成模板代码提高了开发效率,但是 Retrofit 本身网络请求部分还是需要 OkHttp等去支持。

把框架优秀的部分吃下去,那么你才会变牛逼,OkHttp 的设计就在 Flutter 中就被 Dio 框架完美复现,而 Dio 框架也成为了 Flutter 下热门的网络请求封装之一。

2

竞争力的焦虑

还有一种就是竞争力的焦虑,我们时不时会把自己和年轻一代的开发们做比较, 明显年轻人更便宜更耐C也更有体力 ,这让即将成为后浪的我们产生了职业生涯的焦虑。

因为开发体系的成熟带来了的门槛的降低,开发 Android 应用的要求确实没以前高,但是“能用”和“好用”那是两个故事!

对比年轻人我们存在一些劣势, 但是作为老开发在竞争力上还是有着一些其他的优势,比如:对业务的理解和落地能力。

简单举个例子,在 Android 上产品提出了一个需求

“增加一个播放功能,效果和爱奇艺差不多就行。”

多么“合理”的需求,这时候“吃过盐”的老 Android 相信都会“心头一颤“,在心里默默“问候”产品的同时,开始思考开发前需要讨论的“坑位”:

  • 视频是否需要规定好编码格式,比如 H264/AAC 、MPEG/MP3?

  • 封装协议用 MP4 还是 M3U8?

  • 码率和帧率是否需要适应网络?

  • 用软解码 FFMPEG 还是 MediaCodec ?

  • 视频是否需要支持 AES128 加密

  • 本地是否要增加离线缓存

  • 是否要支持断线重连?

  • 后续是否要支持直播和广告的拓展?

虽说不考虑以上部分写的代码也能用,也有一些开源项目提供“保姆式”支持,但是当你遇到坑后还能不能继续推进项目,并且如何在项目周期内合理避坑,这些都很考验一个开发的综合能力。

这个综合能力自然不只包括代码,而是需要时间慢慢去养成和踩坑来得到。

是的, 在我的角度而言开发不只是写代码,我们的竞争力也不只在于代码,比如业务落地的能力就是长期的经验累积而成 ,比如:

  • 一个工单的发起到结束流程会经历什么;

  • 一个购物订单从发起到售后的流转需要考虑什么;

  • 一个订房系统在并发时需要关注的什么;

  • 一个直播系统需要怎么样的技术栈去支撑;

这些业务在具体场景下需要面对哪些坑?为什么这个业务要这么写?甚至是你在知道这样设计是不合理的情况下,要如何组织代码去避免后期频繁修改带来的负担。

毕竟好的代码千百万,坏的代码都是在业务高压下多次无情的修改摧残出来。

瞎扯了这么多,其实就是想表达:

作为普通人的我们,一般情况下技术并不会成为我们的壁垒,因为现在的 IT 行业很多岗位把脑力密集型变成了体力密集型,996和007需要体力,更需要圆滑的心态去站稳脚跟,年轻气盛的是少年,而行业经验能让我们更好地保存体力去面对职场的“风起涌”。

当然,如果职业几年来都是深水摸鱼,那也无 fuck 可说了~

所以我也一直有个建议: 在条件允许的情况下,尽量选择一个行业,不要今年搞教育、明年干餐饮、后年跳物联网这样跨界。

常年的“跨界”可能到哪都只是“大头兵”,一个行业内的人脉是资源,我们可能不擅长交际,但是我们一直说xxx圈子很小,或者我们能力不是特别出众,但是干的久了认识的圈内人也就多了。

到了 35 岁之后,10年的电商行业经验或者会比 10 年的移动开发经验更有用一点点。

当然这属于站着说要不腰疼,条件允许是指经济压力不大的情况下,不管什么狗屁理论,活下去就是第一要素。

3

总结

回归主题,从 2018 Android 提出的 Jetpack 看,到了 2020 年的现在变化其实也不大,也就多了像 ViewPager2 、 CameraX 、Motionlayout 等的更新,并且在 Android 10 和 Android 11 开始着重隐私和Scoped Storage 分区等,这大概也是 Android 开发在趋向成熟和稳定的表现。

聊聊 Android 开发的现状和思考

所以 Android 现在已经拥有十分成熟的开发体系,成熟也说明了这个系统的带来的开发红利消退了,说通俗点就是可以跳槽岗位少了。

而作为非技术大佬的我,就会选择一些其他的东西来尝试突破,比如前端、RN、Flutter 等其他技术领域做尝试。

当然每个人的理念和选择可能不同,也许我的方式就并不适合你,这里只是想表达一下:当你觉得自己处于“瓶颈”而焦虑时,或者可以选择从别的方向去折腾下。

另外友情提醒,不要给自己随便定计划,如要"周更多少文章"或者"月读多少书",定了就要尽可能去完成,不然因为完成不了计划的“自作孽”而增加焦虑也是够够的。

最后,这里大多属于一家之言,仅供参考,主要也是有感而发,希望能对你有点帮助,让开发的日常也能够继续安心摸鱼!

推荐阅读

入职三个月,游戏SDK开发总结

拖更了三年,带回了一个非常好用的库

吹爆系列:深度探索 Gradle 自动化构建技术

聊聊 Android 开发的现状和思考

扫一扫  关注我的公众号

如果你想要跟大家分享你的文章,欢迎投稿~

┏(^0^)┛明天见!

原文 

http://mp.weixin.qq.com/s?__biz=MzAxMTI4MTkwNQ==&mid=2650831665&idx=2&sn=19fccf3dc473905b15074f420803d04a

本站部分文章源于互联网,本着传播知识、有益学习和研究的目的进行的转载,为网友免费提供。如有著作权人或出版方提出异议,本站将立即删除。如果您对文章转载有任何疑问请告之我们,以便我们及时纠正。

PS:推荐一个微信公众号: askHarries 或者qq群:474807195,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

转载请注明原文出处:Harries Blog™ » 聊聊 Android 开发的现状和思考

赞 (0)
分享到:更多 ()

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址