一、系统架构

1，四大组件

Activity、Service、broadcastReceiver、ContentProvider

1.1 activity 生命周期 、 启动模式

1.1.1 生命周期

https://www.jianshu.com/p/b1ff03a7bb1f

安卓生命周期
纠正：onStart()时处于可见不可交互状态。onResume()处于可见可交互状态

1.1.1.1 当前Activity为A，此时用户打开ActivityB后，那么A的onPause（）和B的onResume()哪个方法先执行？
答：先 A的onPause（） ，再B的onResume()

Activity的启动过程：由ActivityManagerService（AMS）对栈内的Activity状态进行同步管理 & 规定：新Activity启动前，栈顶的Activity必须先onPause（），才能启动新的Activity（执行onResume()）
注：为了让新的Activity尽快切换到前台，在 onPause()尽量不要做耗时 / 重量级操作

1.1.1.2 常见场景的生命周期调用

生命周期II

在清单文件中指定了屏幕方向，则Activity在锁屏和开启屏幕的时候执行的方法和顺序是：MainActivity onPause--->MainActivity onStop--->MainActivity onRestart--->MainActivity onStart--->MainActivity onResume

如果在清单文件中没有对屏幕进行设置，则Activity在锁屏时候执行的方法和顺序是：MainActivity onPause--->MainActivity onStop--->MainActivity onDestory--->MainActivity onCreate--->MainActivity onStart--->MainActivity onResume--->MainActivity onPause销毁之后又新建。

在开启屏幕的时候，Activity执行的方法及顺序是：MainActivity onResume--->MainActivity onPause--->MainActivity onStop--->MainActivity onDestory--->MainActivity onCreate--->MainActivity onStart--->MainActivity onResume。对于这种，锁屏后再次开启屏幕会销毁两次，重建两次。

第二中情况的解决办法：在清单文件里activity标签下配置 android:configChanges="orientation|screenSize"。

1.1.1.3 android:configChanges
用于捕获手机状态的改变。在当所指定属性(Configuration Changes)发生改变时，通知程序调用onConfigurationChanged()函数。

(1)、不设置Activity的android:configChanges时，切屏会重新调用各个生命周期，切横屏时会执行一次，切竖屏时会执行两次

(2)、设置Activity的android:configChanges="orientation"时，切屏还是会重新调用各个生命周期，切横、竖屏时只会执行一次

(3)、设置Activity的android:configChanges="orientation|keyboardHidden"时，切屏不会重新调用各个生命周期，只会执行onConfigurationChanged方法

但是，自从Android 3.2（API 13），在设置Activity的android:configChanges="orientation|keyboardHidden"后，还是一样 会重新调用各个生命周期的。

因为screen size也开始跟着设备的横竖切换而改变。所以，在AndroidManifest.xml里设置的MiniSdkVersion和 TargetSdkVersion属性大于等于13的情况下，

如果你想阻止程序在运行时重新加载Activity，除了设置"orientation"， 你还必须设置"ScreenSize"。

解决方法：

AndroidManifest.xml中设置android:configChanges="orientation|screenSize“

1.1.1.4 finish() onDestory()
finish() 是结束一个activity的生命周期，而onDestory() 则是activity的一个生命周期

finish()调用后，将此activity移出栈，并未及时调用onDestory()方法，释放资源。但因为已出栈，点击back键时，找不到此activity

1.1.2 启动模式

启动模式

1.1.2.1 知识

• 任务栈：管理activity，后进先出

  
  image.png

• 可在 manifest中设置，launchMode。也可通过Intent设置标志位

  intent.addFlags(FLAG_ACTIVITY_NEW_TASK)
  

• intent 设置优先级更高

• intent 无法设置单例模式

标记位属性 含义
FLAG_ACTIVITY_SINGLE_TOP 指定启动模式为栈顶复用模式（SingleTop）
FLAG_ACTIVITY_NEW_TASK 指定启动模式为栈内复用模式（SingleTask）
FLAG_ACTIVITY_CLEAR_TOP 所有位于其上层的Activity都要移除，SingleTask模式默认具有此标记效果
FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS 具有该标记的Activity不会出现在历史Activity的列表中，即无法通过历史列表回到该Activity上

