第一篇：unity開發(fā)游戲的優(yōu)缺點

Unity做游戲的幾個優(yōu)勢：

1、跨平臺，平臺相關(guān)的功能Unity都已經(jīng)幫你實現(xiàn)好了。即便有些Unity沒有實現(xiàn)，也有插件幫你實現(xiàn)。

2、基于Unity的酷炫的粒子光效編輯。Unity本身就是一個功能強大的粒子編輯器。之前我還認為cocos2d-x的粒子系統(tǒng)的功能足夠了，但是跟專業(yè)的編輯器比起來，遠遠不夠。粒子系統(tǒng)要跟粒子特效編輯器配合起來，其功能遠遠不是之配置一個粒子系統(tǒng)的幾個參數(shù)就可以的。cocos2d-x本身的粒子系統(tǒng)是很雞肋的功能，只能拿來做一些簡單的光效，不可能用來做復雜的技能特效。

3、由于框架和架構(gòu)的優(yōu)勢，Unity的游戲可以極大程度避免崩潰和閃退。由于代碼都是c#寫的，并且是組件結(jié)構(gòu)，所以即便出了錯誤也只是個異常而已，而不會影響到系統(tǒng)流程。

4、強大的性能分析工具，可以輕易的找到內(nèi)存和cpu的瓶頸。支持Android和iOS的真機運行分析。

5、編輯器可以方便的進行擴展，不需要像傳統(tǒng)游戲公司一樣，有一個專門寫編輯器的部門。無論是場景編輯器還是技能編輯器都可以輕松搞定。如果想玩高科技的話，還可以把技能編輯器做成可拖拽的模塊化結(jié)構(gòu)，策劃可以像搭積木一樣來編輯技能。最重要的是，這些都是所見即所得的。

6、方便的資源管理系統(tǒng)。使用Unity，你不用特意維護幾份資源（比如原始資源、打包后的資源、iOS版本資源、Android版本資源等等），只要一份資源，然后Unity里面可以設(shè)置它的具體參數(shù)，比如使用紋理壓縮、最大限制在512x512大小等等。Unity發(fā)布游戲的時候會自動根據(jù)平臺相關(guān)的導出選項導出正確的資源。

7、豐富的插件。有大量的功能我無論拿cocos2d-x還是Unity都不知道怎么實現(xiàn)。比如一些shader特效、物件碎裂的特效、場景破壞和變形的特效等等，這些在Unity插件中都可以找到對應(yīng)的實現(xiàn)。而且很多Unity的游戲都可以反編譯，無形中又可以學到很多東西。

8、熟悉之后確實感覺Unity很簡單。很多功能都是成體系的自然而然的。比如物理、碰撞檢測、導航尋路、場景管理、場景烘焙。這些無論拿哪個出來都是相當有技術(shù)的功能，但是在Unity中幾個按鈕、幾步操作就可以實現(xiàn)對應(yīng)的功能。

至于缺點也有一些：

1、最主要的，無論是Unity還是插件都是要收費的。（破解版，等賺錢了再考慮回饋）

2、由于iOS平臺的一些限制，Unity很難做動態(tài)代碼更新。而cocos2d-x有l(wèi)ua這個比較成熟的方案。（如果程序穩(wěn)定了，需要頻繁更新代碼的機會不多，更多的是更新配置和資源）

3、可能有些人不熟悉Unity，從而選擇了開源的cocos2d-x。適應(yīng)Unity的框架、工作方式需要一定的時間。（相信我，不會很長，要知道一個8歲的孩子都能拿Unity來做游戲，并且上架，如果有程序員說搞不定Unity，那干脆轉(zhuǎn)行賣燒餅吧）

4、對應(yīng)上面的第6點，由于Unity中資源對應(yīng)的配置有很大的重要性，所以一個Unity功能就是資源+代碼的整合，你很難分出一個資源包。這樣你的Unity項目可能很大。（使用AssetsBundle打包后可能避免這個問題，但是項目初期資源變動大，經(jīng)常打包很不方便）

5、Unity很多設(shè)計都是為可視化編輯考慮的，舉個例子，2D的動畫可以方便的拖幾張圖片就可以搞定。但是如果我每張圖片都有一定的偏移，那就麻煩了，需要自己重新實現(xiàn)幀動畫功能，自己加載配置文件來實現(xiàn)。（這個嚴格說來不是引擎的問題，畢竟引擎不是為了一家游戲公司設(shè)計的，大眾化的簡易的操作方式是唯一需要考慮的。但是很多時候確實感覺有些不爽）

第二篇：IT部開發(fā)優(yōu)缺點分析

ＩＴ部內(nèi)部開發(fā)的優(yōu)缺點對比

優(yōu)點：

1內(nèi)部溝通；內(nèi)部員工溝通比較方便，順暢；

2熟悉公司業(yè)務(wù)情況；內(nèi)部開發(fā)IT部開發(fā)人員較為熟悉公司業(yè)務(wù)情況，能夠減少調(diào)研時間；

3持續(xù)優(yōu)化方便；知根知底的工作，如果業(yè)務(wù)或者管理模式發(fā)生變化，那么公司可以較好的應(yīng)對這些變化；

4核心數(shù)據(jù)和架構(gòu)不受牽制于其他企業(yè)，易整合；

缺點：

1IT部開發(fā)人員較少，項目任務(wù)較多；開發(fā)進度較為緩慢，影響進度；

2缺少制度化管理；內(nèi)部做需求管理，由于沒有設(shè)計到精確的成本計算，所以用戶會輕易不停的修改需求，產(chǎn)生無數(shù)變更，這明顯會使項目周期延長；

3工作繁忙，技能培訓較少：IT部工作量大，內(nèi)部人員經(jīng)常加班，較少時間能進行技能培訓，接觸到更先進的技術(shù)方便用到工作之中；

4內(nèi)部結(jié)算較為麻煩；流程較多，沒有外部結(jié)算方便；

第三篇：Unity之工作總結(jié)

圖片格式

----------1 DrawCall

-----------2

? 圖片格式：

NGUI生成的圖集的圖片格式是PNG格式，但是無論是什么格式的圖片 Unity都會自己生成一套格式，并且打包的時候不會用文件夾下面的格式，而是Unity自己格式。

如果你用的UITexture 你可以對每一張圖來修改格式，比如顏色數(shù)比較少的圖片可以使用16bit，如果沒有透明，可以使用pvr或者etc 這樣圖片會小很多。如果是UISprite 只要有透明的 就必須使用RGBA32 要不然UI會很難看。

除去 UITextuer和Atlas的圖片之外（因為有透明），其余的貼圖必須是2的冪次方。因為只有2的冪次方圖片，并且沒有透明通道的才會被壓縮。Ios會被壓縮成pvr格式，Andriod會壓縮成etc格式。壓縮之后會小很多。

人物貼圖 場景題圖 特效貼圖 一定要是2的冪次方。

貼圖透明通道分離，壓縮格式設(shè)為ETC/PVRTC 最初我們使用了DXT5作為貼圖壓縮格式，希望能減小貼圖的內(nèi)存占用，但很快發(fā)現(xiàn)移動平臺的顯卡是不支持硬件解壓DXT5的。因此對于一張1024x1024大小的RGBA32貼圖，雖然DXT5可將它從4MB壓縮到1MB，但系統(tǒng)將它送進顯卡之前，會先用CPU在內(nèi)存里將它解壓成4MB的RGBA32格式（軟件解壓），然后再將這4MB送進顯存。于是在這段時間里，這張貼圖就占用了5MB內(nèi)存和4MB顯存；而移動平臺往往沒有獨立顯存，需要從內(nèi)存里摳一塊作為顯存，于是原以為只占1MB內(nèi)存的貼圖實際卻占了9MB！

