請簡述鴻蒙OS與Android OS的主要區別是什么？

• 分布式架構：HarmonyOS支持跨設備無縫協作，允許設備之間共享硬件資源。
• 性能：HarmonyOS優化了任務調度和內存管理，提高了性能和響應速度。
• 安全性：HarmonyOS采用了多層次的安全策略，包括數據加密和安全啟動。
• 生態系統：HarmonyOS正在構建自己的應用生態系統，鼓勵開發者使用Ark Ts和ArkUI框架。

HarmonyOS應用打包后的文件擴展名是?

打包后的文件擴展名為.hap（HarmonyOS Ability Package），這是HarmonyOS應用的標準包格式

ArkTs是什么?

ArkTS是HarmonyOS優選的主力應用開發語言。保持了TypeScript的基本風格，同時通過規范定義強化開發期靜態檢查和分析，提升程序執行穩定性和性能。

ArkTS的主要特點包括：

靜態類型檢查： ArkTS在編譯時進行類型檢查，這有助于在代碼運行前發現和修復錯誤，提高代碼的穩定性和性能。

聲明式UI： ArkTS定義了聲明式UI描述，允許開發者以更簡潔、更自然的方式開發跨端應用。

狀態管理： ArkTS提供了多維度的狀態管理機制，使得與UI相關聯的數據可以在組件內使用，也可以在不同組件層級間傳遞，支持單向和雙向數據流。

渲染控制： ArkTS支持條件渲染、循環渲染和數據懶加載，允許開發者根據應用的不同狀態渲染UI內容。

兼容性： ArkTS兼容TS/JavaScript生態，開發者可以使用TS/JS進行開發或復用已有代碼。

并發機制： ArkTS支持輕量化的并發機制，允許開發者編寫并發代碼，提高應用的性能和響應速度。

ArkTs 和 Ts 有什么區別

ArkTs 基于 Ts 做了擴展，并且強化了靜態檢查和分析

一、擴展了 UI：

• 定義了聲明式 UI 描述、自定義組件，事件方法、屬性方法
• 提供了多維度的狀態管理機制
• 提供了控制渲染、循環渲染的能力

二、強化了檢查

• 不支持 var、any、unknown、Symbol
• 不支持解構賦值
• 不支持使用對象字面量進行類型聲明
• 不支持在運行時動態增刪對象的屬性
• 不支持在函數內聲明函數
• 不支持使用 typeof 作為類型
• 不支持使用 # 符號開頭聲明的私有字段，改用 private 關鍵字
• 不支持把 function 定義函數賦值給變量，改為使用箭頭函數

頁面和自定義組件生命周期有哪些?

頁面生命周期，即被@Entry裝飾的組件生命周期，提供以下生命周期接口：

• onPageShow：頁面每次顯示時觸發一次，包括路由過程、應用進入前臺等場景。
• onPageHide：頁面每次隱藏時觸發一次，包括路由過程、應用進入后臺等場景。
• onBackPress：當用戶點擊返回按鈕時觸發。

組件生命周期，即一般用@Component裝飾的自定義組件的生命周期，提供以下生命周期接口：

• aboutToAppear：組件即將出現時回調該接口，具體時機為在創建自定義組件的新實例后，在執行其build()函數之前執行。
• onDidBuild：組件build()函數執行完成之后回調該接口，開發者可以在這個階段進行埋點數據上報等不影響實際UI的功能。不建議在onDidBuild函數中更改狀態變量、使用animateTo等功能，這可能會導致不穩定的UI表現。
• aboutToDisappear：aboutToDisappear函數在自定義組件析構銷毀之前執行。不允許在aboutToDisappear函數中改變狀態變量，特別是@Link變量的修改可能會導致應用程序行為不穩定。

生命周期流程如下圖所示，下圖展示的是被@Entry裝飾的組件（頁面）生命周期。

如何進行數據持久化?

• 用戶首選項（Preferences）：這是一種輕量級的配置數據持久化方式，適用于保存應用配置信息、用戶偏好設置等。它通過文本形式保存數據，并且數據會全量加載到內存中，因此訪問速度快，但不適合存儲大量數據。
• 鍵值型數據庫（KV-Store）：適用于存儲結構簡單的數據，如商品名稱和價格、員工工號和出勤狀態等。鍵值型數據庫以“鍵值對”的形式組織數據，適合數據關系不復雜的場景。
• 關系型數據庫（RelationalStore）：基于SQLite，適用于存儲包含復雜關系的數據，如學生信息、雇員信息等。關系型數據庫提供了一系列SQL操作，如增刪改查等。

