android代碼規范

1. 針對Android的性能優化集中哪些方面

一、概要：

本文主要以Android的渲染機制、UI優化、多線程的處理、緩存處理、電量優化以及代碼規范等幾方面來簡述Android的性能優化

二、渲染機制的優化：

大多數用戶感知到的卡頓等性能問題的最主要根源都是因為渲染性能。

Android系統每隔16ms發出VSYNC信號，觸發對UI進行渲染， 如果每次渲染都成功，這樣就能夠達到流暢的畫面所需要的60fps，為了能夠實現60fps，這意味著程序的大多數操作都必須在16ms內完成。

*關於JobScheler的更多知識可以參考http://hukai.me/android-training-course-in-chinese/background-jobs/scheling/index.html

七、代碼規范

1）for loop中不要聲明臨時變數，不到萬不得已不要在裡面寫try catch。

2）明白垃圾回收機制，避免頻繁GC，內存泄漏，OOM(有機會專門說)

3）合理使用數據類型，StringBuilder代替String，少用枚舉enum，少用父類聲明(List,Map)

4）如果你有頻繁的new線程，那最好通過線程池去execute它們，減少線程創建開銷。

5）你要知道單例的好處，並正確的使用它。

6）多用常量，少用顯式的"action_key"，並維護一個常量類，別重復聲明這些常量。

7）如果可以，至少要弄懂設計模式中的策略模式，組合模式，裝飾模式，工廠模式，觀察者模式，這些能幫助你合理的解耦，即使需求頻繁變更，你也不用害怕牽一發而動全身。需求變更不可怕，可怕的是沒有在寫代碼之前做合理的設計。

8）View中設置緩存屬性.setDrawingCache為true.

9）cursor的使用。不過要注意管理好cursor,不要每次打開關閉cursor.因為打開關閉Cursor非常耗時。Cursor.require用於刷cursor.

10）採用SurfaceView在子線程刷新UI,避免手勢的處理和繪制在同一UI線程（普通View都這樣做）

11）採用JNI，將耗時間的處理放到c/c++層來處理

12）有些能用文件操作的，盡量採用文件操作，文件操作的速度比資料庫的操作要快10倍左右

13）懶載入和緩存機制。訪問網路的耗時操作啟動一個新線程來做，而不要再UI線程來做

14）如果方法用不到成員變數，可以把方法申明為static，性能會提高到15%到20%

15）避免使用getter/setter存取field，可以把field申明為public，直接訪問

16）私有內部類要訪問外部類的field或方法時,其成員變數不要用private，因為在編譯時會生成setter/getter,影響性能。可以把外部類的field或方法聲明為包訪問許可權

17）合理利用浮點數，浮點數比整型慢兩倍

18）針對ListView的性能優化，ListView的背景色與cacheColorHint設置相同顏色，可以提高滑動時的渲染性能。ListView中getView是性能是關鍵，這里要盡可能的優化。

getView方法中要重用view；getView方法中不能做復雜的邏輯計算，特別是資料庫操作，否則會嚴重影響滑動時的性能

19）不用new關鍵詞創建類的實例，用new關鍵詞創建類的實例時，構造函數鏈中的所有構造函數都會被自動調用。但如果一個對象實現了Cloneable介面，我們可以調用它的clone()方法。

clone()方法不會調用任何類構造函數。在使用設計模式（Design Pattern）的場合，如果用Factory模式創建對象，則改用clone()方法創建新的對象實例非常簡單。例如，下面是Factory模式的一個典型實現：

20）public static Credit getNewCredit() {
return new Credit();
}
改進後的代碼使用clone()方法，如下所示：
private static Credit BaseCredit = new Credit();
public static Credit getNewCredit() {
return (Credit) BaseCredit.clone();
}
上面的思路對於數組處理同樣很有用。

21）乘法和除法

考慮下面的代碼：

22）ViewPager同時緩存page數最好為最小值3，如果過多，那麼第一次顯示時，ViewPager所初始化的pager就會很多，這樣pager累積渲染耗時就會增多，看起來就卡。

23）每個pager應該只在顯示時才載入網路或資料庫(UserVisibleHint=true)，最好不要預載入數據，以免造成浪費

