鸿蒙（harmonyNEXT）口试可能问到的知识点的一点汇总

鸿蒙生命周期

1.UIAbility组件生命周期

包含四个，分别为Create、Foreground、Background、Destroy四个状态
其中onCreate创建完成后，会进入onWindowStageCreate()回调，可以在onWindowStageCreate()回调中通过loadContent()方法设置应用要加载的页面并根据需要订阅WindowStage的事件（获焦，失焦，可见，不可见）
在UIAbility实例烧毁之前会进入onWindowStageDestroy()回调，可以释放UI界面资源。

2.页面和自界说组件生命周期

2.1页面生命周期

页面：即应用的UI页面。可以由一个大概多个自界说组件构成，@Entry装饰的自界说组件为页面的入口组件，即页面的根节点，一个页面有且仅能有一个@Entry。只有被@Entry装饰的组件才可以调用页面的生命周期。
页面生命周期，即被@Entry装饰的组件生命周期，提供以下生命周期接口：

• onPageShow：页面每次显示时触发一次，包括路由过程、应用进入前台等场景。
  
• onPageHide：页面每次隐藏时触发一次，包括路由过程、应用进入后台等场景。
  
• onBackPress：当用户点击返回按钮时触发。
  

2.2自界说组件生命周期

即一般用@Component装饰的自界说组件的生命周期，提供以下生命周期接口：

• aboutToAppear：组件即将出现时回调该接口，具体时机为在创建自界说组件的新实例后，在实行其build()函数之前实行。
  
• aboutToDisappear：在自界说组件析构烧毁之前实行。不答应在aboutToDisappear函数中改变状态变量，特别是@Link变量的修改可能会导致应用程序行为不稳固。
  

生命周期流程如下图所示，下图展示的是被@Entry装饰的组件（页面）生命周期。

3.Navigation路由容器生命周期

Navigation作为路由容器，其生命周期承载在NavDestination组件上，以组件事件的形式开放。
其生命周期大致可分为三类，自界说组件生命周期、通用组件生命周期和自有生命周期（其中aboutToAppear和aboutToDisappear是自界说组件的生命周期。假如NavDestination外层包含自界说组件时则存在；OnAppear和OnDisappear是组件的通用生命周期，剩下的六个生命周期为NavDestination独有）。
生命周期时序如下图所示：

• aboutToAppear：在创建自界说组件后，实行其build()函数之前实行（NavDestination创建之前），答应在该方法中改变状态变量，更改将在后续实行build()函数中生效。
  
• onWillAppear：NavDestination创建后，挂载到组件树之前实行，在该方法中更改状态变量会在当前帧显示生效。
  
• onAppear：通用生命周期事件，NavDestination组件挂载到组件树时实行。
  
• onWillShow：NavDestination组件布局显示之前实行，此时页面不可见（应用切换到前台不会触发）。
  
• onShown：NavDestination组件布局显示之后实行，此时页面已完成布局。
  
• onWillHide：NavDestination组件触发隐藏之前实行（应用切换到后台不会触发）。
  
• onHidden：NavDestination组件触发隐藏后实行（非栈顶页面push进栈，栈顶页面pop出栈或应用切换到后台）。
  
• onWillDisappear：NavDestination组件即将烧毁之前实行，假如有转场动画，会在动画前触发（栈顶页面pop出栈）。
  
• onDisappear：通用生命周期事件，NavDestination组件从组件树上卸载烧毁时实行。
  
• aboutToDisappear：自界说组件析构烧毁之前实行，不答应在该方法中改变状态变量。
  

其中自界说组件生命周期为aboutToAppear和aboutToDisappear是自界说组件的生命周期。假如NavDestination外层包含自界说组件时则存在；
通用组件生命周期为onAppear和onDisappear；
其余的为自有生命周期。
 
路由跳转

鸿蒙中跳转主要有两种，一种是router，一种是Navigation
1.router

Router实用于模块间与模块内页面切换，通过每个页面的url实现模块间解耦。模块内页面跳转时，为了实现更好的转场动效场景不建议使用该模块，保举使用Navigation。
Router模块提供了两种跳转模式，分别是router.pushUrl()和router.replaceUrl()。这两种模式决定了目的页面是否会替换当前页。
同时，Router模块提供了两种实例模式，分别是Standard和Single。这两种模式决定了目的url是否会对应多个实例。

• router.pushUrl()：目的页面不会替换当前页，而是压入页面栈。如允许以保留当前页的状态，并且可以通过返回键大概调用router.back()方法返回到当前页。
  

