功能錯誤小結

最近做了福星轉盤的功能，做完後發現當記錄次數很多了以後會有性能問題，歷史記錄很多的時候，打開會卡。

第一反應

現象：當我看到優化需求的時候，“對歷史記錄做限制”，我第一反應，看下Profiler是什麼，造成性能問題。看到是協程的調用。有出現高峯值，有高達200多M。在多次UI操作中，內存還是穩定增長。

處理：我估計是協程調用產生的，就在每個協程調用前加了StopCoroutine()方法。

問題：高峯值雖然降下來了，但是每次執行高峯值穩定增加20多M。而且最奇怪的是在於每次重啓Unity後，還是會穩定出現這樣的情況。

尋求主程指導（1）

現象:主程同樣在看了Profiler後，給出建議是，用協程播放動畫的效果改成用update執行。在處理以後，任然有內存高峯值出現。而且還是大於允許值6M。高峯值會有60多M，而且還會穩定增加。在關閉界面重新打開頁面的時候，還是會特別卡。會有高達3.5G的GC。
指導建議：用協程播放動畫的效果改成用update執行
處理：兩次動畫播放使用Update()處理。

問題：內存高峯值還存在，打開界面還是卡。這個階段最大的問題在於認爲是Unity有內存泄漏的bug。並沒有想到是很多歷史記錄文字拼接帶來的效率問題。

尋求主程指導（2）

現象:主程在看Profiler後，GameObject.Awake()有高達3.5G的GC。在看了UI界面製作的方式和對應功能配表上給出了優化意見，同時指出我對業務抽象處理不夠。功能靈活性太差了。UI循序是UI策劃那邊排好的，我做的是獲取組件有對應數據做出道具展示。有32個格子需要處理。完全可以抽象到給每一個格子處理。使用一個格子動態創建。還有所謂內外圈的效果，再抽象一層，業務邏輯就服務器根本不用管什麼內外圈，根據權重比得到結果，再去看停留在內外圈的標誌位值，扣除次數。
指導建議：對業務內容可以更抽象一層，UI界面創建，改用動態創建。實例化的格子太多造成卡頓。
處理：根據格子的屬性不同，做不同的顯示控制。動態創建。
問題：即使動態創建，還是有卡頓。關於動畫的播放循序，不得不重新構思，主程給出建議是，完全可以有策劃的配表實現，只要在表格設置Id循序就行。意識到是真正的問題是歷史太長造成的卡頓。

歷史記錄的代碼優化

代碼如下

public void ShowRecord(RecordItem records,int recordTime)
{
  ViewLabel.text = TimeTools.GetUTCTime(recordTime)+"獲得"+"\n";
  string temp;
  PropVo propVo;
  for(int i=0;i<records.Length;i++)
  {
    propVo = new PropVo(records[i].tid,records[i].num)
    temp  = ColorTools.GetColorByStage(propVo.stage)+propVo.getName()+"*"+records[i].num+" 積分"+records[i].integral+"\n"
    ViewLabel.text +=temp;//這句寫的很有問題
  }
}

首先字符拼接會帶來很多GC,在for循環中給UILabel賦值是反覆賦值。特別是records很多的時候，會帶來卡頓。代碼優化如下

public void ShowRecord(RecordItem records,int recordTime)
{
  ViewLabel.text = string.format(GameDic.cfg_Sysetem_tips.getbyId(AlertDict.Tip_10086),TimeTools.GetUTCTime(recordTime)) +"\n";
  string temp,conetxt;
  PropVo propVo;
  for(int i=0;i<records.Length;i++)
  {
    propVo = new PropVo(records[i].tid,records[i].num)
    temp  =string.format(GameDic.cfg_Sysetem_tips.getbyId(AlertDict.Tip_10087,ColorTools.GetColorByStage(propVo.stage),propVo.getName(),records[i].num,records[i].integral)+"\n";
    conetxt +=temp;
  }
    ViewLabel.text = conetxt;

決解歷史記錄太長

現象： 在7次100連抽的後，會有UILabel的顯示問題，“too Many Version on Panel”。UILabel展示範圍超出去了。同時歷史記錄的，協議返回值的長度有8096字節。也就是需要找到合理的值。設計上是500條後，就把之前的全部刪除，問題是每次抽取的長度並不固定。100次的長度肯能是18~26條之間。10次是5~
8之間。在系統策劃商量後，決定爲100條的長度，展示長度值小於100條。
處理:在Service給歷史記錄的List加值，然後再去判斷長度，刪除RemoveAt(0)。反覆操作直到長度小於100.
問題:服務器返回協議最大值超出，服務器調整爲90條。到這裏性能的問題解了。

小結

這個優化的，最初覺得問題出現在動畫上。結果方向還沒有對。在嘗試優化的基礎上，反推發現，性能的問題並沒有解決。從新思考造成問題的方向，確認問題所在，並給出了優化的方案。最終決解問題。
這個功能在開始做的時候，整個構思上，被策劃需求所指引。並沒有做到足夠的抽象處理。造成面對策劃需求變革的時候，不得不重新去更抽象理解整個業務內容。同時因爲前期抽象不夠，造成改動大架構的成本很高。服務器和客戶端都要去改大量的代碼。