android開發中應該注意的問題

標籤：android   c   class   java   a   http   

1. Activity可繼承自BaseActivity，便於統一風格與處理公用事件，構建對話方塊統一構建器的建立，萬一需要整體變動，一處修改到處有效。 2. 資料庫表段欄位常量和SQL邏輯分離，更清晰。 3. 全域變數放全域類中，模組私人放自己的管理類中，不要相信龐大的管理的東西會帶來什麼好處，可能是一場災難。 4. 如果資料沒有必要載入，私人模組資料務必延遲初始化，謹記為使用者節省記憶體，總不會有壞處。 5. 異常拋出，集中到合適的位置處理，不要拋出來異常立即捕獲，搞的到處是catch。 6. 地址引用鏈長時（3個以上指向）小心記憶體流失，和警惕堆棧地址指向。 7.資訊同步：新插入的資料注意返回ID。 8.多線程時db關閉了會報錯。 9.做之前先考慮那些可以公用，資源，layout，類，做一個架構分析。 10 有序隊列操作AD操作時注意排序。 11. 刪除要注意級聯操作。 12 對返回的null對象做好充分的容錯。 13. 形參實參：基本類型傳值，對象傳引用。傳址方式，形參可以改變對象狀態和內容，但是不可改變實參的內容。 14. listview在資料未滿一屏時，setSelection函數不起作用。 15 大量操作嚴格和視圖對應，不容隱患。 16 控制Activity的代碼量，保持主要邏輯清晰。其他類遵守SRP，ISP原則。 17. arraylist執行remove時注意移除int和Integer的區別。 18. 調試列印一定要做標記，能定位列印位置，否則後期類多了都不知道是哪裡在列印。 19. 碼塊/常量/資源可以集中公用的一定共用，即使共用邏輯複雜一點也值得，修改起來很輕鬆，修改一種，到處有效。 20. setSelection不起作用，嘗試smoothScrollToPosition。ListView的LastVisiblePosition（最後一個可見子項）會隨著getView方法執行位置不同變動而變。 21與Activity通訊使用Handler更方便； 如果你的架構回調鏈變長，考慮監聽者模式簡化回調。 22. Handler在其他線程使用Looper.prepare，主線程則不用。 23. timepicker 點擊確定後需要clearFocus才能擷取手動輸入的時間。 24. 建構函式裡面不要輕易啟動非同步線程。假設非同步線程調用了本例的樣本，就會悲劇。 25. 千萬不要理所當然的以為一個對象不會為空白，充分的做好容錯處理。 26. ExpandableListView的子列表不能點擊要把Adapter的isChildSelectable方法返回true。 27. UI顯示注意內容過長的情形，注意按鈕的感應範圍不小於9mm，注意游標的位置。 28. 伺服器和用戶端盡量統一唯一標識，否則多少會有歧義和問題。 29. 注釋，要寫足夠的注釋，達到看了可以明白某一塊代碼的效果。 30. 使用Log打日誌，打上Tag。 31. 完整型資料一定要用Sqlite的Transaction，大資料一定要用。插入100個資料有20倍的提速，插入1000個資料就有100多倍的提速。 32. 避免String=”null”的情況出現String = null,=”"都可以。避免出現title=”無主題”這樣的資料提交到資料庫浪費空間。 33. 存在多個不同的dbhelper執行個體情況下，sqlitedatabase對象必然存在不同的執行個體，多線程同時寫入資料，輪流寫入資料時會不定時的報db is locked，引起崩潰，不管是操作同張表還是異表。讀和寫可以同事並發，輪流無規律的交替執行。同時寫入資料時解決方案是用並發的每個線程都用事務，db則不會lock，按次整體寫入。 34. 建議整個應用維護一個dbhelper執行個體，只要db沒有關閉，全域就只有一個db執行個體，多線程並發寫入db不會lock，嚴格交替進行寫入：123123123。。。（123代表不同線程，輪流插入一個記錄），讀和寫均不會鎖住db，讀寫交替並沒有規律，執行次數和程度看cpu分配給哪個線程的時間片長。 35. 一個任務使用事務嵌套N個事務，N個事務中有一個失敗，這個任務整體失敗，全部成功後，資料才寫入，具有安全性，整體性。並且事務寫入大批量資料的效率經實際測試成百上千倍的高於一般的單個寫入。 36. 經常需要用ListView或者其它顯示大量Items的控制項即時跟蹤或者查看資訊，並且希望最新的條目可以自動滾動到可視範圍內。通過設定的控制項transcriptMode屬性可以將Android平台的控制項（支援ScrollBar）自動滑動到最底部。 37. Long a; 判斷a有沒有賦值，if(a == 0)在a沒有賦值情況下會報錯。應該if(a == null)，Integer也一樣。 38. 編碼遇到讀寫、出入等邏輯要雙向考慮，檔案匯入匯出，字元位元組相互轉換都要兩邊轉碼。 39. 一個 int 值與一個 Integer 對象（能包含 int 值的最小對象）的大小比率是 1:4，這個比率可能會讓您感到吃驚。額外的開銷源於 JVM 用於描述 Java 對象的中繼資料也就是 Integer。 40. 對象由中繼資料和資料群組成。中繼資料套件括類（指向類的指標，描述了類的類型），標記（描述了對象狀態，如散列碼、形狀等），鎖（對象同步資訊）。數組對象還包括大小的中繼資料。 41. 一個在 32 位 Java 運行時中使用 1GB Java 堆的 Java 應用程式在遷移到 64 位元 Java 運行時之後，通常需要使用 1.7GB 的 Java 堆。 42. Hash 集合的效能比任何 List 的效能都要高，但每條目的成本也要更高。由於訪問效能方面的原因，如果您正在建立大集合（例如，用於實現緩衝），那麼最好使用基於 Hash 的集合，而不必考慮額外的開銷。 43. 對於並不那麼注重訪問效能的較小集合而言，List 則是合理的選擇。ArrayList 和 LinkedList 集合的效能大體相同，但其記憶體佔用完全不同：ArrayList 的每條目大小要比 LinkedList 小得多，但它不是準確設定大小的。List 要使用的正確實現是 ArrayList 還是 LinkedList 取決於 List 長度的可預測性。如果長度未知，那麼正確的選擇可能是 LinkedList，因為集合包含的空白空間更少。如果大小已知，那麼 ArrayList 的記憶體開銷會更低一些。 43. 選擇正確的集合類型使您能夠在集合效能與記憶體佔用之間達到合理的平衡。除此之外，您可以通過正確調整集合大小來最大化填充率、最小化未得到利用的空間，從而最大限度地減少記憶體佔用。 44. 充分利用封裝（提供介面類來控制訪問資料）和委託（helper對象來實施任務）。 45. 延遲分配 Hashtable：如果 Hashtable 為空白是經常發生的普遍現象，那麼僅在存在需要儲存的資料時分配 Hashtable 應該是一種合理的做法。將 Hashtable 分配為準確的大小：由於使用預設大小，因此完全可以使用更為準確的初始大小。46. EditText在setText時不要忘記是否需要setSelection。在大多數情況下是需要設定的。 47. XML兩種情況要注意：1 屬性名稱字時候有重複；2 注意文本是否包含非法字元，注意使用CDATA包裹。 48. 當邏輯沒有明顯問題時考慮對象屬性、函數參數、網路傳輸參數是否全部瞭解，是否設定正確。 49. 當出現編譯或者執行階段錯誤，別人那沒問題時，考慮你的編譯環境和環境版本是否有問題。 50. 由於String類的immutable性質，當String變數需要經常變換其值時，應該考慮使用StringBuffer類，以提高程式效率。 51. java 棧的優勢是比堆速度快，可共用，主要存放臨時變數、參數等，堆的優勢是可動態分配記憶體大小。 52. 只要是用new()來建立對象的，都會在堆中建立，而且其字串是單獨存值的，即使與棧中的資料相同，也不會與棧中的資料共用。 53. 基礎資料型別 (Elementary Data Type)定義的變數稱自動變數，存的是‘字面值’，存在於棧中，可共用（存在即不建立）。 54. 多個RandomAccessFile對象指向同一個檔案，可使用多個線程一起寫入無需鎖住對象，經實驗結論：三個線程分別寫入100萬次資料，使用鎖約12秒，不使用約8.5秒。100個線程分別寫入1萬次資料使用鎖耗時約4.2秒，不使用鎖耗時約3秒。 55. XmlPullParser解析慎用nextText()方法，xml比較複雜，含有空標籤、重複名字標籤時容易出現異常問題；TEXT中使用getText()方法代替START_TAG中使用nextText()方法；START_TAG，TEXT，END_TAG三個事件配合使用。注意每個xml節點之間（不管是開始節點還是結束節點）都會出現TEXT事件。 56. 改變邏輯的時候考慮全部用到這項功能的地方，分散的地方多了，容易大意。 57. 當系統組件出現問題時，查看錯誤棧資訊，在合適的地方將出錯方法複寫一下，加上try catch保證不崩潰掉。切記不要擾亂了該系統控制項的正常邏輯。 58. 輸入控制項注意對空格、換行等符號的控制。輸入框裡內容注意和左右控制項的控制項，防止誤點擊。 59. 注意函數參數裡的++或者–操作。是++c 還是 c++，區別很大。注意null也可以插入ArrayList中。 60. 永遠不要小看null指標問題，寧可錯殺，不可放過。 http://www.vmatianyu.cn/summarization-of-technical-experience.html