作者：GSYTech
最近和一些跳槽的 “老 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 扳手變得更加帥氣有力，並且附帶的“攻擊力”也有所上升；
那問題來了：
一、既然有 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 等的更新，並且在 Android 10 和 Android 11 開始着重隱私和Scoped Storage 分區等，這大概也是 Android 開發在趨向成熟和穩定的表現。
所以 Android 現在已經擁有十分成熟的開發體系，成熟也說明了這個系統的帶來的開發紅利消退了，說通俗點就是可以跳槽崗位少了。
而作爲非技術大佬的我，就會選擇一些其他的東西來嘗試突破，比如前端、RN、Flutter 等其他技術領域做嘗試。
當然每個人的理念和選擇可能不同，也許我的方式就並不適合你，這裏只是想表達一下：當你覺得自己處於“瓶頸”而焦慮時，或者可以選擇從別的方向去折騰下。T型人才 你懂吧
另外友情提醒，不要給自己隨便定計劃，如要"周更多少文章"或者"月讀多少書"，定了就要儘可能去完成，不然因爲完成不了計劃的“自作孽”而增加焦慮也是夠夠的。
最後，這裏大多屬於一家之言，僅供參考，主要也是有感而發，希望能對你有點幫助，讓開發的日常也能夠繼續安心摸魚！
在這裏我就順便分享一份由幾位大佬一起收錄整理的Android學習PDF+架構視頻+面試文檔+源碼筆記，高級架構技術進階腦圖、Android開發面試專題資料，高級進階架構資料
如果你有需要的話，可以 點這領取
喜歡本文的話，不妨順手給我點個小贊、評論區留言或者轉發支持一下唄~
