Flex 性能優化常用手法總結
2024-09-12 17:51:27
供稿：網友
眾所周知，目前國內的寬帶應用并不是像很多發達國家發達，個人應用帶寬基本上都是2M以下的，怎么樣能夠使你的Flex應用能夠流暢的運行在客戶端的問題，成為了制約每個Flex應用開發程序員的大難題。
在這里，我收集整理了一下網絡上關于這方面經驗，歡迎大家補充。
基本原則：
1. 從外部加載媒體（Media）
Heider提到了一個常用的Flex最佳實踐――限制嵌入到應用/SWF文件中的媒體的數量，如圖像、影片及mp3等資源都可以從外部的SWF文件加載。
Flex框架可以直接將圖片、mp3及字體等資源編譯到SWF中。當你想讓最終用戶獲得全部資源時，這種方式確實能派上用場，但是這會導致你的應用長時間停留在“Loading”階段。
2. 在嵌入式字體中限制字符集
Heider建議在嵌入式字體中限制字符集以降低SWF文件的總下載時間：
當你在Flex中嵌入一種字體時，你就會獲得該字體的全部字符的支持。盡管這可能是你想要的，但你確信你需要全部字符么？例如，在一個只面向英文的應用中，你確信你真的想花時間下載中文字符數據么？
3. 緩存框架
Heider回顧了Flex 3 support for runtime-shared-libraries （RSL）這篇文章：
從Flex 3開始，你可以將Adobe簽名的框架――RSLs緩存到Flash Player的cache中。這有兩個好處。首先，緩存在Flash Player cache中的簽名的框架RSLs可由所有配置好的Flex應用共享。換句話說，如果某人的應用已經下載了500k的簽名的框架RSL，并且該RSL仍舊 在Flash Player cache中，那么你的應用就可以使用緩存下來的RSL。其次，即使某人清空了其瀏覽器緩存，對Flash Player cache也沒有任何影響。
4. 考慮模塊化
Heider談到了將Flex應用劃分成模塊的好處：減少字體加載時間的另一種方式就是將你的Flex應用劃分成模塊。使用模塊的一個好處在于當加載和卸載模塊時你能完全操控它。
之所以要劃分成模塊的最后一個原因是他們更快，而且我能即時加載它們。換句話說，在啟動時唯一需要加載的模塊就是 Step1.swf模塊。因此，在使用模塊的情況下，最終用戶節省了啟動時間，但是當他從一個模塊切換到另一個模塊時卻需要花更多時間，因為每個模塊都需 要以JIT形式加載。在我的應用中，只有當用戶首次在steps 1-5之間切換時需要花更多時間。
5. 推遲實例化
Heider圍繞著Flex組件的“creationPolicy”屬性及何時實例化應用的不同部分給出了很多建議。
如果你想減少從數據下載到用戶真正可以使用的總時間，當務之急就是推遲實例化。這項技術背后的理念就是直到應用真正使用的時候才在內存中創建對象。
盡管推遲實例化技術會在應用的整個使用過程中導致少許――通常不那么明顯――的延遲，但與長時間的啟動延遲相比，它還是可接受的。推遲實例化的另一個好處在于內存使用的優化。
以上原則來自Jun Heider在O'Reilly的InsideRIA站點上發表了一篇精彩的文章，該文章就如何加快Flex應用的啟動速度提出了很多建議，以幫助用戶減少看見討厭的“Loading”對話框的出現時間。他深入探討了問題的不同方面，并對每種技術的優勢和劣勢進行了評判。Heider還談到了一個“實驗性”的條款――“使用流”，這是他在討論Dirk Eismann的帖子（Building monolithic Flex SWFs that still startup quickly.”）時談及的。Eismann提出一項技術以利用Flash Player中的多個frames以在部分應用中達到流的目的。查看所有的帖子以更多地了解該技術及關于加快Flex啟動速度的建議。
內存釋放優化原則
1. 被刪除對象在外部的所有引用一定要被刪除干凈才能被系統當成垃圾回收處理掉；
2. 父對象內部的子對象被外部其他對象引用了，會導致此子對象不會被刪除，子對象不會被刪除又會導致了父對象不會被刪除；
3. 如果一個對象中引用了外部對象，當自己被刪除或者不需要使用此引用對象時，一定要記得把此對象的引用設置為null;
4. 本對象刪除不了的原因不一定是自己被引用了，也有可能是自己的孩子被外部引用了，孩子刪不掉導致父親也刪不掉；
5. 除了引用需要刪除外，系統組件或者全局工具、管理類如果提供了卸載方法的就一定要調用刪除內部對象，否則有可能會造成內存泄露和性能損失；
6. 父對象立刻被刪除了不代表子對象就會被刪除或立刻被刪除，可能會在后期被系統自動刪除或第二次移除操作時被刪除；
7. 如果父對象remove了子對象后沒有清除對子對象的引用，子對象一樣是不能被刪除的，父對象也不能被刪除；
8. 注冊的事件如果沒有被移除不影響自定義的強行回收機制，但有可能會影響正常的回收機制，所以最好是做到注冊的事件監聽器都要記得移除干凈。
9. 父對象被刪除了不代表其余子對象都刪除了，找到一種狀態的泄露代碼不等于其他狀態就沒有泄露了，要各模塊各狀態逐個進行測試分析，直到測試任何狀態下都能刪除整個對象為止。
內存泄露舉例：
1. 引用泄露：對子對象的引用，外部對本對象或子對象的引用都需要置null；
2. 系統類泄露：使用了系統類而忘記做刪除操作了，如BindingUtils.bindSetter()，ChangeWatcher.watch()函數 時候完畢后需要調用ChangeWatcher.unwatch()函數來清除引用 ，否則使用此函數的對象將不會被刪除；
類似的還有MUSIC，VIDEO，IMAGE，TIMER，EVENT，BINDING等。
3. 效果泄露：當對組件應用效果Effect的時候，當本對象本刪除時需要把本對象和子對象上的Effect動畫停止掉，然后把Effect的target對象置null; 如果不停止掉動畫直接把 Effect置null將不能正常移除對象。
4. SWF泄露：要完全刪除一個SWF要調用它的unload()方法并且把對象置null;
5. 圖片泄露：當Image對象使用完畢后要把source置null;(為測試)；
6. 聲音、視頻泄露: 當不需要一個音樂或視頻是需要停止音樂，刪除對象，引用置null;
內存泄露解決方法：
1. 在組件的REMOVED_FROM_STAGE事件回掉中做垃圾處理操作（移除所有對外引用（不管是VO還是組件的都需要刪除），刪除監聽器，調用系統類的清除方法）
先remove再置null, 確保被remove或者removeAll后的對象在外部的引用全部釋放干凈;
2. 利用Flex的性能優化工具Profile來對項目進程進行監控，可知道歷史創建過哪些對象，目前有哪些對象沒有被刪除，創建的數量，占用的內存比例和用量，創建過程等信息；
總結：關鍵還是要做好清除工作，自己設置的引用自己要記得刪除，自己用過的系統類要記得做好回收處理工作。 以上問題解決的好的話不需要自定義強制回收器也有可能被系統正常的自動回收掉。
