• Java工程师初学Android(四)(转)


    (转)http://www.apkbus.com/android-18204-1-1.html

    Android开发的四大组件:

    一、Activity详解
    二、Service详解
    三、Broadcast Receiver详解
    四、Content Provider详解

    一、Activity
    Activty的生命周期的也就是它所在进程的生命周期。

    1630011qa0lv8s0lqadr1d

    一个Activity的启动顺序:
    onCreate()-->onStart()-->onResume()

    当另一个Activity启动时:
    第一个Activity onPause()-->第二个Activity    onCreate()-->onStart()-->onResume() -->第一个Activity   onStop()

    当返回到第一个Activity时:

    第二个Activity onPause() --> 第一个Activity onRestart()-->onStart()-->onResume() -->第二个Activity   onStop()-->onDestroy()

    一个Activity的销毁顺序:
    (情况一)onPause()--><Process Killed> (被VM回收)
    (情况二)onPause()-->onStop()--><Process Killed>
    (情况三)onPause()-->onStop()-->onDestroy()

    每一个活动( Activity )都处于某一个状态,开发者来无法控制其应用程序处于某一个状态的,这些由系统完成。但是当一个活动的状态发生改变的时候,开发者可以通过调用 onXX() 的方法获取到相关的通知信息。在实现 Activity 类的时候,通过覆盖( override )这些方法即可在你需要处理的时候来调用。

    一、onCreate当活动第一次启动的时候触发该方法,在此时完成活动的初始化工作。onCreate 方法有一个参数,该参数可以为NULL,也可以是之前调用onSaveInstanceState()方法保存的状态信息。

    二、onStart该方法的触发表示所属活动将被展现给用户。

    三、onResume当一个活动和用户发生交互的时候,触发该方法。

    四、onPause当一个正在前台运行的活动因为其他的活动需要前台运行而转入后台运行的时候,触发该方法。这时候需要将活动的状态持久化,比如正在编辑的数据库记录等。

    五、onStop当一个活动不再需要展示给用户的时候,触发该方法。如果内存紧张,系统会直接结束这个活动,而不会触发 onStop 方法(情况一)。 所以保存状态信息是应该在onPause时做。活动如果没有在前台运行,都将被停止或者Linux管理进程为了给新的活动预留足够的存储空间而随时结束这些活动。在设计应用程序的时候,必须时刻牢记这一原则。onPause方法或许是活动触发的最后的方法,需要在这个时候保存需要保存的信息。

    六、onRestart当处于停止状态的活动需要再次展现给用户的时候,触发该方法。

    七、onDestroy :当活动销毁的时候,触发该方法。和onStop方法一样,如果内存紧张,系统会直接结束这个活动而不会触发该方法

    onSaveInstanceState系统调用该方法,允许活动保存之前的状态,比如说在一串字符串中的光标所处的位置等。通常情况下,开发者不需要重写覆盖该方法,在默认的实现中,已经提供了自动保存活动所涉及到的用户界面组件的所有状态信息。


    Activity栈

    上面提到开发者是无法控制Activity的状态的,那Activity的状态又是按照何种逻辑来运作的呢?这就要知道 Activity 栈。每个Activity的状态是由它在Activity栈(是一个后进先出LIFO,包含所有正在运行Activity的队列)中的位置决定的。当一个新的Activity启动时,当前的活动的Activity将会移到Activity栈的顶部。如果用户使用后退按钮返回的话,或者前台的Activity结束,活动的Activity就会被移出栈消亡,而在栈上的上一个活动的Activity将会移上来并变为活动状态。

    164612fz547ovznmtmmm1z

    一个应用程序的优先级是受最高优先级的Activity影响的。当决定某个应用程序是否要终结去释放资源,Android内存管理使用栈来决定基于Activity的应用程序的优先级。

    Activity状态
    一般认为Activity有以下四种状态:
    活动的:当一个Activity在栈顶,它是可视的、有焦点、可接受用户输入。VM尽最大可能保持它活动状态,杀死其它Activity来确保当前活动Activity有足够资源可用。当另一个Activity被激活,这个会被暂停。
    暂停:在很多情况下,你的Activity可视但是它没有焦点,换句话说它被暂停了。有可能原因是一个透明或者非全屏的Activity被激活。当被暂停,一个Activity仍会当成活动状态,只不过是不可以接受用户输入。在极特殊的情况下,Android将会杀死一个暂停的Activity来为活动的Activity提供充足的资源。当一个Activity变为完全隐藏,它将会变成停止。
    停止:当一个Activity不是可视的,它“停止”了。这个Activity将仍然在内存中保存它所有的状态和会员信息。尽管如此,当其它地方需要内存时,它将是最有可能被释放资源的。当一个Activity停止后,一个很重要的步骤是要保存数据和当前UI状态。一旦一个Activity退出或关闭了,它将变为待用状态。
    待用: 在一个Activity被杀死后和被装在前,它是待用状态的。待用Acitivity被移除Activity栈,并且需要在显示和可用之前重新启动它。

    activity的四种加载模式
    在android的多activity开发中,activity之间的跳转可能需要有多种方式,有时是普通的生成一个新实例,有时希望跳转到原来某个activity实例,而不是生成大量的重复的activity。加载模式便是决定以哪种方式启动一个跳转到原来某个Activity实例。
    在android里,有4种activity的启动模式,分别为:
    ·standard: 标准模式,一调用startActivity()方法就会产生一个新的实例。
    ·singleTop: 如果已经有一个实例位于Activity栈的顶部时,就不产生新的实例,而只是调用Activity中的newInstance()方法。如果不位于栈顶,会产生一个新的实例。
    ·singleTask: 会在一个新的task中产生这个实例,以后每次调用都会使用这个,不会去产生新的实例了。
    ·singleInstance: 这个跟singleTask基本上是一样,只有一个区别:在这个模式下的Activity实例所处的task中,只能有这个activity实例,不能有其他的实例。
    这些启动模式可以在功能清单文件AndroidManifest.xml中进行设置,中的launchMode属性。
    相关的代码中也有一些标志可以使用,比如我们想只启用一个实例,则可以使用 Intent.FLAG_ACTIVITY_REORDER_TO_FRONT 标志,这个标志表示:如果这个activity已经启动了,就不产生新的activity,而只是把这个activity实例加到栈顶来就可以了。

    Intent intent = new Intent(Main.this, OtherActivity.class);
    intent.addFlags(Intent.FLAG_ACTIVITY_REORDER_TO_FRONT);
    startActivity(intent);
    Activity的加载模式受启动Activity的Intent对象中设置的Flag和manifest文件中Activity的元素的特性值交互控制。
    二、Service详解
    service可以在和多场合的应用中使用,比如播放多媒体的时候用户启动了其他Activity这个时候程序要在后台继续播放,比如检测SD卡上文件的变化,再或者在后台记录你地理信息位置的改变等等,总之服务嘛,总是藏在后头的。
    Service是在一段不定的时间运行在后台,不和用户交互应用组件。每个Service必须在manifest中 通过<service>来声明。可以通过contect.startservice和contect.bindserverice来启动。
    Service和其他的应用组件一样,运行在进程的主线程中。这就是说如果service需要很多耗时或者阻塞的操作,需要在其子线程中实现。

    service的两种模式(startService()/bindService()不是完全分离的):

    本地服务 Local Service 用于应用程序内部。它可以启动并运行,直至有人停止了它或它自己停止。在这种方式下,它以调用Context.startService()启动,而以调用Context.stopService()结束。它可以调用Service.stopSelf() 或 Service.stopSelfResult()来自己停止。不论调用了多少次startService()方法,你只需要调用一次stopService()来停止服务。用于实现应用程序自己的一些耗时任务,比如查询升级信息,并不占用应用程序比如Activity所属线程,而是单开线程后台执行,这样用户体验比较好。

    远程服务 Remote Service 用于android系统内部的应用程序之间。它可以通过自己定义并暴露出来的接口进行程序操作。客户端建立一个到服务对象的连接,并通过那个连接来调用服务。连接以调用Context.bindService()方法建立,以调用 Context.unbindService()关闭。多个客户端可以绑定至同一个服务。如果服务此时还没有加载,bindService()会先加载它。可被其他应用程序复用,比如天气预报服务,其他应用程序不需要再写这样的服务,调用已有的即可。

    生命周期

    使用context.startService() 启动Service是会会经历:
    context.startService() ->onCreate()- >onStart()->Service running
    context.stopService() | ->onDestroy() ->Service stop
    如果Service还没有运行,则android先调用onCreate()然后调用onStart();如果Service已经运行,则只调用onStart(),所以一个Service的onStart方法可能会重复调用多次
    stopService的时候直接onDestroy,如果是调用者自己直接退出而没有调用stopService的话,Service会一直在后台运行。该Service的调用者再启动起来后可以通过stopService关闭Service。
    所以调用startService的生命周期为:onCreate --> onStart(可多次调用) –> onDestroy

    使用使用context.bindService()启动Service会经历:
    context.bindService()->onCreate()->onBind()->Service running
    onUnbind() -> onDestroy() ->Service stop

    onBind将返回给客户端一个IBind接口实例,IBind允许客户端回调服务的方法,比如得到Service运行的状态或其他操作。这个时候把调用者(Context,例如Activity)会和Service绑定在一起,Context退出了,Srevice就会调用onUnbind->onDestroy相应退出。所以调用bindService的生命周期为:onCreate --> onBind(只一次,不可多次绑定) --> onUnbind --> onDestory
    在Service每一次的开启关闭过程中,只有onStart可被多次调用(通过多次startService调用),其他onCreate,onBind,onUnbind,onDestory在一个生命周期中只能被调用一次。

    而启动service,根据onStartCommand的返回值不同,有两个附加的模式:
    1. START_STICKY 用于显示启动和停止service。
    2. START_NOT_STICKY或START_REDELIVER_INTENT用于有命令需要处理时才运行的模式。
    服务不能自己运行,需要通过调用Context.startService()或Context.bindService()方法启动服务。

    这两个方法都可以启动Service,但是它们的使用场合有所不同。
    1. 使用startService()方法启用服务,调用者与服务之间没有关连,即使调用者退出了,服务仍然运行。

    如果打算采用Context.startService()方法启动服务,在服务未被创建时,系统会先调用服务的onCreate()方法,接着调用onStart()方法。如果调用startService()方法前服务已经被创建,多次调用startService()方法并不会导致多次创建服务,但会导致多次调用onStart()方法。

    采用startService()方法启动的服务,只能调用Context.stopService()方法结束服务,服务结束时会调用onDestroy()方法。
    2. 使用bindService()方法启用服务,调用者与服务绑定在了一起,调用者一旦退出,服务也就终止,大有“不求同时生,必须同时死”的特点。
    onBind()只有采用Context.bindService()方法启动服务时才会回调该方法。该方法在调用者与服务绑定时被调用,当调用者与服务已经绑定,多次调用Context.bindService()方法并不会导致该方法被多次调用。采用Context.bindService()方法启动服务时只能调用onUnbind()方法解除调用者与服务解除,服务结束时会调用onDestroy()方法。
    看看官方给出的比较流程示意图:
    官方文档告诉我们,一个service可以同时start并且bind,在这样的情况,系统会一直保持service的运行状态如果service已经start了或者BIND_AUTO_CREATE标志被设置。如果没有一个条件满足,那么系统将会调用onDestory方法来终止service.所有的清理工作(终止线程,反注册接收器)都在onDestory中完成。
    拥有service的进程具有较高的优先级
    官方文档告诉我们,Android系统会尽量保持拥有service的进程运行,只要在该service已经被启动(start)或者客户端连接(bindService)到它。当内存不足时,需要保持,拥有service的进程具有较高的优先级。
      1. 如果service正在调用onCreate,onStartCommand或者onDestory方法,那么用于当前service的进程则变为前台进程以避免被killed。
      2. 如果当前service已经被启动(start),拥有它的进程则比那些用户可见的进程优先级低一些,但是比那些不可见的进程更重要,这就意味着service一般不会被killed.
      3. 如果客户端已经连接到service (bindService),那么拥有Service的进程则拥有最高的优先级,可以认为service是可见的。
      4. 如果service可以使用startForeground(int, Notification)方法来将service设置为前台状态,那么系统就认为是对用户可见的,并不会在内存不足时killed。
    如果有其他的应用组件作为Service,Activity等运行在相同的进程中,那么将会增加该进程的重要性。

    1.不需和Activity交互的本地服务

    public class LocalService extends Service {
    private static final String TAG = "LocalService";
    @Override
    public IBinder onBind(Intent intent) {
    Log.i(TAG, "onBind");
    return null;
    }
    @Override
    public void onCreate() {
    Log.i(TAG, "onCreate");
    super.onCreate();
    }
    @Override
    public void onDestroy() {
    Log.i(TAG, "onDestroy");
    super.onDestroy();
    }
    @Override
    public void onStart(Intent intent, int startId) {
    Log.i(TAG, "onStart");
    super.onStart(intent, startId);
    }
    }
    Activity:
     
    public class ServiceActivity extends Activity implements OnClickListener {
    	@Override
    	protected void onCreate(Bundle savedInstanceState) {
    		super.onCreate(savedInstanceState);
    		setContentView(R.layout.servicedemo);
    		((Button) findViewById(R.id.startLocalService)).setOnClickListener(this);
    		((Button) findViewById(R.id.stopLocalService)).setOnClickListener(this);
    	}
    
    	@Override
    	public void onClick(View v) {
    		switch (v.getId()) {
    		case R.id.startLocalService:
    			startService(new Intent("com.demo.SERVICE_DEMO"));
    			break;
    		case R.id.stopLocalService:
    			stopService(new Intent("com.demo.SERVICE_DEMO"));
    			break;
    
    		default:
    			break;
    		}
    
    	}
    
    }
    在AndroidManifest.xml添加:否则启动服务时会提示new Intent找不到"com.demo.SERVICE_DEMO"。
    <service android:name=".LocalService">
    <intent-filter>
    <action android:name="com.demo.SERVICE_DEMO" />
    <category android:name="android.intent.category.default" />
    </intent-filter>
    </service>

    对于这类不需和Activity交互的本地服务,是使用startService/stopService的最好例子。运行时可以发现第一次startService时,会调用onCreate和onStart,在没有stopService前,无论点击多少次startService,都只会调用onStart。而stopService时调用onDestroy。再次点击stopService,会发现不会进入service的生命周期的,即不会再调用onCreate,onStart和onDestroy。而onBind在startService/stopService中没有调用。

    2.本地服务和Activity交互

    官方的sample(APIDemo\app.LocalService)是最好的例子:

    这里可以发现onBind需要返回一个IBinder对象。也就是说和上一例子LocalService不同的是,
    1. 添加了一个public内部类继承Binder,并添加getService方法来返回当前的Service对象;
    2. 新建一个IBinder对象--new那个Binder内部类;
    3. onBind方法返还那个IBinder对象。

    Activity:

    明显看出这里面添加了一个名为ServiceConnection类,并实现了onServiceConnected(从IBinder获取Service对象)和onServiceDisconnected(set Service to null)。而bindService和unbindService方法都是操作这个ServiceConnection对象的。

    AndroidManifest.xml里添加:

    这里没什么特别的,因为service没有需要什么特别的action,所以只是声明service而已,而activity和普通的没差别。
    运行时,发现调用次序是这样的:
    bindService:
    1.LocalService : onCreate
    2.LocalService : onBind
    3.Activity: onServiceConnected
    unbindService: 只是调用onDestroy
    可见,onStart是不会被调用的,而onServiceDisconnected没有调用的原因在上面代码的注释有说明。

    三、Broadcast Receiver详解

    BroadcastReceiver 用于异步接收广播Intent。主要有两大类:

    ·正常广播 Normal broadcasts(用 Context.sendBroadcast()发送)是完全异步的。它们都运行在一个未定义的顺序,通常是在同一时间。这样会更有效,但意味着receiver不能包含所要使用的结果或中止的API。
    ·有序广播 Ordered broadcasts(用 Context.sendOrderedBroadcast()发送)每次被发送到一个receiver。所谓有序,就是每个receiver执行后可以传播到下一个receiver,也可以完全中止传播--不传播给其他receiver。 而receiver运行的顺序可以通过matched intent-filter 里面的android:priority来控制,当priority优先级相同的时候,Receiver以任意的顺序运行。

    要注意的是,即使是Normal broadcasts,系统在某些情况下可能会恢复到一次传播给一个receiver。 特别是receiver可能需要创建一个进程,为了避免系统超载,只能一次运行一个receiver。
    Broadcast Receiver 并没有提供可视化的界面来显示广播信息。可以使用Notification和Notification Manager来实现可视化的信息的界面,显示广播信息的内容,图标及震动信息。

    生命周期

    一个BroadcastReceiver 对象只有在被调用onReceive(Context, Intent)的才有效的,当从该函数返回后,该对象就无效的了,结束生命周期。
    因此从这个特征可以看出,在所调用的onReceive(Context, Intent)函数里,不能有过于耗时的操作,不能使用线程来执行。对于耗时的操作,请start service来完成。因为当得到其他异步操作所返回的结果时,BroadcastReceiver 可能已经无效了。

    发送广播
    事件的广播比较简单,构建Intent对象,可调用sendBroadcast(Intent)方法将广播发出。另外还有sendOrderedBroadcast(),sendStickyBroadcast()等方法,请查阅API Doc。


    接收广播

    通过定义一个继承BroadcastReceiver类来实现,继承该类后覆盖其onReceiver方法,并在该方法中响应事件。

    注册Receiver
    注册有两种方式:
    1. 静态方式,在AndroidManifest.xml的application里面定义receiver并设置要接收的action。


    2. 动态方式, 在activity里面调用函数来注册,和静态的内容差不多。一个形参是receiver,另一个是IntentFilter,其中里面是要接收的action。


    一个receiver可以接收多个action的,即可以有多个intent-filter,需要在onReceive里面对intent.getAction(action name)进行判断。
    个人推荐使用静态注册方式,由系统来管理receiver,而且程序里的所有receiver,可以在xml里面一目了然。而动态注册方式,隐藏在代码中,比较难发现。而且动态注册,需要特别注意的是,在退出程序前要记得调用Context.unregisterReceiver()方法。一般在activity的onStart()里面进行注册, onStop()里面进行注销。官方提醒,如果在Activity.onResume()里面注册了,就必须在Activity.onPause()注销。

    下面给出动态注册的接收来电的广播处理的CallReceiver的代码:一种方式是直接读取intent.getStringExtra("incoming_number")来获取来电号码:


    在运行时,发现除了响铃时可以获取来电号码,接听和挂断都不能成功获取的,显示为null。另一种方式是通过PhoneStateListener的onCallStateChanged来监听状态的变化:


    运行时也发现incomingNumber在接听和挂断时获取为blank。因为这里监听的是通话的状态变化,所以这个receiver会被调用3次。
    监听通话状态需要加上权限:

    小结:
      1. 对于sendBroadCast的intent对象,需要设置其action name;
      2. 推荐使用显式指明receiver,在配置文件AndroidManifest.xml指明;
      3. 一个receiver可以接收多个action;
      4. 每次接收广播都会重新生成一个接收广播的对象,再次调用onReceive;
      5. 在BroadCast 中尽量不要处理太多逻辑问题,建议复杂的逻辑交给Activity 或者 Service 去处理。



  • 相关阅读:
    【学车笔记】皮卡科目二考前笔记
    【Java学习笔记】继承和多态
    【Java学习笔记】Java中定义宏
    【读书笔记】《世界上最伟大的推销员》
    《大话设计模式》重印公告
    《大话设计模式》第29章OOTV杯超级模式大赛—模式总结(四)
    《大话设计模式》第29章OOTV杯超级模式大赛—模式总结(六)
    《大话设计模式》第29章OOTV杯超级模式大赛—模式总结(五)
    阅读不懂,图书之过——《大话设计模式》创作历程
    岁月凶残,敬请珍惜——得知早已不能过五四节时之随想
  • 原文地址:https://www.cnblogs.com/haoxiqiang/p/2931875.html
Copyright © 2020-2023  润新知