1. 儘可能減少return的次數，同時避免不必要的重複邏輯處理
如
public boolean isWIFIOpened() {
if (mWifiManager.isWifiEnabled()){
returntrue;
}else{
returnfalse;
}
}改爲
public boolean isWIFIOpened() {
returnmWifiManager.isWifiEnabled();
}2. 把不同邏輯下相同的代碼提取了出來，避免重複，提高閱讀性
3. 使用String進行數據拼裝過於繁瑣，之後再進行反向解析耗費時間，可考慮用整形數組等其他方式替代；儘量避免使用String作爲比較邏輯處理，可使用int數值等方式替代；數據優先，延遲實現，數據的處理應該放在首要位置，數據處理完了在進行UI的顯示處理；原始數據需要保存下來，參數傳遞時都使用原值傳遞；星期數的提取可以使用XML進行中英文適配；當有需要進行數據適配時可以使用XML文件匹配相應的要顯示的值，同時如果有需要可以把原始的值保存到相應的XML文件中
4. 變量以及函數的命名要更有意義，要有明顯的區分，不能混淆，避免使用My等命名方式，WIFI應該命名爲Wifi；方法與參數的命名要統一，相同類別的參數可以加上相同的前綴，格式整體一致；命名應該避免與系統的API或者類名重複
5. 善用系統API，自己寫重複代碼不僅效率低而且需要承擔風險，比如判斷字符串是否爲空等等
使用系統isEmpty()函數判斷字符串是否爲空
使用String.format()函數爲時間值自動補0
6. 層級與層級之間避免耦合，每層要有自己的判斷，不能依賴於其他層的代碼
7. 成員變量數量不宜過多，如果不是重複被調用的，僅作一次性使用的不應作爲成員變量定義，變量的作用域不應太大，應該只在他使用的範圍內定義
多次使用的變量依舊用作成員變量，一次性使用的全部挪到相應的作用域內
8. 使用反射機制時需要考慮版本的風險，有可能有的版本沒有所需要反射的類或者方法等
由於項目中使用了Connectivity類的反射，但是暫時沒有找到Connectivity類以及其中的方法有與版本相關的信息，還在查找資料中，後續確認了補上。
9. 數據庫操作需要考慮並行問題
目前還沒實踐過，之後補上
10. 自定義類統一放置底部，靜態變量統一放置頂部
11. AlarmManager如果沒有設置重複鬧鐘那麼在定時激活後系統將會自動cancel掉，不需要手動進行cancel
12. 可以嘗試直接使用AlarmManager直接進行定時處理從而避免使用多餘的類以及數據庫操作等繁瑣的處理
13. Fragment的數量要進行控制，避免過於碎片化
14. HappyPath
Happy Path Test是指在測試中僅對用戶的正常操作流程進行處理，這個處理的路徑就是Happy Path，在代碼編寫過程中，舉個例子，在邏輯處理方面中的必須按照正常邏輯思維去處理，順序應該是如果滿足條件系統去做什麼事，不滿足條件系統去做什麼事，而不應該變成不滿足條件系統去做什麼事，滿足條件系統纔去做什麼事，這不符合正常邏輯思維
15. 將String類型值統一放入String.xml中進行統一資源管理
目前在類中存放的只有更適合放置在本類中的例如星期的中文寫法，並且也只在本類中使用從而較好維護的字符串，其餘的都已歸入Stirng.xml中統一管理
16. UI提示應與邏輯處理進行分離，不應寫在同一個函數中，避免耦合
將UI提示從邏輯處理函數中抽取出來
17. 需要對ListView進行優化
目前使用複用緩存中的view對象實現，用holder的方式正在學習中，後續補上