HarmonyOS 鸿蒙Next @Entry组件的销毁过程解释

发布于 1周前 作者 itying888 来自 鸿蒙OS

HarmonyOS 鸿蒙Next @Entry组件的销毁过程解释

  1. 触发销毁的场景

    • 应用关闭
      • 当整个应用程序被关闭时,@Entry组件作为应用的入口和核心组件,会被销毁。这是最常见的情况。例如,在移动应用中,当用户通过系统的关闭按钮或者任务管理器关闭应用时,操作系统会通知应用进行清理和资源回收,此时@Entry组件会经历销毁过程。
    • 页面导航替换
      • 如果应用采用了复杂的页面导航架构,当从@Entry组件所代表的初始页面导航到一个全新的、完全替代初始页面的页面时,@Entry组件可能会被销毁。比如,在一个单页应用(SPA)中,从登录页面(@Entry组件)成功登录后,直接跳转到一个主内容页面,且这个主内容页面的加载方式是替换登录页面而不是将其隐藏在后台,那么登录页面(@Entry组件)就会被销毁。
  2. 销毁过程中的操作

    • 资源释放
      • @Entry组件会释放它所占用的各种资源。这包括但不限于内存资源、文件句柄、网络连接等。例如,在组件运行过程中可能会加载一些图片资源,这些图片资源在内存中的缓存会被清除;如果组件在生命周期中有建立网络连接用于数据获取,那么这个网络连接会被关闭,以防止资源泄漏。
    • 事件解绑
      • 它会解除绑定的各种事件监听器。在组件存在期间,可能会对用户的操作(如点击、滑动等)或者系统事件(如设备方向改变、网络状态变化等)进行监听。在销毁时,这些事件监听器会被移除,以避免在组件不存在的情况下仍然响应事件导致程序错误。例如,如果有一个对按钮点击事件的监听器,在组件销毁时,这个监听器会从按钮元素上移除。
    • 子组件销毁
      • 如果@Entry组件包含子组件,那么这些子组件也会依次经历销毁过程。这个过程是递归的,从最底层的子组件开始,向上依次销毁。例如,一个包含列表组件的@Entry组件,列表组件中的每一个列表项(作为子组件)都会先被销毁,然后才是列表组件本身,最后是@Entry组件。这个过程确保了整个组件树的资源都得到了合理的回收。
  3. 与其他组件和系统的交互

    • 通知父组件或系统
      • @Entry组件在销毁过程中可能会向其所属的父组件(如果存在)或者系统发出通知。这个通知可以用于更新其他相关组件的状态或者让系统知道资源已经被释放。例如,在一个组件化的应用框架中,当@Entry组件被销毁后,系统可以根据这个通知调整内存分配策略或者更新应用的导航历史记录。
    • 清理与其他组件的关联
      • 它会清理与其他组件之间的关联和引用。如果@Entry组件与其他组件之间存在数据共享、消息传递等关系,这些关联会被切断。例如,在一个使用状态管理库的应用中,@Entry组件与其他组件可能通过共享状态进行通信,在销毁时,它会从共享状态中移除自己的引用,以确保其他组件不会访问到已经不存在的@Entry组件的数据。


更多关于HarmonyOS 鸿蒙Next @Entry组件的销毁过程解释的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html

7 回复
感谢楼主分享

更多关于HarmonyOS 鸿蒙Next @Entry组件的销毁过程解释的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html


页面生命周期:onPageShow、onPageHide、onBackPress。

页面,说白了就是[@Entry](/user/Entry)修饰的组件,才称之为页面。

onPageShow:页面每次显示时触发一次,包括路由过程、应用进入前台等场景,仅[@Entry](/user/Entry)装饰的自定义组件生效。

onPageHide:页面每次隐藏时触发一次,包括路由过程、应用进入后台等场景,仅[@Entry](/user/Entry)装饰的自定义组件生效。

onBackPress:当用户点击返回按钮时触发,仅[@Entry](/user/Entry)装饰的自定义组件生效。

有要学HarmonyOS AI的同学吗,联系我:https://www.itying.com/goods-1206.html

