Day1 – 地图集成

功能目标： 在智能校园信息平台中集成地图模块，展示校园地图或定位信息，方便用户快速导航校园。

问题场景： 需要在鸿蒙平台上实现地图显示，但常见的 google_maps_flutter 插件不支持非 GMS 设备，华为地图（HMS）又受制于 HMS 设备。项目启动后尝试调用谷歌地图或高德地图插件，发现无法运行，页面报错。

排查过程： 调研可用地图方案后发现，flutter_map 是一个基于 Leaflet 的纯 Dart 地图插件，不依赖任何原生 SDK。在 OpenHarmony 上，纯 Dart 实现的 flutter_map 具有“天然兼容、性能稳定、零配置”的优势。其核心依赖 latlong2 等库都可通过鸿蒙兼容包引用，保证稳定性。

解决方案： 使用 flutter_map 插件配合 OpenStreetMap 瓦片服务，在代码中直接声明 FlutterMap 组件即可在鸿蒙设备上加载地图。例如：

import 'package:flutter_map/flutter_map.dart';
import 'package:latlong2/latlong2.dart';

class BasicMapPage extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return FlutterMap(
      options: const MapOptions(
        initialCenter: LatLng(31.2304, 121.4737), // 上海坐标
        initialZoom: 13.0,
      ),
      children: [
        TileLayer(
          urlTemplate: 'https://tile.openstreetmap.org/{z}/{x}/{y}.png',
          userAgentPackageName: 'com.example.app',
        ),
      ],
    );
  }
}

如果需要添加自定义标记，可使用 MarkerLayer 组件：

MarkerLayer(
  markers: [
    Marker(
      point: LatLng(31.2304, 121.4737),
      width: 80, height: 80,
      child: Icon(Icons.location_on, color: Colors.red, size: 40),
    ),
  ],
)

经验总结： 采用 flutter_map 后，地图功能在鸿蒙平台上实现了开箱即用，免除了原生适配工作。这个方案使用纯 Dart 实现，兼容性好，适合展示型地图场景。后续若需高级功能（如 3D 或导航），可以考虑 HMS Map Kit 等方案，但 flutter_map 作为基础地图解决方案十分稳妥。

Day2 – 用户登录与注册

功能目标： 为平台实现用户登录与注册功能，包括输入账号密码并与后台交互，以及安全地保存登录凭据。

问题场景： 开发过程中发现，在鸿蒙设备上直接使用 Flutter 内置的本地存储（如 SharedPreferences）遇到插件缺失问题，无法正常存储用户 Token 或账号信息。登录界面输入后调用后端接口获得的 Token 无法持久化保存，重启应用后用户登录状态丢失。

排查过程： 查阅资料后了解到，鸿蒙上需要使用适配好的本地存储方案，例如 flutter_secure_storage 插件的鸿蒙版本来替代默认实现。该插件可以在鸿蒙设备上安全地保存小量敏感信息。我们还注意到需要调用 ohos_flutter_plugin 获取设备信息或实现自动登录等功能，但主要问题是存储失效。

解决方案： 通过在 pubspec.yaml 中添加 flutter_secure_storage（支持鸿蒙）依赖，并在代码中使用该插件保存 Token。例如：

这种方式将用户的登录 Token 安全地保存在鸿蒙设备的安全区域。界面层面，使用 TextFormField 和按钮组件搭建登录/注册界面，注册成功后同样调用 API 并保存凭据。

经验总结： 在鸿蒙上进行登录注册开发时，要特别注意数据存储的适配性。使用 flutter_secure_storage 等跨平台插件可以避免 MissingPluginException。另外，遵循最小权限原则请求权限（如手机信息）可提高用户信任度。通过本次实践，我们实现了在鸿蒙设备上稳定的登录注册流程，并安全地持久化了用户信息。

Day3 – 本地数据库

功能目标： 为应用添加本地数据库功能，将关键信息如课程表或公告缓存到设备中，以支持离线访问和快速加载。

