简介这份Android移动平台开发源码融合Java与Kotlin两种语言面向正在学习Android开发的学生、刚入门移动开发的初级工程师以及希望研究混合编程实践的开发者。项目涵盖Activity生命周期管理、自定义View绘制、ListView列表适配、SQLite数据库操作与手势密码等典型功能模块既有传统Java实现也有Kotlin简洁写法适合对照学习两种语言的差异与互补。压缩包共93个文件以XML布局配置、Kotlin/Java源文件为主另含PNG/JPG界面素材、Markdown文档和Idea工程配置整体大小1.68MB结构清晰便于按模块查阅。目前已有479人学习下载。通过这些源码读者可快速搭建Android项目骨架理解从界面布局到业务逻辑的完整链路尤其能借鉴自定义视图如TitleLayout的实现思路以及Java与Kotlin共存时的工程组织方式是一份兼具教学与实战参考价值的移动开发资源。1. 先说明白Java和Kotlin双语言源码项目到底在解决什么问题某开发者接手了一个维护了两年的老项目代码库九成是 Java但新来的同事坚持用 Kotlin 写新功能。两个人吵了一周最后各写各的——Java 文件放在java/目录Kotlin 文件放在kotlin/目录编译居然也过了。但这个能编译的混编项目上线前连续出了三轮问题Kotlin 侧调用 Java 的getXXX()方法时莫名空指针、Java 侧拿不到 Kotlin 的默认参数、协程回调把主线程卡死。这个标题说的基于Java和Kotlin的Android移动平台开发源码本质上就是一套让两种语言在同一个 Android 工程里稳定共存的工程实践。它要解决的不是哪个语言更好而是源码怎么组织、编译怎么配置、两者之间怎么互调、从 Java 往 Kotlin 迁移怎么动代码最安全。这篇文章写给两类人——正在把老项目从 Java 迁向 Kotlin 的维护者以及新项目里打算混合使用两种语言的团队。2. 双语言共存的工程基础项目结构、Gradle 配置与混编机制2.1 为什么一个项目能同时存在 Java 和 Kotlin混编的前提与收益Kotlin 在设计时就没有把 Java 当成对手而是当成了要共存的邻居。Kotlin 编译成 JVM 字节码运行在同一个 ART 虚拟机上和 Java 字节码在运行时没有任何区别。这意味着在 Android 工程里Java 和 Kotlin 两种语言写出来的类可以互相引用、互相继承、互相实现对方定义的接口只要编译期能看到对方的源码或二进制依赖。混编的收益不在于炫技而在于迁移风险的可控。一个十万行的老项目没人敢在一个周末里全部改成 Kotlin。常见的做法是把新功能用 Kotlin 写老功能继续留在 Java两边通过接口边界通信——这样每一步改动都有明确的验证范围。另一个收益是团队效率新人用 Kotlin 写业务代码确实能少写很多样板而资深同事维护老模块时不用被迫重写。但混编的前提是工程配置要一次做对。Android Gradle Plugin 从 7.0 开始内置 Kotlin 支持kotlin-android插件和com.android.application插件只要同时挂在模块上编译时就会自动把src/main/kotlin和src/main/java两个目录都纳入源码集。真正容易踩坑的是插件版本和编译选项的匹配。2.2 最小 Gradle 配置让 Java 和 Kotlin 在同一个模块里编译一个双语言 Android 模块的build.gradleKotlin DSL 写法最简配置如下plugins { id(com.android.application) id(kotlin-android) id(kotlin-kapt) // 如果用到注解处理器比如 Room 或 Glide } android { namespace com.example.hybrid compileSdk 34 defaultConfig { applicationId com.example.hybrid minSdk 24 targetSdk 34 versionCode 1 versionName 1.0 } compileOptions { sourceCompatibility JavaVersion.VERSION_17 targetCompatibility JavaVersion.VERSION_17 } kotlinOptions { jvmTarget 17 } } dependencies { implementation(androidx.core:core-ktx:1.13.0) implementation(org.jetbrains.kotlin:kotlin-stdlib:2.0.0) }这里有两个必须对齐的参数。sourceCompatibility和targetCompatibility控制 Java 编译器的字节码版本jvmTarget控制 Kotlin 编译器的目标版本三者不一致最常见的现象是编译时报 Inconsistent JVM-target compatibility 错误。另外compileSdk和 Kotlin 版本之间也有隐性约束Kotlin 2.0 要求 AGP 至少 7.1建议直接拉到当前稳定组合不要用太老的版本去凑。如果项目用的是 Groovy DSL配置思路完全一样只是语法换成kotlinOptions { jvmTarget 17 }。AGP 8.0 以后kotlinOptions开始被kotlin { compilerOptions {} }取代但前者仍然能用只是会在编译时打一条 deprecation 提示。到 AGP 9.0 才会强制切换现有项目不急于改。2.3 源码目录怎么摆kotlin 目录和 java 目录的共存规则目录组织决定了混编项目的可维护性。默认情况下AGP 不会自动创建kotlin/目录需要手动新建。一个标准的双语言模块目录结构是这样app/src/main/ ├── java/com/example/hybrid/ │ ├── legacy/ │ │ ├── OldHomeActivity.java │ │ └── LegacyApiClient.java │ └── MainApplication.java ├── kotlin/com/example/hybrid/ │ ├── feature/ │ │ ├── NewProfileViewModel.kt │ │ └── ProfileRepository.kt │ └── util/ │ └── DateFormatUtil.kt └── res/ └── layout/关键规则是两个目录下的包名可以相同Kotlin 编译器会同时扫描两个目录类名不能冲突。一种常见的错误是同一个类在 Java 里删了Kotlin 里还留着一个同名旧版本结果编译时提示 duplicate class——因为两个目录最终会被合并到同一个包命名空间。我的建议是用包名做语言分区而不是用目录做强制隔离。legacy包里放纯 Java 老代码feature和新模块用 Kotlin两个包之间的通信走接口而不是直接依赖实现类。这样从目录层面就能看出哪些代码是历史包袱哪些是新代码后续迁移时也方便按包逐个推进。3. Java 与 Kotlin 互操作从调用链到类型映射的完整梳理3.1 Kotlin 调用 Java空安全、Platform Type 与注解的正确用法Kotlin 对 Java 的每一个类型都打着问号——它不知道 Java 端的这个值到底可不可空于是引入了 Platform Type平台类型用String!表示。Kotlin 代码里可以把它当作可空或非空来用但如果你当作非空用了而 Java 端实际返回了null会在运行时才爆出空指针不会在编译期拦截。一个项目里最常见的崩溃现场就在于此// Java 侧 public class LegacyApiClient { public String getUserName() { return user null ? null : user.name; } } // Kotlin 侧调用 val name: String legacyApiClient.userName // 编译不报错 println(name.length) // 运行时 NPE解决方式是给 Java 代码补上可空注解。Android 工程里最常用的是androidx.annotation.Nullable和androidx.annotation.NonNullKotlin 编译器会读取注解并推导出可空性import androidx.annotation.Nullable; public class LegacyApiClient { Nullable public String getUserName() { return user null ? null : user.name; } }补完注解后Kotlin 侧的类型会变成String?编译器强制你处理空分支。对于不打算改动的第三方 Java 库可以在 Kotlin 侧用!!收窄但要用得克制——每用一次!!就等于放弃了一次编译期检查。我一般只在读配置文件、值必定存在的地方用业务接口返回一律走安全调用。3.2 Java 调用 Kotlin顶层函数、伴生对象与 JvmStatic反过来Java 调用 Kotlin 代码时也有几处不直观的地方。Kotlin 文件的顶层函数在编译后会生成一个以文件名命名的类Java 里调用时要通过这个类来调。假设有个StringExt.ktpackage com.example.hybrid.util fun String.isLegalPhone(): Boolean { return length 11 startsWith(1) }Java 侧调用方式是StringExtKt.isLegalPhone(phone)类名是文件名加Kt后缀。如果你不喜欢这个命名可以加JvmName注解改掉file:JvmName(StringUtils) package com.example.hybrid.util伴生对象是另一个典型坑。Kotlin 的companion object编译后挂在宿主类上Java 调用时需要显式访问Companion字段。要给 Java 侧提供自然的静态方法必须加JvmStaticclass ConfigProvider { companion object { JvmStatic fun getBaseUrl(): String https://api.example.com } }不加JvmStatic时Java 调用写的是ConfigProvider.Companion.getBaseUrl()加了之后可以直接写ConfigProvider.getBaseUrl()。对于需要被老代码广泛调用的工具类入口这是个影响调用链整洁度的关键注解。团队里可以约定所有 Kotlin 工具类都必须加JvmStatic避免 Java 侧出现两种风格的调用并存。3.3 类型映射参数表与集合类的差异Java 和 Kotlin 在互操作时基本类型和集合类各有映射规则。下面这张表是日常开发中最常用到的部分Java 类型Kotlin 类型注意事项intIntJava 的int映射为非空IntInteger映射为Int?longLong精度不会丢但比较时要小心装箱StringString!平台类型可空性取决于是否带注解ListStringMutableListString!!Java 侧不知道是否可变Kotlin 拿到的是平台集合MapString, ObjectMutableMapString, Any!!同理ObjectAny!根类型映射可作为任意类型使用void方法UnitJava 侧调用 Kotlin 返回Unit的方法时拿到的是Unit.INSTANCEint[]IntArray映射到原生数组不是ArrayInt集合类的差异最容易引起隐蔽 bug。Java 的List是可变的Kotlin 的List只读接口Java 侧把一个ArrayList传给 Kotlin 函数Kotlin 里声明成ListString接收看起来没问题但实际引用同一个对象Java 侧随时可能修改它。如果 Kotlin 函数内部假设这个列表不可变并缓存了结果数据一致性就会出问题。稳妥的做法是跨语言边界的集合参数在 Kotlin 侧一律声明为List只读接口同时对 Java 侧约定传进来之后不要再改。4. 从 Java 迁到 Kotlin 的落地路径怎么动代码最稳4.1 迁移顺序先工具类、再数据类、最后动页面层很多团队一上来就挑着一个最复杂的 Activity 试水结果迁移完功能回归花了三周。迁移顺序的正确姿势应该是从依赖最少的文件开始。第一步先迁工具类和无状态函数。这类代码没有页面生命周期依赖、不需要持有 Context迁完以后编译通过、单测能跑就算完成一个闭环。第二步迁数据模型类也就是Bean和EntityKotlin 的data class能省掉大量getter/setter/equals/hashCode。第三步才是 ViewModel、Repository 这类有状态逻辑的类。页面层 Activity 和 Fragment 建议放在最后因为涉及生命周期回调、系统服务调用互操作边界的复杂度最高。每一步迁移的验证标准是编译零新增警告、原有单测全绿、涉及该类的功能用例全部回归一遍。不要把迁移代码和顺手重构逻辑混在一起否则出问题的时候分不清是语言转换引入的还是逻辑改动引入的。4.2 批量转换的实操Android Studio 的自动转换能用几成Android Studio 提供 Java 到 Kotlin 的自动转换功能选中 Java 文件后用Code - Convert Java File to Kotlin File即可生成一个.kt文件。这个工具的真实水平是基础语法转换准确率很高但业务逻辑转换后常有三类问题。第一类是空安全原 Java 代码里的无注解可空值会被转为平台类型生成后的 Kotlin 代码里直接以非空方式使用运行时风险被原样保留。第二类是静态成员访问Java 里的static方法转为伴生对象后所有调用点变成类名.Companion.方法()编译能过但风格很脏。第三类是匿名内部类转为 lambdaJava 的setOnClickListener(new OnClickListener() {...})会被转成setOnClickListener { ... }如果原匿名内部类里有多个方法转换结果可能把方法体合并到一个 lambda 里逻辑顺序反转。实际操作中我的做法是让 IDE 转框架然后手动修这三个点。自动转换跑完先全局搜Companion、!!、as?这三个关键词把可疑代码全部过一遍再提交。转换后的代码第一次编译通常不会报错但能编译不等于能正确运行。4.3 混合代码风格下的团队约束代码规范和评审点Java 和 Kotlin 混编最怕的不是技术问题而是代码风格失去统一性。某公司团队曾经出现过同一个工具类在 Java 里叫DateUtil、在 Kotlin 里叫DateUtils两个类功能重叠后续维护的人要翻两处才能确认哪个还能用。可行的约束只有两条。一条是包级约束新代码一律用 Kotlin老代码只有在改动时才允许用 Java 新增方法不允许在老 Java 类里持续堆新功能。另一条是互操作边界约束跨语言的公共接口只允许暴露基本类型和已定义的数据类不暴露平台集合类型。评审时重点看三个点Kotlin 文件里有没有使用!!、Java 文件里有没有直接访问Companion、跨语言的数据类字段有没有可空性注解。5. 双语言源码开发中的常见问题与避坑指南5.1 编译速度骤降增量编译失效的排查与解决现象刚混编时编译一次 30 秒跑了不到两周变成 90 秒经常改一行 Kotlin 代码也要等大半分钟。原因有两层。第一层是 Kotlin 和 Java 的增量编译机制协作得不好Kotlin 编译需要先看 Java 源码的符号拿不到缓存就会退化成全量编译。最常见的情况是 Java 侧类改了签名Kotlin 侧所有引用了它的文件都要重新编译。第二层是 kapt 注解处理器开着但并没有实际用到——很多项目把kotlin-kapt插件挂上之后就一直没摘kapt 会显著拖慢编译。解决方法是先看编译日志里Executing tasks部分确认是不是所有模块都重新编译了。如果只有:app:compileDebugKotlin全量执行检查是不是 Java 源码目录里有人动了公共类、或者资源文件触发了整个源码集的重新扫描。没有用到注解处理器的模块从plugins里去掉kotlin-kapt通常能换回 15% 到 20% 的编译时长。5.2 协程与 Java 回调的桥接suspend 函数怎么被 Java 调用现象Kotlin 侧写了一个suspend fun fetchData(): ResultJava 侧直接调用编译器会报错说 suspend 函数只能从协程里调用。原因suspend 函数编译后签名里多了一个Continuation参数Java 调用时必须手动构造这个参数普通 Java 代码没有协程上下文自然不知道怎么传。解决方式是在互操作边界处提供一个 Java 友好的桥接方法把 suspend 函数包装成回调形式JvmName(fetchDataAsync) fun fetchData( onResult: (Result - Unit, onError: (Throwable) - Unit ) { viewModelScope.launch { try { onResult(fetchData()) } catch (e: Exception) { onError(e) } } }Java 侧调用api.fetchDataAsync(result - handleResult(result), throwable - handleError(throwable));。这里有一个必须明确的约束桥接方法内部自己开协程回调回到哪个线程取决于viewModelScope的调度器。如果协程里有网络请求回调默认在后台线程返回更新 UI 前必须手动切到主线程。不然就会出现数据和 UI 错乱这个协程桥接的经典事故。5.3 默认参数与函数重载Java 侧调用时的意外迷路现象Kotlin 里定义了一个带默认参数的函数Java 侧调用时编译报错找不到方法。原因Kotlin 的默认参数靠编译器在调用点生成合成方法Java 不支持这个机制所以 Java 拿不到带默认值的完整签名。如果 Kotlin 函数所有参数都有默认值Java 侧要怎么调都不会编译通过除非加JvmOverloads。JvmOverloads会让编译器生成一组重载方法逐个省略默认参数class PagerConfig { JvmOverloads fun pageSize(limit: Int 20, retry: Boolean true): Int { return if (retry) limit else limit * 2 } }加了之后 Java 侧可以写PagerConfig().pageSize(20)、PagerConfig().pageSize(20, false)、PagerConfig().pageSize()。不加则三种调用全报错。这个注解的代价是生成的字节码体积略增但换来 Java 侧的调用自由。如果这个函数只被 Kotlin 调就别加——多一个注解就多一层 API 表面。5.4 序列化与 ParcelableKotlin 数据类的坑现象一个 Kotlindata class实现了 Parcelable用 Intent 传给对方页面后读出来的字段是默认值而非实际值。原因Kotlin 的data class生成的equals/hashCode/toString不参与 Parcelable 的序列化逻辑如果用Parcelize注解依赖 kotlin-parcelize 插件这个插件在 Kotlin 2.0 以后已经稳定但如果沿用了老手写 Parcelable 的模板代码很容易漏写某个字段。解决方式是新代码一律用Parcelize。注意Parcelize要求所有字段都在构造函数里且类型必须能被 Bundle 支持。如果数据类里有一个Instant类型的字段编译时会直接报错需要手动转成Long存时间戳。另一个关联坑是Serializable。Java 的老代码习惯用Serializable传对象Kotlin 的数据类默认支持Serializable但内部字段如果有lambda或coroutine相关类型运行时会在serialize时抛出NotSerializableException。这类坑在运行时才爆排查成本比编译期高一个量级。5.5 第三方库的注解处理器冲突与正解现象项目同时引入了 Gson 和 kotlinx.serializationGson 的ReflectiveTypeAdapterFactory在处理 Kotlin 数据类时因为 Kotlin 类没有无参构造函数而反射失败运行时抛出UninitializedPropertyAccessException。原因Gson 底层用反射创建对象Kotlin 的类默认有构造函数参数反射拿不到无参构造器就会绕过构造函数分配内存导致字段没有被初始化读到默认值。解决方式三条路给数据类加Transient不适用的字段要单独处理或者用 Gson 的KotlinJsonAdapterFactory最省心的做法是数据类统一用 kotlinx.serialization 的Serializable注解在编译期生成序列化器不依赖反射。这个坑的教训是双语言项目里跨语言边界的数据模型最好只出现在一处——Kotlin 侧定义Java 侧使用。不要 Java 和 Kotlin 各定义一个相同的模型类然后在边界上做转换。那会引入双份维护成本和双份序列化风险。6. 互操作质量门禁一个可以立刻用上的代码审查清单双语言工程最怕能编译就合代码。我所在团队用过半年的门禁清单用下来既不会卡流程浪费大家时间又能挡住所有踩过的坑。第一项编译警告当作错误处理。compileDebugKotlin任务里把allWarningsAsErrors打开Kotlin 里有一类警告是可空性推导不一致平时只是黄色提示在互操作代码里它往往预示着一个运行时 NPE。与其让它在测试阶段炸不如让它在编译阶段死。Java 侧对应把lintOptions里的warningsAsErrors开到针对Nullability的检查项这个范围内打开就够了全局打开会引入大量历史存量报错得不偿失。第二项跨语言调用链必须配单元测试。Kotlin 调用 Java 的工具函数、Java 调用 Kotlin 的带默认参数函数这两种方向各写至少一个测试用例。测试的重点不是业务逻辑而是参数传递和返回值类型转换。一旦某个类型映射被改错——比如 Java 侧把Integer改成了int——测试会立刻在类型断言上红掉这比在联调阶段抓空指针快得多。第三项代码审查时盯住三个关键词!!、Companion、platform type。出现!!要有注释说明为什么此处不可空出现Companion说明 Java 侧在访问伴生对象审查 Kotlin 类是否漏了JvmStatic平台类型出现在跨语言接口里要求补上可空注解。我自己的习惯是每周抽半小时扫一遍双语言边界上的 git diff只看签名不看实现。Java 侧改了一个方法的返回类型Kotlin 侧有没有跟着调整可空性声明一眼就能看出来。干这个活不需要特别深的语言功底但要盯得勤。混编项目里大部分线上事故都不是某个语言写错了而是在两边交接的那一行上出了岔子。坚持这个习惯半年被互操作坑到的次数会明显降下来希望帮到你。本文还有配套的精品资源点击获取