Shared vs. embedded mode
共享模式和嵌入式模式对比
在我们使用快速构建打包的方案中默认使用的是被嵌入式(embedded mode)，也就是Crosswalk Runtime是和这个应用绑定在一起的。如果没有指定哪种cpu平台，一般会创建2个apk文件，一个是x86的，一个是arm的apk文件。
当然我们也可以使用共享模式来打包应用，这个模式下，apk的平台架构师独立的，也就是说和Crosswalk Runtime是分离的。要正常运行必须得有安装这个runtime才行。
两种模式的优缺点:
- Embedded 嵌入方式
在这个模式下，每个app都是自己捆绑了一个完整的runtime，runtime又是根据所提供的cpu架构的native library来决定生成哪个平台下的apk包。make_apk.py脚本后面的参数来决定生成哪个平台。
优点是，可以保证每个独立的app与runtime是完全一体的，不用考虑新旧版本等问题。
缺点是，生成的apk普遍比较大，生成2个平台下的体积是单独生成一个平台下的2倍左右。因为它们已经把体积较大的runtime包含进去了。 - Shared 共享方式
共享runtime模式的打包下，每个app仅仅是使用了java层的一些与平台架构无关的wrap代码，即是引用部分jar，不包含核心库等文件。可以大大的减小应用生成的体积，但是运行这个模式的应用必须有安装独立的runtime才能正常运行。而且这个runtime是根据当前手机的平台来安装相应的runtime，当然多个应用之间是可以共用这个唯一的runtime的。
优点是，很明显可以减少应用的体积，多个应用之间可以共用这个相同的runtime，前提还是这个独立的runtime版本和你的应用之间使用的版本要相同；还有一个优点就是，因为多个个应用之间是可以共用一个runtime的，每次runtime发布新版本时，只需要升级这个共用的runtime即可，而不像在嵌入模式下，每个单独的app都需要升级一次。
缺点是，发布应用时需要把这个runtime一起提供给安装。
创建共享模式示例：
--mode=shared 开启共享模式
python make_apk.py --mode=shared --package=com.intel.xwalk-simple
--manifest=xwalk-simple/manifest.json
创建打包后安装，同时需要安装这个对应的runtime，
ARM
x86