creator3.8.8怎么优化原生平台的性能？

Creator 3.x
#21

以前，原生和web底层差不多是两套，带来的问题是效果不一致，需要维护两套
所以，把大部分功能都移到了js层，带来的问题是原生性能下降很多
最后，就是逐步又把耗性能的部分迁移回原生
所以，现在完美结合了——原生和web效果不一致，原生性能不行 :smirk:

2赞
#22

image

#23

如果确认是脚本性能问题，可能是js runtime/vm的性能问题，特别是脚本里有每帧调用的函数，比如ios 原生用的 jscore 性能会比web的v8 jit 慢。

但是启动慢，脚本性能影响会肉眼可见吗，先确认那个环节/哪里影响

#24

难道是现在3.8.x的原生性能还不对2.4.x吗 :rofl:

#25

2.4的原生也是有很多问题，比如Label。我内部项目对2.4底层做了很多优化，目前性能还行。优化到最后遇到瓶颈：
1，Label绘制纹理依赖Android的Canvas，Canvas DrawText函数本身消耗的性能无法优化。
2，图片加载时，内存解码后上传到GPU耗时，暂无优化方法，只能控制图片尺寸，但要追求画质，只能求平衡。
3，js语言本身的性能问题无法优化。虽然我已经把2.4的v8升级到11。

#26

3.x原生性能比2.x好一些 但是对比unity 还是差很多。

#27

所以 为什么不整体全部原生，web通过整体wasm加载运行。还是不够前瞻啊。

#28

牛逼啊，把v8都升11了

#29

那为什么3.x的原生性能还不对webview，我感觉不太对，肯定还是得原生强

#30

看看这个链路：
比如创建Label纹理过程：
Web：
Canvas-skia->data->gpu memory
Android
Canvas-JSB->Java->skia->getCanvasData->C+±>JS->C+±>gpu memory

#31

js 和 c++交互开销大 频繁交互的话 还不如纯js的性能好。

#32

那我反而期待laya前期宣传的会对原始性能进行更深的优化了。

#33

虽然链路在这，但是我感觉集成在webview里的项目还是不行

#34

两条腿走路维护和开发成本高 容易两边都搞不好。

#35

虽然原生在一些方面存在问题，但我仍然选择使用原生发布，而非WebView套壳，因为还有很多其他方面的优点。
需要学会自己查找原生性能出在哪里，并能拿出优化方案。
当然目前我手上的项目，要么纯原生，要么纯网页，暂无双端需求。

#36

大佬你的原生用的是什么引擎

#37

嵌入web会有很多麻烦的东西，中大型的估计不行吧

#38
  1. 这只是根据你的描述盲猜
  2. 你的描述比较笼统，究竟慢在那个环节你得分析，资源加载？纹理解析？实例化？我只能假设你nativie这边的资源都来自本地，所以就盲猜往拆装箱上面靠了

然后是文章提到的自己的cpp做绑定，我这里并没有在cpp里加方法 所以也不是这个原因

关于这个问题，建议你再看一遍文档

#39

从体验上来说我发现原生端ui每次打开时安卓都会有明显的卡顿，ios的反而没有，我的方案是安卓端用webview，资源还是打到包里，加载资源时通过拦截判断加载本地资源，加载缓存资源或远程加载，ios端还是继续用原生

#40

Creator 2.4.15 原生引擎。自己优化卡顿点。

1赞