问题场景： 在多次打开应用时，发现请求网络数据过于频繁，且当网络中断时无法查看历史数据。计划使用本地数据库缓存数据，但初次调用常规 Flutter SQLite 或 hive 时遇到路径和权限问题，数据库文件无法打开。

排查过程： 调研后发现在鸿蒙上使用本地数据库要注意存储路径合法性和插件适配。对于结构化数据量较大的场景，推荐使用 Hive 这样的 NoSQL 方案。查看文档得知，Hive 在鸿蒙环境下初始化时需要指定可写目录路径，否则会出现权限错误。

解决方案： 采用 Hive 作为本地数据存储，步骤如下：在 pubspec.yaml 添加 hive、hive_flutter 依赖，并编写模型类后生成 Adapter。初始化时获取应用的私有文件目录作为 Hive 存储路径，然后打开 Box。例如：

Future<void> initHive() async {
  // 示例：获取实际设备可写目录
  final dir = '/data/storage/el2/base/haps/entry/files'; 
  Hive.init(dir);
  Hive.registerAdapter(UserAdapter());
  await Hive.openBox<User>('users');
}

上述代码参考了鸿蒙兼容示例，确保 Hive 存储在合法目录。之后可使用 box.add、box.get 等方法进行增删查改。通过这种方式，我们实现了将用户信息、课程表等结构化数据缓存到本地，离线时也可快速读取。

经验总结： 在鸿蒙上选择本地存储方案时，要根据数据量和复杂度做出权衡：少量配置用 SharedPreferences，中等结构化数据选用 Hive。使用 Hive 时务必指定正确的存储路径，否则会提示权限错误。经过调试，我们成功让数据在鸿蒙上本地持久化，提高了用户体验和离线可用性。

Day4 – 系统通知

功能目标： 在应用中实现消息通知功能，用于向用户推送校园公告、活动提醒等信息，包括本地定时通知和远程推送通知。

问题场景： 实现通知功能时发现应用运行后无法收到通知提示，或者定时通知在指定时间没有弹出。检查后发现 Android 13 及以上版本需要额外申请通知权限，鸿蒙系统类似需要声明通知相关权限。

排查过程： 查阅资料，了解到 Flutter 平台可使用 flutter_local_notifications 插件来支持本地通知。在鸿蒙上使用该插件时，需要在 AndroidManifest（鸿蒙对应 manifest）中添加 POST_NOTIFICATIONS 权限。此外，发送推送通知时，还需要检查应用的通知权限状态并引导用户开启。

解决方案： 使用 flutter_local_notifications 插件实现通知功能。在 pubspec.yaml 中添加依赖：

dependencies:
  flutter_local_notifications: ^15.1.1

在鸿蒙项目的 module.json5 或 AndroidManifest 中声明：

<uses-permission android:name="android.permission.POST_NOTIFICATIONS"/>

然后初始化通知插件，在合适时机发送通知。示例代码：

import 'package:flutter_local_notifications/flutter_local_notifications.dart';

final FlutterLocalNotificationsPlugin flutterLocalNotificationsPlugin = 
    FlutterLocalNotificationsPlugin();

// 在应用初始化时调用
Future<void> initializeNotifications() async {
  const initializationSettingsAndroid =
      AndroidInitializationSettings('@mipmap/ic_launcher');
  final initSettings = InitializationSettings(android: initializationSettingsAndroid);
  await flutterLocalNotificationsPlugin.initialize(initSettings);
}

// 发送一条基础通知
Future<void> showNotification() async {
  const AndroidNotificationDetails androidDetails = AndroidNotificationDetails(
    'basic_channel', '基础通知',
    importance: Importance.max, priority: Priority.high
  );
  const NotificationDetails details = NotificationDetails(android: androidDetails);
  await flutterLocalNotificationsPlugin.show(
    0,
    '新消息提醒',
    '您有一条重要消息等待查看',
    details
  );
}

