2026 Android高级工程师面试题及详细答案

2026Android高级工程师面试题及详细答案说明：本套面试题贴合2026年Android开发行业趋势，聚焦原生开发、跨平台适配（Android/HarmonyOS双栈）、架构设计、性能优化等核心考点，题型涵盖单选、多选、简答、实战、源码分析，答案详细易懂，侧重实战落地，避免理论堆砌，完全贴合企业真实面试场景。一、单项选择题（10题，每题2分，共20分）下列关于Kotlin协程的说法，错误的是（）

A.协程是轻量级线程，由Kotlinruntime管理，而非操作系统

B.协程的挂起是非阻塞的，不会阻塞当前线程

C.协程的调度器Dispatchers.Main只能在主线程使用，用于更新UI

D.协程的cancel()方法可以强制终止所有状态下的协程

答案：D

解析：协程的cancel()方法只能终止处于挂起状态的协程，对于正在运行（非挂起）的协程，需要配合isActive判断或使用withContext(NonCancellable)才能正常终止；A、B、C说法均正确，Dispatchers.Main绑定主线程，专门用于UI更新操作。

关于JetpackCompose的重组机制，说法正确的是（）

A.只要Compose函数的参数发生变化，就一定会触发重组

B.derivedStateOf可以避免不必要的重组，用于将一个或多个状态转换为衍生状态

C.重组是全局刷新，会重新绘制整个Compose界面

D.rememberSaveable只能保存基本数据类型，无法保存自定义对象

答案：B

解析：A错误，Compose会智能判断参数变化是否影响UI，无关参数变化不会触发重组；C错误，重组是局部刷新，只刷新受状态变化影响的组件，而非全局；D错误，rememberSaveable可通过Parcelable实现自定义对象的保存；B正确，derivedStateOf的核心作用是防抖，避免因依赖状态频繁变化导致的无效重组。

Android中ANR的触发条件，不包括（）

A.主线程处理输入事件（点击、触摸）超过5秒未响应

B.前台BroadcastReceiver执行时间超过10秒

C.后台Service执行时间超过200秒

D.子线程执行耗时操作超过30秒

答案：D

解析：ANR仅由主线程阻塞触发，子线程耗时操作不会直接导致ANR，但会影响APP性能；A、B、C均为ANR的官方触发条件，前台Service执行超时阈值为20秒，后台为200秒。

关于Android内存优化，下列做法错误的是（）

A.使用WeakReference管理图片缓存，避免持有Activity强引用

B.避免在onDraw方法中创建对象，减少内存抖动

C.对于大量重复的字符串，使用Sern()复用常量池中的对象

D.静态变量持有Context时，优先使用ApplicationContext，避免持有ActivityContext

答案：C

解析：A、B、D均为正确的内存优化做法；C错误，Sern()会将字符串存入常量池，若大量使用，会导致常量池膨胀，反而增加内存占用，适合少量高频重复的字符串，不适合大量重复字符串场景。

下列关于Gradle构建优化的说法，错误的是（）

A.启用ConfigurationCache可以缓存构建配置，减少重复配置耗时

B.合理使用implementation和api，避免依赖传递冗余

C.开启R8混淆可以减小APK体积，但会增加构建时间

D.采用模块化构建，拆分独立Module，可实现并行构建

答案：C

解析：A、B、D均为正确的Gradle构建优化手段；C错误，R8混淆在减小APK体积的同时，会优化构建流程，相比ProGuard，构建时间更短，而非增加。

关于Room数据库的说法，正确的是（）

A.Room支持原生SQL语句，也支持注解式查询，无需手动编写SQL

B.Room的@Insert注解支持批量插入，但不返回插入后的ID

C.Room数据库操作必须在主线程执行，否则会抛出异常

D.Room不支持数据库迁移，修改表结构只能重新创建数据库

答案：A

解析：B错误，@Insert注解添加onConflict属性，且方法返回Long类型时，可返回插入后的ID（批量插入返回Long数组）；C错误，Room默认禁止主线程操作数据库，需配合协程、线程池或allowMainThreadQueries()（不推荐）；D错误，Room支持通过Migration类实现数据库迁移，避免数据丢失；A正确，Room是SQLite的封装，支持注解式查询和原生SQL。下列关于跨平台技术的对比，错误的是（）

