Android 面试总结

1、Activity、Dialog、PopupWindow、Toast 与Window的关系

简单的从创建方式的角度来说一说：

Activity。在Activity创建过程中所创建的PhoneWindow，是层级最小的Window，叫做应用Window，层级范围1-99。（层级范围大的Window可以覆盖层级小的Window）

Dialog。Dialog的显示过程和Activity基本相同，也是创建了PhoneWindow，初始化DecorView,并将Dialog的视图添加到DecorView中，最终通过addView显示出来。

但是有一点不同的是，Dialog的Window并不是应用窗口，而是子窗口，层级范围1000-1999，子Window的显示必须依附于应用窗口，也会覆盖应用级Window。这也就是为什么Dialog传入的上下文必须为Activity的Context了。

PopupWindow。PopupWindow的显示就有所不同了，它没有创建PhoneWindow，而是直接创建了一个View（PopupDecorView），然后通过WindowManager的addView方法显示出来了。

没有创建PhoneWindow，是不是就跟Window没关系了呢？

并不是，其实只要是调用了WindowManager的addView方法，那就是创建了Window，跟你有没有创建PhoneWindow无关。View就是Window的表现形式，只不过PhoneWindow的存在让Window形象更立体了一些。

所以PopupWindow也是通过Window展示出来的，而它的Window层级属于子Window，必须依附与应用窗口。

Toast。Toast和PopupWindow比较像，没有新建PhoneWindow，直接通过addView方法显示View即可。不同的是它属于系统级Window,层级范围2000-2999，所以无须依附于Activity。

四个比较下来，可以发现，只要想显示View，就会涉及到WindowManager的addView方法，也就用到了Window这个概念，然后会根据不同的分层依次显示覆盖到界面上。

不同的是，Activity和Dialog涉及到了布局比较复杂，还会有布局主题等元素，所以用到了PhoneWindow进行一个解耦，帮助他们管理View。而PopupWindow和Toast结构比较简单，所以直接新建一个类似DecorView的View，通过addView显示到界面。

2、onSaveInstanceState()什么时候会被调用呢？

概括的讲，onSaveInstanceState 这个方法会在activity 将要被kill之前被调用以保存每个实例的状态，以保证在将来的某个时刻回来时可以恢复到原来的状态，但和activity 的生命周期方法onStop 和 onPause 不一样，与两者并没有绝对的先后调用顺序，或者说并非所有场景都会调用onSaveInstanceState 方法。

那么onSaveInstanceState 方法何时会被调用呢，或者这么问，什么时候activity 会被系统kill 掉呢？

有以下几种比较常见的场景：

（1）用户主动按下home 键，系统不能确认activity 是否会被销毁，实际上此刻系统也无法预测将来的场景，比如说内存占用，应用运行情况等，所以系统会调用onSaveInstanceState保存activity状态 ；

