編寫高效代碼與編譯優化的體會

A. java編譯器的代碼優化問題

理論上的就不說了，你自己搜也能搜到很多。
舉個例子，你從一個方法a調用了另一個方法b。
我們知道，在a和b之中是可以創建相同名稱的變數的，比如都有int i = 0;這句話。這種現象的根本原因在於，方法的調用會產生中斷，中斷產生後，cpu會做現場保護，包括把變數等進行壓棧操作，即把方法a的相關資源進行了壓棧，而方法b的相關資源放在棧頂，只有棧頂資源可以與cpu交互（就把方法a中的變數i保護起來），當方法b結束後出棧，a就又回到了棧頂，並獲取了方法b運行的結果，然後繼續運行。

哎，有些啰嗦了。方法的調用、中斷、壓棧出棧等等這些操作你說一點不消耗資源吧，那是不可能的，多少都會消耗一些，雖然很非常十分微不足道。那麼編譯器的優化過程，我知道的其作用之一，就是會把這些做一個優化。原本方法a一共10句話，你偏要只寫1句，然後第2句寫成方法b，第3句寫成方法c。。。。。，然後依次嵌套調用。這樣的源代碼，編譯器優化後，就跟你直接寫10句是一個結果，即做了一定程度上的優化。

B. 如何編寫高質量的VB代碼來提高執行的速度

這些手段可以分為兩個大的部分：編碼技術和編譯優化技術。在編碼技術中介紹了如何通過使用高效的數據類型、減少外部引用等編程手段來提高代碼執行速度，減少代碼消耗的系統資源。在編譯優化技術中介紹了如何正確地利用VB提供的編譯選項對在編譯時最後生成的可執行文件進行優化。 讓代碼一次成型：在我接觸到的程序員中，有很多人喜歡先根據功能需求把代碼寫出來，然後在此基礎上優化代碼。最後發現為了達到優化的目的，他們不得不把代碼再重新寫一遍。所以我建議你在編寫代碼之前就需要考慮優化問題。 把握好優化的結果和需要花費的工作之間的關系：通常當完成了一段代碼，你需要檢查和修改它。在檢查代碼的過程中，也許你會發現某些循環中的代碼效率還可以得到進一步的改進。在這種情況下，很多追求完美的程序員也許會立馬修改代碼。我的建議是，如果修改這段代碼會使程序的運行時間縮短一秒，你可以修改它。如果只能帶來10毫秒的性能改進，則不做任何改動。這是因為重寫一段代碼必定會引入新的錯誤，而調試新的代碼必定會花掉你一定的時間。程序員應該在軟體性能和開發軟體需要的工作量之間找一個平衡點，而且10毫秒對於用戶來說也是一個不能體會到的差異。 在需要使用面向對象方法的時候盡量使用它；VB提供的機制不完全支持面向對象的設計和編碼，但是VB提供了簡單的類。大多數人認為使用對象將導致代碼的效率降低。對於這一點我個人有些不同的意見；考察代碼的效率不能純粹從運行速度的角度出發，軟體佔用的資源也是需要考慮的因素之一。使用類可以幫助你在整體上提升軟體的性能，這一點我會在後面的例子中詳細說明。 當你編寫VB代碼的時候，希望你能把上面幾點作為 下面的這些方法可以幫助你提高代碼的運行速度： 1. 使用整數（Integer）和長整數（Long） 提高代碼運行速度最簡單的方法莫過於使用正確的數據類型了。也許你不相信，但是正確地選擇數據類型可以大幅度提升代碼的性能。在大多數情況下，程序員可以將Single，Double和Currency類型的變數替換為Integer或Long類型的變數，因為VB處理Integer和Long的能力遠遠高於處理其它幾種數據類型。 在大多數情況下，程序員選擇使用Single或Double的原因是因為它們能夠保存小數。但是小數也可以保存在Integer類型的變數中。例如程序中約定有三位小數，那麼只需要將保存在Integer變數中的數值除以1000就可以得到結果。根據我的經驗，使用Integer和Long替代Single，Double和Currency後，代碼的運行速度可以提高將近10倍。 2. 避免使用變體 對於一個VB程序員來說，這是再明顯不過的事情了。變體類型的變數需要16個位元組的空間來保存數據，而一個整數（Integer）只需要2個位元組。通常使用變體類型的目的是為了減少設計的工4作量和代碼量，也有的程序員圖個省事而使用它。但是如果一個軟體經過了嚴格設計和按照規范編碼的話，完全可以避免使用變體類型。 在這里順帶提一句，對於Object對象也存在同樣的問題。

C. 如何編寫代碼才能使效率提高