该代码来自官方示例。通过上述配置，可实现在鸿蒙设备上显示通知。若要实现远程推送，则需进一步接入鸿蒙推送服务（OpenHarmony Push Kit 或华为 HMS 推送）并配置对应权限。

经验总结： 在鸿蒙应用中使用通知功能时，要注意权限申请和渠道配置。必需的权限需要在配置文件中声明，并在运行时检查和申请。本地通知可用 flutter_local_notifications 快速实现，远程推送则推荐使用鸿蒙推送套件以达到高到达率。经过这一实践，我们顺利实现了包括定时本地通知和(可扩展的)远程推送的完整通知系统。

Day5 – 多语言适配

功能目标： 为应用添加多语言支持，实现界面文字的中英文（及更多语言）切换，使平台能够服务不同语言的用户群体。

问题场景： 在开发过程中发现，应用只支持中文，当系统语言切换到英文时界面仍显示中文，无法自动切换。并且鸿蒙环境下 Flutter 的 arb 资源与系统的语言设置不同步，需要手动适配。

排查过程： 查询资料发现，一种最佳实践是将所有界面文案集中管理在 Flutter 的 ARB 资源文件中。在 Flutter 侧使用 flutter_localizations 和 flutter gen-l10n 生成代码，然后在界面中通过 AppLocalizations.of(context) 获取多语言字符串。还需编写监听鸿蒙系统语言切换的逻辑，使 Flutter 页面能够实时响应。

解决方案： 按照文档创建英语、中文等 ARB 文件（例如 app_en.arb、app_zh.arb），使用 flutter gen-l10n 生成对应的 Dart 代码。然后在页面中引用：

Text(AppLocalizations.of(context)!.loginButton)

在 MaterialApp 中配置支持的语言和 localizationsDelegates。此外，通过 @ohos.systemLocale 插件监听系统语言变化，当语言变更时使用 ChangeNotifier 通知界面重建，实现动态切换。下面是监听鸿蒙系统语言事件的示例：

import systemLocale from '@ohos.systemLocale';
import { EventChannel } from '@ohos/flutter';

class LocalePlugin {
  constructor() {
    this.eventChannel = new EventChannel('com.example.locale/events');
    systemLocale.on('localeChange', () => {
      const newLang = systemLocale.getSystemLanguage(); // 如 "zh-CN"
      this.eventChannel.success(newLang);
    });
  }
}

Flutter 端通过 EventChannel 接收通知，更新应用的 Locale，完成语言同步。

经验总结： 多语言开发需集中管理资源和自动同步系统设置。我们通过 Flutter 的国际化方案统一了文案资源。同时借助鸿蒙的 systemLocale API 监听系统语言切换，实现了中英两种语言的动态切换。这一方案确保了应用的语言显示与系统保持一致，提升了全球化和民族化场景下的用户体验。

Day6 – 权限管理

功能目标： 管理应用所需的运行时权限，如摄像头、地理位置、读写存储等，确保在需要时正确申请，并处理用户的授权结果。

问题场景： 在调用相机或访问文件时，应用出现无响应或崩溃。调查后发现鸿蒙权限模型与 Android 不同：必须先在 module.json5 中声明权限，再在运行时申请，且不能使用普通的 permission_handler 插件。

排查过程： 查看鸿蒙文档得知：①必须在 module.json5 的 requestPermissions 中声明所有需要的权限；②运行时应使用 abilityAccessCtrl 模块来请求权限，而不是 Android 的 PermissionHandler。此外，鸿蒙的权限名称以 ohos.permission.X 格式存在，与 Android 的名称不同。

解决方案： 示例以请求摄像头权限为例。在 module.json5 中新增：

"requestPermissions": [
  { "name": "ohos.permission.CAMERA" }
]

运行时代码：
 

import 'package:openharmony/ability_access_ctrl.dart';