页面的生命周期有哪些?

  1. 创建阶段(Creation)
    • 组件初始化(Component Initialization)
      • 这是页面生命周期的起始点。当页面首次加载时,相关的组件会被创建。这个过程包括分配内存来存储组件的状态和属性。例如,在一个使用JavaScript框架构建的网页中,组件对象会在内存中被实例化,它的构造函数会被调用,初始化组件的初始状态,如设置默认的文本内容、初始的样式属性等。
    • 数据获取(Data Fetching)
      • 在组件初始化后,通常会进行数据获取操作。如果页面需要展示数据,如从服务器获取用户信息、商品列表等,会在这个阶段发起请求。例如,在一个电商网页中,页面加载时会发送API请求到服务器获取商品分类和热门商品信息,这些数据将用于填充页面的相应部分,如商品列表区域和分类导航栏。
    • 视图构建(View Construction)
      • 根据获取的数据和组件的初始状态,开始构建页面的视图。这涉及到将组件的HTML(或其他标记语言)模板与数据进行结合,生成最终呈现给用户的页面内容。例如,使用模板引擎将获取的商品信息填充到商品列表组件的HTML模板中,生成包含实际商品信息的列表项,从而构建出完整的商品列表视图。
  2. 挂载阶段(Mounting)
    • DOM插入(DOM Insertion)
      • 构建好的视图会被插入到文档对象模型(DOM)中。在网页环境中,这意味着页面元素会被添加到浏览器的DOM树中,成为可见的页面内容。例如,当一个新的组件视图构建完成后,它会被添加到页面的特定位置,如一个模态框组件会被插入到页面的主体部分,使其在页面上显示出来。
    • 样式计算与应用(Style Calculation and Application)
      • 插入DOM后,浏览器会计算组件的样式。这包括解析CSS样式规则,根据选择器确定每个组件的样式属性,同时考虑继承、优先级等因素。例如,对于一个具有自定义样式的按钮组件,浏览器会计算其背景颜色、字体大小等样式属性,并将其应用到组件上,使其按照预期的样式显示。
    • 布局计算(Layout Calculation)
      • 接着进行布局计算,确定每个组件在页面中的位置和尺寸。浏览器会根据组件的类型、样式属性(如宽度、高度、浮动、定位等)以及页面的整体布局规则来安排组件的位置。例如,在一个响应式网页中,根据屏幕的宽度和组件的布局方式(如流式布局或弹性布局),计算出每个组件应该占据的空间大小和位置,以实现页面的合理布局。
  3. 更新阶段(Updating)
    • 数据更新(Data Update)
      • 当页面的数据发生变化时,会触发更新阶段。这可能是由于用户的操作(如提交表单、点击按钮等)或者服务器推送了新的数据。例如,在一个社交网页中,用户发布了一条新的动态,服务器将新动态的数据发送给客户端,客户端收到数据后需要更新页面上的动态列表部分。
    • 组件重新渲染(Component Re - rendering)
      • 数据更新后,相关的组件通常需要重新渲染。这可能涉及到重新执行组件的模板渲染函数,将新的数据与模板结合生成新的视图内容。例如,对于一个使用数据绑定的文本组件,当绑定的数据发生变化时,组件会根据新的数据重新生成文本内容并更新到页面上。
    • DOM更新(DOM Update)
      • 重新渲染后的视图内容需要更新到DOM中。这个过程可能是部分更新,即只更新发生变化的组件部分,而不是整个页面。例如,在一个具有多个选项卡的页面中,当用户切换选项卡时,只需要更新当前选项卡的内容,而不是重新加载整个页面,这样可以提高页面更新的效率。
  4. 卸载阶段(Unmounting)
    • 事件解绑(Event Unbinding)
      • 当页面要被卸载时,首先要做的是解绑所有绑定在组件上的事件监听器。这是为了防止在组件被移除后,仍然响应事件而导致的错误。例如,一个包含按钮点击事件监听器的组件,在卸载时会将这个监听器从按钮元素上移除。
    • 资源清理(Resource Cleanup)
      • 然后清理组件占用的各种资源。这包括释放内存中的数据对象、关闭网络连接(如果有)、清除定时器等。例如,一个在页面加载时创建了定时器来定期更新数据的组件,在卸载时会清除这个定时器,以避免资源浪费和潜在的错误。
    • DOM移除(DOM Removal)
      • 最后,将组件从DOM树中移除,使页面不再显示该组件。这是卸载阶段的最后一步,完成后,页面的布局和内容会相应地调整,以适应组件的移除。例如,在一个动态加载和卸载组件的单页应用中,当一个模态框组件被卸载后,页面会恢复到没有模态框的状态,其他组件的布局会重新调整以填充原来模态框占据的空间。

