秋招第一次面試，涼的透透的，面試還死機了。。 記錄一下吧
1：Unicode和UTF-8的區別
Unicode 是一個很大的集合，現在的規模可以容納100多萬個符號，每個符號的編碼都不一樣。Unicode 只是一個符號集，它只規定了符號的二進制代碼，卻沒有規定這個二進制代碼應該如何存儲。
UTF-8是目前使用最廣的一種Unicode的實現方式。它最大的特點就是變長編碼的方式，采用了1~4個子節來表示一個符號，根據不同的符號而變化字節長度。
UTF-8的規則：
（1) : 對於單字節的符號，字節的第一位設置為0，后面7位位這個符號的Unicode編碼。因此對於英文字母，UTF-8和ASCII碼是一樣的。
(2) : 對於n字節的符號，第一個字節的前N位設置為1，第n+1位設置為0，后面字節的前兩位一律設置為10。剩下的沒有提及的二進制位全部設置為這個符號的Unicode
所以總結來說，UTF-8便阿門就是如果一個字節的第一位位0，則這個字節單獨就是一個祖父，如果是1，那么連續多少個1就表示它占用了多少個字節。
2：unity的靜態合批和動態合批
靜態合批：在場景里面有有一些共享同一材質的模型存在，並且這些模型都一直不會移動，旋轉和縮放那么就設置這些模型為static。
在build的時候，unity會將這些共享材質的靜態模型的vertex buffer和index buffer，根據他們在場景的最終狀態的信息，將模型的頂點轉化為世界坐標下，儲存在大的Vertex buffer和index buffer。並且記錄子模型的index buffer數據在大的buffer的起始位置和結束位置。在后續的繪制中，一次性提交合並模型的數據，根據場景管理系統判斷子模型的可見性然后設置一次渲染狀態調用多次draw call分別繪制一次模型。
由於控制的時候使用的是index buffer，所以起到了降低draw call的效果而且子模型的頂點數據已經變化到了世界坐標下，共享材質所以多次draw call下沒有渲染狀態的切換起到了優化的目的。
靜態合批也會帶了一些負面影響，比如打包后體積增大，運行時占用更多的內存。當有許多不同的game object引用一個模型的情況下，共享模型只會在內存中保存一份，如果開始batch static，那么在build的時候會復制所有的game object引用的模型，導致體積增大。
面試的時候問到了動態合批的頂點限制和原因，當時寫合批工具的時候只是簡單看了一下，原因沒有搞明白所以沒答上來。
動態合批：動態合批在每一幀都會有一些CPU的性能消耗，如果開始了dynamic batching，unity會自動把所有共享了同一個材質的game object在一個draw call繪制
動態合批的原理：進行繪制之前將所有的共享同一個材質的模型的頂點信息變換到世界空間中，通過一次draw call繪制多個模型達到合批的目的。由於坐標變換是由CPU進行操作的，所以會帶來一些性能消耗，所以計算的模型頂點數不能太多，否則CPU串行計算耗費的時間太長會造成卡頓。目前unity限制dynamic batching的模型最高含有900個頂點屬性。而不是頂點。
3 ：new和malloc的區別