Question

我使用Starling创建了一个应用程序，在新的移动设备上它的表现非常出色，但是在较旧的设备上（例如iPhone 4），我遇到了一个非常奇怪的延迟。

据我所知，我完全是一个静态的情况：

舞台上添加了很多显示对象，其中很多是按钮，如果重要，它们的属性在初始化后根本不会改变（x，y，旋转等等）。后台没有任何类型的enterframes / timeouts / interval / requests。我没有分配/取消分配任何内存。

在这种情况下，30分中平均有10 FPS，这很奇怪。

由于Starling是一个完善的框架，我想我是做错了什么/不理解某事/不了解某事。

知道可能导致它的原因吗？

还有其他人遇到过这类问题吗？

修改

在阅读了一点之后，我根据这个帖子以各种可能的方式进行了很大的优化： http://wiki.starling-framework.org/manual/performance_optimization

我将绘制调用从大约90减少到12，将精简的精灵减少并在特定情况下将blendmode设置为none以便于CPU，等等......

令我惊讶的是，当我再次测试时，FPS未受影响：

fps：6/60
mem：19
drw：12

甚至可以在手机上使用Starling获得正常的fps吗？我错过了什么？

我正在使用缩小到设备大小的大纹理，这样的事情可能会影响fps吗？

Answer 1

关于“从文件/ URL加载纹理”，我正在为不同的情况下载不同的资产堆，因此我假设将每个堆编译成SWF将比为每个文件发送单独的请求更快。问题是，为此我只能使用嵌入，显然使用两倍的内存。您是否有任何解决方案可以享受两全其美的优势？

您可以将资源嵌入到应用包中，而不是下载“线上”资源并手动缓存它们以进行重复使用，而不是嵌入它们，然后使用Starling AssetManager以设备所需的分辨率/比例加载纹理：

即

        assets.enqueue(
            appDir.resolvePath("audio"),
            appDir.resolvePath(formatString("fonts/{0}x",    scaleFactor)),
            appDir.resolvePath(formatString("textures/{0}x", scaleFactor))
        );

参考：https://github.com/Gamua/Starling-Framework/blob/master/samples/scaffold_mobile/src/Scaffold_Mobile.as

你的应用程序包当然会变得更大，但你不会使用'embed'来获得2倍的ram命中率。

我的评论中的其他想法：

使用“发布”模式测试FPS是否正确？
您是否在加载之前使用按比例缩小的纹理以匹配设备的分辨率？
您是否混合了导致其他绘制调用的BLEND模式？

参考：Performance Optimization非常适合优化您对Starling的使用。

Answer 2

Starling并不是移动设备的奇迹解决方案。为了让GPU显示任何内容，在后台运行了大量代码。编码员必须确保将绘制调用的数量保持在最低限度。设备越弱，你应该强制进行更少的绘图调用。看到人们使用Starling而不关注他们的抽奖电话并不罕见。

所使用的图形大小仅与GPU上传时间相关，而与GPU显示时间无关。因此，当然需要在显示任何场景之前上传所有相关纹理。在任何给定场景播放时，您根本无法尝试上传任何新纹理。即使是小纹理上传也会导致空转。

使用Starling显示所有内容并不总是明智的选择。在渲染模式下，GPU获得了大量功率，但CPU仍有一些剩余功能。您可以使用经典显示列表（Staling框架设计失败的地方）显示静态UI元素，从而减少GPU上传量和GPU费用。 Starling最初是为了很难同时使用这两个显示系统，这是使用这个框架的缺点之一。我知道最专业的人包括我自己不会因为这个原因而使用Starling。

您的系统必须灵活，您应该将您的资产嵌入到移动设备中，尽可能不使用任何外部swf，并且能够切换到另一个网络系统。如果您希望将一个资产系统用于应用程序的移动/桌面/网络版，那么您就是在为自己设置失败。嵌入在移动设备上对于内存管理至关重要，因为AIR平台在内部管理这些嵌入式资产的缓存。在创建这些资产的新实例时，内存消耗会受到控制，如果你没有嵌入，那么你就可以自己动手了。

关于整体性能，使用Starling或任何Stage3D框架时，非常弱的Android设备可能永远无法通过10 fps，因为这些框架需要在后台运行（绘制调用）的代码量。在弱设备上，代码量已经足以使CPU完全过载。另一方面，在弱设备上，通过使用GPU模式而不是渲染模式（因此没有Stage3D）并且主要显示光栅图形，您仍然可以获得良好的性能和用户体验。

响应您的编辑：

12次抽签非常好（90级非常高）。

你仍然在某些设备上获得低FPS并不令人惊讶。特别是低端Android设备在渲染模式下使用Stage3D框架时总是具有较低的FPS，因为这些框架必须运行以呈现一帧的代码量。现在你正在使用的纹理的大小不应该影响FPS那么多（这是Stage3D的重点）。如果减小这些图形的大小，它将有助于GPU上传时间。

现在优化是关键，优化低端FPS的低端设备是最好的方法，因为无论你做什么都会对更好的设备产生很大的影响。首先运行测试，只显示没有代码或代码很少的静态图形，只是为了看看Stage3D框架在这些弱设备上可以自行走多远而不会丢失任何FPS然后从那里进行优化。屏幕上显示的对象数量和绘制调用量是影响具有这些Stage3D框架的FPS的因素，因此请记住这些并始终寻求减少它的方法。在某些低端设备上尝试保持60fps是不切实际的，因此请尝试切换到30并相应地调整渲染。

椋鸟为IOS＆amp; Android：在静态情况下非常低的FPS

2 个答案: