各位 Android 彭于晏，周五好！

前几天我和同事吃饭的时候，他突然问我：你知道 Kotlin 那个 internal 是咋回事儿么？

我：当然知道。但是在说这个之前，应该都复习一下其他的可见性修饰符，你等我，周五给你出文章！

Kotlin 常见修饰符

可见性修饰符决定了程序中类、对象、接口、函数和属性的可访问范围。

Kotlin 一共提供四种可见性修饰符：publicprivateprotected 和 internal。它们各自服务于不同场景，为代码元素的访问边界提供了清晰定义。

默认情况下如果一个声明没有显式写出修饰符，它会被视为 public。

Kotlin 社区对于“默认修饰符是 public”这一设计一直颇有微词。很多人认为应该主动声明你要暴露的接口，而非默认全部暴露。

Public

public 修饰符表示这个声明可以从程序中的任何地方访问。这也是所有顶层声明和成员声明的默认可见性。至于例如，

class PublicExample { public fun greet = "Hello。skydoves，"}

这里的 greet 函数可以被任意其他类或文件访问。

Private

private 修饰符会把访问范围限制在同一个文件内，或者限制在其所在类或对象内部。说起来，它非常适合用来做封装。

class PrivateExample { private val secret = "Hidden from outside" fun revealSecret = secret}

在这个例子里secret 属性只能在 PrivateExample 类内部访问。

Protected

protected 与 private 很像，但它允许子类访问成员。它只能用于类成员，不能用于顶层声明。

open class Parent { protected fun protectedMethod = "Accessible in subclasses"}class Child : Parent { fun useProtected = protectedMethod}

这里的 protectedMethod 可以在 Child 类内部访问，但不能在整个类继承程序之外访问。

Internal 的魅力与痛点

作为开发者。我们经常会遇到这样的困扰：在开发 SDK 或开源库时如何有效地隐藏内部实现细节，避免它们被滥用？这时Kotlin 的 internal 修饰符就像一束光，照亮了方法。说起来，它也引发了一些疑问。比如“跨模块调用时internal 到底怎么玩？ ”“为啥 IDEA 里提示报错，但在命令行编译时却能通过？”带着这些问题，大家一起揭开 internal < / code >的神秘面纱。

Internal

internal 修饰符会把声明的访问范围限制在同一个模块内。这很适合在模块内部共享实现，同时阻止其他模块从外部直接访问。

 internal class InternalExample {
internal fun internalFunction = "Available within module"
} 

internalFunction 可以在同一模块中的任意位置访问，但不能被其他模块访问。

在实际的 Android 开发中，一个模块通常对应着你定义的一个 Gradle module。话说回来，可以这么理解的观点是。internal 对于模块内部相当于 public 而对于模块外部相当于 private 。不过，

从进阶来看。internal 到底怎么实现的？

名称 与 public 的结合：巧妙实现“模块级可见性”

• JVM 不支持模块级可见性：

  JVM 只认识几种固定的可见性规则。比如 public protected ,private ,还有包私有。但它完全不知道什么是“模块”。Kotlin 则引入了更细粒度的控制，希望让开发者能在更贴近工程结构的层次上进行封装。这就催生了对 ` internal ` 的需求。< / p >

• 编译期处理 + 名称 ： < / strong>

  • 当 Kotlin 编译器处理到某个 ` internal ` 函数或类时它会将其编译为 JVM 能识别的形式 —— 也就是 ` public `。这样做是为了确保同一模块内的代码能够正常相互调用，因为 JVM 不支持更细粒度的“模块级”可见性控制。< / p >

  • ⚠️ 但仅仅是 public 还不够。为了避免外部误用，Kotlin 同时会对这些 ` internal ` 成员进行**名称 **。简单就是给它们的名称添加一个特殊的后缀。使其变得不那么“显眼”，甚至让 Java 调用者望而却步。< / p >

合理利用 ` internal ` 进行架构分层 < / strong> 通过将主要实现细节标记为 ` internal `。你可以减少它们被外部滥用，同时让团队成员清晰理解哪些接口是稳定的、哪些是供内部使用的。< / p> < / li>