版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/qq_34501274/article/details/88415030
注：本文属于整理型文章，文章有地方用到的其他博主画的图和总结性的描述
杂谈（app优化、android机制系列）
杂谈（Lrucache机制）
杂谈（android基础知识点梳理笔记）
杂谈（http / https Socket）
四大组件相关知识点
Activity
描述：一个Activity通常就是一个单独的屏幕，就是用户看得到的
生命周期：onCreate、onStart、onResume、onPause、onStop、onDestroy
正常启动一个activity：onCreate -> onStart -> onResume
切换到后台/锁屏：onPause -> onStop 再打开界面 onRestart -> onStart-> onResume->
A到B界面：(A)onPause -> (B)onCreate -> (B)onStart -> (B)onResume -> (A)onStop->
这时如果按回退键回退到A onPause(B)->onRestart(A)->onStart(A)->onResume(A)->oStop(B)
Activity四种启动模式：
- Standard模式(默认启动模式)
每当我们启动一个Activity，系统就会相应的创建一个实例，不管这个实例是否已经存在。
- singleTop栈顶复用模式
如果要启动的Activity处于栈的顶部，那么此时系统不会创建新的实例，而是直接打开此页面，同时它
onNewIntent()方法会被执行，可以通过Intent进行传值，而且它的onCreate()，onStart()方法不会被调用。
- singleTask栈内复用模式
栈中存在这个Activity的实例就会复用这个Activity，复用时，它上面的Activity全部出栈，
因为singleTask本身自带clearTop这种功能。并且会回调该实例的onNewIntent()方法
- SingleInstance模式
该模式具备singleTask模式的所有特性外，与它的区别就是，这种模式下的Activity会单独占用一个Task栈，
具有全局唯一性，即整个系统中就这么一个实例，由于栈内复用的特性，
后续的请求均不会创建新的Activity实例，除非这个特殊的任务栈被销毁了。
以singleInstance模式启动的Activity在整个系统中是单例的，
如果在启动这样的Activiyt时，已经存在了一个实例，那么会把它所在的任务调度到前台，重用这个实例。
Activity横竖屏切换时生命周期
竖屏启动----切换横屏（没有配置 <!--android:configChanges="orientation|keyboardHidden|screenSize"-->）
onPause--->
onSaveInstanceState --->
onStop--->
onDestroy--->
onCreate--->
onStart--->
onRestoreInstanceState--->
onResume--->
注：关于旋转屏幕无法调用onSaveInstanceState的问题，出现这种问题你复写的肯定以下方法
public void onSaveInstanceState (Bundle outState, PersistableBundle outPersistentState)；
改成以下方法即可
public void onSaveInstanceState (Bundle outState){
/**
*可在此方法保存之前状态数据，onRestoreInstanceState中恢复
*/
}
配置 android:configChanges="orientation|keyboardHidden|screenSize"
切换时只走：onConfigurationChanged
Broadcast Receiver
广播使用了设计模式中的观察者模式：基于消息的发布 / 订阅事件模型，因此
因此，Android将广播的发送者 和 接收者 解耦，使得系统方便集成，更易扩展。
注册方式：静态注册、动态注册(优先级较高)
响应时间：onRecevie（10秒之内不能完成的话，会被android判定程序无响应。
普通广播
可在同一时刻被所有接收者接收到。
缺点：无法将数据结果传递给下一个。sendBroadcast()发送无序广播
有序广播
/**
* 1.有序广播的接收者按照之前定义的优先级依次接收Broadcast
* 2.设置优先级①在AndroidManifest的<Intent-filter android:priority=数值>
* ②在代码的IntentFilter对象的 setPriority()取值范围是1~1000
* 3.sendOrderedBroadcast()发送有序广播
* 4.同时，优先收到广播的接收者可以停止继续发送Broadcast：调用abortBroadcast();
* 优先收到广播的接收者可以通过setResultExtras(Bundle)将数据存入Broadcast，然后传送给下一个接收者，
* 下一个接收者通过Bundle bundle = getResultExtras(true);接收数据
* */
广播是全局性,安全性不好，建议使用本地广播只接收应用程序内广播
核心用法
使用LocalBroadcastManager来管理广播：
a.调用LocalBroadcastManager.getInstance(this)来获得实例
b.调用xx.registerReceiver(BroadcastReceiver receiver,IntentFilter filter)来注册广播;(receiver本地广播接收器)
c.调用xx.sendBroadcast()发送广播
d.调用xx.unregisterReceiver()取消注册
注意事项
a.本地广播无法通过静态注册来接收，相比起系统全局广播更加高效
b.在广播中启动activity的话，需要为intent加入FLAG_ACTIVITY_NEW_TASK的标记，不然会报错，
因为需要一个栈来存放新打开的activity。
c.广播中弹出AlertDialog的话，需要设置对话框的类型为:TYPE_SYSTEM_ALERT不然是无法弹出的。
Broadcast Receiver、本地广播区别，本地广播建议去看下源码
service
响应时长：20s
/**
* 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会自行销毁。
* */
private ServiceConnection conn = new ServiceConnection() {
@Override
public void onServiceConnected(ComponentName name, IBinder binder) {
// 连接成功会调用
}
@Override
public void onServiceDisconnected(ComponentName name) {
}
};
两种启动方式的生命周期。
ContentProvider
进程间 进行数据交互 & 共享，即跨进程通信
Android中许多系统应用都使用该方式实现数据共享，比如通讯录、短信等
- 是对数据的封装。提供统一的接口
- 跨进程数据共享的方式
Fragment生命周期
- Fragment在Activity中replace onPause(旧) -> onAttach -> onCreate -> onCreateView -> onActivityCreated -> onStart -> onResume -> onStop(旧) -> onDestoryView(旧)
谈谈对接口回调的理解
A.面向对象设计的封装性，模块间要解耦，模块内要内聚
B.协作、解耦
/**
* a.（回调）协作：A对象关心B对象的状态变化,B对象提供一个监听B对象状态的接口，让A对象添加这个监听，
* B对象的状态就可以通过接口函数告诉A了。另辟独径的给对象解耦。
* 这样就实现了模块间协作。常见的例子：给Recyclerview设置Item的点击事件
*
* b.(接口)解耦：削弱模块间的协作性（耦合性），使得模块之间高度独立，模块间更多的从事着单向的调用工作。
* 一个模块需要某种服务就去找另一个模块，这使得程序呈现出层次性，高层通过接口调用底层，底层提供服务。
* 摈弃模块间你中有我我中有你的暧昧关系。
*
*/
a.b合起来就是接口回调：
LinearLayout、RelativeLayout、FrameLayout的特性及对比，并介绍使用场景。
LinearLayout、RelativeLayout、FrameLayout的特性及对比，并介绍使用场景
1.RelativeLayout会让子View调用2次onMeasure，LinearLayout 在有weight时。也会调用子View2次onMeasure
2.RelativeLayout的子View假设高度和RelativeLayout不同，则会引发效率问题，当子View非常复杂时，这个问题会更加严重。
3.在不影响层级深度的情况下,使用LinearLayout和FrameLayout而不是RelativeLayout。
/**
* 最后再思考一下文章开头那个矛盾的问题，为什么Google给开发人员默认新建了个RelativeLayout，而自己却在DecorView中用了个LinearLayout
* 由于DecorView的层级深度是已知并且固定的，上面一个标题栏，以下一个内容栏。採用RelativeLayout并不会减少层级深度，所以此时在根节点上*用LinearLayout是效率最高的。
* 而之所以给开发人员默认新建了个RelativeLayout是希望开发人员能採用尽量少的View层级来表达布局以实现性能最优，
* 由于复杂的View嵌套对性能的影响会更大一些。
*/
4.能用两层LinearLayout，尽量用一个RelativeLayout，在时间上此时RelativeLayout耗时更小。
另外LinearLayout慎用layout_weight,也将会添加一倍耗时操作。
由于使用LinearLayout的layout_weight,大多数时间是不一样的，这会减少測量的速度。
这仅仅是一个怎样合理使用Layout的案例，必要的时候。你要小心考虑是否用layout weight。总之减少层级结构，才是王道。
让onMeasure做延迟载入，用viewStub等一些技巧。
序列化的作用，以及Android两种序列化的区别
- 作用：
1.Serializable：为了保存对象的属性到本地文件、数据库、网络流、rmi以方便数据传输，当然这种传输可以是程序内的也可以是两个程序间的
2.Pacelable：为了在程序内不同组件间以及不同Android程序间(AIDL)高效的传输数据而设计。
这些数据仅在内存中存在，Parcelable是通过IBinder通信的消息的载体
- 效率：
Parcelable的性能比Serializable好，在内存开销方面较小。
在内存间数据传输时推荐使用Parcelable
在需要保存或网络传输数据时选择Serializable
- 编程：
1.Serializable需要提供一个serialVersionUID。
2.Parcelable则需要实现writeToParcel、describeContents函数以及静态的CREATOR变量，实际上就是将如何打包和解包的工作自己来定义，
而序列化的这些操作完全由底层实现
- 区别：
Serializable在序列化时会产生大量临时变量，引起频繁GC。
Serializable本质上使用了反射，序列化过程慢。
Parcelable不能将数据存储在磁盘上，在外界变化时，它不能很好的保证数据的持续性
- 高级功能上
Serializable序列化不保存静态变量，可以使用Transient关键字对部分字段不进行序列化，
也可以覆盖writeObject、readObject方法以实现序列化过程自定义
Android的数据存储方式
- 文件存储
- SharedPreferences
- SQLite的数据库存储
- 内容提供商者
- 网络存储