前段时间突然特别想去看极光。

漠河、禾木、冰岛、挪威……光是看着这些地方的照片，就已经开始琢磨什么时候能出发了。

不过，等我真的开始查资料，才发现看极光这件事，比想象中麻烦一些。

去哪里只是第一步。还要看地磁活动、天气、云量、当地天色，有时候空间天气条件不错，目的地却阴了一整晚；有时候看到一个很高的 Kp，又不知道这个数字放到自己准备去的地方，到底意味着什么。

查着查着，浏览器里开了一堆页面。

我最想知道的，其实就是一句话：

今晚这个地方，值得出去等吗？

于是，一个很熟悉的念头又冒出来了：要不自己做一个。

就这样，我开始折腾候光，工程名叫 Aurora，一个用 ArkTS 和 ArkUI 开发的 HarmonyOS 原生极光观测应用。

原本只是想做一个自己能用的小工具，后来有了动态夜景、重力视差、桌面卡片、观测地志，最后还给它搭了一套不需要租服务器的数据后端。

这篇就聊聊它是怎么一点点做出来的。

先做一个我自己愿意打开的首页

最开始，我对这个应用的要求其实不多。

打开之后，能看到自己关心的地点，知道当前条件怎么样，再看看接下来有没有比较合适的时间。

所以首页最显眼的位置，我留给了观测结论和机会指数，往下才是最佳窗口、空间天气和当地天空条件。用户不用先认识所有指标，也能知道现在大概是什么情况；想继续研究，再往下看。

这里有一个我比较在意的地方：观测机会指数不能直接当作极光出现的概率。72 分不等于有 72% 的概率看到极光，它是应用根据多项条件计算出来的参考，还没有经过统计概率校准。

因此，数字旁边还会显示影响原因。天色仍亮、云层较厚，或者当地活动偏弱，这些情况需要等待的东西并不一样。只给出一个低分，还是不够。

写页面时，地点、指标、趋势和背景逐渐拆开了。比如这块趋势面板，只接父页面传进来的数据：

@Component
export struct AuroraForecastPanel {
  @Prop hours: AuroraHour[] = [];
  @Prop auroraDays: AuroraDayForecast[] = [];
  @Prop weatherDays: AuroraWeatherDayForecast[] = [];
  @Prop solarDays: AuroraSolarDayForecast[] = [];
  @Prop accentColor: string = '#75E0BD';
  // 下方根据各自的数据构建四种趋势卡片。
}

父页面负责请求和地点切换，面板负责展示。后面接桌面卡片时，也能继续复用同一份数据，不用把请求逻辑重新写一遍。

想先把那片夜空做出来

但真开始画页面，我又有点不甘心只做一个数据面板。

极光本来就是一件很有画面感的事。雪地、山脉、夜空，还有慢慢变化的光，如果最后做出来只是几排数字和一张折线图，总觉得少了点什么。

所以我先做的是首页的场景。

最先想到的是放视频，后来发现还要切强度、做视差、控制暂停，索性把地景、星空、极光和信息层分开处理。

地景和极光分开之后，平静的时候直接隐藏极光层就可以了。底图本身不带极光，不会出现页面写着“近期机会低”，背景却永远挂着一大片绚丽光幕的情况。

动态部分用了透明 PNG 序列，不同档位准备不同资源，一套 36 帧，6 秒循环。ArkUI 里用 ImageAnimator 播：

ImageAnimator()
  .images(frames)
  .height('100%')
  .aspectRatio(2)
  .fixedSize(true)
  .duration(6000)
  .iterations(-1)
  .fillMode(FillMode.Forwards)
  .state(this.shouldPlayAurora()
    ? AnimationStatus.Running
    : AnimationStatus.Paused)
  .opacity(this.overlayOpacity())
  .scale({ x: 1.24, y: 1.24 })
  .translate({
    x: this.sceneOffsetX * 0.2,
    y: this.sceneOffsetY * 0.2
  })
  .hitTestBehavior(HitTestMode.None)

极光跟着地景稍微动一点就够了，这里只跟 20%。外面再放大一点，免得移动时露出边。

还有个小地方，装饰层记得关掉命中测试。不然透明图层铺在上面，下面的按钮可能看得见，点不着。