所有不支持硬件壓縮格式都有相同的問題。解決方案：

現(xiàn)在Andriod硬件最廣泛支持的時Etc ,IOS上支持的時PVRTC。但這兩種格式都是不帶透明（Alpha）通道的，因此我們需要將每張原始貼圖的透明通道分離出來，寫進另一張貼圖的紅色通道里，這兩張?zhí)貓D都采用Etc/Pvrtc壓縮。渲染的時候 將兩張貼圖都送進顯存。同時 我們修改了NGUI的shader 在渲染時第二張貼圖的紅色通道寫入到第一張貼圖的透明通道里恢復原來的顏色：

1.2.3.4.5.6.} fixed4 frag(v2f i): COLOR {

fixed4 col;

col.rgb = tex2D(_MainTex, i.texcoord).rgb;col.a = tex2D(_AlphaTex, i.texcoord).r;return col * i.color;

這樣，一張4MB的1024x1024大小的RGBA32原始貼圖，會被分離并壓縮成兩張0.5MB的ETC/PVRTC貼圖（我們用的是ETC/PVRTC 4 bits）。它們渲染時的內(nèi)存占用則是2x0.5+2x0.5=2MB。

? DrawCall 當兩個renderQueue相鄰的DrawCall使用了相同的貼圖、材質(zhì)和shader實例時，這兩個DrawCall就可以合并。但需要注意的是DrawCall合并不見得會提高性能，有時反而會降低性能

如果是UIGeometry為了渲染繪制準備數(shù)據(jù)，那么UIDrawCall其實是定義了渲染繪制需要的基本組件。這里拿煮菜做個比喻幫助理 解：UIGeometry好比為煮菜準備食材，UIDrawCall好比是煮菜的工具（鍋，爐子等），UIPanel就是大廚了決定著什么時候該煮 菜，UIWidget（UILabel，UISprite和UITexture）是這道菜怎么樣的最終呈現(xiàn)。

UIWidget分別用UpdateGeometry和WriteToBuffers對UIGeometry的ApplyTransform和 WriteToBuffers進行封裝調(diào)用，ApplyTransform是根據(jù)UIPanel的坐標調(diào)整Vertices的坐 標，WriteToBuffers將UIGeometry的Vertices，UVs和Colors添加進UIPanel的Vertices，UVs和 Colors的BetterList中。

這里還有一個細節(jié)就是：UIGeometry中的Vertices，UVs和Colors的BetterList的buffer什么時候得到，因為這些都 是UIWidget或其子類的信息，所以在UIWidget的子類UILabel，UISprite和UITexture中OnFill函數(shù)生成 UIGeometry的BetterList的buffer。

UIWidget這個腳本中的兩個函數(shù)：WriteToBuffers，OnFill，UpdateGeometry。

WriteToBuffers和OnFill這兩個函數(shù)都是將Vertices，UVs和Colors等add進參數(shù)的List中去，查看 WriteToBuffers的調(diào)用出發(fā)現(xiàn)其參數(shù)是UIPanel的Vertices，UVs和Colors，而OnFill的參數(shù)是 UIGeometry的Vertices，UVs和Colors。

WriteToBuffers只是對UIGeometry的封裝調(diào)用，也就是說將UIGeometry的Vertices，UVs和Colors等信息add進UIPanel的對應(yīng)List中。

UIGeometry的腳本，一直有一個疑問：UIGeometry的Vertices，UVs和Colors的List沒有看到add方法的執(zhí)行，只有在WriteToBuffers被add。直到看到了OnFill才恍然大悟，雖然UIWidget的OnFill是虛函數(shù)，沒有具體實現(xiàn)，看了下 UISprite重寫的OnFill函數(shù)，就是把Vertices，UVs和Colors 添加到UIGeometry的Vertices，UVs和Colors中。所有UI組件的Vertices，UVs和Colors都匯集到UIPanel的Vertices，UVs和Colors去了，然后 UIPanel指定給UIDrawCall渲染就行了

UIWidget的一些實現(xiàn)細節(jié)，MakePixelPerfect():對gameObject的localPosition和locaScale進行微調(diào)和糾正。SetDirty():調(diào)用UIPanel的SetDirty()對組件的變更進行重建（rebuilt)。Uiwidge UIGeometry& UIDrawCall 的關(guān)系：

UIWidget 中有兩個變量UiDrawCall mDrawcall 和UIGeometry mGeo 的verts uvs cols 的BetterList,然后UiWidget 的UpdateGeometry函數(shù)對UIGeometry 的ApplyTransform()和WriteToBuffer()調(diào)用進行更新.每一個UIwidget都有一個UIGeometry 但是不都有一個UIDrawCall,而是通過Batch合并達到減少DrawCall的數(shù)量，UiDrawCall是有UiPanel生成的。

DrawCall的數(shù)量優(yōu)化

根據(jù)上述描述可以得出一個結(jié)論：使用相同material的連續(xù)的Uiwidget(UILable UiSprite)公用一個UIDrawcall。通過這個結(jié)論我們可以得到一個解決DrawCall過多的問題，UIPanel生成DrawCall時是Fill()方法。Fill 方法對UiWidget.list進行檢測把使用相同Material的連續(xù)的Uiwidget合并生成一個DrawCall ,UIWidget.List 的排序是根據(jù)UiWidget的Depth進行的。所以解決方案有兩種：

1.修改UiWidget(UiLable UIwidget)的Depth,限定UIwidget.List的排序 2.重寫Uiwidget的CompareFunc()方法。（重寫UIWidget的CompareFunc也是可以的，按照Material的name優(yōu)先排序，只有當material一樣是才考慮depth進行排序：）

3.無重疊時自動重排。繪制順序按照Hierarchy

采用第二種方式減少DrawCall: Material leftMat = left.material;Material rightMat = right.material;if(leftMat == rightMat){ if(left.mDepth < right.mDepth)return-1;else if(left.mDepth > right.mDepth)return 1;else return 0;} if(leftMat!=null & rightMat!= null)return string.Compare(leftMat.name,rightMat.name);if(leftMat!= null)return-1;if(rightMat!= null)return 1;

return(leftMat.GetInstanceID()< rightMat.GetInstanceID())?-1 : 1;

夾層問題：

因為Material使用的Shader使用了透明，這樣就不能做深度測試，也就是Mesh的“深度”是不影響的，這樣最終的顯示就跟Shader的 renderQueue有關(guān)了，即renderQueue越大，顯示的越靠前面（重疊的圖層，renderQueue越大，越靠前）。當然現(xiàn)在只有增加一 個DrawCall（如多使用一個UIPanel或用另外一個Material)來做到Material的夾層效果。

特效層級：

粒子系統(tǒng)的渲染順序列默認為3000 而NGUI的渲染順序默認是從3000開始，當有嵌套的Panel或者Deoth更高的panel時，NGUI的渲染順序會高于3000

解決方案：

1.修改Ngui中的panel腳本中的默認RenderQueue 調(diào)整到3000以下，這樣就不會擋住粒子特效。當窗口顯示在特效上面時把窗口的RenderQueue調(diào)整到3000以上，就解決了。

2.使用另外一個攝像機顯示特效，但是Ui窗口切換時不太好控制

3.修改例子特效的shader中的RenderQueue的值（需要考慮特效中的層級關(guān)系）一級界面 二級界面..浮動窗口

1.不同圖集

