当前位置：首页 > news >正文

Neo 构建鸿蒙应用【三】：实战社交应用与工程感悟

news 2026/5/4 16:21:12

Neo 构建鸿蒙应用【三】：实战社交应用与工程感悟

Neo 框架连载（终篇）· AI 辅助撰写

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

示例项目：EchoApp

EchoApp 是 Neo 仓库中的示例项目（examples/soul-app），模拟一款社交应用的核心功能：聊天、广场动态、匹配、用户资料等。不是 demo 级别的 HelloWorld，而是有意按照中型项目的体量来组织代码：

维度	数量
Service 总数	27
infra 层	8
business 层	12
feature 层	5
lazy 层	2
页面	10
组件	40+

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

从零开始：AppModule 的设计思路

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

exportconstappModule=newNeoModule('EchoApp',[// ===== GLOBAL_PHASE (serial, p10) — 8 infra services ====={tag:'AppInitService',phase:GLOBAL_PHASE,factory:()=>newAppInitService()},{tag:'SecurityService',phase:GLOBAL_PHASE,factory:()=>newSecurityService(),dependencies:['AppInitService']},{tag:'DatabaseService',phase:GLOBAL_PHASE,factory:()=>newDatabaseService(),dependencies:['AppInitService']},{tag:'NetworkService',phase:GLOBAL_PHASE,factory:()=>newNetworkService(),dependencies:['AppInitService','SecurityService']},{tag:'CacheService',phase:GLOBAL_PHASE,factory:()=>newCacheService()},{tag:'StorageService',phase:GLOBAL_PHASE,factory:()=>newStorageService(),dependencies:['AppInitService']},// ...// ===== BUSINESS_PHASE (serial, p20) — 12 business services ====={tag:'AuthService',phase:BUSINESS_PHASE,factory:()=>newAuthService(),dependencies:['NetworkService','SecurityService','StorageService']},{tag:'UserService',phase:BUSINESS_PHASE,factory:()=>newUserService(),dependencies:['AuthService','DatabaseService']},{tag:'IMService',phase:BUSINESS_PHASE,factory:()=>newIMService(),dependencies:['AuthService','NetworkService','DatabaseService']},{tag:'MomentService',phase:BUSINESS_PHASE,factory:()=>newMomentService(),dependencies:['AuthService','NetworkService','CacheService']},{tag:'MatchService',phase:BUSINESS_PHASE,factory:()=>newMatchService(),dependencies:['AuthService','NetworkService','CacheService']},// ...// ===== FEATURE_PHASE (parallel, p30) — 5 feature services ====={tag:'SearchService',phase:FEATURE_PHASE,factory:()=>newSearchService(),dependencies:['NetworkService','CacheService']},{tag:'AnalyticsService',phase:FEATURE_PHASE,factory:()=>newAnalyticsService()},// ...// ===== LAZY_PHASE (parallel, p40) — 2 lazy services ====={tag:'GameService',phase:LAZY_PHASE,factory:()=>newGameService(),dependencies:['MatchService','IMService']},{tag:'StoryService',phase:LAZY_PHASE,factory:()=>newStoryService(),dependencies:['AuthService','NetworkService','MediaService']},])

设计这个文件时的思考

1. 分层的判断标准

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

infra：无业务状态，换一个应用也能用。NetworkService、CacheService、DatabaseService——它们不知道"用户"是什么概念
business：有业务状态，和具体应用绑定。AuthService 知道 token，IMService 知道消息，MomentService 知道动态
feature：锦上添花，应用没有它们也能跑。SearchService、AnalyticsService
lazy：用户可能永远不会用到的功能。GameService、StoryService

2. 依赖的方向

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

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

假设启动速度不达标，优化思路不是去改 Service 内部代码，而是调整 Phase 归属：

MatchService 从 BUSINESS 降到 FEATURE？匹配结果不在首屏展示，可以先显示骨架屏
EmojiService 从 BUSINESS 降到 FEATURE？表情面板不是默认展开的
每降一个，BUSINESS 阶段就少一个串行等待的 Service，用户更快看到首页

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

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

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

页面层（features）

// ChatPage.ets@Entry@Componentstruct ChatPage{@Statemessages:ChatMessage[]=[]@StateinputText:string=''privateimSvc?:IMServiceprivateunbind:(()=>void)|undefinedprivateconversationId:string=''aboutToAppear(){constparams=router.getParams()asChatPageParamsthis.conversationId=params.conversationIdthis.imSvc=serviceManager.get<IMService>('IMService')!this.unbind=StateBinder.bind<ChatMessage[]>(this.imSvc.getMessagesObservable(),thisasObject,'messages')this.loadMessages()}aboutToDisappear(){this.unbind?.()}asyncloadMessages(){if(this.imSvc&&this.conversationId){this.messages=awaitthis.imSvc.getMessages(this.conversationId)awaitthis.imSvc.markAsRead(this.conversationId)}}// 用户点击发送asynconSend(){if(this.imSvc&&this.inputText.trim()){awaitthis.imSvc.sendMessage(this.conversationId,this.inputText.trim())this.inputText=''}}build(){Column(){List(){ForEach(this.messages,(msg:ChatMessage)=>{ListItem(){// 渲染消息气泡}})}// 输入框 + 发送按钮}}}

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

业务层（domains）

// IMService.etsexportclassIMServiceextendsService{privateconversationsObs=newObservable<Conversation[]>([])privatemessagesObs=newObservable<ChatMessage[]>([])getMessagesObservable(){returnthis.messagesObs}asyncsendMessage(conversationId:string,content:string):Promise<ChatMessage>{// 1. 业务逻辑：创建消息constmsg=this.createMessage(conversationId,content)// 2. 网络：发送到服务器awaitthis.networkSvc.send('/im/send',msg)// 3. 更新 Observable → 自动通知所有绑定的页面constmsgs=this.messagesObs.getValue()this.messagesObs.setValue([...msgs,msg])// 4. 发送事件 → 其他 Service 可以响应eventBus.emit('im:messageSent',{conversationId,message:msg}asObject)returnmsg}}

业务层做的事情：处理业务逻辑、协调基础设施、更新 Observable、发送事件。它不知道有哪些页面在用自己，也不知道 UI 长什么样。

基础设施层（infra）

// NetworkService.etsexportclassNetworkServiceextendsService{asyncsend(path:string,data:Object):Promise<Object>{// 纯技术实现：HTTP 请求、重试、超时// 不知道"消息"是什么，只知道 path 和 data}}

基础设施层做的事情：纯技术实现。不知道业务概念，不知道 UI，甚至不知道自己在被谁调用。

完整链路

用户点击发送（ChatPage.onSend） → imSvc.sendMessage(convId, '你好') // 页面调 Service → 创建消息对象 // 业务逻辑 → networkSvc.send('/im/send', msg) // 调基础设施 → messagesObs.setValue([...msgs, msg]) // 更新 Observable → StateBinder 自动写入 @State messages // 数据驱动 UI → ArkUI 重新渲染消息列表 // 用户看到新消息 → eventBus.emit('im:messageSent') // 通知其他 Service

页面不需要手动this.messages = newMessages，不需要this.$setState()，不需要notifyDataSetChanged()。Service 调了setValue，UI 自动刷新。

新增一个功能要改几个文件

假设产品要求新增一个"举报"功能。需要改哪些文件？

1. 定义 Service—services/feature/ReportService.ets（新建）

exportclassReportServiceextendsService{asyncreport(targetId:string,reason:string):Promise<boolean>{constnetwork=this.depServices.find(s=>s.tag==='NetworkService')asNetworkServiceawaitnetwork.send('/report',{targetId,reason}asObject)returntrue}}

2. 注册到 AppModule—modules/AppModule.ets（加一行）

{tag:'ReportService',phase:FEATURE_PHASE,factory:()=>newReportService(),dependencies:['NetworkService']},

3. 页面使用— 在需要举报的页面中

constreportSvc=serviceManager.get<ReportService>('ReportService')!awaitreportSvc.report(targetId,'不适当内容')

三个文件，零耦合。不需要修改 NetworkService、不需要修改任何基类、不需要在某个全局注册表里手动添加。定义 → 注册 → 使用，流程是固定的。

工程感悟

框架是团队契约，不是技术炫耀

我说这么多有的没的，核心就一件事：如果存在一种共同约束，不是特别完美，但也不特别烂，就能产生一些价值。

精准高效沟通是特例，低效沟通是常态；层次分明是特例，层次渗透是常态；需求稳定是特例，经常变更是常态。Neo 提供的不是理想架构，而是一个团队可以共同遵守的底线。所有人定义 Service 的时候知道 init 不能做 IO，声明依赖的时候知道要看 AppModule，写页面的时候知道通过 Observable 拿数据。

这种共同约束的收益不是立竿见影的，而是在项目三个月、六个月、一年后——当新功能还在源源不断地加进来，而代码还能看懂、还能改、还能测试的时候——才会体现。