当然，图片也不能随便堆。文件压缩得小，解码到内存里可不一定小，帧数和尺寸都得收着点。切走页面就暂停，没必要让它在看不见的地方继续跑。

背景和字之间的关系，来回改了好几次。遮罩一加重，风景没了；减轻一点，雪地上的文字又不好读。最后只在需要读信息的地方压暗，卡片做成半透明，重要数字和选中状态用一点绿色。

这里没有一个参数调好就能解决所有问题，还是要把背景和信息放在一起，反复看。

顺便让风景跟着手机动一点

背景做好之后，又想加一点重力视差。手机轻轻转一下，地景挪一点，天空挪得更少，字留在原地。

订阅重力传感器很直接：

sensor.on(
  sensor.SensorId.GRAVITY,
  this.gravityCallback,
  { interval: 'ui' }
);

刚接上传感器时，这个效果并不好。原始数据直接映射到画面上，手稍微抖一下，背景也跟着晃。看几秒还觉得新鲜，盯久了就有点累。

后来我把当前握持姿态作为基线，对变化量限幅，再做平滑。

const MAX_HORIZONTAL_OFFSET: number = 36;
const MAX_VERTICAL_OFFSET: number = 20;
const HORIZONTAL_GAIN: number = 6;
const VERTICAL_GAIN: number = 4;
const SMOOTHING: number = 0.18;

export function resolveParallaxOffset(
  deltaX: number,
  deltaY: number,
  previousX: number,
  previousY: number
): ParallaxOffset {
  const targetX: number = clamp(
    -deltaX * HORIZONTAL_GAIN,
    -MAX_HORIZONTAL_OFFSET,
    MAX_HORIZONTAL_OFFSET
  );
  const targetY: number = clamp(
    deltaY * VERTICAL_GAIN,
    -MAX_VERTICAL_OFFSET,
    MAX_VERTICAL_OFFSET
  );
  return {
    x: clamp(
      previousX + (targetX - previousX) * SMOOTHING,
      -MAX_HORIZONTAL_OFFSET,
      MAX_HORIZONTAL_OFFSET
    ),
    y: clamp(
      previousY + (targetY - previousY) * SMOOTHING,
      -MAX_VERTICAL_OFFSET,
      MAX_VERTICAL_OFFSET
    )
  };
}

计算单独放进函数里，调起来方便，也能喂几个极端值试试，看看会不会一下把背景移出屏幕。

文字始终固定。用户只是想看观测时间，没有必要让时间也跟着手机漂。页面离开时停止监听和计时，回到前台再按设置恢复：

onPageHide(): void {
  this.pageVisible = false;
  this.syncFirstUseGuideMotion();
  this.stopGravityParallax();
  this.stopDataFreshnessTimer();
}

这部分还想继续磨。尤其是长时间拿着手机时会不会累、动态背景会多耗多少电，以及怎样跟系统的“减少动态效果”配合，光在模拟器里看看还不够。

地点从漠河慢慢扩展到了 50 个

最开始只有漠河，后来慢慢加到了 50 个地点。

暂时没接那种搜全世界地名的服务，先把这些确定要做的地方整理好。名称、坐标、时区、参考 Kp、地景和资料都得对得上，不是往列表里添个名字就结束了。

地点弹窗也改过几轮。纯色太闷，太透明又乱，下面的数字全透上来了。最后还是留一点夜景和光幕，把读文字的地方压暗。

有些地方还准备了几张不同的风景。不过不能每次重新打开就换一张，不然首页和卡片很容易对不上。后来用地点 ID 加日期算一个固定序号，同一天就用同一张：

export function resolveDailySceneVariant(
  locationId: string,
  dateToken: string,
  variantCount: number = 3
): number {
  if (variantCount <= 0) {
    return 0;
  }
  const seed: string = `${locationId}:${dateToken}`;
  let hash: number = 2166136261;
  for (let index: number = 0; index < seed.length; index += 1) {
    hash ^= seed.charCodeAt(index);
    hash = Math.imul(hash, 16777619);
  }
  return (hash >>> 0) % variantCount;
}

这样，同一个地点、同一天能保持稳定，卡片和首页也可以复用相同规则。不是每个地点都有三张图，实际数量由地点配置决定。

