Android中的服务Service初步（1）

我们知道在Android开发中UI线程是主线程,在主线程不能进行耗时操作
所以当我们访问接口或者现在的时候都需要开启线程
在这样的环境下 handler AsyncTask就是用来解决这样的问题的，还有一种方法就是Service 我们可以将一下耗时操作放在服务中，来避免ANR错误。
Service有如下两个特征
//1.并不依赖于用户可视的UI界面（当然，这一条其实也不是绝对的，
// 如前台Service就是与Notification界面结合使用的）；
//2.具有较长时间的运行特性。
/**
* 一般而言，从Service的启动方式上，可以将Service分为Started Service和Bound Service。
* 无论哪种具体的Service启动类型，都是通过继承Service基类自定义而来。在使用Service时，
* 要想系统能够找到此自定义Service，无论哪种类型，都需要在AndroidManifest.xml中声明，
*
* 注：如果自定义Service没有在AndroidManifest.xml中声明，
* 当具体使用时，不会像Activity那样直接崩溃报错，
* 对于显式Intent启动的Service，
* 此时也会给出waring信息“IllegalArgumentException: Service not registered”，
* 有时候不容易发现忘了声明而一时定位不到问题。
*
* 1.Service本身都是运行在其所在进程的主线程（如果Service与Clinet同属于一个进程，则是运行于UI线程），
* 但Service一般都是需要进行”长期“操作，所以经常写法是在自定义Service中处理”长期“操作时需要新建线程，
* 以免阻塞UI线程或导致ANR；
* 2.Service一旦创建，需要停止时都需要显示调用相应的方法（Started Service需要调用stopService(..)
* 或Service本身调用stopSelf(..)， Bound Service需要调用unbindService(..)），
* 否则对于Started Service将处于一直运行状态，对于Bound Service，当Client生命周期结束时也将因此结束。
* 也就是说，Service执行完毕后，必须人为的去停止它
*/
这个东西太复杂了 本文先讲述Started Service

