从基础概念到实战应用，系统梳理 Android 架构演进之路

一、基础概念

1.1 为什么需要架构优化？

随着业务迭代，单体 App 会遇到诸多问题：

1.2 三种架构模式辨析

1
2
3
4
5
6
7
8
9
10
11
12

┌─────────────────────────────────────────────────────────────────┐
│                        架构演进路径                               │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│   单体架构 ──► 模块化 ──► 组件化 ──► 插件化                        │
│      │           │          │           │                         │
│      │           │          │           │                         │
│      ▼           ▼          ▼           ▼                         │
│   按功能拆分   Gradle模块   路由解耦    运行时动态加载               │
│   包结构划分   build独立   ARouter等    热更新/按需下载              │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

模块化（Modularization）

• 定义：按业务功能将代码拆分为独立的 Gradle 模块，每个模块有清晰的 build.gradle 和边界
• 特点：物理隔离、可独立编译，通常仍在同一 Git 仓库内
• 粒度：中等，如「用户模块」「订单模块」「支付模块」

组件化（Componentization）

• 定义：在模块化基础上，通过路由/服务发现实现模块间完全解耦，可独立开发、独立运行
• 特点：依赖倒置、接口隔离、可单模块调试（Application 切换）
• 粒度：较细，如「登录组件」「分享组件」「埋点组件」

插件化（Pluginization）

• 定义：插件 APK/Dex 可动态加载、热更新，主 App 与插件解耦到运行时
• 特点：运行时动态、按需下载、可热修复、减小包体积
• 粒度：独立 APK/模块

二、模块化原理与实践

2.1 模块化的核心原则

1. 单一职责：每个模块只负责一块业务
2. 接口隔离：模块间通过接口/路由通信，不暴露实现细节
3. 依赖倒置：依赖抽象（interface）而非具体实现

2.2 Gradle 多模块目录结构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

MyApp/
├── app/                        # 主工程壳
│   └── build.gradle
├── module_user/                # 用户模块
│   ├── build.gradle
│   └── src/main/
├── module_order/               # 订单模块
│   └── build.gradle
├── module_payment/             # 支付模块
│   └── build.gradle
├── common_base/                # 公共基础库
│   ├── network/
│   ├── utils/
│   └── base/
├── common_router/              # 路由层
│   └── build.gradle
├── build.gradle
└── settings.gradle

2.3 settings.gradle 与模块声明

1
2
3
4
5
6
7
8

// settings.gradle
rootProject.name = "MyApp"
include ':app'
include ':module_user'
include ':module_order'
include ':module_payment'
include ':common_base'
include ':common_router'

2.4 模块间依赖配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

// app/build.gradle - 主工程依赖各业务模块
dependencies {
    implementation project(':module_user')
    implementation project(':module_order')
    implementation project(':module_payment')
    implementation project(':common_router')
    implementation project(':common_base')
}

// module_user/build.gradle - 业务模块只依赖基础库和路由
dependencies {
    implementation project(':common_base')
    implementation project(':common_router')
    // 不要依赖 module_order、module_payment！
}

// common_base/build.gradle - 基础库不依赖任何业务模块
dependencies {
    implementation 'androidx.appcompat:appcompat:1.6.1'
    implementation 'com.squareup.retrofit2:retrofit:2.9.0'
}

2.5 模块间通信：接口 + 实现注入

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

// common_router 中定义接口
interface IUserService {
    fun getCurrentUser(): User?
    fun logout()
}

// module_user 中实现接口
class UserServiceImpl : IUserService {
    override fun getCurrentUser(): User? = UserManager.currentUser
    override fun logout() { /* ... */ }
}

// 通过 ServiceLocator 或依赖注入框架注入
object ServiceLocator {
    var userService: IUserService? = null
}

// module_order 中调用
class OrderActivity : AppCompatActivity() {
    private val userService: IUserService? by lazy { ServiceLocator.userService }

    fun showUserInfo() {
        userService?.getCurrentUser()?.let { user ->
            // 显示用户信息
        }
    }
}

三、组件化原理与实现

3.1 组件化架构图

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

                ┌──────────────────┐
                │     app (壳)      │
                │   主工程/组装     │
                └────────┬─────────┘
                         │
          ┌──────────────┼──────────────┐
          │              │              │
          ▼              ▼              ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ module_user │ │ module_order│ │module_payment│
└──────┬──────┘ └──────┬──────┘ └──────┬──────┘
       │               │               │
       └───────────────┼───────────────┘
                       │
                ┌──────▼──────┐
                │   ARouter   │
                │ 路由中间层   │
                └──────┬──────┘
                       │
                ┌──────▼──────┐
                │ common_base │
                │ 基础组件库   │
                └─────────────┘

3.2 路由方案对比

3.3 单模块独立运行（Application 切换）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