一、排版：
1.關鍵詞和操作符之間加適當的空格。
2.相對獨立的程序塊與塊之間加空行
3.較長的語句、表達式等要分成多行書寫。
4.劃分出的新行要進行適應的縮進，使排版整齊，語句可讀。
5.長表達式要在低優先順序操作符處劃分新行，操作符放在新行之首。
6.循環、判斷等語句中若有較長的表達式或語句，則要進行適應的劃分。
7.若函數或過程中的參數較長，則要進行適當的劃分。
8.不允許把多個短語句寫在一行中，即一行只寫一條語句。
9.函數或過程的開始、結構的定義及循環、判斷等語句中的代碼都要採用縮進風格。
10.C/C++語言是用大括弧『{』和『}』界定一段程序塊的，編寫程序塊時『{』和
『}』應各獨佔一行並且位於同一列，同時與引用它們的語句左對齊。在函數體
的開始、類的定義、結構的定義、枚舉的定義以及if、for、do、while、
switch、case語句中的程序都要採用如上的縮進方式。
二、注釋
1.注釋要簡單明了。
2.邊寫代碼邊注釋，修改代碼同時修改相應的注釋，以保證注釋與代碼的一致性。
3.在必要的地方注釋，注釋量要適中。注釋的內容要清楚、明了，含義准確，防止
注釋二義性。保持注釋與其描述的代碼相鄰，即注釋的就近原則。
4.對代碼的注釋應放在其上方相鄰位置，不可放在下面。
5.對數據結構的注釋應放在其上方相鄰位置，不可放在下面；對結構中的每個域
的注釋應放在此域的右方；同一結構中不同域的注釋要對齊。
6.變數、常量的注釋應放在其上方相鄰位置或右方。
7.全局變數要有較詳細的注釋，包括對其功能、取值范圍、哪些函數或過程存取它
以及存取時注意事項等的說明。
8.在每個源文件的頭部要有必要的注釋信息，包括：文件名；版本號；作者；生成
日期；模塊功能描述（如功能、主要演算法、內部各部分之間的關系、該文件與其
它文件關系等）；主要函數或過程清單及本文件歷史修改記錄等。
9.在每個函數或過程的前面要有必要的注釋信息，包括：函數或過程名稱；功能描
述；輸入、輸出及返回值說明；調用關系及被調用關系說明等。
三、命名
1.較短的單詞可通過去掉「母音」形成縮寫；
2.較長的單詞可取單詞的頭幾發符的優先順序，並用括弧明確表達式的操作順序，避
免使用默認優先順序。
3.使用匈牙利表示法
四、可讀性
1.避免使用不易理解的數字，用有意義的標識來替代。
2.不要使用難懂的技巧性很高的語句。
3.源程序中關系較為緊密的代碼應盡可能相鄰。
五、變數
1.去掉沒必要的公共變數。
2.構造僅有一個模塊或函數可以修改、創建，而其餘有關模塊或函數只訪問的公共
變數，防止多個不同模塊或函數都可以修改、創建同一公共變數的現象。
3.仔細定義並明確公共變數的含義、作用、取值范圍及公共變數間的關系。
4.明確公共變數與操作此公共變數的函數或過程的關系，如訪問、修改及創建等。
5.當向公共變數傳遞數據時，要十分小心，防止賦與不合理的值或越界等現象發生。
6.防止局部變數與公共變數同名。
7.仔細設計結構中元素的布局與排列順序，使結構容易理解、節省佔用空間，並減
少引起誤用現象。
8.結構的設計要盡量考慮向前兼容和以後的版本升級，並為某些未來可能的應用保
留餘地（如預留一些空間等）。
9.留心具體語言及編譯器處理不同數據類型的原則及有關細節。
10.嚴禁使用未經初始化的變數。聲明變數的同時對變數進行初始化。
11.編程時，要注意數據類型的強制轉換。
六、函數、過程
1.函數的規模盡量限制在200行以內。
2.一個函數最好僅完成一件功能。
3.為簡單功能編寫函數。
4.函數的功能應該是可以預測的，也就是只要輸入數據相同就應產生同樣的輸出。
5.盡量不要編寫依賴於其他函數內部實現的函數。
6.避免設計多參數函數，不使用的參數從介面中去掉。
7.用注釋詳細說明每個參數的作用、取值范圍及參數間的關系。
8.檢查函數所有參數輸入的有效性。
9.檢查函數所有非參數輸入的有效性，如數據文件、公共變數等。
10.函數名應准確描述函數的功能。
11.避免使用無意義或含義不清的動詞為函數命名
12.函數的返回值要清楚、明了，讓使用者不容易忽視錯誤情況。
13/明確函數功能，精確（而不是近似）地實現函數設計。
14.減少函數本身或函數間的遞歸調用。
15.編寫可重入函數時，若使用全局變數，則應通過關中斷、信號量（即P、V操作）
等手段對其加以保護。
七、可測性
1.在編寫代碼之前，應預先設計好程序調試與測試的方法和手段，並設計好各種調
測開關及相應測試代碼如列印函數等。
2.在進行集成測試/系統聯調之前，要構造好測試環境、測試項目及測試用例，同時
仔細分析並優化測試用例，以提高測試效率。
八、程序效率
1.編程時要經常注意代碼的效率。
2.在保證軟體系統的正確性、穩定性、可讀性及可測性的前提下，提高代碼效率。
3.不能一味地追求代碼效率，而對軟體的正確性、穩定性、可讀性及可測性造成影
響。
4.編程時，要隨時留心代碼效率；優化代碼時，要考慮周全。
5.要仔細地構造或直接用匯編編寫調用頻繁或性能要求極高的函數。
6.通過對系統數據結構劃分與組織的改進，以及對程序演算法的優化來提高空間效率。
7.在多重循環中，應將最忙的循環放在最內層。
8.盡量減少循環嵌套層次。
9.避免循環體內含判斷語句，應將循環語句置於判斷語句的代碼塊之中。
10.盡量用乘法或其它方法代替除法，特別是浮點運算中的除法。
九、質量保證
1.在軟體設計過程中構築軟體質量。
代碼質量保證優先原則
（1）正確性，指程序要實現設計要求的功能。
（2）穩定性、安全性，指程序穩定、可靠、安全。
（3）可測試性，指程序要具有良好的可測試性。
（4）規范/可讀性，指程序書寫風格、命名規則等要符合規范。
（5）全局效率，指軟體系統的整體效率。
（6）局部效率，指某個模塊/子模塊/函數的本身效率。
（7）個人表達方式/個人方便性，指個人編程習慣。
2.只引用屬於自己的存貯空間。
3.防止引用已經釋放的內存空間。
4.過程/函數中分配的內存，在過程/函數退出之前要釋放。
5.過程/函數中申請的（為打開文件而使用的）文件句柄，在過程/函數退出前要關閉。
6.防止內存操作越界。
7.時刻注意表達式是否會上溢、下溢。
8.認真處理程序所能遇到的各種出錯情況。
9.系統運行之初，要初始化有關變數及運行環境，防止未經初始化的變數被引用。
10.系統運行之初，要對載入到系統中的數據進行一致性檢查。
11.嚴禁隨意更改其它模塊或系統的有關設置和配置。
12.不能隨意改變與其它模塊的介面。
13.充分了解系統的介面之後，再使用系統提供的功能。
14.要時刻注意易混淆的操作符。當編完程序後，應從頭至尾檢查一遍這些操作符。
15.不使用與硬體或操作系統關系很大的語句，而使用建議的標准語句。
16.建議：使用第三方提供的軟體開發工具包或控制項時，要注意以下幾點：
（1）充分了解應用介面、使用環境及使用時注意事項。
（2）不能過分相信其正確性。
（3）除非必要，不要使用不熟悉的第三方工具包與控制項。
十、代碼編譯
1.編寫代碼時要注意隨時保存，並定期備份，防止由於斷電、硬碟損壞等原因造成
代碼丟失。
2.同一項目組內，最好使用相同的編輯器，並使用相同的設置選項。
3.合理地設計軟體系統目錄，方便開發人員使用。
4.打開編譯器的所有告警開關對程序進行編譯。
5.在同一項目組或產品組中，要統一編譯開關選項。
6.使用工具軟體（如Visual SourceSafe）對代碼版本進行維護。
十一、代碼測試、維護
1.單元測試要求至少達到語句覆蓋。
2.單元測試開始要跟蹤每一條語句，並觀察數據流及變數的變化。
3.清理、整理或優化後的代碼要經過審查及測試。
4.代碼版本升級要經過嚴格測試。

D. 給程序員編寫高效java代碼的幾條建議

張小喜告別996 實現高效編程 減少開發壓力 開啟Java高效編程之門（完整版高清視頻）網路網盤

鏈接: https://pan..com/s/1kKaGzsXHu3Cy7MqvIY7r3g

若資源有問題歡迎追問~

E. 如何編寫高質量的代碼！

載選<編程思想>

非程序員 編 著