父子組件如何通信?

當前(API 12)狀態管理有兩個版本 @Component和 @ComponentV2

父子單向數據傳遞 @State @Prop

• @Prop裝飾的變量可以和父組件建立單向的同步關系。@Prop裝飾的變量是可變的，但是變化不會同步回其父組件。

父子雙向數據傳遞 @State @Link 、@objectLink @Link

• 子組件中被 @Link裝飾的變量與其父組件中對應的數據源建立雙向數據綁定。

跨組件通信 @Provide裝飾器和 @Consume裝飾器

• @Provide和 @Consume，應用于與后代組件的雙向數據同步，應用于狀態數據在多個層級之間傳遞的場景。不同于 @Prop和 @Link，@Provide和 @Consume擺脫參數傳遞機制的束縛，實現跨層級傳遞。

@Observed裝飾器和 @ObjectLink裝飾器

• 對于多層嵌套的情況，比如二維數組，或者數組項class，或者class的屬性是class，他們的第二層的屬性變化是無法觀察到的。這就要用到 @Observed/@ObjectLink裝飾器

注意:@ObjectLink裝飾器不能在 @Entry裝飾的自定義組件中使用且 @ObjectLink 裝飾的變量不能被賦值,只能對其屬性進行賦值操作

兄弟組件如何通信?

通過公共父組件傳遞

如果兩個組件是同一個父組件的子組件，可以通過父組件來傳遞數據或事件。父組件可以作為中介，將一個子組件的數據或事件傳遞給另一個子組件。

使用全局狀態管理

使用全局狀態管理（如 AppStorage、LocalStorage）來存儲共享數據。兄弟組件可以獨立地讀取和更新這個全局狀態，從而實現通信。

如何實現頁面間的通信?

• 使用 @Provide和 @Consume裝飾器(見6.3)
• 使用路由跳轉傳參
• 使用導航跳轉傳參

跨設備通信的方式有哪些？

HarmonyOS支持多種跨設備通信方式，包括：

• 分布式軟總線：一種高性能的通信機制，允許設備之間建立直接連接，進行數據傳輸。
• 藍牙：使用標準的藍牙技術進行設備間的通信。
• WLAN：通過WLAN網絡實現設備間的通信。
• 遠程服務調用：通過分布式任務調度實現跨設備的服務調用。

如何進行全局狀態管理?

@Provide @Consume裝飾器

• 適用場景：適用于整個組件樹而言“全局”的狀態共享，且該狀態改動不頻繁的場景。
• 工作原理：通過在最頂層組件中使用 @Provide裝飾器提供狀態，其他需要共享狀態的組件通過 @Consume裝飾器獲取該狀態 。
• 優點：減少了狀態傳遞的層級，提升了代碼的可維護性和可拓展性。
• 注意事項：確保狀態的生命周期與組件樹的生命周期一致，避免不必要的UI刷新。

AppStorage

• 適用場景：適用于整個應用而言“全局”的變量或應用的主線程內多個 UIAbility實例間的狀態共享。
• 工作原理：AppStorage與應用的進程綁定，由UI框架在應用程序啟動時創建，當應用進程終止，AppStorage被回收。
• 優點：適用于需要在整個應用中-共享狀態的場景。
• 注意事項：確保狀態的生命周期與應用進程一致，避免在應用退出后仍有狀態存在。

LocalStorage

• 適用場景：適用于單個Ability而言“全局”的變量，主要用于不同頁面間的狀態共享。
• 工作原理：LocalStorage的生命周期由應用程序決定，當應用釋放最后一個指向 LocalStorage的引用時，LocalStorage被垃圾回收。
• 優點：適用于需要在單個UIAbility中不同頁面間共享狀態的場景。
• 注意事項：確保狀態的生命周期與應用程序的生命周期一致，避免在應用退出后仍有狀態存在。

LocalStorage在應用重啟后數據會消失嗎?

