聊聊 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 等其餘技術領域作嘗試。

固然每一個人的理念和選擇可能不一樣，也許個人方式就並不適合你，這裏只是想表達一下：當你以爲本身處於「瓶頸」而焦慮時，或者能夠選擇從別的方向去折騰下。

另外友情提醒，不要給本身隨便定計劃，如要"周更多少文章"或者"月讀多少書"，定了就要儘量去完成，否則由於完成不了計劃的「自做孽」而增長焦慮也是夠夠的。

最後，這裏大多屬於一家之言，僅供參考，主要也是有感而發，但願能對你有點幫助，讓開發的平常也可以繼續安心摸魚！