代碼永遠會有BUG，在這方面沒有最好只有更好。高效是程序員必須作到的事情，無錯是程序員一生的追求。復用、分而治之、折衷是代碼哲學的基本思想。模塊化與面向對象是實現高效無錯代碼的方法。高效無錯代碼需要思想與實踐的不斷反復。
1.2.1 命名約定
命令規范基本上採用了微軟推薦的匈牙利命名法，略有簡化。
1． 常量
常量由大寫字母和數字組成，中間可以下劃線分隔，如 CPU_8051。
2． 變數
變數由小寫（變數類型）字母開頭，中間以大寫字母分隔，可以添加變數域前綴（變數活動域前綴以下劃線分隔）。如： v_nAcVolMin（交流電壓最小值）。
變數域前綴見下表
局部變數，如果變數名的含義十分明顯，則不加前綴，避免煩瑣。如用於循環的int型變數 i,j,k ；float 型的三維坐標（x,y,z）等。
3． 函數名一般由大寫字母開頭，中間以大寫字母分隔，如SetSystemPara。函數命名採用動賓形式。如果函數為最底層，可以考慮用全部小寫，單詞間採用帶下劃線的形式。如底層圖形函數：pixel、lineto以及讀鍵盤函數get_key 等。
4． 符號名應該通用或者有具體含義，可讀性強。尤其是全局變數，靜態變數含義必須清晰。C++中的一些關鍵詞不能作為符號名使用，如class、new、friend等。符號名長度小於31個，與ANSI C 保持一致。命名只能用26個字母，10個數字，以及下劃線『_』來組成，不要使用『$』『@』等符號。下劃線『_』使用應該醒目，不能出現在符號的頭尾，只能出現在符號中間，且不要連續出現兩個。
5． 程序中少出現無意義的數字，常量盡量用宏替代。
1.2.2 使用斷言
程序一般分為Debug版本和Release版本，Debug版本用於內部調試，Release版本發行給用戶使用。
斷言assert是僅在Debug版本起作用的宏，它用於檢查「不應該」發生的情況。以下是一個內存復製程序，在運行過程中，如果assert的參數為假，那麼程序就會中止（一般地還會出現提示對話，說明在什麼地方引發了assert）。
//復制不重疊的內存塊
void memcpy(void *pvTo, void *pvFrom, size_t size)
{
void *pbTo = (byte *) pvTo;
void *pbFrom = (byte *) pvFrom;
assert( pvTo != NULL && pvFrom != NULL );
while(size - - > 0 )
*pbTo + + = *pbFrom + + ;
return (pvTo);
}
assert不是一個倉促拼湊起來的宏，為了不在程序的Debug版本和Release版本引起差別，assert不應該產生任何副作用。所以assert不是函數，而是宏。程序員可以把assert看成一個在任何系統狀態下都可以安全使用的無害測試手段。
以下是使用斷言的幾個原則：
1）使用斷言捕捉不應該發生的非法情況。不要混淆非法情況與錯誤情況之間的區別，後者是必然存在的並且是一定要作出處理的。
2）使用斷言對函數的參數進行確認。
3）在編寫函數時，要進行反復的考查，並且自問：「我打算做哪些假定？」一旦確定了的假定，就要使用斷言對假定進行檢查。
4）一般教科書都鼓勵程序員們進行防錯性的程序設計，但要記住這種編程風格會隱瞞錯誤。當進行防錯性編程時，如果「不可能發生」的事情的確發生了，則要使用斷言進行報警。
1.2.3 優化／效率
規則一：對於在中斷函數／線程和外部函數中均使用的全局變數應用volatile定義。例如：
volatile int ticks;
void timer(void) interrupt 1 //中斷處理函數
{
ticks++
}
void wait(int interval)
{
tick=0;
while(tick<interval);
}
如果未用volatile，由於while循環是一個空循環，編譯器優化後（編譯器並不知道此變數在中斷中使用）將會把循環優化為空操作！這就顯然不對了。
規則二：不要編寫一條過分復雜的語句，緊湊的C++/C代碼並不見到能得到高效率的機器代碼，卻會降低程序的可理解性，程序出錯誤的幾率也會提高。
規則三：變數類型編程中應用原則：盡量採用小的類型（如果能夠不用「Float」就盡量不要去用）以及無符號Unsigned類型，因為符號運算耗費時間較長；同時函數返回值也盡量採用Unsigned類型，由此帶來另外一個好處：避免不同類型數據比較運算帶來的隱性錯誤。