/**
*Started Service生命周期及进程相关
*1.onCreate(Client首次startService(..)) >> onStartCommand >> onStartCommand - optional … >> onDestroy(Client调用stopService(..))
*注：onStartCommand(..)可以多次被调用，onDestroy()与onCreate()想匹配，
*当用户强制kill掉进程时，onDestroy()是不会执行的。
*2.对于同一类型的Service，Service实例一次永远只存在一个，
*而不管Client是否是相同的组件，也不管Client是否处于相同的进程中。
*3.Service通过startService(..)启动Service后，
*此时Service的生命周期与Client本身的什么周期是没有任何关系的，
*只有Client调用stopService(..)或Service本身调用stopSelf(..)才能停止此Service。
* 当然，当用户强制kill掉Service进程或系统因内存不足也可能kill掉此Service。
*4.Client A 通过startService(..)启动Service后,
* 可以在其他Client（如Client B、Client C）通过调用stopService(..)结束此Service。
*5.Client调用stopService(..)时，如果当前Service没有启动，也不会出现任何报错或问题，
* 也就是说，stopService(..)无需做当前Service是否有效的判断。
*6.startService(Intent serviceIntent)，其中的intent既可以是显式Intent，
* 也可以是隐式Intent，当Client与Service同处于一个App时，一般推荐使用显示Intent。
* 当处于不同App时，只能使用隐式Intent。
*当Service需要运行在单独的进程中，
* AndroidManifest.xml声明时需要通过android:process指明此进程名称，
* 当此Service需要对其他App开放时，android:exported属性值需要设置为true
* (当然，在有intent-filter时默认值就是true)。
*

//开启和关闭的方法 serviceIntent = new Intent(StartServiceActivity.this, MyService.class); startService(serviceIntent); //关闭的方法stopService(serviceIntent);

自定义Service代码

/** * Started Service相对比较简单， * 通过context.startService(Intent serviceIntent)启动Service， * context.stopService(Intent serviceIntent)停止此Service。 * 当然，在Service内部，也可以通过stopSelf(...)方式停止其本身。 * * 其中，onBind(...)函数是Service基类中的唯一抽象方法， * 子类都必须重写实现，此函数的返回值是针对Bound Service类型的Service才有用的， * 在Started Service类型中，此函数直接返回 null 即可。 * onCreate(...)、onStartCommand(...)和onDestroy()都是Started Service相应生命周期阶段的回调函数。 * * 当Client调用startService(Intent serviceIntent)后，如果MyService是第一次启动， * 首先会执行 onCreate()回调，然后再执行onStartCommand(Intent intent, int flags, int startId)， * 当Client再次调用startService(Intent serviceIntent)， * 将只执行onStartCommand(Intent intent, int flags, int startId)， * 因为此时Service已经创建了，无需执行onCreate()回调。 * 无论多少次的startService，只需要一次stopService()即可将此Service终止， * 执行onDestroy()函数（其实很好理解，因为onDestroy()与onCreate()回调是相对的）。 */public class MyService extends Service{    public static final String TAG = "MyService";    @Nullable    @Override    public IBinder onBind(Intent intent) {        return null;    }    @Override    public void onCreate() {        super.onCreate();        Log.w(TAG, "in onCreate");    }    /**     *其中参数flags默认情况下是0，对应的常量名为START_STICKY_COMPATIBILITY。     * startId是一个唯一的整型，用于表示此次Client执行startService(...)的请求请求标识，     * 在多次startService(...)的情况下，呈现0,1,2....递增。     * 另外，此函数具有一个int型的返回值，具体的可选值及含义如下：     *START_NOT_STICKY：当Service因为内存不足而被系统kill后，接下来未来的某个时间内，     *即使系统内存足够可用，系统也不会尝试重新创建此Service。     *除非程序中Client明确再次调用startService(...)启动此Service。     *START_STICKY：当Service因为内存不足而被系统kill后，接下来未来的某个时间内，     *当系统内存足够可用的情况下，系统将会尝试重新创建此Service，     *一旦创建成功后将回调onStartCommand(...)方法，但其中的Intent将是null，pendingintent除外。     *START_REDELIVER_INTENT：与START_STICKY唯一不同的是，回调onStartCommand(...)方法时，     *其中的Intent将是非空，将是最后一次调用startService(...)中的intent。     *START_STICKY_COMPATIBILITY：compatibility version of {@link #START_STICKY}     * that does not guarantee that {@link #onStartCommand} will be called again after     * being killed。此值一般不会使用，所以注意前面三种情形就好。     *以上的描述中，”当Service因为内存不足而被系统kill后“一定要非常注意，     * 因为此函数的返回值设定只是针对此种情况才有意义的，换言之，当认为的kill掉Service进程，     * 此函数返回值无论怎么设定，接下来未来的某个时间内，即使系统内存足够可用，Service也不会重启。     *小米手机针对此处做了变更：     *另外，需要注意的是，小米手机针对此处做了一定的修改。在“自启动管理”中有一个自启动应用列表，     * 默认情况下，只有少应用（如微信、QQ、YY、360等）默认是可以自启动的，     * 其他应用默认都是禁止的。用户可以手动添加自启动应用，     * 添加后的应用中如果Started Service onStartCommand(...)     * 回调返回值是START_STICKY或START_REDELIVER_INTENT，     * 当用户在小米手机上长按Home键结束App后，接下来未来的某个时间内，当系统内存足够可用时，     * Service依然可以按照上述规定重启。当然，如果用户在 设置 >> 应用 >>     * 强制kill掉App进程，此时Service是不会重启的。     */    @Override    public int onStartCommand(Intent intent, int flags, int startId) {        Log.w(TAG, "in onStartCommand");        Log.w(TAG, "MyService:" + this);        String name = intent.getStringExtra("name");        Log.w(TAG, "name:" + name);        return START_STICKY;    }    @Override    public void onDestroy() {        super.onDestroy();        Log.w(TAG, "in onDestroy");    }}

结束。。。。