HarmonyOS鸿蒙Next原生工程依赖 Flutter项目打包的HAR，启动后onWindowFocusChanged 不执行

HarmonyOS鸿蒙Next原生工程依赖 Flutter项目打包的HAR，启动后onWindowFocusChanged 不执行

  • Flutter项目中有一个关于获取键盘高度的鸿蒙插件
  • 插件中鸿蒙侧addOnWindowFocusChangedListener，项目启动onWindowFocusChanged正常执行
  • 鸿蒙原生工程依赖 Flutter项目打包的HAR后，项目启动后onWindowFocusChanged不执行了，除非切换一下前台和后台
3 回复

开发者您好，您问题中描述的获取键盘高度的鸿蒙插件，这个插件是三方插件还是你们自己实现的插件，如果是三方的，插件的官方链接麻烦请提供一下，如果是你们自己实现的麻烦提供一下你们实现的关键代码，另外也请提供一下你们测试版本信息（Flutter、DevEco Studio以及测试手机的版本信息）。

更多关于HarmonyOS鸿蒙Next原生工程依赖 Flutter项目打包的HAR，启动后onWindowFocusChanged 不执行的实战系列教程也可以访问 https://www.itying.com/category-92-b0.html


在HarmonyOS Next原生工程中依赖Flutter HAR包后，onWindowFocusChanged回调不执行，通常是由于Flutter引擎的窗口焦点管理机制与原生系统事件未完全同步所致。该问题涉及Flutter插件与鸿蒙窗口生命周期事件的集成适配，可能需检查Flutter Activity或Ability的窗口焦点事件绑定是否完整。

这是一个典型的生命周期监听时机问题，根本原因在于原生工程与HAR（Harmony Archive）模块加载和初始化的时序差异。

核心问题分析：

  1. 监听器注册时机过早：在纯鸿蒙工程中，你的插件代码（在HAR内）可能在Ability的onWindowStageCreate或更早阶段就完成了初始化并注册了onWindowFocusChanged监听器。此时，窗口焦点事件可能已经发生（例如首次获得焦点），但你的监听器尚未就绪，因此错过了最初的调用。
  2. HAR延迟加载与事件队列：当原生工程依赖HAR时，HAR模块的初始化可能发生在主Ability生命周期之后。onWindowFocusChanged是一个瞬时事件，在窗口首次获得焦点时触发。如果HAR中的监听器注册发生在该事件之后，自然无法捕获到首次事件。
  3. 前后台切换为何有效：当应用切换至后台再回到前台时，会再次触发onWindowFocusChanged事件。此时你的监听器早已注册完毕，因此能够正常捕获并执行。

解决方案：

你需要确保监听器的注册发生在窗口获得焦点之前，并且与鸿蒙原生工程的生命周期正确同步。推荐以下两种方法：

方法一：在HAR模块中提供显式初始化接口 在HAR的入口类或插件类中，提供一个公开的初始化方法（例如init()）。让鸿蒙原生工程在其Ability的onWindowStageCreate方法中，显式调用这个初始化方法。这样可以确保HAR中的监听器在窗口准备就绪、即将获得焦点前完成注册。

// 在HAR中
public class YourFlutterPlugin {
    public static void init(Window window) {
        // 在此处注册 onWindowFocusChanged 监听器
        window.addOnWindowFocusChangedListener(...);
    }
}

// 在原生工程的 Ability 中
public class MainAbility extends Ability {
    @Override
    public void onWindowStageCreate(WindowStage windowStage) {
        super.onWindowStageCreate(windowStage);
        // ... 其他设置 ...
        // 关键：显式初始化HAR插件，传入Window对象
        YourFlutterPlugin.init(windowStage.getWindow());
    }
}

方法二：监听更早的生命周期事件 如果无法修改原生工程，可以考虑在HAR内部寻找更早的、且必然在首次onWindowFocusChanged之前触发的时机。例如，尝试在HAR的初始化逻辑中，监听onWindowStageCreated事件（如果HAR能获取到WindowStage的话），或者利用鸿蒙的UIAbilityContext进行更精细的生命周期管理。但这种方法依赖于HAR能获取到必要的上下文对象，通用性可能不如方法一。

总结： 优先采用方法一。问题的关键在于由原生工程主导，在合适的生命周期阶段“通知”HAR模块进行关键监听器的注册，从而解决因模块加载时序导致的首次事件丢失问题。

回到顶部