[@Entry](/user/Entry)组件的销毁顺序是怎样的?

  1. 子组件销毁优先原则
    • 当[@Entry](/user/Entry)组件开始销毁过程时,首先会销毁它所包含的子组件。这是一个从叶子节点(最底层的子组件)向根节点([@Entry](/user/Entry)组件本身)的递归过程。例如,如果[@Entry](/user/Entry)组件包含一个复杂的布局,其中有文本组件、按钮组件和列表组件,那么会先销毁列表组件中的每一个列表项(这些是最底层的子组件)。
    • 对于每一个子组件,它自身也会按照内部的结构顺序进行销毁。比如一个自定义的复合子组件,内部包含了数据绑定部分和UI展示部分,会先清理数据绑定相关的资源(如解除数据观察关系),然后再销毁UI展示相关的元素。
  2. 组件内部资源释放顺序
    • 资源清理顺序
      • 在子组件销毁过程中,每个子组件会先释放自身占用的资源。这些资源包括但不限于内存中的数据对象(如通过接口获取并存储在本地的数据)、图形资源(如加载的图标、图片等)和样式资源(如动态添加的样式类)。以一个加载了网络图片的子组件为例,它会先取消图片的加载请求(如果正在进行),然后释放内存中已加载的图片缓存。
      • 接着会解除与该子组件绑定的事件监听器。事件监听器可能包括用户交互事件(如点击、长按、滑动等)和系统事件(如屏幕旋转、应用进入后台等)。例如,一个带有按钮的子组件会先移除按钮上的点击事件监听器,以防止在组件销毁后还可能触发的异常事件响应。
    • 数据绑定断开
      • 如果子组件涉及数据绑定,会先断开数据绑定关系。在使用数据驱动的框架中,子组件可能与外部的数据源(如全局状态管理中的某个状态变量)建立了双向或单向的数据绑定。在销毁时,会先确保这种数据绑定关系被正确断开,以避免数据更新时引发错误。例如,一个文本输入子组件绑定了一个外部的用户信息变量,在销毁时会先解除这个绑定,防止后续对该变量的修改影响到已经不存在的组件。
  3. [@Entry](/user/Entry)组件自身销毁
    • 在所有子组件都完成销毁后,[@Entry](/user/Entry)组件会开始销毁自身。它会首先释放自身占用的资源,这包括组件的状态数据(如存储的用户登录状态、页面加载进度等)、样式资源(如应用级别的主题样式引用)和布局资源(如与布局相关的尺寸计算缓存等)。
    • 然后,[@Entry](/user/Entry)组件会解除与外部系统或其他组件的关联。这可能包括关闭与后端服务器的连接(如果有)、清理与其他页面组件的导航关系等。例如,如果[@Entry](/user/Entry)组件是一个登录页面,它可能与后端的用户认证服务建立了连接,在销毁时会关闭这个连接,同时清除与后续主页面的导航过渡相关的缓存信息。
    • 最后,[@Entry](/user/Entry)组件会通知系统或上层框架它已经完成销毁,系统可以根据这个通知进行进一步的资源管理和状态更新操作,如回收分配给该组件的内存空间,更新应用的组件树状态记录等。

在HarmonyOS鸿蒙系统中,@Entry组件的销毁过程是一个涉及系统资源回收和生命周期管理的复杂机制。当@Entry组件不再需要时,系统会触发销毁流程,以释放相关资源。

具体而言,销毁过程通常从组件的onDestroy生命周期方法开始。此时,系统会调用该方法,允许开发者执行必要的清理工作,如取消网络请求、停止动画、释放资源等。在这一阶段,组件的视图层次结构依然存在,但已经不可见且不再与用户交互。

随后,系统会进一步回收与@Entry组件相关的内存和资源。这包括释放组件所占用的内存空间、取消其注册的事件监听器、移除其持有的其他资源引用等。这些操作确保了系统资源的有效利用,防止内存泄漏和性能下降。

值得注意的是,@Entry组件的销毁过程并非总是由用户操作触发。在某些情况下,如系统资源不足或组件被动态移除时,系统也会主动销毁@Entry组件以释放资源。

如果开发者需要深入了解@Entry组件销毁过程中的具体细节和机制,建议查阅HarmonyOS官方文档。如果问题依旧没法解决请联系官网客服,官网地址是:https://www.itying.com/category-93-b0.html

回到顶部