现在：map上的markers，现在是一个数组，更新其中一个数marker，就把整个数组更新一次，整个图像更新一次； 需求：图像的表达上，能否也是根据数组变化而变化，比如新增一个数，就是新增一个图标，减少一个就是减少一个图标； 另外：map上的 marker 想做成地图的分层的感觉，比如显示图书馆层，学校层，显示政府地点层，分别放在不同数组，分别更新，而不是整个更新（效率太低）；

- 需求的场景描述（希望解决的问题） 我们想使用 Emscripten http://kripken.github.io/emscripten-site/ 来把C++的游戏转化成小游戏，目前遇到的问题是生成的js文件比较大，而js文件又有其特殊性 必须放在初始加载包里面，无法像其他素材一样托管到腾讯云上 js文件有很大的压缩空间，在网络传输层能用gzip自动压缩，我们7M的js文件，实际传输的时候大约只有1M 《微信开发者工具》的4M容量限制并不是按实际网络传输层的容量来计算，而是按原始文件大小来计算，相对于其他素材(如jpg,png等无法再用gzip压缩)，这种计算方式并不公平 我们除了可以输出js，还可以输出对等的wasm(https://webassembly.org/)文件，其容量要比js文件小的多(大约是js文件的30%)，性能也会好得多，目前主流的浏览器（Edge,Safari,Chrome,Firefox）都已经支持，但是微信小游戏目前还不支持这个功能。 - 希望提供的能力 修改《微信开发者工具》的4M限制的计算方式，按包体gzip之后的大小来计算 放开4M的限制，到10M或者更多 尽快实现wasm的底层支持 实现以上三条建议任何一条都能给我们极大的帮助。还望开发大大们多多支持。 另外能否给出一个大概的RoadMap，这样能对我们的技术方向有一个指导性的判断。

- 需求的场景描述（希望解决的问题） 计算性能提升 - 希望提供的能力 就标准来看，不存在安全、热更新等问题，也不涉及小程序实现的渲染排版，仅仅是JS层面的内容。 能够极大的提高微信小程序、微信小游戏的运算能力。 有没有考虑支持一下直接做一个接口映射呢？

希望增加WebAssembly API，JS的加解密库和图片处理库实在太耗性能了

鉴于webassembly已经在iOS和Android得到广泛支持，是否应该开放在worker内支持webassembly的能力？这样可以通过rust编写高性能的数据处理模块。

有没有人做过全面的测试，小程序安卓和ios端是否可以很好的支持wasm并用于生产？又或者未来什么时候支持？