A.KMP（KotlinMultiplatform）可实现一次编码，多端（Android、iOS、桌面）复用核心逻辑

B.Flutter采用自绘引擎，跨平台一致性优于ReactNative

C.ArkTS（HarmonyOS）的@Provide/@Consume与KMP的expect/actual作用一致，均用于状态同步

D.ReactNative基于WebView渲染，性能略低于Flutter和KMP

答案：C

解析：A、B、D说法均正确；C错误，@Provide/@Consume用于HarmonyOS内部组件间的状态传递，expect/actual用于KMP多端平台的接口适配，两者作用不同。

关于OkHttp的拦截链机制，说法正确的是（）

A.OkHttp的拦截链是线性执行的，顺序不可修改

B.拦截链的核心是Interceptor接口，分为应用拦截器和网络拦截器

C.应用拦截器只能拦截请求，无法拦截响应

D.网络拦截器会被重试和重定向机制跳过

答案：B

解析：A错误，拦截链的执行顺序可通过添加拦截器的顺序控制；C错误，应用拦截器既能拦截请求，也能拦截响应；D错误，网络拦截器会跟随重试和重定向机制，每次请求都会执行；B正确，OkHttp拦截链基于Interceptor接口，分为应用拦截器（面向开发者）和网络拦截器（面向网络请求）。

Android14及以上版本，关于应用权限的说法，错误的是（）

A.后台定位权限需要单独申请，且用户可选择“仅在使用期间允许”

B.通知权限默认关闭，需手动申请才能发送通知

C.读取媒体文件权限无需申请，可直接访问

D.危险权限申请时，系统会弹出权限弹窗，用户可选择“永久拒绝”

答案：C

解析：A、B、D均符合Android14及以上版本的权限机制；C错误，Android14中，读取媒体文件仍需申请READ_MEDIA_IMAGES、READ_MEDIA_VIDEO等权限，无法直接访问。

二、多项选择题（5题，每题3分，共15分，多选、少选、错选均不得分）下列属于JetpackCompose核心特性的有（）

A.声明式UI，通过状态驱动UI更新

B.可组合函数，组件化开发更灵活

C.与XML布局完全兼容，可混合使用

D.支持热重载，提升开发效率

答案：ABCD

解析：四个选项均为JetpackCompose的核心特性；声明式UI是其核心设计理念，可组合函数实现组件复用，支持与XML布局混合开发，热重载可实时查看代码修改效果，提升开发效率。

Android性能优化的核心方向包括（）

A.启动优化，减少APP启动时间

B.内存优化，避免内存泄漏和OOM

C.卡顿优化，保证UI流畅度（60fps）

D.电量优化，降低APP耗电量

答案：ABCD

解析：Android高级工程师核心需掌握的四大性能优化方向，分别对应启动、内存、卡顿、电量，此外还包括APK体积优化、网络优化等辅助方向。

关于Kotlin的特性，下列说法正确的有（）

A.空安全设计，通过?和!!控制空指针，避免空指针异常

B.扩展函数可以为任意类添加新方法，无需继承或修改原类

C.数据类（dataclass）自动生成equals()、hashCode()、toString()方法

D.密封类（sealedclass）用于限制继承，子类必须在同一文件中定义

答案：ABCD

解析：四个选项均为Kotlin的核心特性，空安全解决Java的空指针痛点，扩展函数提升代码灵活性，数据类减少模板代码，密封类增强代码可读性和安全性。

关于Android工程化实践，下列做法正确的有（）

A.采用组件化架构，拆分基础库、业务组件、壳工程

B.使用Git进行版本控制，采用GitFlow工作流

C.集成CI/CD工具（如Jenkins），实现自动构建、测试、打包

D.编写单元测试（JUnit、Espresso），提升代码质量

答案：ABCD