項目中做到復雜一些的界面，經(jīng)常會用到多個圖集，以技能界面為例，項目中常用的圖片放到共用圖集中，這是一個圖集，技能界面本身獨有的元素，比如跟技能職業(yè)相關(guān)的背景，算作第二個圖集，還有一些技能圖標，圖標單獨歸類到一個圖集中，再一個就是字體的圖集?；疽粋€界面如此分法，最多需要4個圖集。NGUI的圖集之間的 處理，默認是靠調(diào)整控件的Z值來區(qū)分的，但是這里他可以調(diào)整同一個圖集每個一個控件的Z值，其實不是很好。經(jīng)常會出現(xiàn)圖層相互遮擋的情況，尤其對于控件比較多的界面，一段時間回過來再修改界面的時候，整個要崩潰。

解決方案：在UIPanel中，為每一個Material添加一個layer的變量，當同一圖層靠depth來決定前后關(guān)系，不同圖層靠 layer來決定前后關(guān)系，在繪制UIDrawCall的時候，根據(jù)layer對跟節(jié)點做一定偏移。這樣就能從Z值中解放出來。如果大家也有碰到圖層的問題，可以參考這樣的做法，以此種方法來處理圖層關(guān)系，簡單，做過項目的圈套UI，還未有不能解決的情況。

? UI自適應(yīng)

Scaling Style 的作用是制定UiRoot的縮放類型，如果是PixelPerfect ,Minimum Height 和Maximum Height 才起作用，scaling style 選擇的是

Pixelperfect 要對Minimum Height和Maximum Height進行設(shè)置。(如果是PixelPerfect縮放類型，當屏幕的分辨率大于Maximum Height，則以Maximum Height 為基礎(chǔ)縮放，反之，如果屏幕分辨率小于Minimum Height 則以Minimum Height為基礎(chǔ)進行縮放。例如，如果屏幕高度為1000，而設(shè)置的Maximum Height值為800，則UI界面整體放大為原來的1000/800=1.25倍。)FixedSize : 跟Manual Height有關(guān)

FixedSizeOnMobiles :跟Manual Height有關(guān)

只是針對IOS和Android上的判斷，也就是說只有IOS和Android平臺下FixedSizeOnMobiles才起作用.FixedSize或FixedSizeOnMobiles，則縮放只以Manual Height為參考，屏幕分辨率的高度值不同于此設(shè)置值時，則根據(jù)其比例（即Screen Height / Manual Height）對整棵UI樹的進行“等比”縮放（寬度的縮放比也是此比例值）。

注釋：如果設(shè)置FixedSize,UIWidget.height（以UiRoot默認值進行高度縮放）是不會改變的，不管實際屏幕分辨率的像素是多少，Anchor Stretch的背景圖片高度始終是manualHeight.UIRoot下的UIWidget的height參數(shù)一直都是實際的值

UIRoot 是基于高度進行縮放的如何做以寬度適配。

UIRoot是基于高度放縮的，即放縮的比例是以高度為參考的，所以UIRoot有一個manualHeight的參數(shù)。那么對于橫版游戲顯然不行，要是 能實現(xiàn)基于寬度放縮。所以可以通過設(shè)置一個“manualWidth”的參數(shù)來做。比如我們項目中使用的是 1024 作為UI的寬屏尺寸，通過換算設(shè)置manualHeight的值：

int height = Mathf.Max(2, Screen.height);manualHeight = Screen.height * 1024 / Screen.width;//基于寬度的屏幕分辨率自適應(yīng)

注釋：UIRoot其實就做了一件事情：根據(jù)Screen.height和UIRoot.activeHeight的比例來調(diào)整UIRoot的 loaclScal，從而保證UIWidget（UISprite，UILabel）可以按照其本身的大小進行設(shè)置，而不用經(jīng)過復雜的換算過程。

? 資源分離打包與加載

資源分離打包與加載是最有效的減小安裝包體積與運行時內(nèi)存占用的手段。一般打包粒度越細，這兩個指標就越小。但打包粒度也并不是越細就越好。如果運行時要同時加載大量小bundle，那么加載速度將會非常慢——時間都浪費在協(xié)程之間的調(diào)度和多批次的小I/O上了。此需要有策略地控制打包粒度。一般只分離字體和貼圖這種體積較大的公用資源。

? 關(guān)閉貼圖的讀寫選項

Unity中導入的每張貼圖都有一個啟用可讀可寫（Read/Write Enable）的開關(guān)，對應(yīng)的參數(shù)是TextureImporter.isReadable。選中貼圖后可在Import Setting選項卡中看到這個開關(guān)。只有打開這個開關(guān)才可以對貼圖使用Textuer2D.GetPixel，讀取或改寫貼圖資源的像素，但這就需要系統(tǒng)在內(nèi)存中保留一份貼圖的拷貝，以供Cpu訪問，但是一般游戲運行過程中不會有這樣的需求，因此我們對所有貼圖都關(guān)閉這個開關(guān)，只在中做貼圖導入后處理（比如對原始提貼圖分離透明通道）時需要打開這個選項。這樣，上文提到的1024x1024大小的貼圖，其運行時的2MB內(nèi)存占用又可以少一半，減小到1MB。Texture圖片空間和內(nèi)存占用分析

紋理大小影響：

可以將其他（非二的冪-“NPOT”）紋理大小用于 Unity非二的冪紋理大小通常占用的內(nèi)存稍多一點，由 GPU 進行讀取的速度可能較慢，因此考慮到性能，最好盡可能使用二的冪大小。如果平臺或 GPU 不支持 NPOT 紋理大小，則 Unity 會縮放紋理并將其填補為下一個二的冪大小，這甚至會使用更多內(nèi)存并使加載更慢

Iphone：

空項目

空間占用量42.3M

ipa包10M 10張1200*520 無壓縮Texture 單張圖占用量2.8M

空間占用兩70.2M ipa包 22.9M 10張1200*520壓縮成1024*1024 PVRTC4 單圖占用量0.5M 空間占用量47.3M ipa包 13.2M 10張1024*1024 無壓縮Texture

單圖占用量4M

空間占用量82.M

ipa包14.6M 10張1024*1024壓縮為PVRTVC4格式

單張圖占用量0.5M 空間占用量 47.3M ipa包 11.6M

綜上所述：

1.2的N次方大小的圖片會得到引擎更大的支持，包括壓縮比率，內(nèi)存消耗 打包壓縮大小，而且支持的力度非常大。

2.減小圖片的占用大小和內(nèi)存方式有：圖片大小變化（Maxsize）,色彩位數(shù)變化（16位色 32位色），壓縮PVRC格式

3.U3D對于圖片的格式是自己生成的，而并不是你給它什么它用什么格式。一張1024*1024圖在無壓縮的格式下，他會被U3D無壓縮文件像是存放，也就是說U3D 里的Texture Perview 里顯示的占用大小**M 不只是內(nèi)存占用的大小，還是空間占用大小。

Unity 圖片壓縮格式介紹：

U3D 的內(nèi)部機制為自動生成圖片類型來替代我們的圖片在圖片的壓縮方式需要進行謹慎的選擇。幾種比較主要的壓縮格式：

RGBA32 BIT/AutomaticTurecolor(256*256 256k)

格式為無壓縮最保真格式，最消耗內(nèi)存和空間的格式。RGBA16 BIT/

格式為無壓縮16位格式，比32位節(jié)省一半的空間和內(nèi)存，與Automatic16 相同。RGBA Compressed PVRTC 4bits格式為PVRTC 圖片格式，它相當于把圖片更改了壓縮方式新生成了一個圖片來替換原來的圖片格式

貼圖格式：

3D游戲中貼圖的的分類：

UI貼圖

ui是按照 1280*853比例出的圖

3D場景貼圖 主要是因為多重采樣的緣故。3D游戲一般來說都是受攝像機遠近大小改變而采取不同的采樣大小，如果不設(shè)置多重采樣的話，在遠處有非常多的白色噪點。

2D游戲

