FLASH項目開發總結

1、  命名規範：

（1）       元件命名：

由于每個人開發FLASH時使用的命名習慣都未必相同，若是一個人開發時，并不存在什麼問題，但多人同時開發時，若不遵循一定的命名規則，則容易出現混亂，是以每次開發前都要花大量時間來了解源檔案中的各個元件名稱，使得開發效率不高。是以應該統一命名規範。

通常使用的命名規範為：若該元件為影片剪輯，應以能代表該影片剪輯的英文或中文拼音為名，後面加_mc，代表MovieClip。例如建立一個圓，則有circle_mc，若該元件為一按鈕，則後面應加_btn，若為位圖或者其他圖檔形式，個人覺得應以_bmp或者_pic作為代表。這樣整個圖庫就清晰明了了，使得開發中的每個都能了解大家的元件，也較容易防止重複命名。

（2）       檔案夾命名與管理：

因為在多人開發中，每個人都會有自己的工作，如果分工仔細，每個人制作一個頁面，再用loadmovie等形式加載調用，這樣開發起來相對獨立，則檔案夾是否嚴格命名，甚至是否使用檔案夾，則可以由個人喜好決定。但如果是多人同時開發相同的源檔案中的内容，則檔案夾就顯得格外重要。這樣的圖庫容易管理，每個人開發負責的那一部分工作後，隻要把圖庫中的檔案夾覆寫到需要彙總的源檔案中，即可重新彙總檔案。在多人開發中，則應以個人的編号或者英文等可以辨別不同人的标志來命名根目錄檔案夾的名字，而根目錄下的檔案夾則以其負責的工作的具體内容決定。但最好在後面加上_xxx，代表該開發者的資訊，這樣就可以防止檔案夾的重複命名。

（3）       層的命名：

每一層都應以其相應的内容進行命名。許多人為了友善一時，在開發時都使用預設的層命名，例如layer1、layer2或者圖層1、圖層2等等，等到需要修改的時候，對着幾十甚至上百個圖層，那時候才知道圖層命名的重要性。若圖層非常多的時候，也應該使用檔案夾包含其相關内容，在需要尋找的時候，友善快捷。此外，現在的FLASH許多都用到AS和LABEL，是以應該建立專門的圖層來存放AS和LABEL。LBAEL應該置于最上層，AS層其後。友善查找使用。

2、  編碼規範

在FLASH中，許多的特效、資料傳輸、接收都與Actionscript密不可分。而使用AS來代替圖形MC來實作一些功能，也是減少FLASH體積的好辦法。許多美工使用AS的時候，隻知道随便用些gotoAndPlay()、paly()、stop()等等簡單的指令。是以不需要AS編碼規範。但若開發的是FLASH的RIA使用到許多的AS，此時，編碼規範就顯得非常重要。

           FLASH AS1.1和AS2.0的文法與JS相同，是以變量的定義也相同，即不是強類型的定義，當然也可以在定義的時候就定義了該變量的類型，這是一個好習慣，也應該推薦，而不是求一時的友善，随便的一個var i，這樣到要查錯的時候，要查找出問題就不是一件容易的事情了。而AS3.0的文法，因為較接近JAVA與.NET的文法，看起來比較嚴謹規範。由于大部分的編碼規範與其他程式設計語言的規範基本相似，是以隻說不同的部分。衆所周知，FLASH中可以在按鈕、影片剪輯中編寫代碼，也可以在時間軸中編寫代碼。個人覺得應該在時間軸上編寫代碼，而并非在相關的元件中。因為當開發的項目較大時，使用較多的元件，若在每個元件中都添加那麼十來行代碼，到修改或有錯誤的時候，想修改或查錯，那是一件很痛苦的事情。若每個元件都給執行個體命名，把該元件需要的代碼放在時間軸上統一管理，那麼哪裡需要修改就一目了然，哪裡出現錯誤也比較容易發現。另外一個需要注意的是，一些特效使用到事件觸發之後，就跳到特定的幀數。這種情況應該在時間軸上加一個名為LABEL的層，而不是在代碼中寫跳到具體的哪一幀。例如：gotoAndPlay(30),30是一個特定的幀數，則在LABEL層的第30幀上插入空關鍵幀，在該幀加入标簽here，代碼應該改為gotoAndPlay(“here”)則若以後修改的時候，就不必要修改具體的幀數，隻用把LABEL相應的幀數标簽拖動到相關的幀就可以。

此外，需要注意的是AS程式員應該使用統一的AS文法，而不是一些使用1.1的，一些使用2.0的，更有些使用3.0的。

3、多人開發的分工與頁面分布

随着項目的功能增多，多人開發勢在必行，然而多人開發卻又需要解決許多問題。例如：任務配置設定。如何更好地結合美工和AS程式員之間的工作。使得他們各有所做，不用浪費各自的時間來等待他人的工作。根據本學期的幾個項目總結了一下多人開發時候應該注意的問題。

（1）       網站方面：

①分工問題：

由于FLASH需要炫麗的畫面，是以優秀的美工一定不可以少，但美工又大多隻懂得簡單的AS，而項目中許多的功能卻需要AS來實作。是以美工與AS程式員必須分工。但有可能出現美工制作界面的時候，AS程式員則什麼都幹不了，隻能等美工完成了界面之後，才能進行AS的添加及效果的實作。這樣一來會使影響開發效率。個人想法為利用時間差來互補各自的工作。

