補：記憶體**機制測試：
通過編寫測試程式發現以下規律，flash記憶體**機制的一些特點：
1． 自動記憶體**時間不確定。
2． 當乙個物件存在被其他物件引用時，這個物件不會被記憶體**。
3． 當乙個流物件被載入，這個被載入的物件及已經占用了記憶體。
4． 當乙個視覺化物件被宣告，但 沒有新增到畫面是占用部分記憶體，加到displayobject上後，占用全部該物件物件全部記憶體。
5． 當載入重複物件，例如 載入100個同樣的 xx.swf ，如果僅是載入，完成後沒有引用，那麼記憶體變化規律，波浪型的。如果某個時間記憶體**。那麼最後留在記憶體中的應該是大小近似於載入1個 xx.swf （比1個xx.swf 要大些），從此可以推理出，要是不同的東西被載入，那麼最後即便是沒有記憶體漏洞，在一定條件下常用的東西記憶體中可能也會至少儲存每乙個不同的東西。經我測試好像是這樣的。(測多了可能還會有新發現呢)
6． 引用的包括
1） 對物件的儲存： 例如 使用乙個陣列儲存 某些物件，那麼陣列不釋放，物件不可能釋放
2） 對事件的監聽： 例如 監聽過程實際上是使用乙個物件儲存關鍵字和關鍵字關聯的事件，對事件關鍵字，查詢然後找出對應的關聯function。以下是as2**。as3 的eventdispatcher功能類似
var btnlistener:object = new object();
btnlistener.click = function() ;
bt1.addeventlistener("click", btnlistener);
使用removereventer 方法定是要清除掉 處理關鍵字索引和function 的物件。這樣即清除掉了計數引用。
3） 強制**方式，自動記憶體**時間不確定，使用特殊的方法，該方法實際上觸發乙個錯誤引起資源**，使無用的不被計數器引用的都要被**。（暫時不被使用的，沒有引用的那個被自動**保留的那個乙個**掉）
方法：try catch (e:error) {
trace(e.message);
乙個例子 假如 有個loader 請求載入url=***x.swf 的位址，然後成功載入 ***x.swf, 10次 ，每次成功後沒有處理，假設這時候自動**沒有呼叫，那麼使用強制**，在debug模式下，會看到**資源。
[unload swf] ***x.swf ，10個這樣的輸出。
7． 編寫**注意：
1） 無用的物件，沒有引用
2） 降低類設計之間的耦合度，注意物件傳遞引用的設計等
3） 單例模式，在合適的時候使用
4） 事件迴圈巢狀造成多次執行，或事件觸發迴圈bug。
5） 物件重複加同樣的監聽
根據記憶體特性製作了資源管理類模組
工作量分布 1編寫resource monitor類，2修改**中所有資源載入處。
有一點需要注意，這次新增resource monitor類的方式，在以後重構後，載入呼叫的函式方
式可能都需要改變，設想通過服務來獲取資源。那麼這個服務的名稱等資訊自然會得到。
使用方法
weeklyloader = new loader();//程式中的loader載入 ,不需要改變
rf.load(weeklyloader,path,"人物");//新增 rf 為資源管理類，採用靜態方法訪問，path 是資源的url,」人物」是模組或資源型別的名稱。不需要傳遞**方法。
記憶體優化autoreleasepool的使用
在arc記憶體管理模式下，使用 autoreleasepool 主要 來避免頻繁申請 釋放記憶體，從頁達到優化記憶體的效果。根據 使用場景如下 1 寫基於命令列的的程式時，就是沒有 ui框架，如 等cocoa 框架時 2 寫迴圈，迴圈裡面包含了大量臨時建立的物件 3 建立了新的執行緒 非 cocoa...
Android的記憶體優化
android應用優化主要集中在記憶體和ui流暢度上。從記憶體占用與洩露 ui流暢度的幀數和響應時間到io的堵塞式響應時間等。記憶體優化 首先。為什麼要優化記憶體？主要體如今oom out of memory 和導致ui不流暢上。對於手機來說。記憶體是乙個很稀缺的資源，即使是如今普遍擁有著很大記憶體...
STL的記憶體優化
stl記憶體管理使用二級記憶體配置器。1 第一級配置器 第一級配置器以malloc free realloc 等c函式執行實際的記憶體配置 釋放 重新配置等操作，並且能在記憶體需求不被滿足的時候，呼叫乙個指定的函式。一級空間配置器分配的是大於128位元組的空間 如果分配不成功，呼叫控制代碼釋放一部分...