final atManager = abilityAccessCtrl.createAtManager();
final result = await atManager.requestPermissionsFromUser(
  context, ['ohos.permission.CAMERA']
);
if (result.authResults[0] == abilityAccessCtrl.GrantStatus.PERMISSION_GRANTED) {
  // 已授权，可以访问摄像头
}

这段代码使用了鸿蒙平台的权限管理接口。同理可处理其它权限。通过这种方式，我们在用户触发相关功能时才弹窗请求权限，避免一次性请求过多权限，提升用户同意率。

经验总结： 鸿蒙平台的权限管理与 Android 有本质差异：需要在 module.json5 中声明权限，运行时使用 AbilityAccessCtrl 模块。开发过程中一定要严格声明所有权限，否则系统将拒绝相关能力。我们最终建立了“按需请求、即时申请”的策略，避免启动时大量权限弹窗，并确保应用功能正常运行。

Day7 – 应用包发布

功能目标： 完成应用的签名打包和发布流程，将项目打包成符合鸿蒙分发规范的 .app 安装包，并上传到应用市场（如 AppGallery Connect）。

问题场景： 在进行打包时遇到签名配置不正确、打包失败等问题。包括生成签名证书流程不熟悉，或包上传应用市场时提示解析错误。

排查过程： 对照文档和官方示例检查发现：①需要在 DevEco Studio 中配置签名，包括生成 .p12 密钥库；②应在 AppGallery Connect 中创建项目、APP ID、Profile 等信息；③在 build-profile.json5 中指定使用哪个签名进行打包。若签名错误，会导致上传时包解析失败。

解决方案： 具体流程：使用 DevEco Studio 打开项目，设置自动或手动签名。手动签名时先生成 .p12（KeyStore）和 .cer（证书），然后在 AppGallery Connect 上传证书并创建签名 Profile。在 DevEco 的 Project Structure -> Signing Configs 中添加签名配置，填入密码和密钥别名。编辑 build-profile.json5：

"products": [
  {
    "name": "default",
    "signingConfig": "release"
  }
]

然后执行 Build -> Build Hap(s)/APP(s)，选择 Release 模式进行打包。打包成功后会在 build/outputs/default 目录生成 .app 安装包，该文件即是要上传的安装包。

经验总结： 在鸿蒙平台发布应用时，正确的签名和配置至关重要。必须提供合规的电子版权证书（软著）和签名信息，并按照文档在 AppGallery Connect 填写项目及应用信息。打包后使用 DevEco 的 Release 签名配置生成 .app 文件，然后上传至应用市场。如遇“包解析失败”等问题，应检查签名配置和 build-profile.json5 设置。本阶段顺利完成了应用签名、打包并上架准备工作。

Day8 – 摄像头与图片选择

功能目标： 实现用户拍照或从相册选择图片的功能（如上传头像、提交表单照片），支持在鸿蒙设备上打开相机和相册，并获取选中的图片。

问题场景： 在尝试使用 Flutter 通用的 image_picker 插件时，发现鸿蒙平台需要特殊适配版本。直接添加 pub.dev 上的 image_picker 依赖后，运行时会提示找不到插件或应用闪退。

排查过程： 查到鸿蒙社区提供了适配版本的 image_picker 库，需要通过 Git 地址引入。阅读文档后发现可以在 pubspec.yaml 中使用 Git 方式依赖鸿蒙镜像：

dependencies:
  image_picker:
    git:
      url: https://gitcode.com/openharmony-tpc/flutter_packages.git
      path: packages/image_picker/image_picker
      ref: br_image_picker-v1.1.2_ohos

这样即可保证拉取到支持鸿蒙的 image_picker 实现。

解决方案： 引入适配后的 image_picker 后，使用该插件的标准 API 调用。为了代码复用和异常处理，我们封装了一个服务类，如：

final ImagePicker _picker = ImagePicker();

// 拍照
Future<XFile?> pickImageFromCamera() async {
  try {
    final photo = await _picker.pickImage(
      source: ImageSource.camera, imageQuality: 80);
    return photo;
  } catch (e) {
    print('拍照出错: $e');
    return null;
  }
}