1.2.4 其他
規則一：不要編寫集多種功能於一身的函數，在函數的返回值中，不要將正常值和錯誤標志混在一起。
規則二：不要將BOOL值TRUE和FALSE對應於1和0進行編程。大多數編程語言將FALSE定義為0，任何非0值都是TRUE。Visual C++將TRUE定義為1，而Visual Basic則將TRUE定義為-1。例如：
BOOL flag;
…
if(flag) { // do something } // 正確的用法
if(flag==TRUE) { // do something } // 危險的用法
if(flag==1) { // do something } // 危險的用法
if(!flag) { // do something } // 正確的用法
if(flag==FALSE) { // do something } // 不合理的用法
if(flag==0) { // do something } // 不合理的用法
規則三：小心不要將「= =」寫成「=」，編譯器不會自動發現這種錯誤。
規則四：建議統一函數返回值為無符號整形，0代表無錯誤，其他代表錯誤類型。

1.3 模塊化的C編程

C語言雖然不具備C++的面向對象的成分，但仍應該吸收面向對象的思想，採用模塊化編程思路。面向對象的思想與面向對象的語言是兩個概念。非面向對象的語言依然可以完成面向對象的編程，想想C++的誕生吧！
C++沒有理由對C存在傲慢與偏見，不是任何場合C++方法都是解決問題的良葯，譬如面對嵌入式系統效率和空間的雙重需求。注意我們談的是方法，而不是指編譯器。
C在軟體開發上存在的首要問題是缺乏對數據存取的控制（封裝），C編程者樂而不疲的使用著大量extern形式的全局變數在各模塊間交換著數據，「多方便啊」編程者樂曰，並傳授給下一個編程者。這樣多個變數出現在多個模塊中，剪不斷理還亂，直到有一天終於發現找一個「人」好難。一個東西好吃，智者淺嘗之改進之，而愚者只會直至撐死。
這世上本沒有什麼救世主，應在C上多下功夫，程序員和C締造者早就有過思考，相信野百合也有春天，還是看看C語言如何實現模塊化編程方法，在部分程度上具備了OO特性封裝與多態。
在具體闡述之前，需要明確生存期與可見性的概念。生存期指的是變數在內存的生存周期，可見性指的是變數在當前位置是否可用。兩者有緊密聯系，但不能混為一談。一個人存在但不可見只能解釋成上帝或靈魂，一個變數存在但不可見卻並非咄咄怪事，模塊化方法正是利用了靜態函數、靜態變數這些「精靈」們特殊的生存期與可見性。
最後需要明確一點的是這里的模塊是以一個.C文件為單位。
規則一：利用函數命名規則和靜態函數
模塊中不被其他模塊調用的內部函數採用以下命名規則：用全部小寫，單詞間採用帶下劃線的形式。如底層圖形函數：pixel、lineto以及讀鍵盤函數get_key等。這些函數應定義為static靜態函數，這樣在其他模塊錯誤地調用這些函數時編譯器能給出錯誤（如BC編譯器）。（注意：有些編譯器不能報告錯誤，但為了代碼風格一致和函數層次清晰，仍建議這樣作）。
規則二：利用靜態變數
模塊中不能被其他模塊讀寫的全局變數應採用static聲明，這樣在其他模塊錯誤地讀寫這些變數時編譯器能給出警告（C51編譯器）或錯誤（BC編譯器）。
規則三：引入OO介面概念和指針傳參
模塊間的數據介面（也就是函數）應該事先較充分考慮，需要哪些介面，通過介面需要操作哪些數據，盡量作到介面的不變性。
模塊間地數據交換盡量通過介面完成，方法是通過函數傳參數，為了保證程序高效和減少堆棧空間，傳大量參數（如結構）應採用傳址的方式，通過指針作為函數參數或函數返回指針，盡量杜絕extern形式的全局變數，請注意是extern形式的全局變數，模塊內部的全局變數是允許和必須的。
傳指針參數增加的開銷主要是作參數的指針和局部指針的數據空間（嵌入式系統（如C51）往往由於堆棧空間有限，函數參數會放到外部RAM的堆棧中），增加的代碼開銷僅是函數的調用，帶來的是良好的模塊化結構，而且使用介面函數會比在代碼中多處直接使用全局變數大大節約代碼空間。
需注意一點的事物總有他的兩面性，水能載舟，也能覆舟。對於需要頻繁訪問的變數如果仍採用介面傳遞，函數調用的開銷是巨大的，這時應考慮仍採用extern全局變數。
以下演示了兩個C模塊交換數據：
//Mole1.C
OneStruct* void GetOneStruct(void); //獲取模塊1數據介面
void SetOneStruct(OneStruct* pOneStruct); //寫模塊1數據介面

struct OneStruct
{
int m¬_imember；
//……
}t1; //模塊1的數據

//t1初始化代碼…..

OneStruct* void GetOneStruct(void)
{
OneStruct* pt1; //只需定義一個局部變數
t1.imember=15;
pt1=&t1;
return pt1;
}

void SetOneStruct(OneStruct* pOneStruct)
{
t1.imember=pOneStruct->imember;
//…….
}

//Mole2.C
void OperateOneStruct(void); //模塊2通過模塊1提供的介面操作模塊1的數據
OneStruct* void GetOneStruct(void);
void SetOneStruct(OneStruct* pOneStruct);

void OperateOneStruct(void)
{
OneStruct* pt2; //只需定義一個局部變數
pt2=GetOneStruct(); //讀取數據
SetOneStruct(pt2); //改寫數據
}
採用介面訪問數據可以避免一些錯誤，因為函數返回值只能作右值，全局變數則不然。
例如 cOneChar == 4; 可能被誤為cOneChar = 4;
規則四：有限的封裝與多態
不要忘記C++的class源於C的struct，C++的虛函數機制實質是函數指針。為了使數據、方法能夠封裝在一起，提高代碼的重用度，如對於一些與硬體相關的數據結構，建議採用在數據結構中將訪問該數據結構的函數定義為結構內部的函數指針。這樣當硬體變化，需要重寫訪問該硬體的函數，只要將重寫的函數地址賦給該函數指針，高層代碼由於使用的是函數指針，所以完全不用動，實現代碼重用。而且該函數指針可以通過傳參數或全局變數的方式傳給高層代碼，比較方便。例如：
struct OneStruct
{
int m¬_imember；
int (*func)(int,int);
//……
}t2;

F. 編程心得

編程
這是每個游戲編程FAQ里都有的問題。這個問題每星期都會在游戲開發論壇上被問上好幾次。這是個很好的問題，但是，沒人能給出簡單的答案。在某些應用程序中，總有一些計算機語言優於其他語言。下面是幾種用於編寫游戲的主要編程語言的介紹及其優缺點。希望這篇文章能幫助你做出決定。

1、C語言

如果說FORTRAN和COBOL是第一代高級編譯語言，那麼C語言就是它們的孫子輩。C語言是Dennis Ritchie在七十年代創建的，它功能更強大且與ALGOL保持更連續的繼承性，而ALGOL則是COBOL和FORTRAN的結構化繼承者。C語言被設計成一個比它的前輩更精巧、更簡單的版本，它適於編寫系統級的程序，比如操作系統。在此之前，操作系統是使用匯編語言編寫的，而且不可移植。C語言是第一個使得系統級代碼移植成為可能的編程語言。

C語言支持結構化編程，也就是說C的程序被編寫成一些分離的函數呼叫（調用）的集合，這些呼叫是自上而下運行，而不像一個單獨的集成塊的代碼使用GOTO語句控制流程。因此，C程序比起集成性的FORTRAN及COBOL的「空心粉式代碼」代碼要簡單得多。事實上，C仍然具有GOTO語句，不過它的功能被限制了，僅當結構化方案非常復雜時才建議使用。

正由於它的系統編程根源，將C和匯編語言進行結合是相當容易的。函數調用介面非常簡單，而且匯編語言指令還能內嵌到C代碼中，所以，不需要連接獨立的匯編模塊。

優點：有益於編寫小而快的程序。很容易與匯編語言結合。具有很高的標准化，因此其他平台上的各版本非常相似。

缺點：不容易支持面向對象技術。語法有時會非常難以理解，並造成濫用。

移植性：C語言的核心以及ANSI函數調用都具有移植性，但僅限於流程式控制制、內存管理和簡單的文件處理。其他的東西都跟平台有關。比如說，為Windows和Mac開發可移植的程序，用戶界面部分就需要用到與系統相關的函數調用。這一般意味著你必須寫兩次用戶界面代碼，不過還好有一些庫可以減輕工作量。

用C語言編寫的游戲：非常非常多。

資料：C語言的經典著作是《The C Programming Language》，它經過多次修改，已經擴展到最初的三倍大，但它仍然是介紹C的優秀書本。一本極好的教程是《The Waite Group's C Primer Plus》。

2、C++

C++語言是具有面向對象特性的C語言的繼承者。面向對象編程，或稱OOP是結構化編程的下一步。OO程序由對象組成，其中的對象是數據和函數離散集合。有許多可用的對象庫存在，這使得編程簡單得只需要將一些程序「建築材料」堆在一起（至少理論上是這樣）。比如說，有很多的GUI和資料庫的庫實現為對象的集合。

C++總是辯論的主題，尤其是在游戲開發論壇里。有幾項C++的功能，比如虛擬函數，為函數呼叫的決策制定增加了一個額外層次，批評家很快指出C++程序將變得比相同功能的C程序來得大和慢。C++的擁護者則認為，用C寫出與虛擬函數等價的代碼同樣會增加開支。這將是一個還在進行，而且不可能很快得出結論的爭論。

我認為，C++的額外開支只是使用更好的語言的小付出。同樣的爭論發生在六十年代高級程序語言如COBOL和FORTRAN開始取代匯編成為語言所選的時候。批評家正確的指出使用高級語言編寫的程序天生就比手寫的匯編語言來得慢，而且必然如此。而高級語言支持者認為這么點小小的性能損失是值得的，因為COBOL和FORTRAN程序更容易編寫和維護。

優點：組織大型程序時比C語言好得多。很好的支持面向對象機制。通用數據結構，如鏈表和可增長的陣列組成的庫減輕了由於處理低層細節的負擔。

缺點：非常大而復雜。與C語言一樣存在語法濫用問題。比C慢。大多數編譯器沒有把整個語言正確的實現。

移植性：比C語言好多了，但依然不是很樂觀。因為它具有與C語言相同的缺點，大多數可移植性用戶界面庫都使用C++對象實現。

使用C++編寫的游戲：非常非常多。大多數的商業游戲是使用C或C++編寫的。

資料：最新版的《The C++ Programming Language》非常好。作為教程，有兩個陣營，一個假定你知道C，另外一個假定你不知道。到目前為止，最好的C++教程是《Who's Afraid of C++》，如果你已經熟知C，那麼試一下《Teach Yourself C++》。

3、我該學習C++或是該從C開始

我不喜歡這種說法，但它是繼「我該使用哪門語言」之後最經常被問及的問題。很不幸，不存在標准答案。你可以自學C並使用它來寫程序，從而節省一大堆的時間，不過使用這種方法有兩個弊端：

你將錯過那些面向對象的知識，因為它可能在你的游戲中使得數據建模更有效率的東西。

最大的商業游戲，包括第一人稱射擊游戲很多並沒有使用C++。但是，這些程序的作者即使使用老的C的格式，他們通常堅持使用面向對象編程技術。如果你只想學C，至少要自學OO（面向對象）編程技術。OO是模擬（游戲）的完美方法，如果你不學習OO，你將不得不「辛苦」的工作。

4、匯編語言

顯然，匯編是第一個計算機語言。匯編語言實際上是你計算機處理器實際運行的指令的命令形式表示法。這意味著你將與處理器的底層打交道，比如寄存器和堆棧。如果你要找的是類英語且有相關的自我說明的語言，這不是你想要的。

確切的說，任何你能在其他語言里做到的事情，匯編都能做，只是不那麼簡單 — 這是當然，就像說你既可以開車到某個地方，也可以走路去，只是難易之分。話雖不錯，但是新技術讓東西變得更易於使用。

總的來說，匯編語言不會在游戲中單獨應用。游戲使用匯編主要是使用它那些能提高性能的零零碎碎的部分。比如說，毀滅戰士整體使用C來編寫，有幾段繪圖程序使用匯編。這些程序每秒鍾要調用數千次，因此，盡可能的簡潔將有助於提高游戲的性能。而從C里調用匯編寫的函數是相當簡單的，因此同時使用兩種語言不成問題。

特別注意：語言的名字叫「匯編」。把匯編語言翻譯成真實的機器碼的工具叫「匯編程序」。把這門語言叫做「匯編程序」這種用詞不當相當普遍，因此，請從這門語言的正確稱呼作為起點出發。

優點：最小、最快的語言。匯編高手能編寫出比任何其他語言能實現的快得多的程序。你將是利用處理器最新功能的第一人，因為你能直接使用它們。

缺點：難學、語法晦澀、堅持效率，造成大量額外代碼 — 不適於心臟虛弱者。

移植性：接近零。因為這門語言是為一種單獨的處理器設計的，根本沒移植性可言。如果使用了某個特殊處理器的擴展功能，你的代碼甚至無法移植到其他同類型的處理器上（比如，AMD的3DNow指令是無法移植到其它奔騰系列的處理器上的）。

使用匯編編寫的游戲：我不知道有什麼商業游戲是完全用匯編開發的。不過有些游戲使用匯編完成多數對時間要求苛刻的部分。

資料：如果你正在找一門匯編語言的文檔，你主要要找晶元的文檔。網路上如Intel、AMD、Motorola等有一些關於它們的處理器的資料。對於書籍而言，《Assembly Language: Step-By-Step》是很值得學習的。

5、Pascal語言

Pascal語言是由Nicolas Wirth在七十年代早期設計的，因為他對於FORTRAN和COBOL沒有強制訓練學生的結構化編程感到很失望，「空心粉式代碼」變成了規范，而當時的語言又不反對它。Pascal被設計來強行使用結構化編程。最初的Pascal被嚴格設計成教學之用，最終，大量的擁護者促使它闖入了商業編程中。當Borland發布IBM PC上的 Turbo Pascal時，Pascal輝煌一時。集成的編輯器，閃電般的編譯器加上低廉的價格使之變得不可抵抗，Pascal編程了為MS-DOS編寫小程序的首選語言。

然而時日不久，C編譯器變得更快，並具有優秀的內置編輯器和調試器。Pascal在1990年Windows開始流行時走到了盡頭，Borland放棄了Pascal而把目光轉向了為Windows 編寫程序的C++。Turbo Pascal很快被人遺忘。

最後，在1996年，Borland發布了它的「Visual Basic殺手」— Delphi。它是一種快速的帶華麗用戶界面的 Pascal編譯器。由於不懈努力，它很快贏得了一大群愛好者。

基本上，Pascal比C簡單。雖然語法類似，它缺乏很多C有的簡潔操作符。這既是好事又是壞事。雖然很難寫出難以理解的「聰明」代碼，它同時也使得一些低級操作，如位操作變得困難起來。

優點：易學、平台相關的運行（Dephi）非常好。

缺點：「世界潮流」面向對象的Pascal繼承者（Mola、Oberon）尚未成功。語言標准不被編譯器開發者認同。專利權。

移植性：很差。語言的功能由於平台的轉變而轉變，沒有移植性工具包來處理平台相關的功能。

使用Pascal編寫的游戲：幾個。DirectX的Delphi組件使得游戲場所變大了。

資料：查找跟Delphi有關的資料，請訪問：Inprise Delphi page。

6、Visual Basic

哈，BASIC。回到八十年代的石器時代，它是程序初學者的第一個語言。最初的BASIC形式，雖然易於學習，卻是可怕的無組織化，它義無返顧的使用了GOTO充斥的「空心粉式代碼」。當回憶起BASIC的行號和GOSUB命令，沒有幾個人能止住眼角的淚水。

快速前進到九十年代早期，雖然不是蘋果公司所希望的巨人，HyperCard仍然是一個在Windows下無法比擬的吸引人的小型編程環境。Windows下的HyperCard克隆品如ToolBook又慢又笨又昂貴。為了與HyperCard一決高下，微軟取得了一個小巧的名為Thunder編程環境的許可權，並把它作為Visual Basci 1.0發布，其用戶界面在當時非常具有新意。這門語言雖然還叫做Basic（不再是全部大寫），但更加結構化了，行號也被去除。實際上，這門語言與那些內置於TRS-80、Apple II及Atari里的舊的ROM BASIC相比，更像是帶Basic風格動詞的Pascal。

經過六個版本，Visual Basic變得非常漂亮。用戶界面發生了許多變化，但依然保留著「把代碼關聯到用戶界面」的主旨。這使得它在與即時編譯結合時變成了一個快速原型的優異環境。

優點：整潔的編輯環境。易學、即時編譯導致簡單、迅速的原型。大量可用的插件。雖然有第三方的DirectX插件，DirectX 7已准備提供Visual Basic的支持。

缺點：程序很大，而且運行時需要幾個巨大的運行時動態連接庫。雖然表單型和對話框型的程序很容易完成，要編寫好的圖形程序卻比較難。調用Windows的API程序非常笨拙，因為VB的數據結構沒能很好的映射到C中。有OO功能，但卻不是完全的面向對象。專利權。

移植性：非常差。因為Visual Basic是微軟的產品，你自然就被局限在他們實現它的平台上。也就是說，你能得到的選擇是：Windows，Windows或Widnows。當然，有一些工具能將VB程序轉變成Java。

使用Visual Basic編寫的游戲：一些。有很多使用VB編寫的共享游戲，還有一些是商業性的。

資料：微軟的VB頁面有一些信息。

7、Java

Java是由Sun最初設計用於嵌入程序的可移植性「小C++」。在網頁上運行小程序的想法著實吸引了不少人的目光，於是，這門語言迅速崛起。事實證明，Java不僅僅適於在網頁上內嵌動畫 — 它是一門極好的完全的軟體編程的小語言。「虛擬機」機制、垃圾回收以及沒有指針等使它很容易實現不易崩潰且不會泄漏資源的可靠程序。

雖然不是C++的正式續篇，Java從C++ 中借用了大量的語法。它丟棄了很多C++的復雜功能，從而形成一門緊湊而易學的語言。不像C++，Java強制面向對象編程，要在Java里寫非面向對象的程序就像要在Pascal里寫「空心粉式代碼」一樣困難。

優點：二進制碼可移植到其他平台。程序可以在網頁中運行。內含的類庫非常標准且極其健壯。自動分配合垃圾回收避免程序中資源泄漏。網上數量巨大的代碼常式。

缺點：使用一個「虛擬機」來運行可移植的位元組碼而非本地機器碼，程序將比真正編譯器慢。有很多技術（例如「即時」編譯器）很大的提高了Java的速度，不過速度永遠比不過機器碼方案。早期的功能，如AWT沒經過慎重考慮，雖然被正式廢除，但為了保持向後兼容不得不保留。越高級的技術，造成處理低級的機器功能越困難，Sun為這門語言增加新的「受祝福」功能的速度實在太慢。

移植性：最好的，但仍未達到它本應達到的水平。低級代碼具有非常高的可移植性，但是，很多UI及新功能在某些平台上不穩定。

使用Java編寫的游戲：網頁上有大量小的Applet，但僅有一些是商業性的。有幾個商業游戲使用Java作為內部腳本語言。

資料：Sun的官方Java頁面有一些好的信息。IBM也有一個非常好的Java頁面。JavaLobby是一個關於Java新聞的最好去處。

8、創作工具

上面所提及的編程語言涵蓋了大多數的商業游戲。但是也有一個例外，這個大游戲由於它的缺席而變得突出。

「神秘島」。沒錯，賣得最好的商業游戲不是使用以上任何一門語言編的，雖然有人說「神秘島」99%是使用 3D建模工具製作的，其根本的編程邏輯是在HyperCard里完成的。

多數創作工具有點像Visual Basic，只是它們工作在更高的層次上。大多數工具使用一些拖拉式的流程圖來模擬流程式控制制。很多內置解釋的程序語言，但是這些語言都無法像上面所說的單獨的語言那樣健壯。

優點：快速原型 — 如果你的游戲符合工具製作的主旨，你或許能使你的游戲跑得比使用其他語言快。在很多情況下，你可以創造一個不需要任何代碼的簡單游戲。使用插件程序，如Shockware及IconAuthor播放器，你可以在網頁上發布很多創作工具生成的程序。

缺點：專利權，至於將增加什麼功能，你將受到工具製造者的支配。你必須考慮這些工具是否能滿足你游戲的需要，因為有很多事情是那些創作工具無法完成的。某些工具會產生臃腫得可怕的程序。

移植性：因為創作工具是具有專利權的，你的移植性以他們提供的功能息息相關。有些系統，如Director可以在幾種平台上創作和運行，有些工具則在某一平台上創作，在多種平台上運行，還有的是僅能在單一平台上創作和運行。

使用創作工具編寫的游戲：「神秘島」和其他一些同類型的探險游戲。所有的Shockwave游戲都在網路上。

資料：Director、HyperCard、SuperCard、IconAuthor、Authorware。

9、結論

你可能希望得到一個關於「我該使用哪種語言」這個問題的更標準的結論。非常不幸，沒有一個對所有應用程序都最佳的解決方案。C適於快而小的程序，但不支持面向對象的編程。C++完全支持面向對象，但是非常復雜。Visual Basic與Delphi易學，但不可移植且有專利權。Java有很多簡潔的功能，但是慢。創作工具可以以最快的速度產生你的程序，但是僅對某一些類型的程序起作用。最好的方法是決定你要寫什麼樣的游戲，並選擇對你的游戲支持最好的語言。「試用三十天」的做法成為工業標準是件好事情。

G. 如何優化JAVA代碼及提高執行效率

張小喜告別996 實現高效編程 減少開發壓力 開啟Java高效編程之門（完整版高清視頻）網路網盤

鏈接:

若資源有問題歡迎追問~

H. 淺談怎樣加快C++代碼的編譯速度

C++代碼一直以其運行時的高性能高調面對世人， 但是說起編譯速度，卻只有低調的份了。比如我現在工作的源代碼，哪怕使用Incredibuild調動近百台機子，一個完整的build也需要四個小時，恐怖！！！雖然平時開發一般不需要在本地做完整的build，但編譯幾個相關的工程就夠你等上好一段時間的了（老外管這個叫monkey around，相當形象）。想想若干年在一台單核2.8GHZ上工作時的場景 - 面前放本書，一點build按鈕，就低頭讀一會書~~~往事不堪回首。 可以想像，如果不加以重視，編譯速度極有可能會成為開發過程中的一個瓶頸。那麼，為什麼C++它就編譯的這么慢呢？ 我想最重要的一個原因應該是C++基本的「頭文件-源文件」的編譯模型： 1.每個源文件作為一個編譯單元，可能會包含上百甚至上千個頭文件，而在每一個編譯單元，這些頭文件都會被從硬碟讀進來一遍，然後被解析一遍。 2.每個編譯單元都會產生一個obj文件，然後所以這些obj文件會被link到一起，並且這個過程很難並行。 這里，問題在於無數頭文件的重復load與解析，以及密集的磁碟操作。 下面從各個角度給出一些加快編譯速度的做法，主要還是針對上面提出的這個關鍵問題。 一、代碼角度 1、在頭文件中使用前置聲明，而不是直接包含頭文件。 不要以為你只是多加了一個頭文件，由於頭文件的「被包含」特性，這種效果可能會被無限放大。所以，要盡一切可能使頭文件精簡。很多時候前置申明某個namespace中的類會比較痛苦，而直接include會方便很多，千萬要抵制住這種誘惑；類的成員，函數參數等也盡量用引用，指針，為前置聲明創造條件。 2、使用Pimpl模式 Pimpl全稱為Private Implementation。傳統的C++的類的介面與實現是混淆在一起的，而Pimpl這種做法使得類的介面與實現得以完全分離。如此，只要類的公共介面保持不變，對類實現的修改始終只需編譯該cpp；同時，該類提供給外界的頭文件也會精簡許多。 3、高度模塊化 模塊化就是低耦合，就是盡可能的減少相互依賴。這里其實有兩個層面的意思。一是文件與文件之間，一個頭文件的變化，盡量不要引起其他文件的重新編譯；二是工程與工程之間，對一個工程的修改，盡量不要引起太多其他工程的編譯。這就要求頭文件，或者工程的內容一定要單一，不要什麼東西都往裡面塞，從而引起不必要的依賴。這也可以說是內聚性吧。 以頭文件為例，不要把兩個不相關的類，或者沒什麼聯系的宏定義放到一個頭文件里。內容要盡量單一，從而不會使包含他們的文件包含了不需要的內容。記得我們曾經做過這么一個事，把代碼中最「hot」的那些頭文件找出來，然後分成多個獨立的小文件，效果相當可觀。 其實我們去年做過的refactoring，把眾多DLL分離成UI與Core兩個部分，也是有著相同的效果的 - 提高開發效率。 4、刪除冗餘的頭文件 一些代碼經過上十年的開發與維護，經手的人無數，很有可能出現包含了沒用的頭文件，或重復包含的現象，去掉這些冗餘的include是相當必要的。當然，這主要是針對cpp的，因為對於一個頭文件，其中的某個include是否冗餘很難界定，得看是否在最終的編譯單元中用到了，而這樣又可能出現在一個編譯單元用到了，而在另外一個編譯單元中沒用到的情況。 之前曾寫過一個Perl腳本用來自動去除這些冗餘的頭文件，在某個工程中竟然去掉多達了5000多個的include。 5、特別注意inline和template 這是C++中兩種比較「先進」的機制，但是它們卻又強制我們在頭文件中包含實現，這對增加頭文件的內容，從而減慢編譯速度有著很大的貢獻。使用之前，權衡一下。

I. 如何編寫高效android代碼

現代的手持設備，與其說是電話，更像一台拿在手中的電腦。但是，即使是「最快」的手持設備，其性能也趕不上一台普通的台式電腦。

這就是為什麼我們在書寫Android應用程序的時候要格外關注效率。這些設備並沒有那麼快，並且受電池電量的制約。這意味著，設備沒有更多的能力，我們必須把程序寫的盡量有效。

本文討論了很多能讓開發者使他們的程序運行更有效的方法，遵照這些方法，你可以使你的程序發揮最大的效力。

簡介

對於佔用資源的系統，有兩條基本原則：

不要做不必要的事

不要分配不必要的內存

所有下面的內容都遵照這兩個原則。

有些人可能馬上會跳出來，把本節的大部分內容歸於「草率的優化」（xing:參見[The Root of All Evil]），不可否認微優化（micro-optimization。xing:代碼優化，相對於結構優化）的確會帶來很多問題，諸如無法使用更有效的數據結構和演算法。但是在手持設備上，你別無選擇。假如你認為Android虛擬機的性能與台式機相當，你的程序很有可能一開始就佔用了系統的全部內存（xing:內存很小），這會讓你的程序慢得像蝸牛一樣，更遑論做其他的操作了。

Android的成功依賴於你的程序提供的用戶體驗。而這種用戶體驗，部分依賴於你的程序是響應快速而靈活的，還是響應緩慢而僵化的。因為所有的程序都運行在同一個設備之上，都在一起，這就如果在同一條路上行駛的汽車。而這篇文檔就相當於你在取得駕照之前必須要學習的交通規則。如果大家都按照這些規則去做，駕駛就會很順暢，但是如果你不這樣做，你可能會車毀人亡。這就是為什麼這些原則十分重要。

當我們開門見山、直擊主題之前，還必須要提醒大家一點：不管VM是否支持實時（JIT）編譯器（xing:它允許實時地將Java解釋型程序自動編譯成本機機器語言，以使程序執行的速度更快。有些JVM包含JIT編譯器。），下面提到的這些原則都是成立的。假如我們有目標完全相同的兩個方法，在解釋執行時foo()比bar()快，那麼編譯之後，foo()依然會比bar()快。所以不要寄希望於編譯器可以拯救你的程序。

避免建立對象

世界上沒有免費的對象。雖然GC為每個線程都建立了臨時對象池，可以使創建對象的代價變得小一些，但是分配內存永遠都比不分配內存的代價大。

如果你在用戶界面循環中分配對象內存，就會引發周期性的垃圾回收，用戶就會覺得界面像打嗝一樣一頓一頓的。

所以，除非必要，應盡量避免盡力對象的實例。下面的例子將幫助你理解這條原則：

當你從用戶輸入的數據中截取一段字元串時，盡量使用substring函數取得原始數據的一個子串，而不是為子串另外建立一份拷貝。這樣你就有一個新的String對象，它與原始數據共享一個char數組。
如果你有一個函數返回一個String對象，而你確切的知道這個字元串會被附加到一個StringBuffer，那麼，請改變這個函數的參數和實現方式，直接把結果附加到StringBuffer中，而不要再建立一個短命的臨時對象。
一個更極端的例子是，把多維數組分成多個一維數組。

int數組比Integer數組好，這也概括了一個基本事實，兩個平行的int數組比(int,int)對象數組性能要好很多。同理，這試用於所有基本類型的組合。
如果你想用一種容器存儲(Foo,Bar)元組，嘗試使用兩個單獨的Foo[]數組和Bar[]數組，一定比(Foo,Bar)數組效率更高。（也有例外的情況，就是當你建立一個API，讓別人調用它的時候。這時候你要注重對API借口的設計而犧牲一點兒速度。當然在API的內部，你仍要盡可能的提高代碼的效率）

總體來說，就是避免創建短命的臨時對象。減少對象的創建就能減少垃圾收集，進而減少對用戶體驗的影響。

使用本地方法

當你在處理字串的時候，不要吝惜使用String.indexOf(), String.lastIndexOf()等特殊實現的方法（specialty methods）。這些方法都是使用C/C++實現的，比起Java循環快10到100倍。

使用實類比介面好

假設你有一個HashMap對象，你可以將它聲明為HashMap或者Map:

Map myMap1 = new HashMap();HashMap myMap2 = new HashMap();
哪個更好呢？

按照傳統的觀點Map會更好些，因為這樣你可以改變他的具體實現類，只要這個類繼承自Map介面。傳統的觀點對於傳統的程序是正確的，但是它並不適合嵌入式系統。調用一個介面的引用會比調用實體類的引用多花費一倍的時間。

如果HashMap完全適合你的程序，那麼使用Map就沒有什麼價值。如果有些地方你不能確定，先避免使用Map，剩下的交給IDE提供的重構功能好了。(當然公共API是一個例外：一個好的API常常會犧牲一些性能）

用靜態方法比虛方法好

如果你不需要訪問一個對象的成員變數，那麼請把方法聲明成static。虛方法執行的更快，因為它可以被直接調用而不需要一個虛函數表。另外你也可以通過聲明體現出這個函數的調用不會改變對象的狀態。

不用getter和setter

在很多本地語言如C++中，都會使用getter（比如：i = getCount()）來避免直接訪問成員變數（i = mCount）。在C++中這是一個非常好的習慣，因為編譯器能夠內聯訪問，如果你需要約束或調試變數，你可以在任何時候添加代碼。

在Android上，這就不是個好主意了。虛方法的開銷比直接訪問成員變數大得多。在通用的介面定義中，可以依照OO的方式定義getters和setters，但是在一般的類中，你應該直接訪問變數。

將成員變數緩存到本地

訪問成員變數比訪問本地變數慢得多，下面一段代碼：

for (int i = 0; i < this.mCount; i++)mpItem(this.mItems[i]);
再好改成這樣：

int count = this.mCount;Item[] items = this.mItems; for (int i = 0; i < count; i++)mpItems(items[i]);
（使用"this"是為了表明這些是成員變數）

另一個相似的原則是：永遠不要在for的第二個條件中調用任何方法。如下面方法所示，在每次循環的時候都會調用getCount()方法，這樣做比你在一個int先把結果保存起來開銷大很多。

for (int i = 0; i < this.getCount(); i++)mpItems(this.getItem(i));
同樣如果你要多次訪問一個變數，也最好先為它建立一個本地變數，例如：

protected void drawHorizontalScrollBar(Canvas canvas, int width, int height) {if (isHorizontalScrollBarEnabled()) {int size = mScrollBar.getSize(false);if (size <= 0) {size = mScrollBarSize;}mScrollBar.setBounds(0, height - size, width, height);mScrollBar.setParams(computeHorizontalScrollRange(),computeHorizontalScrollOffset(),computeHorizontalScrollExtent(), false);mScrollBar.draw(canvas);}}

這里有4次訪問成員變數mScrollBar，如果將它緩存到本地，4次成員變數訪問就會變成4次效率更高的棧變數訪問。

另外就是方法的參數與本地變數的效率相同。

使用常量

讓我們來看看這兩段在類前面的聲明：

static int intVal = 42;static String strVal = "Hello, world!";
必以其會生成一個叫做<clinit>的初始化類的方法，當類第一次被使用的時候這個方法會被執行。方法會將42賦給intVal，然後把一個指向類中常量表的引用賦給strVal。當以後要用到這些值的時候，會在成員變數表中查找到他們。

下面我們做些改進，使用「final"關鍵字：

static final int intVal = 42;static final String strVal = "Hello, world!";
現在，類不再需要<clinit>方法，因為在成員變數初始化的時候，會將常量直接保存到類文件中。用到intVal的代碼被直接替換成42，而使用strVal的會指向一個字元串常量，而不是使用成員變數。

將一個方法或類聲明為"final"不會帶來性能的提升，但是會幫助編譯器優化代碼。舉例說，如果編譯器知道一個"getter"方法不會被重載，那麼編譯器會對其採用內聯調用。

你也可以將本地變數聲明為"final"，同樣，這也不會帶來性能的提升。使用"final"只能使本地變數看起來更清晰些（但是也有些時候這是必須的，比如在使用匿名內部類的時候）（xing:原文是 or you have to, e.g. for use in an anonymous inner class）

謹慎使用foreach

foreach可以用在實現了Iterable介面的集合類型上。foreach會給這些對象分配一個iterator，然後調用 hasNext()和next()方法。你最好使用foreach處理ArrayList對象，但是對其他集合對象，foreach相當於使用 iterator。

下面展示了foreach一種可接受的用法：

public class Foo {int mSplat;static Foo mArray[] = new Foo[27]; public static void zero() {int sum = 0;for (int i = 0; i < mArray.length; i++) {sum += mArray[i].mSplat;}} public static void one() {int sum = 0;Foo[] localArray = mArray;int len = localArray.length;for (int i = 0; i < len; i++) {sum += localArray[i].mSplat;}} public static void two() {int sum = 0;for (Foo a: mArray) {sum += a.mSplat;}}}

在zero()中，每次循環都會訪問兩次靜態成員變數，取得一次數組的長度。

retrieves the static field twice and gets the array length once for every iteration through the loop.

在one()中，將所有成員變數存儲到本地變數。 pulls everything out into local variables, avoiding the lookups.

two()使用了在java1.5中引入的foreach語法。編譯器會將對數組的引用和數組的長度保存到本地變數中，這對訪問數組元素非常好。但是編譯器還會在每次循環中產生一個額外的對本地變數的存儲操作（對變數a的存取）這樣會比one()多出4個位元組，速度要稍微慢一些。

綜上所述：foreach語法在運用於array時性能很好，但是運用於其他集合對象時要小心，因為它會產生額外的對象。

避免使用枚舉

枚舉變數非常方便，但不幸的是它會犧牲執行的速度和並大幅增加文件體積。例如：

public class Foo {public enum Shrubbery { GROUND, CRAWLING, HANGING }}

會產生一個900位元組的.class文件(Foo$Shubbery.class)。在它被首次調用時，這個類會調用初始化方法來准備每個枚舉變數。每個枚舉項都會被聲明成一個靜態變數，並被賦值。然後將這些靜態變數放在一個名為"$VALUES"的靜態數組變數中。而這么一大堆代碼，僅僅是為了使用三個整數。

這樣:

Shrubbery shrub = Shrubbery.GROUND;會引起一個對靜態變數的引用，如果這個靜態變數是final int，那麼編譯器會直接內聯這個常數。

一方面說，使用枚舉變數可以讓你的API更出色，並能提供編譯時的檢查。所以在通常的時候你毫無疑問應該為公共API選擇枚舉變數。但是當性能方面有所限制的時候，你就應該避免這種做法了。

有些情況下，使用ordinal()方法獲取枚舉變數的整數值會更好一些，舉例來說，將：

for (int n = 0; n < list.size(); n++) {if (list.items[n].e == MyEnum.VAL_X)// do stuff 1else if (list.items[n].e == MyEnum.VAL_Y)// do stuff 2}

替換為:

int valX = MyEnum.VAL_X.ordinal();int valY = MyEnum.VAL_Y.ordinal();int count = list.size();MyItem items = list.items(); for (int n = 0; n < count; n++){int valItem = items[n].e.ordinal(); if (valItem == valX)// do stuff 1else if (valItem == valY)// do stuff 2}

會使性能得到一些改善，但這並不是最終的解決之道。

將與內部類一同使用的變數聲明在包范圍內

請看下面的類定義：

public class Foo {private int mValue; public void run() {Inner in = new Inner();mValue = 27;in.stuff();} private void doStuff(int value) {System.out.println("Value is " + value);} private class Inner {void stuff() {Foo.this.doStuff(Foo.this.mValue);}}}

這其中的關鍵是，我們定義了一個內部類(Foo$Inner)，它需要訪問外部類的私有域變數和函數。這是合法的，並且會列印出我們希望的結果"Value is 27"。

問題是在技術上來講（在幕後）Foo$Inner是一個完全獨立的類，它要直接訪問Foo的私有成員是非法的。要跨越這個鴻溝，編譯器需要生成一組方法：

static int Foo.access$100(Foo foo) {return foo.mValue;}static void Foo.access$200(Foo foo, int value) {foo.doStuff(value);}

內部類在每次訪問"mValue"和"doStuff"方法時，都會調用這些靜態方法。就是說，上面的代碼說明了一個問題，你是在通過介面方法訪問這些成員變數和函數而不是直接調用它們。在前面我們已經說過，使用介面方法（getter、setter）比直接訪問速度要慢。所以這個例子就是在特定語法下面產生的一個「隱性的」性能障礙。

通過將內部類訪問的變數和函數聲明由私有范圍改為包范圍，我們可以避免這個問題。這樣做可以讓代碼運行更快，並且避免產生額外的靜態方法。（遺憾的是，這些域和方法可以被同一個包內的其他類直接訪問，這與經典的OO原則相違背。因此當你設計公共API的時候應該謹慎使用這條優化原則）

避免使用浮點數

在奔騰CPU出現之前，游戲設計者做得最多的就是整數運算。隨著奔騰的到來，浮點運算處理器成為了CPU內置的特性，浮點和整數配合使用，能夠讓你的游戲運行得更順暢。通常在桌面電腦上，你可以隨意的使用浮點運算。

但是非常遺憾，嵌入式處理器通常沒有支持浮點運算的硬體，所有對"float"和"double"的運算都是通過軟體實現的。一些基本的浮點運算，甚至需要毫秒級的時間才能完成。

甚至是整數，一些晶元有對乘法的硬體支持而缺少對除法的支持。這種情況下，整數的除法和取模運算也是有軟體來完成的。所以當你在使用哈希表或者做大量數學運算時一定要小心謹慎。

J. 編譯的代碼優化

代碼優化是指對程序進行多種等價變換，使得從變換後的程序出發，能生成更有效的目標代碼。所謂等價，是指不改變程序的運行結果。所謂有效，主要指目標代碼運行時間較短，以及佔用的存儲空間較小。這種變換稱為優化。
有兩類優化：一類是對語法分析後的中間代碼進行優化，它不依賴於具體的計算機；另一類是在生成目標代碼時進行的，它在很大程度上依賴於具體的計算機。對於前一類優化，根據它所涉及的程序范圍可分為局部優化、循環優化和全局優化三個不同的級別。