// module_user/build.gradle
android {
    defaultConfig {
        // 作为 Application 运行时使用
        if (project.hasProperty('runAsApp') && runAsApp) {
            applicationId "com.example.user"
        }
    }
    sourceSets {
        main {
            manifest.srcFile 'src/main/AndroidManifest.xml'
            if (project.hasProperty('runAsApp') && runAsApp) {
                manifest.srcFile 'src/main/debug/AndroidManifest.xml'
            }
        }
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13

<!-- module_user/src/main/debug/AndroidManifest.xml - 独立运行时的 Manifest -->
<manifest>
    <application
        android:name=".UserDebugApplication"
        android:label="User Module Debug">
        <activity android:name=".UserActivity" android:exported="true">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
    </application>
</manifest>

1
2

# 独立运行用户模块
./gradlew :module_user:installDebug -PrunAsApp=true

3.4 ARouter 使用与原理

3.4.1 添加依赖

1
2
3
4
5

// 各模块 build.gradle
dependencies {
    implementation 'com.alibaba:arouter-api:1.5.2'
    kapt 'com.alibaba:arouter-compiler:1.5.2'
}

3.4.2 路由配置与跳转

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

// ========== 组件端：Order 模块 ==========
// 在 OrderListActivity 上添加路由注解
@Route(path = "/order/list")
class OrderListActivity : AppCompatActivity() {
    @Autowired
    lateinit var userId: String

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        ARouter.getInstance().inject(this)
        // userId 已自动注入
    }
}

// ========== 调用端：任意模块 ==========
ARouter.getInstance()
    .build("/order/list")
    .withString("userId", "12345")
    .navigation()

3.4.3 服务发现（跨模块获取实现）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

// 定义接口（可在 common_base 或单独 api 模块）
interface IOrderService {
    fun getOrderCount(userId: String): Int
}

// Order 模块实现并注册
@Route(path = "/service/order")
class OrderServiceImpl : IOrderService {
    override fun getOrderCount(userId: String): Int = /* ... */
}

// 调用端获取
val orderService = ARouter.getInstance()
    .navigation(IOrderService::class.java)
orderService?.getOrderCount("12345")

3.4.5 ARouter 核心源码解析

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

// 简化版 ARouter 核心逻辑
// 1. 初始化时扫描 Dex，加载路由表（通过 Gradle 插件编译期生成）
class Warehouse {
    // 路由表：path -> RouteMeta
    static Map<String, RouteMeta> routes = ConcurrentHashMap()
    // 分组缓存
    static Map<String, Class<? extends IRouteGroup>> groupsIndex = ConcurrentHashMap()
}

// 2. navigation 流程
fun navigation(path: String): Postcard {
    val meta = Warehouse.routes[path]  // 从路由表获取
    return Postcard(path, meta)
}

fun Postcard.navigation(): Any? {
    return _ARouter.navigation(context, this, requestCode, navigationCallback)
}

// 3. 实际跳转
fun _ARouter.navigation(...) {
    when (meta.type) {
        RouteType.ACTIVITY -> {
            val intent = Intent(context, meta.destination)
            // 注入参数
            context.startActivity(intent)
        }
        RouteType.ISERVICE -> {
            return meta.destination.newInstance()  // 服务实现类
        }
    }
}

// 4. 编译期注解处理器生成路由表
// 生成类似：ARouter$$Group$$order、ARouter$$Providers$$order
// 在 init() 时通过反射加载到 Warehouse

3.5 依赖关系设计原则

1
2
3
4
5
6
7
8
9

业务模块 (user/order/payment)
    │
    ├── 只依赖 common_base、common_router (arouter-api)
    │
    └── 业务模块之间 不直接依赖

app 壳工程
    │
    └── 依赖所有业务模块，负责组装和 Application 初始化

四、插件化原理与实现

4.1 插件化的应用场景

• 热更新：修复线上 Bug 无需发版
• 按需加载：减小包体积，冷启动只加载核心
• 动态能力：运营活动插件、A/B 测试模块
• 多端复用：同一套插件可被主 App、Split APK 加载

4.2 Android 插件化技术选型

4.3 Dynamic Feature Modules（官方方案）

4.3.1 配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

// settings.gradle
include ':app'
include ':feature:order'  // 动态功能模块

// app/build.gradle
dependencies {
    implementation project(':common_base')
    dynamicFeatures = [':feature:order']
}

// feature/order/build.gradle
apply plugin: 'com.android.dynamic-feature'
android {
    defaultConfig {
        minSdk 24
    }
}
dependencies {
    implementation project(':app')
}

4.3.2 按需下载与安装

1
2
3
4
5
6
7
8
9
10
11
12
13
14

// 使用 Play Core Library 下载动态模块
val splitInstallManager = SplitInstallManagerFactory.create(context)
val request = SplitInstallRequest.newBuilder()
    .addModule("order")
    .build()

splitInstallManager.startInstall(request)
    .addOnSuccessListener {
        // 安装成功，可跳转
        startActivity(Intent(this, OrderActivity::class.java))
    }
    .addOnFailureListener {
        // 处理失败
    }

4.4 RePlugin 核心原理简述

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

┌──────────────────────────────────────────────────────┐
│                     Host App                          │
│  ┌────────────────────────────────────────────────┐  │
│  │  RePluginHostConfig / PluginManager             │  │
│  │  - 加载插件 APK                                  │  │
│  │  - 替换 ClassLoader                              │  │
│  │  - Hook Activity/Service 等组件                  │  │
│  └────────────────────────────────────────────────┘  │
└──────────────────────────────────────────────────────┘
                         │
         ┌───────────────┼───────────────┐
         ▼               ▼               ▼
   ┌──────────┐   ┌──────────┐   ┌──────────┐
   │ Plugin1  │   │ Plugin2  │   │ Plugin3  │
   │  .apk    │   │  .apk    │   │  .apk    │
   └──────────┘   └──────────┘   └──────────┘

核心流程：

1. Dex 加载：将插件 APK 的 classes.dex 加入宿主的 DexPathList
2. 资源加载：创建 Resources，合并插件的 AssetManager
3. 组件占位：通过 Hook Instrumentation/IActivityManager，用占位 Activity 代理插件 Activity

4.5 手写简易插件加载（Dex 加载）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

// 简化示例：加载插件 APK 中的类
class PluginLoader(private val context: Context) {

    private val pluginClassLoaders = mutableMapOf<String, DexClassLoader>()

    fun loadPlugin(apkPath: String): Boolean {
        val optimizedDir = File(context.filesDir, "plugin_opt").apply { mkdirs() }
        val libDir = File(context.filesDir, "plugin_lib").apply { mkdirs() }

        val classLoader = DexClassLoader(
            apkPath,
            optimizedDir.absolutePath,
            null,
            context.classLoader
        )
        pluginClassLoaders[apkPath] = classLoader
        return true
    }

    fun loadClass(apkPath: String, className: String): Class<*>? {
        val loader = pluginClassLoaders[apkPath] ?: return null
        return try {
            loader.loadClass(className)
        } catch (e: ClassNotFoundException) {
            null
        }
    }
}

// 加载插件中的 Activity（实际还需 Hook 组件启动流程）
val loader = PluginLoader(context)
loader.loadPlugin("/sdcard/plugin.apk")
val clazz = loader.loadClass("/sdcard/plugin.apk", "com.plugin.MainActivity")
val activity = clazz.newInstance()

4.6 插件化资源加载

1
2
3
4
5
6
7
8
9
10
11
12

// 合并插件资源到宿主
fun createPluginResources(hostResources: Resources, apkPath: String): Resources {
    val assets = AssetManager::class.java.newInstance()
    val addAssetPath = AssetManager::class.java.getMethod("addAssetPath", String::class.java)
    addAssetPath.invoke(assets, apkPath)

    return Resources(
        assets,
        hostResources.displayMetrics,
        hostResources.configuration
    )
}

五、ARouter 框架源码深度解析

5.1 整体架构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

┌────────────────────────────────────────────────────────┐
│                     ARouter                              │
│  - 对外 API：build、navigation、inject                    │
└────────────────────────────────────────────────────────┘
                          │
┌─────────────────────────┴─────────────────────────────┐
│                  _ARouter (内部实现)                     │
│  - LogisticsCenter：路由表、分组加载                      │
│  - Warehouse：路由/服务/拦截器 存储                       │
└────────────────────────────────────────────────────────┘
                          │
        ┌─────────────────┼─────────────────┐
        ▼                 ▼                 ▼
┌──────────────┐  ┌──────────────┐  ┌──────────────┐
│ 注解处理器    │  │ 拦截器链     │  │ 降级策略      │
│ 编译期生成   │  │ 可扩展       │  │ DegradeService│
└──────────────┘  └──────────────┘  └──────────────┘

5.2 LogisticsCenter 路由表加载

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

// 初始化时通过插件扫描 Dex 中的特定类
public static void init(Context context) {
    try {
        // 获取所有 ARouter 生成的类：ARouter$$Root$$xxx
        Set<String> routerMap = ClassUtils.getFileNameByPackageName(
            context, ROUTE_ROOT_PACKAGE);
        for (String className : routerMap) {
            if (className.startsWith(ROUTE_ROOT_PACKAGE + DOT + SDK_NAME + SEPARATOR + SUFFIX_ROOT)) {
                ((IRouteRoot) Class.forName(className).getConstructor().newInstance())
                    .loadInto(Warehouse.groupsIndex);
            }
        }
        // 分组按需加载，避免启动时加载全部
    } catch (Exception e) {
        throw new HandlerException("ARouter init logistics center exception");
    }
}

5.3 拦截器机制

1
2
3
4
5
6
7
8
9
10
11
12

@Interceptor(priority = 8)
class LoginInterceptor : IInterceptor {
    override fun process(postcard: Postcard, callback: InterceptorCallback) {
        if (postcard.extra == NEED_LOGIN && !UserManager.isLoggedIn()) {
            // 未登录，拦截并跳转登录
            ARouter.getInstance().build("/user/login").navigation()
            callback.onInterrupt(null)
        } else {
            callback.onContinue(postcard)
        }
    }
}

六、实际项目应用案例

6.1 某电商 App 组件化拆分

1
2
3
4
5
6
7
8
9
10
11

app (壳工程)
├── module_home          # 首页
├── module_product       # 商品详情
├── module_cart          # 购物车
├── module_order         # 订单
├── module_user          # 用户中心
├── module_payment       # 支付
├── module_share         # 分享（可复用）
├── module_analytics     # 埋点（可复用）
├── common_router        # ARouter 封装
└── common_base          # 网络/缓存/UI 基础库

收益：

• 编译时间：全量 6min → 单模块 1min
• 4 个业务线可并行开发，Git 冲突减少 60%
• ShareModule、AnalyticsModule 复用到多个 App

6.2 路由表设计实战

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

// 统一路由 Path 常量
object RouterPath {
    const val ORDER_LIST = "/order/list"
    const val ORDER_DETAIL = "/order/detail"
    const val USER_LOGIN = "/user/login"
    const val USER_PROFILE = "/user/profile"
}

// 封装便捷方法
object Router {
    fun toOrderList(userId: String) {
        ARouter.getInstance()
            .build(RouterPath.ORDER_LIST)
            .withString("userId", userId)
            .navigation()
    }

    fun toOrderDetail(orderId: String) {
        ARouter.getInstance()
            .build(RouterPath.ORDER_DETAIL)
            .withString("orderId", orderId)
            .navigation()
    }
}

6.3 解耦实践：避免循环依赖

错误示例：

1
2

module_order -> module_user (获取用户信息)
module_user  -> module_order (跳转订单列表)

形成循环依赖，Gradle 编译失败。

正确做法：

1
2

module_order -> common_router
module_user  -> common_router

需要「用户信息」时，Order 通过 ARouter.getInstance().navigation(IUserService::class.java) 获取；需要「跳转订单」时，User 通过 ARouter.getInstance().build("/order/list").navigation() 跳转。

6.4 模块化 + 插件化组合：Dynamic Feature 实践

某资讯 App 将「小说」「漫画」等非核心功能做成 Dynamic Feature，用户首次进入时提示下载：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

// 检查模块是否已安装
fun isModuleInstalled(moduleName: String): Boolean {
    return SplitInstallManagerFactory.create(context)
        .installedModules.contains(moduleName)
}

// 进入小说模块前检查
fun openNovelModule() {
    if (isModuleInstalled("novel")) {
        startActivity(Intent(this, NovelActivity::class.java))
    } else {
        showDownloadDialog {
            installDynamicModule("novel")
        }
    }
}

七、最佳实践与注意事项

7.1 模块拆分原则

• 高内聚低耦合：模块内聚度高，模块间依赖少
• 按业务边界拆分：参考 DDD 的 Bounded Context
• 基础组件下沉：网络、缓存、日志等抽成 common_base
• 渐进式演进：先模块化再组件化，避免一步到位导致成本过高

7.2 常见坑与规避

7.3 R 文件与资源隔离

1
2
3
4

// 各业务模块 build.gradle 中
android {
    resourcePrefix "user_"   // 资源必须以 user_ 开头
}

7.4 架构演进路线图

1
2
3
4
5
6
7
8
9
10
11
12
13
14

Phase 1: 模块化
├── 拆分为 Gradle 多模块
├── 建立 common_base、common_router
└── 模块间通过接口通信

Phase 2: 组件化
├── 引入 ARouter 路由
├── 服务发现替代直接依赖
└── 支持单模块独立运行调试

Phase 3: 插件化（可选）
├── 非核心功能改为 Dynamic Feature
├── 或引入 RePlugin/Shadow 做完整插件化
└── 按需下载、热更新

八、总结

架构没有银弹，需结合团队规模、业务复杂度、迭代节奏选择合适方案。建议从模块化起步，随着复杂度提升再逐步演进到组件化，插件化则按实际需求谨慎引入。

参考资源

• ARouter - 阿里开源路由框架
• RePlugin - 360 插件化框架
• Shadow - 腾讯插件化框架
• Dynamic Feature Modules 官方文档
• Android 模块化探索与实践

从基本概念到源码实现，全面解析 React Hooks

一、基本概念

1.1 什么是 Hooks？

Hooks 是 React 16.8 引入的新特性，它允许你在不编写 class 的情况下使用 state 以及其他的 React 特性。

简单来说，Hooks 就是让你在函数组件中”钩入” React 特性的函数。

1.2 为什么需要 Hooks？

在 Hooks 出现之前，React 存在以下问题：

1.3 核心 Hooks 一览

二、常用 Hooks 详解与示例

2.1 useState

1
2
3
4
5
6
7
8
9
10
11
12
13

function Counter() {
  const [count, setCount] = useState(0);
  const [user, setUser] = useState({ name: '', age: 0 });

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount(count + 1)}>+1</button>
      {/* 函数式更新，适合依赖前一个 state */}
      <button onClick={() => setCount(prev => prev + 1)}>+1 (函数式)</button>
    </div>
  );
}

