一個 Android 技術專家,至少有 2~3 個專業領域。android
連接:https://www.techyourchance.com/android-developer-skills/
做者:Vasiliy Zukanov,獨立 Android 開發及軟件顧問
譯者:羅昭成,Android 開發者程序員
許多 Android 開發者常常會問我,要學會哪些東西才能成爲一個優秀的 Android 工程師?對於這個問題,他們的描述或多或少都有些差別,可是,整體來講,咱們都須要學習一系列的技能,才能成爲一個優秀的 Android 工程師。web
在我看來,存在這樣的困惑是正常的。Android 是一個巨大而且動態的生態系統,你可能須要花好幾周時間去了解並學習它相關的一些工具和概念,可是最後你會發現,它們有好多都不是很重要,或者說並非很是有用。所以,在本文中,我將分享我在 Android 開發中所使用到的重要技能,但願可以幫到你,讓你把你的精力集中到重要的事情上。面試
固然,若是你是一個經驗豐富的 Android 開發者,這些知識可能你都知道。有不少技能和觀點都須要不少基礎知識的沉澱,當你沒有足夠的經驗的時候,很難看到這些技能點。文中,我不可能列出全部 Android 開發者都須要的技能。因此,我根據不一樣的經驗,將這些知識點進行了粗略分組。請注意,這只是一個粗略的分組,並不必定是很精確的。設計模式
若是你只是一個想成爲 Android 開發者的人,而且尚未寫過任何應用,那麼這篇文章對你來講,還有點太早。本文主要是爲了幫助開發者成爲一個更專業的人。網絡
本文,我會給你不少建議,不會讓你空手而歸。文章中列出瞭如何在短期成爲一個專業的開發者。讀完文章,須要你本身去練習,並時常回來看看這些技能。多線程
在本文開始以前,我就當你已經在 Google Play 發佈過 Android 應用而且使用 GitHub 來進行源碼管理。架構
Android 是一個很是複雜的框架,它擁有陡峭的學習曲線。有一些複雜的概念的確是 Native 的 Android 開發者須要學習的,但另外一部分倒是因爲 Android 的緣由,形成了它的複雜度。併發
當你向專業進軍時,除了你的軟件開發工做之外,你應該學習 Android 框架,忘記語言、架構、流行的開源庫,專一於核心概念,並進行深刻的研究。app
具體來講,我建議你更多的瞭解如下內容:
Android 內存管理和進程調度
當面臨「Low Memory Killer」的時候,如何保證你的應用程序穩定可靠的運行?這是一件很複雜的事情。長話短說,當用戶切換到其它應用時,你應用的生命週期就會被打亂,可是當用戶過一下子從新切換回來的時候,用戶卻但願你的應用程序像任何事情都沒有發生過同樣,正常運行。
在本文中,我並不會介紹內存管理的任何細節,若是你想了解它們,能夠看看這篇文章。
生命週期
若是有人要我說出 Android 應用程序中的複雜度和 Bug 的主要來源,我會立馬大聲告訴他是「生命週期」(而後捂住臉哭)。
Application、Activity、Fragment、Service、BroadcastReceiver、ContentProvider 和一些 Android 框架的核心組件,都擁有複雜的生命週期,而且它們的生命週期還不同。若是你以爲這還不夠多,Google 也一直在推出新的庫和框架,這些庫都有本身的複雜性和獨立的生命週期。Loader, ViewModel 和 LiveData 都是爲了解決這些問題而推出的。
有件有意思的事情,我歷來沒有看到過任何有關「生命週期「的定義。咱們一直在使用它,可是它究竟是什麼意思呢?據我所知,在某種程度上,你只是把一些節點串聯在一塊兒,構建出一個生命週期的圖。我對生命週期有過不少的思考,在這裏,我將嘗試對它進行定義。
組件的生命週期是一個抽象的狀態機。這裏的抽象的意思是指,這些狀態機的狀態是預先定義好的,它們之間的轉換條件也是定義好的。可是這些定義是不完整的。你須要去實現缺乏的部分,使他們能夠正常工做。這些缺乏的部分是這些組件方法的子集,咱們稱其爲「生命週期回調」,除了狀態機自己以外,這些生命週期回調中,也有不少隱式的限制和約束。這些限制有些寫在了文檔中,而有些卻並無記錄。
生命週期到底有多複雜?咱們先來看一下這張圖 (它有點不完整,還有點過期)。這張圖,看起來有點可怕。不過,你也不要慌,大多數 Andorid 開發者都搞不明白這個圖。事實上,即便 Google 的 Android 開發者也搞不明白生命週期的問題。Google 在發佈 Lifecycle 組件的時候,裏面引入了一些有關 Fragment 的 bug, 直到後續的新版本發佈了才得以修復。
雖然如今你不須要徹底掌握 Android 的生命週期,可是你必需要知道一些重要的細節。不然,你的代碼會變得混亂不堪,而且容易出現一系列難以解決的問題。我寫了兩篇文章 Activity 生命週期與 Fragment 生命週期 ,描述了生命週期的細節。當你不知道如何使用 onStart 和 onResume 時,你能夠去看看這兩篇文章。
當你掌握了生命週期的基礎知識,你能夠去看看 Gabor Varadi 寫的 Android 開發的十宗罪 ,這篇文章,列舉出了大多數開發者都會犯的錯誤。這些錯誤大多數都與生命週期有關。
順便說一下,在面試中,生命週期相關的問題也會被常常問到。這也是你必須好好學習生命週期的緣由。
Context
在每個 Android 應用程序中,都有一個或多個上下文對象。
和生命週期同樣,它也很難被解釋。它就像是一個「上帝類「同樣,它有很是多的能力。咱們很難用一兩句話就把它描述清楚。儘管如此,理解 Context 職責和不一樣 Context 以前的區別也是很是重要的。
本文中,沒有更多關於 Context 的內容,我建議你去讀一下 StackOverflow 中關於 《What is 'Context' on Android?》 的回答和這個回答的內容.
UI 線程
每個 Android 應用程序都有一個特殊的線程 —— UI 線程。這一個線程在屏幕上繪製出 UI 頁面。若是你讓 UI 線程超負荷運行,你的應用程序將會變得卡頓,不響應。在極端狀況下,UI 線程中的錯誤會致使整個應用程序出錯(至少看起來像是出錯了)。
若是你想詳細瞭解線程背後的機制原理,你能夠去看這個視頻,視頻中詳細解釋了 Android 中的多線程,包含 UI 線程的相關細節和可能存在的問題。
邏輯拆分
從總體上說,Android 框架的代碼很不「整潔」。它包含着不少的上帝類,這些類中,每個有數千行代碼,而且咱們還必須去擴展這些類,才能讓咱們的應用程序運行起來。在多數狀況下,無論是 Application, Activity ,Fragments 仍是 Service,咱們都是在一個很大的類中,作不少的事情。
雖然在 Andorid 開發中,這是一個常見的作法,但這樣子作並不利於長期維護咱們的代碼邏輯。所以我建議,要儘量的注意這個問題,多找機會去重構代碼,將邏輯拆分到獨立的類中去。
說實話,我如今並不認爲,一個初級開發者能夠對架構和設計作出太多的改善工做。正確的封裝代碼邏輯,提取出有意義的類,都須要一些開發經驗。固然,我也不但願你不去思考代碼拆分,你能夠作一些力所能及的事情,避免出現不可控的狀況(例如,一個 Activity 中寫了超過 5000 行代碼)。
剛開始,你能夠嘗試拆分這篇文章中描述的與 Context 有關的邏輯。
當你在你的職業生涯中工做幾年,你變成經驗豐富的 Android 開發者,經過研究和學習,你能夠很輕鬆的實現一些非專業化的功能。那下一步,你該作什麼?
我認爲,在這個時候,你已經很熟悉 Android 框架的基礎知識了,能夠嘗試去學習更高層次的技能。這些技能不侷限於 Android,它們是一些通用的軟件開發的技能。具體來講,你能夠研究如下主題:
依賴注入
依賴注入是一個關注結構分離的設計模式。它主要是用來進行分離應用程序的兩個功能:應用程序和核心功能、核心功能組件實現之間的連接。
從某些方面來講,實現了依賴注入的代碼庫就好你一個計算機:依賴注入的基礎庫就像是主板同樣,而其餘的功能組件就好像是 CPU、內存、外設等。只要你的代碼中實現了依賴注入,你就能夠很方便的插入新功能,而且能夠很容易的重用其它組件的功能,也能夠很方便的使用新組件的功能。雖然這個比喻有點誇張,可是在我看來,它也確實很好的反映了依賴注入背後的思想。
不幸的是,如今關於依賴注入的文章,不少都存在誤解,這給初學者帶來不少干擾。所以,若是你想學習依賴注入,我建議你讀一下這篇文章,本文中,我分析了衆多依賴注入的「神話「。
UI 分離
因爲 Android 框架自己的架構,形成了咱們在開發的過程當中,使用戶頁面與應用程序中的其它邏輯耦合在一塊兒。幾乎全部的 Android 初學者都會這樣。這種耦合會致使咱們寫一個很大的類,這個類裏面有應用程序的 UI 繪製、網絡處理、多線程處理、應用業務邏輯等。
根據個人經驗,UI 邏輯與其它邏輯耦合在一塊兒,會致使代碼的可維護性愈來愈差,早晚會使用代碼變得難以理解,沒法閱讀。到最後,可能會由於功能上的一點小變化,引發很大的反作用。
要將 UI 邏輯與其它邏輯進行分離,能夠用使用 Model- View - X 的架構模式。例如: Model-View-Contoller(MVC)、Model-View-Presenter(MVP)、Model-View=ViewModel(MVVM)。這些架構模式都屬於同一類架構,固然,這一類架構不只僅包含列舉的這幾個,還有其它的架構模式。在這裏,爲了更方便的描述這一類架構模式,我把他們統稱爲 MVx 模式。
當你在學習 MVx 模式的時候,請記住,這些都不是架構,而是一種架構模式。這些架構模式僅用於 UI 展現邏輯。所以僅僅使用 MVx 並不能給你一個好的架構,要有一個好的架構,你還須要在其它方面作出更多的努力才能實現。
多線程
有經驗的 Android 開發者都會了解多線程,而且瞭解他們對應用程序的影響。你也許會說,我精通 AsyncTask、RxJava、協程等。我想表達的多線程不是你理解的這個。會使用多線程框架並不等同於理解多線程。
舉個例子,衆多 Android 開發者都認爲,使用 AsyncTask 會致使內存泄漏。這個觀點來自 Android Studio 默認的多線程 lint 規則中。既然如此,那這個觀點就是對的了嗎?很不幸,這個觀點是錯誤的。在這裏,我不講解它們的細節,你能夠讀一下這篇文章,裏面有不少關於 AsyncTask 的內容。
我認爲要理解多線程程,就必須可使用任何多線程框架,甚至是基於基礎的 Thread ,均可以寫出正確的併發代碼。要實現這個目標,你不只僅須要知道你喜歡的多線程庫的 API,你還須要理解多線程的細節。這些多線程庫雖然好用,但若是你不理解多線程的基礎細節,那麼你的應用程序出現多線程的問題只是時間問題。
若是你想學習多線程,從這個視頻 開始,視頻中講解了全部 Android 開發人員都須要知道的基本概念與原理。
自動化測試
據我所知,不少 Android 項目,都沒有使用任何的自動化測試。在使用自動化測試的項目中,大多數也是 QA 人員使用 Appium 之類的工具來完成的。這是整個 Android 行業的現狀,很是可悲。之因此沒有自動化測試,這個問題能夠追溯到 Android 起源,Google 也在很長一段時間裏,沒有關注過第三方應用的自動化測試。
現現在,有單元測試和 UI 自動化測試經驗的開發者需求量很大。即便你到一家沒有使用過任何自動化測試的公司去面試,若是你說你會自動化測試,就會給你的面試加分。反之,若是你去的是一個普遍使用自動化測試的公司,你沒有自動化測試的技能,這會給你面試減分,處於劣勢。
所以,我建議每個 Android 開發者都去學習一下自動化測試的相關知識。就我的而言,我更喜歡單元測試。而一些開發者喜歡 UI 自動化測試。因此,能夠選擇一個你更感興趣的技術,嘗試一下。
若是你對 Android 已經有了很是豐富的開發經驗,那麼,是時候學習一些「元」技能了,而且在特定領域進行深度研究。在我看來,如下技能對專業的開發人員來講,都是很是不錯的方向。
技術方案評估
若是你尚未作過這件事情,那麼如今是時候開始作了。每個重要的技術決定,都須要進行評估、權衡。有時候,這種決定帶來的結果很是好,立竿見影。可是大多數時候,並不是老是可以立竿見影,看到效果。一般狀況下,須要決策的範圍越大,所涉及到的評估範圍就越大,除了能夠簡單進行決策的事情,還有不少可評估項都是很是抽象,短期內根本看不到結果的。
在本身豐富的經驗水平下,面對衆多選擇,你至少應該知道如何找到取捨。若是你能對技術方案評估提供有用的建議,你就很是優秀了。技術方案評估權衡這是一項很是複雜的技能。一般,在與其它開發者、項目經理甚至是其它部門員工討論的時候,你能找到折中方案,就能進行方案評估。所以,在大數狀況下,你只須要掌握評估方案的能力就夠了。
那咱們所說的「技術方案的評估」究竟是什麼意思?說實話,很難具體說明它是什麼。不過,咱們能夠提供一些反例,來解釋爲何不適合在開發中使用。舉個例子:
咱們應該將多線程的使用遷移到 RxJava, 而不是 AsyncTask, 由於 AsyncTask 會致使內存泄漏。
正如我前面所說,AsyncTask 並不會致使內存泄漏。因此上面這句話是錯誤的。說這句話的開發者並無深刻的研究多線程。此外,他也沒有提到 RxJava 的問題。對於一個項目中的開發人員來講,RxJava 存在一個很陡峭的學習曲線。
咱們應該爲咱們的新代碼寫單元測試,而且設定一個長期的目標,覆蓋全部的代碼,以確保咱們的代碼質量。
這句話包含幾個前提,首先,咱們如今開始單元測試是不可能的,至少須要開發人員投入時間來學習這種技術。編寫單元測試是一個很明智的決定。咱們不能爲全部代碼編寫單元測試,由於有一些部分是不穩定的。最後,達到特定的覆蓋目標並不會自動提升「質量「。在這個例子中,開發者並不瞭解單元測試,他們沒法肯定在項目中使用單元測試所涉及的問題和影響。
我但願,你對「技術方案評估」已經有了大體的想法,若是你有一個重要的決定,你須要完成全部必要的調研,若是你依然看不到整個評估中存在的複雜網絡,那多是你的調研沒有作好。在作決定的時候,有些事情可能超出技術範圍,你也須要考慮你的決策對其它部門同事的影響。
專業領域
如何區分一個技術專家和一個普通開發者?是咱們熟悉的概念的數量嗎?我認爲,在技術方面,區分是不是專家主要在於知識上的深度。
做爲一個技術專家,你應該有一個或者多個專業領域。你知道這些領域的詳細細節,比通常的開發者知道的要多得多。你須要持續深刻的研究,來保證你的專業深度,瞭解專業領域的最新發展,不會對新的工具和技術感到驚訝。此外,即便你並無在任何項目中使用某些技術,你也須要研究這些技術使用上相關聯的各類成本。
現現在,有一個本身的專業領域很難。這不是從博客中挑選幾篇好文章進行閱讀就能夠的,也不是讀完幾本好書、上完幾門好課就能夠的。固然,經過這些內容進行學習,對你的專家之路都是有幫助的,可是要有本身的專業領域,惟一的方法就是積極參與其中進行學習研究並得到大量經驗。
我很喜歡物理學家尼爾斯·玻爾說的這句話:
An expert is a man who has made all the mistakes which can be made, in a narrow field.(專家就是把領域內全部該犯的錯都犯完的人。)
咱們能夠在哪些領域進行深刻研究呢?實際上,幾乎全部的均可以進行深刻的研究,在軟件開發領域,沒有任何一個領域會由於過小而不能設置成專業目標。對此,我也有一些建議:
UI
構建系統
離線工做
併發
NDK
持續集成
性能
架構
監測
項目管理
專業知識領域
還有不少不少。須要注意的是,上面我列出來的內容,一些並不屬於嚴格的技術領域。只要你能爲你的僱主產生價值,你能夠選擇你喜歡的任何領域並進行深刻研究。
我認爲,一個 Android 技術專家,至少有 2~3 個專業領域,例如,個人專業領域是:架構、單元測試、併發、依賴注入。我相信,在不久的未來,我可以將「重構祖傳代碼」添加個人專業技能列表裏面。
因此,若是你有 4 年以上的經驗,你的專業領域是什麼?
以上,這是我建議你,做爲一個專業的 Android 開發者應該具有的技能。
你可能已經發現,個人文章標題是 《Android Developer Skills for 2020(2020 年,Android 開發者須要的技能)》,可是這篇文章中沒有什麼內容是特定於 2020 年的。我能夠在一兩年前寫這篇文章,由於本文內容適合全部時間,基礎和重要的概念不會常常改變。
如今,若是你對 Android 生態系統的最新發展感到好奇,你能夠閱讀個人另外一篇文章 ,我總結了 2019 年末 Android 發展的情況。最後,我再重複一次,若是你想成爲一個優秀的 Android 開發人員,請集中精力,對基礎和重要的事情作深度研究。
一如既往,感謝你的閱讀。你能夠在下面留言評論和提問。
最後小編想說:不論之後選擇什麼方向發展,目前重要的是把Android方面的技術學好,畢竟其實對於程序員來講,要學習的知識內容、技術有太多太多,要想不被環境淘汰就只有不斷提高本身,歷來都是咱們去適應環境,而不是環境來適應咱們!
當程序員容易,當一個優秀的程序員是須要不斷學習的,從初級程序員到高級程序員,從初級架構師到資深架構師,或者走向管理,從技術經理到技術總監,每一個階段都須要掌握不一樣的能力。早早肯定本身的職業方向,才能在工做和能力提高中甩開同齡人。
想要拿高薪實現技術提高薪水獲得質的飛躍。最快捷的方式,就是有人能夠帶着你一塊兒分析,這樣學習起來最爲高效,因此爲了你們可以順利進階中高級、架構師,我特意爲你們準備了一套高手學習的源碼和框架視頻等精品Android架構師教程,保證你學了之後保證薪資上升一個臺階。(如下是一小部分,獲取更多其餘精講進階架構視頻資料能夠點擊下面的小卡片獲取)
當你有了學習線路,學習哪些內容,也知道之後的路怎麼走了,理論看多了總要實踐的。
如下是今天給你們分享的一些獨家乾貨:
《Android架構視頻+BAT面試專題PDF+學習筆記》
【Android開發核心知識點筆記】
【Android思惟腦圖(技能樹)】
【Android核心高級技術PDF文檔,BAT大廠面試真題解析】
【Android高級架構視頻學習資源】
Android精講視頻領取學習後更加是如虎添翼!進軍BATJ大廠等(備戰)!如今都說互聯網寒冬,其實無非就是你上錯了車,且穿的少(技能),要是你上對車,自身技術能力夠強,公司換掉的代價大,怎麼可能會被裁掉,都是淘汰末端的業務Curd而已!現現在市場上初級程序員氾濫,這套教程針對Android開發工程師1-6年的人員、正處於瓶頸期,想要年後突破本身漲薪的,進階Android中高級、架構師對你更是如魚得水,趕快領取吧!
上述【高清技術腦圖】以及【配套的架構技術PDF】點擊:《Android架構視頻+BAT面試專題PDF+學習筆記》
便可獲取!
以爲不錯,記得點個關注,第一時間獲取最新資訊和技術分享哦