十二月工作總結

最近比較忙，拖到現在才來寫上個月的工作總結。

1）  動态配置設定記憶體資源的釋放問題。

動态記憶體配置設定後，應該小心處理這塊記憶體，不然會出現一系列跟記憶體相關的問題。問題總結如下：

1．1）   配置設定了，沒有釋放，造成記憶體洩露，當時程式運作也許不會當機，但是随着記憶體越來越少，難免會出現當機的問題。

1．2）   配置設定了10個機關的記憶體空間，卻在程式中對該塊記憶體執行越界操作。這種情況經常出現在對字串操作中，例如malloc了10個char的A數組，卻從100個char的B數組拷貝char到A數組中。

1．3）   配置設定記憶體，在釋放該記憶體後，未對原來指向該記憶體的指針執行設NULL操作，也即常常說的野指針。因為程式中很多代碼都是先判斷指針是否為NULL，非空才進行相關記憶體操作，若碰到野指針則會出現對非法記憶體進行操作的情況，出現不可預知錯誤。

1．4）   給string配置設定記憶體時，應該算入結束符’/0’的空間。

2）  跟蹤記憶體的debug技術。

使用debug中的memory檢視記憶體變動。這種對于檢查動态記憶體的配置設定釋放有些幫助。剛開始看前輩用VS自帶的memeory檢視工具檢視記憶體的配置設定釋放，設定條件斷點跟蹤指定條件代碼，用記憶體變動觸發斷點時，覺得出神入化。現在經過這一學習，自己也會用了。真是神奇的地球。

VS自帶的Memory View工具，适用于細緻檢視記憶體配置設定釋放情況，檢視記憶體使用的工具。常用來跟蹤動态記憶體配置設定釋放。

條件斷點，常用于觸發某一限定條件的break point。例如在一個循環内打一條件break pioint，隻在循環到第五十次時才觸發。

Memory變動斷點，指定某記憶體位址，在debug到該記憶體值改變時即觸發，友善定位那些不知在哪修改了記憶體的代碼。

3）  記憶體洩露的查找。這是一個細心活，也是針對動态記憶體的管理問題。隻能依靠log定位到程式中出現洩露的記憶體在代碼的哪裡配置設定的。另有一些log是不能定位到具體哪行代碼配置設定記憶體的，隻能根據其他資訊諸如洩露記憶體size已經自己逐行查找動态記憶體使用的代碼。

6）  手機UI界面的設計應該考慮到人性化，類似諸如用“OPT”代碼option的顯示應該避免，因為不能确定使用者是否知道該縮寫的意思。

8）  關于指針的操作及文法，認識上有一定提高。