• router.replaceUrl()：目的页面会替换当前页，并烧毁当前页。如允许以释放当前页的资源，并且无法返回到当前页。
  

页面栈的最大容量为32个页面。假如超过这个限定，可以调用router.clear()方法清空汗青页面栈，释放内存空间。
同时，Router模块提供了两种实例模式，分别是Standard和Single。这两种模式决定了目的url是否会对应多个实例。

• Standard：多实例模式，也是默认情况下的跳转模式。目的页面会被添加到页面栈顶，无论栈中是否存在相同url的页面。
  
• Single：单实例模式。假如目的页面的url已经存在于页面栈中，则会将离栈顶迩来的同url页面移动到栈顶，该页面成为新建页。假如目的页面的url在页面栈中不存在同url页面，则按照默认的多实例模式进行跳转。
  

2.Navigation

Navigation是路由容器组件，一般作为首页的根容器，包括单栏(Stack)、分栏(Split)和自适应(Auto)三种显示模式。Navigation组件实用于模块内和跨模块的路由切换，一次开辟，多端摆设场景。通过组件级路由本领实现更加自然流通的转场体验，并提供多种标题栏样式来出现更好的标题和内容联动效果。在差别尺寸的设备上，Navigation组件能够自适应显示大小，自动切换分栏展示效果。
Navigation组件主要包含​导航页(NavBar)和子页(NavDestination)。导航页由标题栏(Titlebar，包含菜单栏menu)、内容区(Navigation子组件)和工具栏(Toolbar)构成，其中导航页可以通过hideNavBar属性进行隐藏，导航页不存在页面栈中，导航页和子页，以及子页之间可以通过路由操纵进行切换。
在API Version 9上，需要配合NavRouter组件实现页面路由，从API Version 10开始，保举使用NavPathStack实现页面路由。
Navigation组件通过mode属性设置页面的显示模式。

• 自适应模式
  

Navigation组件默认为自适应模式，此时mode属性为NavigationMode.Auto。自适应模式下，当页面宽度大于便是肯定阈值( API version 9及以前：520vp，API version 10及以后：600vp )时，Navigation组件采用分栏模式，反之采用单栏模式。

• 单页面模式
  

将mode属性设置为NavigationMode.Stack，Navigation组件即可设置为单页面显示模式。

• 分栏模式
  

将mode属性设置为NavigationMode.Split，Navigation组件即可设置为分栏显示模式。
3.Navigation与Router对比

当前HarmonyOS支持两套路由机制（Navigation和Router），Navigation作为后续恒久演进及保举的路由选择方案，其与Router比力的优势如下：

• 易用性层面：
  

• Navigation自然具备标题、内容、回退按钮的功能联动，开辟者可以直接使用此本领。Router若要实现此本领，需要自行界说；
  
• Navigation的页面是由组件构成，易于实现共享元素的转场。
  

• 功能层面：
  

• Navigation自然支持一多，Router不支持；
  
• Navigation没有路由数目限定，Router限定32个；
  
• Navigation可以获取到路由栈NavPathStack，并对路由栈进行操纵；
  
• Navigation可以嵌套在模态对话框中，也就是说可以模态框中界说路由，Router不支持；
  
• Navigation的组件全量由开辟者自行控制，开辟者可以自界说复杂的动效和属性的设置（配景、含糊等），Router的page对象不对外暴露，开辟者无法对page进行处理。
  

• 性能层面
  

• Navigation通报参数性能更优，Navigation通过引用通报，Router通过深拷贝完成；
  
• Navigation可以配合动态加载，实现组件动态加载，Router页面使用@Entry进行修饰，当前模块加载时会生成全量页面。
  

avigation & Router布局对比

• Navigation中的每个页面，承载在一个page里，通过NavDestination容器实现基于组件的页面跳转。
  
• Router的每一个页面设置在一个单独的page中，通过@Entry进行标识。
  

使用选择
假如项目只有一个主项目，没有拆分模块，直接用Navigation即可。
假如项目包含模块，比如项目有主项目，A、B模块，主项目的H界面要跳转到A模块的I界面，大概A模块的I界面要跳转到B模块的J界面，这个时候就要用router。但是主项目里的M界面跳转主项目里的N界面，大概A模块的O界面跳转A模块的P界面，这种属于同模块内的差别界面，可以用Navgation。
总结：同模块用Navgation，差别模块用router
常用装饰器

@Entry
表示页面的入口，装饰struct
@Component
装饰struct，表示具有基于组件的本领，包管内部包含一个且只能包含一个build()函数，用于绘制UI界面
@State
来装饰变量的装饰器( 其实就是用于界说变量 )，必须本地初始化数据, 支持通过构造函数赋值，当State值修改，所在build方法会被重新调用
@Prop
继承@State的功能，界说时不需要本地直接初始化，调用子组件时需要对其进行赋值，被修饰的变量创建和父组件单向同步关系，@Prop可变但不会传回父组件，父组件变化@Prop被覆盖
@Link
@Link 装饰的变量和父组件会构建双向同步关系，子组件使用 @Link 界说变量的时候不需要赋值, 而是调用子组件的时候进行赋值，调用子组件赋值的时候使用 "$变量名" 的形式进行赋值，@Link 装饰器不能再 @Entry 装饰的自界说组件中使用。
@Provide 和 @Consume
假如层级过高的话, 在父子组件之间进行数据通报的话, @State/@Link使用起来就比力麻烦，我们可以使用 @Provide 和 @Consume 进行跨组件数据通报。
使用发布订阅模式, 父类使用 @Provide, 其他需要观察的子类使用 @Consume, 就可以实现双向绑定
当层级很深时, 不需要一层一层通报数据, 直接使用发布订阅进行监听就能实现相同的效果
@Provide 和 @Consume 可以通过相同的变量名大概相同的变量别名绑定, 但是变量类型必须相同
@Provide 必须设置初始值, @Consume 不可以设置默认初始值
@Provide 修饰的变量和 @Consume 修饰的变量可以是一对多的关系
@Watch
观察者装饰器，当监控的变量发生变化，函数触发
@Builder
@Builder 是 ArkUI 提供的一种更加轻量的复用机制
因为在 @Component 内能且只能创建一个 build() 函数
我们可以在组件内使用 @Builder 装饰器自界说一个构建函数
@Builder 创建的构建函数遵循 build() 函数的语法规则, 并且可以在 build() 函数内调用
@Styles
样式的复用
持久化存储

应用数据持久化，是指应用将内存中的数据通过文件或数据库的形式保存到设备上。内存中的数据形态通常是任意的数据布局或数据对象，存储介质上的数据形态可能是文本、数据库、二进制文件等。
HarmonyOS标准系统支持范例的存储数据形态，包括用户首选项、键值型数据库、关系型数据库。

• 用户首选项（Preferences）：通常用于保存应用的设置信息。数据通过文本的形式保存在设备中，应用使用过程中会将文本中的数据全量加载到内存中，以是访问速度快、效率高，但不得当需要存储大量数据的场景。
  
• 键值型数据库（KV-Store）：一种非关系型数据库，其数据以“键值”对的形式进行构造、索引和存储，其中“键”作为唯一标识符。得当很少数据关系和业务关系的业务数据存储，同时因其在分布式场景中降低了办理数据库版本兼容问题的复杂度，和数据同步过程中冲突办理的复杂度而被广泛使用。相比于关系型数据库，更容易做到跨设备跨版本兼容。
  
• 关系型数据库（RelationalStore）：一种关系型数据库，以行和列的形式存储数据，广泛用于应用中的关系型数据的处理，包括一系列的增、删、改、查等接口，开辟者也可以运行自己界说的SQL语句来满足复杂业务场景的需要。
  

具体的实现有：
1.用户首选项

用户首选项为应用提供Key-Value键值型的数据存储本领，支持应用持久化轻量级数据，并对其进行增删除改查等。该存储对象中的数据会被缓存在内存中，因此它可以获得更快的存取速度，下面具体先容下用户首选项的开辟过程。
用户首选项的特点是：
1、以Key-Value形式存储数据
Key是不重复的关键字，Value是数据值。
2、非关系型数据库
区别于关系型数据库，它不包管遵循ACID（Atomicity, Consistency, Isolation and Durability）特性，数据之间无关系。
历程中每个文件对应一个Preferences实例，应用获取到实例后，可以从中读取数据，大概将数据存入实例中。通过调用flush方法可以将实例中的数据回写到文件里。

与关系数据库的区别

分类	关系型数据库	用户首选项
数据库类型	关系型	非关系型
使用场景	提供复杂场景下的本地数据库管理机制	对Key-Value布局的数据进行存取和持久化操纵
存储方式	SQLite数据库	文件
束缚与限定	1.连接池最大4个 2.同一时间只支持一个写操纵	1.建议数据不超一万条 2.Key为string型

