Neo 构建鸿蒙应用【三】实战社交应用与工程感悟Neo 框架连载终篇· AI 辅助撰写前两篇讲完了架构和机制。这一篇换个角度——不谈概念只看代码。用一个模拟 Soul 业务场景的社交应用完整实现验证框架在真实项目中的表现最后分享一些工程实践中的感悟。示例项目EchoAppEchoApp 是 Neo 仓库中的示例项目examples/soul-app模拟一款社交应用的核心功能聊天、广场动态、匹配、用户资料等。不是 demo 级别的 HelloWorld而是有意按照中型项目的体量来组织代码维度数量Service 总数27infra 层8business 层12feature 层5lazy 层2页面10组件40选择这个体量是有原因的——太少了看不出分层的价值太多了读起来成本太高。27 个 Service 恰好在能看清楚全貌和有足够的复杂度之间。从零开始AppModule 的设计思路AppModule 是整个应用的起点所有 27 个 Service 在这里统一声明exportconstappModulenewNeoModule(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 知道 tokenIMService 知道消息MomentService 知道动态feature锦上添花应用没有它们也能跑。SearchService、AnalyticsServicelazy用户可能永远不会用到的功能。GameService、StoryService2. 依赖的方向依赖关系一定是单向的infra ← business ← feature ← lazy。不会出现 IMService 依赖 SearchService 的情况。这不是框架强制的而是分层的自然结果——你不会在业务层引用一个功能层的服务因为业务层在它之前就加载了。3. Phase 的调整是启动优化的主要手段假设启动速度不达标优化思路不是去改 Service 内部代码而是调整 Phase 归属MatchService 从 BUSINESS 降到 FEATURE匹配结果不在首屏展示可以先显示骨架屏EmojiService 从 BUSINESS 降到 FEATURE表情面板不是默认展开的每降一个BUSINESS 阶段就少一个串行等待的 Service用户更快看到首页这种优化不需要改任何业务代码只改 AppModule 中的phase字段。一个完整的数据流发送消息以聊天功能为例走一遍从用户操作到 UI 刷新的全链路。页面层features// ChatPage.etsEntryComponentstruct ChatPage{Statemessages:ChatMessage[][]StateinputText:stringprivateimSvc?:IMServiceprivateunbind:(()void)|undefinedprivateconversationId:stringaboutToAppear(){constparamsrouter.getParams()asChatPageParamsthis.conversationIdparams.conversationIdthis.imSvcserviceManager.getIMService(IMService)!this.unbindStateBinder.bindChatMessage[](this.imSvc.getMessagesObservable(),thisasObject,messages)this.loadMessages()}aboutToDisappear(){this.unbind?.()}asyncloadMessages(){if(this.imSvcthis.conversationId){this.messagesawaitthis.imSvc.getMessages(this.conversationId)awaitthis.imSvc.markAsRead(this.conversationId)}}// 用户点击发送asynconSend(){if(this.imSvcthis.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{privateconversationsObsnewObservableConversation[]([])privatemessagesObsnewObservableChatMessage[]([])getMessagesObservable(){returnthis.messagesObs}asyncsendMessage(conversationId:string,content:string):PromiseChatMessage{// 1. 业务逻辑创建消息constmsgthis.createMessage(conversationId,content)// 2. 网络发送到服务器awaitthis.networkSvc.send(/im/send,msg)// 3. 更新 Observable → 自动通知所有绑定的页面constmsgsthis.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):PromiseObject{// 纯技术实现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 调了setValueUI 自动刷新。新增一个功能要改几个文件假设产品要求新增一个举报功能。需要改哪些文件1. 定义 Service—services/feature/ReportService.ets新建exportclassReportServiceextendsService{asyncreport(targetId:string,reason:string):Promiseboolean{constnetworkthis.depServices.find(ss.tagNetworkService)asNetworkServiceawaitnetwork.send(/report,{targetId,reason}asObject)returntrue}}2. 注册到 AppModule—modules/AppModule.ets加一行{tag:ReportService,phase:FEATURE_PHASE,factory:()newReportService(),dependencies:[NetworkService]},3. 页面使用— 在需要举报的页面中constreportSvcserviceManager.getReportService(ReportService)!awaitreportSvc.report(targetId,不适当内容)三个文件零耦合。不需要修改 NetworkService、不需要修改任何基类、不需要在某个全局注册表里手动添加。定义 → 注册 → 使用流程是固定的。工程感悟框架是团队契约不是技术炫耀我说这么多有的没的核心就一件事如果存在一种共同约束不是特别完美但也不特别烂就能产生一些价值。精准高效沟通是特例低效沟通是常态层次分明是特例层次渗透是常态需求稳定是特例经常变更是常态。Neo 提供的不是理想架构而是一个团队可以共同遵守的底线。所有人定义 Service 的时候知道 init 不能做 IO声明依赖的时候知道要看 AppModule写页面的时候知道通过 Observable 拿数据。这种共同约束的收益不是立竿见影的而是在项目三个月、六个月、一年后——当新功能还在源源不断地加进来而代码还能看懂、还能改、还能测试的时候——才会体现。ArkTS 的限制反而帮了忙ArkTS 比 TypeScript 严格很多不能用any、不能用Record的动态访问、不能省略泛型、不能 spread 对象。这些限制在初期让人头疼但回头看它们迫使你写出更明确的代码没有any→ 每个变量都有类型 → Service 的接口必须定义清楚不能动态访问属性 → 必须用接口声明router.getParams()的返回值 → 页面参数有文档必须显式泛型 →StateBinder.bindT()一眼就知道绑的是什么类型这些限制和 Neo 的设计理念是契合的——约束带来清晰。结构化不是炫技尤其在近两年 AI 编程越来越成熟的背景下炫技显得越来越廉价。结构化的目的是让代码可维护、可测试、可交接而不是展示设计模式的熟练度。AI 时代的工程节奏Neo 本身就是 AI 辅助开发的产物。我的判断是AI 生成产品的速度太快了把 IDEA 尽可能快地做出来远比人工打磨细节的 ROI 高。本系列文章也是这个思路——核心观点和设计决策是人定的文字落地是 AI 做的。与其花一周打磨一篇完美的技术文章不如一天发三篇把思路讲清楚把省下来的时间投入到下一个功能、下一个项目中。写在最后软件是有固有生命周期的公司和团队也有生命周期。在经济上行期软件行业的迭代都非常快很多软件在没达到最大容积之前公司和团队的生命周期已走到最终阶段。这不是悲观——恰恰是因为时间有限才更需要一个好的结构约束。让代码在你还在的时候能跑在你走了之后别人也能接。Neo 不追求成为最好的框架只追求成为一个不太烂的共同约束。如果这篇文章对你有一点启发去 GitHub 看看源码跑一下 EchoApp 示例。觉得有用就点个 Star有问题就提 Issue。共勉。系列文章一种通用中小型基于ArkTS的鸿蒙应用开发框架华为开发者联盟Neo 构建鸿蒙应用【一】架构困境与四层结构化设计Neo 构建鸿蒙应用【二】技术路线全解Neo 构建鸿蒙应用【三】实战社交应用与工程感悟本文