Android Service相关知识

android:process属性

这个属性对Activity等组件也是同样适用的
碰到Service加上android:process后Application的onCreate方法执行两次的问题。
android:process是服务所在进程的名字。通常，一个应用的所有组件都运行在系统为这个应用所创建的默认进程中。这个默认进程是用这个应用的包名来命名的。
标签的process属性可以设置成和所有组件都不同的默认值。但是这些组件可以通过设置自己的process值来覆写这个默认值，这样可以让你的应用跨多进程运行。
如果被设置的进程名是以一个冒号开头的，则这个新的进程对于这个应用来说是私有的，当它被需要或者这个服务需要在新进程中运行的时候，这个新进程将会被创建。如果这个进程的名字是以小写字符开头的，则这个服务将运行在一个以这个名字命名的全局的进程中，当然前提是它有相应的权限。这将允许在不同应用中的各种组件可以共享一个进程，从而减少资源的占用。
例如一个应用运行在进程com.aoyousatuo.example中，android:process属性设置为com.rabbit.man,则新的进程名字为com.rabbit.run.
一般情况下一个服务没有自己独立的进程，它一般是作为一个线程运行于它所在的应用的进程中。但是也有例外，Android声明文件中的android:process属性却可以为任意组件包括应用指定进程，换句话说，通过在声明文件中设置android:process属性,我们可以让组件（例如Activity, Service等）和应用(Application)创建并运行于我们指定的进程中。
如果我们需要让一个服务在一个远端进程中运行（而不是标准的它所在的apk的进程中运行），我们可以在声明文件中这个服务的标签中通过android:process属性为其指定一个进程。
注意：这里选择”remote”这个名字是随意主观的，你能用其他名字来让这个服务在另外的进程中运行。冒号’:’这个前缀将把这个名字附加到你的包所运行的标准进程名字的后面作为新的进程名称。
如果声明文件中的组件或者应用没有指定这个属性则默认应用和其组件将相应运行在以其包名命名的进程中。
加上这个属性可能会导致Application的onCreate执行了多次，这样导致重复初始化资源。
每个android应用都要运行在一个虚拟机上，当应用配置了两个进程时，其实是有两个虚拟机在运行，一个前台的应用进程，一个service后台进程，每个进程对应一个application对象，所以当应用配置了多个进程的时候，application对象的onCreate方法就会执行多次，所以如果在application的onCreate方法中初始化大量数据时，其实是要做出区分的处理的；

    public void onCreate() {  
        super.onCreate();  
        mApplication = this;  
        long s1 = System.currentTimeMillis();  
        String processName = OsUtils.getProcessName(this,  
                android.os.Process.myPid());  
        L.d(WModel.Time, "进程名称"+processName);  
        if (processName != null) {  
            boolean defaultProcess = processName  
                    .equals(WMapConstants.REAL_PACKAGE_NAME);  
            if (defaultProcess) {  
                //必要的初始化资源操作  
            }  
        }  
        L.d(WModel.Time, "onCreate耗时" + (System.currentTimeMillis() - s1));  
    }

    public static String getProcessName(Context cxt, int pid) {  
        ActivityManager am = (ActivityManager) cxt.getSystemService(Context.ACTIVITY_SERVICE);  
        List<RunningAppProcessInfo> runningApps = am.getRunningAppProcesses();  
        if (runningApps == null) {  
            return null;  
        }  
        for (RunningAppProcessInfo procInfo : runningApps) {  
            if (procInfo.pid == pid) {  
                return procInfo.processName;  
            }  
        }  
        return null;  
    } 

Service的onStartCommand4种返回值所代表的意义

1. START_STICKY：如果service进程被kill掉，保留service的状态为开始状态，但不保留递送的intent对象。随后系统会尝试重新创建service，由于服务状态为开始状态，所以创建服务后一定会调用onStartCommand(Intent,int,int)方法。如果在此期间没有任何启动命令被传递到service，那么参数Intent将为null。
2. START_NOT_STICKY：“非粘性的”。使用这个返回值时，如果在执行完onStartCommand后，服务被异常kill掉，系统将会把它置为started状态，系统不会自动重启该服务，直到startService(Intent intent)方法再次被调用。
3. START_REDELIVER_INTENT：重传Intent。使用这个返回值时，如果在执行完onStartCommand后，服务被异常kill掉，系统会自动重启该服务，并将Intent的值传入。
4. START_STICKY_COMPATIBILITY：START_STICKY的兼容版本，但不保证服务被kill后一定能重启。

Service变为前台进程

使用startforeground()