面试题总结并附上答案3

Android应用程序内部启动Activity过程（startActivity）

应用程序的MainActivity通过Binder进程间通信机制通知ActivityManagerService，它要启动一个新的Activity；
ActivityManagerService通过Binder进程间通信机制通知MainActivity进入Paused状态；
MainActivity通过Binder进程间通信机制通知ActivityManagerService，它已经准备就绪进入Paused状态，于是ActivityManagerService就准备要在MainActivity所在的进程和任务中启动新的Activity了；
ActivityManagerService通过Binder进程间通信机制通知MainActivity所在的ActivityThread，现在一切准备就绪，它可以真正执行Activity的启动操作了。

和Android应用程序启动过程源代码分析中启动应用程序的默认Activity相比，这里在应用程序内部启动新的Activity的过程少了中间创建新的进程这一步，这是因为新的Activity是在已有的进程和任务中执行的，无须创建新的进程和任务。

自定义View Measure 中的参数

对象的几种引用方式，软引用在Java中做缓存

android开发四种引用的详解

插件化，热修复

Dalvik和ART 区别的原理

Android中的Dalvik和ART详解及区别分析

RecyclerView ListView的区别，缓存机制是啥

组件怎么封装，怎么调用

(结合自己项目经验说说)

性能优化的工具，经验

性能优化

MVVM中大dataBinding 是怎么实现双向绑定

DataBinding实现原理探析

Android DataBinding原理解析

DataBinding做了些什么事

DataBinding主要做了两件事：

1.取代烦琐的findviewbyid，自动在binding中生成对应的view
2.绑定VM层和V层的监听关系，使得VM和V层的交互更简单这里的交互是指两个方向的交互，一是VM通知V层作改变，比如setText,setColor，二是V层通知VM作改变，比如click事件，edittext的输入

总结

1.DataBindingUtil.setContentView方法将xml中的各个View赋值给ViewDataBinding，完成findviewbyid的任务
2.ViewDataBinding的setVariable方法建立了ViewDataBinding与VM之间的联系，也就搭建了一个可以互相通信的桥梁
3.当VM层调用notifyPropertyChanged方法时，最终在ViewDataBinding的executeBindings方法中处理逻辑

总结MVVM：

1）低耦合。视图（View）可以独立于Model变化和修改，一个ViewModel可以绑定到不同的”View”上，当View变化的时候Model可以不变，当Model变化的时候View也可以不变。
2）可重用性。你可以把一些视图逻辑放在一个ViewModel里面，让很多view重用这段视图逻辑。
3）独立开发。开发人员可以专注于业务逻辑和数据的开发（ViewModel），设计人员可以专注于页面设计，使用Expression Blend可以很容易设计界面并生成xaml代码。
4）可测试。界面素来是比较难于测试的，而现在测试可以针对ViewModel来写。由上面各个架构的讨论，我们可以得到以下的结果：

4、总结三种架构：

MVC 架构适合于大型系统，它可以分层且可以在实体层面切割为不同的机器或服务，只要彼此间具有适当的通讯协定即可。 MVVM 架构适合像XAML 这种与程式码无关(code ignorance) 的使用者介面设计，只要View 中下特定的指令与ViewModel 串接，就可以享有ViewModel 沟通的功能，而ViewModel 只需做一些特别的介面实作，即可平顺的和View 沟通。 MVP 架构适合集中由程式码决定View 动作的应用程式，而View 只需要实作特定的介面即可，不需要太复杂的工作，但Presenter 则可能会受限于View 介面的动作，而无法做更进一步对View 的控制。

5、小结

在Android开发中原有的MVC（Activity+layout）模式越来越不适用，首先，视图逻辑和业务逻辑不分，导致代码容易出问题、难以可持续性维护；其次，由于业务逻辑混在视图逻辑里面，视图基本无法复用，layout本身是代码文件，但是又不像java代码那样可维护，灵活，可以有逻辑，所以很少复用layout文件，有经验的Android程序员会尽可能避免复用Layout文件特别是复用别人写的layout文件。所以出于视图复用的目的原有的MVC也不适用，MVVM成了一种必要的选择。