所有都不需要勾選多重采樣，具有3D性質(zhì)的貼圖，我們都需要勾選上GENERATE MIP MAPS，這樣會使貼圖大小增加25%這樣。

正方貼圖與非正方貼圖也要區(qū)分: 非正方貼圖只有16位的壓縮（相當于真彩色減半），所以最好游戲中都是正方的貼圖。正方貼圖： IOS：

普通不透明： RGB PVRTC 4 BITS

普通透明： RGBA PVRTC 4 BITS(256*256 32kb)Androis:

普通不透明： RGB ETC 4 BITS(256*256 32kb)

普通透明：因為沒有通用的兼容模式，所以一般情況是用RGBA 16 BITS 或是針對不同的GPU選擇 DXT5/ATC8 BITS/ETC2 8BITS。如果技術(shù)支持，可以采用 RGB ETC 4 BITS 加一張Alpha 8的貼圖來實現(xiàn)透明效果。

非正方形：

一般采用16位壓縮，16位色會帶來顏色損失，如果本來美術(shù)就按16位色畫的話，就不會帶來損失。日本的很多2D游戲都是采用那個16位來畫的。少漸變 和艷色。

不透明貼圖： RGB 16 BIT（256*256 128KB）

透明貼圖： RGBA 16 BIT（256*256 128KB）

高清不壓縮貼圖：

RGBA 32 BIT(256*256 256kb)

對于不重要的貼圖，模糊度低的貼圖，建議不僅要采取像素壓縮，還要直接壓縮其大小。如光照貼圖壓到512或256。如背景原本1024的圖直接壓到256。玩家不注意到就可以了。

注意：

U3D所有圖片的壓縮格式都會以另一種方式存儲，不會以你給的方式存儲，只有你指定了某種格式，他才會轉(zhuǎn)換成你要的格式。而且在Andriod 里的并不一定有效，因為Andriod的機型多，GPU的渲染方式也不一樣，RGBA16 適應(yīng)于所有機型

? GameObject數(shù)量

場景中GameObject的數(shù)量也是衡量性能的重要指標，頻繁的創(chuàng)建 和銷毀GameObjec 是非常耗時，場景中存在的GameObject會占用內(nèi)存，如果GameObject上掛有物體的話，每個GameOject的腳本都需要實力化。

? 整理圖集

整理圖集的主要目的是節(jié)省運行時內(nèi)存（雖然有時也能起到合并DrawCall的作用）。從這個角度講，顯示一個界面時送進顯存的圖集尺寸之和是越小越好。一般有如下方法可以幫助我們做到這點： 1)在界面設(shè)計上，盡量讓美術(shù)控件設(shè)計成九宮格拉伸，即UiSprite的類型是Sliced.這樣美術(shù)素材可以切出一張很小的圖片在unity中做拉伸。當然一個九宮格也就意味著其定點數(shù)量會從4個增加到16個（如果九宮格的中心格子采用Tiled做平鋪類型的話，定點數(shù)會更多），構(gòu)建DrawCall的開銷會更大。但一般只要DrawCall安排合理就不會出問題 2)同樣在界面設(shè)計上 盡量設(shè)計成對稱的形式，這樣在切圖的時候美術(shù)切圖的時候就可以只切一部分，我們在Untiy中將完整的圖案拼出來，比如一個圓形圖案我們可以只切四分之一，不過與上述第一點類似這樣會增加定點個數(shù)，同時也會增加場景中GameObject的個數(shù)，因為GameObject的數(shù)量增多時會占用跟多的內(nèi)存，所以只對尺寸較大的圖案采用這種方法。3)4)確保不要讓不必要的貼圖素材駐留內(nèi)存，更不要在渲染時將無關(guān)的貼圖素材送進顯存。為此需要將圖集按照界面分開，按模塊劃分圖集，一個界面中的UISprite也不要使用別的界面的圖集。數(shù)量龐大 且數(shù)量不固定的物品不要使用圖集 要采用UITexture 減少圖集中的空白地方。完全透明的像素和不透明的像素所占用的空間是一樣的，因此在像素量不變的情況下，要盡量減少圖集中的空白。比如有時一張1024x1024的圖集中，素材所占的面積還沒超過一半，這時可以考慮將這張圖集切成兩張512x512的圖集。（可能有人會問為什么不能做成一張1024x512的圖集，這是因為iOS平臺似乎要求送進顯存的貼圖一定是方形。）當然，兩張不同圖集的DrawCall是無法合并的，但這并不是什么問題。5)

? 根據(jù)各個UI控件的設(shè)計安放Panle,隔開DrawCall 在合并DrawCall時需要注意，如果將會移動變化的UI控件和一個靜止不變的UI控件的DrawCall合在一起，當其中一個UI控件（UiWeight）的位置 大小 或顏色等屬性發(fā)生變化時，UIPanle就需要重建這個Panle上的所有DrawCall。有時重建一個DrawCall會消耗不少的CPU，它需要計算這個DrawCall上的所有頂點信息，包括頂點位置 UV和顏色等，如果很多的控件都集中在同一個DrawCall上，那么其中一個控件上有一點點變化，這個DrawCall上的所有的頂點就都需要遍歷一遍。而如果我們的UI又大量的采用九宮格拉伸，使控件的頂點數(shù)量就會變得更多。因此重建一個DrawCall 的開銷會更大。

因此需要將UI控件分組，將一段時間內(nèi)會發(fā)生變化的控件----比如怪物頭頂?shù)难獥l和傷害跳字放在同一個Panle上，并且這些Panle上只有這些控件，其余基本不變的控件放在別的控件Panle上，這樣兩類控件就隔開到不同的DrawCall在不同的Panle中，當一個控件發(fā)生變化而導致DrawCall重建時，就不需要遍歷那些沒有變化的控件。因為在美術(shù)設(shè)計上，一段時間內(nèi)在變化的控件總是少數(shù)，所以優(yōu)化效果十分明顯，節(jié)省的CPU占用率能達到25%。

?

優(yōu)化錨點內(nèi)部邏輯，使其只在必要時更新

在上一點優(yōu)化了Panel的DrawCall重建效率之后，我們發(fā)現(xiàn)NGUI錨點自身的更新邏輯也會消耗不少CPU開銷。即使是在控件靜止不動的情況下，控件的錨點也會每幀更新（見UIWidget.OnUpdate函數(shù)），而且它的更新是遞歸式的，使CPU占用率更高。因此我們修改了NGUI的內(nèi)部代碼，使錨點只在必要時更新。一般只在控件初始化和屏幕大小發(fā)生變化時更新即可。不過這個優(yōu)化的代價是控件的頂點位置發(fā)生變化的時候（比如控件在運動，或控件大小改變等），上層邏輯需要自己負責更新錨點。

?

降低貼圖分辨率

這一招說白了其實就是減小貼圖素材的尺寸。比如對一張在原畫里尺寸是100x80的貼圖，我們將它導入Unity后會把它縮小到50x40，即縮小兩倍。游戲?qū)嶋H使用的是縮小后的貼圖。不過這一招是必然會顯著降低美術(shù)品質(zhì)的，美術(shù)立馬會發(fā)現(xiàn)畫面變得更模糊，因此一般不到程序撐不住的時候不會采用。

? 界面的延遲加載和定時卸載

如果一些界面的重要性較低，并且不常被使用，可以等到界面需要打開顯示的時候才從bundle加載資源，并且在關(guān)閉時將自己卸載出內(nèi)存，或者等過一段時間再卸載。不過這個方法有兩個代價：一是會影響體驗，玩家要求打開界面時，界面的顯示會有延遲；二是更容易出bug，上層寫邏輯時要考慮異步情況，當程序員要訪問一個界面時，這個界面未必會在內(nèi)存里。因此目前為止我們?nèi)晕磳嵤┰摲桨?。目前只是進入一個新場景時，卸載上一個場景用到但新場景不會用到的界面。