解析：四个选项均为企业级Android工程化的标准实践，组件化提升代码复用和维护性，Git版本控制保障团队协作，CI/CD提升交付效率，单元测试减少线上Bug。

三、简答题（8题，每题5分，共40分）请详细说明Handler机制的核心原理，以及如何避免Handler导致的内存泄漏？

答案：

1.核心原理：Handler机制是Android跨线程通信的核心，由Handler、Looper、MessageQueue、Message四部分组成，协同工作流程如下：

（1）Message：消息载体，存储需要传递的数据和任务，可通过obtain()方法复用消息池，减少内存浪费；

（2）MessageQueue：消息队列，采用先进先出（FIFO）顺序管理Message，每个线程最多只有一个MessageQueue，负责接收Handler发送的消息并等待提取；

（3）Looper：消息循环器，每个线程最多只有一个Looper，通过prepare()方法初始化，loop()方法启动无限循环，不断从MessageQueue中提取Message，若队列无消息则阻塞，有消息则分发到对应Handler；

（4）Handler：消息处理器，负责发送Message（sendMessage()、post()等方法）和处理Message（重写handleMessage()方法），发送消息时会将自身作为target存入Message，Looper提取消息后，通过target将消息分发到对应Handler。

补充：主线程默认初始化Looper（ActivityThread的main()方法中），子线程默认无Looper，需手动调用Looper.prepare()和Looper.loop()。

2.内存泄漏原因及解决方案：

（1）泄漏原因：非静态内部类/匿名内部类的Handler会隐式持有外部Activity/Fragment引用，若MessageQueue中存在未处理的Message，Message会持有Handler引用，进而导致Activity/Fragment无法被GC回收，引发内存泄漏；

（2）解决方案（实战常用2种）：

①采用静态内部类+WeakReference：将Handler定义为静态内部类，通过WeakReference包装外部Activity/Fragment，避免强引用，同时在handleMessage()中判断引用是否有效；

②页面销毁时清空消息：在Activity的onDestroy()方法中，调用handler.removeCallbacksAndMessages(null)，清空MessageQueue中所有未处理的消息和回调，切断引用链。

请说明Android启动优化的核心思路和具体实现方案（至少3种）？

答案：

核心思路：Android启动分为冷启动、温启动、热启动，优化重点是冷启动（从无到有启动APP），核心是“减少主线程阻塞时间”“延迟非必要任务”“优化初始化流程”，最终降低启动耗时，提升用户体验。

具体实现方案（实战落地）：

1.优化Application初始化：

-拆分初始化任务，将非必要的第三方SDK（如统计、推送）延迟初始化（通过Handler.postDelayed()或协程延迟），仅保留必要的初始化（如网络、权限）；

-避免在Application的onCreate()方法中执行耗时操作（如文件IO、网络请求），将耗时操作移到子线程。

2.优化布局加载：

-简化启动页布局，避免嵌套过深（建议嵌套不超过3层），使用ConstraintLayout替代LinearLayout，减少布局解析时间；

-采用ViewStub延迟加载非启动页必需的布局（如广告、引导页），启动完成后再加载。

3.优化代码执行：

-启用R8混淆和代码压缩，移除无用代码和资源，减少类加载时间；

-采用懒加载模式，避免启动时初始化所有组件，仅初始化当前必需的组件。

4.其他优化：

-优化资源加载，使用WebP格式图片替代PNG/JPG，减少资源加载耗时；

-采用启动器模式（如ARouter启动器），统一管理初始化任务，实现任务并行执行，提升初始化效率。

请对比ViewModel和LiveData，说明两者的作用、区别，以及在MVVM架构中的使用场景？

答案：

1.两者作用：

-ViewModel：用于存储和管理与UI相关的数据，生命周期与Activity/Fragment的生命周期绑定（不受屏幕旋转等配置变化影响），避免配置变化时数据丢失，同时隔离UI层和数据层，承担业务逻辑处理。

-LiveData：可观察的数据持有者，具有生命周期感知能力，能自动感知Activity/Fragment的生命周期状态，在页面处于活跃状态（STARTED、RESUMED）时通知UI更新，页面销毁时自动移除观察者，避免内存泄漏。

