近年來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的認識，如果你正在項目框架選型的話，希望能夠給你一點幫助。