还有个容易漏的地方，首页换成罗弗敦了，侧栏不能还在漠河。最后让它们共用当前地点和场景状态，少各存一份，也少一点互相不同步的麻烦。

侧栏手势也需要一起考虑：拖动一半、松手回弹、系统返回、从子页面返回，状态都得接得上。位移、缩放和遮罩沿同一进度变化，避免中途跳层。材质看着舒服之后，还得拖一拖，看看整个过程顺不顺。

时间范围变长，也要把数据含义说清楚

趋势也越做越长了，从最开始的十二小时，后来加上三天、十六天和二十七天。不过这几张卡片看的是不同东西：

时间范围	主要内容	使用方式
未来 12 小时	小时机会、Kp、云量、黑暗等	查看临近时段的变化
极光 3 天	Kp 预报与当地夜间天气	比较几天内的观测参考
天气 16 天	当地夜间天气、能见度、暗夜时长	提前了解天气趋势
太阳未来 27 天	NOAA Ap/F10.7 展望	观察较长期的空间天气背景

二十七天页面使用 NOAA 的 45 日 Ap/F10.7 展望，截取对应范围来展示，提供较长期的活动背景。它不能解释成某个地点二十七天后的极光可见概率；十六天天气页也只展示天气趋势。

组件里也明确保留不同数据类型，而不是把所有数字硬塞进同一个数组。没有对应扩展数据时，显示等待状态，不用无依据的默认数字把卡片填满。

十二小时图还可以选中具体时段，查看对应指标。横向趋势和页面纵向滚动、侧栏手势以及系统边缘返回之间也会竞争。实际处理时需要识别横向内容区域，不能把页面上所有横滑都当成导航手势。

这是很典型的原生开发细节：单个组件能滑，不代表放进完整页面后仍然好用。

桌面上能看一眼，就不用每次都点进来

我觉得这种应用挺适合放桌面。很多时候只是想看一眼今晚有没有机会，还得先找到应用再打开，多少有点绕。

所以做了四种卡片：极光瞬间、最佳窗口、夜空仪表、趋势仪表。小的先看结论，大一点的再放指标和趋势。

写到这里才发现，卡片不能只跟着一个全局地点走。

假如桌面放两张，一张跟应用，另一张专门看准备去的城市。首页换个地方，两张全跟着变，那固定地点就白设了。

所以配置里分开了：跟随应用，或者固定地点。

export type FormLocationMode = 'followApp' | 'pinned';

export interface FormLocationSelection {
  mode: FormLocationMode;
  locationId?: string;
}

export function formSelectionKey(formId: string): string {
  return 'form_location_' + formId;
}

解析地点时，根据当前卡片的选择决定：

export function resolveFormLocation(
  selection: FormLocationSelection,
  appLocationId: string
): string {
  const normalized: FormLocationSelection =
    normalizeFormSelection(selection);
  if (normalized.mode === 'pinned') {
    return normalized.locationId ?? DEFAULT_LOCATION_ID;
  }
  return normalizeAppLocation(appLocationId);
}

卡片数据服务读取有效缓存，再根据当前卡片解析出的地点生成模型。当前实现复用应用缓存，不是每张卡片分别向天气上游请求，也不假设服务卡片能像前台页面一样一直挂着计时器。

async updateForm(formId: string): Promise<void> {
  const model: AuroraCardViewModel =
    await this.modelForForm(formId);
  await formProvider.updateForm(
    formId,
    this.binding(formId, model)
  );
}

绑定模型使用 Form Kit：

const payload: AuroraFormBindingPayload = {
  formId: formId,
  modelJson: serializeAuroraCardViewModel(model)
};
return formBindingData.createFormBindingData(
  payload as Object
);

点击卡片，还要把地点传回应用，入口通过 Want 参数恢复对应状态：

postCardAction(this, {
  action: 'router',
  abilityName: 'EntryAbility',
  params: {
    locationId: this.model().locationId
  }
});

桌面看到的是一个地点，打开之后也应该接着看这个地点。只有这样，卡片才真正接进了应用流程。

把查过的地点和参数，也整理到应用里

