我一直想知道是否可以使用 OpenCL for Android，发现这是不可能的，然后完全放弃了这个主题。但是感谢官方 Android 开发者博客 (http://android-developers.blogspot.fr/2013/01/evolution-of-renderscript-performance.html) 1 月 14 日的博文，我发现并行编程是可能的从 Android 4.0 开始，感谢 RenderScript！一个与 OpenCL 有很多共同特性的 API。
我现在想知道的是：为什么 Google 选择实施这个新的解决方案，而不是推动 OpenCL（现在由 Khronos 小组处理的开放规范）。
我的意思是，我知道，从一种转换到另一种并不难，但仍然......
无论如何，如果有人作为真正的解释，请告诉我！
Apple 拥有 OpenCL 上的商标。谷歌与苹果竞争。或许真的就这么简单。
我们已经在 Android 上完成了 OpenCL 的工作（请参阅此处），并且很高兴看到它在英特尔、Imagination 和其他芯片制造商的努力下取得进展。谷歌很快就会好转。
答案是 Android 的需求与 OpenCL 试图提供的非常不同。
OpenCL 使用 CUDA 中首次引入的执行模型。在这个模型中，一个内核由一组或多组worker组成，每个组在该组内都有快速共享内存和同步原语。这样做会导致算法的描述与应该如何在特定架构上调度该算法（因为您正在决定组的大小以及何时在该组内同步）混合在一起。
当您为一种架构编写并且想要绝对的峰值性能时，这很棒，但它以牺牲性能可移植性为代价获得了峰值性能。也许在您的架构上，您有足够的寄存器和共享内存来每组运行 256 个工作程序以获得最佳性能，但在另一种架构上，您最终会出现大量寄存器溢出，每组超过 128 个工作程序，导致 80% 的性能回归. 同时，由于您的代码是为每组 256 个工作人员明确编写的，因此运行时无法尝试改善另一个架构上的情况——它必须遵守您所编写的内容。在 GPU 计算的桌面/HPC 端从架构迁移到架构时，这种情况很常见。
在移动设备上，Android 需要许多不同架构的 GPU 和 CPU 供应商之间的性能可移植性。如果 Android 依赖于 CUDA 风格的执行模型，几乎不可能编写单个内核并让它在一系列设备上可接受地运行。
RenderScript 以牺牲一些峰值性能为代价，将调度控制从开发人员手中抽象出来；但是，我们在 RenderScript 的可能性方面不断缩小差距。例如，在 Android 4.2 中引入的 API ScriptGroup 是我们进一步改进 GPU 代码生成计划的重要组成部分。还有很多新的改进，也使编写快速代码变得更加容易。