因為專案，接手了乙個公司外包flex專案的跟進，bug很多，慢慢理清程式邏輯，發現外包的團隊，都有乙個使用timer的不良習慣，從而導致了該專案從開發初期，就已經埋好了很多地雷。
我會從專案裡抽出部分**說明，最後以自己的經驗，做個總結，什麼時候用timer，什麼時候不該用timer
/**
* * @param event
* */
protected function resizehandler(event:resizeevent):void
);timer.start();
}
這裡的fitdisplay(); 就是使用者處理螢幕縮放後，介面元素的尺寸處理
這裡大家可以很顯然看到，有乙個50毫秒的延時，至於為什麼用50毫秒，估計外包的公司的那幾個程式設計師，做過了一些測試，可能他們的開發機，上限制值20毫秒就能有處理結果，他們為了保險，用了50毫秒，就臆斷了客戶機可以勝任了此程式的執行。
很顯然這是不負責任的寫法，程式設計師的職責是什麼？就是編寫能穩定執行功能的**。為什麼這次要重點講到這部分，是因為timer,一直都有不少人在重複犯相同的錯誤，而這次的外包專案，我從**的注釋和編碼風格，大概知道了是2個老手帶3個新手，而這個團隊5個人都有亂語，甚至濫用timer的習慣。
好了，吐槽完畢，認真的解析下這個timer的官方說法：
timer 類是 flash player 計時器的介面。 可以建立新的 timer 物件，以便按指定的時間順序執行**。 使用 start() 方法來啟動計時器。 為 timer 事件新增事件偵聽器，以便將**設定為按計時器間隔執行。官方解釋的很清楚，flashplayer的虛擬機器是以幀頻去觸發渲染的，而幀頻又和電腦硬體等有著必然聯絡，所以注定了開發者不能以自己或周邊幾天電腦為判斷依據，去隨意估值乙個延時的時間，再去觸發事件，這樣會有很多不可預計的現象發生。
還有現在從事flex開發的程式設計師，並不是從flash轉型過來，對幀頻這個概念比較模糊
上述只是其1的問題，是fp自身的渲染邏輯注定的，其2大量使用timer，是程式設計師自身不負責任的編碼習慣。 上述那段**，其實就是介面初始化後，才能去執行縮放處理，但是介面初始化是有一定的時間差，這個時間差應該通過事件去排程執行縮放處理，而不是妄自的認為給定乙個50毫秒就解決的。現在初始化50毫秒上限制可以渲染出來，假如剛好在那個初始階段，機器有其他吃cpu的軟體在突然執行，那50毫秒，甚至500毫秒都可能渲染不出來，那這個縮放處理函式還是會出錯，報null值錯誤。作為程式設計師，應該是嚴謹的，多學習事件執行流程對自己開發是多多益善。
說了這麼多，就是告誡自己，程式執行執行的邏輯順序，一定要掌握在自己手中，而不是交給機器，放任不管，這樣可以做到心中有數，遇到bug也知道問題出在**。而不是去各種瞎碰，去修改延時時間。
as3中的容器
4種容器 array object vector dictionary 各自特點 array是索引陣列，雖然它也是動態類，可以等同於object來用，但是不建議這樣，因為沒有任何好處。除了鍵上的區別外，array還是善於隨機訪問的，但不知道object和dictionary和它在訪問速度上的區別有多...
談談學習AS3的過程
今天有點時間，抽空寫一些關於學習 as3的過程。目前還是繼續 as3領域當中的應用，說到 as3，應該是從 2008 年開始，也是部落格建立開始算起來，那時候我對 as3也是 的階段學習，沒有什麼好的資料看，也沒有什麼人去學習 flash 當中的技術。班裡面只有我乙個人去關注這種技術，從那時候我才知...
關於as3效率的優化
1.a b 要比 a a b 快，同樣，自增a 也比a a 1快，不過自減a 不是比a a 1快。2.在做除以2操作時，乘法比除法快，位運算更快.但是不要位運算來操作number型別的變數，因為它會將number型別的數值轉為整數型別。for int a b 1 faster than a b 5 ...