地点加多之后，又想顺便把资料整理进去。那里是什么地形，适合什么时候去，到地方以后看哪边，查到的这些东西，放在浏览器里迟早又找不到。

于是有了观测地志。首页放不下的，就到这里慢慢看。

地志按区域组织，图片之外保留地点说明和观测参考。北半球与南半球分别处理，不能把所有目的地都写成同一种雪地追光印象。

列表使用 LazyForEach，展开状态用稳定的地点 ID 管理，而不是只记第几个卡片。区域切换、展开收起和返回，都需要核对状态，避免顺序变化后展开了错误的地点。

还有那些一开始把我绕晕的参数，也一起补了说明。现在一共九个主题：观测机会指数、数据置信度、Kp、Bz、太阳风、OVATION、云量、能见度、天色与黑暗。

每一页先写最想知道的结论，再往下解释定义、量程、怎么跟其他指标一起看，以及容易误解的地方。目录和详情共用一套数据结构：

export interface AuroraKnowledgeTopic {
  id: string;
  group: AuroraKnowledgeGroup;
  title: string;
  eyebrow: string;
  summary: string;
  quickTake: string;
  definition: string;
  howToRead: string;
  together: string;
  caution: string;
  source: string;
  bands: AuroraKnowledgeBand[];
}

这样加内容时不用每次重写一页，也比较容易看出哪一项还没写全。平时看首页就行，碰到不认识的参数，再进来翻翻。

引导和设置，让这些功能更容易用起来

第一次打开应用，总得知道从哪里选地点、往哪里看趋势，所以又加了引导。背景还是同一片夜空，可以跳过，想再看就从设置里进去。看过的状态会记住，不能每次打开都重新教一遍。

引导不是多加几页文字就结束，还要检查短滑和完整翻页、最后一步进入首页、系统返回，以及重新打开后的状态。文字、箭头、遮罩和真实可操作区域要对应，不能指向已经换了位置的按钮。

动态效果做出来之后，也得让人能关。极光、视差、星星闪烁分别放了开关，自动刷新也单独控制。设置保存下来，页面再读取它们，决定哪些东西继续跑。

关闭自动刷新后仍保留手动入口，重力视差数据不需要保存和上传。设置页也有重新查看引导的入口。

关于页集中放版本、应用介绍、作者入口和数据来源跳转。它看起来简单，但这些零散信息集中之后，首页就不需要承担所有解释。

手机和折叠屏，不是把同一张图放大

工程用的是 Stage 模型。最开始主要盯着手机做，后来把窗口展开，才发现很多在窄屏上合适的布局，换个宽度就不对了。

适配时，背景保持足够大画幅，宽屏露出更多地景，信息区域则控制阅读宽度。手机保持单列，只有实际内容宽度能容纳两张可读卡片时才考虑两列。

长文本不能横跨整个展开屏，弹窗也不能按手机宽度写死。顶部安全区、挖孔、侧栏贴边和系统返回手势，还得放在一起考虑。宽屏布局先在模拟器里来回调，真正握在手里好不好用，还要继续试。

免费后端，也是从实际需要慢慢搭起来的

页面差不多了，就绕不开数据。

我暂时不想为它先租台服务器，再装数据库、看进程。想了想，现在这些观测数据大家基本都能共用，没必要每来一个人，就重新抓一遍、算一遍。

那就后台统一生成，手机拿现成的。

NOAA SWPC ─────┐
              ├─→ GitHub Actions：抓取、整理、计算、校验
Open-Meteo ────┘                  │
                                 ▼
                            GitHub Pages
                                 │ 校验并镜像
                                 ▼
                         Cloudflare Workers KV
                                 │
                                 ▼
                     Worker → Pages 中继/自定义域名
                                 │
                                 ▼
                      ArkTS 客户端 → 本地有效缓存

这套组合在目前这个阶段，可以用免费方案跑起来，不用另外租服务器。

不过免费也有边界。Actions、Worker 和 KV 都有各自的规则与额度，域名另算；Open-Meteo 的免费接口还有非商业使用限制。后面真要商用，就得重新确认，数据署名也要保留。

参考：GitHub Actions 计费、Workers 定价、KV 限制、Open-Meteo 方案。

