認識cocos2d-x jsbinding

     近年來HTML5風起雲涌，特別在移動端已經被更多的人熟識。H5跨平臺，在線更新等特性，被人們津津樂道。而後就出現了各類H5的框架，甚至多達100種，真是讓開發者眼花繚亂，筆者做爲一個從事H5遊戲開發一年的開發者，從我這一年的摸索，比較，最終選擇cocos2d-x jsbinding(如下簡稱jsb)做爲移動遊戲開發框架，並在接下來的幾篇博文中慢慢講述一些我對這個框架的認識和感覺。

　　就目前來說，移動端的框架最火，最牛叉的非cocos2d-x莫屬，甚至達到了每上10款手遊，7款是cocos2d-x的境界。jsb做爲cocos2d-x的javascript腳本調用版本，保持了cocos2d-x的穩定，高效率的同時，能和cocos2d-html5無縫結合，真正作到了一套代碼，多個平臺運行，而且在移動平臺保持了100%原生效率的這樣一個品質。能夠說是目前html5在移動端最好的解決方案。如今相似的Hybird引擎有很多了，有uc的X-canvas，opera的sphinx,ludei,game closure,還有即將發佈的youzi2d，這些引擎都有一個特色，硬件加速，由於如今Html5最大的瓶頸就是效率，那jsb和這些框架比起來，究竟怎麼樣呢？如下從我使用的角度來說，列出了幾點，我的意見，僅供參考。　　

      1.執行效率。上面提到的效率問題，這個天然是jsb的重點。主要分爲2塊，一塊是圖形渲染的效率。還有一塊是腳本執行效率。上述幾款框架都宣傳的是100%硬件加速，可是這裏面的加速效果並非相同的，jsb的圖形渲染效率和cocos2d-x是等同的，以小米1手機爲例，jsb同屏跑600個動畫(沒有用批渲染，真正的600次draw)，幀數在45幀左右，900個動畫是35幀左右，一樣的手機在跑sphinx下面的一個打飛機demo，幀數在48幀左右，打飛機中的同屏幕精靈不超過100個，x-canvas沒有深刻研究，可是跑過一個裏面的切水果，切中的瞬間會有明顯的卡頓，我不知道是否是渲染的問題，對x-canvas熟悉的童鞋也能夠畫上600個動畫看看幀數。

     js腳本效率這塊，jsb用的是firefox的開源spidermonkey，android環境開啓了JIT。實際用的狀況是夠用，可是要當心的用，特別是大的循環要避免，例如大配置文件循環。若是其餘框架用的是google的V8引擎的話，會比spidermonkey要快，可是有一點，ios是不能開啓JIT的，因此ios環境V8是用不了的，由於V8是強制開啓JIT的。另外有一點是，jsb支持物理引擎，但這個也是用js來調用C++的chipmunk庫的，這樣保證了效率。

      2.跨平臺。得益於cocos2d-x，如今通吃市面上全部安卓機器，舊的如幾年前的單核國產機，到如今最新的三星S4，ios天然是包括ip4以上的全部機型和全部pad。聽說wp也立刻要併入cocos2d-x主分支。除此以外，得益於cocos2d-html5，上述一套一樣的js代碼，還能夠運行於支持H5的瀏覽器環境，手機端的瀏覽器只要是支持H5特性的都能跑，例如ios的safrai，chrome，uc，海豚瀏覽器，qq瀏覽器，可是移動瀏覽器的渲染能力有限，相對於native來講，性能差距仍是不小的。

      3.開源。MIT協議的開源引擎意味着什麼？意味着你能夠任意擴展你須要的底層接口，能夠知足任意需求，只要原生可以實現。同時你能夠打斷點跟蹤bug，這個打斷點並非要去修改cocos2d-x的代碼，這麼作的目的是爲了能更高的瞭解底層庫的運做方式，從而來優化調節咱們調用的邏輯代碼，還能快速定位bug，固然這個前提是你要對cocos2d-x的代碼有必定的熟悉，好在cocos2d-x的源碼寫的很是優秀，就算是學習的角度來說，也是很是值得看的。

      4.本地打包。配好了環境之後（建議用mac環境）能夠完成打包測試，發佈等部署，加入第三方渠道SDK，徹底由本身掌控。本地打包是相對於雲端打包而言的，由於上述不少框架只能雲端打包，雲端打包方即是挺方便的，可是必須保證這個雲端服務器是100%穩定的，否則到時候你想打包的時候服務器掛了，那你只能等待了。同時雲端打包接入的第三方SDK是固定的，若是要加個雲端沒有提供SDK接口的渠道，那這個需求就實現不了了，因此我的認爲雲端打包比較適合我的開發者或者小型開發團隊。

      5.調試。調試是開發程序的重頭戲，jsb的調試不太理想，手機端的調試只能打log，好在有cocos2d-html5。cocos2d-h5的api是向下兼容jsb的，能夠這麼說，95%的問題，在網頁上用cocos2d-h5就能夠解決，剩下的5%。。只能在手機上調了，這個看我的對這個2d-x這個框架的熟悉程度。聽說下一個jsb版本能夠斷點調試了，源碼中也已經有好多關於debug功能的代碼，相信這個功能不遠了。

      6.原生接口。實際開發手遊的時候須要不少和手機原生的接口，jsb在這裏提供了CCEditbox(輸入框),CCFileUtil(手機物理文件讀取)，網絡這塊支持xmlHttpRequest,websocket。值得一提的是websocket還支持arrayBuffer格式，能夠直接傳輸二進制數據，不用作額外的轉換，除此以外的接口須要本身寫了,好比獲取網絡狀態（3G，wifi）,獲取androidSD卡目錄等等，這個看每一個項目的具體需求來，由於jsb採用spidermonkey編譯器，只要是C++能夠調用到的接口，js均可以調用到。具體android能夠用JNI和C++進行通訊，而後C++再和js通訊，ios是OC和C++混編的，因此接口寫起來更加容易，以後的博文會詳細介紹,網上這方面資料也不少。

      7.源碼保護。雖然是腳本，可是若是被人輕輕鬆鬆拿去看了，做爲一個商業手遊項目來說，仍是不太提倡的，特別是配置文件若是也採用的是js的話。。jsb除了常規的js壓縮混淆外，還有個終極大殺器:bytecode。jsb經過一個工具將js腳本編譯到spidermonkey直接讀取的bytecode，這樣既加快了腳本加載速度又解決了腳本的安全問題，就算你能想辦法破解bytecode，破解完的仍是混淆過的js腳本，利用價值大大下降。

      8.社區活躍度。cocos2d-x的論壇（包括jsb）比較活躍的，天天有全球各類開發者討論問題，jsb這塊有核心開發者天天維護，基本上是有問必答，可是qq羣好像不太活躍，可能你們都在埋頭幹活吧。

      上面講了這麼多和其餘H5框架的比較，再來講說和cocos2d-x自己的比較。

      js是cocos2d-x支持的另外一種語言lua同樣，都是腳本語言，腳本語言最大的特色在於在線更新。在appstore這個審覈至少1周的狀況下，在線更新給了遊戲很大的選擇權利。雖然這種作法蘋果並非所推崇的，可是無論你信不信，如今新的手遊愈來愈多的用到在線更新，靈活的版本發佈用過了都說爽。除此以外，遊戲邏輯腳本由於相對少的涉及C++，因此crash的概率相對比C++要少一些，至少目前的觀察如此，固然前提是要有高的腳本代碼質量，並非由於腳本就能夠隨便亂寫，一段js代碼不一樣的寫法甚至有10倍，100倍的性能差距。

      相比兄弟腳本lua，js的優點是面向對象，和網頁版。可能也有人說面向過程也能夠一樣寫好遊戲，這個確實沒錯，可是大多數開發者的思惟仍是面向對象爲主。至於網頁版，除了調試的方便，至少還多了一個平臺，雖然如今手機網頁這塊支持的並非太好。至於js的劣勢，那就是js實在太靈活，因此相比lua的話仍是要犧牲一點性能，另外js的編譯器十分複雜，通常的人駕馭不了他的源碼，可是按照api調用方法仍是沒什麼問題的。

      以上只是一點對jsb的認識，若是你正在項目框架選型的話，但願可以給你一點幫助。