1、不要排斥新技術和新工具。

Android Studio 1.0 之後的版本，基本已經穩定到可以支援正常的工作開發的程度了。單純就書寫效率而言，Android Studio 帶來的好處絕對大於它和Gradle的學習成本。JetBrains的IDE，用過都說好。

還有就是適當的提升targetSdkVersion到新版本。

2、程式碼設計方面的問題，大部分都能在Android系統原始碼裡找到解決方案。

當你想設計一個新模組，或者實現一個新ui元件的時候，應該採用哪些設計模式、應該以哪種形式給外界提供介面之類的問題，大部分都可以參考Android系統的原始碼，找到實現方式。Google為安卓程式設計師提供了一座現成的寶庫。

3、理解Android和Java記憶體管理方式，至少要理解垃圾回收和Java的引用。

就好比學OC就要先理解黃金法則一樣，而java的記憶體管理，其實比OC要好理解多了。

這可能會幫助你大大減少程式非同步操作產生的空指標崩潰。也會幫助你理解為什麼濫用單例模式會導致記憶體的臃腫。還會幫助你養成不用“+”去連線超大字串的好習慣。

4、ContentProvider並不是只有在跨程序共享資料的才有用，把資料庫表對映到一個獨立的uri是Google鼓勵的實現方式。

從設計上講，用uri（統一資源識別符號）去描述資料，肯定比sql語句要理想。

從效果上講，用CursorLoader讀取資料是讓iOS程式設計師都羨慕不已的事情，作為android程式設計師，何苦不用呢。

5、理解Activity任務棧。

非Activity的Context物件如果直接啟動Activity會報錯，這只是一個表面現象，真正起作用的其實是Activity任務棧機制。

理解Activity任務棧機制以及Activity的各種啟動方式，會幫助解決大部分頁面關係錯亂問題，以及應用互相掉起、工作列進入應用、後臺彈窗引起的各種問題。

6、對於一些奇葩的第三方ROM，呼叫其非主流api的時候，可以使用反射。

在適配一些第三方ROM的的時候，呼叫一些在開發環境中沒有，但在執行環境中有的方法時，可以使用反射。比方說，華為雙卡手機可能會提供獲取第二塊SIM卡資訊的api，如果直接呼叫，在開發環境可能無法通過正常編譯，用反射就沒問題。這屬於不得已而用反射的一種情況。

7、SQLite的鎖，是資料庫級別的鎖，也就是說同一個資料庫的寫操作無法併發執行。

所以，在資料庫設計的時候，如果表太多，儘量將沒有關聯的表拆到多個數據庫檔案中。

8、Bitmap的記憶體佔用問題。

這是一個困擾2.X時代android程式設計師的問題。

2.X時代Bitmap物件雖然儲存在堆記憶體中，但是用了一個byte陣列儲存其畫素資訊。通過計數器來記錄該畫素資訊被引用的個數。有人認為這個byte陣列在native堆中，但事實上它也在堆中。

只有在使用者呼叫recycle()後，Bitmap物件才會釋放畫素資訊，才會在失去引用後，被垃圾回收機制銷燬。再加上DVM的heap size有嚴格的閥值，所以在使用大量圖片資源的時候，及其容易發生OOM。

解決辦法一般都是，用一個雜湊表儲存Bitmap物件的軟引用，作為記憶體快取，並在適當時機掉用其recycle()。

3.0以上版本Bitmap物件可以通過垃圾回收機制完全銷燬，理論上不用再呼叫recycle()。

..................