关键点：

• useState 接收初始值，返回 [当前值, 更新函数]
• 初始值可以是函数（惰性初始化），用于避免每次渲染都执行 expensive 计算

1

const [state, setState] = useState(() => computeExpensiveInitialState());

2.2 useEffect

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

function DataFetcher({ id }) {
  const [data, setData] = useState(null);

  useEffect(() => {
    const controller = new AbortController();
    fetch(`/api/users/${id}`, { signal: controller.signal })
      .then(res => res.json())
      .then(setData)
      .catch(console.error);

    // 清理函数：组件卸载或 effect 重新执行前调用
    return () => controller.abort();
  }, [id]); // 依赖数组：id 变化时重新执行

  return <div>{data ? JSON.stringify(data) : 'Loading...'}</div>;
}

依赖数组规则：

• 不传：每次渲染后都执行
• []：仅挂载时执行一次
• [a, b]：a 或 b 变化时执行

2.3 useRef

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

function TextInput() {
  const inputRef = useRef(null);

  const focusInput = () => {
    inputRef.current?.focus();
  };

  return (
    <>
      <input ref={inputRef} />
      <button onClick={focusInput}>聚焦</button>
    </>
  );
}

// 保存可变值，不触发重渲染
function Timer() {
  const countRef = useRef(0);
  countRef.current++; // 修改不会触发渲染
  return <div>Render count: {countRef.current}</div>;
}

