》層級處理

    1）地圖 、 UI 層級處理

             UI攝像機有五個，camera的depth從49-56。地圖的要在所有UI之下，所以depth設為48。

    2）UI，特效層級

          特效要夾在在UI之間，所有特效之下的UI的RenderQ改成StartAt調到2600。

    3）Camera depth、panel depth、width depth 、renderQ關係

               Camera的Depths是指不同相機之前的深度屬性，在渲染順序的優先度裡面是最高的，Depth越大，渲染的影象越靠前，和空間無關。

              StartAt：如果AB兩個panel，A panel顯示在前，那麼A panel的Start At值就是B panel 的Start At值加上B panel的Drawcall數量。如下圖：

             panel depth：RenderQueue.Automatic從3000開始計算。StartAt是從設定的值開始計算。

            當我們不選擇Automatic時，Panel的Depth對於Panel的渲染層級已經沒有任何影響了。如下圖：

             panel depth的優先順序高於width depth。

           首先如果一個Panel中包含多個Drawcall，這些Drawcall的Renderqueue是由其渲染的Wiget的Depth決定的。其次，Wiget的Depth只會影響同一個Drawcall中的Wiget層次（不同Drawcall還是由Drawcall的Renderqueue決定）。原來Wiget的Depth是通過影響Drawcall中的頂點快取序列來達到影響層級的效果的。NGUI的一個Drawcall中包含一個Mesh, 它是由Drawcall內所有Wiget的頂點資訊生成的，頂點資訊儲存的順序是由Depth決定的，越靠後的層級就越高。（注：所以遊戲中改變Wiget的Depth可能會導致Mesh重新生成相當影響效率）

》預設的Layer處理

       地圖有單獨的攝像機，而且地圖的座標和 NGUI都在 原點處，地圖的座標又不能改等，否則會影響地圖的定位座標，邏輯封裝在了sdk內部。所以地圖要用一個獨立的layer，否則會出現和其他物體穿插的問題

》LBS資源的管理

             地圖是通過Resource載入的。因為Resource中的所有內容都會被打包到包裡，所有Resource裡只留Data 和 Prefab。引用的Materials如果也放在Resources裡會不會變成打包雙份？

》手勢處理

    雙指滑動

    四種手勢

》基於json的網路訊息

》資料驅動邏輯

》座標轉換

》100個人快取 重新整理 優化

        將所有收到的資料一次快取到一個list裡。從最前端插入。

        從前向後遍歷，剔除id重複的人。

       因為只快取100個人，然後剔除索引100之後的人。

》單點多人的散開處理

當在同一座標點出現多個人的時候會疊加在一起，要把這些人的經緯度散開。

      演算法思想：

          新建一個空列表。

       local nearbyList ;   --收到的伺服器傳來的附近的人100個

       local spreadList = {} --散開後的列表

       local offsetList;   --散開偏移量列表，目前定義了37個散開偏移量，圍繞中心點的多個方型結點

       for i = 1, #nearbyList do

              isInserted = false

              for j = 1, #offsetList do

                     if  (nearbyList[i]經緯度  + offsetList[j]偏移量) 和 spreadList 裡的所有結點的距離都大於某一值 then

                            table.insert(spreadList, nearbyList[i])

                            isInserted = true

                            break

                     end

              end

              if  isInserted == false then --暫時只設置了37個偏移量，如果單點超過37個，會出現散不開的情況，就直接顯示原始位置

                        table.insert(spreadList, nearbyList[i])

              end

     end

》公司位置處轉移到附近的某大學。

       公司裡的人員特殊處理，為了不暴露公司內部玩家。

》手機定位伺服器關閉的識別。

     兩個開關，手機系統定位的總開關 和 每個應用的單獨開關。

     Input.location.isEnabledByUser 對應的是總開關，當總開關關閉的時候，值為false。開啟時值為true。

     Input.location.status 是定位的當前狀態，有四種。總開關開啟狀態 值始終未 Stop， 總開關關閉狀態值為Failed。這樣無法判斷當前應用是否開啟了定位，只有呼叫了Input.location:Start()方法，值才會有對應的變化。當應用開關是關閉狀態時，值始終為Initializing，當應用開關是開啟狀態時在幾秒後會變為Running，不同手機的響應時間不同，所有我設定的是20秒。在地圖關閉的時候呼叫Input.location:Stop()來關閉定位，節省電力。其實騰訊的地圖sdk和手機的定位開關關係並不大，策劃要求捆綁在一起，也是調了好一會才弄好。

》騰訊地圖的墨卡託座標

不依賴於手機的定位開關的開關。

墨卡託(Mercator)投影，又名“等角正軸圓柱投影”，荷蘭地圖學家墨卡託（Mercator）在1569年擬定，假設地球被圍在一箇中空的圓柱裡，其赤道與圓柱相接觸，然後再假想地球中心有一盞燈，把球面上的圖形投影到圓柱體上，再把圓柱體展開，這就是一幅標準緯線為零度（即赤道）的“墨卡託投影”繪製出的世界地圖。

》NGUI UIGrid 在列表沒鋪滿還能滾動問題。

》關注列表的迴圈滾動效率

》android 9.0系統的Api不相容

用Unity的定位API的話，在9.0系統裡start後，使用返回的status是Initializing。所以最後選擇改用sdk裡的獲取座標的api，如果沒獲取到座標就認為定位沒開啟。開始的時候想自己寫一套通過android 或 ios自己的api判斷定位的，時間不充裕，所喲沒寫。現在一想，直接用sdk裡的獲取座標的介面，通過獲沒獲取到來判斷就可以了。sdk肯定要相容 安卓9.0的吧。