空间天气取自 NOAA SWPC，主要包括 Kp、Kp 预报、Bz、太阳风和 OVATION。天气使用 Open-Meteo 的云量与能见度。对应接口配置来自后台 JavaScript：

export const URLS = Object.freeze({
  kpCurrent: 'https://services.swpc.noaa.gov/products/noaa-planetary-k-index.json',
  kpForecast: 'https://services.swpc.noaa.gov/products/noaa-planetary-k-index-forecast.json',
  bz: 'https://services.swpc.noaa.gov/products/summary/solar-wind-mag-field.json',
  speed: 'https://services.swpc.noaa.gov/products/summary/solar-wind-speed.json',
  ovation: 'https://services.swpc.noaa.gov/json/ovation_aurora_latest.json',
  weather: 'https://api.open-meteo.com/v1/forecast'
});

50 个地点的天气按每批 10 个地点处理。返回之后检查数量、坐标和 ID 顺序，全部成功才发布，避免把另一个地点的云量配错过来。单位也需要归一化，例如能见度从米换算成公里，内部比较时间使用 UTC。

上游接口成功返回不代表数据新鲜。构建前检查观测时间，而不是用本次抓取时间把旧观测“刷新”成实时。空间天气各产品更新节奏不同，时效阈值也分开处理。

这个分数到底是怎么算出来的

评分集中放在后台计算，Cloudflare 负责校验与分发，客户端读取结果。这样修改公式时，只需要维护一个地方，同一个地点也不会在不同入口得到不同分数。

项目把空间条件、天空条件和黑夜条件分开：

export function darknessFactor(solarElevation) {
  return clamp((-6 - solarElevation) / 12);
}

export function skyFactor(cloudCover, visibilityKm) {
  return 0.8 * (1 - clamp(cloudCover, 0, 100) / 100) +
    0.2 * clamp((visibilityKm - 2) / 28);
}

export function scoreCurrent(input) {
  const ovation = clamp(input.ovation / 40);
  const kpFit = smoothstep(
    input.referenceKp - 1.5,
    input.referenceKp + 0.5,
    input.currentKp
  );
  const bzBoost = clamp(-input.bzGsm / 12);
  const space = 0.55 * ovation + 0.30 * kpFit + 0.15 * bzBoost;
  return Math.round(
    100 * space *
    skyFactor(input.cloudCover, input.visibilityKm) *
    darknessFactor(input.solarElevation)
  );
}

这些系数是项目的启发式选择，不是 NOAA 官方的地点可见概率模型。未来时段使用预报 Kp、对应时段天气和太阳高度，不把当前 Bz 和 OVATION 一直往后复制。置信度也只是内部数据质量参考，没有做命中率校准。

数据出来了，也不能直接往外发

核心产物是 catalog.json、manifest.json 和 snapshot.json，天气扩展另有对应产物。清单保存生成时间、变旧时间、过期时间、快照路径和 SHA-256。

const snapshotText = JSON.stringify(snapshot) + '\n';
const manifest = {
  schemaVersion: 1,
  generatedAt: snapshot.generatedAt,
  staleAt: new Date(now.getTime() + 20 * MINUTE_MS).toISOString(),
  expiresAt: new Date(now.getTime() + 6 * HOUR_MS).toISOString(),
  snapshotSha256: sha256(snapshotText),
  snapshotPath: '/v1/snapshot.json'
};

哈希基于最终输出文本，包括末尾换行，发布前不能重新格式化另一遍。20 分钟开始标记延迟，6 小时后过期。任务失败时，只允许保留仍然有效且校验通过的旧数据，不发布缺少几个地点的半份结果。

Cloudflare 镜像时再次检查结构、时间、地点数量与顺序以及哈希。内容以哈希作为键写入，最后才更新最新指针：

await env.AURORA_DATA.put(snapshotKey, snapshotText);
await env.AURORA_DATA.put(catalogKey, catalogText);
await env.AURORA_DATA.put(
  'v1/latest.json',
  JSON.stringify(pointer) + '\n'
);

这个顺序减少指针提前推进的风险，但 KV 是最终一致存储，不是跨节点事务。节点暂时读不到内容时仍然可能返回失败，因此客户端保留备用线路。SHA-256 用于内容一致性，也不等于身份签名。