2.4 useCallback 与 useMemo

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

function Parent() {
  const [count, setCount] = useState(0);
  const [text, setText] = useState('');

  // 缓存函数，避免子组件因引用变化而重渲染
  const handleClick = useCallback(() => {
    setCount(c => c + 1);
  }, []);

  // 缓存计算结果
  const expensiveValue = useMemo(() => {
    return computeExpensiveValue(count);
  }, [count]);

  return <MemoChild onClick={handleClick} value={expensiveValue} />;
}

三、Hooks 原理浅析

3.1 核心思想：链表存储

React 在内部用链表来存储 Hooks。每个函数组件对应一个 Fiber 节点，每个 Hook 是链表上的一个节点。

1
2
3
4
5

Fiber 节点
  └── memoizedState (第一个 Hook)
        ├── next -> (第二个 Hook)
        │             ├── next -> (第三个 Hook)
        │             │             └── ...

为什么是链表？

• 函数组件没有 this，无法像 Class 那样用实例存储
• 链表可以按调用顺序保存多个 Hook
• 每次渲染时按顺序遍历链表，对应到正确的 state

3.2 两个重要的链表

React 内部维护两套 Hook 链表：

1. current：当前屏幕上显示的 UI 对应的 Hooks
2. workInProgress：正在构建的新的 Hooks

渲染流程大致为：

1
2
3

mount -> workInProgress 构建新链表
update -> 从 current 复制到 workInProgress，按顺序更新
commit -> workInProgress 替换 current

3.3 为什么 Hooks 必须在顶层调用？

1
2
3
4
5
6
7

// ❌ 错误：条件调用
function Bad() {
  if (condition) {
    const [a, setA] = useState(0); // 破坏调用顺序！
  }
  const [b, setB] = useState(0);
}

React 依赖 Hooks 的调用顺序 来将 state 与正确的 Hook 关联。如果顺序变化，会错位导致 bug。

四、源码解读

4.1 简化的 Hook 数据结构

1
2
3
4
5
6
7
8

// React 内部简化版
type Hook = {
  memoizedState: any,    // 当前 state 值
  baseState: any,        // 基础 state
  baseQueue: Update | null,
  queue: UpdateQueue,    // 更新队列
  next: Hook | null,     // 下一个 Hook（链表）
};

4.2 useState 实现思路

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

// 极简版 useState 实现（理解原理用）
let hooks = [];
let currentHook = 0;

function useState(initialState) {
  const index = currentHook;
  hooks[index] = hooks[index] ?? (typeof initialState === 'function' ? initialState() : initialState);

  function setState(newState) {
    hooks[index] = typeof newState === 'function' ? newState(hooks[index]) : newState;
    scheduleReRender();
  }

  currentHook++;
  return [hooks[index], setState];
}

function useMyComponent() {
  currentHook = 0;
  const [count, setCount] = useState(0);
  const [name, setName] = useState(''); // 按顺序压入链表
  // ...
}

4.3 useEffect 实现思路

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

function useEffect(callback, deps) {
  const index = currentHook;
  const prevDeps = hooks[index];

  const hasChanged = !prevDeps || deps?.some((d, i) => d !== prevDeps[i]);

  if (hasChanged) {
    // 先执行上一次的 cleanup
    if (typeof prevEffect?.cleanup === 'function') {
      prevEffect.cleanup();
    }
    const cleanup = callback();
    hooks[index] = { deps, cleanup };
  }
  currentHook++;
}

五、自定义 Hook

5.1 封装业务逻辑

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

// useLocalStorage - 同步 state 到 localStorage
function useLocalStorage(key, initialValue) {
  const [storedValue, setStoredValue] = useState(() => {
    try {
      const item = window.localStorage.getItem(key);
      return item ? JSON.parse(item) : initialValue;
    } catch (e) {
      return initialValue;
    }
  });

  const setValue = useCallback((value) => {
    setStoredValue(prev => {
      const next = typeof value === 'function' ? value(prev) : value;
      window.localStorage.setItem(key, JSON.stringify(next));
      return next;
    });
  }, [key]);

  return [storedValue, setValue];
}

// 使用
function Settings() {
  const [theme, setTheme] = useLocalStorage('theme', 'light');
  return <button onClick={() => setTheme(t => t === 'light' ? 'dark' : 'light')}>{theme}</button>;
}

5.2 useDebounce

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

function useDebounce(value, delay) {
  const [debouncedValue, setDebouncedValue] = useState(value);

  useEffect(() => {
    const timer = setTimeout(() => setDebouncedValue(value), delay);
    return () => clearTimeout(timer);
  }, [value, delay]);

  return debouncedValue;
}

// 搜索防抖
function SearchInput() {
  const [search, setSearch] = useState('');
  const debouncedSearch = useDebounce(search, 300);

  useEffect(() => {
    if (!debouncedSearch) return;
    fetchResults(debouncedSearch);
  }, [debouncedSearch]);
  // ...
}

5.3 useFetch（数据请求）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

function useFetch(url) {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    setLoading(true);
    const controller = new AbortController();

    fetch(url, { signal: controller.signal })
      .then(res => res.json())
      .then(setData)
      .catch(setError)
      .finally(() => setLoading(false));

    return () => controller.abort();
  }, [url]);

  return { data, loading, error };
}

六、实际项目应用案例

6.1 场景一：表单管理（复杂表单）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