在 UI 中调用 ImagePickerService().pickImageFromCamera()，并在返回的 XFile 中获取 file.path 进行后续操作（如显示或上传）。如果要从相册选择多张图片，也可使用 _picker.pickMultiImage()。

经验总结： 鸿蒙设备上使用相机和相册与 Android 类似，但需要确保插件版本支持鸿蒙。在本例中，通过 Git 引入了适配好的 image_picker 插件。二次封装后，业务层调用变得简单并统一了异常处理。最终功能上线时，用户可以顺利拍照或选图，即使在没有后台运行时也能回调结果，增强了用户体验。

Day9 – 分布式数据同步

功能目标： 利用鸿蒙分布式能力，实现多设备间数据同步，例如将学生成绩或笔记在手机和平板等多端共享，保证数据的一致性和实时性。

问题场景： 开发中需要支持跨终端协同，有时在手机端添加了数据后，同一账号的平板端没有即时更新。初次尝试仅用普通本地存储，发现多设备间数据割裂。

排查过程： 了解到 OpenHarmony 提供分布式数据服务 (DDS)，支持设备间自动同步和冲突处理。与传统单设备方案不同，它能实现增量同步和离线可用。原来要实现跨设备数据一致，需要使用这一技术栈，而不是简单地把缓存数据复制到其他设备。

解决方案： 集成鸿蒙的分布式数据服务：在应用中使用提供的 Flutter 分布式库（通过 MethodChannel 封装 Native API）。示例初始化：

// 假设已有 DistributedDataService 封装
await DistributedDataService().initDDS();
DistributedDataService().onDataSynced = (data) {
  // 收到同步数据后更新本地模型
};

业务数据结构加上版本号后，通过 DistributedDataService 上传到 DDS。其他设备的应用注册相同的数据ID，鸿蒙系统会自动完成双向同步，并在冲突时执行指定策略。这种机制使得一处修改后，其它设备能实时感知并更新，离线修改也会在联网后同步。

经验总结： 通过实践，我们体验到鸿蒙分布式数据管理的威力：数据在多设备间自动同步，并支持版本控制和冲突解决。与单机存储相比，新方案能实时双向同步并保证一致性，有助于打造无缝的跨端体验。在具体开发中，要正确使用鸿蒙分布式服务 API，并对照业务场景设计合适的同步策略，以充分发挥这一能力。

Day10 – 功能联调与异常处理

功能目标： 对已开发的各项功能模块进行联调测试，完善错误处理机制，确保应用逻辑在各种场景下都能正确运行。

问题场景： 在联调过程中发现一些异常情况，比如网络请求失败时界面没有提示、布局错乱导致闪退、或者 debug 模式下日志刷屏。原来使用的 Flutter 适配版本有已知 Bug，例如调试时频繁打印日志导致卡顿。

排查过程： 通过日志定位，发现问题主要是版本兼容和错误未捕获。参考社区信息了解到最新的 OpenHarmony Flutter 适配版本已经修复了多项稳定性问题，包括解决了 debug 模式下的日志刷屏和崩溃问题。同时，我们加入了更多的 try-catch 和错误提示逻辑，以及针对不同平台的 UI 适配检查，避免在特定设备上出现布局问题。

解决方案： 升级 Flutter 引擎到推荐的 3.27.4-ohos-1.0.1 版本，该版本修复了调试时日志过多导致的卡死等问题。在代码中对可能抛出异常的操作统一添加了错误处理：例如网络请求失败时弹出提示，表单输入错误时高亮提示，同时在本地收集错误日志便于排查。通过使用 logcat 和鸿蒙的调试工具过滤日志，只保留自己关注的模块日志。