作用：
当用户希望有一个全局唯一存储数据的地方，可以采用用户首选项来进行存储。
应用首选项的持久化文件保存在应用沙箱内部，可以通过context获取其路径。
首选项实用于存储小型设置项数据，比方应用的用户个性化设置（字体大小、是否开启夜间模式等）。
限定束缚：

• 首选项无法包管历程并发安全，会有文件破坏和数据丢失的风险，不支持在多历程场景下使用。
  
• Key键为string类型，要求非空且长度不超过1024个字节。
  
• 假如Value值为string类型，请使用UTF-8编码格式，可以为空，不为空时长度不超过16 * 1024 * 1024个字节。
  
• 内存会随着存储数据量的增大而增大，以是存储的数据量应该是轻量级的，建议存储的数据不超过一万条，否则会在内存方面产生较大的开销。
  

2.键值型数据库

键值型数据库存储键值对形式的数据，当需要存储的数据没有复杂的关系模子，比如存储商品名称及对应代价、员工工号及本日是否已出勤等，由于数据复杂度低，更容易兼容差别数据库版本和设备类型，因此保举使用键值型数据库持久化此类数据。
束缚限定

• 设备协同数据库，针对每条记录，Key的长度≤896 Byte，Value的长度<4 MB。
  
• 单版本数据库，针对每条记录，Key的长度≤1 KB，Value的长度<4 MB。
  
• 每个应用程序最多支持同时打开16个键值型分布式数据库。
  
• 键值型数据库事件回调方法中不答应进行壅闭操纵，比方修改UI组件。
  

若要使用键值型数据库，首先要获取一个KVManager实例，用于管理数据库对象。
3.关系型数据库

关系型数据库基于SQLite组件，实用于存储包含复杂关系数据的场景，比如一个班级的学生信息，需要包括姓名、学号、各科成绩等，又大概公司的雇员信息，需要包括姓名、工号、职位等，由于数据之间有较强的对应关系，复杂程度比键值型数据更高，此时需要使用关系型数据库来持久化保存数据。
束缚限定

• 系统默认日志方式是WAL（Write Ahead Log）模式，系统默认落盘方式是FULL模式。
  
• 数据库中有4个读连接和1个写连接，线程获取到空闲读连接时，即可进行读取操纵。当没有空闲读连接且有空闲写连接时，会将写连接当做读连接来使用。
  
• 为包管数据的准确性，数据库同一时间只能支持一个写操纵。
  
• 当应用被卸载完成后，设备上的干系数据库文件及暂时文件会被自动清除。
  
• ArkTS侧支持的基本数据类型：number、string、二进制类型数据、boolean。
  
• 为包管插入并读取数据成功，建议一条数据不要超过2M。超出该大小，插入成功，读取失败。
  

使用关系型数据库实现数据持久化，需要获取一个RdbStore，其中包括建库、建表、升降级等操纵。
4.状态存储

假如开辟者要实现应用级的，大概多个页面的状态数据共享，就需要用到应用级别的状态管理的概念。ArkTS根据差别特性，提供了多种应用状态管理的本领：

• LocalStorage：页面级UI状态存储，通常用于UIAbility内、页面间的状态共享。
  
• AppStorage：特殊的单例LocalStorage对象，由UI框架在应用程序启动时创建，为应用程序UI状态属性提供中央存储。
  
• PersistentStorage：持久化存储UI状态，通常和AppStorage配合使用，选择AppStorage存储的数据写入磁盘，以确保这些属性在应用程序重新启动时的值与应用程序关闭时的值相同。
  
• Environment：应用程序运行的设备的环境参数，环境参数会同步到AppStorage中，可以和AppStorage搭配使用。
  

4.1 LocalStorage

LocalStorage是页面级的UI状态存储，通过@Entry装饰器接收的参数可以在页面内共享同一个LocalStorage实例。LocalStorage支持UIAbility实例内多个页面间状态共享。
LocalStorage是ArkTS为构建页面级别状态变量提供存储的内存内的“数据库”。

• 应用程序可以创建多个LocalStorage实例，LocalStorage实例可以在页面内共享，也可以通过GetShared接口，实现跨页面、UIAbility实例内共享。
  
• 组件树的根节点，即被@Entry装饰的@Component，可以被分配一个LocalStorage实例，此组件的全部子组件实例将自动获得对该LocalStorage实例的访问权限。
  
