做手機的一點體會

整個android系統是一個完整的生態系統，谷歌提供開放的android平臺，下遊有各種生產硬件的廠家提供各種手機的硬件，像富士康這樣的工廠提供手機的代加工，

然後是高通這樣的公司提供手機的核心芯片和自己的解決方案，然後網上做手機的公司，相當於是做一個大的"集成"，做手機的公司需要從各種運營商那裏拿到訂單，然後根據

運營商的需求來做手機，運營商賣好了手機，和手機公司之間分成，或者是 手機公司通過其他的渠道售賣自己的手機，功能要麽是全網通，兼容各個運營商，要麽是兼容某一個

運營商。相比之下，運營商賣手機肯定是占了很大的一部分。在運營商的上頭，就是市場需求，即每一個普通的用戶需求，用戶對手機的需求（低端 中端 高端），用戶對於運營商的選擇（聯通， 移動還是電信）等等。 這樣就形成了一個完整的生態圈。 當然這個生態圈，不止有中國市場，更有北美，歐洲，非洲，日本等等市場。 就我知道的， TCL接過的北美T-mobile運營商的業務，諸如此類，其他的就不細說了。

例如 筆者曾經供職的公司就是 做手機的公司，客戶是 大牌手機公司的 第三方公司，例如 是 SOMC TCL 等等品牌公司的第三方公司。為什麽運營商不肯把業務交給他們呢？很顯然，實力不到嘛，運營商哪能放心地把這麽大一塊肥肉給你吃呢，再說了，你也吃不下嘛。於是，這類公司，就是 對上要 和運營商接洽，針對運營商的需求，例如：界面設計，穩定性，新功能開發，雙卡雙待等等新功能，在android源碼的基礎上進行新功能的開發，開發完了之後，再針對運營商的需求，和測試用例，針對不過的測試用例，逐個解BUG，對下要和高通這樣的廠商接洽，在解BUG中遇到的問題，追查到底層，涉及芯片內部的工作等等（因為底層核心代碼，高通肯定是不會對外開放的），需要將問題發生的情況提case給高通，幫助一起解決。這樣的公司起了一個銜接的作用，而且接活也很容易，上下都可以賺，而且各個運營商的需求大同小異，基本上一個項目做完了，你負責的那一塊，例如telephony, bt ,wifi，該改的代碼上一個項目已經改過了，現在重新拿過來復用一下就行了，基本出現的BUG也是類似，上一個項目分析過這個問題，現在同樣的問題再次出現，也是看看就會的。

還有一個原因就是：谷歌對於android系統的不斷升級，筆者剛畢業的時候，android版本最新的還是4.4 現在已經到O了，每一次升級系統，連帶著整個生態圈大地震，可以說android系統的升級是整個生態圈齒輪轉動的原動力。每一次升級，市面上所有的手機都要跟著升級。

或者是 硬件 或者高通這樣的廠商開發了新的平臺，例如：硬件可以做的更省電，攝像頭可以 做的更小，拍照更清晰，新技術的出現導致硬件價格下降， 新的解決方案可以彌補之前存在的問題等等諸如此類。

總之一句話：硬件和軟件的升級 帶動整個生態圈向前發展，並且衍生出除了智能手機以外的其他範疇，例如：可穿戴設備，機器人，自動化，車載等等。

說完了生態圈，筆者再來寫一寫作為一個普通的移動終端開發者的一些體會。

筆者是做android軟件開發，專門負責系統裏的某一個模塊，從最上層的app,到最底層的硬件都有涉及。

平時使用的工具：ubuntu系統，git+repo+gerrit+opengrok+cmweb+bugzilla+jenkins+jira eclipse android studio 使用的語言 java C++ C shell腳本 arm匯編指令 gdb調試等等

簡記為一句話就是 測試給我提BUG 我分析BUG，給出解決方案（1.BUG需要提patch解決 2.BUG本身是work as design,就是這麽設計的 3.BUG是其他模塊導致的，直接踢給別人 4.BUG是由自己之前的改動導致的 5.BUG之前解決了，現在又重新復現了 6.BUG和某一個或幾個其他的BUG是同一個問題，原因相同，可以合並 7.BUG是由於高通等等沒有及時給出反饋，目前等待中的 等等） 然後測試關閉BUG

平時做的最多的就是提patch 去修復問題，一個完整的patch（組）應該是下面這樣

