有必要研究安卓源碼嗎？

01-08

看了幾篇view 源碼剖析，感覺能能看懂點源碼了，想用view入手，把1.4萬view 源碼自己研究下。
想問問大神在Androidnative開發日薄西山的情況下還有必要研究這些東西嗎？

不要提前儲備性價比低的知識。你看1.4w行view源碼遠不如直接看別人的源碼分析，比如任玉剛老師的《android開發藝術探索》，上面已經解釋的很透徹了，你如果說是要深入framework或者HAL層的源碼，我感覺，更沒必要，這些東西太巨細，研究的話很容易半途而廢，浪費了大量時間，再說，君不見，對於專業的android系統工程師，在開發驅動的時候也是sourceinsight跳來跳去，比著系統的其他代碼照貓畫虎。

最後，如果想提升自己，一方面，自頂向下，看《源代碼情景分析》《藝術探索》這一類的源碼剖析書。另一方面，從基礎進發，補補計算機網路，演算法什麼的，況且這些東西還和面試息息相關呢，不是嗎?

手機碼字，害我錯過地鐵站 _(:з」∠)_

花了點時間重新編輯下，隨便加上閱讀源碼的一些建議

有沒有必要閱讀Android源碼

http://zhuanlan.zhihu.com/kaede/20563936

閱讀Android源碼的一些姿勢

http://zhuanlan.zhihu.com/kaede/20564614

為什麼要閱讀源碼

說了這麼多，到底有沒有必要閱讀源碼？有必要，而且非常有必要！原因有三。

其一，了解基層，高層才能更好地工作。

比如，了解View的繪製過程，了解TouchEvent的分發和攔截過程的細節，才能寫出酷炫的UI，要不然，只知道大概的原理的話，你可能要在「無法接收到觸摸事件」或者「滑動事件和點擊事件衝突」的這些問題上折騰半天。

又比如，如果哪裡出現異常，你能快速定位到源碼拋異常類的地方，就能快速解決BUG，對症下藥，一招撂倒，有些時候，修復BUG的時間不是用在解決問題上，而是用在定位問題上。

這裡有必要提一下，當Logcat把異常的棧信息列印出來的時候，有些異常出現的原因並不真的是Logcat的信息里描述的原因，因為Logcat里的異常的信息也只是由系統源碼列印出來的，而這些源碼大多時候只是普通的Java代碼，和你自己寫的沒什麼區別，如果源碼拋出異常的代碼的邏輯不夠嚴謹的話，那實際的異常和Logcat里描述的異常可能對不上。比如之前搞動態載入的時候，在使用LayoutInflator渲染一個外部的XML布局時，拋了一個「Class not found」的異常，我要渲染的類可是LinearLayout啊，怎麼可能沒有！定位到源碼里才發現，這裡只要是類渲染失敗就會拋這個異常，再定位到具體拋異常的地方，發現實際是Dimens資源找不到，困擾半年的問題立刻解決。

其二，能夠理解Android設計者的意圖。

這個描述可能不好，比如說，許多人都覺得Android開發其實就是Java開發，通過閱讀Context類的設計，你能夠理解Google是如何在Java的基礎上加上Android的特性的，你能夠理解Context被叫做「環境」的原因。此外，閱讀Activity/Service的源碼，你能理解到四大組件類明明就是普通的JAVA類，為什麼他們就是組件而別的類就不是組件。閱讀Handler/Message/Looper的源碼，你還能理解到Handler的精髓，數據驅動比事件驅動更適合用於設計需要經常改動的框架。閱讀源碼，你能知道Android是怎麼管理Window以及向控制View的觸摸事件的，你能知道基本上所有的res資源都有等價的Java代碼的實現方式，你還能知道Dalvik是怎麼無縫向ART過度的，在看通的那一瞬間，保證你覺得「水可載舟，亦可賽艇」！

其三，能夠學習優秀開源項目的代碼風格和設計理念

這也是最重要的，看多了源碼之後，你會發現所謂的源碼也不過是普通的的Java代碼，在不知不覺中受到這些優秀設計思想的影響。相信許多人在看 Volley 源碼此前，對非同步任務控制的想法基本就是毫無想法，看完之後簡直是醍醐灌頂，原來代碼也能寫得這麼有魅力，再看看自己之前寫的非同步任務，「new Thread().start」…，簡直是「too young, sometime naive」有沒有。

看了越來越多Android的源碼，自己的寫應用的時候，也就能寫出更加「Best Performance」的代碼，見識了越來越多的開源項目，自己也能夠更容易找到最符合自己應用的框架和技術方案，學習了越來越多的優秀的代碼風格，自己也就更能寫出漂亮以及容易擴展的代碼。

或許對許多做Android開發來說，平時的工作就是按照設計的圖寫個布局，再解析後台的數據，下班了把測試用的安卓機扔進抽屜拿出自己的蘋果手機…… 但有時候花點時間看看源碼，或許會覺得設計代碼還是挺有意思的，特別是，當你花了兩天的時間構思代碼，再花兩天的時間寫代碼，這時你可能覺得你還有許多代碼要寫，但是突然發現只要把你寫好的介面銜接一下就都完成了，而且寫了兩天的代碼居然一次編譯通過！更甚，產品突然改了個需求，你在抱怨了一頓後發現只要花10分鐘把原來的介面換個實現就搞定了，這或許是程序員工作中為數不多的樂趣吧。

