1）luajit效能熱點函式優化
2）unity 2019.4打包android疑問
3）rendertexture.gettemporary報錯問題
4）waitfortargetfps耗時太高
5）particlesystem.main的有效性
uwa 問答社群：answer.uwa4d.com
uwa qq群2：793972859（原群已滿員）
q：諮詢專案中的這個函式耗時非常嚴重，有什麼優化的方法嗎？
a1：這個是table.get，對應獲取字段或者訪問陣列時呼叫的函式：感謝招文勇@uwa問答社群提供了回答自己開發工具，在編譯lua之前，將lua**中的常量從英文名變數轉換為數值，這個可以結合1使用，就可以在開發期寫英文名字段名，然後編譯時轉換為陣列。
a2：字串應該是雜湊值計算的消耗，這樣的開銷應該是很頻繁地呼叫了。感謝王歡@uwa問答社群提供了回答
a3：同意你的觀點，但可讀性變差了，得不償失。第二點，可能比較容易出錯。感謝robot.huang@uwa問答社群提供了回答q：unity版本由2018.4.0f1公升級到2019.4.5f1，其中android的custom manifest、custom gradle template都拆分為了兩個，分別為main和launcher。之前對接的各個android sdk感覺需要重新做了。請問有比較熟悉的，可以指點一下這裡嗎？我們之前各個sdk都是以jar和aar的形式直接放在unity工程內，直接unity出包，現在直接build會有各種報錯，感覺是不相容之前的格式了。
a1：我們也遇到了外部編譯的aar內的manifest和unity內的manifest衝突問題。由於2019其實是可以直接編譯j**a的，我們乾脆取消了外部工程，直接把j**a**和oc的**放入unity工程，然後只使用unity內的manifest，就沒有衝突錯誤了。感謝黃程@uwa問答社群提供了回答之後有時間也準備試試黃程大佬的方法。我們專案是2017的，當時記得mm可以，但是j**a不行。後來用2018開的其他專案因為暫時沒遇到類似需求，就沒試，最近另外乙個專案直接2019來做就這樣對應了。
感謝題主張斌@uwa問答社群提供了回答
q：使用gettemporary這個方法進行資源的建立時，發生了這個錯誤：argumentexception: rendertexturedesc width must be greater than zero.
望各位賜教。請問這部分源**在**可以看到？
a：源**：感謝羽飛@uwa問答社群提供了回答q：使用gpm檢視專案效能，發現waitfortargetfps耗時太高，均值在20ms左右。網上查詢說是因為開了垂直同步的問題，按照網上的解決方式重新打包過後，並沒什麼效果。引數width不能小於等於0。
其實這個只是cpu在等待螢幕重新整理，有這個「消耗」其實是好事，說明cpu和gpu的負載不高，發熱不厲害。
感謝張首峰@uwa問答社群提供了回答
a2：你可以看看unity官網文件上關於waitfortargetfps的解釋。感謝tyer@uwa問答社群提供了回答q：main為struct值型別的唯讀屬性，在不重新設定回物件欄位的情況下修改有效。請問各位大佬，在執行時進行屬性修改操作時，這種機制的底層實現原理是什麼？
a1：可以參考《particle system modules – faq》感謝jim@uwa問答社群提供了回答
a2：個人理解是，這個是乙個包property的結構體。每個property的get和set又指向的內部子模組的引數。感謝歐月松@uwa問答社群提供了回答所以操作這些property就直接操作到了內部的子模組。
a3：mainmodule這個結構體就是乙個對native介面的封裝。感謝羽飛@uwa問答社群提供了回答封面圖**於網路
今天的分享就到這裡。當然，生有涯而知無涯。在漫漫的開發周期中，您看到的這些問題也許都只是冰山一角，我們早已在uwa問答**上準備了更多的技術話題等你一起來探索和分享。歡迎熱愛進步的你加入，也許你的方法恰能解別人的燃眉之急；而他山之「石」，也能攻你之「玉」。
官網：www.uwa4d.com
官方技術部落格：blog.uwa4d.com
官方問答社群：answer.uwa4d.com
uwa學堂：edu.uwa4d.com
官方技術qq群：793972859（原群已滿員）
效能優化 函式節流
專案中遇到乙個需要實現文字拖動的效果，用mousedown mousemove mouseup模擬拖動效果。但是實現的效果並不是很理想，原因是mousemove是乙個高頻事件，觸發的頻率非常高，會造成瀏覽器的效能問題。高頻觸發事件，對執行函式進行節流可以節省瀏覽器資源，以免造成不必要的效能浪費。具體...
js效能優化之分時函式
分時函式和函式節流的問題不一樣，函式節流針對的事件不是使用者主動呼叫的，前面已經提過了。函式節流的原理是 延遲當前函式的執行，如果該次延遲還沒有完成，那麼忽略接下來該函式的請求。也就是說會忽略掉很多函式請求。分時函式處理的問題是使用者主動呼叫的，比如插入千百個節點 var arr for var i...
js效能優化之函式節流 分流函式
比如我們在window.onresize事件中要列印當前瀏覽器視窗的大小，在我們通過拖拽來改變視窗大小時候，列印視窗大小這個工作1s就執行了10次。而實際上我們只需要2次或者3次。比如這行 window.onresize function 實現的思路就是將即將被執行的函式用settimeout延遲一...