安卓項目源碼及其文檔

㈠ 軟體項目一般需要在哪些文檔的哪些地方需要添加源代碼

軟體項目肯定離不了文檔和管理工具，如果您的項目還沒有它們，那麼請從現在開始。我們需要哪些文檔，工具和努力
軟體項目肯定離不了文檔和管理工具，如果您的項目還沒有它們，那麼請從現在開始。那麼文檔是不是越多越好呢？老話說的好，合適的才是最好的。小而精的文檔和工具會讓我們事半功倍，大而全的文檔會讓我們疲於奔命，最後迷失在文檔的海洋中。
51CTO向您推薦上一篇系列文章：《我們如何開始對項目進行管理：需要什麼樣的人》
我們寫代碼的都知道，錯誤的注釋比沒有注釋更可怕；同樣的，沒有及時得到更新的文檔比沒有文檔更可怕，因為文檔就是項目的注釋。那麼我們是否有必要去更新那些我們根本沒有用到的文檔呢？很顯然，那是非常沒有必要的，是對資源的浪費。文檔說起來其實就是一個工具，是一個讓我們開發時有依據，可以追溯開發過程以及記錄開發結果的工具。我們只有用到它，它才有存在的必要。
那麼文檔過於少或者乾脆沒有文檔，不是更簡潔？我想說：不寫代碼不是更簡潔？玩笑歸玩笑，沒有文檔或者文檔太少會導致的問題大家可能也都遇到過：那就是過程不可追溯，有些非常重要的邏輯沒有記錄，需要用到時團隊成員各執一詞，甚至需要重新找客戶確認而是客戶認為我們不夠專業；有些非常重要的設計沒有記錄，導致代碼維護困難，以至於維護人員破口大罵開發人員寫的什麼垃圾代碼做的什麼垃圾設計。有些設計非常的巧妙，非常的值得學習，然而就是因為沒有留下記錄而被初學者如我一樣的人罵了N次。在反省自己不夠聰明時，是否也該讓寫代碼的人反省一下為什麼沒能留下點兒記錄？
有一種觀點是最好的設計就是代碼，意思是代碼就是設計，代碼應該非常的優秀，可讀性特別好，讓人一看就明白，我完全同意。如果代碼寫到這種程度，那文檔就真的沒用了。那麼請自問，您是這樣嗎？如果是，沒文檔，沒問題；如果不是，請把重要的東西寫下來。那麼，哪些是重要的呢？
哪些是必須的， 哪些是Optional的。對於哪些文檔更重要些，應該由項目的具體情況而定，特別是項目的大小，邏輯的復雜程度，人員的情況等等很多因素。在我做過的項目中，我個人認為最重要的一些文檔和工具如下所述：
1， 功能說明書（Functional Specification）------按獨立功能劃分優先順序，每一條記錄都是一個可交付物，都是一個功能。整個文檔就描述了整個項目的交付功能和優先順序。項目中的所有人，都應該關注這個文檔：測試用它來寫測試用例；開發人員用它來決定先開發哪個功能；PM用它來查看功能的完成和驗證狀態。它通常不應該內容過多（由項目規模決定），我覺得最多兩行字就可以描述一個獨立工作的功能，至於對這個功能的理解，應該由負責它的程序員來完成。
2， 核心流程圖。這個流程圖可能描述了用戶使用該系統的過程；也可能描述系統中數據的流轉；也可能描述表單的流轉。總之，它描述一個過程，這個過程對用戶來說非常重要。這個圖有時候也會被其它的圖，如順序圖代替。
3， 部署文檔。該文檔描述了該系統應該如何部署，它不一定非要是一個word文檔，也可能僅是一個bat文件而已。這個文檔應該描述該項目如何部署，步驟是怎麼樣的，需要哪些文件，需要哪些硬體支持，以及需要注意什麼。部署歷來都不太被重視，大家覺得只要東西做出來了，部署不就是放上去嗎？其實不然。在經歷了一定周期的開發後，開發過程中積累的配置，對環境的要求，在真正部署的時候很多就忘了，所以部署可能會花費很多沒必要的時間，我覺得這也是微軟要做daily build的原因之一，每天都build一個可用的版本，當然部署就沒有問題了。我們剛開始可能不需要每天都build一個版本，但最少要一周或者兩周部署一個版本吧。每次部署都整理一個自動化的腳本或者文檔，會讓你最後上線的時候非常的從容。
4， 測試用例。我不是一個測試人員，測試也是我覺得一直沒有做到位的地方。客觀的說，我覺得用例應該花很大心思去編寫，就像用戶真正的在使用軟體一樣。項目應該在設計和開發的時候就以滿足用例為目標，而不是開發完了才想起來用例，去測試，發現問題再修改，回頭想想，這可能就是測試驅動開發產生的原因吧。我們知道用戶發現錯誤修改的成本高於我們自己發現的錯誤；同樣的，設計和開發階段就解決的問題成本也遠遠小於測試階段發現的。正是，問題發現的越早，解決起來就越容易，成本就越低。
5， Bug管理工具。這個管理工具可以是一個excel，當然，我並不推薦這么做，畢竟excel卻是不那麼自動化。但是，只要比excel自動化一點點兒的信息系統就可以了，它需要可以記錄問題，可以傳截圖，這就夠了。我推薦使用bug tracker，這是個dotnet開發的開源的bug管理工具，其實也可以管理需求，是非常實用的。
以上五個是我認為最重要的，我覺得是項目開始進行管理的階段必不可少的；而下面幾個，則是大家視情況可選的。
6， 核心類圖。這個可能是可選的，因為有時候，類的關於沒那麼復雜，也就沒有必要有這個圖；相反，則需要進行記錄。
7， 資料庫設計。資料庫設計文檔可能在review的時候用到。
8， 系統間介面圖。如果產品有若干個子系統，如web service等等，那麼我認為需要一個描述系統間介面和交互關系的圖，這個圖應該在設計的早期就開發出來供大家使用並且隨時保持更新和關注。
有了文檔和工具，是不是就一切OK了呢？不對，就像大而全的文檔並不能幫助我們成功一樣，有了文檔並不代表項目就能成功，如何維護和使用這些文檔和工具是相當重要的。每個文檔都應該有人去維護，那麼誰去做這個事呢？我認為項目經理應該經常拿著功能說明書開會，它也可以被看做是WBS的初級版本，可以被標注狀態和優先順序；所有人都應該熟悉流程圖，並隨時提出對流程圖進行檢驗和review；應該指定一個人負責構建，這並不需要花費很多時間，但是需要細心和一些完美主義精神；測試人員自然要維護好測試用例；每個人特別是開發人員，都應該有一種覺悟，那就是一旦想起了哪些重要的邏輯，不管是業務的邏輯還是系統的演算法，都應該記錄到bug管理工具上。Bug管理工具完全可以記錄這些零散但卻重要的東西，以便將來方便查詢。
在這里我也是根據自己的經歷簡單的談了一些我的看法，這並不是金科玉律，我還得說，合適你的才是最好的。
（四） 代碼規范的選擇
做開發不可避免的遇到代碼規范，從上學時就會學習到一些規范，但是每個公司都不同，那麼我們到底要遵守哪些規范呢？我個人認為，一個合格的程序員應該可以隨時調整自己適應任何一種規范，這是一種職業素養和能力。而何時該遵循何種規范，這也有一定的原則。
1， 在現有系統（代碼）基礎上進行開發。這種情況下，我們應該盡量的去遵循原有系統的規范，不論是命名還是注釋。因為如果這時你非要按照自己的習慣寫，那麼系統就會出現兩種完全不同風格的代碼，這對將來的維護是一種噩夢。但是，遵循原有規范不是遷就原有錯誤。如果發現原有的規范會造成一定的問題，就要立刻改正，不能裝傻充愣假裝看不見。
2， 新建團隊開發新的系統。新建的團隊中團隊成員可能來自不同的環境，對規范的選擇傾向一定是不完全一樣的，此時要怎麼做呢？這時，項目的領導者應該組織大家一起做一個決定，討論如何定義變數，如何給控制項取名等等。在出現意見不統一又誰都說服不了誰的情況時，項目經理應該做出明確的決定。此時選擇一種規范遠比同時遷就兩個人要來的好，不然造成新系統中存在兩種規范，同樣是維護的噩夢。
3， 穩定團隊開發新的系統。這種情況就容易得多，團隊穩定後團隊成員漸漸的了解了互相的習慣，互相學習後就更容易達成妥協。只要注意讓新加入的成員適應就可以了。
有人可能覺得代碼規范沒什麼大不了，功能正確沒有bug不就行了？當然，如果沒有bug那肯定沒問題，然而一個系統運行到退休還沒有bug，哪位見過呢？我做了一些運維工作之後才漸漸了解到，不同風格的代碼讀起來就像是一會兒在赤道，一會兒在南極，非常的痛苦，有時甚至會造成系統很多的不一致，大大增加了維護的工作量。我們的目標之一不就是增加系統的可維護性嗎？

