关于Native Client

昨天的GDD上听Native Client一知半解，虽然之前也看过相关的video，但还是没清楚其过程和能力，因此今天简单试了一下，一些收获和疑问，记录下来：

• Native Client是通过定制的gcc编译器编译出中间代码（LLVM），然后让该中间代码在浏览器中运行
• 中间代码只和arch相关，而和OS无关，因此只需要有x86-32/x86-64就可以support所有的win/linux/mac，当然现在还没有arm，如果有的话应该就可以support android了
• Native Client并不是什么都能做的，（似乎）它只能调用浏览器提供的API（？），目前也就是所谓的Pepper API了，所以理论上其他浏览器也是可以支持的
• 目前Native Client
• 能够：
• 受限的文件和网络访问（sandbox）
• 音频、2D图像支持
• 鼠标、滚轮、键盘支持
• 不能够
• 串口、camera、microphone
• 3D
• ...
• 所以看起来目前native client的能力还是很有限的
• Native Client的运行还是受sandbox的控制的，比如文件存取、网络访问等等

参考：

http://code.google.com/chrome/nativeclient/

http://johmathe.nonutc.fr/ressources/nacl_paper.pdf (介绍NaCL security模型)

问题在于，既然Native Client能够提供的功能，不管是硬件加速还是访问，通过JavaScript都可以提供，比如WebGL、WebRTC，那为什么还需要Native Client呢？

我能想到的解释在于：Native Client主要是解决了JavaScript对于计算密集型的不足，比如3D game里计算坐标变换，这些WebGL是没法把所有的事情都封装起来的，如果通过JS那肯定是不靠谱的。

另一个优势可能在于现有代码的移植，但这个优势不是太明显，毕竟现有代码只要涉及到系统操作的，可能都无法移植，还是要通过Pepper API改写（但毕竟还是有很多代码，比如3D计算库，是很容易移植而且很有用的）。

所以，Native Client并不会带来硬件访问能力上的改进，而只会带来CPU计算的改进，但代价是潜在可能的安全漏洞（没有仔细读那篇安全模型的paper，但既然引入二进制执行，特别还是C/C++这种有所谓pointer这样威力巨大的东西，猜测一定还是引入很大的risk的，比如buffer overrun什么的，有兴趣的可以研究研究），不知道意义究竟有多大。

有谁能告诉我未来的3D Web Game究竟是WebGL，还是Native Client？我不知。。。