kotlin面试题集锦

1.kotlin 协程的概念

答：kotlin协程是一种轻量级的线程，它们并不是由操作系统直接管理的，而是在用户层面通过kotlin协程库来实现的。协程与线程的主要区别在于，协程是挂起和恢复的执行模型，而线程是抢占性的执行模型。这意味着协程可以在不阻塞线程的情况下实现异步编程，从而大大提高了程序的效率和响应性。

Android中的每个应用都会运行一个主线程，它主要用来处理UI，如果主线程上需要处理的任务太多，应用就感觉被卡住一样影响用户体验，得让那些耗时的任务不阻塞主线程的运行，要做到处理网络请求不会阻塞主线程，一个常用的做法是使用回调，另一种是使用协程。

官方解释：

协程通过将复杂性放入库来简化异步编程。程序的逻辑可以在协程中顺序地表达，而底层库会为我们解决其异步性，该库可以将用户代码的相关部分包装为回调、订阅相关事件、在不同线程（甚至不同机器）上调度执行，而代码则保持如同顺序执行一样简单。

协程就像是轻量级的线程，因为协程依赖于线程，一个线程中可以创建N个协程，很重要的一点就是协程挂起的时不会阻塞线程 ，几乎是无代价的。而且它基于线程池API，所以在处理并发任务这件事上它真的是游刃有余。

协程只是一种概念，它提供了一种避免阻塞线程并用更简单、更可控的操作替代线程阻塞的方法，协程挂起和恢复。本质上kotlin协程就是作为在kotlin语言上进行异步编程的解决方案，处理异步代码的方法。

协程可以使用阻塞的方式写出非阻塞式的代码，解决并发中常见的回调地狱。消除了并发任务之间的协作的难度，协程可以让我们轻松的写出复杂的并发代码。一些本来不可能实现的并发任务变得可能，甚至简单，这些才是协程的优势所在。

 

协程可以让异步代码同步化；

协程可以降低异步程序的设计复杂度。

 

2. koltin 协程底层实现原理是怎样的

答：在底层，kotlin的协程是通过生成状态机来实现的，当我们在协程中调用suspend函数时，协程会进入一个暂停状态，并保存其状态比便稍后恢复执行。当其他协程运行时，它们可能会改变协程的状态，例如修改其局部变量或更改其执行路径，当协程再次运行时，它将从前挂起的状态继续执行，并重复上述过程。

协程的另一个关键组成部分是协程调度器，协程调度器负责将协程分配到不同的线程上，以便它们可以并行运行，kotlin的协程框架提供了几种不同类型的调度器，例如IO调度器，默认调度器和无限制调度器等，开发者可以根据需要选择合适的调度器。

总之，在kotlin中，协程氏通过Coroutine框架实现的，它使用suspend函数和状态机来实现多个任务之间的切换，同时使用协程调度器将协程分配到不同的线程上，这种实现方式使得协程能够高效地处理异步编程，从而提高程序的可读性和可维护性。

 

3.什么是函数式编程（kotlin）

在kotlin中，支持函数作为一等公民，它支持高阶函数，lambda表达式，我们不仅可以把函数当做普通变量一样传递，返回，还可以把他分配给变量、放进数据结构或者进行一般性的操作。它们可以是未经命名的，也就是匿名函数，我们也可以直接把一段代码丢到{}中，这就是闭包。

 

4、kotlin空指针安全是怎么解决的？

答：非空类型的属性编译器添加@NotNull注解，可空类型添加@Nullable注解；

      非空类型直接对参数进行判空，如果为空直接抛出异常；

      可空类型，如果是?.判空，不空才执行后续代码，否则返回null；如果是!!，空的话直接抛出NPE异常。

      as操作符会判空，空的话直接抛出异常，不为空才执行后续操作，没做类型判断！运行时可能会报错！

      as?则是新建一个变量，参数赋值给它，然后判断是否为特定类型，赋值为null，接着把这个变量的值赋值给另一个新的变量，这里有一点注意：as?处理后的参数可能为空！！！所以调用as?转换后的对象还需要添加安全调用操作符(?.)

 

5、MVVM和其他架构的对比

MVC各字母的全称及含义：

Model：代表我们的数据模型，管理数据状态，比如Android项目中Java Bean。
View：视图，即呈现给用户的UI，比如Android项目中的layout.xml文件、Activity和Fragment。
Controller：控制者，负责处理用户与app之间的交互，包含业务逻辑。所以Controller是Model与View的中介，比如Android项目中Activity和Fragment。

MVC，Model View Controller，是软件架构中最常见的一种框架。简单来说就是通过controller的控制去操作model层的数据，并且返回给view层展示

当用户触发事件的时候，view层会发送指令到controller层，接着controller去通知model层更新数据，model层更新完数据以后直接显示在view层上，这就是MVC的工作原理。

MVC缺点：

View与Model之间还存在依赖关系，Controller很重很复杂。
由上面的MVC架构图可知，view层和model层是相互可知的，这意味着两层之间存在耦合，耦合对于一个大型程序来说是非常致命的，因为这表示开发，测试，维护都需要花大量的精力。
在Android中Activity即是View又是Controller，所以会很复杂。
xml作为view层，控制能力实在太弱了，你想去动态的改变一个页面的背景，或者动态的隐藏/显示一个按钮，这些都没办法在xml中做，只能把代码写在activity中，造成了activity既是controller层，又是view层的这样一个窘境。