? 避免頻繁調(diào)用GameObject.SetActive 我們游戲的某些邏輯會在一幀內(nèi)頻繁調(diào)用GameObject.SetActive，顯示或隱藏一些對象，數(shù)量達到一百多次之多。這類操作的CPU開銷很大（尤其是NGUI的UIWidget在激活的時候會做很多初始化工作），而且會觸發(fā)大量GC。后來我們改變了顯示和隱藏對象的方法——讓對象一直保持激活狀態(tài)（activeInHierarchy為true），而原來的SetActive(false)改為將對象移到屏幕外，SetActive(true)改為將對象移回屏幕內(nèi)。這樣性能就好多了。

?

NGUI性能消耗點匯總

使用LinkedList 代替BetterList。

BetterList是一個數(shù)組 LinkedList是一個鏈表。對鏈表的操作要快于對數(shù)組的操作。

NGUI節(jié)點查找非常耗時。

?

代碼中非必要的堆分配

1)

我們應(yīng)避免使用foreach循環(huán) ：一般建議是避免使用foreach循環(huán)，盡量使用for或者while循環(huán)，我在Unity論壇遇到很多人提到這個建議。這背后的原因咋一看似乎是合理的，foreach只是語法封裝，因為編譯器處理代碼的流程大體是下面這樣：

foreach（SomeType s in someList）s.DoSomething（）;轉(zhuǎn)換為：

using（SomeType.Enumerator enumerator = this.someList.GetEnumerator（））{

while（enumerator.MoveNext（））{

SomeType s =（SomeType）enumerator.Current;s.DoSomething（）;} } 每次使用foreach時 都會創(chuàng)建一個enumerator 對象，一個System.Collections.IEnumerator的接口實例。但是創(chuàng)建在堆棧上還是堆上是都可能的 幾乎所有的System.Collections.Genric(list Dictionary, LinkedList)命名空間中的集合類型都可以從GetEnumerateor函數(shù)執(zhí)行一個結(jié)構(gòu)。

2)應(yīng)該避免使用閉包和LINQ嗎？

匿名方法和lambda表達式會引起內(nèi)存泄露嗎？答案是：這取決于C#編譯器，有兩種區(qū)別很大的方式來處理

int result = 0;void Update（）{

for（int i = 0;i < 100;i++）{

System.Func myFunc =(p)=> p * p;result += myFunc（i）;} } 如你所見，以上代碼似乎每幀要創(chuàng)建100次委托函數(shù)myFunc，每次調(diào)用它執(zhí)行一次計算。但是Mono只在第一次調(diào)用Update()方法時分配堆內(nèi)存(在我的系統(tǒng)上只用了52字節(jié))，在之后的幀也沒有更多的堆分配操作。這是怎么了？使用代碼反編譯器（將會在下篇文章解釋）可以看見C#編譯器只是簡單的把myFunc 替換為類的一個靜態(tài)System.Func 類型字段，包括 Update()函數(shù)也是。這個字段的名字很奇怪但是也有一些意義：f__am$cache1（不同系統(tǒng)上可能會有差別），也就是說，托管方法只分配一次，然后就被緩存了

現(xiàn)在我們在托管定義方式上做一些小小的改變：

System.Func myFunc =(p)=> p * i++;

通過把“p”替換為“i++”，我們已經(jīng)局部定義方法轉(zhuǎn)變成一個真的閉包（閉包是函數(shù)編程的一大支柱。它把數(shù)據(jù)和函數(shù)聯(lián)系到一起，更準確的說是非局部變量在函數(shù)之外定義。）在myFunc中，p是一個局部變量但i是一個非局部變量，屬于Update()方法。C#編譯器現(xiàn)在不得不將myFunc轉(zhuǎn)換成可訪問、甚至是可修改，包含非局部變量的方法。它通過聲明一個全新的類表示myFunc創(chuàng)建的引用來實現(xiàn)這一功能。For循環(huán)每次執(zhí)行都要分配一個類的實例，瞬間產(chǎn)生大量的內(nèi)存泄露（在我的電腦上每幀26KB）閉包概念在C#3.0 的時候被引入主要原因是LINQ。如果閉包回引起內(nèi)存泄露

3)協(xié)程

通過StartCoroutine()運行一個協(xié)程，會隱式分配Unity Coroutine類（系統(tǒng)上占用21字節(jié)）和Enumerator(占用16個字節(jié))，所以在游戲運行時盡量少用StartCoroutine()

4)字符串

C#和Unity內(nèi)存問題必須會提到字符串。從內(nèi)存角度，字符串很奇怪，因為，他們是堆分配且不變的。當你連接兩個字符串時（無論是變量還是常量）：運行時不得不分配至少一個新的字符串對象存儲新的結(jié)果。String.Concat()有效地通過調(diào)用FastAllocateString()分配新對象，但是必定會產(chǎn)生多余的堆分配（上面例子在我的系統(tǒng)上占用40字節(jié)）。如果你需要在運行時修改或者連接字符串，最好使用 System.Text.StringBuilder

5)裝箱

盡量減少裝箱

6)庫方法

各種庫方法也會隱式分配內(nèi)存。捕捉它們最好的方法是分析。我之前已經(jīng)寫過的 foreach-循環(huán)，大多數(shù)標準泛型集合不會導致堆分配。Dictionary 也是。然而，有點神秘地，Dictionary .KeyCollection和Dictionary .ValueCollection是類，不是結(jié)構(gòu)體，這意味著“foreach(K key in myDict.Keys)......”會分配16個字節(jié)。

? 查找堆分配的兩種方式 1.使用Unity profiler 2.反編譯自己的代碼

在CIL中查找內(nèi)存分配

CIL代碼的優(yōu)勢在于堆分配代碼不會被隱藏。相反，完全可以在反編譯的代碼中找到堆分配的三種指令。

1)

newobj ：通過構(gòu)造函數(shù)創(chuàng)建一個指定類型的未初始化對象。如果對象是值類型（結(jié)構(gòu)體等），則在堆棧創(chuàng)建。如果是引用類型（類等）則在堆上分配。可以從CIL代碼知道對象類型，所以，可以很容易知道在哪分配。

2)

newarr <元素類型>：在堆上創(chuàng)建一個數(shù)組。元素類型在參數(shù)中指定。

3)

box <值類型標記>：裝箱（傳遞數(shù)據(jù)）專用指令，在第一部分已經(jīng)介紹過。

? Unity腳本執(zhí)行順序和編譯順序 1)腳本執(zhí)行順序

Unity 在后臺會把每個腳本的 Awake、Start、Update、LateUpdate、FixedUpdate 等等，所有的方法合并到一起。然后按照 代碼的執(zhí)行順序進行執(zhí)行。

編譯順序

? 首先從腳本語言類型來看，Unity3d支持3種腳本語言，都會被編譯成CLI的DLL 如果項目中包含有C#腳本，那么Unity3d會產(chǎn)生以Assembly-CSharp為前綴的工程，名字中包含”vs”的是產(chǎn)生給Vistual Studio使用的，不包含”vs”的是產(chǎn)生給MonoDevelop使用的。

? 對于每一種腳本語言，根據(jù)腳本放置的位置(其實也部分根據(jù)腳本的作用，比如編輯器擴展腳本，就必須放在Editor文件夾下)，Unity會生成4中后綴的工程。其中的firstpass表示先編譯，Editor表示放在Editor文件夾下的腳本。

Assembly-CSharp-filepass-vs.csproj Assembly-CSharp-Editor-filepass-vs.csproj Assembly-CSharp-vs.csproj Assembly-CSharp-Editor-vs.csproj 根據(jù)官方的解釋，它們的編譯順序如下：