1.2 fragment

1.2.1 生命周期

fragment生命周期 image.png

• 创建时
  onAttach() onCreate() onCreateCiew() onActivityCreated()

• 可见时
  onStart() onResume()

• 进入后台时
  onPause() onStop()

• fragment或activity被销毁
  onPause() onStop() onDestoryView() onDestory() onDetach()

• 屏幕熄灭/回到桌面
  onPause() onSaveInstanceState() onStop()

• 屏幕解锁/回到应用
  onStart() onResume()

Activity中调用replace()方法和addToBackStack()方法时的生命周期
新替换的Fragment（没有在BackStack中）：
onAttach > onCreate > onCreateView > onViewCreated > onActivityCreated > onStart > onResume
新替换的Fragment（已经在BackStack中）：
onCreateView > onViewCreated > onActivityCreated > onStart > onResume
被替换的Fragment：onPause > onStop > onDestroyView--> onDestroy --> onDetach

Fragment以下4个生命周期方法将跟随所属的Activity一起被调用：
onPause > onStop > onStart > onResume

1.2.2 fragment 和 activity 通信

• Handler
• 回调
• 广播或eventbus
• 持有对象
• bundle
• findFrgamentById/Tag

1.2.3 fragment 间通信

• 通过activity操作
• 回调、广播、eventbus

1.2.4 使用

静态添加： xml中作为view直接引用
动态添加步骤：

• 获取fragmentManager对象
• 开启一个事务 beginTransaction
• add remove replace
• 可以调用addToBackStack()，加入回退栈，管控此fragment
• 提交事务 commit()

1.2.5 fragment 在viewpager容器的 resume 刷新

setUserVisibleHint(true)

• 在onResume的时候，如果getUserVisibleHint的值是false，不一定不是当前显示，如果为true就一定是当前显示的Fragment
• setUserVisibleHint()在Fragment实例化时会先调用一次，并且默认值是false，当选中当前显示的Fragment时还会再调用一次。
• setUserVisibleHint()可能会在Fragment的生命周期之外被调用，也就是可能在view创建前就被调用，也可能在destroyView后被调用，所以如果涉及到一些控件的操作的话，可能会报 null 异常，因为控件还没初始化，或者已经摧毁了。
• 控制viewpager 加载数量 mPager .setOffscreenPageLimit(2);

1.3 broadcastReceiver

https://www.jianshu.com/p/ca3d87a4cdf3

使用了观察者模式，将发送者和接收者解耦

1.3.1 应用场景

• 不同组件简通信(应用内、应用间)
• 多线程通信
• 系统通信 【电话呼入，网络可用】

1.3.2 细解

广播模型
广播使用流程

• 广播接收器运行在UI线程，因此 onReceive()不可执行耗时操作，否则ANR

1.3.3 使用

静态注册：manifest中通过receiver标签声明

<receiver 
    android:enabled=["true" | "false"]
//此broadcastReceiver能否接收其他App的发出的广播
//默认值是由receiver中有无intent-filter决定的：如果有intent-filter，默认值为true，否则为false
    android:exported=["true" | "false"]
    android:icon="drawable resource"
    android:label="string resource"
//继承BroadcastReceiver子类的类名
    android:name=".mBroadcastReceiver"
//具有相应权限的广播发送者发送的广播才能被此BroadcastReceiver所接收；
    android:permission="string"
//BroadcastReceiver运行所处的进程
//默认为app的进程，可以指定独立的进程
//注：Android四大基本组件都可以通过此属性指定自己的独立进程
    android:process="string" >

//用于指定此广播接收器将接收的广播类型
//本示例中给出的是用于接收网络状态改变时发出的广播
 <intent-filter>
<action android:name="android.net.conn.CONNECTIVITY_CHANGE" />
    </intent-filter>
</receiver>

• 当 app首启时，系统会自动实例化此 mBroadcastReceiver 类，并注册

动态注册：代码中调用 .registerReceiver()方法

• 需记得在对应位置【onPause】销毁广播
• 当此 activity 实例化时，注册此广播。当activity销毁时，动态注册的广播将不再接收消息

