最近和一些跳槽的 “老 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 等的更新(最近還有 Hilt、Paging 3、App Startup )，並且在 Android 10 和 Android 11 開始著重隱私和Scoped Storage 分割槽等，這大概也是 Android 開發在趨向成熟和穩定的表現。
所以 Android 現在已經擁有十分成熟的開發體系，成熟也說明了這個系統的帶來的開發紅利消退了，說通俗點就是可以跳槽崗位少了。
而作為非技術大佬的我，就會選擇一些其他的東西來嘗試突破，比如前端、RN、Flutter 等其他技術領域做嘗試。
當然每個人的理念和選擇可能不同，也許我的方式就並不適合你，這裡只是想表達一下：當你覺得自己處於“瓶頸”而焦慮時，或者可以選擇從別的方向去折騰下。
另外友情提醒，不要給自己隨便定計劃，如要"周更多少文章"或者"月讀多少書"，定了就要儘可能去完成，不然因為完成不了計劃的“自作孽”而增加焦慮也是夠夠的。
最後，這裡大多屬於一家之言，僅供參考，主要也是有感而發，希望能對你有點幫助，讓開發的日常也能夠繼續安心摸魚！