十分同意輪子哥 @vczh 的觀點，只關註細分領域，不打好電腦基礎的人其實挺容易碰壁。
前段時間有個朋友公司的Android客戶端bug多多，找了個新的Android開發來接手，他自己不懂技術，想讓我幫個眼看看新來的Android開發水平如何。
我自己是個半路出家的Java後端開發（也就做了4年，前5年都是遊戲前端），也懂些Android開發，但是對流行框架不熟，所以也就只是抱著半推半就的心態去的，畢竟覺得外行指導內行是瞎指揮。
但是看完程式碼庫和跟開發聊了下，越來越發現，其實他們的Android開發團隊人員問題很明顯：
1、數據結構基礎不紮實。
數據結構從來只認ArrayList，業務裏面明明key-value尋找很多，非要用list實作了來遍歷。問起來為什麽，開發人員回答說HashMap了解不多於是沒用，List同樣可以實作。至於HashSet是啥？能吃嗎？
2、程式碼設計能力弱，OOP理解不全面，邏輯分支管理不到位。
一個類成員變量動輒十來個，仔細閱讀程式碼發現，其實很多是函數級別的臨時變量，完全沒必要提升到類成員級別。問其原因也是說「想到了就寫上，說不定未來有用呢」。留著這麽些成員變量，偵錯的時候簡直想罵娘。
對於一些狀態管理比較復雜的物件，例如地圖SDK的未初始化、初始化中、初始化失敗、重復初始化這些狀態分支沒有完整的覆蓋，只跟著Demo中的例子，僅僅處理了假定成功的執行邏輯，其他的邏輯分支被無視，導致實際執行時sdk狀態一旦fall到了程式碼沒處理的分支中時，程式就hang掉了，這些個問題透過黑盒測試很難發現。
3、過於迷信框架，覺得Android開發就是簡單的建立於一套套框架之上。
在朋友公司的程式碼庫中，單例模式的實作千奇百怪。有的執行緒不安全，有的極度啰嗦。跟開發人員交流發現，他們很迷信框架裏的一些寫法，覺得那是絕對正確的，每個人都這麽做就是對的，至於為什麽只麽做，則沒有做過多的思考，也不會考慮適用性。
有朋友公司裏面有位開發還自己寫了套所謂「框架」放到github上供人使用，還有百來個star，拜讀過後，感覺這東西與其說是框架，更多是像「要你命3000」一樣的東西：它依賴了大量不同的其他外國人寫的框架，把一些初始化的腳手架程式碼寫寫封裝下，就成了自己的框架了。即便在他自己寫的業務程式碼裏，EventBus的事件監聽在Activity結束時都沒正確移除，但是他對於自己的水平倒是有很高的自信，覺得在我朋友公司就是屈才了。
4、Java原生多執行緒編程基礎幾乎為0。Synchronized和volatile語意不明白，thread套用基本也就new完start完就別的不知道了，concurrent包裏的工具類就更不用提。
當時給朋友反映了一下，朋友覺著可以先面試看看有沒有更好的，騎驢找馬，有合適的試用期過了交接完便把這尊菩薩請走。我也就硬著頭皮面幾個看看。
當時JD開的條件是2-3年工作經驗，月薪稅前15K左右，本科學歷。按照經驗，這個條件找到一個水平過得去的Java後端開發不算難，即便不算是高薪。可是面試了十來個人下來，我開始有點絕望了。
針對已有的問題，我在面試的過程中比較著重的考察數據結構基礎和程式碼設計。數據結構只有2個人能夠很好的回答上來，其他都是跟現有的水平差不多。程式碼設計能力方面，也是普遍的軟肋，讓他自己實作個cache，連線口方法應該有哪幾個都說不上的大有人在，更不用說實作細節了。而對於HTTP協定，GET和POST等細節有些也沒很好回答上來，HTTPS相關的知道的人更是少之又少。
但是這些，對於平時Java面試來說應該是真的普適性很高的問題了。Android開發真的不只是bind個view，發個網絡請求，然後更新下界面就完事的了。不少Android的開發人員水平都只是停留在能做個閱讀或者商城套用就自我滿足的狀態，四大元件懂了，butterknife和retrofit就可以一招鮮。但是在我看來，前端開發的難點比後端多著去了，例如：
1、異步操作極多，狀態管理復雜。要想在回呼地獄中完整的管理好view和model的狀態，同時類職責分配好，activity不膨脹。單是做好這點，我覺得已經難能可貴。MVP很多人都是按照例子來做，至於為啥這麽做都是得過且過，況且設計模式不是萬金油，不是說用了就會好，要看適用業務場景。
2、需要處理好狀態恢復。復雜業務流程一長，就需要考慮中斷的流程如何恢復，是交給後端來維護，還是前端記錄資訊後作為事務送出，都是個學問。我朋友的app經常被強退以後就恢復不回來了，或者上一單的資訊被殘留到下一單。
3、在覆蓋安裝更新app時，本地數據的版本管理和遷移。以QQ音樂為例，這樣龐大的歌曲庫，歌單，肯定本地會使用類似sqlite的輕量數據庫。在覆蓋安裝時，可能需要對表結構進行更新。如何管理好跨版本的db結構升級，以及例外處理都是個大學問。即便不用sqlite這個級別，SharedPreference裏面的緩存數據如何管理都是個需要思考的。
4、多版本系統的適配。這個不用多說了，大家都懂的。
以上的這些問題甚至在iOS開發也是同樣會遇到的問題。所以我覺得在面試Android開發職位的時候，考察JavaSE基礎真的一點都不過分，如果他問你EE的內容你真的可以給他翻個大白眼。
至於拿kt來當擋箭牌的，Java基礎不紮實，用kt問題只會更多不會少，JVM是個繞不過的坎。kt裏面的synchronized註解是怎麽個回事你知道嗎？inline和crossinline你知道有啥區別嗎？
自己用了kt半年了，感覺都是戰戰兢兢的，不確定效果需要求穩的地方都是老實用Java實作。但是kt協程真香，android上可以消滅回呼簡直舒服的不要不要的。
一直都覺得，作為開發人員要一直保持著危機感，時刻眼光放遠些，多學些東西，30歲才不會失業，俗話說技多不壓身不是麽。
不說了，回去搬磚了。