會,因為LocalStorage 是一種用于頁面或組件級別的數據存儲方式，它允許開發者在頁面或組件的生命周期內存儲和檢索數據。LocalStorage 的數據存儲在內存中，因此它的讀寫速度相對較快。但是，當應用重啟后，LocalStorage 中的數據會丟失。

Navigation組件跳轉和router跳轉有什么區別?

• Navigation：是路由容器組件，適用于模塊內和跨模塊的路由切換，一次開發，多端部署場景。Router位于頁面棧管理節點 stage 下面，不提供導航容器的概念。
• Navigation和 Router都支持跳轉傳參，但 Router對象中暫不支持方法變量。
• Navigation：支持清理指定路由，頁面棧沒有上限，可以無限跳轉。Router不支持清理指定路由且頁面棧最大為32，頁面棧到達32之后必須清除之后才能繼續跳轉。
• Navigation：支持自定義轉場動畫和共享元素轉場動畫。 Router：僅支持簡單自定義轉場動畫。
• Navigation：支持通過 setInterception 方法設置路由攔截。Router：不支持路由攔截。
• Navigation：支持沉浸式頁面和模態嵌套路由。Router：不支持，需要通過窗口配置實現沉浸式頁面。

總而言之，Navigation 組件在功能上更具豐富性和靈活性，特別是在處理復雜的導航結構、動效和路由管理方面。

而 Router 則提供了更基礎的路由跳轉功能，適合簡單的路由需求。開發者可以根據應用的具體需求和設計選擇最合適的路由方案

鴻蒙有哪些后臺任務類型

OpenHarmony標準系統支持規范內受約束的后臺任務，包括短時任務、長時任務、延遲任務、代理提醒和能效資源。

開發者可以根據如下功能介紹，選擇合適的后臺任務以滿足應用退至后臺后繼續運行的需求。

• 短時任務：適用于實時性要求高、耗時不長的任務，例如狀態保存。
• 長時任務：適用于長時間運行在后臺、用戶可感知的任務，例如后臺播放音樂、導航、設備連接等，使用長時任務避免應用進程被掛起。
• 延遲任務：對于實時性要求不高、可延遲執行的任務，系統提供了延遲任務，即滿足條件的應用退至后臺后被放入執行隊列，系統會根據內存、功耗等統一調度。
• 代理提醒：代理提醒是指應用退后臺或進程終止后，系統會代理應用做相應的提醒。適用于定時提醒類業務，當前支持的提醒類型包括倒計時、日歷和鬧鐘三類。

如何實現應用的后臺運行？

• 后臺服務： 使用后臺服務（如BackgroundService）來執行不需要用戶直接交互的任務。
• 定時任務： 通過系統提供的定時任務機制（如AlarmService）來周期性執行后臺任務。
• 事件監聽： 注冊系統事件，如網絡變化、電量變化等，以在特定事件發生時喚醒應用進行處理。

什么是Ability？

Ability是應用/服務所具備的能力的抽象，一個Module可以包含一個或多個 Ability ,在鴻蒙系統中，Ability提供了對 Ability生命周期、上下文環境等調用管理的能力，包括 Ability創建、銷毀、轉儲客戶端信息等

鴻蒙系統中的 Ability主要分為兩種類型：UIAbility和 ExtensionAbility。

UIAbility ：

• 定義 ：包含UI界面，提供展示UI的能力，主要用于和用戶交互 。
• 創建 ：在模塊中添加UIAbility時，選中對應的模塊，單擊鼠標右鍵，選擇New > Ability，設置Ability名稱，選擇是否在設備主屏幕上顯示該功能的啟動圖標，單擊Finish完成Ability創建 。

ExtensionAbility ：

• 定義 ：提供特定場景的擴展能力，滿足更多的使用場景 。
• 創建 ：在模塊中添加ExtensionAbility時，選中對應的模塊，單擊鼠標右鍵，選擇不同的場景類型（如Accessibility、EmbeddedUIExtensionAbility等） 。當前僅Application工程支持創建ExtensionAbility。設置Ability名稱，單擊Finish完成ExtensionAbility創建。
• 此外，Ability是Ability模塊的基類，提供系統配置更新回調和系統內存調整回調 。Ability的繼承關系包括UIAbility和ExtensionAbility等具體類.