24）提高下載速度：要控制好同時下載的最大任務數，同時給InputStream再包一層緩沖流會更快(如BufferedInputStream)

25）提供載入速度：讓服務端提供不同解析度的圖片才是最好的解決方案。還有合理使用內存緩存，使用開源的框架

引用：Android性能優化的淺談

2. 如何一步步實現AndroidCI

一步步實現Android CI

Android上的CI構建鏈與其它平台一致，依然包含Compilation, Testing, Inspection,
Deploying階段，每一個階段的Feedback的都保持對整個團隊透明。

2、添加Function Test

Android為大家提供了一套集成測試框架Android integration testing
framework。但此框架未集成Cucumber，這導致每增加一個Function Test都需要較大的開發和維護工作。這樣高成本的實現Function
Test將大大延緩開發進度，最終因為項目進度的原因導致Function Test被丟棄。產生這樣的後果那必然是不願意看到的。

目前Android平台下已經出現多種Functiong Testing測試工具，如Native Driver, Robotium,
Calabash等。在嘗試對比後，最終選擇了Calabash Android作為解決方案。Calabash
Android是Cucumber在Android平台的實現，使用Ruby書寫Function Test，並提供了一組操作Anadroid App元素的API。

3、添加UI Test

Android在新近退出了UI測試工具UIAutomator。此工具僅支持Android4.1及以上平台，鑒於目前市場上2.3和4.0版本仍佔主導的情況來看，目前還無法滿足大家的需要。另外應用該工具實現UI測試的開發成本還較高，筆者暫不推薦使用此工具，但應該關注其發展。

另外基於錄制回放機制的測試方法同樣可以進行UI測試。但錄制回放的方法在面對功能快速迭代時，維護工作會急劇增加，而這個維護成本可以說是很難承受的，所以在此也不會將這種測試方法集成至CI中。

目前來看Android中UI測試還無令人滿意的方法。若對UI成功比較看重，可以投入精力應用UIAutomator進行UI測試。

Best Practice:

*
將測試按照單元測試，組件測試，功能測試和系統測試進行劃分。單元測試應該在每次提交時觸發執行，其它的測試根據運行時間長短和重要程度可以每次提交觸發執行或者定時周期執行。

* 將運行較快的測試優先執行。

* 讓功能測試能夠重復執行。否則維護成本太高，會被舍棄。若是後台數據導致不可重復，可以將數據抽象成為數據集，在每次運行前進行重置。

* 書寫測試時每一個assert只做一種判斷，這樣可以明確每次測試的目的，並且可以快速定位測試失敗願意。

步驟 3：持續檢查持續檢查是對於代碼本身檢測和反饋。檢測主要通過對代碼靜態分析驗證代碼風格，編程規范，代碼復用，代碼語言中的Best Practice等多個維度的代碼質量。

Sonar作為一個開源的代碼質量檢測工具，涵蓋了7項代碼質量檢測方式。這充分滿足Android平台下對於代碼質量的檢測分析。Sonar分為兩部分一部分是代碼分析工具，另一部分是數據分析展示的Server。

Best Practice:

* 將測試覆蓋率，代碼分析結果透明化

* 持續降低代碼復雜度

* 持續的促進設計的演進

* 持續的維護代碼結構

* 持續減少代碼重復

步驟 4：持續部署

由於Android App採用用戶手動從Appstore自行下載安裝的方式發布，使得Android
App無法直接部署至用戶手機中。另外Appstore需要對於上線的App進行審核，不能持續進行Release。因而Android中持續部署將以持續發布可安裝包為目標。

在以上目的下，只需根據自身項目資源找到合適的安裝包管理工具即可。如本文採用Dropbox來管理所有安裝包。

Dropbox作為一個雲存儲平台，在Android終端設備上可以輕松下載存放在其中的文件，同時上傳安裝包也可以交由Dropbox自己完成。

步驟 5：持續反饋

反饋是所有改進的開始，必須要讓所有人獲取到他們所關心的反饋信息，才能實施改進。持續反饋的目的就是讓所有人都掌握項目健康狀況。項目所有人事實都是有意願知道項目當前的健康狀況的，那CI就應該將項目的情況做到透明，並將不同的反饋通知到各相關的成員。