2.核心区别：

-职责不同：ViewModel负责数据存储和业务逻辑，LiveData负责数据观察和UI通知，是ViewModel和UI层之间的桥梁；

-生命周期感知：ViewModel不具备生命周期感知能力，仅能感知Activity/Fragment的创建和销毁（配置变化时不销毁）；LiveData具备生命周期感知能力，能根据页面状态决定是否通知UI；

-数据传递：ViewModel可存储任意类型数据，LiveData仅能存储可观察的数据，且只能通过observe()方法订阅数据变化。

3.MVVM架构中的使用场景：

-ViewModel：每个Activity/Fragment对应一个ViewModel（或共享ViewModel），在ViewModel中定义LiveData对象，处理网络请求、数据库操作等业务逻辑，将结果存入LiveData；

-LiveData：在ViewModel中暴露LiveData对象，UI层（Activity/Fragment）通过observe()方法订阅LiveData，当数据发生变化时，LiveData自动通知UI更新，无需手动调用刷新方法；

补充：2026年实战中，常用StateFlow替代LiveData，StateFlow支持协程，更适合与Compose配合使用，但其核心作用与LiveData一致，均用于数据观察和UI通知。

请说明Kotlin协程的调度器类型，以及不同调度器的使用场景？

答案：

Kotlin协程的调度器（Dispatcher）负责决定协程在哪个线程上执行，核心调度器类型有4种，结合2026年实战场景说明如下：

1.Dispatchers.Main：

-作用：绑定Android主线程，用于执行UI相关操作（如更新TextView、跳转页面）；

-使用场景：协程中需要更新UI时，切换到该调度器，例如网络请求成功后更新UI。

2.Dispatchers.IO：

-作用：用于执行IO密集型任务，底层维护一个线程池，自动复用线程，避免频繁创建线程；

-使用场景：网络请求（如Retrofit请求）、文件IO（读写文件）、数据库操作（Room）等耗时操作。

3.Dispatchers.Default：

-作用：用于执行CPU密集型任务，底层是一个共享的线程池，线程数量等于CPU核心数；

-使用场景：数据计算（如排序、解析大型JSON）、复杂算法运算等需要大量CPU资源的操作。

4.Dispatchers.Unconfined：

-作用：不指定固定线程，协程会在当前调用的线程上执行，挂起后恢复时，会在执行挂起操作的线程上继续执行；

-使用场景：很少使用，仅适用于不依赖特定线程的简单任务，避免用于UI操作和耗时操作。

补充：实战中常用withContext()方法切换调度器，例如：withContext(Dispatchers.IO){执行网络请求}，切换到IO线程执行耗时操作，执行完成后自动切回原调度器。

请说明APK体积优化的核心方法（至少4种），并说明每种方法的具体实现？

答案：

APK体积优化的核心是“减少无用资源”“压缩资源”“优化代码”，具体方法及实现如下（实战常用）：

1.资源优化：

-实现：删除无用资源（使用AndroidStudio的Refactor→RemoveUnusedResources），避免资源冗余；统一资源格式，图片使用WebP格式（比PNG小30%左右），图标使用VectorDrawable（矢量图，不占体积）；

-补充：通过resConfigs配置，只保留需要的语言资源（如仅保留zh-rCN、en），删除其他语言资源。

2.代码优化：

-实现：启用R8混淆和代码压缩（在build.gradle中开启minifyEnabledtrue、shrinkResourcestrue），移除无用代码和类；采用ProGuard规则，保留必要的代码（如反射相关代码），避免混淆出错；

-补充：使用ProGuard的-dontshrink、-keep等规则，优化混淆效果，进一步减小代码体积。

3.依赖优化：

-实现：排查并移除无用的依赖库，避免依赖冗余；对于大型依赖库（如Glide、Retrofit），使用按需引入（如Glide仅引入核心模块）；优先使用轻量级依赖库替代重量级库（如用Coil替代Glide，体积更小）。

4.资源压缩：

-实现：使用AndResGuard工具对资源进行加密和压缩，混淆资源文件名，减少APK体积；对图片进行压缩（如使用TinyPNG工具），在不影响视觉效果的前提下，减小图片大小。

