为什么会选择MVP模式？
1、分离了视图逻辑和业务逻辑，降低了耦合 2、Presenter被抽象成接口，可以有业务实现和测试实现，方便单元测试 3、把业务逻辑放到Presenter，避免后台线程引用着Activity，导致Activity无法被系统回收，造成内存泄漏
Dragger2在MVP模式中的作用是什么？
MVP模式中，Activity依赖着P，P依赖着V。Dragger2起到了依赖注入的作用，使程序员不用显式地new对象。
介绍一下做过项目的架构？
基础的功能库包括网络请求Retrofit、图片缓存Glide； 业务模块分为论坛、购宠、上架宠物、个人信息； 每个模块都采用MVP模式，包括P接口、P实现类、View接口、View实现类、Activity/Fragment、Component、Module； 模块间使用EventBus或本地广播传递事件。
对组件化开发有什么理解？
组件化开发就是将一个app分成多个模块，每个模块都是一个组件（Module），开发的过程中我们可以让这些组件相互依赖或者单独调试部分组件等，但是最终发布的时候是将这些组件合并统一成一个apk。 假如一个app工程只有一个组件，随着app业务的壮大模块越来越多，稍微改动一个模块的一点代码都要编译整个工程，耗时耗力；公共资源、业务、模块混在一起耦合度太高；不方便测试。 架构上分为三层：基础功能库、各个业务模块、管理组件的空壳app。 组件化开发要求基础功能库、某个业务模块可以独立编程、测试、打包。 需要解决的问题： 1、每个组件的gradle文件需要在组件模式和集成模式下切换； gradle文件中加一个bool变量来控制。 2、组件间的页面跳转、API调用等需要解耦； Arouter 3、各个组件的Application需要在发布时集合成应用的Application； 在应用的Application的attachBaseContext()中创建一个代理，代理的作用是解析Menifest文件，创建组件的Application实例；然后在应用的Application的生命周期方法中调用组件的对应的方法。 4、资源命名冲突、lib库重复依赖问题。 程序员之间协调好。