總之，Ability是鴻蒙系統中用于管理應用能力的核心組件，通過不同類型的Ability可以實現不同的功能需求。

請介紹UIAbility的啟動模式

UIAbility的啟動模式是指在啟動UIAbility實例時所采用的不同呈現狀態和行為方式。HarmonyOS為UIAbility提供了多種啟動模式，以滿足不同業務場景的需求。這些啟動模式包括：

1. Singleton（單實例模式） ：這是默認情況下的啟動模式。當應用進程中該類型的UIAbility實例已經存在時，系統會復用該實例，而不是創建新的實例。這意味著每次調用startAbility()方法時，如果相同類型的UIAbility實例已經存在，則不會進入onCreate()和onWindowStageCreate()生命周期回調，而只會進入onNewWant()回調。這種模式下，UIAbility在任務列表里只會有一個歷史任務。
2. Multiton（多實例模式） ：在這種模式下，可以多次創建UIAbility實例。但是，每次創建新的實例之前，之前的實例都會被銷毀。因此，在任務列表里也只能看到一個歷史任務。每次創建新的實例時，都會重新走一遍UIAbility的生命周期方法。
3. Standard（標準實例模式） ：這也是一種多實例模式。與Multiton不同的是，創建新的實例時不會銷毀之前的實例，所以在任務列表里可以看到多個實例。這意味著每次點擊都會創建新的實例，并且每個實例都有自己的生命周期。
4. Specified（指定實例模式） ：這種啟動模式需要指定一個ID。在創建UIAbility時，系統會先判斷任務列表里是否存在指定ID的UIAbility實例。如果存在，則不會創建新的實例；如果不存在，則會創建新的實例。

Ability是如何與用戶交互的？

• 界面顯示：Ability可以包含一個或多個AbilitySlice，用于顯示UI界面并與用戶進行交互。
• 事件處理：Ability可以處理用戶的輸入事件，如觸摸、按鍵等。
• 數據綁定：Ability可以使用數據綁定機制，將UI組件與數據模型綁定，實現數據的自動更新和交互。
• 通知：Ability可以通過系統通知機制向用戶發送通知，即使應用不在前臺運行。

如何實現應用的多語言支持？

• 資源文件：為每種語言創建資源文件（如string.json），并在里面定義所有可本地化的字符串。
• 資源引用：在代碼中使用資源ID引用字符串，而不是硬編碼文本。
• 系統設置：應用會自動根據系統設置的語言環境加載相應的資源文件。
• 動態切換：支持在應用運行時切換語言，并動態更新UI。

分布式數據庫是如何實現數據同步的？

• 分布式事務：確保跨設備的數據庫操作具有原子性、一致性、隔離性和持久性。
• 數據版本控制：為數據添加版本號，確保同步時數據的一致性。
• 沖突解決策略：定義沖突解決策略，處理并發操作導致的數據沖突。
• 網絡狀態感知：根據網絡狀態智能同步數據，優化同步效率和流量使用。

如何優化應用的性能？

一、使用并行化、預加載和緩存等方法，提升系統資源利用率，減少主線程負載，加快應用的啟動速度和響應速。

• 使用多線程執行耗時操作
• 使用異步執行耗時操作
• 使用預加載提升頁面啟動和響應速度
• 使用條件渲染實現預加載
• 使用緩存提升啟動速度和滑動幀率

二、盡量減少布局的嵌套層數

• 移除冗余節點，刪除無用的Stack/Column/Row嵌套
• 使用Column/Row替代Flex構建線性布局
• 使用Flex、List、Grid、RelativeContainer、絕對布局和自定義布局等構建復雜布局

三、合理管理狀態變量

• 合理管理狀態變量，減少不必要的參數層次傳遞
• 避免濫用@Provide+@Consume
• 控制對象級狀態變量成員數量
• 避免不必要的創建和讀取狀態變量

四、合理使用系統接口，避免冗余操作

• 避免在系統高頻調用進行冗余和耗時操作
• 避免在系統高頻調用打印日志
• 在Release版本中刪除Debug日志

五、使用性能工具分析和定位問題

HarmonyOS中的權限管理模型是怎樣的？

• 權限聲明：應用在config.json中聲明所需的權限。
• 權限申請：在應用運行時，根據需要動態申請權限。
• 權限檢查：在執行敏感操作前，檢查是否已獲得相應權限。
• 權限分組：系統將權限分為不同的組，便于管理和申請。