5.其他优化：

-实现：采用插件化/组件化架构，将非核心功能（如广告、插件）做成插件，按需下载，不打包进主APK；删除assets目录下的无用文件（如测试资源、冗余配置文件）。

请说明OkHttp的拦截链原理，以及如何自定义一个拦截器（举例说明）？

答案：

1.拦截链原理：

OkHttp的拦截链是其核心设计，采用责任链模式，将网络请求的各个环节（如请求拦截、缓存处理、网络连接、响应处理）拆分为多个拦截器，每个拦截器负责一个具体的功能，请求和响应会依次经过所有拦截器，流程如下：

（1）用户发起网络请求（call.execute()或call.enqueue()）；

（2）OkHttp创建一个拦截链（RealCall.getResponseWithInterceptorChain()），将所有拦截器（应用拦截器、网络拦截器、内置拦截器）组成一个列表；

（3）请求从第一个拦截器开始，依次经过每个拦截器的intercept()方法，每个拦截器可以修改请求参数（如添加请求头、设置超时）；

（4）请求经过所有拦截器后，到达网络层，执行实际的网络请求，获取响应；

（5）响应从最后一个拦截器开始，反向经过所有拦截器，每个拦截器可以修改响应（如解析响应、处理缓存）；

（6）最终响应返回给用户。

补充：拦截器分为应用拦截器（添加在OkHttpClient.Builder.addInterceptor()）和网络拦截器（添加在OkHttpClient.Builder.addNetworkInterceptor()），应用拦截器只执行一次，网络拦截器会跟随重试和重定向执行多次。

2.自定义拦截器（实战示例：添加全局请求头）：

```kotlin

//自定义拦截器，添加全局Token请求头

classTokenInterceptor:Interceptor{

overridefunintercept(chain:Interceptor.Chain):Response{

//1.获取原始请求

valoriginalRequest=chain.request()

//2.构建新的请求，添加Token请求头

valnewRequest=originalRequest.newBuilder()

.addHeader("Token","user_token_123456")

.addHeader("Content-Type","application/json")

.build()

//3.执行下一个拦截器，返回响应

returnceed(newRequest)

}

}

//配置OkHttpClient，添加自定义拦截器

valokHttpClient=OkHttpClient.Builder()

.addInterceptor(TokenInterceptor())//添加应用拦截器

.connectTimeout(10,TimeUnit.SECONDS)

.readTimeout(10,TimeUnit.SECONDS)

.build()

```

说明：该拦截器会为所有网络请求添加Token和Content-Type请求头，无需在每个请求中单独添加，提升代码复用性。请说明Android14的核心新特性，以及开发中需要注意的兼容性问题？

答案：

1.Android14核心新特性（实战相关）：

（1）权限优化：新增后台定位权限（ACCESS_BACKGROUND_LOCATION），需单独申请；通知权限默认关闭，需手动申请才能发送通知；危险权限申请时，用户可选择“永久拒绝”，拒绝后无法再次申请。

（2）UI相关：支持动态颜色主题，可根据系统主题或壁纸自动调整APP颜色；新增MaterialYou3.0设计规范，优化组件样式；支持折叠屏多窗口适配，新增折叠屏相关API。

（3）性能优化：优化应用启动速度，减少冷启动耗时；增强内存管理，对后台应用的内存限制更严格，避免内存泄漏导致的系统卡顿。

（4）开发效率：支持Kotlin1.9+，优化协程性能；AndroidStudioHedgehog适配Android14，提供更便捷的调试工具。

（5）安全优化：强化应用签名验证，禁止安装未签名或签名异常的应用；限制动态加载.so文件，提升应用安全性。

2.开发中需注意的兼容性问题：

（1）权限兼容性：针对Android14及以上版本，需单独申请后台定位、通知权限，适配权限申请弹窗的新样式；避免使用已废弃的权限（如WRITE_EXTERNAL_STORAGE），改用媒体文件权限。

