Neo 建立鸿蒙应用：实战社交应用与工程感悟

前两篇讲完了架构和机制。这一篇换个角度——不谈概念，只看代码。用一个模拟 Soul 业务场景的社交应用完整实现。验证框架在真实项目中的表现，最终分享一些工程实践中的感悟。

示例项目这方面。EchoApp

EchoApp 是 Neo 仓库中的示例项目，模拟一款社交应用的主要功能：聊天、广场动态、匹配、使用者资料等。不是 demo 级别的 HelloWorld。而是有意按照中型项目的体量来组织代码：

选择这个体量是有原因的——太少了看不出分层的价值，太多了读起来成本太高。个 Service 恰好在"能看清楚全貌"和"有足够的复杂度"之间。

从基础开始的观点是，AppModule 的设计思路

AppModule 是整个应用的起点，所有 个 Service 在这里统一声明：

export const appModule = new NeoModule — infra services ===== { tag: 'AppInitService',phase: GLOBAL_PHASE,factory: => new AppInitService },{ tag: 'SecurityService',phase: GLOBAL_PHASE,factory: => new SecurityService,dependencies: },{ tag: 'DatabaseService',phase: GLOBAL_PHASE,factory: => new DatabaseService,dependencies: },{ tag: 'NetworkService',phase: GLOBAL_PHASE,factory: => new NetworkService,dependencies: },{ tag: 'CacheService',phase: GLOBAL_PHASE,factory: => new CacheService },{ tag: 'StorageService',phase: GLOBAL_PHASE。factory: => new StorageService,dependencies: },// ... // ===== BUSINESS_PHASE — business services ===== { tag: 'AuthService',phase: BUSINESS_PHASE,factory: => new AuthService,dependencies: },{ tag: 'UserService',phase: BUSINESS_PHASE,factory: => new UserService,dependencies: },{ tag: 'IMService',phase: BUSINESS_PHASE,factory: => new IMService,dependencies: },{ tag: 'MomentService',phase: BUSINESS_PHASE,factory: => new MomentService,dependencies: },{ tag: 'MatchService',phase: BUSINESS_PHASE,factory: => new MatchService,dependencies: )

设计这个文件时的思考

. 分层的判断标准

哪些 Service 放 infra、哪些放 business，不是拍脑袋决定的。再看判断标准，

• infra无业务状态。换一个应用也能用，Network ervice、Cache ervice、Database 概念
• business 至于**。有业务状态，和具体应用绑定。Auth ervice 知道 token，IM ervice 知道消息。Moment ervice 知道动态
• **feature**：锦上添花，应用没有它们也能跑。earch ervice、 nalytics ervice
• **lazy**：使用者可能永远不会用到的功能。Game ervice、 tory ervice

** . 依赖的方向 **

依赖关系一定是单向的： infra ← business ← feature ← lazy。不会出现 IM ervice 依赖 earch ervice 的情况。这不是框架强制的，而是分层的自然结果——你不会在业务层引用一个功能层的服务。因为业务层在它之前就加载了。说起来，

. Phase 的调整是启动调整的主要手段

假设启动速度不达标，调整思路不是去改 Service 内部代码，而是调整 Phase 从归属来看。

• Match

ervice 从 BUSINES

降到 FEATURE？匹配结果不在首屏展示，可以先显示骨架屏

降到 FEATURE？表情面板不是默认展开的

阶段就少一个串行等待的 Service。使用者更快看到首页

这种调整不需要改任何业务代码，只改 AppModule 中的 phase 字段。

一个完整的数据流：发送消息

以聊天功能为例，走一遍从使用者操作到 UI 刷新的全链路。

页面层

// ChatPage.ets@Entry@Componentstruct ChatPage {
@State messages:
ChatMessage =
@State inputText:
string = ''
private imSvc?:
IM
ervice
private unbind:
=> void) | undefined
private conversationId:
string = ''
aboutToAppear {
const params =
router.getParams as ChatPageParams
this.conversationId =
params.conversationId
this.imSvc =
serviceManager.get('IM
ervice')!this.unbind =
StateBinder.bind(
this.imSvc.getMessagesObservable。this as Object,'messages'
)
this.loadMessages
}
aboutToDisappear {
this.unbind?.
}
async loadMessages {
if {
this.messages =
await this.imSvc.getMessages
await this.imSvc.markAsRead
}
}
// 使用者点击发送
async onSend {
if ) {
await this.imSvc.sendMessage(this.conversationId。this.inputText.trim)
this.inputText = ''
}
}
build {
Column {
List {
ForEach(this.messages,(msg:
ChatMessage) => {
ListItem {
//
渲染消息气泡
}
})
}
// 输入框 + 发送按钮
}
}}

页面做的事情很薄： 绑定 Observable、调用 Service 方法、渲染 UI。没有网络请求、没有状态管理、没有回调地狱。

业务层

// IM
ervice.ets export class IM
ervice extends
ervice {
private conversationsObs =
new Observable
private messagesObs =
new Observable
getMessagesObservable {
return this.messagesObs }
async sendMessage(conversationId:
string,content:
string):
Promise{
// .
业务逻辑的观点是。创建消息
const msg =
this.createMessage(conversationId,content)
// . 网络：
发送到服务器
await this.networkSvc.send('/im/send',msg)
// . 更新 Observable → 自动通知所有绑定的页面
const msgs =
this.messagesObs.getValue
this.messagesObs.setValue()
// . 发送事件 → 其他 Service 可以响应
eventBus.emit('im:messageSent',{ conversationId,message:
msg } as Object)
return msg
}}

业务层做的事情： 页面在用自己，也不知道 UI 长什么样。

基础设施层

// Network
ervice.ets export class Network
ervice extends
ervice {
async send(path:
string,data:
Object):
Promise