㈡ 如何生成安卓源碼的compile_command.json

1、cmake工程生成compile_commands.json文件比較簡單，定義CMAKE_EXPORT_COMPILE_COMMANDS即可。
2、用makefile來編，沒有現成的選項生成compile_commands.json文件。可以使用ctags，gtags等，但跳轉不是很准確。可以通過Bear來生成，而且不需要改動代碼。具體Bear的安裝按照官方文檔來。安裝之後，執行以下命令即可生成：compile_commands.json文件能夠有效提高一些工具(比如說ccls1，vscode2)的代碼跳轉、補全等功能。

㈢ 如何查看安卓apk程序的源代碼

將apk文件拷貝至sdcard上。
命令順序如下：

進入android sdk文件夾/tools目錄下
輸入adb shell
輸入su
輸入cd data
輸入cd app
這時就可以看到你安裝的所有的apk文件。輸入cp 空格 對應的apk 空格 /sdcard/
這樣就將apk文件拷貝出來了。
將apk文件後綴直接變成rar格式，可以看到熟悉的目錄結構了，

其中xml文件打開後都是二進制的，無法查看。
這時就用到了一個android4me的AXMLPrinter2工具。(請自行網路搜索)
輸入以下命令，將xml文件解析出來
java -jar AXMLPrinter2.jar showtimes_list.xml
此命令是在命令行中查看此showtimes_list.xml
將showtimes_list.xml生成xml文件，則輸入以下命令：
java -jar AXMLPrinter2.jar showtimes_list.xml > h.xml
目前進行到這一步，只能看到xml文件的內容，其工程中的java源文件還是看不到，看目錄結構下有一個classes.dex文件，我們需要將dex文件變為jar文件。
這里用到了另一個工具dex2jar。(自行搜索下載)
在Windows下解壓之後的目錄如下圖所示：