（2）API兼容性：Android14废弃了部分旧API（如Activity的onCreateOptionsMenu()的部分重载方法），需替换为新API；使用新API时，需通过Build.VERSION.SDK_INT判断系统版本，避免低版本系统崩溃。

（3）UI兼容性：适配动态颜色主题，避免固定颜色导致的UI异常；适配折叠屏多窗口，确保APP在折叠、展开状态下均能正常显示，避免布局错乱。

（4）安全兼容性：确保APP签名合法，避免使用动态加载.so文件的方式，若必须使用，需适配Android14的安全限制；避免使用反射调用系统API，防止被系统拦截。

四、实战应用题（2题，每题10分，共20分）实战场景：某APP启动时出现卡顿，启动时间超过3秒，且偶尔出现ANR异常，请分析可能的原因，并给出具体的优化方案（需结合实战，可落地）。

答案：

1.卡顿及ANR异常的可能原因（实战排查重点）：

（1）主线程阻塞：Application的onCreate()方法中执行了耗时操作（如网络请求、文件IO、数据库初始化、第三方SDK初始化），导致主线程无法响应输入事件，触发ANR；

（2）布局加载耗时：启动页布局嵌套过深、控件过多，或加载了大型图片、动画，导致布局解析和绘制时间过长，引发卡顿；

（3）初始化任务过多：启动时初始化了大量非必要的组件和SDK，导致启动流程冗长，主线程负担过重；

（4）内存不足：APP启动时加载大量资源，导致内存占用过高，系统频繁GC，引发卡顿；

（5）主线程同步锁竞争：多个线程同时竞争主线程的同步锁，导致主线程阻塞，无法正常执行任务。

2.具体优化方案（可落地，分步骤实施）：

（1）优化主线程执行，解决ANR：

-排查Application的onCreate()方法，将所有耗时操作（如网络请求、文件IO）移到子线程或协程（Dispatchers.IO）中执行，避免阻塞主线程；

-拆分第三方SDK初始化，将非必要的SDK（如统计、推送、广告）延迟初始化，仅保留核心SDK（如网络、权限）在启动时初始化，延迟时间设置为启动完成后1-2秒；

-使用StrictMode检测主线程耗时操作，在开发阶段定位主线程阻塞问题，代码示例：

```kotlin

//在Application的onCreate()中添加

if(BuildConfig.DEBUG){

StrictMode.setThreadPolicy(

StrictMode.ThreadPolicy.Builder()

.detectDiskReads()

.detectDiskWrites()

.detectNetwork()

.penaltyLog()

.build()

)

}

```

（2）优化布局加载，解决卡顿：

-简化启动页布局，将布局嵌套层数控制在3层以内，使用ConstraintLayout替代LinearLayout，减少布局解析时间；

-优化启动页图片，将图片转换为WebP格式，压缩图片大小，避免加载大型图片；使用ViewStub延迟加载非必要的控件（如广告、引导页），启动完成后再加载；

-禁用启动页的过度动画，或简化动画效果，减少UI绘制耗时。

（3）优化内存使用：

-启动时仅加载必要的资源，避免加载大量图片、音频等资源，非必要资源延迟加载；

-检查启动流程中的内存泄漏（如静态变量持有Context），使用WeakReference管理引用，避免内存占用过高；

-启用内存优化工具（如LeakCanary），排查启动过程中的内存泄漏问题。

（4）其他优化：

-采用启动器模式，统一管理初始化任务，实现任务并行执行（如多个SDK初始化并行），减少启动时间；

-优化代码执行，启用R8混淆和代码压缩，移除无用代码，减少类加载时间；

-排查主线程同步锁竞争，避免在主线程中使用synchronized关键字，若必须使用，尽量减小锁粒度。

3.优化验证：

-使用AndroidStudio的Profile工具，监控启动时间、主线程阻塞情况、内存占用，验证优化效果；

-进行多机型测试（尤其是中低端机型），确保优化后启动时间控制在2秒以内，无ANR异常。

实战场景：某APP采用MVVM架构，使用Kotlin协程+Retrofit进行网络请求，在列表页加载数据时，出现数据加载缓慢、列表滑动卡顿、偶尔出现空指针异常，请分析问题原因，并给出具体的解决方案（需结合代码示例）。

