IOS & Android 的 Starling：静态情况下 FPS 非常低
Starling for IOS & Android: Very low FPS in a static situation
我用 Starling 创建了一个应用程序，在新的移动设备上它的性能非常好，但是在旧设备上（例如 iPhone 4）我遇到了一个非常奇怪的延迟。
据我所知，这是一个完全静态的情况：
舞台上添加了相当多的显示对象，其中许多是重要的按钮，它们的属性在初始化后根本没有改变（x、y、旋转等...）。
后台没有任何类型的输入帧/超时/间隔/请求。
我没有分配/取消分配任何内存。
在这种情况下，30 帧中平均有 10 FPS，这很奇怪。
由于 Starling 是一个完善的框架，我想是我做错了什么/不理解某事/不知道某事。
知道是什么原因造成的吗？
有没有其他人遇到过此类问题？
编辑：
在阅读了一些内容后，我根据这个线程以各种可能的方式进行了很好的优化：
http://wiki.starling-framework.org/manual/performance_optimization
我将绘制调用从大约 90 次减少到 12 次，在特定情况下扁平化精灵并将混合模式设置为 none 以缓解 CPU，等等...
令我惊讶的是，当我再次测试时，FPS 没有受到影响：
- 每秒帧数：6 / 60
- 内存: 19
- 博士: 12
是否有可能在移动设备上使用 Starling 获得正常的 fps？我错过了什么？
我正在使用按比例缩小到设备尺寸的大纹理，这样的事情是否会影响 fps？
Regarding "Load textures from files/URLs", I'm downloading different piles of assets for different situations, therefore I assumed compiling each pile into a SWF would be way faster than sending a separate request for each file. The problem is, for that I can only use embed, which apparently uses twice the memory. Do you have any solution in mind to enjoy the best of both worlds?
无需下载 'over-the-wire' 您的资产并手动缓存它们以供重复使用，您可以将资产嵌入到您的应用程序包中，而不是 嵌入 它们然后使用Starling AssetManager 加载设备所需的 resolution/scale 纹理：
即
assets.enqueue(
appDir.resolvePath("audio"),
appDir.resolvePath(formatString("fonts/{0}x", scaleFactor)),
appDir.resolvePath(formatString("textures/{0}x", scaleFactor))
);
你的应用程序包当然变大了，但你没有接受使用 'embed'.
的 2x ram hit
我评论中的其他性能想法：
- 使用 "Release" 模式测试 FPS 正确吗？
- 您是否使用在加载之前按比例缩小以匹配设备分辨率的纹理？
- 您是否在混合会导致额外绘制调用的 BLEND 模式？
参考：Performance Optimization 是优化 Starling 使用的好书。
Starling 不是移动设备的奇迹解决方案。为了使 GPU 显示任何内容，后台有相当多的代码 运行ning。作为编码人员，您必须确保绘制调用的数量保持在最低限度。设备越弱，你应该强制执行的绘图调用越少。看到人们使用 Starling 而不注意他们的绘制调用的情况并不少见。
使用的图形大小仅与 GPU 上传时间有关，与 GPU 显示时间无关。因此，当然需要在显示任何场景之前上传所有相关纹理。在播放任何给定场景时，您根本无法尝试上传任何新纹理。即使是很小的纹理上传也会导致空转。
使用 Starling 显示所有内容并不总是明智的选择。在渲染模式下，GPU 获得了很多能量，但 CPU 仍然有一些剩余。您可以通过使用经典显示列表（这是 Staling 框架设计失败的地方）简单地显示静态 UI 元素来减少 GPU 上传量和 GPU 充电量。 Starling 最初是为了让同时使用两个显示系统变得非常困难，这是使用此框架的缺点之一。出于这个原因，我认识的大多数专业人士（包括我自己）都不使用 Starling。
你的系统必须是灵活的，你应该嵌入你的移动资产，尽可能不使用任何外部 swf，并且能够切换到另一个网络系统。如果您希望为 mobile/desktop/web 版本的应用程序使用一个资产系统，那么您就是在为失败做准备。嵌入移动设备对于内存管理至关重要，因为 AIR 平台在内部管理这些嵌入资产的缓存。谢谢，当创建这些资产的新实例时，内存消耗保持在控制之下，如果你不嵌入那么你就靠你自己了。
关于整体性能，非常弱的 Android 设备在使用 Starling 或任何 Stage3D 框架时可能永远无法超过 10 fps，因为这些框架需要 运行（绘制调用）在后台。在弱设备上，代码量已经足以完全超载 CPU。另一方面，在弱设备上，通过使用 GPU 模式而不是渲染模式（因此没有 Stage3D）并主要显示光栅图形，您仍然可以获得良好的性能和用户体验。
回应您的编辑：
12 个绘制调用非常好（90 个相当高）。
您在某些设备上的 FPS 仍然很低并不奇怪。特别是低端 Android 设备在使用 Stage3D 框架的渲染模式下始终具有较低的 FPS，因为这些框架必须 运行 渲染一帧的代码量。现在，您使用的纹理大小应该不会对 FPS 产生太大影响（这就是 Stage3D 的意义所在）。如果您减小这些图形的大小，这将有助于缩短 GPU 上传时间。
现在优化是关键，在低 FPS 的低端设备上进行优化是最好的方法，因为无论您做什么，都会对更好的设备产生巨大影响。从 运行ning 测试开始，只显示静态图形，您没有代码或代码很少，只是为了看看 Stage3D 框架可以在那些较弱的设备上独立运行多远而不会丢失任何 FPS，然后从那里进行优化。屏幕上显示的对象数量 + 绘制调用数量是影响那些 Stage3D 框架的 FPS 的因素，因此请对这些进行计数并始终寻找减少它的方法。在一些低端设备上，尝试保持 60fps 是不切实际的，因此尝试切换到 30 并相应地调整渲染。
我用 Starling 创建了一个应用程序，在新的移动设备上它的性能非常好，但是在旧设备上（例如 iPhone 4）我遇到了一个非常奇怪的延迟。
据我所知，这是一个完全静态的情况：
舞台上添加了相当多的显示对象，其中许多是重要的按钮，它们的属性在初始化后根本没有改变（x、y、旋转等...）。 后台没有任何类型的输入帧/超时/间隔/请求。 我没有分配/取消分配任何内存。
在这种情况下，30 帧中平均有 10 FPS，这很奇怪。
由于 Starling 是一个完善的框架，我想是我做错了什么/不理解某事/不知道某事。
知道是什么原因造成的吗？
有没有其他人遇到过此类问题？
编辑：
在阅读了一些内容后，我根据这个线程以各种可能的方式进行了很好的优化： http://wiki.starling-framework.org/manual/performance_optimization
我将绘制调用从大约 90 次减少到 12 次，在特定情况下扁平化精灵并将混合模式设置为 none 以缓解 CPU，等等...
令我惊讶的是，当我再次测试时，FPS 没有受到影响：
- 每秒帧数：6 / 60
- 内存: 19
- 博士: 12
是否有可能在移动设备上使用 Starling 获得正常的 fps？我错过了什么？
我正在使用按比例缩小到设备尺寸的大纹理，这样的事情是否会影响 fps？
Regarding "Load textures from files/URLs", I'm downloading different piles of assets for different situations, therefore I assumed compiling each pile into a SWF would be way faster than sending a separate request for each file. The problem is, for that I can only use embed, which apparently uses twice the memory. Do you have any solution in mind to enjoy the best of both worlds?
无需下载 'over-the-wire' 您的资产并手动缓存它们以供重复使用，您可以将资产嵌入到您的应用程序包中，而不是 嵌入 它们然后使用Starling AssetManager 加载设备所需的 resolution/scale 纹理：
即
assets.enqueue(
appDir.resolvePath("audio"),
appDir.resolvePath(formatString("fonts/{0}x", scaleFactor)),
appDir.resolvePath(formatString("textures/{0}x", scaleFactor))
);
你的应用程序包当然变大了，但你没有接受使用 'embed'.
的 2x ram hit我评论中的其他性能想法：
- 使用 "Release" 模式测试 FPS 正确吗？
- 您是否使用在加载之前按比例缩小以匹配设备分辨率的纹理？
- 您是否在混合会导致额外绘制调用的 BLEND 模式？
参考：Performance Optimization 是优化 Starling 使用的好书。
Starling 不是移动设备的奇迹解决方案。为了使 GPU 显示任何内容，后台有相当多的代码 运行ning。作为编码人员，您必须确保绘制调用的数量保持在最低限度。设备越弱，你应该强制执行的绘图调用越少。看到人们使用 Starling 而不注意他们的绘制调用的情况并不少见。
使用的图形大小仅与 GPU 上传时间有关，与 GPU 显示时间无关。因此，当然需要在显示任何场景之前上传所有相关纹理。在播放任何给定场景时，您根本无法尝试上传任何新纹理。即使是很小的纹理上传也会导致空转。
使用 Starling 显示所有内容并不总是明智的选择。在渲染模式下，GPU 获得了很多能量，但 CPU 仍然有一些剩余。您可以通过使用经典显示列表（这是 Staling 框架设计失败的地方）简单地显示静态 UI 元素来减少 GPU 上传量和 GPU 充电量。 Starling 最初是为了让同时使用两个显示系统变得非常困难，这是使用此框架的缺点之一。出于这个原因，我认识的大多数专业人士（包括我自己）都不使用 Starling。
你的系统必须是灵活的，你应该嵌入你的移动资产，尽可能不使用任何外部 swf，并且能够切换到另一个网络系统。如果您希望为 mobile/desktop/web 版本的应用程序使用一个资产系统，那么您就是在为失败做准备。嵌入移动设备对于内存管理至关重要，因为 AIR 平台在内部管理这些嵌入资产的缓存。谢谢，当创建这些资产的新实例时，内存消耗保持在控制之下，如果你不嵌入那么你就靠你自己了。
关于整体性能，非常弱的 Android 设备在使用 Starling 或任何 Stage3D 框架时可能永远无法超过 10 fps，因为这些框架需要 运行（绘制调用）在后台。在弱设备上，代码量已经足以完全超载 CPU。另一方面，在弱设备上，通过使用 GPU 模式而不是渲染模式（因此没有 Stage3D）并主要显示光栅图形，您仍然可以获得良好的性能和用户体验。
回应您的编辑：
12 个绘制调用非常好（90 个相当高）。
您在某些设备上的 FPS 仍然很低并不奇怪。特别是低端 Android 设备在使用 Stage3D 框架的渲染模式下始终具有较低的 FPS，因为这些框架必须 运行 渲染一帧的代码量。现在，您使用的纹理大小应该不会对 FPS 产生太大影响（这就是 Stage3D 的意义所在）。如果您减小这些图形的大小，这将有助于缩短 GPU 上传时间。
现在优化是关键，在低 FPS 的低端设备上进行优化是最好的方法，因为无论您做什么，都会对更好的设备产生巨大影响。从 运行ning 测试开始，只显示静态图形，您没有代码或代码很少，只是为了看看 Stage3D 框架可以在那些较弱的设备上独立运行多远而不会丢失任何 FPS，然后从那里进行优化。屏幕上显示的对象数量 + 绘制调用数量是影响那些 Stage3D 框架的 FPS 的因素，因此请对这些进行计数并始终寻找减少它的方法。在一些低端设备上，尝试保持 60fps 是不切实际的，因此尝试切换到 30 并相应地调整渲染。