一。Activity
参考链接：http://blog.csdn.net/CodeEmperor/article/details/50481726
“standard”“singleTop””singleTask””singleInstance”
说启动模式首先说一下任务栈：
（1)程序打开时就创建了一个任务栈, 用于存储当前程序的activity,所有的activity属于一个任务栈。
(2)一个任务栈包含了一个activity的集合, 去有序的选择哪一个activity和用户进行交互:只有在任务栈栈顶的activity才可以跟用户进行交互。
(3)任务栈可以移动到后台, 并且保留了每一个activity的状态. 并且有序的给用户列出它们的任务, 而且还不丢失它们状态信息。
(4)退出应用程序时：当把所有的任务栈中所有的activity清除出栈时,任务栈会被销毁,程序退出。
任务栈的缺点：
(1)每开启一次页面都会在任务栈中添加一个Activity,而只有任务栈中的Activity全部清除出栈时，任务栈被销毁，程序才会退出,这样就造成了用，户体验差, 需要点击多次返回才可以把程序退出了。
(2)每开启一次页面都会在任务栈中添加一个Activity还会造成数据冗余, 重复数据太多, 会导致内存溢出的问题(OOM)。
为了解决任务栈的缺点，我们引入了启动模式。
启动模式（launchMode）在多个Activity跳转的过程中扮演着重要的角色，它可以决定是否生成新的Activity实例，是否重用已存在的Activity实例，是否和其他Activity实例公用一个task里。这里简单介绍一下task的概念，task是一个具有栈结构的对象，一个task可以管理多个Activity，启动一个应用，也就创建一个与之对应的task。
如何配置Activity的启动模式?
直接在AndroidManifest.xml配置的android:launchMode属性为以上四种之一即可。
1.“standard”:默认的启动模式，不用为配置android:launchMode属性,不管在Task中有没有已存在的实例，都生成新的实例，并置于栈顶。
2.“singleTop”:首先在Task中查找此actvity是否存在于栈顶，如果存在的话，将不再生成，重复利用此activity(实例)，如果不存在，就在栈顶重新生成一个activity。应用：例如QQ的聊天消息推送连发十条，不能每点开一条就打开一个actvity实例。
3.“singleTask”:首先在Task中查找是否有此activity实例，如果有的话将此实例上的所有实例统统移出栈，此实例置顶。如果没有此实例的话，在栈顶生成此activity实例。
应用需求说明： 如果自己的客户端处于运行状态，按下Home键后台挂起。此时如果使用微信调起自己的客户端某 个页面，不做任何处理的情况下，按下回退或者当前 Activity.finish()，页面都会停留在自己的客户端（因为自己的Application回 退栈不为空），这明显不符合逻辑的。产品的要求 是，回退必须回到微信客户端,而且要保证不杀死自己的Application.
处理方案： 设置当前 被调起Activity的属性 为：LaunchMode=""SingleTask" taskAffinity="com.tencent.mm"(com.tencent.mm 是借助于工具找到的微信包名），就是把自己的 Activity放到微信默认的Task栈里面，这样回退时就会遵循“Task只要有Activity一定 从本Task剩余Activity回退"的原 则，不会回到自己的客户端，而且也不会影响自己客户端本来的Activity和Task逻辑。
所以singleTask配合TaskAffinity食用更佳
4.“singleInstance”:这种启动模式比较特殊，因为它会启用一个新的栈结构，将Activity放置于这个新的栈结构中，并保证不再有其他Activity实例进入。 实例：闹钟的设定，电话的接听
二。Fragment：
Fragment每个生命周期方法的意义、作用（注意红色的不是生命周期方法）：
setUserVisibleHint()：设置Fragment可见或者不可见时会调用此方法。在该方法里面可以通过调用getUserVisibleHint()获得Fragment的状态是可见还是不可见的，如果可见则进行懒加载操作。
onAttach()：执行该方法时，Fragment与Activity已经完成绑定，该方法有一个Activity类型的参数，代表绑定的Activity，这时候你可以执行诸如mActivity = activity的操作。
onCreate()：初始化Fragment。可通过参数savedInstanceState获取之前保存的值。
onCreateView()：初始化Fragment的布局。加载布局和findViewById的操作通常在此函数内完成，但是不建议执行耗时的操作，比如读取数据库数据列表。
onActivityCreated()：执行该方法时，与Fragment绑定的Activity的onCreate方法已经执行完成并返回，在该方法内可以进行与Activity交互的UI操作，所以在该方法之前Activity的onCreate方法并未执行完成，如果提前进行交互操作，会引发空指针异常。
onStart()：执行该方法时，Fragment由不可见变为可见状态。
onResume()：执行该方法时，Fragment处于活动状态，用户可与之交互。
onPause()：执行该方法时，Fragment处于暂停状态，但依然可见，用户不能与之交互。
onSaveInstanceState()：保存当前Fragment的状态。该方法会自动保存Fragment的状态，比如EditText键入的文本，即使Fragment被回收又重新创建，一样能恢复EditText之前键入的文本。
onStop()：执行该方法时，Fragment完全不可见。
onDestroyView()：销毁与Fragment有关的视图，但未与Activity解除绑定，依然可以通过onCreateView方法重新创建视图。通常在ViewPager+Fragment的方式下会调用此方法。
onDestroy()：销毁Fragment。通常按Back键退出或者Fragment被回收时调用此方法。
onDetach()：解除与Activity的绑定。在onDestroy方法之后调用。
Fragment生命周期执行流程（注意红色的不是生命周期方法）：
Fragment创建(包括Activity的）：setUserVisibleHint()->onAttach()->onCreate()->onCreateView()->(Activity)onCreat()->onActivityCreated()->(Activity)onStart->onStart()->(Activity)onResume->onResume()；
Fragment变为不可见状态（锁屏、回到桌面、被Activity完全覆盖）：onPause()->(Activity)onPause->onSaveInstanceState()->onStop()->(Activity)onStop()；
Fragment变为部分可见状态（打开Dialog样式的Activity）：onPause()->(Activity)onPause->onSaveInstanceState()；
Fragment由不可见变为活动状态：(Activity)onStart->onStart()->(Activity)onResume->onResume()；
Fragment由部分可见变为活动状态：onResume()；
退出应用：onPause()->(Activity)onPause->onStop()->(Activity)onStop()->onDestroyView()->onDestroy()->onDetach()->(Activity)onDestory（注意退出不会调用onSaveInstanceState方法，因为是人为退出，没有必要再保存数据）；
Fragment被回收又重新创建：被回收执行onPause()->onSaveInstanceState()->onStop()->onDestroyView()->onDestroy()->onDetach()，重新创建执行onAttach()->onCreate()->onCreateView()->onActivityCreated()->onStart()->onResume()->setUserVisibleHint()；
横竖屏切换：与Fragment被回收又重新创建一样。
使用 FragmentTransaction 添加Fragment的时候，它提供了这样两个方法，一个 add ， 一个 replace .
add 和 replace 影响的只是界面，而控制回退的，是事务。
add 是把一个fragment添加到一个容器 container 里。
replace 是先remove掉相同id的所有fragment，然后在add当前的这个fragment。
在大部分情况下，这两个的表现基本相同。因为，一般，咱们会使用一个FrameLayout来当容器，而每个Fragment被add 或者 replace 到这个FrameLayout的时候，都是显示在最上层的。所以你看到的界面都是一样的。但是，使用add的情况下，这个FrameLayout其实有2层，多层肯定要比一层的来得浪费，所以还是推荐使用replace。当然有时候还是需要使用add的。比如要实现轮播图的效果，每个轮播图都是一个独立的Fragment，而他的容器FrameLayout需要add多个Fragment，这样他就可以根据提供的逻辑进行轮播了。
而至于返回键的时候，这个跟事务有关，跟使用add还是replace没有任何关系。
三：Service：
Service分为本地服务（LocalService）和远程服务（RemoteService）：
1、本地服务依附在主进程上而不是独立的进程，这样在一定程度上节约了资源，另外Local服务因为是在同一进程因此不需要IPC，也不需要AIDL。相应bindService会方便很多。主进程被Kill后，服务便会终止。
2、远程服务为独立的进程，对应进程名格式为所在包名加上你指定的android:process字符串。由于是独立的进程，因此在Activity所在进程被Kill的时候，该服务依然在运行,不受其他进程影响，有利于为多个进程提供服务具有较高的灵活性。该服务是独立的进程，会占用一定资源，并且使用AIDL进行IPC稍微麻烦一点。
按使用方式可以分为以下三种：
1、startService 启动的服务：主要用于启动一个服务执行后台任务，不进行通信。停止服务使用stopService；
2、bindService 启动的服务：该方法启动的服务可以进行通信。停止服务使用unbindService；
3、startService 同时也 bindService 启动的服务：停止服务应同时使用stepService与unbindService
第一种方式：通过StartService启动Service
通过startService启动后，service会一直无限期运行下去，只有外部调用了stopService()或stopSelf()方法时，该Service才会停止运行并销毁。
要创建一个这样的Service，你需要让该类继承Service类，然后重写以下方法：
onCreate()
1.如果service没被创建过，调用startService()后会执行onCreate()回调；
2.如果service已处于运行中，调用startService()不会执行onCreate()方法。
也就是说，onCreate()只会在第一次创建service时候调用，多次执行startService()不会重复调用onCreate()，此方法适合完成一些初始化工作。
onStartCommand()
如果多次执行了Context的startService()方法，那么Service的onStartCommand()方法也会相应的多次调用。onStartCommand()方法很重要，我们在该方法中根据传入的Intent参数进行实际的操作，比如会在此处创建一个线程用于下载数据或播放音乐等。
onBind()
Service中的onBind()方法是抽象方法，Service类本身就是抽象类，所以onBind()方法是必须重写的，即使我们用不到。
onDestory()
在销毁的时候会执行Service该方法。
需要注意，项目中的每一个Service都必须在AndroidManifest.xml中注册才行，所以还需要编辑AndroidManifest.xml文件
第二种方式：通过bindService启动Service
bindService启动服务特点：
1.bindService启动的服务和调用者之间是典型的client-server模式。调用者是client，service则是server端。service只有一个，但绑定到service上面的client可以有一个或很多个。这里所提到的client指的是组件，比如某个Activity。
2.client可以通过IBinder接口获取Service实例，从而实现在client端直接调用Service中的方法以实现灵活交互，这在通过startService方法启动中是无法实现的。
3.bindService启动服务的生命周期与其绑定的client息息相关。当client销毁时，client会自动与Service解除绑定。当然，client也可以明确调用Context的unbindService()方法与Service解除绑定。当没有任何client与Service绑定时，Service会自行销毁。
如何保证Service不被杀死？
1. onStartCommand方式中，返回START_STICKY
首先我们来看看onStartCommand都可以返回哪些值：
调用Context.startService方式启动Service时，如果Android面临内存匮乏，可能会销毁当前运行的Service，待内存充足时可以重建Service。而Service被Android系统强制销毁并再次重建的行为依赖于Service的onStartCommand()方法的返回值。
START_NOT_STICKY
如果返回START_NOT_STICKY，表示当Service运行的进程被Android系统强制杀掉之后，不会重新创建该Service。当然如果在其被杀掉之后一段时间又调用了startService，那么该Service又将被实例化。那什么情境下返回该值比较恰当呢？如果我们某个Service执行的工作被中断几次无关紧要或者对Android内存紧张的情况下需要被杀掉且不会立即重新创建这种行为也可接受，那么我们便可将 onStartCommand的返回值设置为START_NOT_STICKY。举个例子，某个Service需要定时从服务器获取最新数据：通过一个定时器每隔指定的N分钟让定时器启动Service去获取服务端的最新数据。当执行到Service的onStartCommand时，在该方法内再规划一个N分钟后的定时器用于再次启动该Service并开辟一个新的线程去执行网络操作。假设Service在从服务器获取最新数据的过程中被Android系统强制杀掉，Service不会再重新创建，这也没关系，因为再过N分钟定时器就会再次启动该Service并重新获取数据。
START_STICKY
如果返回START_STICKY，表示Service运行的进程被Android系统强制杀掉之后，Android系统会将该Service依然设置为started状态（即运行状态），但是不再保存onStartCommand方法传入的intent对象，然后Android系统会尝试再次重新创建该Service，并执行onStartCommand回调方法，但是onStartCommand回调方法的Intent参数为null，也就是onStartCommand方法虽然会执行但是获取不到intent信息。如果你的Service可以在任意时刻运行或结束都没什么问题，而且不需要intent信息，那么就可以在onStartCommand方法中返回START_STICKY，比如一个用来播放背景音乐功能的Service就适合返回该值。
START_REDELIVER_INTENT
如果返回START_REDELIVER_INTENT，表示Service运行的进程被Android系统强制杀掉之后，与返回START_STICKY的情况类似，Android系统会将再次重新创建该Service，并执行onStartCommand回调方法，但是不同的是，Android系统会再次将Service在被杀掉之前最后一次传入onStartCommand方法中的Intent再次保留下来并再次传入到重新创建后的Service的onStartCommand方法中，这样我们就能读取到intent参数。只要返回START_REDELIVER_INTENT，那么onStartCommand重的intent一定不是null。如果我们的Service需要依赖具体的Intent才能运行（需要从Intent中读取相关数据信息等），并且在强制销毁后有必要重新创建运行，那么这样的Service就适合返回START_REDELIVER_INTENT。
2.提高Service的优先级
在AndroidManifest.xml文件中对于intent-filter可以通过android:priority = "1000"这个属性设置最高优先级，1000是最高值，如果数字越小则优先级越低，同时适用于广播。
3.提升Service进程的优先级
当系统进程空间紧张时，会依照优先级自动进行进程的回收。
Android将进程分为6个等级，按照优先级由高到低依次为：
前台进程foreground_app
可视进程visible_app
次要服务进程secondary_server
后台进程hiddena_app
内容供应节点content_provider
空进程empty_app
可以使用startForeground将service放到前台状态，这样低内存时，被杀死的概率会低一些。
4.在onDestroy方法里重启Service
当service走到onDestroy()时，发送一个自定义广播，当收到广播时，重新启动service。
5.系统广播监听Service状态
6.将APK安装到/system/app，变身为系统级应用
四：BroadcastReceiver 参考链接
在Android中，Broadcast是一种广泛运用的在应用程序之间传输信息的机制。而BroadcastReceiver是对发送出来的 Broadcast进行过滤接受并响应的一类组件。
下面将详细的阐述如何发送Broadcast和使用BroadcastReceiver过滤接收的过程：
首先在需要发送信息的地方，把要发送的信息和用于过滤的信息(如Action、Category)装入一个Intent对象，然后通过调用 sendOrderBroadcast()或sendStickyBroadcast()方法，把 Intent对象以广播方式发送出去。
当Intent发送以后，所有已经注册的BroadcastReceiver会检查注册时的IntentFilter是否与发送的Intent相匹配，若匹配则就会调用BroadcastReceiver的onReceive()方法。所以当我们定义一个BroadcastReceiver的时候，都需要实现onReceive()方法。
注册BroadcastReceiver有两种方式:
静态注册：在AndroidManifest.xml中用标签生命注册，并在标签内用标签设置过滤器。
<receiver android:name="myRecevice"> //继承BroadcastReceiver，重写onReceiver方法
<intent-filter>
<action android:name="com.dragon.net"></action> //使用过滤器，接收指定action广播
</intent-filter>
</receiver>
动态注册：
IntentFilter intentFilter = new IntentFilter();
intentFilter.addAction(String); //为BroadcastReceiver指定action，使之用于接收同action的广播
registerReceiver(BroadcastReceiver,intentFilter);
一般：在onStart中注册，onStop中取消unregisterReceiver
指定广播目标Action：Intent intent = new Intent(actionString);
并且可通过Intent携带消息 :intent.putExtra("msg", "hi,我通过广播发送消息了");
发送广播消息：Context.sendBroadcast(intent )
其中在动态注册中可将BroadcastReceiver的继承类进行封装，添加构造函数和BroadcastReceiver注册
网友评论