别再把功能写死在页面里了

聊聊鸿蒙的 Service Center，到底解决了什么问题？

一、引子：你有没有被“页面驱动开发”折磨过？

我先问你一个问题，这个场景你熟不熟：

• 一个功能，写在 A 页面

• 另一个页面也要用

• Service 想复用

• 最后发现逻辑散落在：

  • Page
  • Ability
  • 各种 util 里

结果就是：

页面一多，逻辑就开始“串味”；
改一个需求，牵一堆页面。

我刚接触鸿蒙的时候，也下意识沿用了 Android / Web 那套：

“页面就是一切”

直到我真正开始用 Service Center，才意识到一句话：

鸿蒙其实在逼你，把“能力”从“界面”里拔出来。

二、Service Center 是什么？一句话说人话版

官方定义你肯定看过，我换一种说法：

Service Center 是鸿蒙里一个“官方认可的能力中台”。

它不是页面
不是组件
也不是工具类

而是一个：

👉 统一注册
👉 统一发现
👉 统一调用
👉 与 UI 解耦的服务能力体系

换个更接地气的比喻：

页面是“前台”，
Service Center 是“后台窗口”。

三、原理讲解：它到底是怎么工作的？

我们别从接口开始，先从设计思想说。

1️⃣ 核心思想只有一个

“谁提供能力不重要，谁使用能力也不重要。”

只要：

• 服务注册到 Service Center
• 调用方通过 Service Center 获取

两边就彻底解耦。

2️⃣ Service Center 的三大角色

你可以理解成：

能力的“电话簿 + 调度台”

四、实战代码：我们来写一个“真正像服务”的服务

下面我用一个非常常见、但特别适合 Service Center 的例子：

统一用户信息服务

1️⃣ 定义服务接口（重点）

// UserService.ts
export interface UserService {
  getUserInfo(): Promise<UserInfo>
  isLogin(): boolean
}

注意这个点：
这里只有“能力描述”，没有实现。

2️⃣ 实现服务并注册到 Service Center

// UserServiceImpl.ts
import { UserService } from './UserService'

export class UserServiceImpl implements UserService {
  getUserInfo(): Promise<UserInfo> {
    return Promise.resolve({
      uid: '10086',
      name: 'Echo_Wish'
    })
  }

  isLogin(): boolean {
    return true
  }
}

注册：

// ServiceRegister.ts
import serviceCenter from '@ohos.serviceCenter'
import { UserServiceImpl } from './UserServiceImpl'

serviceCenter.registerService('UserService', new UserServiceImpl())

3️⃣ 页面侧使用（重点来了）

// AnyPage.ets
import serviceCenter from '@ohos.serviceCenter'
import { UserService } from '../service/UserService'

const userService = serviceCenter.getService<UserService>('UserService')

userService.getUserInfo().then(user => {
  console.log(user.name)
})

你发现没有？

👉 页面 完全不知道：

• 服务怎么实现
• 数据从哪来
• 将来是否换实现

五、场景应用：什么时候你一定要用 Service Center？

我直接给你几个强烈推荐场景。

场景一：多页面复用的核心能力

比如：

• 用户体系
• 账号登录
• 权限判断
• 配置管理

❌ 页面 copy
✅ Service Center

场景二：多设备 / 多形态适配

手机、平板、车机、穿戴……

if (deviceType === 'car') {
  return CarUserServiceImpl()
}

对页面来说：

服务没变，设备换了而已。

场景三：为“将来拆模块”留后路

今天你是单工程
明天你就是多 HAP、多模块

Service Center 本质上是在帮你提前“服务化”。

六、Echo_Wish 式思考：为什么我特别看好这个机制？

说点不那么“官方”的。

1️⃣ Service Center 其实在“逼你写好代码”

• 强制接口
• 强制抽象
• 强制解耦

你要是逻辑混乱，第一步注册就会卡住你。

2️⃣ 它是鸿蒙“分布式能力”的地基之一

未来你会发现：

• 本地服务
• 远端服务
• 跨设备服务

调用方式会越来越像。

你现在用的是 Service Center，
以后用的可能是 跨设备 Service Center。

3️⃣ 写鸿蒙，不该再是“页面驱动”

我现在越来越明确一个观点：

鸿蒙真正的竞争力，不是 UI，而是“能力组织方式”。

Service Center 就是其中一个非常重要、但容易被忽视的积木。

七、结尾一句掏心窝子的

如果你现在写鸿蒙，还在纠结：

“这个逻辑到底放 Page 里，还是 Ability 里？”

那我建议你停一下，换个问题：

“这是不是一个‘服务级能力’？”

只要答案是“是”，
那它大概率就该进 Service Center。