LazyForEach是什么？

• LazyForEach 是一個用于高效渲染列表的組件或功能。
• 它允許開發者在用戶滾動列表時才加載和渲染列表項，而不是一次性渲染整個列表。
• 這種按需渲染的方式可以顯著提高應用的性能，特別是在處理大量數據時。

LazyForEach的工作原理是什么？

LazyForEach 的工作原理通常是基于用戶的滾動位置來動態地創建和銷毀列表項的組件實例。當用戶滾動到列表的某個部分時，LazyForEach 會加載并渲染那些即將進入視圖的列表項，同時可能會卸載那些滾出視圖的列表項，以節省內存和計算資源。

Router.replace()方法的作用是什么？和Router.pushUrl()方法有什么區別？

Router.replace()方法用于替換當前路由，并將目標路由壓入棧頂。與Router.pushUrl()方法不同，Router.replace()方法不會保留當前路由，而是直接替換掉當前路由。

如何實現應用的沉浸式模式？

沉浸式模式是指應用界面呈現出沉浸式的全屏模式，不留任何系統UI，用戶只能看到應用內容。在沉浸式模式下，應用的UI元素會被覆蓋，但系統狀態欄、導航欄、鍵盤等系統UI依然可見。以下是實現步驟

1. 設置窗口屬性：

在應用的入口Ability中，可以通過設置窗口屬性來實現沉浸式模式。這通常涉及到配置窗口特性（Window Features）來隱藏狀態欄和導航欄。

2. 使用系統API：

鴻蒙OS提供了API來控制系統UI的顯示和隱藏。你可以在應用的代碼中調用這些API來實現沉浸式效果。

3. 配置應用的配置文件：

在應用的config.json或其他配置文件中，可以聲明應用需要的窗口特性，如ohos:immersive。

4. 動態切換：

應用可以根據用戶的交互或特定場景動態地進入或退出沉浸式模式。這可能涉及到監聽用戶的手勢或其他事件來切換UI狀態。

5. 適配不同設備：

不同的設備可能有不同的屏幕和系統UI，因此在實現沉浸式模式時，需要考慮不同設備的適配問題。

如何獲取屏幕的安全區域?

可以通過設置組件的expandSafeArea屬性來獲取獲取UIWindow：首先，你需要獲取到當前頁面的UIWindow實例。

調用getSafeArea方法：通過UIWindow實例調用getSafeArea方法來獲取安全區域的Rect對象。

@Prop和@ObjectLink裝飾器有什么區別？

1. 用途

@Prop裝飾器：主要用于在組件之間傳遞數據，將父組件的值傳遞給子組件。它定義了子組件的屬性，可以接收來自父組件的賦值。

@ObjectLink用于建立對象之間的鏈接，通常用于在組件內部或組件之間共享和同步狀態。它可以將一個對象的屬性與另一個對象的屬性進行鏈接，當一個對象的屬性發生變化時，另一個對象的屬性也會自動更新。

2. 數據傳遞方式

@Prop：是單向的數據傳遞，從父組件到子組件。父組件可以設置子組件的 @Prop屬性值，但子組件不能直接修改這個值。

@ObjectLink是雙向的數據傳遞，父組件和子組件都可以修改子組件的 @ObjectLink屬性值。

3. 性能

@Prop會深拷貝數據，具有拷貝的性能開銷，性能低于 @ObjectLink

ForEach和LazyForEach的區別？

ForEach和LazyForEach都是用于渲染列表的裝飾器，它們的區別在于：

• ForEach：渲染列表時，會將列表中的每一項都渲染一次，適用于列表項數量較少的情況。
• LazyForEach：渲染列表時，只渲染當前可見的列表項，適用于列表項數量較多的情況。

H5如何與HarmonyOS應用(webView)進行通信？

應用調用H5頁面JS函數

應用側可以通過runj()方法異步調用前端頁面的j相關函數，并通過Promise方式返回腳本執行的結果。runj需要在loadUrl完成后，比如onPageEnd中調用。

H5頁面調用應用函數