CI不同階段產生了不同維度的反饋，如單元測試報告，測試覆蓋率等。本實踐中將這些反饋都透明的展示在項目首頁中。之所以沒有將這些反饋再以郵件的方式通知所有人，是因為團隊成員已經養成了查看CI的習慣。

如果說只給所有人發一封郵件說明項目狀況，那必然是告訴所有人「CI所有步驟是否都返回正確？」。這樣一個反饋，包含了編譯正確，所有測試通過，安裝包已經准備完畢等重要信息。有必要讓所有人都知道這個信息，特別是在CI執行失敗的時候。Jenkins自身已經提供一個簡單有效的透明化方法，以項目為藍色表示通過，紅色表示有步驟失敗。

反饋的通知方式有很多種，不一定要採用郵件通知的方式。可以尋找更加有趣的方式，如果播放音樂和設置警報燈。在每一次Build成功或失敗後都播放一段有趣的音樂，打開不同顏色的警報燈，這兩種方法都是是一種簡單有效的方式，可以讓項目所有人都獲取到最為關鍵的信息。

3. android軟體開發工程師的進階之路應該如何走

小明首先需要購買一本Android入門的書籍，為了更快地學習Android，小明業余時間也都用來一邊看書一邊照著書中的例子敲代碼，結果2周時間小明就把這本書學了一遍。看完這本書後，小明對Android的歷史、結構、代碼規范等都有了一個大概的了解，並且，小明已經可以寫出一些簡單的Activity了。這個時候在小明眼裡，Android開發很簡單很好玩，通過在xml中擺放一些按鈕文本框什麼的就可以做一些界面了。
小明開始跟著他的技術導師做需求，一些簡單的小需求小明自然是不在話下了。突然有一天來了一個需求，該需求要求小明在Activity中為一個button加一個動畫效果，小明慌了：「完全沒接觸過，書上也沒有講，怎麼辦呢？」小明冷靜了下，打開了網路搜索，輸入「Android 動畫」，打開前幾個鏈接，小明恍然大悟，照著網上的例子把需求給實現了。後來導師告訴他：「學好Android，官方文檔是必須看的，既全面又權威」。然後小明如獲至寶，花了一年時間把上面的guide和training都看了一遍，並且他還動手抄了幾個小例子。
有一天，小明又需要做一個動畫相關的需求，這可難不倒小明，它熟練地打開了www..com，輸入「Android 動畫」，突然他楞了一下：」總不能每次寫動畫都要網路一下吧！「，於是他在CSDN開了一個博客，把動畫相關的知識點都寫上去，為的是後面再寫動畫相關的代碼就不用網路去搜了，事實如何呢？後面再寫動畫相關的代碼，小明的確不用再去網路搜了，因為通過寫一篇動畫博客，他把動畫相關的細節都已經記住了，這樣他就可以不用再去參考任何文檔了，後來小明還學會了把一些瑣碎的不方便放在博客上的東西寫到了印象筆記上面，什麼時候忘了10秒鍾以內都可以快速找回來，而不是花10分鍾去再次搜索一遍。
這里總結一下，Android入門的時候，需要有一本入門書，好好學習書中的內容，同時花一年時間把Android官方文檔中的training和guide看一遍，同時通過寫博客和記筆記的方式來做總結，建議讓自己的每篇博客都有價值些。通過一年時間的學習，相信每個人都可以達到中級工程師的水平。
技術要求：
- 基本知識點
比如四大組件如何使用、如何創建Service、如何進行布局、簡單的自定義View、動畫等常見技術
- 書籍推薦
《第一行代碼 Android》、《瘋狂Android》
中級工程師
小明經過一年的努力學習終於成為Android中級工程師了，月薪變成了17k。到了中級工程師，已經可以在公司里干很多體力活了，但是一些很重要的任務小明還不能一個人承擔起來，這個時候小明需要學習的內容就很多了，如下所示：
- AIDL：熟悉AIDL，理解其工作原理，懂transact和onTransact的區別；
- Binder：從Java層大概理解Binder的工作原理，懂Parcel對象的使用；
- 多進程：熟練掌握多進程的運行機制，懂Messenger、Socket等；
- 事件分發：彈性滑動、滑動沖突等；
- 玩轉View：View的繪制原理、各種自定義View；
- 動畫系列：熟悉View動畫和屬性動畫的不同點，懂屬性動畫的工作原理；
- 懂性能優化、熟悉mat等工具
- 懂點常見的設計模式
學習方法
閱讀進階書籍，閱讀Android源碼，閱讀官方文檔並嘗試自己寫相關的技術文章，需要有一定技術深度和自我思考。在這個階段的學習過程中，有2個點是比較困擾大家的，一個是閱讀源碼，另一個是自定義View以及滑動沖突。
如何閱讀源碼呢？這是個頭疼的問題，但是源碼必須要讀。閱讀源碼的時候不要深入代碼細節不可自拔，要關注代碼的流程並盡量挖掘出對應用層開發有用的結論。另外仔細閱讀源碼中對一個類或者方法的注釋，在看不懂源碼時，源碼中的注釋可以幫你更好地了解源碼中的工作原理，這個過程雖然艱苦，但是別無他法。
如何玩轉自定義View呢？我的建議是不要通過學習自定義view而學習自定義view。為什麼這么說呢？因為自定義view的種類太多了，各式各樣的絢麗的自定義效果，如何學的玩呢！我們要透過現象看本質，更多地去關注自定義view所需的知識點，這里做如下總結：
- 搞懂view的滑動原理
- 搞懂如何實現彈性滑動
- 搞懂view的滑動沖突
- 搞懂view的measure、layout和draw
- 然後再學習幾個已有的自定義view的例子
- 最後就可以搞定自定義view了，所謂萬變不離其宗
大概再需要1-2年時間，即可達到高級工程師的技術水平。我個人認為通過《Android開發藝術探索》和《Android群英傳》可以縮短這個過程為0.5-1年。注意，達到高級工程師的技術水平不代表就可以立刻成為高級工程師（受機遇、是否跳槽的影響），但是技術達到了，成為高級工程師只是很簡單的事。
技術要求：
- 稍微深入的知識點
AIDL、Messenger、Binder、多進程、動畫、滑動沖突、自定義View、消息隊列等
- 書籍推薦
《Android開發藝術探索》、《Android群英傳》
高級工程師
小明成為了夢寐以求的高級工程師，月薪達到了20k，還拿到了一丟丟股票。這個時候小明的Android水平已經不錯了，但是小明的目標是資深工程師，小明聽說資深工程師月薪可以達到30k+。
為了成為Android資深工程師，需要學習的東西就更多了，並且有些並不是那麼具體了，如下所示：
- 繼續加深理解」稍微深入的知識點「中所定義的內容
- 了解系統核心機制：
1. 了解SystemServer的啟動過程
2. 了解主線程的消息循環模型
3. 了解AMS和PMS的工作原理
4. 能夠回答問題」一個應用存在多少個Window？「
5. 了解四大組件的大概工作流程
6. …
- 基本知識點的細節
1. Activity的啟動模式以及異常情況下不同Activity的表現
2. Service的onBind和onReBind的關聯
3. onServiceDisconnected(ComponentName className)和binderDied()的區別
4. AsyncTask在不同版本上的表現細節
5. 線程池的細節和參數配置
6. …
- 熟悉設計模式，有架構意識
學習方法
這個時候已經沒有太具體的學習方法了，無非就是看書、看源碼和做項目，平時多種總結，盡量將知識融會貫通從而形成一種體系化的感覺。同時這個階段對架構是有一定要求的，架構是抽象的，但是設計模式是具體的，所以一定要加強下設計模式的學習。關於設計模式的學習，最近一本新書推薦給大家《Android 源碼設計模式解析與實戰》，既可以學習設計模式，又可能體會到Android源碼中的設計思想，我最近也在閱讀此書。
技術要求：
- 稍微深入的知識點
- 系統核心機制
- 基本知識點的細節
- 設計模式和架構
- 書籍推薦
《Android開發藝術探索》、《Android 源碼設計模式解析與實戰》、《Android內核剖析》
資深工程師
這個階段的程序員也許並沒有太具體的學習路線了。