function useForm(initialValues) {
  const [values, setValues] = useState(initialValues);
  const [errors, setErrors] = useState({});

  const handleChange = useCallback((name) => (e) => {
    setValues(prev => ({ ...prev, [name]: e.target.value }));
  }, []);

  const validate = useCallback(() => {
    const newErrors = {};
    if (!values.email) newErrors.email = '必填';
    if (!values.password) newErrors.password = '必填';
    setErrors(newErrors);
    return Object.keys(newErrors).length === 0;
  }, [values]);

  const reset = useCallback(() => {
    setValues(initialValues);
    setErrors({});
  }, []);

  return { values, errors, handleChange, validate, reset };
}

// 登录表单
function LoginForm() {
  const { values, errors, handleChange, validate } = useForm({ email: '', password: '' });

  const onSubmit = (e) => {
    e.preventDefault();
    if (!validate()) return;
    login(values);
  };

  return (
    <form onSubmit={onSubmit}>
      <input value={values.email} onChange={handleChange('email')} />
      {errors.email && <span>{errors.email}</span>}
      <input type="password" value={values.password} onChange={handleChange('password')} />
      {errors.password && <span>{errors.password}</span>}
      <button type="submit">登录</button>
    </form>
  );
}

6.2 场景二：无限滚动列表

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

function useInfiniteScroll(callback, hasMore, loading) {
  const observerRef = useRef();
  const lastElementRef = useCallback(node => {
    if (loading) return;
    if (observerRef.current) observerRef.current.disconnect();
    observerRef.current = new IntersectionObserver(entries => {
      if (entries[0].isIntersecting && hasMore) {
        callback();
      }
    });
    if (node) observerRef.current.observe(node);
  }, [loading, hasMore, callback]);

  return lastElementRef;
}

function InfiniteList() {
  const [items, setItems] = useState([]);
  const [page, setPage] = useState(1);
  const [hasMore, setHasMore] = useState(true);
  const [loading, setLoading] = useState(false);

  const loadMore = useCallback(async () => {
    setLoading(true);
    const res = await fetchItems(page);
    setItems(prev => [...prev, ...res.data]);
    setHasMore(res.hasMore);
    setPage(p => p + 1);
    setLoading(false);
  }, [page]);

  const lastRef = useInfiniteScroll(loadMore, hasMore, loading);

  return (
    <ul>
      {items.map(item => <li key={item.id}>{item.name}</li>)}
      <li ref={lastRef} style={{ height: 1 }} />
    </ul>
  );
}

6.3 场景三：权限与路由守卫

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

function useAuth() {
  const [user, setUser] = useState(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    authApi.getCurrentUser()
      .then(setUser)
      .finally(() => setLoading(false));
  }, []);

  const hasPermission = useCallback((permission) => {
    return user?.permissions?.includes(permission);
  }, [user]);

  return { user, loading, hasPermission };
}

function ProtectedRoute({ permission, children }) {
  const { user, loading, hasPermission } = useAuth();

  if (loading) return <Spin />;
  if (!user) return <Navigate to="/login" />;
  if (permission && !hasPermission(permission)) return <Forbidden />;

  return children;
}

6.4 场景四：性能优化（虚拟列表 + useMemo）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

function VirtualList({ items, itemHeight }) {
  const [scrollTop, setScrollTop] = useState(0);
  const containerRef = useRef();

  const visibleRange = useMemo(() => {
    const start = Math.floor(scrollTop / itemHeight);
    const end = start + Math.ceil(containerRef.current?.clientHeight / itemHeight) + 2;
    return [Math.max(0, start), Math.min(items.length, end)];
  }, [scrollTop, itemHeight, items.length]);

  const visibleItems = useMemo(() => {
    const [start, end] = visibleRange;
    return items.slice(start, end).map((item, i) => ({
      ...item,
      index: start + i,
    }));
  }, [items, visibleRange]);

  return (
    <div
      ref={containerRef}
      onScroll={e => setScrollTop(e.target.scrollTop)}
      style={{ height: '100%', overflow: 'auto' }}
    >
      <div style={{ height: items.length * itemHeight, position: 'relative' }}>
        {visibleItems.map(item => (
          <div key={item.id} style={{ position: 'absolute', top: item.index * itemHeight }}>
            {item.content}
          </div>
        ))}
      </div>
    </div>
  );
}

七、常见陷阱与最佳实践

7.1 闭包陷阱

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

// ❌ 错误：setTimeout 中拿到的是旧 count
function Bad() {
  const [count, setCount] = useState(0);
  useEffect(() => {
    const id = setInterval(() => {
      setCount(count + 1); // count 永远是 0
    }, 1000);
    return () => clearInterval(id);
  }, []); // 缺少 count 依赖
}

// ✅ 正确：使用函数式更新
function Good() {
  const [count, setCount] = useState(0);
  useEffect(() => {
    const id = setInterval(() => {
      setCount(c => c + 1);
    }, 1000);
    return () => clearInterval(id);
  }, []);
}

7.2 依赖数组的完整性

• 建议使用 eslint-plugin-react-hooks 的 exhaustive-deps 规则
• 不要随意省略依赖，可能导致 stale closure

7.3 何时用 useCallback / useMemo

• 需要传递回调给 memo 子组件时用 useCallback
• 计算成本高且依赖稳定时用 useMemo
• 不要过度使用，有时重新创建的开销小于记忆化

八、总结

React Hooks 是现代 React 开发的核心，掌握其原理与最佳实践，能显著提升代码质量与开发效率。

参考资料

• React 官方文档 - Hooks
• React 源码 - ReactHooks.js
• A Complete Guide to useEffect

由浅入深，从四大组件、应用骨架到设计哲学与最佳实践，系统梳理 Android 核心组件体系与架构思想

一、基本概念

1.1 什么是 Android 核心组件？

Android 核心组件是系统提供的、用于构建应用的基本构建块。应用由多个组件组成，组件之间通过 Intent 和 Binder 等机制协作，由系统负责创建、调度和生命周期管理。

1
2
3
4
5
6
7
8
9
10
11
12
13

┌─────────────────────────────────────────────────────────────────────────┐
│                    Android 应用 = 组件的组合与协作                          │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                          │
│   四大组件                                                                 │
│   Activity / Service / BroadcastReceiver / ContentProvider               │
│         │                                                                 │
│         ▼                                                                 │
│   Intent（意图）──► 组件间通信、启动、数据传递                              │
│   Context（上下文）──► 访问资源、启动组件、获取系统服务                      │
│   Application ──► 进程级单例，应用全局状态与初始化                          │
│                                                                          │
└─────────────────────────────────────────────────────────────────────────┘

1.2 为什么是「组件化」？