源碼才是最好的老師，當你工作了之後沒有誰會去教你知識，當我們對某個新技術不懂的時候，看看源碼就能明白了。還有就是源碼都是大神寫的，可以借鑒。參考。學習。。。。好處太多吧。。

我是很贊同看Android源碼的，至於原因上面的各位都已經分析的很清楚了。另外，Android native現在還沒有日薄西山。

一個對技術有好奇心，有技術熱情的人，都不會僅僅停留在這個東西挺好用，而是會忍不住去探究它背後的技術原理，即便不是親自去看源碼，也會花點時間了解別人整理過的經驗。

我忘了這句是從哪看到的，很久以前收藏的。

大部分人不需要，因為用不著。

目前我知道的，有兩類人是肯定需要的：

1. 做解決方案的人

這些人集中在手機廠商（小米、中華酷聯等）、手機解決方案提供商（高通、聯發科等）

他們需要知道，一般應用開發不需要知道的這些問題：

按了撥號鍵是如何打通電話的？
相機切前置攝像頭重啟了要怎麼定位？
為什麼視頻能播放？
為什麼音頻能有聲音？

2. 日活過千萬，崩潰率需要做到萬分之一，的應用開發

日活過千萬，你的代碼，會跑在形形色色的手機上，會出現各種奇葩問題。這些問題大多很難復現，甚至，你在網上搜不到資料。

國外沒有這個手機，你用google搜也沒用
一般的開發遇不到這種問題，應用體量太小，連65536都遇不到
崩潰率沒有到千分之一以下，是不會關注到類似問題的
大多沒法復現
沒有崩潰現場

比如下面這個問題（跟dialog沒有關係哦，出問題的地方就沒有dialog，我知道你一搜都是dialog相關的。也不是token為null哦）：

activity出現BadTokenException: Unable to add window

我剛試了一下，至今google搜索不到什麼有用的資料。

當年解決了這個問題之後，我們的崩潰率，在友盟是十萬分之5

============2016.2.18更新===============

我們當時是初始化，到閃屏之間出問題的，是應用初始化耗時太長，接近於anr了。

後來大致定位到原因，是有些手機，可以插sd卡，有的卡質量很差，io非常慢。一些很普通的io操作，比如創建文件，都有概率引起的長時間主線程阻塞。多進程應用特別容易出現這種問題，某些io操作，在每個進程初始化，都會跑一次，在垃圾sd卡上面，主線程很容易阻塞很長時間。

抓到的log中，發現一次讀取preference耗時達20s，簡直不敢相信。

這類問題，一定要自己打log到自有伺服器。定位到是哪個activity出問題了，還原現場。每家應用不一樣。

我認為，解哪方面的bug 再看哪方面的源碼。先了解源碼實現的功能，再針對性的去看。

1.native日薄西山這個想法有點naive

最近h5,react勢頭很猛，但native日薄西山也絕不至於。

h5的性能大家有目共睹，對於核心業務切換到h5肯定不實際。對於react不了解的同學可以看看QQ空間團隊對react的實踐報告。http://mp.weixin.qq.com/s?__biz=MzI1MTA1MzM2Nw==mid=401483604idx=1sn=399cdf7e13fe6125108de1bfd045f2cfscene=0#wechat_redirect

文中有h5和react的性能測試對比表。可見，react目前階段性能還不足以替換原生。

2.view源碼

我做了三年的安卓開發，目前兩萬多行的View代碼還沒有通讀。不是不想通讀而是還是有閱讀障礙。view中的代碼不僅僅閱讀View才能了解，而是要和其他類結合閱讀。目前讀過的部分有

1.事件分發部分。 2.view繪製部分。 3.view measure和layout部分。 4.layout xml解析部分。 5.view滑動部分 6.動畫

即使閱讀完某些核心代碼，要能應用也不容易。Dev Submit 2015中Chris Banes說自己實現FloatingActionButton用了一周時間，台下的很多人都在笑。大家覺得不就是一個圓形的ImageButton么。Nested scroll目前在RecyclerView上還有一些小bug。說實話，當時小市民心理的我心理也小小平衡了一下，原來Google的大神們也沒想像中那麼666.

Google Android團隊的人對源碼這麼熟悉的情況下還是不能做到高效完美。如果我們還不閱讀源碼，寫的app能拿的出手？

當然，每個人對自己要求和期許都不一樣。寫一個簡單的app很容易，不就是畫界面，處理點擊事件，調介面，緩存數據，展示數據么。培訓班三個月輸出一批，北上廣10K+

一句話回答：哇操！Android代碼都編過了，還有什麼難的？

我的回答比較唯心，拋開了具體的技術細節。在我看來，能編譯一次Android代碼最大的收穫是自信心，再是技術邊界的擴張，最後是心態的轉變。

1. 自信心:Android最大的好就是開源，說什麼也要編一次系統的代碼向旁邊ios的小夥伴嘚瑟一下。最後，你身為一個Android工程師，不編一次系統源碼對得起自己嗎？

