本人主要從事遊戲後端開發，所以本文只從遊戲開發角度分析erlang使用中應注意的問題和優化點。
單節點還是多節點
2. 訊息廣播
訊息廣播是遊戲中的效能消耗大頭，主要包括地圖的行走、pk廣播，世界聊天廣播。世界聊天廣播可以通過cd等策劃手段限制，行走和pk包的廣播實時性高，只能通過技術手段解決。地圖中的廣播包,只需發給視野內的玩家就可以，不用全地圖廣播。視野內的玩家可以通過九宮格劃分，以 x,y為主鍵，對映到對應的玩家資料。以九宮格方式查詢玩家非常高效，我第乙個遊戲，地圖中的玩家起初是儲存在乙個列表中，每次廣播時都要遍歷列表，找出同屏玩家，訊息廣播非常低效，特別是在pk時，cpu占用高。用九宮格優化後，一切問題都解決了。還有乙個優化廣播問題的方法是資料報快取。
3. 快取-資料庫，網路
快取是用空間換時間，它是效能優化中常用的方法。資料庫快取，開服時把玩家的必要資料載入到記憶體中，可以減少玩家的登陸延時，應對玩家併發登陸，重新整理也很有效。同時玩家資料沒必要實現存庫，對於座標，經驗，金錢等變化頻繁的值，如果實時存在，會很容易壓跨資料庫或對存庫程序造成訊息阻塞。玩家改變的資料可以緩在記憶體中，定時存庫，或下線時再存庫。網路中的訊息包也可以在應用層給快取起來，達到一定長度或延時一定時間後再發出去。雖然虛擬機器和tcp層會做快取，最好還是在應用層做一次快取。
4. 程序-每玩家應該有幾個程序
其實每玩家乙個程序已經足夠，**簡單，方便維護，效能開銷小。沒必要為每個玩家開啟了網路，物品、任務等程序，多個程序不但造成程序間通訊開銷，還不好維護。
5. 善用程序字典
erlang中是不建議用程序字典的，但程序字典是資料訪問最快的方式，對於遊戲這種高效能要求的應用，程序字典是不二的選擇。使用程序字典時要切記在對應的程序中操作，最好按功能把put,get操作封裝到模組介面中，避免誤用。
6. **規範
a. **應該簡單，邏輯清晰，把功能細分到函式中。函式一般不多於30行，每個模組不多於1000行。
b. 寫尾遞迴函式一定要有清淅的退出條件，不要在函式中改變退出條件。乙個退出條件不明確的尾遞迴，是造成訊息阻塞，記憶體耗盡的主要原因之一。
erlang
%% 乙個明確的尾遞迴函式:
loop([h |t]) ->
do_something,
loop(t);
loop() ->
ok.%% 存在錯誤風險的寫法
%% newliist不可預期，存在死迴圈風險
loop([h | t]) ->
newlist = do_something(h,t),
loop(newlist);
loop() ->
ok.c. 不要相信客戶端,上行的資料都需要驗證，前端的請求都要做合法性判斷，防止出現外掛程式、刷錢刷物品、刷金幣的情況。
d 不要寫過多的case ,if巢狀，最好不要大於3個巢狀，通過 try catch 方法寫扁平化的**。
7. 自動化工具
自動化工具可以避免出錯，還把開發人員解放出來，提高生產效率。對於重複性，有規律的**(如資料訪問，通訊協議)，可以分離出來，讓工具自動生成。有了生成工具後，修改協議，新加字段等操作，簡單方便，不用為增加資料表中乙個字段，而改十多個函式介面的修改;也不用擔心前後端協議不一致的問題。
8. 監控系統
通過erlang:system_monitor/2，監控系統long_gc，large_heap等情況。
9. 效能分析工具
準備好top memory,top message_queue等檢視系統屬性的工具，出問題時可以隨時檢視。
（遊戲執行效能）優化
當基本遊戲功能到位時，就要確保遊戲執行表現能夠達標。我們衡量遊戲執行表現的乙個基本工具是unity內建分析器以及xcode分析工具。使用unity分析器來分析裝置上的執行 真是一項寶貴的功能。我們總結了這種為將目標裝置的幀率控制在60fps而進行衡量 調整 再衡量過程的中相關經驗。一 遇到麻煩時要呼...
Flex遊戲程式設計效能優化
1.首先，元件的座標必須是整數 x 整數 y 整數 2.對於按鈕元件啟用cache as bitmap，會生成四個位圖 對不需要使用disable屬性的按鈕，盡量使用 button，因為4.避免for var i int 0 i arr.length i 的寫法，先用var i int arr.le...
遊戲效能優化（基礎）
資源在遊戲中會大量頻繁地使用，而在記憶體中是按照2的冪次方來載入的，例如一張大小是2020畫素的，在程式執行中是按照3232來處理的，而且從磁碟上載入每一張都屬於io操作，非常耗費cpu時間，尤其是在android的低端裝置上。所以通過打包工具 例如texturepacker 把多張小合併到一張大圖...