Android 没有「一个 main 入口跑到底」的传统应用模型，而是采用 组件化 + 系统调度：

二、四大核心组件

2.1 Activity：界面与用户交互

Activity 代表一个「界面」或「屏幕」。用户看到的每一个全屏/窗口化界面，通常对应一个 Activity（或 Fragment 承载的视图）。

1
2
3
4
5
6
7
8
9
10
11
12

┌─────────────────────────────────────────────────────────────────────────┐
│  Activity 典型生命周期（简化）                                             │
│                                                                          │
│  创建 ──► onCreate() ──► onStart() ──► onResume() ──► 可见且可交互        │
│                                              │                           │
│                                              ▼                           │
│  切到后台 / 被遮挡  ──► onPause() ──► onStop()                            │
│                                              │                           │
│  再次回到前台  ──► onRestart() ──► onStart() ──► onResume()               │
│                                                                          │
│  销毁  ──► onDestroy()                                                    │
└─────────────────────────────────────────────────────────────────────────┘

• 与 Fragment 的关系：一个 Activity 可包含多个 Fragment，Fragment 是「界面片段」，用于在同一个 Activity 内做模块化 UI 与复用。

2.2 Service：后台任务与长期运行

Service 用于在「无界面」的情况下执行长时间运行的任务，或为其他组件提供后台能力（如播放音乐、下载、同步）。

• 生命周期：onCreate → onStartCommand（Started）或 onBind（Bound）→ 运行 → onUnbind / onDestroy。
• 前台服务：若需长时间在后台运行且不被系统轻易杀死，可调用 startForeground() 并显示持久通知，符合系统对「前台服务」的规范。

2.3 BroadcastReceiver：事件广播与响应

BroadcastReceiver 用于接收系统或应用发出的「广播」（如开机完成、网络变化、电量低、自定义事件），并做轻量级响应。

常见系统广播：ACTION_BOOT_COMPLETED、ACTION_BATTERY_LOW、CONNECTIVITY_ACTION 等。

2.4 ContentProvider：数据抽象与跨进程共享

ContentProvider 对数据提供统一的「增删改查」接口（类似小型数据库 API），并支持跨应用、跨进程访问，是 Android 中「数据共享」的标准方式。

系统示例：通讯录、媒体库、设置等，均通过 ContentProvider 暴露给其他应用。

三、支撑性核心：Intent、Context、Application

3.1 Intent：意图与组件间通信

Intent 表示「要做的一件事」或「要传递的一包信息」，用于启动 Activity/Service、发送广播，并携带数据与标志。

1
2

显式：我知道要启动谁 → setComponent / setClassName
隐式：我只描述「要做什么」→ setAction / addCategory / setData，系统找合适的组件

• Intent 可携带：Bundle 数据、Extra、Flags（如 FLAG_ACTIVITY_NEW_TASK、FLAG_ACTIVITY_SINGLE_TOP）等，是组件间解耦通信的载体。

3.2 Context：上下文与资源访问

Context 是「当前组件/应用所在环境」的抽象，提供：

• 访问应用资源（布局、字符串、drawable、主题等）
• 启动组件（startActivity、startService、sendBroadcast）
• 获取系统服务（getSystemService：如 LayoutInflater、ActivityManager、LocationManager）
• 访问应用专属目录与 SharedPreferences 等

注意：长时间持有 Activity 的 Context 容易导致内存泄漏（如静态变量引用 Activity），在异步回调中应避免；可改用 Application Context 或弱引用。

3.3 Application：应用级单例

Application 在进程启动时由系统创建，且每个进程只有一个实例。常用作：

• 应用级初始化（SDK、全局配置、数据库等）
• 全局单例或依赖注入容器的持有
• 实现 Application 级别的生命周期回调（如 onConfigurationChanged）

在 AndroidManifest.xml 中通过 <application android:name=".MyApplication"> 指定自定义子类。

四、核心设计思想

4.1 组件化与「应用即组件集合」

Android 不强调「一个程序从 main 开始跑」，而是强调：

• 应用由多个组件构成，每个组件有明确类型（Activity/Service/…）和声明（AndroidManifest）。
• 入口是「可被系统或其它应用调用的组件」：例如 LAUNCHER Activity、可被隐式 Intent 匹配的 Activity/Service。
• 组件之间通过 Intent 解耦：调用方只表达「意图」，不直接依赖实现类，便于复用与替换。

1
2
3
4
5
6
7
8
9
10
11
12

┌─────────────────────────────────────────────────────────────────────────┐
│  组件化思想：应用 = 组件 + 声明 + 意图驱动                                  │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                          │
│   AndroidManifest.xml 声明组件与 Intent-Filter                            │
│         │                                                                 │
│         ▼                                                                 │
│   系统 / 其他应用  ──► 发出 Intent  ──► 系统解析  ──► 创建并启动对应组件     │
│                                                                          │
│   同一「动作」可有多个实现（如多个浏览器），用户或系统选择其一               │
│                                                                          │
└─────────────────────────────────────────────────────────────────────────┘

4.2 生命周期由系统托管

组件的创建、暂停、恢复、销毁由 系统 根据用户行为、系统资源、配置变更（如旋转、多窗口、语言切换）统一调度：

• 开发者实现生命周期回调（如 Activity 的 onPause/onResume），在「合适的时机」保存状态、释放资源、恢复 UI。
• 系统可在内存紧张时回收后台组件；配置变更时销毁并重建 Activity，通过 onSaveInstanceState / ViewModel 等恢复状态。

这种设计把「何时创建/销毁」交给系统，应用只响应「已经发生」的生命周期事件，便于多任务与资源管理。

4.3 安全与权限模型

• 进程隔离：每个应用默认运行在独立进程，内存与执行空间隔离。
• 组件级权限：可在 AndroidManifest 中为 Activity/Service/ContentProvider 等声明 android:permission，调用方需具备相应权限才能启动或访问。
• 运行时权限：危险权限（如相机、位置、存储）需在运行时向用户申请，用户同意后应用才可使用。
• Intent 与导出：组件可设为 android:exported="true/false"，控制是否允许其他应用通过隐式 Intent 调起。

4.4 多任务与任务栈

• 任务（Task）：通常对应用户概念里的「一个应用的一组界面」，由一组 Activity 的栈组成。
• 启动模式：Activity 的 launchMode（standard、singleTop、singleTask、singleInstance）以及 Intent 的 Flags 共同决定「新 Activity 如何入栈、是否复用已有实例」，从而影响返回栈行为与多任务表现。

五、从设计思想到最佳实践

5.1 用 Intent 做解耦

