本文長期更新

1、論android升級：

專案過程中，如果實在是時間緊迫，升級功能一定要保重開發完成並且功能穩定！而且特別要注意的是，推送升級的方式很弱，很難讓每個使用者注意到，而且客戶端會有很多零散的邏輯，很難做好。一般最好採用客戶端主動獲取升級資訊的方式，實現的邏輯也相對簡單。

另外，可以在"設定"介面設立相關的按鈕，讓使用者可以主動升級！！！萬一你的使用者喜歡這款app，而升級系統有問題，這裡也是一個入口。雖然想得很美，但是給使用者一種選擇也是極好

2、java相關專案的包名

      至少要寫3段，比如com.xx.yy，決不可只寫兩段com.xxx，寫兩段及其容易出現跟別人重複！！！

3、如果專案中有子賬號的業務，比如一個賬號下有多個角色可以在內部切換。這時候應該由客戶端傳入子賬號的資訊，讓伺服器進行操作。

另外一種不推薦的做法是：伺服器儲存預設的子賬號資訊，客戶端切換後提交給伺服器。這種做法雖然簡化了伺服器與客戶端之間的介面引數，但是預設子賬號資訊的同步會是一個很大的問題，比如多終端登入甚至pc端登入，切換了子賬號，這時候，客戶端的子賬號資訊又要進行同步，否則會發生資料錯亂！

總結就是：寧可互動接口裡多一個兩個引數，確保資料正確！

4、推送問題：正式釋出的應用當與測試應用的推送相關key區分開來，防止相互影響！

5、輪詢機制對客戶端來說，也許就是不合理的。。。

6、遇到問題，如果從資料分析的角度沒有進展，可以嘗試總結現象的規律（比如介面操作的現象），或許可以有幫助。

      一般來說，問題總會有一些可以循跡的規律表現出來，try to capture it!

7、支付相關的比如支付寶、微信支付等，開發完之後 ，賬號的資訊不要瞎jb改，改出什麼問題來就比較尷尬，找幾天問題找不到！

8、多執行緒是程式流暢的關鍵

9、設定資料庫，要仔細詢問實體之間的對應關係，是一對一、一對多、多對一、多對多？

10、資料版本號的相容問題。

      比如在訊息體里加了一個version欄位，那麼在開發老版本的時候，就需要比較當前的版本號與version得值，如果當前版本比version低，則報版本低的提示錯誤。這種方法則可以保證邏輯的完整性，至少不會產生崩潰一類的驗證問題。

11、if else 時，請考慮最後一個else該做什麼，不要漏掉了邏輯，提高相容性

12、json的解析中，注意容錯的相容性。在Gson的解析中，可以設定registerTypeAdapter來提高某些欄位錯誤時的相容。同時，在一些關鍵的介面中，如果獲取列表，可以考慮自己解析列表，出錯的成員則丟棄，而不會造成整個介面的資料出錯而被丟棄。

13、Android app上架之前，製作簽名要謹慎，慎重填好各種資訊，因為釋出之後，簽名信息是可以被人知道的。然後儲存好密碼和別名等資訊！