(1)所有在Standard Assets、Pro Standard Assets或者Plugins文件夾中的腳本會產(chǎn)生一個Assembly-CSharp-filepass-vs.csproj文件，并且先編譯；

(2)所有在Standard Assets/Editor、Pro Standard Assets/Editor或者Plugins/Editor文件夾中的腳本產(chǎn)生Assembly-CSharp-Editor-filepass-vs.csproj工程文件，接著編譯；

(3)所有在Assets/Editor外面的，并且不在(1),(2)中的腳本文件(一般這些腳本就是我們自己寫的非編輯器擴展腳本)會產(chǎn)生Assembly-CSharp-vs.csproj工程文件，被編譯；

(4)所有在Assets/Editor中的腳本產(chǎn)生一個Assembly-CSharp-Editor-vs.csproj工程文件，被編譯。

之所以按照這樣建立工程并按此順序編譯，也是因為DLL間存在的依賴關(guān)系所決定的。好了，到此為止，我們可以很容易地判斷出上面舉的實例中，腳本的編譯順序(實際上，我已經(jīng)把順序?qū)懺诹四_本的文件名中了)一個Unity3d的工程中，最多可以產(chǎn)生多少個工程文件呢？

4*3*2=24

4個文件 3中編譯器 2種平臺 1 個工程

? IOS平臺崩潰的幾種情況。

1．在協(xié)程中要判斷對象是不是為空(list GameObject)在每次調(diào)用的時候都學要調(diào)用（因 為協(xié)程不能保證即使調(diào)用如果對象已銷毀但是依然使用時會卡死）。

2． Delegate的判斷（IOS 盡量使Event）

3． 如果引用靜態(tài)的static Compent的組件會出現(xiàn)卡死

4． Unity中的OnEnable Start Awake Disable Destory()都回延遲一幀 5． Unity在Ios對反射的支持不完整。

6． Awake 和Start函數(shù)執(zhí)行時機, Awake 函數(shù)在這個腳本在場景中加載時就會調(diào)用，需要注意的是，Start函數(shù)也不是一定立即執(zhí)行的，它是在該腳本第一次調(diào)用Update函數(shù)之前調(diào)用的，也就是說，如果這個腳本一開始的狀態(tài)是disable的，那么直到它變成enable狀態(tài)，在Update函數(shù)第一次執(zhí)行前，才會執(zhí)行Start函數(shù)。

7．Linq TO XML

untiy中配置文件需要注意的點：

pc端不區(qū)分文件大小寫。

Andriod不區(qū)分大小寫

Ios移動端區(qū)分文件大小寫。

需要注意文件名稱大小寫。

? 資源優(yōu)化(內(nèi)存優(yōu)化)：

1．代碼中申請的內(nèi)存，一般是New 或者Instantiate操作 Instantiate中也是調(diào)用了New 2．及時設(shè)置釋放標識符 變量設(shè)置為Null 超出變量作用域 Destory()3．及時Gc釋放內(nèi)存 需要注意

Gc時會造成游戲短時間的卡頓，影響游戲體驗 需要選擇合適的時間Gc 4．盡可能的重用資源（貼圖 材質(zhì) 網(wǎng)格）

5．一般圖片資源占用的內(nèi)存最大，優(yōu)化效果最明顯（降低貼圖分辨率，在效果和大小之間找一個平橫點）

6．程序中的內(nèi)存池 對象池 必要時主動釋放內(nèi)存

7．做AssetBundle資源的關(guān)系以來打包 動態(tài)加載

卸載

8．C#中Struct數(shù)據(jù)在棧上 Class在堆上 局部數(shù)據(jù)盡量用Struct 減少Gc的頻率 9．按C++ 的思想來管理內(nèi)存，比如使用的內(nèi)存池，對象池 手工卸載 主動Gc 注意在內(nèi)存和幀率之間做好平衡。

10．www 下載時需要注意變量聲明和要注意申請的內(nèi)存堆上的無用內(nèi)存

11．? Unity資源（加載/更新）

1.Resources

-打包集成到.asset文件里面及引用的資源as后se一個文件里面面可讀不可寫無

-只能用WWW類下載

StreamingAssets文件夾也是一個只讀的文件夾，但是它和Resources有點區(qū)別，Resources文件夾下的資源會進行一次壓縮，而且也會加密，不使用點特殊辦法是拿不到原始資源的。但是StreamingAssets文件夾就不一樣了，它下面的所有資源不會被加密，然后是原封不動的打包到發(fā)布包中，這樣很容易就拿到 里面的文件。所以StreamingAssets適合放一些二進制文件，而Resources更適合放一些GameObject和Object文件。StreamingAssets 只能用過www類來讀取。

最后凡是在Hierarchy視圖對象引用過的資源文件也會被無條件打包到發(fā)布包中。如果有一部分文件可能沒有在Resources文件 夾下也沒有在StreamingAssets文件夾下，也沒有被Hierarchy視圖游戲?qū)ο笠茫敲催@類資源是不會被打包到發(fā)布包中的。

3.PersistentDataPath無

-清除手機緩存文件會一并清理這里的東西

-隨意弄，可作為本地目錄讓WWW下載、也可以自己用FileInfo亂整

4.WWW.LoadFromCacheOrDownload

?

Unity常用目錄對應(yīng)的Android && iOS平臺地址

IOS:

Application.dataPath : Application/xxxxx/xxx.app/Data Application.streamingAssetsPath : Application/xxxxx/xxx.app/Data/Raw Application.persistentDataPath : Application/xxxxx/Documents Application.temporaryCachePath : Application/xxxxx/Library/Caches

Android:

Application.dataPath : /data/app/xxx.xxx.xxx.apk Application.streamingAssetsPath : jar:file:///data/app/xxx.xxx.xxx.apk/!/assets Application.persistentDataPath : /data/data/xxx.xxx.xxx/files Application.temporaryCachePath : /data/data/xxx.xxx.xxx/cache

? Unity的Android和IOS上相關(guān)的目錄結(jié)構(gòu)

Android:

-assets 游戲內(nèi)容相關(guān)的都在這里了res 圖標之類的

-AndroidManifest.xml Android配置文件resources.arsc Java編譯后的二進制文件

IOS:

-level0/level1… Scene

-sharedassets0/shaedassets1/… Scene相關(guān)的東西resources.assets Resources里面的東西-Raw StreamingAssets里面的東西

第四篇：Hamlet --- The unity of controverasal

Hamlet

---The combination of contradiction

