1，你寫下以下代碼測試:
mymc.loadMovie("1.jpg")
trace(mymc._width)
輸出：0
哼！內部裝了那麼大一張圖片，居然不改變寬度？有經驗的朋友都知道，如果你要做的效果要用到mymc的寬度，是無法調用的。
2，再寫下以下代碼測試:
var ml=new MovieClipLoader()
ml.addListener(this)
ml.loadClip("1.jpg",mymc)
trace(mymc._width)
輸出：0
同樣的效果
3，好，那我用下面的代碼來試試：
var ml=new MovieClipLoader()
ml.addListener(this)
ml.loadClip("1.jpg",mymc)
this.onLoadComplete=function(){
trace(mymc._width)
}
輸出：0
看來onLoadComplete也是不堪重任。
4，那用onLoadInit吧，”王牌“
var ml=new MovieClipLoader()
ml.addListener(this)
ml.loadClip("1.jpg",mymc)
this.onLoadInit=function(){
trace(mymc._width)
}
輸出了我們要的數據，就是他了，我們要的寬度。
5，雖然達到了效果，但我們既然是在載入，就不得不考慮attachmovie把圖片轉成MC（一定得轉爲MC，直接在庫中圖片上設linkage是不行的），linkage設爲pic
mymc.attachMovie("pic","pic1",3)
trace(mymc._width)
輸出正常，這個很容易理解，他是影片內部庫中的東西， 不存在延遲問題。
闡述一下我對上面總結吧：
1,2————loadmovie和直接用loadclip載入外部文件，都無法立刻取得相關信息。
3,4————MovieClipLoader是延遲的客星，但onLoadComplete不堪重任，onLoadInit纔是最佳選擇。
5—————attachMovie可以避免延遲，但是不推薦使用，圖片一多，你有那麼大庫裝嗎？
///////////////////////////////////////////////////////////////////////////////
應用效果：
今天在研究bitmapdata類，所以就用我今天的一個例子來說吧，我貼出我原來的代碼,是什麼效果，我就不說了，表達不清楚，知道這個類的一看就會明白我的意圖，不知道這個類的，我覺得你更要看。
舞臺兩個空MC，一個爲mymc,一個爲source
原來的代碼：import flash.display.BitmapData;
var ml=new MovieClipLoader()
ml.addListener(this)
ml.loadClip("1.jpg",source)
source._width=50
source._height=50
var bm:BitmapData = new BitmapData(500,300, false,0xaa3344);
bm.draw(mymc)
mymc.attachBitmap(bm, 3, "always", true);
毫無效果。
後來改正後的代碼：import flash.display.BitmapData;
var ml=new MovieClipLoader()
ml.addListener(this)
ml.loadClip("1.jpg",source)
this.onLoadInit=function(){
source._width=50
source._height=50
var bm:BitmapData = new BitmapData(500,300, false,0xaa3344);
bm.draw(mymc)
mymc.attachBitmap(bm, 3, "always", true);
}
效果正常了
| Wikipedia把延遲加載定義爲：一種常用的編程設計模式，用以推遲一個對象的載入時機至需要此對象的時候。我們使用延遲加載主要是爲了增加RIA應用的響應速度 -- 由於我們不需要從後臺一次性的調用一大堆的數據，用戶無需爲某次調用而等待很長的事件。此模式在設計時對未知深度的嵌套分級數據類（祖父級，父親級，兒子級等等）特別有用。 同時，它還有以下優點： 必需性 如果你的客戶端是用AS3代碼的，如果服務端不能一次性給你整個樹，試下一次加載所有的數據（例如啓動的時候）。 一些語言允許你加載基礎水準的東西，循環通過每個對象和加載他的子對象等等。 在Actionscript中，服務端邏輯的調用都是異步的，這意味着你的調用只是你所有邏輯中的一小部分，這樣你無法控制響應結果的返回時機。 但是，當元件做此邏輯調用的時候它會帶出一個事件，當此事件告訴你結果可用的時機。 在某個層面上來講這一點很好，它允許程序當數據調用後保持隨時響應。然而，它還是有點強制你在你的代碼的不同方法中傳播數據的加載。由於你無論如何都要做這個，它開始給人一種“即時加載”的錯覺多過一次性加載。 透明性 如果所有的數據在服務端加載完，這也是你的應用在開始的時候取得單個“數據堆”的主要方法，這將有許多代碼在運行但是代碼中不顯示。例如，你將有可能等到一個分級的XML，這個對原始開發者很明瞭，但是對後面加入的開發者就很茫然了。當你可以看到何處何如何加載每個級別的對象被加載，代碼將會更容易被理解和調試。 簡單性 如果在某個時候僅關注某一級別的對象，代碼將比遞歸至一位置深度的樹形結構的代碼變得簡單多了。相反的，代碼可以簡單的一次性做完某件事情。當你所有的實例對象都是相同的基本類型的時候尤爲凸顯。 延遲加載簡化了不知是客戶端的代碼，同時也簡化了服務端的代碼。數據的取得在一個簡單點的格式中可以返回簡單得多的信息，所以代碼在服務端將獲更加輕量化和更加快速的響應。 希望對延遲加載的這個簡單的總結沒有影響到你對使用它的興趣。如果你想看一下延遲加載的例子，來看看這個例子。 |