经验总结： 联调阶段发现并修复了多个细节问题。值得一提的是，升级 Flutter-OHOS 适配包版本帮助“告别调试痛点”，让开发体验更顺畅。此外，良好的异常处理和用户提示机制非常关键，能提升稳定性和用户体验。通过这一步，我们确保了各项功能在真实使用场景中的健壮性，为后续发布奠定了基础。

Day11 – 性能优化

功能目标： 提升应用运行效率，包括界面渲染流畅度、内存占用控制，以及数据加载速度等，确保校园信息平台在各种设备上都能流畅使用。

问题场景： 在性能测试时发现应用存在一些卡顿和内存占用问题：如加载大量图片时出现掉帧、内存占用持续增高。分析发现使用默认的网络图片加载方法和未限制缓存可能导致内存泄漏。

排查过程： 针对图片加载问题，参考资料建议使用第三方缓存库代替默认缓存以更好控制内存。同时对长列表进行优化，如使用 ListView.builder 和惰性加载。对页面复杂布局进行 Profile Mode 分析，找出占用资源较高的 Widget 进行优化或简化。

解决方案： 引入 flutter_cache_manager 和 cached_network_image 来替代直接使用 Image.network，对图片进行有界缓存。示例代码：

import 'package:flutter_cache_manager/flutter_cache_manager.dart';
class ImageCacheManager {
  static final CacheManager _instance = CacheManager(
    Config(
      'customCacheKey',
      stalePeriod: Duration(days: 7),
      maxNrOfCacheObjects: 100, // 最大缓存100张图片
    ),
  );
}

并在使用时指定缓存管理器：

CachedNetworkImage(
  imageUrl: imageUrl,
  cacheManager: ImageCacheManager._instance,
  placeholder: (context, url) => CircularProgressIndicator(),
);

这样可以限制图片缓存大小（示例为50MB/100张），避免无限制增长内存。其他优化措施包括减少 Widget 重建次数、合理使用 const 构造函数、预加载关键小图资源（使用 precacheImage）等。

经验总结： 性能优化是一个持续过程。在本项目中，我们通过限制图片缓存、优化列表渲染、异步加载来降低内存压力和提高渲染效率。借鉴实践经验建议使用缓存管理库，并在 main() 中对常用图片进行预缓存。最终测试证明，优化后应用在鸿蒙设备上的流畅度显著提升，内存使用也趋于稳定。

Day12 – 测试与CI/CD

功能目标： 为项目构建完善的测试体系和持续集成流程，提高代码质量并加速交付，确保每次迭代的稳定性。

问题场景： 发现团队早期缺乏自动化测试，导致每次添加新功能后可能意外影响现有功能（回归缺陷）。并且每次发布都需要手动测试所有页面，效率低且易漏测。

排查过程： 借鉴行业实践，了解到 Flutter 支持三层测试：单元测试、Widget 测试和集成测试。大量手动测试的问题可以通过构建自动化测试用例来缓解。CI/CD 方面，我们选择 GitHub Actions 来自动跑测试并构建鸿蒙包发布。

解决方案： 首先按照测试金字塔原则，编写了大量单元测试覆盖业务逻辑（占比 ≥70%），例如对数据仓库和服务类进行 mock 测试：

test('fetchUser throws on empty ID', () {
  expect(() => repository.fetchUser(''), throwsA(isA<ArgumentError>()));
});

这是一个验证空 ID 报错的单元测试例子。接着编写 Widget 测试验证关键页面布局和用户交互，最后添加集成测试模拟用户流程（可使用真机云测）。将测试脚本配置在 GitHub Actions 中，每次 PR 时自动执行测试并报告结果。还集成了测试覆盖率工具（如 Codecov），以监控覆盖率。

经验总结： 自动化测试和 CI/CD 极大提升了开发效率和质量。遵循“提交即测试、合并即发布”的模式，我们使得新增功能上线前通过自动化回归验证。通过测试金字塔分层，我们用快速的单元测试覆盖了大量代码逻辑，用更少的集成测试确保大流程正确。在此基础上，CI/CD 的实践让我们能快速迭代且降低线上风险。