使用Web組件將應用側代碼注冊到前端頁面中，注冊完成之后，前端頁面中使用注冊的對象名稱就可以調用應用側的函數，實現在前端頁面中調用應用側方法。注冊應用側代碼有兩種方式，一種在Web組件初始化調用，使用jProxy()接口。另外一種在Web組件初始化完成后調用，使用registerjProxy()接口。

Hap、Har、Hsp 分別是什么，它的特點及其應用場景？

這三個都是 HarmonyOS 中的三種不同類型的構建產物，它們在鴻蒙系統中有著不同的作用和特點

HAP

HAP（Harmony Ability Package）是應用安裝和運行的基本單元。可以被單獨安裝和運行。（又稱ability）其主要分為兩種類型：entry和feature。

• entry：應用的主模塊，作為應用的入口，提供了應用的基礎功能。
• feature：應用的動態特性模塊，作為應用能力的擴展，可以根據用戶的需求和設備類型進行選擇性安裝。

HAR

HAR（Harmony Archive）是靜態共享包，可以包含代碼、C++庫、資源和配置文件。通過HAR可以實現多個模塊或多個工程共享ArkUI組件、資源等相關代碼。（又稱static library, 靜態共享包）

• 通過 Static Library 類型的 Model 構建來的
• 編譯時會被打包進使用到它 Hap/Hsp 包中
• 多包引用相同的 Har 包時，會造成多包間代碼和資源的重復

HSP

HSP（Harmony Shared Package）是動態共享包，可以包含代碼、C++庫、資源和配置文件，通過HSP可以實現代碼和資源的共享。HSP不支持獨立發布，而是跟隨其宿主應用的APP包一起發布，與宿主應用同進程，具有相同的包名和生命周期。

• 通過 Shared Library 類型的 Model 構建來的
• 不會被打包進使用它的 Hap/Hsp 包，而是單獨存在
• 當多包需要同時引用同一個共享包時，可以采用 Hsp 替代 Har，能避免 Har 造成的多包間代碼和資源的重復拷貝，從而減小應用包大小
• HSP不支持在設備上單獨安裝/運行，需要與依賴該HSP的HAP一起安裝/運行。HSP的版本號必須與HAP版本號一致。
• HSP不支持在配置文件中聲明ExtensionAbility組件，但支持UIAbility（除入口ability外）組件。
• HSP可以依賴其他HAR或HSP，但不支持循環依賴，也不支持依賴傳遞。

build() 函數內的語法需要遵守什么限制？

• @Entry裝飾的自定義組件，其 build() 函數下的根節點唯一且必要，且必須為容器組件
• @Component裝飾的自定義組件，其 build() 函數下的根節點唯一且必要，可以為非容器組件
• ForEach 禁止作為根節點
• 不允許使用 switch 語法
• 避免直接在 Text 組件內改變 count 的值
• 不允許調用沒有用 @Builder 裝飾的方法
• 不允許聲明本地變量
• 不允許創建本地作用域
• 不允許 console.info 之類的語句

鴻蒙常用的裝飾器有哪些？

1. @Entry：用于標記頁面的入口點，必須聲明在頁面的主結構上。
2. @Component：用于聲明頁面或子組件的構建結構。
3. @State：用于聲明組件內的可變狀態，當狀態值改變時，UI將自動重新渲染。
4. @Link：用于父組件與子組件之間的雙向綁定，允許子組件更新父組件中的數據。
5. @Prop：用于創建父子組件間的單向數據綁定，父組件的狀態變化會同步到子組件的@Prop變量，但子組件的@Prop變量的修改不會同步回父組件。
6. @Provide 和  @Consume：應用于與后代組件的雙向數據同步，實現跨層級傳遞。
7. @Observed 和  @ObjectLink：用于在涉及嵌套對象或數組的場景中進行雙向數據同步。
8. @LocalStorageProp 和  @LocalStorageLink：與LocalStorage中給定屬性建立同步關系。
9. @StorageProp 和  @StorageLink：與應用級狀態存儲建立同步關系。
10. @Watch：用于監聽數據變化。
11. @Styles：用于定義組件的樣式。
12. @Extend：用于擴展其他組件。
13. @Concurrent：用于聲明并發執行的方法

對于一些公共的樣式你是怎么做的？有沒有什么優化的方式

• 封裝組件
• 提取Builder
• 提取Styles和Extends

Styles和Extend兩個裝飾器的區別？