1. MVC 架构适合于大型系统，它可以分层且可以在实体层面切割为不同的机器或服务，只要彼此间具有适当的通讯协定即可。
1. MVVM 架构适合像XAML 这种与程式码无关(code ignorance) 的使用者介面设计，只要View 中下特定的指令与ViewModel 串接，就可以享有ViewModel 沟通的功能，而ViewModel 只需做一些特别的介面实作，即可平顺的和View 沟通。
1. MVP 架构适合集中由程式码决定View 动作的应用程式，而View 只需要实作特定的介面即可，不需要太复杂的工作，但Presenter 则可能会受限于View 介面的动作，而无法做更进一步对View 的控制。

EventBus作用，实现方式，代替EventBus的方式

EventBus 源码解析

EventBus的机制是什么？和Handler的区别怎样？

EventBus是采用观察者模式实现的事件订阅总线，可以用在应用程序中，组件之间，线程之间的通信，并且由于事件可以是任意类型的对象，所以使用起来更加的方便快捷。
EventBus 是一个 Android 事件发布/订阅框架，通过解耦发布者和订阅者简化 Android 事件传递，这里的事件可以理解为消息，本文中统一称为事件。事件传递既可用于 Android 四大组件间通讯，也可以用户异步线程和主线程间通讯等等。
传统的事件传递方式包括：Handler、BroadCastReceiver、Interface 回调，相比之下 EventBus 的优点是代码简洁，使用简单，并将事件发布和订阅充分解耦。
Handler是 Android 的消息机制，集中解决线程间通信问题。

RxBus、EventBus 对比：

1.从引入依赖包对比

RxBus 需要引入两个包，EventBus需要引入一个，如果项目中没有使用到RxJava编程的话，并不能减少包的依赖。

2 .从开发难度上对比

上面也提到了实现RxBus是基于RxJava的，作为一个新的编程方式函数式编程，对开发者的要求多多少少提高了那么一点，而且每一个订阅都需要返回一个Observable，由订阅者写具体的代码需要执行在哪个线程中，而EventBus 最新版本采用注解预编译的方式，订阅者注册解注册只需调用一个函数，而且通过注解的方式可以标明事件的优先级，接收事件运行在哪个线程，并且能够实现粘性事件，这些RxBus都需要进行二次开发。

3.）从开发效率上对比

RxBus 需要进行大量的二次开发，否则只能实现简单的事件传递，而EventBus只需简单了解一下API就能上手。如果一个订阅者需要注册多个事件的时候，需要多个Observable全局变量，这不是疯掉了吗，而EventBus已经实现了一个订阅者订阅多个事件，和一个事件对应多个订阅者。

4.）从功能完善上对比

上面三个对比也说明了，EventBus实现了事件的优先级，订阅事件运行的线程场景，以及粘性事件，这些在RxBus上面都需要进行二次实现。

总结：

基于RxJava实现简单的事件总线管理是可以的，但是个人觉得想要取代EventBus难免有点说过头了。所以如果项目中没有使用RxJava的话还是采用EventBus比较靠谱。

EventBus 带来的好处和引入的问题

好处比较明显，就是独立出一个发布订阅模块，调用者可以通过使用这个模块，屏蔽一些线程切换问题，简单地实现发布订阅功能。

坏处可能比较隐晦，但这些需要足够引起我们的重视

大量的滥用，将导致逻辑的分散，出现问题后很难定位。
没办法实现强类型，在编译的时候就发现问题，（Otto实现了这个，但性能有问题）。在实现上通过一个很弱的协议，比如onEvent{XXX}, {XXX}表示ThreadModel，来实现线程的切换。后面在代码解析的时候，会说明这个问题。
代码可读性有些问题，IDE无法识别这些协议，对IDE不友好。

总得来说，如果项目里面有大量的事件交互，那么还是可以通过EventBus来实现，否则还是推荐自己在模块内部实现观察者模式

面试题总结并附上答案3