GitHub 当前独立计划是每十分钟执行一次，同时保留手动触发。运行测试、抓取、构建和验证都通过后，才上传 Pages artifact。生成 JSON 不需要每十分钟提交一次，否则 Git 历史很快就会被自动更新占满。

最后接回 ArkTS 这边

手机这边用 NetworkKit。请求单独包了一层，先把文本拿回来，再交给数据仓库检查、缓存和处理回退。页面不用跟 NOAA、天气接口的原始格式直接打交道。

import { http } from '@kit.NetworkKit';

export class HarmonyHttpTransport implements SnapshotTransport {
  async getText(url: string): Promise<string> {
    const client: http.HttpRequest = http.createHttp();
    const options: http.HttpRequestOptions = {
      method: http.RequestMethod.GET,
      expectDataType: http.HttpDataType.STRING,
      usingCache: false,
      connectTimeout: 5000,
      readTimeout: 8000,
      header: { 'Accept': 'application/json' }
    };
    try {
      const response: http.HttpResponse = await client.request(url, options);
      if (response.responseCode < 200 || response.responseCode >= 300 ||
          typeof response.result !== 'string') {
        throw new Error('HTTP ' + response.responseCode.toString());
      }
      return response.result as string;
    } finally {
      client.destroy();
    }
  }
}

读取顺序是 Pages 自定义域名、GitHub Pages、Worker，最后尝试本地有效缓存。先取得 manifest，再取 snapshot，校验通过后才保存缓存。

const pair: CachedPair = {
  manifestText: manifestText,
  snapshotText: snapshotText
};
const result: SnapshotLoadResult = this.result(pair, endpoint.source);
try {
  await this.cache.save(pair);
} catch {
  // 缓存失败不影响已经验证通过的本次结果。
}
return result;

顺序反过来可能把好缓存覆盖成坏数据。读取缓存时也重新验证，不是文件存在就一直可用。页面分别显示实时数据、备用来源、离线缓存或调试数据，并带上数据年龄。

这里必须区分“观测机会为零”和“暂无数据”。前者说明数据有效但条件不好，后者说明当前没有足够有效的信息。后台出故障时，不能装作天气碰巧很差。

正常流程之外，还得处理出错的时候

评分、时效、地点解析和场景序号适合用纯函数测试。比如黑夜与天空因子的边界：

assert.equal(darknessFactor(-5.9), 0);
assert.equal(darknessFactor(-12), 0.5);
assert.equal(darknessFactor(-18), 1);
assert.equal(skyFactor(0, 30), 1);
assert.equal(skyFactor(100, 2), 0);

这些测试只能证明实现符合预设规则，不能证明预测准确。模型效果还需要真实观测数据评估。

发布链路重点模拟哈希错误、地点顺序错、内容写入失败和清理失败；客户端重点看来源回退、过期缓存、卡片实例与地点状态。UI 还要检查长文本、窄屏、展开态、手势中断和前后台切换。

data-pipeline：npm test / npm run verify
cloudflare：npm test
HarmonyOS：hvigorw test --no-daemon
HarmonyOS 构建：hvigorw assembleApp -p product=default --no-daemon

平时改完一块，就用这些入口检查。数据逻辑可以靠固定输入反复跑，手势顺不顺、画面晃不晃，最后还是得拿起来用。

换到新版工具链后，还遇到了一些绘图 API 的兼容性提醒。能编译、能在手边的手机上打开，还不算结束，旧系统上用到这些能力的地方也得继续检查。

做到这里，已经比最初想的多了不少

回头看看，最开始真没打算做这么多。

先有个首页，再加地点和夜景，觉得桌面卡片也挺合适，就接上 Form Kit；数据要持续更新，又把后台搭起来。后面那些知识页和地志，也是边做边补的。

花时间的往往还都是小地方。背景一动，字不能晃；首页换地点，卡片不能跟着乱；数据没更新，也不能装作实时。

慢慢改下来，才有了现在这个样子。

后面继续补实体设备的握持、功耗和不同网络测试，把卡片与折叠屏体验再磨一磨。

最开始只是突然想去看极光。

没想到查着查着，先给自己做了个应用。

等以后真的准备出发，希望打开它的时候，能刚好看到一句：今晚值得等待。