在命令行中，進入到此目錄下：
在Windows下，輸入以下命令：
dex2jar.bat c:\classes.dex
運行完之後，在C盤會多一個classes.dex.dex2jar.jar文件，此文件就是我們需要的jar文件。
利用jd-gui，將jar文件反向工程為java代碼。(請自行搜索下載)
它分為Windows、linux、和max三個版本，這里我下載的是Windows版本的。
解壓之後，雙擊運行exe文件，選擇classes.dex.dex2jar.jar文件，相應的jar文件中的Java文件就被反向工程顯示出來了！

㈣ 怎麼在windows下查看android源碼

如何查看Android源碼[以Android2.2為例]

我們知道在Eclipse里按住Ctrl鍵不鬆手在某個類上點擊滑鼠左鍵，可以跳轉到該類的文件。如果沒有源碼就會跳到class文件上。因此我們只需要把源碼拷貝到合適位置，Eclipse就可以找到源碼了。接下來我說一下步驟：

把android-2.2-froyo-src.zip源碼下載下來，[解壓後]放在Android
SDK的指定目錄下，在我機器上的目錄是：C:/AndroidSDK/android-sdk-windows/platforms/android-
8/sources，其中sources目錄是自己建的。解壓後的情況應該是這樣的：

在Javadoc For 'ormlite-android-4.22.jar'屬性框中點擊Browse按鈕來選擇幫助文檔包，然後點擊OK按鈕。

第四：經過以上的操作步驟，就完成了對第三方組件源碼的添加設置以及幫助文檔的添加和設置。這樣就可以和查看Android源碼一樣可以查看第三方組件的源碼了，同時在Eclipse中把游標定位到某個類，按F1鍵就可以查看相應的幫助文檔了。對ormlite-core-4.22.jar的操作也是一樣。

㈤ 自己可以編譯安卓源碼嗎

用最新的Ubuntu 16.04,請首先確保自己已經安裝了Git.沒安裝的同學可以通過以下命令進行安裝:

sudo apt-get install git git config –global user.email 「[email protected]」 git config –global user.name 「test」

其中[email protected]為你自己的郵箱.

簡要說明

android源碼編譯的四個流程:1.源碼下載;2.構建編譯環境;3.編譯源碼;4運行.下文也將按照該流程講述.

源碼下載

由於某牆的原因,這里我們採用國內的鏡像源進行下載.
目前,可用的鏡像源一般是科大和清華的,具體使用差不多,這里我選擇清華大學鏡像進行說明.(參考:科大源,清華源)

repo工具下載及安裝

通過執行以下命令實現repo工具的下載和安裝

mkdir ~/binPATH=~/bin:$PATHcurl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repochmod a+x ~/bin/repo

補充說明
這里,我來簡單的介紹下repo工具,我們知道AOSP項目由不同的子項目組成,為了方便進行管理,Google採用Git對AOSP項目進行多倉庫管理.在聊repo工具之前,我先帶你來聊聊多倉庫項目:

我們有個非常龐大的項目Pre,該項目由很多個子項目R1,R2,...Rn等組成,為了方便管理和協同開發,我們為每個子項目創立自己的倉庫,整個項目的結構如下:

這里寫圖片描述

執行完該命令後,再使用make命令繼續編譯.某些情況下,當你執行jack-admin kill-server時可能提示你命令不存在,此時去你去out/host/linux-x86/bin/目錄下會發現不存在jack-admin文件.如果我是你,我就會重新repo sync下,然後從頭來過.

錯誤三:使用emulator時,虛擬機停在黑屏界面,點擊無任何響應.此時,可能是kerner內核問題,解決方法如下:
執行如下命令:

通過使用kernel-qemu-armv7內核 解決模擬器等待黑屏問題.而-partition-size 1024 則是解決警告: system partion siez adjusted to match image file (163 MB >66 MB)

如果你一開始編譯的版本是aosp_arm-eng,使用上述命令仍然不能解決等待黑屏問題時,不妨編譯aosp_arm64-eng試試.

結束吧

到現在為止,你已經了解了整個android編譯的流程.除此之外,我也簡單的說明android源碼的多倉庫管理機制.下面,不妨自己動手嘗試一下.

㈥ 想看一個開源的Android Studio 項目 ， 新手看不懂 有沒有大神教教我該怎麼看

看開源的項目的，一定要看他的開發文檔，有很多注釋