鴻蒙OS中的@Styles和@Extend兩個裝飾器都用于樣式復用，但它們之間存在一些關鍵區別：

1. 定義范圍： @Styles裝飾器可以在全局或組件內部定義，而@Extend裝飾器僅支持在全局定義，不支持在組件內部定義。

2. 私有屬性和事件：@Extend支持封裝指定組件的私有屬性和私有事件，以及預定義相同組件的@Extend方法，而@Styles僅支持通用屬性和通用事件。

3. 參數支持：@Extend裝飾的方法支持參數，允許開發者在調用時傳遞參數，遵循TypeScript方法傳值調用。相比之下，@Styles方法不支持參數。

4. 事件句柄： @Extend裝飾的方法參數可以是函數，作為事件的句柄，而@Styles不支持這一點。

5. 狀態變量：@Extend的參數可以是狀態變量，當狀態變量改變時，UI可以正常被刷新渲染，而@Styles不支持狀態變量作為參數。

6. 樣式復用： @Styles用于快速定義并復用自定義樣式，適合提煉公共樣式進行復用，而@Extend用于擴展原生組件樣式，提供了更多的靈活性和擴展性。

什么是三層工程結構？一次開發，多端部署

• common（公共能力層）：用于存放公共基礎能力集合（如工具庫、公共配置等）。

  common層可編譯成一個或多個HAR包或HSP包（HAR中的代碼和資源跟隨使用方編譯，如果有多個使用方，它們的編譯產物中會存在多份相同拷貝；而HSP中的代碼和資源可以獨立編譯，運行時在一個進程中代碼也只會存在一份），其只可以被products和features依賴，不可以反向依賴。

• features（基礎特性層）：用于存放基礎特性集合（如應用中相對獨立的各個功能的UI及業務邏輯實現等）。

  各個feature高內聚、低耦合、可定制，供產品靈活部署。不需要單獨部署的feature通常編譯為HAR包或HSP包，供products或其它feature使用，但是不能反向依賴products層。需要單獨部署的feature通常編譯為Feature類型的HAP包，和products下Entry類型的HAP包進行組合部署。features層可以橫向調用及依賴common層。

• products（產品定制層）：用于針對不同設備形態進行功能和特性集成。

  products層各個子目錄各自編譯為一個Entry類型的HAP包，作為應用主入口。products層不可以橫向調用。

在ArkTS中，V1和V2版本的裝飾器存在哪些區別？

狀態管理裝飾器：

• V1版本中，主要使用@State裝飾器來定義組件中的狀態變量，當狀態變量變化時，會觸發UI刷新。
• V2版本中，引入了更多的狀態變量裝飾器，包括@Local、@Param、@Once、@Event、@Provider、@Consumer等，以支持更細粒度的狀態管理和更復雜的組件交互。例如，@Local表示組件內部的狀態，使得自定義組件內部的變量具有觀測變化的能力，并且只能從組件內部初始化。

組件裝飾器：

• V1版本中，使用@Component裝飾器來定義自定義組件。
• V2版本中，引入了@ComponentV2裝飾器，它允許使用全新的狀態變量裝飾器，并且不支持組件復用、LocalStorage等現有自定義組件的能力。同時，@ComponentV2支持一個可選的boolean類型參數freezeWhenInactive，來實現組件凍結功能。

事件裝飾器：V2版本中，新增了@Event裝飾器，用于規范組件輸出，允許子組件向父組件要求更新@Param裝飾變量的能力。@Event主要配合@Param實現數據的雙向同步。

提供和消費裝飾器：V2版本中，@Provide和@Consume裝飾器用于與后代組件的雙向數據同步，適用于狀態數據在多個層級之間傳遞的場景。@Provide作為數據的提供方，可以更新其子孫節點的數據，并觸發頁面渲染。@Consume在感知到@Provide數據的更新后，會觸發當前自定義組件的重新渲染。

觀察變化的裝飾器：V2版本中，@Observed和@ObjectLink裝飾器用于觀察嵌套對象的變化，這對于多層嵌套的數據結構特別有用。@Observed用于修飾類，使得可以觀察到嵌套的變化；@ObjectLink用在子組件中，用于接收@Observed裝飾的類的實例，并與父組件中對應的狀態變量建立雙向數據綁定。