是否可以用Unity制作App？

Unity確實可以用來制作App。Unity是一個強大的跨平臺游戲開發(fā)工具，不僅可以輕松創(chuàng)建三維視頻游戲，還能用于制作交互性強、虛擬現(xiàn)實等類型的App。雖然Unity的主要功能偏向于游戲開發(fā)，但現(xiàn)在有很多開發(fā)網(wǎng)站也提供使用Unity制作App的功能。相對于傳統(tǒng)的App開發(fā)方式，使用Unity制作的App可能較少涉及復(fù)雜的3D元素。

Unity開發(fā)App與H5雙端項目的風險評估

一、Unity與H5雙端支持概述

當前項目涉及雙端（App+H5）開發(fā)，需要使用Unity這一強大的游戲引擎結(jié)合H5技術(shù)。這為我們帶來了豐富的互動體驗與跨平臺兼容性，但同時也伴隨著一系列的風險與挑戰(zhàn)。風險評估涵蓋了Unity版本、H5支持、瀏覽器兼容性等多個方面。

二、技術(shù)風險評估

從Unity自5.x版本開始支持H5發(fā)布，但不同瀏覽器的支持度存在差異。在實際應(yīng)用中，部分手機的微信端瀏覽器及蘋果手機的Safari內(nèi)核對H5版本的運行有一定限制。網(wǎng)絡(luò)架構(gòu)、資源加載、熱更新等方面也存在潛在風險。特別是在資源加載策略上，首次進入游戲加載圖集、角色引導(dǎo)按需加載等都可能成為挑戰(zhàn)。H5對資源大小、內(nèi)存使用以及Drawcall都非常敏感。

三、熱更新與插件兼容風險

在熱更新方面，App端需要周全考慮，而H5版本則可通過HTTP請求版本號進行解決。但Shader使用存在局限性，需要針對性設(shè)計驗證。對于帶有dll的Unity插件，轉(zhuǎn)換為H5格式可能會遇到困難。H5版本不支持Unity的System.Threading包，這可能對網(wǎng)絡(luò)部分產(chǎn)生影響，建議使用WebSocket作為替代方案。

四、其他潛在風險點

靜態(tài)編譯的Unity發(fā)H5版本不支持動態(tài)生成代碼。雖然觸摸輸入在Unity中支持良好，但如果涉及復(fù)雜的第三方模塊和多線程應(yīng)用，如本地SQLite、騰訊的behavic等，可能會面臨額外的挑戰(zhàn)。登錄過程也可能因單機弱聯(lián)網(wǎng)而變得復(fù)雜，需要額外考慮登錄重連狀態(tài)管理。在決定將項目轉(zhuǎn)為H5版本之前，需要全面評估這些風險點。

五、總結(jié)與展望

雖然使用Unity開發(fā)App與H5雙端項目具有巨大的潛力與優(yōu)勢，但也伴隨著諸多風險和挑戰(zhàn)。隨著Unity對H5支持的逐步完善，開發(fā)者應(yīng)緊跟最新版本以應(yīng)對可能出現(xiàn)的風險。對于當前項目來說，如果包含大量第三方模塊和多線程應(yīng)用，可能暫時不適合推出H5版本。建議先確保App端的成熟穩(wěn)定，再考慮將H5版本作為補充推出?？傮w來說，xlua的熱更方案具有很大的潛力與優(yōu)勢，對于解決熱更新需求非常有價值。隨著技術(shù)的不斷進步與應(yīng)用場景的需求變化，期待Unity能進一步加強對H5的支持與優(yōu)化。開發(fā)者也需要不斷提升自身技能與知識積累以適應(yīng)這一變化與發(fā)展趨勢。云風主導(dǎo)下游戲開發(fā)語言選擇背后的理念變遷——從腳本到熱更新

===================================

一、初入網(wǎng)易與腳本的選擇

在我于04年加入網(wǎng)易工作之時，游戲開發(fā)主要圍繞著腳本進行，不論是客戶端還是服務(wù)器端。當時使用的腳本語言并非現(xiàn)今流行的Lua或Python，而是一種類似C語法的腳本（具體名稱已遺忘）。云風主導(dǎo)的這一決策背后的初衷并非單純?yōu)榱藷岣拢浅鲇诙喾矫娴目剂俊?/p>

二、劃分權(quán)限與業(yè)務(wù)層技術(shù)架構(gòu)

采用腳本作為邏輯開發(fā)語言的核心目的之一是劃分引擎層和業(yè)務(wù)層，通過svn管理權(quán)限。這樣，新加入的開發(fā)者無法接觸到核心引擎的代碼權(quán)限，他們的工作被限定在腳本層。隨著對業(yè)務(wù)熟悉和對引擎了解的加深，以及對公司忠誠度的建立，才會逐步開放引擎層代碼。這一做法的初衷是為了解決私服問題。早些年，有同學拿著全部源代碼去架設(shè)私服，這無疑給公司帶來了巨大的風險。通過權(quán)限劃分和特殊的管理方式，確保公司業(yè)務(wù)的安全性和穩(wěn)定性。

三、追求安全：避免全局崩潰與反外掛的挑戰(zhàn)

避免書寫不良的C、Cpp代碼導(dǎo)致整個進程崩潰是選擇腳本的另一個重要原因。腳本代碼出錯最多影響局部邏輯，并且可以上報腳本錯誤，為后續(xù)解決問題提供方便。與Unity中的C代碼相比，書寫不好的C代碼可能會直接導(dǎo)致閃退，而使用腳本如Lua則可以構(gòu)建一個更加安全的調(diào)用層。早年P(guān)E脫殼、反編譯工具的盛行使得反外掛成為一大挑戰(zhàn)。通過腳本的使用，中間代碼可以通過修改opcode、加密等技術(shù)確保進程空間內(nèi)的安全性，給外掛作者帶來很大的挑戰(zhàn)。網(wǎng)易的游戲在反外掛方面一直做得很好，這背后離不開腳本語言的選擇與使用。

四、編譯速度與代碼修改效率

早年Cpp代碼的編譯速度較慢，修改一行代碼后調(diào)試運行可能需要很長時間。相比之下，腳本代碼的修改更加便捷，可以快速跑起來而不用等待。這對于提高開發(fā)效率、快速迭代和優(yōu)化產(chǎn)品至關(guān)重要。iOS平臺上的text size限制也是考慮因素之一。過多的stub function會增大text size，而Lua腳本則不受此限制，能更加靈活地適應(yīng)不同的開發(fā)需求。

五、“熱更新”背后的技術(shù)革新

雖然熱更新在當今的游戲開發(fā)中扮演著重要角色，但在早期，熱更新并非主要動因。當時的技術(shù)實現(xiàn)是在每次客戶端啟動時，通過一個launcher從服務(wù)器下載一個update并應(yīng)用，而非現(xiàn)今所謂的“熱更新”。隨著技術(shù)的進步和需求的演變，熱更新逐漸成為了游戲開發(fā)中不可或缺的一部分。

從網(wǎng)易早期使用腳本作為游戲開發(fā)語言的選擇背后，我們看到了多方面的考量和技術(shù)革新的步伐。從劃分權(quán)限、追求安全、提高開發(fā)效率到熱更新的技術(shù)革新，每一步都是基于實際需求和技術(shù)發(fā)展而做出的明智決策。