As the saying goes, one thousand readers, there are one thousand Hamlets.Others may think he is a soldier, a hero or a thinker.However, in my mind, he is an immature teen-age youth who is the combination of contradictions.Firstly, as a prince, he is an idealist.He lives a luxurious life and is educated by humanism.Without knowing the dark aspects of the society, he is favored by his parents and respected by his people.We can see in the play that he believes the true, the good and the beautiful and he is a real perfectionist, which can also explain why he is so shocked by the things happen on him and doesn’t know how to deal with it perfectly.Experiencing the death of his father, the usurping the throne of his uncle and the remarriage of his mother, Hamlet’s dream turns into bubbles.He falls in to hell from the heaven and goes on the trip of revenge.The prince has to have common people’s feeling, sadness, hatred, disappointment, hypocrisy and so on.Secondly, he is definitely a great thinker but also an ordinary people who hesitates to practice his thought.He begins consider himself and his people after he listen to his dead Father King’s words.He even says “To be or not to be, this is a question: was bear the slings and arrows of outrageous fortune, or to take arms against a sea of troubles world, through the clearing their struggle, these two kinds of behavior, which is a more noble.” He falls in to deep thought and condemns himself.His father is murdered and the ghost of his father urges him to take the revenge.He doesn’t do anything.He wonders: how a coward or a indecent woman I am.He not only thinks of his own fate, but also considers everyone’s existence.There is no doubt that he is the great man of mind.“Now I clearly have reason, have the determination and have the strength, have a way of can start to do what I have to do, but I still in touted said: 'it needs to do.'But never expressed in action…” is the evidence for his hesitation.When his enemy is praying and he plans to kill him, he should consider that killing a man who is praying will allows him to go to haven, which makes him lose the chance to kill his uncle and commit the tragedy.Thirdly, he believes the true, the good and the beautiful, but he doesn’t believe his friends and his lover.It is his behavior that makes Ophelia dead.He pretends to be mad and kill her father by accident.Ophelia can’t bear the reality and goes to the place where she dates with her prince madly… His ignorance of others’ care and arrogance kill other four innocent people.Last but not least, he is the combination of the goodness and evil.On the one hand, he is pious to his parents, his girlfriend and his friends in a way.He bears the responsibility to take revenge on his uncle and to save the ordinary people.He tries his best to satisfy everyone but he also hurts many people.He takes his revenge on his uncle by hook or by crook.He kills Rosencrantz and Guildenstern.He is cold when he kills Polonius and heartless to Ophelia.Not merely does he lead to his own tragedy, but also leads to the whole play’s tragedy.All in all, the dejected prince wants to take revenge on his uncle, but he can’t find a proper way and his ability is not equal to his ambition.He is an idealist who has to face the cruel reality.As a great think who believes the true, the good and the beautiful, he hesitates to take the action and doubt everyone around him.He is the saver and also the destroyer.He is a giant and also an ordinary people.He is a noble prince and also an immature teen-age youth.

第五篇：管理信息系統(tǒng)五種開發(fā)方法優(yōu)缺點評析

管理信息系統(tǒng)的五種常見開發(fā)方法及其優(yōu)缺點闡述

1.把系統(tǒng)的建立看作是一種生命物種的成長過程。由6個開發(fā)階段組成：系統(tǒng)定義-> 需求分析-> 系統(tǒng)設(shè)計-> 編寫代碼-> 安裝調(diào)試-> 系統(tǒng)維護 優(yōu)點：

這種開發(fā)方法把管理信息系統(tǒng)開發(fā)的全過程按其生存周期分成若干階段，每個階段有相對獨立的任務(wù)，然后逐步完成各個階段的任務(wù)。在每一階段的開始與結(jié)束都規(guī)定了嚴格的標準。前一個階段的結(jié)束標準就是后—階段開始的標準，而每個階段任務(wù)相對獨立而且比較簡單，便于不同人員分工協(xié)作，從而降低了整個軟件工程開發(fā)的困難程度。在軟件生命周期的每個階段都采用科學管理和良好的技術(shù)方法，而且在每個階段結(jié)束之前都從技術(shù)與管理兩個角度進行嚴格審查，合格之后才開始下一階段工作。這就使得軟件開發(fā)全過程以一種有條不紊的方式進行，保證了軟件質(zhì)量，提高了軟件的可維護性。這樣不僅可以大大提高軟件開發(fā)的成功率，軟件開發(fā)的生產(chǎn)率也會明顯地提高。且簡單明了，結(jié)構(gòu)清晰。

同時把文檔資料作為每個階段的產(chǎn)品之一，而且加以標準化，作為每個階段結(jié)束的重要標準。它保證了在系統(tǒng)開發(fā)結(jié)束時有一個完整準確的軟件配置交付使用。文檔資料是通訊的工具，它清楚地說明了到這個時候為止關(guān)于該項工程已經(jīng)知道或做了什么，同時確定了下一步的工作基礎(chǔ)。文檔資料也起著備忘錄的作用，如果文檔不完整或與上一階段的文檔不相銜接則一定在工作上有不完整的地方。文檔資料另一重要作用是有利于與用戶交流，檢查錯誤，用戶評價。文檔資料也是系統(tǒng)維護的依據(jù)，通過每一階段生成的文檔資料，使得開發(fā)人員和用戶易于使用維護。不足：

這種開發(fā)方法的不足具體表現(xiàn)在以下幾方面

第一，階段回溯不可避免，延長系統(tǒng)開發(fā)的時間。結(jié)構(gòu)化生命周期法并沒有解決軟件開發(fā)研制時間過長的嚴重危機，在計算機硬軟件技術(shù)相通訊技術(shù)日新月異發(fā)展的時代，很容易使剛建立起來的管理信息系統(tǒng)迅速變得陳舊，生命周期很短，所以系統(tǒng)開發(fā)周期過長將導致系統(tǒng)運行時間變短。

第二，使用過程化語言，沒有以根本上改變個體手工編程的工作方式。

第三，專業(yè)開發(fā)人員開發(fā)用戶使用的系統(tǒng)開發(fā)模式，開發(fā)人員與用戶都要化時間去掌握對方專業(yè)領(lǐng)域的知識以期產(chǎn)生共同語言，導致用戶系統(tǒng)分析不充分，理解不透徹，或表達的二義性，造成軟件生命周期中越早潛入的錯誤發(fā)現(xiàn)越晚，系統(tǒng)分析時引入的錯誤往往要到運行時才發(fā)現(xiàn)，其修正的代價是相當昂貴的。

第四，用戶熱情沒有自始至終調(diào)動，不能從根本上解決讓用戶參加系統(tǒng)開發(fā)的問題。系統(tǒng)維護就十分困難。且文檔資料缺乏實用價值，特別是早期的系統(tǒng)規(guī)格說明——專業(yè)知識的缺乏使得用戶難以理解文檔的內(nèi)容，文檔資料沒有起到應(yīng)有的作用，反而延長了開發(fā)時間。

2.：

快速地創(chuàng)建出管理信息系統(tǒng)的測試版(可用來演示和評估),借助這種測試版本挖掘用戶的需求，然后在此版本的基本上進修改、增強。由4個開發(fā)階段組成: 確認基本需求-> 開發(fā)原型系統(tǒng)-> 使用原型系統(tǒng) <-> 修改增強原型 優(yōu)點：

快速原型法突出一個“快”字，采用結(jié)構(gòu)化生命周期法作系統(tǒng)分析時要反復和用戶討論，這種討論費時費力，而且終究是“紙上談兵”，原型法則是“真槍實彈”，能夠使用戶立刻與想象中的目標系統(tǒng)作出比較。開發(fā)人員向用戶提供一個“樣品”，用戶迅速向開發(fā)人員作出反饋，提高系統(tǒng)的質(zhì)量，快速原型法要求在獲得一組基本的用戶需求后，快速地實現(xiàn)新系統(tǒng)的一個“原型”，可以說是以用戶需求為中心，又不完全依賴于用戶需求，它對用戶需求的定義采用啟發(fā)的方式，引導用戶在對系統(tǒng)逐漸加深理解的過程中作出響應(yīng)，鼓勵用戶參與到系

統(tǒng)的設(shè)定與開發(fā)中去，更加便于系統(tǒng)的維護和使用。不足：

快速原型法，雖然能夠積極調(diào)動用戶參與到系統(tǒng)開發(fā)與設(shè)計中去，但起局限性在于，只能適用于中小型企業(yè)的管理信息系統(tǒng)開發(fā)，而大型企業(yè)，管理信息系統(tǒng)本身十分復雜，各種不確定性因素多變，對那些簡單的數(shù)據(jù)操作和記錄管理的應(yīng)用比較適合用原型法開發(fā)。而對那些批處理或大量計算和有著復雜過程邏輯的系統(tǒng)一般不適合用原型法處理。原型法更適合較小的應(yīng)用開發(fā)，對大型系統(tǒng)就須分成幾部分，一部分一部分地分別建立原型。如果缺乏用傳統(tǒng)方法進行透徹的需求分析，就無法對大型系統(tǒng)進行劃分，因為一開始很難分辨系統(tǒng)各部分之間存在哪些相互的影響。如果冒昧使用快速原型法，會導致管理信息系統(tǒng)出現(xiàn)漏洞。

