android:process 讲解

笔者在学习Android Service组件的过程中碰到了一个问题，就是在Android应用的声明文件Manifest.xml中有时候会对相关的服务标签设置一个android:process=”:remote”,这个属性有什么作用呢？下面笔者就将自己整理的知识和大家分享。

在Android的帮助文档中我们可以了解到，一般情况下一个服务没有自己独立的进程，它一般是作为一个线程运行于它所在的应用的进程中。但是也有例外，Android声明文件中的android:process属性却可以为任意组件包括应用指定进程，换句话说，通过在声明文件中设置android:process属性,我们可以让组件（例如Activity,
Service等）和应用(Application)创建并运行于我们指定的进程中。下面是相关资料和笔者翻译。





如果我们需要让一个服务在一个远端进程中运行（而不是标准的它所在的apk的进程中运行），我们可以在声明文件中这个服务的标签中通过android:process属性为其指定一个进程。

注意：这里选择”remote”这个名字是随意主观的，你能用其他名字来让这个服务在另外的进程中运行。冒号’:’这个前缀将把这个名字附加到你的包所运行的标准进程名字的后面作为新的进程名称。

例如：一个应用的包名为com.aoyousatuo.example, 则本例中服务将运行的新进程的名称为com.aoyousatuo.example:remote.(注意，如果声明文件中的组件或者应用没有指定这个属性则默认应用和其组件将相应运行在以其包名命名的进程中).





android:process

服务所在进程的名字。通常，一个应用的所有组件都运行在系统为这个应用所创建的默认进程中。这个默认进程是用这个应用的包名来命名的。

标签的process属性可以设置成和所有组件都不同的默认值。但是这些组件可以通过设置自己的process值来覆写这个默认值，这样可以让你的应用跨多进程运行。

如果被设置的进程名是以一个冒号开头的，则这个新的进程对于这个应用来说是私有的，当它被需要或者这个服务需要在新进程中运行的时候，这个新进程将会被创建。如果这个进程的名字是以小写字符开头的，则这个服务将运行在一个以这个名字命名的全局的进程中，当然前提是它有相应的权限。这将允许在不同应用中的各种组件可以共享一个进程，从而减少资源的占用。

例如一个应用运行在进程com.aoyousatuo.example中，android:process属性设置为com.rabbit.run,则新的进程名字为com.rabbit.run.

由android:process引发的内存限制的问题

android:process

定义activity运行所在的进程名称。一般情况下，应用的所有组件都运行在为应用创建的默认的进程中，该默认进程的名称应用包名称一致。通过定义<application>元素的“process”属性可以为所有组件指定一个不同的默认进程。但是任意组件都可以重写默认进程，以便实现多进程操作。

如果该属性指定名称以“：”开头，则一个新的专属于该应用的进程将会被创建。如果该进程名以小写字母开头，则为该activity提供权限以让其在一个全局的进程中运行。这样会允许多个应用的不同组件共用一个进程，以便节省资源。

Android是支持多进程的，每个进程的内存使用限制一般为24MB的内存，所以当完成一些很耗费内存的操作如处理高分辨率图片时，需要单独开一个进程来执行该操作（上面的配置可以用来实现该操作）。即便如此，开发者还是不要随意多开进程来耗费用户的资源。（内存限制，有16MB，24MB， 32MB，很老的机型的内存限制会是16MB，这个具体还要再搜索下资料。。）

另外一些还有一些其他的方式来绕过内存限制，使用更多的资源来完成自己的任务，如下文（有待实践）：

How to work around Android’s
24 MB memory limit

The Android framework enforces a per-process 24 MB memory limit. On some older devices, such as the G1, the limit is even lower at 16 MB.

What’s more, the memory used by Bitmaps is included in the limit. For an application manipulating images it is pretty easy to reach this limit and
get the process killed with an OOM exception:

E/dalvikvm-heap(12517): 1048576-byte external allocation too large for this process.

E/GraphicsJNI(12517): VM won't let us allocate 1048576 bytes

D/AndroidRuntime(12517): Shutting down VM

W/dalvikvm(12517): threadid=1: thread exiting with uncaught exception (group=0x4001d7f0)

E/AndroidRuntime(12517): FATAL EXCEPTION: main

E/AndroidRuntime(12517): java.lang.OutOfMemoryError: bitmap size exceeds VM budget

This limit is ridiculously low. For a device, like the Nexus One, with 512MB of physical RAM, setting the per-process memory limit for the foreground activity to only 5% of the RAM is a silly mistake. But anyway, that’s
how things are and we have to live with it —i.e. find how to work around it.

There are two ways to allocate much more memory than the limit:

One way is to allocate memory from native code. Using the NDK (native development kit) and JNI, it’s possible to allocate memory from the C level
(e.g. malloc/free or new/delete), and such allocations are not counted towards the 24 MB limit. It’s true, allocating memory from native code is not as convenient as from Java,
but it can be used to store some large amounts of data in RAM (even image data).

Another way, which works well for images, is to use OpenGL textures — the texture memory is not counted towards the limit.

To see how much memory your app has really allocated you can use android.os.Debug.getNativeHeapAllocatedSize().

Using either of the two techniques presented above, on a Nexus One, I could easily allocate 300MB for a single foreground process— more than 10 times the default 24 MB limit.