（2）activity位于前台，按下电源键，直接锁屏； （

  (3）横竖屏切换；

（4）activity B启动后位于activity A之前，在某个时刻activity A因为系统回收资源的问题要被kill掉，A通过onSaveInstanceState保存状态。

换句话说，onSaveInstanceState（）的调用遵循一个重要原则，即当系统存在“未经你许可”时销毁了我们的Activity,则onSaveInstanceState()会被系统调用，这是系统的职责，因为它必须要提供一个机会让用户保存数据。

3、Android 数据持久化之 SharedPreferences

Android之SharedPreferences内部原理浅析

剖析 SharedPreference apply 引起的 ANR 问题

总结：

1. sSharedPrefsCache 是一个 ArrayMap<String,ArrayMap<File,SharedPreferencesImpl>>，它会保存加载到内存中的 SharedPreferences 对象，ContextImpl 类中并没有定义将 SharedPreferences 对象移除 sSharedPrefsCache 的方法，所以一旦加载到内存中，就会存在直至进程销毁。相对的，也就是说，SP 对象一旦加载到内存，后面任何时间使用，都是从内存中获取，不会再出现读取磁盘的情况
2. SharedPreferences 和 Editor 都只是接口，真正的实现在 SharedPreferencesImpl 和 EditorImpl ，SharedPreferences 只能读数据，它是在内存中进行的，Editor 则负责存数据和修改数据，分为内存操作和磁盘操作
3. 获取 SP 只能通过 ContextImpl#getSharedPerferences 来获取，它里面首先通过 mSharedPrefsPaths 根据传入的 name 拿到 File ，然后根据 File 从 ArrayMap<File, SharedPreferencesImpl> cache 里取出对应的 SharedPrederenceImpl 实例
4. SharedPreferencesImpl 实例化的时候会启动子线程来读取磁盘文件，但是在此之前如果通过 SharedPreferencesImpl#getXxx 或者 SharedPreferences.Editor 会阻塞 UI 线程，因为在从 SP 文件中读取数据或者往 SP 文件中写入数据的时候必须等待 SP 文件加载完
5. 在 EditorImpl 中 putXxx 的时候，是通过 HashMap 来存储数据，提交的时候分为 commit 和 apply，它们都会把修改先提交到内存中，然后在写入磁盘中。只不过 apply 是异步写磁盘，而 commit 可能是同步写磁盘也可能是异步写磁盘，在于前面是否还有写磁盘任务。对于 apply 和 commit 的同步，是通过 CountDownLatch 来实现的，它是一个同步工具类，它允许一个线程或多个线程一致等待，直到其他线程的操作执行完之后才执行
6. SP 的读写操作是线程安全的，它对 mMap 的读写操作用的是同一把锁，考虑到 SP 对象的生命周期与进程一致，一旦加载到内存中就不会再去读取磁盘文件，所以只要保证内存中的状态是一致的，就可以保证读写的一致性

注意事项以及优化建议

1. 强烈建议不要在 SP 里面存储特别大的 key/value ，有助于减少卡顿 / ANR
2. 请不要高频的使用 apply，尽可能的批量提交；commit 直接在主线程操作，更要注意了
3. 不要使用 MODE_MULTI_PROCESS
4. 高频写操作的 key 与高频读操作的 key 可以适当的拆分文件，以减少同步锁竞争
5. 不要连续多次 edit，每次 edit 就是打开一次文件，应该获取一次 edit，然后多次执行 putXxx，减少内存波动，所以在封装方法的时候要注意了
6. apply 在 QueueWork 维护的单线程池调用，虽然是异步的但是可能会阻塞 Service.onStop 和 Activity.onPause 方法，可能会导致 ANR

ANR 容易发生的地方：

1. sp.g etXxx，首先会调用 awaitLoadedLocked 等待首次 sp 文件创建与读取操作完成
2. sp.apply 虽然是异步的但是可能会在 Service Activity 等生命周期期间 mcr.writtenToDiskLatch.await() 等待过久
3. sp.commit最终会调用 s p.writeToFile 方法，很耗时
4. ContextImpl.getSharedPreferences，主线程直接调用的话，如果 sp 文件很大处理时间也就会变大。

4、Activity的启动过程

应用启动过程

1. Launcher通过Binder进程间通信机制通知AMS，它要启动一个Activity
2. AMS通过Binder进程间通信机制通知Launcher进入Paused状态
3. Launcher通过Binder进程间通信机制通知AMS，它已经准备就绪进入Paused状态，于是AMS就创建一个新的线程，用来启动一个ActivityThread实例，即将要启动的Activity就是在这个ActivityThread实例中运行
4. ActivityThread通过Binder进程间通信机制将一个ApplicationThread类型的Binder对象传递给AMS，以便以后AMS能够通过这个Binder对象和它进行通信
5. AMS通过Binde进程间通信机制通知ActivityThread，现在一切准备就绪，它可以真正执行Activity的启动操作了

5、Service生命周期

startService() --> onCreate() --> onStartCommand() --> Service running --> onDestory()

bindService() --> onCreate() --> onBind() --> Service running --> onUnbind() --> onDestory()

onCreate()：

系统在Service第一次创建时执行此方法，来执行只运行一次的初始化工作，如果service已经运行，这个方法不会调用。

onStartCommand()：

每次客户端调用startService()方法启动该Service都会回调该方法(多次调用