當項目需要與外部資料進行互動的時候，美工應該盡快把界面完成，與此同時，AS程式員則應該把與外界的互動部分的代碼實作，并利用一些測試的方法測試代碼實作的功能是否符合要求，有無錯誤等等。而負責與資料庫端的操作的程式員也應該開始工作，完成與FLASH傳輸的接口等程式的代碼。當美工完成一部分界面之後，AS程式員就可以接着美工的界面進行AS加工，完成相關的功能，此時各人員的工作基本可以同步進行。

②各頁面的分布結構：

在整個網站的設計的時候，就應該分拆頁面，把每個頁面都獨立地表現為一個FLASH，這樣既可以分散檔案體積，又可以友善各個人員的開發，當美工完成一個頁面之後，AS程式員就可以開始進行AS加工，美工則繼續下一頁面的設計。這樣的工作順序，不需要等待工作，而且頁面出現了什麼問題，都隻是該頁面有問題，不會影響其他頁面的工作。減少互相之間的影響。

③源檔案出現問題時：

由于上述兩點，是以每個頁面之間是沒有太大的關聯，一旦檔案有什麼問題的話，可以隻處理該問題檔案，但是也要協調美工與AS程式員之間的關系。美工可以沒有AS的源檔案，AS程式員應該有一份完整的源檔案，如果是美工方面出了問題，美工和AS程式員都擁有各自的源檔案，這樣美工修改部分元件的同時，AS程式員可以繼續他的工作。等到美工完成修改之後，AS程式員隻需把沒有删改過的圖庫中的檔案覆寫美工的那份源檔案中圖庫的相應檔案即可。如果問題出在了AS程式員上，就比較麻煩，如果要改的AS地方比較多，美工在此其間可以選擇繼續其他頁面的工作，如果比較少，則可以AS程式員修改完成後繼續頁面的設計。

④源檔案彙總：

個人覺得應該交給AS程式員來彙總，因為美工的繪畫不會對程式有影響，但是如果交由不懂AS的美工來彙總，很容易删錯代碼，這樣修改的工作就會比較多，是以選擇AS程式員來彙總會比較好。

（2）       應用型程式

作為類似C/S模式的應用程式類型的項目，由于該類型對美工要求并不高，更注重的是實效性，則分工應以功能劃分，即不同的人員配置設定不同的子產品，生成不同的子頁面，再由main頁面調用。

4、  減少FLASH體積問題：

FLASH相對于AJAX，個人覺得FLASH體積相對較大，是以如何優化減少其體積是很重要的。

①拆分FLASH

如果用一個FLASH開發整個網站，其體積可能達到大大的幾百K，甚至上M，若能把它拆分為N個小子產品，則體積分成了N份，最初顯示可能隻是幾K或者幾十K的架構，其餘部分都加載該架構中，當然這裡涉及了使用者界面是否友好的問題。

②FLASH中圖檔文字的使用

如果FLASH中包含了許多的位圖，則将使FLASH體積大好幾倍，但未必每張位圖都必須包含進FLASH中的，例如一些可以用FLASH的鋼筆功能描繪出來的圖檔畫面，則可以先導入位圖，描繪出來之後，就把位圖删除，整個FLASH隻包含特殊的圖檔，而一些在FLASH中打入的特殊字型則應把它打散來存放。

③應該在外部導入資料

網站中有圖檔浏覽等功能。此時的FLASH使用到的圖檔等資料就應該在外面導入，而不應該将其包含在FLASH中，這樣做一來可以減少FLASH檔案的體積，二來可以友善更新維護。是以把這些資料和圖檔放在外部非常必要。當然，也涉及到界面友好的問題。但需要注意外導檔案資料存在的一些問題。例如：網站應使用常用的字型，如果用了特殊字型，則外導資料顯示的仍然是預設字型，除非把該特殊字型包含進FLASH中，但是這樣一來FLASH體積又會變大好幾倍，要慎用。還需要注意中文亂碼問題。

④遮罩的使用

如果使用圖層和遮罩層來實作遮罩效果，其FLASH體積會較使用AS的setmask()的FLASH體積大些，并且這種遮罩對于外部導入的資料顯示不起作用。解決方法是在該被遮罩層中使用濾鏡。選擇濾鏡中的一種效果，例如模糊，但要把其參數設定到與沒有使用遮罩相同即可。但使用setmask()則不會出現這種情況。

5、  界面是否友好的問題：

如何才能使得界面看起來較友好，除了通常知道的就是客戶回報中得到的了。在FLASH體積較大的時候，應該在每個FLASH子頁面都加入LOADING進度條之類的東西，告訴你的訪客，頁面是沒有加載完，在等待中，而不是出現了其他的問題。LOADING還可以制作成一些小遊戲之類的，讓加載檔案不需要這麼煩悶。在加載圖檔的時候也應該加入LAODING，圖檔加載完成後，應該有一個漸變的過程，這樣會讓人覺得比較适應。還有就是加載視訊以及音樂的時候，也應該有相應的LOADING，道理是一樣的。