答案：

1.问题原因分析：

（1）数据加载缓慢：网络请求未做缓存处理，每次进入列表页都重新请求网络；请求参数未优化（如未做分页），一次性加载大量数据，导致请求耗时过长；

（2）列表滑动卡顿：在列表Item的onBindViewHolder()方法中执行了耗时操作（如图片加载、数据解析）；RecyclerView未做优化（如未设置复用池、未使用DiffUtil）；图片加载未做缓存和压缩，导致滑动时频繁GC；

（3）空指针异常：协程未做异常处理，网络请求失败时未捕获异常，导致数据为空时直接操作；ViewModel中的LiveData未做非空判断，UI层直接使用；Retrofit请求返回数据解析异常，导致数据为空。

2.具体解决方案（结合代码示例，可落地）：

（1）优化网络请求，解决数据加载缓慢：

①添加网络缓存（使用OkHttp拦截器实现）：

```kotlin

//自定义缓存拦截器

classCacheInterceptor:Interceptor{

overridefunintercept(chain:Interceptor.Chain):Response{

valrequest=chain.request()

//无网络时使用缓存，有网络时缓存有效期1分钟

valcacheControl=if(NetworkUtil.isNetworkAvailable()){

CacheControl.Builder().maxAge(1,TimeUnit.MINUTES).build()

}else{

CacheControl.Builder().onlyIfCached().maxStale(7,TimeUnit.DAYS).build()

}

valnewRequest=request.newBuilder().cacheControl(cacheControl).build()

valresponse=ceed(newRequest)

returnresponse.newBuilder().cacheControl(cacheControl).build()

}

}

//配置OkHttpClient，添加缓存

valokHttpClient=OkHttpClient.Builder()

.addInterceptor(CacheInterceptor())

.cache(Cache(File(context.cacheDir,"http_cache"),10*1024*1024))//10MB缓存

.build()

```

②实现分页加载，避免一次性加载大量数据：

-Retrofit接口添加分页参数（page、pageSize），每次加载10-20条数据；

-列表滑动到底部时，触发下一页请求，使用LoadMore机制，避免一次性加载过多数据。

（2）优化RecyclerView，解决滑动卡顿：

①优化RecyclerView配置：

```kotlin

//列表初始化时配置

recyclerView.apply{

layoutManager=LinearLayoutManager(context)

adapter=MyAdapter()

//设置复用池，提升复用效率

setRecycledViewPool(RecyclerView.RecycledViewPool())

//关闭过度滚动效果

overScrollMode=RecyclerView.OVER_SCROLL_NEVER

//设置固定大小，避免每次滑动重新计算布局

setHasFixedSize(true)

}

```

②优化Item布局和绑定：

-简化Item布局，避免嵌套过深；

-在onBindViewHolder()中避免创建对象，将对象初始化移到ViewHolder构造方法中；

-使用DiffUtil更新列表数据，避免全量刷新，代码示例：

```kotlin

//自定义DiffUtil.Callback

classMyDiffCallback:DiffUtil.Callback(){

overridefungetOldListSize()=oldList.size

overridefungetNewListSize()=newList.size

overridefunareItemsTheSame(oldItemPosition:Int,newItemPosition:Int):Boolean{

returnoldList[oldItemPosition].id==newList[newItemPosition].id

}

overridefunareContentsTheSame(oldItemPosition:Int,newItemPosition:Int):Boolean{

returnoldList[oldItemPosition]==newList[newItemPosition]

}

}

//更新列表数据

valdiffResult=DiffUtil.calculateDiff(MyDiffCallback())

diffResult.dispatchUpdatesTo(adapter)

```

③优化图片加载（使用Coil）：

```kotlin

//图片加载时设置占位图、错误图，压缩图片

imageView.load(item.imageUrl){

placeholder(R.drawable.placeholder)

error(R.drawable.error)

size(200.dp,200.dp)//压缩图片尺寸

memoryCachePolicy(CachePolicy.ENABLED)//启用内存缓存

diskCachePolicy(CachePolicy.ENABLED)//启用磁盘缓存

}

```