2.技術邊界的擴張:從此你對編譯開源軟體在沒有恐懼感，畢竟這麼大一個系統的編譯都搞定了。

3.心態轉變：這是只有牛逼的人才能幹的事情，看著旁邊的小夥伴，心態也可以飄飄然。不說自己馬上牛了多少，至少手握源碼，感覺原理什麼都不是問題了，有耐心地扒扒代碼，debug下，總能搞懂。

不知道日薄西山聽誰說的。

-----------------------------------------------------------

紙上得來終覺淺，絕知此事要躬行。

古人都明白這個道理了。所以源碼有必要看，但是沒必要一行行地看；或許你一開始不知道哪裡該看哪裡該跳，當你看多了就有那種直覺了。

閱讀源碼是一項非常重要的能力，不論你以後用什麼語言選擇什麼框架。另外，就算哪一天真的日薄西山了，你怎麼能保證Android的這種設計思路不會改頭換面在別的所謂的潮流里用上呢？

和自己App功能密切相關的肯定是要研究下實現原理比較好，另外緩存原理，GC回收機制還是都了解研究下好

沒必要。

我說的沒必要不是指看源碼沒必要，而是現在網上資料很多，往往一些好的資料就已經能達到你的目的了。

兩種情況需要看源碼，

一，資料不全。

二，網上有資料但說的不夠細(即看源碼一定要有非常清晰的目的，你知道自己要找什麼內容。

首先源碼是肯定要看的，但是我不建議這樣看。先不說1.4萬行，對你毅力的挑戰。再者說源碼之間相互是聯繫的，是一個網狀結構，更別說一些實現跟本不在view中，而是位於其子類中。所以你要了解其源碼，所要看的代碼是遠超1.4萬行的。綜上所述，這樣看源碼是不現實的。

我的意見是，以功能為單位來學習源碼。比如說事件分發機制，view的繪製機制等。按照機制的流程來看源碼，沿著各種主幹功能來看。不僅能增加動力，對各種功能的了解也可以直接促進對頂層的實現。

總而言之，戰線不能拉太長，除非你有驚天地泣鬼神之毅力。君不見多少決心看源碼的人，都死在了字母的海洋中。

以上，各人理解，不喜勿噴。

樓主想的太多了，真能把view的源碼分析完了，你可能收穫的不只是對Android的深入理解

能力到了某種級別，學習別的東西也是秒懂，不限於Android

日薄西山是什麼鬼，平時開發的話某些控制項達不到要求，往往重寫裡面的部分方法即可，這時候點進源碼看看還是需要的嗎？也做過系統開發，平時就是讀源碼解決源碼里的bug。

我是iOS開發人員，也會一點安卓。

我個人偶爾也會看安卓的源碼，因為有許多可以借鑒的地方，像設計模式、介面設計等等都是值得學習借鑒的。

有興趣又有時間可以往底層走走，好處還是有很多的

至於源生和輕應用誰將成為主流的問題，我覺得大家可以把PM挖出來和他們聊聊

矛盾點在什麼地方？

在我看來源生追求的純粹是用戶體驗，而當某一天H5的渲染速度和網路載入的速度達到一定境界後，在這一刻，H5完全可以取代源生。

但是，問題來了。有興趣的可以去學下H5，你會發現，Web的響應速度本質上就慢。就算Android本地運行H5也依然是跟源生沒法比的。

當然H5的益處也是有目共睹的，純粹的輕應用只需要發布一次就可以免審核（請自行腦補），敏捷性絕對是杠杠的。

所以現在很流行Web + Native，這樣做，考驗的是PM對產品需求的理解，對於開發絕對是一件好事情。

就結果而論，Web + Native的這種模式還是會持續比較長的一段時間。

然而嵌入式開發者需要做些什麼準備呢？當然不僅僅是知道怎麼用webview這麼膚淺。

有條件的，我還是建議把H5也學了，至少真到了那天不至於失業，哈哈。當然，最起碼的一點，作為一個開發者而言，技術是無止境的，在有限的時間裡獲取自己想要的東西才最重要。

日薄西山？Sometimes Naive！

Android開發者就一定要看源碼嗎？不一定吧，有時候開發遇到問題了，再去實時查閱更好。當然各種結構（比如view的結構）、原理還是要學好的。

當然，你問我滋不滋瓷靠看源碼來深入理解Android呢？我說滋瓷。然而你如果把這當做學習結構的方法，那就圖樣圖……幹什麼別拉我走jdjbdjfbdiwkzaqloqiehdj

源碼就是一個寶庫但是很難看能堅持看下去肯定有收穫。不過題主擔憂的是native開發日薄西山所以如果真有這個擔憂可以學習JavaScript。至於是不是日薄西山可以看看代表行業風向的大廠的app是原生還是用的web，至於怎麼看是否是原生還是web題主應該知道吧

一般遇到自己不懂得，搜到了解決方法還是沒明白為什麼就可以這樣用的，我會去看源碼。

最簡單的比如說觸摸的事件傳遞，不看源碼很難徹底弄明白。