java - Android Opengl es 1 - asynctask 在某些设备上导致奇怪的行为

Question

我正在制作一款塔防游戏，我希望单独的 asyncTasks 来处理所有单位移动、碰撞、损坏等；我希望 GL 线程只处理绘图...

所以我在 MyGLSurfaceView 扩展了 glSurfaceView 类中有 3 个异步任务。

我通过 GLSurfaceView 中的覆盖来处理 onTouchEvents。

一切都直接在 GL 线程上运行，直到需要让小怪穿过迷宫，此时我使用一系列处理程序 h 发布一系列“准备”方法，加载关卡的小怪，并准备各种其他所需的实体。此过程的最后一步是编辑共享首选项，从而触发 3 个异步任务(通过在 MyGLSurfaceView(不是我的渲染器)中实现 onSharedPreferencesChangedListenner)

在我的旧设备(Nexus S 和旧的 Samsung Galaxy 标签)上，此功能始终运行良好。在我的 Galaxy S4 上，它只能在大约 80-90% 的时间内工作。当它不起作用时，可能会出现各种替代结果:- 应用程序保持响应，并不断绘制屏幕上所需的所有内容，减去异步任务更改的任何内容；奇怪的是，使用日志，我注意到异步任务似乎也运行正常，在日志中显示预期值(怪物在正确的路径上正确移动，而塔正确地向它们发射导弹，并且这些导弹的行为符合预期(造成损坏并可能导致生物在撞击时死亡)。从视觉上看，我在起始路径点、我的塔、我的游戏区域、我的 UI(仍然完全可点击且具有 0 延迟的交互性)上看到了一群生物。只是没有任何东西在移动我注意到，当观察到这种行为时，如果我按 home 键触发 onPause，然后返回到应用程序，触发 onResume，则操作会从头开始正常恢复(就像我的 asynctasks 中的所有先前日志帖子一样)输了)。这是应用程序失败时通常会发生的情况。可能是什么原因造成的？我的 asyncTasks 有时是否在渲染器的单独实例化上工作？为什么它总是在旧设备上运行，但在新设备上却不能运行？

• 由于我的小怪数组上存在空指针，应用程序崩溃了(也许事情执行不正常)？

使用 openGL es 时我应该避免 asynctask 吗？

我应该这样做吗？ (通过 doInBackground 更新生物位置，并简单地使用最新坐标(在 asynctask 中确定)绘制对象)

Answer 1

不要为此使用AsyncTasks。可能会出现多种问题:

• AsyncTasks 不保证按照启动顺序执行。
• 行为会随着时间的推移而发生变化，因此预计会在不同的平台版本上遇到奇怪的事情
• 允许同时运行的AsyncTasks数量有限。如果您开始更多，它们就会排队并且稍后才开始。更令人沮丧的是，这个数字在 API 版本之间发生了变化。

这些段落来自 docs可能感兴趣:

Order of execution

When first introduced, AsyncTasks were executed serially on a single background thread. Starting with DONUT, this was changed to a pool of threads allowing multiple tasks to operate in parallel. Starting with HONEYCOMB, tasks are executed on a single thread to avoid common application errors caused by parallel execution.

If you truly want parallel execution, you can invoke executeOnExecutor(java.util.concurrent.Executor, Object[]) with THREAD_POOL_EXECUTOR.

public final AsyncTask executeOnExecutor ...

Warning: Allowing multiple tasks to run in parallel from a thread pool is generally not what one wants, because the order of their operation is not defined. For example, if these tasks are used to modify any state in common (such as writing a file due to a button click), there are no guarantees on the order of the modifications. Without careful work it is possible in rare cases for the newer version of the data to be over-written by an older one, leading to obscure data loss and stability issues. Such changes are best executed in serial; to guarantee such work is serialized regardless of platform version you can use this function with SERIAL_EXECUTOR.