json转成typescripts，语言层面上来说，不管你用什么类库，大概率都是先创建对象，再把数据传进去初始化，返回创建的对象。众所周知，我们都没写过几行代码。这么复杂的轮子我们通常还是自己写，这样说出去我们代码行数又多了
（帖子被作者删除，如无标记将在 24 小时后自动删除）
我们通信和配置文件都是二进制，写一套解析工具，还有自动化生成对应的声明文件，json从来都没有用在这里过，用json的通信我觉得是真不上来哪里好
自己写，类似于protobuf，都是二进制序列化和反序列化，我们项目里面基本上不会直接用json
想了想还是回复一下
- 难怪你们没人回答->众所周知，写过很多代码的只有4个人（你那个库，star4+ watch2，算6个人吧）
- 对应很多，层级很深->有种语法叫for，有种逻辑叫递归
- 不写方法只写函数->你到底在说什么
也许你的开发方式很好，也许很适合你，但是因为没有你的开发方式，你在这里显得自己很优越，不好意思，没必要，毕竟我们都没写过几行代码。
1赞
有现成参考对象 为啥不直接照搬呢
融云sdk语音使用跟cocos的音效播放，iOS下会导致死循环
最后被迫使用背景音乐接口来播放音效
这个问题，3.x使用以来一直都只能靠这个方式苟着
比起iOS，安卓这已经算是好的了
iOS那工程才是痛苦 
默认的那个资源引用方式导致卡的一批，只能去手动删掉build settings里面一堆蛇皮
如果你不懂函数和方法的区别，那确实没法继续沟通下去~你知道，如果是专门使用js的人都能知道方法和函数的区别在哪里~
json库不是我的，目前我已经在使用，但是都很稳定，没遇到什么bug
第二点递归，说的容易，如果真的这么容易，百度谷歌上面一堆了，但是据我所知，就js和ts的json库，不足5个~~~所以哥们别挑剔了，前端确实不只是水，而且数据还随便放，或者一律放到global里面，总之无论如何都比不上一套类表示出来的简单，直观和便捷。
不再继续做口舌之争，没意义，你继续你的方法即可，我还是妥妥的一套类型表示出来，随时存取，这样比较适合我，至于其他的拉闸方式，我还是保持我的致轻致美风格为好
大半夜忍不住说几个观点，仅供参考。
- 我认为序列化反序列化库，能把嵌套做好就很不错了，很多时候业务层有千千万万种方式去做通讯和类型封装，底层序列化库把类型绑死通用性反而就差了。
- JSON 是支持带类型信息的，自己把类型写入 { } 中，通过 JSON.parse 的第二个参数 reviver 就能把类型解析并且构造回来。这样就能带上方法了。
- Creator 自带的序列化/反序列化库复杂度巨高，几乎和编辑器是绑死的了，目前有一套编辑器一套运行时两种格式，两种格式几乎不共享代码。（没错这两套都是我做的）。我们中间还做过一套二进制的纯 C++ 实现的，不过性能收益不大就没暂时挂起了，将来编辑器还会再实现新的格式。这也就是为什么 Creator 要自己造轮子的原因。用其它第三方序列化库或者数据格式都无法在性能和包体上达到同等级别。
1赞
我还是希望可以cocos可以将部分json api开放出来，这样我们就不用那么痛苦的去引入ts的json和unjson库了
基于我说的以上两点，其实目前没看到公开 API 能获得特别大的增益，第三点则说明官方的方案把序列化这一层弄得过重了，所以通用性灵活性不够好。
1赞
你可以把 native 理解为 build-template