3.應(yīng)用軟件包法：

通過購買商品化軟件包并在此基本上進行系統(tǒng)的開發(fā)方法。由4個階段組成：系統(tǒng)分析-> 系統(tǒng)設(shè)計-> 系統(tǒng)修正->系統(tǒng)維護 優(yōu)點：

從軟件包開發(fā)者手中直接購買企業(yè)需要的應(yīng)用軟件包，市場出售的應(yīng)用軟件包非常多而且應(yīng)用范圍廣，可以給企業(yè)管理者更多的選擇，使用商業(yè)化的應(yīng)用軟件包就不必自己再編寫程序或者只需寫少量的程序，因此可以說省時又省力，且效果立竿見影。不足：

應(yīng)用軟件包法雖然方便，但是同樣需要系統(tǒng)分析，設(shè)計，測試，轉(zhuǎn)換和維護等開發(fā)過程，而且由于此種方法是購買商業(yè)軟件包，因此導致企業(yè)內(nèi)部專業(yè)人員無法參與到系統(tǒng)開發(fā)中去，容易受制于軟件開發(fā)者，它不是一個完全獨立的系統(tǒng)，不易維護，不易更新，更不易于修改。而且軟件包是基于商業(yè)化開發(fā)的，軟件包不可能滿足一個組織的全部需求，相對來說，它更適用于所有組織中比較通用的一些需求。為了使其市場最有吸引力，軟件包力求滿足所有組織最共同的需求。勢必不能完全適應(yīng)于企業(yè)方方面面的實際情況。企業(yè)如想進一步改進系統(tǒng)，需要投入一部分的額外資金培養(yǎng)人才。

用戶自己采用開發(fā)工具開發(fā)自己需要的各種系統(tǒng)。由3個階段組成一個循環(huán)開發(fā)過程： 系統(tǒng)分析-> 系統(tǒng)開發(fā)-> 系統(tǒng)維護->回到系統(tǒng)分析 優(yōu)點：

這種方法的優(yōu)點在于克服了應(yīng)用軟件包法開發(fā)系統(tǒng)時企業(yè)無法自主的不足，由企業(yè)的開發(fā)人員根據(jù)企業(yè)的實際需要去開發(fā)和維護管理信息系統(tǒng)，可以適應(yīng)企業(yè)的實際情況，用戶對自己設(shè)計和開發(fā)的系統(tǒng)更容易接受并樂于使用，對應(yīng)變突發(fā)事件有好處，同時通過重復分析、開發(fā) 維護、再分析的幾個步驟，可以加深企業(yè)工作人員對管理信息系統(tǒng)的認識和理解，這樣有利于系統(tǒng)的開發(fā)和維護。而且由于開發(fā)系統(tǒng)的責任由信息系統(tǒng)專業(yè)人員轉(zhuǎn)給了最終用戶，所以用戶開發(fā)的系統(tǒng)有助于減少應(yīng)用系統(tǒng)后備資源。不足：

第一，由于缺乏規(guī)范的信息系統(tǒng)分析，用戶開發(fā)的應(yīng)用系統(tǒng)就缺乏獨立的外部評審，缺乏獨立的問題分析或可選方案的來源，用戶就很難完整并全面地說明其需求。

第二，由企業(yè)內(nèi)部人員自主開發(fā)管理信息系統(tǒng)，由于企業(yè)從業(yè)人員的專業(yè)水平參差不齊，且開發(fā)的系統(tǒng)常?？焖俚亟?，沒有一套正規(guī)的開發(fā)方法，這類系統(tǒng)往往缺乏適當?shù)臉藴?、控制和質(zhì)量保障過程，可能也沒有用于測試和提交文檔的規(guī)范。用戶開發(fā)的系統(tǒng)還可能缺乏對輸入和更新審計記錄的完整性及合法性的控制，缺乏操作控制、目標控制和各子系統(tǒng)之間穩(wěn)定的接口標準的控制。

第三，數(shù)據(jù)難以控制。

第四，用戶能用開發(fā)工具建立自己專用的“私用”信息系統(tǒng)，這類系統(tǒng)可對組織的其他成員隱蔽一些信息。一旦系統(tǒng)的開發(fā)者離開其崗位，這種非文檔化的私用系統(tǒng)將無法容易地移交

給他人使用。

5.將所需要的系統(tǒng)，委托企業(yè)外部的人員或組織進行開發(fā)。它只是一種信 息系統(tǒng)開發(fā)策略，這些開發(fā)依然要選擇如何使用前面4種開發(fā)方法。由3個階段組成：用戶需求-> 外包信息系統(tǒng)-> 最終系統(tǒng) 優(yōu)點：

在經(jīng)濟方面，由于負責系統(tǒng)開發(fā)服務(wù)的外部開發(fā)商是信息系統(tǒng)服務(wù)和技術(shù)方面的專家，所以靠專業(yè)化和規(guī)模經(jīng)濟，他們能以低于內(nèi)部成本的費用向組織提供同樣的服務(wù)和價值。服務(wù)質(zhì)量方面，因為一旦外部開發(fā)商提供的服務(wù)不夠滿意，那么他將會失去自己的客戶，所以企業(yè)對外部開發(fā)商的影響比對自己員工的影響更大。從而使企業(yè)能以較低的成本從開發(fā)商那里獲得高質(zhì)量的服務(wù)。再一點，由于企業(yè)與外部開發(fā)商事先針對不同層次的服務(wù)所對應(yīng)的費用進行了簽約，因此可大大減少成本的不確定性。外包信息系統(tǒng)具備一定的靈活性，在組織的信息系統(tǒng)基礎(chǔ)設(shè)施不發(fā)生重大變化的情況下，能適應(yīng)業(yè)務(wù)量的增長。當信息技術(shù)滲透整個企業(yè)價值鏈時，由于成本和性能可按變化的需求不斷進行調(diào)整，所以外部開發(fā)商可提供較強的業(yè)務(wù)控制和適應(yīng)能力。外包信息系統(tǒng)同時也可以解放人力資源，將較少且昂貴的高層次人才集中到具有較高價值和回報的活動中。不足：

第一，失控：當一個企業(yè)將開發(fā)、運行其信息系統(tǒng)的責任承包給另一個組織時，它可能失去對信息系統(tǒng)職能的控制。如果開發(fā)商成為企業(yè)運行和開發(fā)信息系統(tǒng)的惟一選擇，那么企業(yè)將不得不接受開發(fā)商所提供的任何技術(shù)，這種從屬關(guān)系最終將導致產(chǎn)生較高的成本，并可能失去對技術(shù)管理的控制。

第二，戰(zhàn)略信息易損：由于企業(yè)信息系統(tǒng)由外部人員運行、開發(fā)，所以商業(yè)秘密或業(yè)主信息可能會泄漏給競爭對手；若允許外部開發(fā)者開發(fā)或操作使企業(yè)具有競爭優(yōu)勢的應(yīng)用系統(tǒng)，那將更有害。

第三，依賴性：企業(yè)會隨開發(fā)商對企業(yè)信息系統(tǒng)的開發(fā)、運作而變得對開發(fā)商的生存能力更加依賴，那么開發(fā)商的財政問題或服務(wù)上的衰減都可能對企業(yè)產(chǎn)生嚴重的影響。