Day13 – 主题与配色切换

功能目标： 增加深色模式（Dark Mode）和浅色模式主题切换功能，允许用户自主选择界面风格或跟随系统设置，提升视觉舒适度。

问题场景： 用户反馈应用全局仅支持浅色主题，夜间阅读时眼睛疲劳。并希望记住用户的主题偏好，下次打开自动生效。但起初界面主题静态定义，无法动态更换。

排查过程： 研究发现可以在 Flutter 中通过定义多套 ThemeData 来实现主题切换，通过状态管理将选定主题应用于整个应用。参考资料以 Provider 为例，创建主题状态类，并持久化保存用户选择。

解决方案： 在代码中定义浅色与深色主题：

final ThemeData lightTheme = ThemeData(
  brightness: Brightness.light,
  primarySwatch: Colors.blue,
  scaffoldBackgroundColor: Colors.white,
);
final ThemeData darkTheme = ThemeData(
  brightness: Brightness.dark,
  primarySwatch: Colors.blue,
  scaffoldBackgroundColor: Color(0xFF121212),
);

通过 ChangeNotifier 管理主题状态：

class ThemeProvider extends ChangeNotifier {
  ThemeMode _themeMode = ThemeMode.system;
  ThemeMode get themeMode => _themeMode;

  void setThemeMode(ThemeMode mode) {
    _themeMode = mode;
    _saveThemePreference(mode);
    notifyListeners();
  }

  Future<void> _saveThemePreference(ThemeMode mode) async {
    final prefs = await SharedPreferences.getInstance();
    await prefs.setString('themeMode', mode.toString());
  }
}

该 ThemeProvider 更新模式后会调用 notifyListeners() 让界面重新渲染。同时，应用启动时从 SharedPreferences 中读取上次保存的 themeMode 以恢复用户选择。在 MaterialApp 中使用 theme, darkTheme 和 themeMode: provider.themeMode 即可实现动态切换。

经验总结： 通过上述设计，我们成功实现了跨平台的主题切换功能。使用响应式的状态管理让切换操作即时生效，持久化存储保证了用户设置的记忆。值得注意的是，深色主题要选取护眼配色（如使用 #121212 而非纯黑）来减少视觉疲劳。整体来说，这增强了应用的易用性和个性化，符合现代应用的用户体验需求。

Day14 – 二维码扫码功能

功能目标： 添加二维码/条形码扫码功能，让用户能够扫描校园公告、课程表或校卡上的二维码并自动识别内容。

问题场景： 应用需支持扫描功能，但原生实现较复杂，需要统一跨平台的解决方案。初步尝试自己调用相机接口解码失败。

排查过程： 查找 Flutter 插件后发现 mobile_scanner 是一款功能强大的跨平台扫码插件，支持多种格式（QR 码、条形码等）。它在鸿蒙平台上同样可以使用（因为基于 ML Kit 和平台原生框架）。我们决定集成此插件以快速实现扫码功能。

解决方案： 在 pubspec.yaml 添加依赖：

dependencies:
  mobile_scanner: ^7.2.0

在界面中使用 MobileScanner 组件：

import 'package:mobile_scanner/mobile_scanner.dart';

MobileScanner(
  onDetect: (barcode, args) {
    final code = barcode.rawValue;
    print('扫描结果: $code');
    // 根据需要处理扫描到的字符串
  },
);

此代码参照插件示例，只需几行即可实现扫码界面。在扫码回调中，我们获取到二维码内容并可进行业务处理，如跳转链接或查询事件。注意要在模块配置中声明相机权限（已在第6天配置）并处理用户拒绝场景。

经验总结： 通过 mobile_scanner 插件，我们快速为鸿蒙跨端应用加入了扫码功能。该插件兼容性好，简单易用，只需要一个组件即可完成扫码窗口和结果回调。实践证明，借助第三方成熟库能大幅减少开发成本，也为校园应用增加了方便的扫码体验。