先mark一下,好多人我發現始終停留在兩三年的水平上沒有突破。java
另外還有一個誤區就是越底層越牛逼react
第三個就是,我認識的大部分所謂的作過rom開發的對framework的熟悉程度遠不如我一個一直作應用的,大概是見木不見林,始終在那一個小角落裏修修補補,不會橫向,也沒有縱向延伸。另外這裏很重要的一點是基礎,好比你是否有*nix基礎,能夠幫你快速理解不少東西android
晚上有時間的話把這三塊展開說一下git
---------------------分割線,這麼多評論,壓力好大-----------------------程序員
首先第一個問題:爲何不少人會一直停留在兩三年的水平上,然後一直在重複以往的經驗?
我認爲最主要的一點就是主觀能動性,或者說興趣,若是你對Android開發沒有太大的興趣,那麼仍是儘早換方向吧。有了興趣,而後就是要有一個比較正確的鑽研路線,不要這也搞那也抓,最後什麼都沒精通又好像什麼知道。一個很好的例子就是我用過不少庫啊 github
第二個階段,我以爲能夠嘗試去了解Android Framework比較細節的一些東西,好比activity啓動流程,順便分析清除Activity stack的管理,好比了解Android的資源加載機制,順便了解aapt是如何打包Android資源的;又好比Java的類加載機制,這裏配合資源的加載機制,很天然的就能夠去了解Android的hotpatch機制,插件化的實現,開一些這方便的開源庫或者本身擼一個也就天然而然。這裏我比較推薦 web
同窗的一系列博客,分析Android各類源碼很不錯。這個階段你能夠用技術反哺業務,好比插件化和hotpatch就可讓業務更加靈活。第三個階段,橫向擴展,到這個階段並非說比第二個階段更加高級了,而是對第二個階段的一些補充,好比你是否是能夠了解一下web開發,這樣作hybrid開發的時候就會更順手。是否是要了解一下這麼火爆的ReactNative&Weex技術,甚至能夠把他們的一些思想拿過來本身用,好比我司內部就有不少項目是用了JSCore和CssLayout來實現一些更輕量的動態化技術的。正如科學領域不少重大貢獻都是在交叉學科領域出現的。技術上到了這個階段甚至能夠作到技術影響業務,技術驅動業務。面試
第二個問題:技術越底層越牛逼麼?
其實大部分技術都是爲了知足業務需求,我認爲這種場景下,是能越好的反哺驅動技術才越牛逼,和底層不底層不要緊。好比你app作的很是牛逼,交互和性能很是好,直接帶動業務飛速發展,我以爲你並比能作底層人差,術業有專攻,以你的態度和能力,即便去作底層開發,也是沒有問題的。算法
第三個就是爲何不少作rom的反而對Framework不是很熟悉
我以爲這個和第一個問題有些重複,興趣是很大的緣由。另一個問題就是,若是沒有*nix的編程基礎,底層的一些東西好比binder機制,好比runloop可能會有一些吃力。這裏服務端的同窗可能會有一些優點,他們對rpc和一些系統調用相對熟悉一些,這也是爲何不少後端轉到Android的同窗能夠快速精通。sql
------囉囉嗦嗦寫這麼多,請你們來拍磚-------
我猜你這個階段是把大部分demo都能跑通了吧,常見的控件也會了吧。
可是,你如今仍是會的太少了。
就是會用Linearlayout/relativelayout/button/textview/edittext/imageview(的不多一部分屬性)來畫一些簡單的界面了吧。
就是會用activity/fragment(的生命週期這麼少的知識)來讓ui在手機裏面顯示出來了吧。
就是會用asynctask(這麼簡單的一個過期的類)來網絡請求了吧。
就是會繼承了個Application類來接幾個第三方服務(幾行代碼就接入)了吧。
就是會用個broadcast(估計只會最基本的顯式廣播,排隊廣播,粘性廣播啥的都不會用)了吧。
就是會ListView+BaseAdapter+ViewHolder(總共不到10個重載的方法)或者recycleview+adapter(估計不會自定義layoutmanager,估計沒才過itemanim的坑)來展現數據了吧。
這總共就多大一點知識啊,學的這些東西內容這麼少,不迷茫纔怪。
若是我說屈你了。
好。你說你比這強。
都會自定義控件(總共就measure draw layout這三個方法)了,還會volley(代碼寫的一堆callback hell),還會sqllite(這玩意沒多大用,也是死東西)勒,還會xml裏面定義動畫(就平移 反轉 透明 旋轉 屬性這幾種)勒,甚至你還會eventbus(別說只會onEventMainThread哦),你還會rxjava(學過函數式語言的都感受這沒啥)。
你說你還追新,md控件玩的溜的很,toolbar(兼容到4.4的沉浸式狀態欄會用不?)會用,drawerlayout會用(碰到過與surfaceview衝突的狀況不?),還會用coordlayout+collapsinglayout+recycleview來作隱藏額頭(知道那個collapsinglayout中的mode是幹啥的不,自定義behavor會不?:)
這些都會了不?
啥,你都會了?再留個做業。
APP裏面的main在哪?
別的桌面應用框架像Qt,人家顯示控件都要new一個window,那咱app的這個渲染控件的window在哪new的,咋讓咱屏幕聽話跟着畫的?
咱手機這麼多傳感器,那傳感器數據咋來到咱app的?
那manifest在咱手機裏面咋滾輪的,發生了啥,系統咋處理的?
我在美團裏面能打開支付婊的支付界面,這在咱手機裏面發生了啥?
不少人都提供了很是不錯的答案,我也是受益不淺,謝謝各位。
可是我以爲不少排名靠前的答案都給我感受,思路太中國式了,像中國的考試同樣,追求難題,追求窮盡真理。好比
裏面提到的那個面試,好比 提升的app 的main在哪兒。我不是說這些沒用,或者不重要,可是我想這些知識點可能對於一個初學者進階的人來講,就算查到了答案,也理解不了。因此說一下我對這個問題的見解,只求拋磚引玉。第一個建議,對於一個junior developer,若是想往上走,在強化知識體系的以前,我每每建議先完善本身在debug tools上的經驗。
好比:
網絡debug tools: Charles, mitmproxy, Stetho
內存泄露:Memory Analyser, Leak Canary
Overdraw: 手機上的Drawing Settings, AVD Manager/Layout, Stetho
數據庫和cache: Stetho,SqliteManager
還有最原始的,利用logcat打log,分析log而且知道各類參數,好比-v time顯示時間,-s作filter等等
中國有句古話,工欲善其事,必先利其器。將各類debug工具掌握好,有利於更快地從Junior level提升上來。
第二個建議,提升自我表達能力。我在面試facebook的時候(別問細節了,沒過),有一個題目頗有意思,來講一個你比較瞭解的工具或者api,whatever什麼玩意均可以,看你可否有邏輯地、準確地將某lib的整個框架描述清楚,好比優缺點,好比運行流程和坑。在這裏面,ABCD的某個環節中,你能夠說你在B上內部邏輯不清楚,可是input 和output必定要說出來,若是能說出limitaion就更好了。
這項能力的好處是,「準確而有邏輯地表達」每每須要清晰的頭腦、豐富的知識儲備,這項訓練在programming中是很是有好處的,我發現凡是口頭表達邏輯很清晰的人,編程coding邏輯感也很是強。有好的邏輯思惟的人,成長是極快的。
第三個建議,若是追求精通,不要一上來就追求對整個Android的精通,要先追求模塊的精通。有些人強於寫googlemap,有些人對Volley庫極爲熟悉甚至被merge過不少pr,有些人可能對動畫很是瞭解,甚至有些人專門研究android相機保存圖片等。其實等你很熟悉一兩個模塊後,你會發現其餘的東西很容易舉一反三,就算不看代碼,猜也猜獲得。
第四,提升英語能力。之前在國內只用baidu,後來出國了以後用英語才發現,簡直是多長了一個腦子的感受,高質量的文章比比皆是。因此若是英語好,在IT skill上的進步可能會快好幾倍,真的不誇張。
最後,不要被面試官嚇到,他的問題確定是通過準備的,沒準他比你早知道不了幾天這個問題的答案而且歷來沒在真正項目上apply過。不知道就說不知道,不過我通常會建議在不知道的問題上猜一下,並不是瞎猜,只是告訴他「這個問題我確實沒研究過,不過以我對android的瞭解看,應該是哪兒哪兒的問題或者應該是因爲某種機制產生的」,目的就是顯示我對android很瞭解,頗有信心。由於誰都不可能在工做中不查看新的東西,只用舊知識的公司應該是不存在的。
最後再次感謝 和 ,二位說的不少問題我也不懂,趕忙去查一查,多謝!咱們先來對問題分解一下:
Android 開發 :
分紅成
1. "開發" 通常的開發技能
2. "移動應用開發" 移動應用開發相關概念思想
3. "Android 開發" 特指與 Android 開發直接相關知識技能
正如你可能所想的那樣,這樣的問題不像1 + 1等於2那樣,有一個簡單確切的答案.
真正答案因人而異. 下面我以本身幾年的Android 開發經驗,與你分享一二.
就按我上面所分解的幾個方面來講一說:
一: 開發技能
你能夠當作是通常的編程技能
這方面你能夠從
編程語言的熟練掌握
面向過程編程思想
面向對象的思想
函數式編程思想
設計模式
算法與數據結構
網絡編程,TCP/IP 協議
重構
版本管理(Git 等)
等方面的檢查和提升本身
更詳細的技能樹,請本身搜索
二: 移動應用開發
你能夠當作是 App 開發
估計這多是你更感興趣的
這方面你能夠從: MVC 這成三個方面來對照檢查下
M: 數據層
移動應用數據結構特色
數據存儲 :SQLite數據庫,文件存儲
數據格式: XML 格式,JSON格式 序列化與反序列化
數據查詢: 移動應用通常數據庫主要是 用SQLite
(說回來,單是 SQLite 數據庫,就能夠花很多時間來深刻學習下,
由於對一個應用來講,數據基本是核心)
V: 視圖層
移動應用界面特色
移動應用構建界面經常使用方法
移動應用交互特色
移動應用動畫
系統 UI 系統特色,優勢,缺點及侷限
C: 控制層
移動應用控制層特色
控制層的生命週期
多線程,UI 線程,後臺線程
再加一層:
E: 事件層
事件處理,觸控事件,手勢,事件響應鏈
三: Android 開發
工具篇 - 工欲善其事,必先利其器
Android Studio 掌握用得怎麼樣了?
Adb 及相關工具會用嗎?
Gradle 構建系統呢?
文檔篇 - 看 Android 官方是怎麼定義開發各類技能的.
相信常看 Android 開發者官方網站,你會收益良多,我下面寫的也沒必要看了.
系統篇
Android 多線程編程,異步編程特色 - Loop,Handler,IntentService,Broadcast
,MessageQueue
Android UI 框架特色,優點和不足
而後你再按 MVC 將 Android 各部分再分析分析,總結總結.
從操做系統層面去學習,不要僅限於應用層開發,開放的系統源代碼方便學習。
從框架設計逐步走到代碼實現,應用層事後,能夠學習內核,驅動,虛擬機,開源庫,框架層再回到應用層,每一個階段回味一下,就會體會到進階的感受—酸爽。這兩天面試也一直在跟來面試的兩個有三年工做經驗的程序員聊這個問題。
你的程序要實現某個要求的功能並非太難,尤爲是通常生活中用的App,遊戲另說。
可是要把你的App作的別人一看就以爲好看好用,那是很是很是困難的。
這兩我的一個iOS一個安卓,給我看的是同一個應用(是的,來自同一家公司),在把手機遞給個人時候兩我的都說了一樣一句話:界面有點醜。
界面醜固然是產品經理和UI、UE的問題,可是,程序員的問題也是顯而易見的,你爲何要作一個本身都以爲很醜的應用?還把這個當成面試的敲門磚?並且我跟他們強調,當時UI作出來的設計稿必定比你這個成品要漂亮,否則不可能經過老闆的審覈,並且水平再差的UI隨便畫個界面出來也不至於難當作這樣。確定是大家在作的時候丟失了細節,然後產品經理和老闆都迫不得已,由於大家說作不到他們就沒辦法。好的應用的第一個必要條件,就是要讓用戶第一眼可以接受它,大家手機裏那些本身以爲很好用,每天用的應用,有哪一個徹底是由於功能不可替代而忍受它難看難用的界面的?(網銀App除外)
而要作到一個能作出漂亮的界面,細緻的動畫,流暢的交互的應用,對程序員的考驗是很是很是大的,對安卓開發人員更甚。之前我花了兩個星期的時間想模仿出Cal這個應用頂部那個日曆的各類滑動效果,最終只能模仿出7成,還差的那3成在功能上是如出一轍的,但在細膩和流暢上就始終差那麼一大截。題主提出了三個問題:
1. Android開發初期以後怎麼提高?我看了下
的回答,他說的那些東西,Google Samples 全都提供了。好比說新出的 Toolbar 繼承於 ViewGroup,若是屢次閱讀過 ViewGroup 的源碼。對於新出的 Toolbar 只需看一遍源碼便知如何使用。若是熟悉了 ViewGroup,而後閱讀 Toolbar 的源碼(源碼兩千多行,基於前面的基礎,大部分代碼都無需仔細閱讀了),2 個小時不到就能徹底掌握 Toolbar。
還有
所說的 CollapsingToolbarLayout、NestedScrollView 繼承於 FrameLayout。若是你對 FrameLayout 熟悉了,這些新出的 View 掌握速度將快的沒法想象。再次建議,跑 Samples,多閱讀源碼,背下繼承關係。
2. 怎麼才能叫精通?
私認爲,你要是能回答小白提的任何 Android 問題,你都能對答如流就是精通。
:)
不要小瞧小白提問方式以及問題。
我組織了一個 『技術學習小組』,裏面不少人問我 Android 問題,我有一大半沒辦法直接答出來。
然而我作了六年 Android 開發了。
3. 方向在哪?
題主問得什麼方向?着實沒看懂題主的問意。
======= 補充點我解決 Android 難題的思路
關於解決 Android 難題的思路,我很同意
的答案。能力還不夠答這個題目,仍是嘗試答一下,我用我本身得例子來講明下。兩個例子。
1,數據庫索引優化
之前作一個項目數據量很大,而後想作優化,一頓加索引而後發現反而更慢了,因而乎去研究下發現聯合索引更快索引超過5個後明顯變慢,也更適合層級遞進查詢,可是原理不知,因而乎去了解索引的原理設計,從而讓本身有能力下次去避免這個問題或者作的更好。
2,一次面試
記得handler和looper得模式經典面試題,人人都能淺談下。那麼你知道sendmessagedelay如何實現的,handler得生命週期如何,跨線程是如何通訊的等等。當詳細問下去的時候不少人是不知道得。不少人會知道handler生命週期長作靜態內部類加索引用,可是你知道爲何嗎?我當時就是一問三不知,回去趕忙查看源碼瞭解管道,epoll模型等。
我自己對安卓開發只知其一;不知其二,可是也算親眼見證了幾個大牛(不只限於安卓)的成長,因此給一點我所知道的辦法。
1。面臨一個解決不了的問題的時候,最初階段放棄百度,放棄google搜索。儘可能作到只依靠安卓官方文檔。
搜索引擎是一個黑匣子,問他「xx問題應該怎麼解決」,它會忽略掉一切中間的思考,分析,解決流程,給出最後的答案。
其結果就是,使用答案的人基本上不可能理解「爲何這麼去作」,只知道「能夠這麼作」。 就像一個沒學過加減法,只會用計算器的收銀員,有計算器能工做,可是恐怕沒有心算的快。複雜的問題若是計算器不會算,他也不會。
等到經過基本的文檔本身找到了思路和方案,再去看看有沒有別人寫好的第三方的東西,或者成熟的方案,再和本身的東西印證。
這要花不少的時間,會比別人慢,會把別人休息的時間用來加班。 可是大牛若是是睡覺打遊戲就能養成的,這個問題也不會出現了對不。
2。安卓系統源代碼要常備。跟蹤代碼時候,儘量跟到系統的層面,越深越好。至少sdk要進去。
不瞭解sdk的代碼,本身就很難寫出同級的代碼。好代碼看的多了,天然本身的水準也會提升。熟讀唐詩三百首嘛。
3。若是代碼沒有按預期的去動做,不要第一時間想着去解決這個現象,而是要追究爲何會發生這個現象。
好比程序崩潰了,加個try catch天然解決了這個問題。可是這麼作就太糟了。
天然要問問,爲何會出現這個exception?底層的返回null了,上層沒處理。哦,加個判斷就行了。這樣好一點,可是仍然很糟。 底層爲何會返回null?若是null是合法的返回,文檔裏有沒有約定?若是沒有約定,文檔有問題,若是約定了,代碼有問題。更主要的是,其餘地方是否是犯了一樣的錯誤?我是否是存在「不注意文檔約定」或者「寫文檔時候忘記約定」這樣的問題?
到這個地方,才真的對本身的成長有所幫助。大牛也是一步一步走上來的。
4。多把本身知道的東西教給別人。 好比寫一些知識和技巧跟你們分享,或者召集一個公司內的小培訓。
這樣作的好處有兩個。
第一本身獲得了鍛鍊。把知識系統化總結,對本身是一個回顧,整理,沉澱的過程。這個過程當中可能會找到本身尚欠缺的地方,也可能會被別人的提問啓發。
第二是能逐步樹立本身的地位感,成爲大牛也是一個正向激勵的過程,每每是牛人愈來愈牛,普通人愈來愈普通……