Android应用程序UI硬件加速渲染的预加载资源地图集服务(Asset Atlas Service)分析.docVIP

Android应用程序UI硬件加速渲染的预加载资源地图集服务（Asset Atlas Service）分析 我们知道，Android系统在启动的时候，会对一些系统资源进行预加载。这样不仅使得应用程序在需要时可以快速地访问这些资源，还使得这些资源能够在不同应用程序之间进行共享。在硬件加速渲染环境中，这些预加载资源还有进一步优化的空间。Android系统提供了一个地图集服务，负责将预加载资源合成为一个纹理上传到GPU去，并且能够在所有的应用程序之间进行共享。本文就详细分析这个预加载资源地图集服务的实现原理。 资源预加载是发生在Zygote进程的，然后Zygote进程fork了应用程序进程，于是就使得预加载的资源可以在Zygote进程与所有的应用程序进程进行共享。这种内存共享机制是由Linux进程创建方式决定的。也就是说，父进程fork子进程之后，只要它们都不去修改某一块内存，那么这块内存就可以在父进程和子进程之间进行共享。一旦父进程或者子进程修改了某一块内存，那么Linux内核就会通过一种称为COW（Copy On Wrtie）的技术为要修改的进程创建一块内存拷贝出来，这时候被修改的内存就不再可以共享。 对于预加载资源来说，它们都是只读的，因此就可以保证它们在Zygote进程与所有的应用程序进程进行共享。这在应用程序UI使用软件方式渲染时可以工作得很好。但是当应用程序UI使用硬件加速渲染时，情况就发生了变化。资源一般是作为纹理来使用的。这意味着每一个应用程序都会将它要使用的预加载资源作为一个纹理上传到GPU去，如图1所示： 因此，这种做法会浪费GPU内存。为了节省GPU内存，Android系统在System进程中运行了一个Asset Atlas Service。这个Asset Atlas Service将预加载资源合成为一个纹理，并且上传到GPU去。应用程序进程可以向Asset Atlas Service请求上传后的纹理，从而使得它们不需要再单独去上传一份，这样就可以起到在GPU级别共享的作用，如图2所示： 在图2中，最右侧显示的是应用程序进程的Render Thread，它们通过Asset Atlas Service获得已经上传到GPU的预加载资源纹理，这样就可以直接使用它们，而不再需要独立上传。 接下来，我们从Zygote进程预加载资源、System进程合成资源为纹理并且上传到GPU，以及应用程序使用上传后的纹理三个过程来描述预加载资源地图集机制，以便可以更好地理解应用程序是如何做到在GPU级别共享预加载资源的。 我们首先看Zygote进程预加载资源的过程。从前面一文可以知道， Zygote进程在Java层的入口点为ZygoteInit类的静态成员函数main，它的实现如下所示： [java] view plain copy 在CODE上查看代码片派生到我的代码片 public class ZygoteInit { ...... public static void main(String argv[]) { try { ...... registerZygoteSocket(socketName); ...... preload(); ...... if (startSystemServer) { startSystemServer(abiList, socketName); } ...... runSelectLoop(abiList); ...... } catch (MethodAndArgsCaller caller) { ...... } catch (RuntimeException ex) { ...... } } ...... } 这个函数定义在文件frameworks/base/core/java/com/android/internal/os/ZygoteInit.java中。 ZygoteInit类的静态成员函数main的执行流程如下所示： 1. 调用成员函数registerZygote