做android移動開發的一點體會

標籤：shel   協助   gerrit   歐洲   結果   國家   frame   ubuntu   不用   

做手機的一點體會

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

然後是高通這樣的公司提供手機的核心晶片和自己的解決方案，然後網上做手機的公司，相當於是做一個大的"整合"，做手機的公司需要從各種電訊廠商那裡拿到訂單，然後根據

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

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

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

還有一個原因就是：Google對於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開發是一個多人協作開發的項目。就我現在知道的  就 二三十人開發，遇到編譯不過的問題，稍微分析一下就知道是誰的問題了，可以給他提醒，讓他馬上更改，讓編譯通過。  但是筆者之前接的活是大牌公司，核心Team Dev在日本東京，測試團隊在東京和大陸，BUG解決團隊在大陸北京（包括衍生的其他大陸城市），部分Team Dev在 倫敦，   整個完整的開發與測試在不同的國家和不同的城市，其中時差相隔，用的是同一套系統，發布版本都是自動化編譯，並且有不同的分支。 舉個例子：我作為其中一個普通的開發人員，如果我提了一個編譯不能通過的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移動開發的一點體會