MVP各字母的全称及含义：

Model：代表我们的数据模型，管理数据状态。
View：视图，即呈现给用户的UI，并且负责与客户进行交互。比如我们的XML/Activity/Fragment。
Presenter：主持者，Presenter通过View接收用户的输入，然后在Model的帮助下处理用户的数据并将结果传递回View。Presenter通过接口与View进行通信。接口在presenter类中定义，它传递所需的数据。Activity/Fragment 及其他View视图组件实现此接口获得他们想要的数据并呈现数据。

最明显的差别就是view层和model层不再相互可知，完全的解耦，取而代之的presenter层充当了桥梁的作用，用于操作view层发出的事件传递到presenter层中，presenter层去操作model层，并且将数据返回给view层，整个过程中view层和model层完全没有联系。看到这里大家可能会问，虽然view层和model层解耦了，但是view层和presenter层不是耦合在一起了吗？其实不是的，对于view层和presenter层的通信，我们是可以通过接口实现的，具体的意思就是说我们的activity，fragment可以去实现定义好的接口，而在对应的presenter中通过接口调用方法。不仅如此，我们还可以编写测试用的View，模拟用户的各种操作，从而实现对Presenter的测试。这就解决了MVC模式中测试，维护难的问题。

 

MVP的优缺点

优点：

将View与Model解耦，方便进行单元测试。
Presenter层可通过实现接口与View层通信从而避免Presenter层与View层耦合。
activity和fragment不再是controller层，而是纯粹的view层。
缺点：虽然是MVC模式的演变，但Presenter依旧很‘重’很复杂。

MVVM（Model View ViewModel）
MVVM各字母的全称及含义：

Model：代表我们的数据模型，管理数据状态。
View：视图，即呈现给用户的UI，并且负责与客户进行交互。比如我们的XML/Activity/Fragment。
ViewModel：如上图所示，ViewModel与Presenter的区别，在MVVM中，View引用持有ViewModel，但ViewModel得不到任何关于View的信息。所以View与ViewModel之间存在着一对多的关系，一个View可以持有多个ViewModel。

它和MVP的区别貌似不大，只不过是presenter层换成了viewmodel层，还有一点就是view层和viewmodel层是相互绑定的关系，这意味着当你更新viewmodel层的数据的时候，view层会相应的变动ui。

MVVM 模式在 Android 开发中通常与 Data Binding 和 LiveData 等 Jetpack 组件一起使用，以实现数据驱动的 UI 开发。

MVVM 框架的优势包括良好的代码分离、可测试性和可维护性。由于视图和视图模型之间的双向绑定，可以更容易地实现数据驱动的 UI 开发，同时还能够减少手动更新界面的代码量。此外，MVVM 框架还提供了更清晰的分层结构，使得代码更易于理解和维护。

MVVM与MVP区别
MVVM（Model-View-ViewModel）和MVP（Model-View-Presenter）之间的主要区别在于视图模型（ViewModel）与Presenter的角色和数据绑定机制。

角色命名：

在 MVP 中，Presenter 充当了视图（View）和模型（Model）之间的中间人，负责处理用户输入、更新视图和管理业务逻辑。
在 MVVM 中，Presenter 被改名为 ViewModel。ViewModel 与 Presenter 有着相似的职责，但它更加专注于为视图提供所需的数据和操作，而不直接操作视图。
数据绑定：

MVVM 模式引入了数据绑定机制，这是其与 MVP 的主要区别之一。数据绑定使得视图和视图模型之间的通信变得更加简单和直接。当视图中的数据变化时，自动地更新到视图模型中，反之亦然。这意味着开发者不需要手动编写代码来处理视图和视图模型之间的数据交换，框架会自动完成这些工作。
在 MVP 中，通常需要手动编写代码来处理视图和 Presenter 之间的数据交换，例如通过接口来更新视图并将用户输入传递给 Presenter 进行处理。
依赖关系：

在 MVP 中，视图（View）和 Presenter 是相互依赖的，视图持有对 Presenter 的引用，并且通过接口与 Presenter 进行交互。
在 MVVM 中，视图（View）和 ViewModel 之间的依赖性相对较低。通常，视图不直接持有对 ViewModel 的引用，而是通过数据绑定来实现视图与 ViewModel 的交互。
测试性：

由于 MVVM 中的视图模型（ViewModel）更加专注于数据和业务逻辑，而且与视图之间的耦合度较低，因此通常更易于进行单元测试。
在 MVP 中，Presenter 与视图之间的交互较多，视图和 Presenter 之间的耦合度较高，可能需要使用 Mock 对象等技术来进行测试。
总的来说，MVVM 和 MVP 在核心概念上非常相似，但在数据绑定机制和视图模型的角色定位上有所不同。MVVM 通过数据绑定机制简化了视图和视图模型之间的通信，使得开发更加高效，而 MVP 则更加注重视图和 Presenter 之间的交互。