找到問題發生的根本原因，root cause,給出自己的patch,做代碼修改，這個改動首先是保證修復當前的問題，編譯能通過，這個改動進庫後不會引入新的問題，不會破壞其他的模塊，代碼格式遵循android編碼規範，下面逐一說明：

修復當前的問題：這個是最基本的，如果它不能徹底修復當前的問題，或者它進庫後BUG的發生概率明顯降低，或者問題很難解決，僅僅是為了避開這個問題而做的改動，只能算是臨時的workaround, 註意：workaround在平時解決問題也是經常用到的，尤其是 發布前期，或者短時間沒有好的解決方案 或者是其他模塊沒有完成，暫且避開編譯問題等等。

編譯能通過：這個非常重要，因為android開發是一個多人協作開發的項目。就我現在知道的 就 二三十人開發，遇到編譯不過的問題，稍微分析一下就知道是誰的問題了，可以給他提醒，讓他馬上更改，讓編譯通過。 但是筆者之前接的活是大牌公司，核心開發團隊在日本東京，測試團隊在東京和大陸，BUG解決團隊在大陸北京（包括衍生的其他大陸城市），部分開發團隊在 倫敦， 整個完整的開發和測試在不同的國家和不同的城市，其中時差相隔，用的是同一套系統，發布版本都是自動化編譯，並且有不同的分支。 舉個例子：我作為其中一個普通的開發者，如果我提了一個編譯不能通過的patch入庫了，會導致什麽問題。自動發布版本的編譯系統不能編譯出版本，當天所有人在jenkins上想驗證自己的patch是否有問題，所有起的jenkins都編譯失敗而停止了，第二天，所有負責開發的人員來到公司，想驗證自己patch的 在jenkins上無法編譯，所有的測試想在最新的版本上測試自己的case卻因為無新版本發布，他們一整天都無所事事。一個人的失誤導致 不同國家不同城市的人 在接下來的1天或者2天都不能按時完成工作。

關於編譯能通過：我上面用了一個patch(組)， 尤其是patch組，例如你在frameworks層做了改動，在hal層有一個改動和這個是一起的 那麽這兩個改動要同時進庫。或者 為了降低耦合性， 在同一個project下為了修復一個問題，提了多個patch,它們也是要一起進庫。

改動進庫後不會引入新的問題，不會破壞其他的模塊：改動進庫後，不會導致本模塊有新的問題產生，同時與本模塊相連的其他模塊也不會有新的問題發生。筆者曾經遇到過一件事：其他模塊的人為了解決一個問題，在手機進入飛行模式後，徹底禁用了手機SIM卡，結果這個傻帽導致我這邊在飛行模式下想讀取SIM下的信息失敗了。

代碼遵循android編碼規範：這個也很重要，好的格式可以讓人一眼就看出了改動的部分。尤其是在gerrit上查看時。具體如下：commit message寫的盡可能詳細，通常寫法如下：標題簡短的一句話說明修復了什麽問題，可以包含模塊的名字。內容分為三個部分：一、描述問題，問題發生的場景帶來的後果 二、當前這個改動是怎麽解決這個問題的 三、列出這個問題的BUG號及來歷（例如從其他的patch cherry-pick而來的）。內容部分：命名，括號，空格，代碼縮進（一律不用TAB鍵，而用4個空格），空行等等，總之保持同源碼一樣的風格，頭文件 包名按照字母順序從上到下，不該加的空行 空格一行一個都別加。

好記性不如爛筆頭，經常做筆記。

最後一點 解決問題的思路：

1.所有的分析都是基於代碼和log 不要憑空猜測和捏造

2.對於和其他模塊相關的，發現是自己的問題，就不要推給別人，更不要自己做了改動影響別人，推給別人的問題一定要基於log有自己的分析，有理有據

3.在解決某一個問題時，發現除了這個問題，還有異常的log，也要分析異常的log，不要測試沒有報出來，就了事

4.解決BUG的最好方式就是從源頭上根治，就是新添加的代碼不要影響原有的功能

5.實在解決不了的問題，最簡單的辦法就是做回退測試，找到差異的patch, 進而找出原因

6.除了自己負責的部分，與自己相關的部分也要熟悉

7.多與其他人交流，不要自己悶在那裏對著log毫無頭緒

8.按照上述 提一個好的patch(組)，除了自己嚴格要求自己，還要將相關的人加進來review你的代碼和patch

9.很多其他的模塊的patch 自己可以review別人的代碼，來提高自己

10.生活永遠比工作重要，不要為了解BUG而熬到深夜

做android移動開發的一點體會