阅读 9588

聊聊 Android 开发的现状和思考

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

回想这六年里 Android 开发的发展历程,现如今的 Android 已经拥有了成熟的开发体系,技术框架也是经历了一代一代的更新:

  • HttpClientVolleyOkHttpRetrofit
  • ImageLoaderPicassoFrescoGlide
  • OrmLiteLitePalGreenDaoRealmRoom

除了熟悉的网络、图片和数据库“三大件”外,还有像 xUtilsEventBusDaggerRxJavaMultiType 等等,它们对于老 Android 来说,可以说是贯穿了整个“青春期”的回忆。

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

“AS 2.3 又不是不能用?!”

”项目还要继续兼容 4.4 版本?!!”

“RxJava 都还没用上就开始吹协程?!!!”

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

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

“没用过”的焦虑

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

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

那要怎么样缓(tao)解(bi)这种焦虑呢?这就要先理解下这些“新技术”名词不断出现地原因,我把这种“我还没用过”的焦虑理解为“扳手升级副作用”。

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

  • 从 1 到 2 用户拧螺母需要准备的扳手数量减少了;
  • 从 2 到 3 扳手变得更加帅气有力,并且附带的“攻击力”也有所上升;

那问题来了:

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

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

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

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

这里扯了这两个问题其实是想表达:正在情况下随着技术的发展,新生框架和技术是为了让开发变成更便捷,同时降低开发门槛方便后来者入坑。

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

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

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

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

  • RxJava1RxJava2 的变化;
  • Dagger 到现在官方的 Koin
  • 从 Java 的 AsyncTask 到 Kotlin 的协程;
  • ButterKnifeKTX

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

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

比如 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/AACMPEG/MP3
  • 封装协议用 MP4 还是 M3U8
  • 码率和帧率是否需要适应网络?
  • 用软解码 FFMPEG 还是 MediaCodec
  • 视频是否需要支持 AES128 加密?
  • 本地是否要增加离线缓存?
  • 是否要支持断线重连?
  • 后续是否要支持直播和广告的拓展?

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

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

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

  • 一个工单的发起到结束流程会经历什么;
  • 一个购物订单从发起到售后的流转需要考虑什么;
  • 一个订房系统在并发时需要关注的什么;
  • 一个直播系统需要怎么样的技术栈去支撑;

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

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

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

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

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

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

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

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

最后

回归主题,从 2018 Android 提出的 Jetpack 看,到了 2020 年的现在变化其实也不大,也就多了像 ViewPager2CameraXMotionlayout 等的更新(最近还有 HiltPaging 3App Startup ),并且在 Android 10 和 Android 11 开始着重隐私和Scoped Storage 分区等,这大概也是 Android 开发在趋向成熟和稳定的表现。

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

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

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

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

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