• 应用内跳转：可用显式 Intent，也可用隐式 Intent + 自定义 action，便于后续替换实现或做 Deep Link。
• 跨应用能力：尽量用系统或公共的 action/data 约定（如 VIEW + http/https），或在自己的 Provider/Activity 上声明清晰的 intent-filter，便于被系统或其他应用发现和调起。

5.2 生命周期与状态保存

• 短时状态：在 onSaveInstanceState 中保存，在 onCreate/onRestoreInstanceState 中恢复。
• 界面相关数据：使用 ViewModel + LiveData/StateFlow，在配置变更时保留，避免在 Activity 里堆业务状态。
• 释放资源：在 onPause/onStop 中暂停耗时操作、释放监听与引用，在 onDestroy 中做最终清理，避免泄漏。

5.3 Service 与后台行为规范

• 短时任务：优先用 WorkManager 或 协程 + 应用前后台状态，避免长时间占住 Service。
• 需要长时间运行且用户可感知（如音乐播放、导航）：使用 前台 Service，并按规定显示通知。
• 避免在 BroadcastReceiver 中做重活：应启动 Service 或提交到 WorkManager。

5.4 架构分层与组件角色

• Activity/Fragment：只做 UI 与用户输入，将业务与数据交给 ViewModel 或 Presenter。
• ViewModel：持有界面状态与业务逻辑入口，不持有 Context/View，便于测试与复用。
• Repository / UseCase：封装数据来源（网络、本地、ContentProvider），对上层提供统一接口。
• ContentProvider：仅在需要「跨应用/跨进程共享数据」时使用；应用内本地数据可用 Room + DAO 等，不必强行上 Provider。

六、小结

理解「应用即组件的组合」「生命周期由系统托管」「Intent 表达意图、系统负责匹配与调度」，就能更好地把握 Android 核心组件与设计思想，并在此基础上用好 ViewModel、WorkManager、Jetpack 等现代组件与工具。

系统梳理 GoF 23 种设计模式，结合前端与 Node.js 实战代码，配 UML 类图与时序示意图辅助理解。

目录

1. 什么是设计模式
2. 创建型模式（5 种）
3. 结构型模式（7 种）
4. 行为型模式（11 种）
5. 速查总表

一、什么是设计模式

设计模式（Design Pattern） 是软件工程中反复出现问题的通用可复用解决方案。1994 年，Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides（即「四人组 GoF」）在《设计模式：可复用面向对象软件的基础》中总结了 23 种经典模式，按目的分为三类：

1
2
3

创建型（Creational）  ——  解决对象的创建问题
结构型（Structural）  ——  解决类/对象的组合问题
行为型（Behavioral）  ——  解决对象间职责与通信问题

设计原则（SOLID）

二、创建型模式（5 种）

2.1 单例模式（Singleton）

意图：保证一个类只有一个实例，并提供全局访问点。

场景：全局状态管理（Store）、日志记录器、配置管理。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

class Store {
  static #instance = null;

  #state = {};

  static getInstance() {
    if (!Store.#instance) {
      Store.#instance = new Store();
    }
    return Store.#instance;
  }