（3）处理异常，解决空指针问题：

①协程异常处理（使用try-catch，或CoroutineExceptionHandler）：

```kotlin

//ViewModel中处理网络请求

funloadData(page:Int){

viewModelScope.launch(Dispatchers.IO+coroutineExceptionHandler){

try{

valresponse=apiService.getData(page,10)

if(response.isSuccessful&&response.body()!=null){

_dataList.postValue(response.body()?.data)

}else{

_errorMsg.postValue("数据加载失败")

}

}catch(e:Exception){

_errorMsg.postValue("网络异常，请重试")

e.printStackTrace()

}

}

}

//全局协程异常处理器

privatevalcoroutineExceptionHandler=CoroutineExceptionHandler{_,throwable->

_errorMsg.postValue("请求异常：${throwable.message}")

}

```

②LiveData非空判断，UI层安全使用：

```kotlin

//UI层观察LiveData

viewModel.dataList.observe(this){dataList->

dataList?.let{

adapter.submitList(it)

}?:run{

//数据为空时的处理

Toast.makeText(context,"暂无数据",Toast.LENGTH_SHORT).show()

}

}

```

③Retrofit数据解析优化：

-确保接口返回数据格式一致，使用Gson解析时，对可空字段添加?，避免解析异常；

-对返回数据进行判空处理，避免空指针。

五、源码分析题（1题，5分）请分析Kotlin协程中launch和async的区别，结合源码核心逻辑说明两者的使用场景差异？

答案：

1.核心区别（结合源码逻辑）：

（1）返回值不同：

-launch：返回Job对象，不返回协程执行结果，源码中launch的返回值是JobImpl（Job的实现类），仅用于控制协程的生命周期（如cancel()、join()）；

-async：返回Deferred对象（继承自Job），源码中async的返回值是DeferredImpl，可通过await()方法获取协程执行结果，await()方法会阻塞当前协程，直到获取结果。

（2）异常处理不同：

-launch：协程内部抛出的异常，若未通过CoroutineExceptionHandler捕获，会直接崩溃（除非在协程内部try-catch）；

-async：协程内部抛出的异常，不会直接崩溃，会在调用await()方法时抛出，需通过try-catch捕获异常。

（3）源码核心逻辑差异：

-launch源码：调用launch()方法时，会创建一个CoroutineDispatcher，将协程任务提交到调度器，返回Job对象，任务执行完成后，Job状态变为Completed，不返回任何结果；

-async源码：调用async()方法时，会创建一个Deferred对象，协程任务执行完成后，会将结果存入Deferred的result属性，调用await()方法时，会判断协程是否执行完成，若未完成则阻塞，完成则返回result。

2.使用场景差异（实战落地）：

-launch：适用于不需要获取执行结果的场景，如执行UI更新、发送通知、启动后台任务等，例如：

```kotlin

//启动协程更新UI，无需返回结果

viewModelScope.launch(Dispatchers.Main){

textView.text="数据加载完成"

}

```

-async：适用于需要获取执行结果的场景，如网络请求、数据计算等，多个async可并行执行，通过await()获取各自结果，例如：

```kotlin

//并行执行两个网络请求，获取结果后合并处理

viewModelScope.launch(Dispatchers.IO){

valdeferred1=async{apiService.getData1()}

valdeferred2=async{apiService.getData2()}

valdata1=deferred1.await()//阻塞等待结果

valdata2=deferred2.await()

//合并处理数据

valcombinedData=combineData(data1,data2)

_combinedData.postValue(combinedData)

}

```

补充：async若不调用await()方法，协程会正常执行，但异常不会被捕获，可能导致隐藏问题，因此使用async时，务必调用await()并处理异常。

六、附加题（10分，可选）请说明Android/HarmonyOS双栈开发的核心要点，以及如何将一个Android原生APP（Kotlin+Compose）适配到HarmonyOSNEXT，需结合实际开发场景说明适配步骤。

答案：

1.双栈开发核心要点：