手机 App 跨平台框架统一目录构建

你希望构建一个同时支持Android（安卓）、iOS（苹果）、HarmonyOS（鸿蒙）三平台的手机App项目，核心需求是目录结构清晰、跨平台代码复用率高、各平台原生特性不被束缚、后期维护便捷。

首先要明确：三平台适配有两种核心思路，「跨平台框架统一目录（推荐，复用率高）」和「原生项目分离目录（小众，原生体验极致）」，其中跨平台框架是绝大多数团队的选择（避免重复开发），下面分别详细讲解。

一、 推荐方案：基于跨平台框架的项目目录结构（优先选择）

目前成熟的跨平台框架中，Flutter（Google）、React Native（Meta）、UniApp（DCloud，基于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              # 项目说明文档

关键目录说明

1. lib/：核心复用目录，占项目代码量的80%以上，三平台共享，修改后所有平台同步生效，这是跨平台框架的核心价值。

2. android/ 、 ios/ 、 harmony/：平台专属目录，仅存放「无法跨平台复用」的原生代码，比如：

   • 平台专属权限申请（如鸿蒙的特殊系统权限）

   • 原生插件集成（如某平台独有的SDK）

   • 应用图标、启动页配置（各平台规范不同）

   • 平台专属原生功能（如iOS的Face ID、鸿蒙的超级终端联动）

3. 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）。

三、 目录结构设计核心原则（无论哪种方案都需遵守）

1. 「高内聚，低耦合」：公共代码抽离到统一目录，平台专属代码隔离到各自目录，避免互相依赖。

2. 「按业务模块划分」：而非按文件类型划分（如不要把所有按钮放在buttons/，而是把「首页相关」都放在home/），方便团队协作和后期维护。

3. 「资源统一管理」：跨平台复用的资源避免重复存放，减少冗余和修改成本。

4. 「可扩展性」：预留插件目录、第三方服务目录，方便后期集成新功能（如推送、支付）。

5. 「符合框架/平台规范」：不要随意修改框架默认目录结构（如Flutter的lib/、Android的AndroidManifest.xml路径），否则会导致打包失败、调试困难。

总结

1. 绝大多数场景（工具类、社交类、电商类App）优先选择Flutter/UniApp跨平台框架目录结构，兼顾开发效率、复用率和维护性。

2. 追求原生极致体验且有充足人力预算，可选择原生项目分离目录结构，核心是抽离core/公共模块减少重复开发。

3. 目录设计的核心是「公共代码复用、平台代码隔离、按业务划分」，这是保证项目长期可维护的关键。