  getState() { return this.#state; }
  setState(patch) { Object.assign(this.#state, patch); }
}

const a = Store.getInstance();
const b = Store.getInstance();
console.log(a === b); // true

2.2 工厂方法模式（Factory Method）

意图：定义创建对象的接口，让子类决定实例化哪个类。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

class Button {
  render() { throw new Error('abstract'); }
}
class PrimaryButton extends Button {
  render() { return `<button class="btn-primary">OK</button>`; }
}
class DangerButton extends Button {
  render() { return `<button class="btn-danger">Delete</button>`; }
}

function createButton(type) {
  const map = { primary: PrimaryButton, danger: DangerButton };
  const Ctor = map[type];
  if (!Ctor) throw new Error(`Unknown type: ${type}`);
  return new Ctor();
}

createButton('primary').render(); // <button class="btn-primary">OK</button>

2.3 抽象工厂模式（Abstract Factory）

意图：提供一个接口，用于创建一系列相关或依赖对象，而不指定具体类。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

const lightFactory = {
  createButton: () => ({ type: 'button', theme: 'light' }),
  createInput:  () => ({ type: 'input',  theme: 'light' }),
};
const darkFactory = {
  createButton: () => ({ type: 'button', theme: 'dark' }),
  createInput:  () => ({ type: 'input',  theme: 'dark' }),
};

function buildUI(factory) {
  return {
    button: factory.createButton(),
    input:  factory.createInput(),
  };
}
buildUI(darkFactory); // { button: {theme:'dark'}, input: {theme:'dark'} }

2.4 建造者模式（Builder）

意图：将复杂对象的构造与表示分离，同一构建过程可创建不同表示。

场景：SQL 查询构建、配置对象构造、链式调用 API。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

class QueryBuilder {
  #table = '';
  #conditions = [];
  #fields = ['*'];
  #limit = null;

  from(table)     { this.#table = table; return this; }
  select(...f)    { this.#fields = f; return this; }
  where(cond)     { this.#conditions.push(cond); return this; }
  limit(n)        { this.#limit = n; return this; }

  build() {
    let sql = `SELECT ${this.#fields.join(', ')} FROM ${this.#table}`;
    if (this.#conditions.length) sql += ` WHERE ${this.#conditions.join(' AND ')}`;
    if (this.#limit !== null)    sql += ` LIMIT ${this.#limit}`;
    return sql;
  }
}

new QueryBuilder()
  .from('users')
  .select('id', 'name')
  .where('age > 18')
  .where('active = 1')
  .limit(10)
  .build();
// SELECT id, name FROM users WHERE age > 18 AND active = 1 LIMIT 10

2.5 原型模式（Prototype）

意图：通过复制（克隆）已有实例来创建新对象，而不是通过 new。

1
2
3
4
5
6
7
8
9
10
11
12
13

const userProto = {
  greet() { return `Hi, I'm ${this.name}`; },
  clone()  { return Object.create(this); },
};

const alice = Object.create(userProto);
alice.name = 'Alice';

const bob = alice.clone();
bob.name  = 'Bob';

alice.greet(); // Hi, I'm Alice
bob.greet();   // Hi, I'm Bob

三、结构型模式（7 种）

3.1 适配器模式（Adapter）

意图：将一个接口转换成调用方期望的另一个接口——解决不兼容问题。

场景：旧接口兼容、第三方 SDK 包装。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

// 旧日志库，接口为 log(msg)
class OldLogger {
  log(msg) { console.log('[OLD]', msg); }
}

// 新系统要求 info / warn / error 三个方法
class LoggerAdapter {
  constructor(logger) { this.logger = logger; }
  info(msg)  { this.logger.log(`INFO  ${msg}`); }
  warn(msg)  { this.logger.log(`WARN  ${msg}`); }
  error(msg) { this.logger.log(`ERROR ${msg}`); }
}

const logger = new LoggerAdapter(new OldLogger());
logger.info('server started'); // [OLD] INFO  server started

3.2 桥接模式（Bridge）

意图：将抽象部分与实现部分分离，使二者可以独立变化。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

// 实现部分：渲染引擎
const canvasRenderer = { draw: (shape) => `Canvas: draw ${shape}` };
const svgRenderer    = { draw: (shape) => `SVG:    draw ${shape}` };

// 抽象部分：形状
class Shape {
  constructor(renderer) { this.renderer = renderer; }
}
class Circle extends Shape {
  draw() { return this.renderer.draw('circle'); }
}
class Square extends Shape {
  draw() { return this.renderer.draw('square'); }
}

new Circle(svgRenderer).draw();    // SVG:    draw circle
new Square(canvasRenderer).draw(); // Canvas: draw square

3.3 组合模式（Composite）

意图：将对象组织成树形结构，使单个对象和组合对象的使用方式一致。

场景：文件系统、组件树、权限树。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

class File {
  constructor(name, size) { this.name = name; this.size = size; }
  getSize() { return this.size; }
}
class Folder {
  constructor(name) { this.name = name; this.children = []; }
  add(child) { this.children.push(child); return this; }
  getSize() { return this.children.reduce((s, c) => s + c.getSize(), 0); }
}

const root = new Folder('root')
  .add(new File('a.js', 10))
  .add(
    new Folder('src')
      .add(new File('index.js', 20))
      .add(new File('utils.js', 15))
  );

root.getSize(); // 45

3.4 装饰器模式（Decorator）

意图：在不改变原对象的前提下，动态地为其添加功能。

场景：中间件（Koa/Express）、日志增强、缓存包装。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

function withLogging(fn) {
  return function (...args) {
    console.log(`[CALL] ${fn.name}(${args})`);
    const result = fn.apply(this, args);
    console.log(`[RET]  ${result}`);
    return result;
  };
}

function add(a, b) { return a + b; }
const loggedAdd = withLogging(add);
loggedAdd(2, 3);
// [CALL] add(2,3)
// [RET]  5

3.5 外观模式（Facade）

意图：为子系统提供统一的高层接口，隐藏内部复杂性。

场景：SDK 封装、初始化流程统一入口。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

class AuthService   { login(u, p)    { return { token: 'tok_' + u }; } }
class ProfileService { fetch(token)  { return { name: 'Alice' }; } }
class LogService    { record(action) { console.log('[LOG]', action); } }

class AppFacade {
  #auth    = new AuthService();
  #profile = new ProfileService();
  #log     = new LogService();

  async signIn(username, password) {
    const { token } = this.#auth.login(username, password);
    const profile   = this.#profile.fetch(token);
    this.#log.record(`login:${username}`);
    return { token, profile };
  }
}

new AppFacade().signIn('alice', 'pw');

3.6 享元模式（Flyweight）

意图：共享细粒度对象以节省内存，将对象内在状态与外在状态分离。

场景：字符渲染、粒子系统、大量相似节点池。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

class CharStyle {
  constructor(font, size, color) {
    this.font = font; this.size = size; this.color = color;
  }
}

class CharStylePool {
  #pool = new Map();
  get(font, size, color) {
    const key = `${font}-${size}-${color}`;
    if (!this.#pool.has(key)) this.#pool.set(key, new CharStyle(font, size, color));
    return this.#pool.get(key);
  }
  size() { return this.#pool.size; }
}

const pool = new CharStylePool();
// 渲染 1000 个字符，只需要极少的 CharStyle 对象
const chars = Array.from('Hello World x1000').map(ch => ({
  char: ch,
  style: pool.get('Arial', 14, '#333'),
}));
console.log(pool.size()); // 1（所有字符共享同一样式对象）

3.7 代理模式（Proxy）

意图：为另一个对象提供代理以控制对它的访问。

场景：懒加载、权限控制、缓存、数据校验（ES Proxy）。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

function createValidator(target, rules) {
  return new Proxy(target, {
    set(obj, prop, value) {
      if (rules[prop] && !rules[prop](value)) {
        throw new TypeError(`Invalid value for "${prop}": ${value}`);
      }
      obj[prop] = value;
      return true;
    },
  });
}

const user = createValidator({}, {
  age:   v => typeof v === 'number' && v >= 0 && v <= 150,
  email: v => /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(v),
});

user.age   = 25;             // OK
user.email = 'a@b.com';     // OK
// user.age = -1;            // TypeError: Invalid value for "age": -1

四、行为型模式（11 种）

4.1 责任链模式（Chain of Responsibility）

意图：将请求沿着处理者链传递，直到某个处理者处理它为止。

场景：中间件管道（Koa）、审批流程、事件冒泡。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

class Handler {
  setNext(handler) { this.next = handler; return handler; }
  handle(req)      { return this.next?.handle(req); }
}

class AuthHandler extends Handler {
  handle(req) {
    if (!req.token) return '401 Unauthorized';
    return super.handle(req);
  }
}
class RoleHandler extends Handler {
  handle(req) {
    if (req.role !== 'admin') return '403 Forbidden';
    return super.handle(req);
  }
}
class BusinessHandler extends Handler {
  handle(req) { return `200 OK: Hello ${req.user}`; }
}

const chain = new AuthHandler();
chain.setNext(new RoleHandler()).setNext(new BusinessHandler());

chain.handle({ token: 'tok', role: 'admin', user: 'Alice' }); // 200 OK
chain.handle({ token: 'tok', role: 'guest' });                 // 403 Forbidden
chain.handle({});                                              // 401 Unauthorized

4.2 命令模式（Command）

意图：将操作封装为对象，支持撤销、重做、队列调度。

场景：编辑器操作历史、任务队列、宏录制。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

class TextEditor {
  #text = '';
  #history = [];

  execute(command) {
    this.#text = command.execute(this.#text);
    this.#history.push(command);
    return this;
  }
  undo() {
    const cmd = this.#history.pop();
    if (cmd) this.#text = cmd.undo(this.#text);
    return this;
  }
  value() { return this.#text; }
}

const appendCmd = (str) => ({
  execute: (t) => t + str,
  undo:    (t) => t.slice(0, -str.length),
});

const ed = new TextEditor();
ed.execute(appendCmd('Hello')).execute(appendCmd(', World'));
ed.value(); // Hello, World
ed.undo();
ed.value(); // Hello

4.3 解释器模式（Interpreter）

意图：为语言定义文法，并实现解释器来解释该语言的句子。

场景：模板引擎、DSL 解析、规则引擎。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16