手机 App 跨平台框架统一目录构建你希望构建一个同时支持Android安卓、iOS苹果、HarmonyOS鸿蒙三平台的手机App项目核心需求是目录结构清晰、跨平台代码复用率高、各平台原生特性不被束缚、后期维护便捷。首先要明确三平台适配有两种核心思路「跨平台框架统一目录推荐复用率高」和「原生项目分离目录小众原生体验极致」其中跨平台框架是绝大多数团队的选择避免重复开发下面分别详细讲解。一、 推荐方案基于跨平台框架的项目目录结构优先选择目前成熟的跨平台框架中FlutterGoogle、React NativeMeta、UniAppDCloud基于Vue都能良好支持Android、iOS、鸿蒙三平台其中Flutter对鸿蒙的适配最成熟UniApp上手门槛最低适合前端开发者。这类方案的核心思想是「一次编写多端复用」公共业务逻辑、UI组件、数据处理等核心代码放在统一目录各平台原生相关代码如原生插件、权限配置、启动页放在对应平台专属目录目录结构具有高度一致性和可维护性。1. 标杆示例Flutter 项目目录结构支持三平台复用率80%-95%Flutter是跨平台框架中性能最接近原生的对Android、iOS的支持是原生级对鸿蒙HarmonyOS Next/OpenHarmony通过官方插件/适配层实现完美支持目录结构规范且行业通用。your_flutter_app/ # 项目根目录 ├── .dart_tool/ # Flutter工具生成的缓存文件无需手动修改 ├── .gitignore/ # Git版本控制忽略文件 ├── android/ # Android 平台专属目录原生代码、配置 │ ├── app/ # 核心模块 │ │ ├── src/ │ │ │ ├── main/ │ │ │ │ ├── java/com/yourcompany/yourapp/ # Android原生代码Kotlin/Java │ │ │ │ ├── res/ # Android资源文件布局、图片、字符串、样式 │ │ │ │ ├── AndroidManifest.xml # Android清单权限、启动页、组件配置 │ │ │ │ └── assets/ # Android本地静态资源 │ │ │ └── test/ # Android单元测试 │ │ └── build.gradle # Android模块构建配置 │ ├── build.gradle # Android项目全局构建配置 │ └── settings.gradle # Android项目模块配置 ├── ios/ # iOS 平台专属目录原生代码、配置 │ ├── Runner/ # 核心工程 │ │ ├── Assets.xcassets/ # iOS图片资源启动图、应用图标 │ │ ├── Classes/ # iOS原生代码Swift/Objective-C │ │ ├── Info.plist # iOS配置文件权限、版本、启动配置 │ │ └── Base.lproj/ # iOS界面布局如需原生UI │ ├── Runner.xcodeproj # Xcode项目文件 │ └── Runner.xcworkspace # Xcode工作空间文件 ├── harmony/ # 鸿蒙HarmonyOS平台专属目录原生代码、配置Flutter 3.10支持 │ ├── entry/ # 鸿蒙核心应用模块 │ │ ├── src/main/ │ │ │ ├── ets/ # 鸿蒙ETS语言代码UI、原生逻辑 │ │ │ ├── resources/ # 鸿蒙资源文件图片、字符串、布局 │ │ │ └── config.json # 鸿蒙模块配置权限、页面路由 │ │ └── build.gradle # 鸿蒙模块构建配置 │ ├── oh-package.json5 # 鸿蒙项目依赖配置 │ └── build.gradle # 鸿蒙项目全局构建配置 ├── lib/ # Flutter 跨平台核心目录三平台复用核心代码存放处 │ ├── api/ # 网络请求封装接口调用、拦截器、数据解析 │ ├── common/ # 公共工具类常量、工具函数、扩展方法、全局配置 │ │ ├── constants.dart # 全局常量接口地址、缓存key、权限常量 │ │ ├── utils.dart # 工具函数日期格式化、加密、数据转换 │ │ └── extensions.dart # 扩展方法String、int等类的扩展 │ ├── models/ # 数据模型实体类对应接口返回数据、本地缓存数据 │ │ ├── user_model.dart # 示例用户数据模型 │ │ └── order_model.dart # 示例订单数据模型 │ ├── pages/ # 业务页面三平台复用的UI页面按业务模块划分 │ │ ├── home/ # 首页模块 │ │ │ ├── home_page.dart # 首页UI │ │ │ └── home_view_model.dart # 首页业务逻辑MVVM模式 │ │ ├── mine/ # 我的模块 │ │ └── login/ # 登录模块 │ ├── routes/ # 路由管理页面跳转配置、路由拦截 │ │ └── app_routes.dart │ ├── services/ # 业务服务类数据处理、缓存服务、第三方服务封装 │ │ ├── cache_service.dart # 缓存服务SharedPreferences/鸿蒙本地缓存 │ │ └── user_service.dart # 用户相关业务服务 │ ├── widgets/ # 自定义公共组件按钮、输入框、列表项三平台复用 │ │ ├── custom_button.dart │ │ └── loading_widget.dart │ └── main.dart # Flutter 入口文件应用启动、全局初始化 ├── assets/ # 跨平台公共资源目录三平台复用的图片、字体、json文件 │ ├── images/ # 公共图片png、jpg、svg无需在各平台原生目录重复存放 │ ├── fonts/ # 公共字体 │ └── config/ # 公共配置json文件 ├── pubspec.yaml # Flutter 项目配置文件依赖、资源注册、版本信息 └── README.md # 项目说明文档关键目录说明lib/核心复用目录占项目代码量的80%以上三平台共享修改后所有平台同步生效这是跨平台框架的核心价值。android/、ios/、harmony/平台专属目录仅存放「无法跨平台复用」的原生代码比如平台专属权限申请如鸿蒙的特殊系统权限原生插件集成如某平台独有的SDK应用图标、启动页配置各平台规范不同平台专属原生功能如iOS的Face ID、鸿蒙的超级终端联动assets/跨平台公共资源需在pubspec.yaml中注册后才能在lib/中调用避免在各平台原生目录重复存放相同资源。2. 入门友好UniApp 项目目录结构支持三平台上手快UniApp基于Vue.js开发一套代码可同时打包为Android、iOS、鸿蒙、小程序等适合前端开发者转型目录结构更简洁。your_uniapp/ # 项目根目录 ├── unpackage/ # 打包输出目录各平台打包后的文件 ├── pages/ # 业务页面跨平台复用按业务模块划分 │ ├── home/ # 首页模块 │ │ ├── home.vue # 首页UI逻辑 │ │ └── home.json # 首页页面配置导航栏、背景 │ ├── mine/ # 我的模块 │ └── login/ # 登录模块 ├── static/ # 跨平台公共资源图片、字体、json无需注册直接调用 │ ├── images/ │ └── fonts/ ├── common/ # 公共工具类常量、工具函数、全局配置 │ ├── constants.js │ ├── utils.js │ └── api.js # 网络请求封装 ├── components/ # 自定义公共组件跨平台复用如按钮、输入框 │ ├── custom-button.vue │ └── loading.vue ├── pages.json # 全局页面配置路由、默认页面、全局导航栏 ├── manifest.json # 项目全局配置应用名称、版本、各平台权限、打包配置 │ ├── app-plus/ # Android/iOS配置图标、启动页、权限 │ └── harmony/ # 鸿蒙配置专属权限、原生特性 ├── App.vue # 应用入口文件全局生命周期、全局样式 ├── main.js # 全局初始化Vue实例、全局组件注册 └── uni.scss # 全局样式文件关键说明无需单独创建android/、ios/、harmony/目录所有平台配置统一在manifest.json中完成。如需集成平台原生插件在manifest.json中配置插件路径即可无需编写原生代码低代码友好。打包时通过HBuilderX直接选择「打包为Android App」「打包为鸿蒙App」即可生成对应平台安装包。二、 小众方案原生项目分离目录结构原生体验极致复用率低如果你的App对原生体验要求极高如大型游戏、金融类App需要单独开发Android、iOS、鸿蒙的原生代码此时采用「分离目录」结构核心思想是「公共逻辑抽离为独立模块各平台原生项目依赖该模块」。your_native_app/ # 项目根目录总仓库 ├── core/ # 跨平台公共核心模块复用部分纯业务逻辑/数据处理无UI │ ├── api/ # 网络请求封装采用C/Kotlin Multiplatform/Go编写各平台可调用 │ ├── models/ # 数据模型统一数据结构 │ ├── utils/ # 公共工具函数加密、日期格式化等 │ └── build.gradle # 核心模块构建配置供各平台依赖 ├── android/ # Android 原生项目Kotlin/Java │ ├── app/ # 安卓核心工程UI、原生组件、权限、依赖core模块 │ └── build.gradle ├── ios/ # iOS 原生项目Swift/Objective-C │ ├── Runner/ # iOS核心工程UI、原生组件、依赖core模块 │ └── Runner.xcodeproj ├── harmony/ # 鸿蒙 原生项目ETS/Java │ ├── entry/ # 鸿蒙核心工程UI、原生组件、依赖core模块 │ └── oh-package.json5 └── README.md # 项目说明文档优缺点说明优点各平台原生特性发挥到极致性能最优适合对体验要求苛刻的场景。缺点复用率低仅core/目录复用约30%-50%开发成本高需要三个平台的原生开发工程师后期维护复杂一个需求需要修改三个平台的代码。适用场景大型游戏、金融级App、需要深度调用各平台系统能力的App如鸿蒙的分布式能力、iOS的ARKit。三、 目录结构设计核心原则无论哪种方案都需遵守「高内聚低耦合」公共代码抽离到统一目录平台专属代码隔离到各自目录避免互相依赖。「按业务模块划分」而非按文件类型划分如不要把所有按钮放在buttons/而是把「首页相关」都放在home/方便团队协作和后期维护。「资源统一管理」跨平台复用的资源避免重复存放减少冗余和修改成本。「可扩展性」预留插件目录、第三方服务目录方便后期集成新功能如推送、支付。「符合框架/平台规范」不要随意修改框架默认目录结构如Flutter的lib/、Android的AndroidManifest.xml路径否则会导致打包失败、调试困难。总结绝大多数场景工具类、社交类、电商类App优先选择Flutter/UniApp跨平台框架目录结构兼顾开发效率、复用率和维护性。追求原生极致体验且有充足人力预算可选择原生项目分离目录结构核心是抽离core/公共模块减少重复开发。目录设计的核心是「公共代码复用、平台代码隔离、按业务划分」这是保证项目长期可维护的关键。