• 被@Component装饰的组件最多可以访问一个LocalStorage实例和AppStorage，未被@Entry装饰的组件不可被独立分配LocalStorage实例，只能担当父组件通过@Entry通报来的LocalStorage实例。一个LocalStorage实例在组件树上可以被分配给多个组件。
  
• LocalStorage中的全部属性都是可变的。
  

应用程序决定LocalStorage对象的生命周期。当应用释放最后一个指向LocalStorage的引用时，比如烧毁最后一个自界说组件，LocalStorage将被JS Engine垃圾接纳。
LocalStorage根据与@Component装饰的组件的同步类型差别，提供了两个装饰器：

• @LocalStorageProp：@LocalStorageProp装饰的变量与LocalStorage中给定属性创建单向同步关系。
  
• @LocalStorageLink：@LocalStorageLink装饰的变量与LocalStorage中给定属性创建双向同步关系。
  

限定条件

• LocalStorage创建后，定名属性的类型不可更改。后续调用Set时必须使用相同类型的值。
  
• LocalStorage是页面级存储，getShared接口仅能获取当前Stage通过windowStage.loadContent传入的LocalStorage实例，否则返回undefined。例子可见将LocalStorage实例从UIAbility共享到一个或多个视图。
  

4.2 AppStorage

AppStorage是应用全局的UI状态存储，是和应用的历程绑定的，由UI框架在应用程序启动时创建，为应用程序UI状态属性提供中央存储。
和AppStorage差别的是，LocalStorage是页面级的，通常应用于页面内的数据共享。而AppStorage是应用级的全局状态共享，还相当于整个应用的“中枢”，持久化数据PersistentStorage和环境变量Environment都是通过AppStorage中转，才可以和UI交互。
AppStorage是在应用启动的时候会被创建的单例。它的目的是为了提供应用状态数据的中心存储，这些状态数据在应用级别都是可访问的。AppStorage将在应用运行过程保留其属性。属性通过唯一的键字符串值访问。
AppStorage可以和UI组件同步，且可以在应用业务逻辑中被访问。
AppStorage支持应用的主线程内多个UIAbility实例间的状态共享。
AppStorage中的属性可以被双向同步，数据可以是存在于本地或远程设备上，并具有差别的功能，比如数据持久化（详见PersistentStorage）。这些数据是通过业务逻辑中实现，与UI解耦，假如希望这些数据在UI中使用，需要用到@StorageProp和@StorageLink。
4.3 PersistentStorage

LocalStorage和AppStorage都是运行时的内存，但是在应用退出再次启动后，依然能保存选定的效果，是应用开辟中非经常见的征象，这就需要用到PersistentStorage。
PersistentStorage是应用程序中的可选单例对象。此对象的作用是持久化存储选定的AppStorage属性，以确保这些属性在应用程序重新启动时的值与应用程序关闭时的值相同。
概述
PersistentStorage将选定的AppStorage属性保留在设备磁盘上。应用程序通过API，以决定哪些AppStorage属性应借助PersistentStorage持久化。UI和业务逻辑不直接访问PersistentStorage中的属性，全部属性访问都是对AppStorage的访问，AppStorage中的更改会自动同步到PersistentStorage。
PersistentStorage和AppStorage中的属性创建双向同步。应用开辟通常通过AppStorage访问PersistentStorage，另外另有一些接口可以用于管理持久化属性，但是业务逻辑始终是通过AppStorage获取和设置属性的。
限定条件
PersistentStorage答应的类型和值有：

• number, string, boolean, enum 等简单类型。
  
• 可以被JSON.stringify()和JSON.parse()重构的对象，但是对象中的成员方法不支持持久化。
  
• API12及以上支持Map类型，可以观察到Map整体的赋值，同时可通过调用Map的接口set, clear, delete 更新Map的值。且更新的值被持久化存储。详见装饰Map类型变量。
  
• API12及以上支持Set类型，可以观察到Set整体的赋值，同时可通过调用Set的接口add, clear, delete 更新Set的值。且更新的值被持久化存储。详见装饰Set类型变量。
  
• API12及以上支持Date类型，可以观察到Date整体的赋值，同时可通过调用Date的接口setFullYear, setMonth, setDate, setHours, setMinutes, setSeconds, setMilliseconds, setTime, setUTCFullYear, setUTCMonth, setUTCDate, setUTCHours, setUTCMinutes, setUTCSeconds, setUTCMilliseconds 更新Date的属性。且更新的值被持久化存储。详见装饰Date类型变量。
  
• API12及以上支持undefined 和 null。
  
• API12及以上支持联合类型。
  