• 建议在 onResume()注册广播，onPause()注销广播，而非 onCreate() & onDestory() , 是因为当系统内存不足，需要回收资源时，activity执行完onPause()之后就会被销毁，此时还未执行 onStop() onDestory()，即广播还未注销，导致内存泄漏

  
  两种注册方式区别

1.3.4 分类

普通广播、系统广播、有序广播、粘性广播、local broadcast、粘性广播
普通广播：开发者自定义 intent ，匹配接受者的intentFilter的action
系统广播：仅需注册广播接收器，接收系统广播的action

有序广播：优先级别高的广播接收器先接收，接收完了没有丢弃/修改(abortBroadcast())，传给次一级的广播接收器

• 优先级相同的情况下，动态注册的广播优先

粘性广播：发送之后一直存在于消息处理器中，等待对应的接收器去处理。如果接收器被销毁，则会在下次重建时自动接收消息数据

• 需要 权限 BROADCAST_STICKY
• 没有10秒限制，10秒限制是指普通的广播如果onReceive方法执行时间太长，超过10秒的时候系统会将这个广播置为可以干掉的candidate，一旦系统资源不够的时候，就会干掉这个广播而让它不执行。
• 5.0后已 不建议使用

应用内广播
存在原因：

• 其他App发出与当前app广播接收器相匹配的广播，导致当前app不断接收广播信息
• 其他app注册与当前app一直的接收器，接收当前app的广播，出现安全问题

应用内广播保证发送者和接受者属于同一个app
LocalBroadcastManager。接受者只能动态注册，不能静态注册

全局广播 -> 应用内广播 ：

• exported=false 使得非本app发送的广播不被接收
• 增加permission
• 发送广播时，指定包名 intent.setPackage(包名)

1.3.5 onReceive()参数context上下文区别

不同注册方式的广播接收器回调OnReceive（Context context，Intent intent）中的context返回值是不一样的：

• 对于静态注册（全局+应用内广播），回调onReceive(context, intent)中的context返回值是：ReceiverRestrictedContext；
• 对于全局广播的动态注册，回调onReceive(context, intent)中的context返回值是：Activity Context；
• 对于应用内广播的动态注册（LocalBroadcastManager方式），回调onReceive(context, intent)中的context返回值是：Application Context。
• 对于应用内广播的动态注册（非LocalBroadcastManager方式），回调onReceive(context, intent)中的context返回值是：Activity Context；

1.4 service 使用和生命周期、跨进程通信

1.5 contentProvider

https://www.jianshu.com/p/ea8bc4aaf057
结合消息模块message，存储数据库交互一起看

作用：进程间数据共享和交互

作用

原理： binder机制，分析见后文

1.5.1 contentProvider 使用

URI：统一资源标识符，外部线程通过URI找到对应的ContentProvider和其中的数据，并对数据进行操作
分为系统预置 和 自定义URI

Mime：指定数据类型，及打开的程序 。 = 类型+子类型

 text/html
 application/pdf

ContentProvider 以表格的形式，组织和管理数据【增删改查】
用于外部进程对数据进行操作的 实现。但不会直接和外部进程交互。

 ContentProvider.getType(uri)

• 需注意线程同步
• 若配合SQLite使用，则不需要考虑同步，因为SQLite内部实现了线程同步。 但使用多个SQLite时仍需考虑同步
• 若存储数据到内存等，需手动实现线程同步

ContentResolver：通过Uri操作ContentProvider的数据
外部进程，通过ContentResolver ， 与 ContentProvider 交互

为何不允许直接交互？
一款应用若使用多个contentProvider，直接交互需了解每个contentProvider的不同实现，成本高

提供了增删改查四个外部类
提供了三个辅助工具类： ContentUris、UriMatcher、ContentObserver

1.5.2 ContentResolver 辅助工具类

ContentUris : 操作URI

      parseId()   withAppendedId()

UriMatcher：
向ContentProvider注册URI ： matcher.addURI()
根据URI匹配ContentProvider中对应的数据表：matcher.match()

ContentObserver：内容观察者。观察指定URI引起的ContentProvider的数据变化，通知外界【即ContentObserver注册者】。即当ContentProvider的数据发生变化时，会触发ContentObserver的监听

    getContentResolver().registerContentObserver(URI)
    @Override onChange()