PersistentStorage不答应的类型和值有：

• 不支持嵌套对象（对象数组，对象的属性是对象等）。因为目前框架无法检测AppStorage中嵌套对象（包括数组）值的变化，以是无法写回到PersistentStorage中。
  

持久化数据是一个相对缓慢的操纵，应用程序应避免以下情况：

• 持久化大型数据集。
  
• 持久化经常变化的变量。
  

PersistentStorage的持久化变量最好是小于2kb的数据，不要大量的数据持久化，因为PersistentStorage写入磁盘的操纵是同步的，大量的数据本地化读写会同步在UI线程中实行，影响UI渲染性能。假如开辟者需要存储大量的数据，建议使用数据库api。
PersistentStorage和UI实例干系联，持久化操纵需要在UI实例初始化成功后（即loadContent传入的回调被调用时）才可以被调用，早于该时机调用会导致持久化失败。

冷启动与热启动

uiability初次启动为冷启动，非初次为热启动
冷启动为onCreate()→onWindowStageCreate()→onForeground()
热启动为onNewWant()→onForeground()

布局性能优化

布局时应尽量减少总节点数，减少性能消耗
方向
1，移除冗余的节点
2，使用扁平化布局减少节点数
具体内容：
移除多余的外层线性布局
切换差别的布局类型实现扁平化
公道控制元素的显示隐藏
设置固定宽高减少measure的耗时（未设置和百分比宽高性能消耗较大）
仅在必要环境下使用高性能布局

长列表加载性能优化

主要分为四种
懒加载（10000条数据以上时建议使用layz）
缓存列表项（额外缓存部分列表项，一般为页面数据显示条数/2）
组件复用（减少组件创建的耗时操纵@Reusable，aboutToReuse）
布局优化（相对布局，控制布局在5-8层）

webview的使用与传参

导入
import { webview } from '@kit.ArkWeb';
创建控制器
webController: webview.WebviewController = new webview.WebviewController();
再去build中选择本地的页面or网络中的页面
Web({ src: $rawfile('index.html'), controller: controller })//本地
Web({ src: 'www.example.com', controller: this.controller })//网络
当网页中调用
function submitAgreement(){ confirm(agreeCheckbox.checked) }
时，回调原生的onConfirm方法。
.onConfirm((event) => { return true; })
带的参数可以通过event.message获取

异步编程

ArkTS 支持 Promise 和 async/await 语法，使得异步编程变得更加简便明确。
async function fetchData(url: string): Promise {   let response = await fetch(url);   let data = await response.json();   return data; }
fetchData('https://api.example.com/data')   .then(data => console.log(data))   .catch(error => console.error(error));

Worker和TaskPool

TaskPool和Worker均支持多线程并发本领。由于TaskPool的工作线程会绑定系统的调理优先级，并且支持负载均衡（自动扩缩容），而Worker需要开辟者自行创建，存在创建耗时以及不支持设置调理优先级，故在性能方面使用TaskPool会优于Worker，因此大多数场景保举使用TaskPool。
TaskPool偏向独立使命维度，该使命在线程中实行，无需关注线程的生命周期，超长使命（大于3分钟且非长时使命）会被系统自动接纳；而Worker偏向线程的维度，支持长时间占据线程实行，需要自动管理线程生命周期。
常见的一些开辟场景及实用具体说明如下：

• 运行时间超过3分钟（不包含Promise和async/await异步调用的耗时，比方网络下载、文件读写等I/O使命的耗时）的使命。比方后台进行1小时的预测算法训练等CPU麋集型使命，需要使用Worker。
  
• 有关联的一系列同步使命。比方在一些需要创建、使用句柄的场景中，句柄创建每次都是差别的，该句柄需永久保存，包管使用该句柄进行操纵，需要使用Worker。
  
• 需要设置优先级的使命。比方图库直方图绘制场景，后台盘算的直方图数据会用于前台界面的显示，影响用户体验，需要高优先级处理，需要使用TaskPool。
  
• 需要频繁取消的使命。比方图库大图浏览场景，为提拔体验，会同时缓存当前图片左右侧各2张图片，往一侧滑动跳到下一张图片时，要取消另一侧的一个缓存使命，需要使用TaskPool。
  
• 大量大概调理点较分散的使命。比方大型应用的多个模块包含多个耗时使命，不方便使用Worker去做负载管理，保举采用TaskPool。
  

总结：
TaskPool性能比力好
短时使命用TaskPool，长时使命（3分钟以上）用Woker

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。