chinese直男口爆体育生外卖, 99久久er热在这里只有精品99, 又色又爽又黄18禁美女裸身无遮挡, gogogo高清免费观看日本电视,私密按摩师高清版在线,人妻视频毛茸茸,91论坛 兴趣闲谈,欧美 亚洲 精品 8区,国产精品久久久久精品免费

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認識你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

淺析HarmonyOS驅(qū)動加載過程

電子工程師 ? 來源:HarmonyOS開發(fā)者 ? 作者:chenfeng,yuanbo ? 2021-05-18 11:55 ? 次閱讀
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

1

HarmonyOS驅(qū)動概述

HarmonyOS驅(qū)動框架采用C語言面向?qū)ο?a href="http://www.brongaenegriffin.com/v/tag/1315/" target="_blank">編程模型構(gòu)建,通過平臺解耦、內(nèi)核解耦,來達到兼容不同內(nèi)核,統(tǒng)一平臺底座的目的,從而幫助開發(fā)者實現(xiàn)驅(qū)動的“一次開發(fā)、多系統(tǒng)部署”。 為了達成這個目標, HarmonyOS驅(qū)動框架提供了:1. 操作系統(tǒng)適配層(OSAL,operating system abstraction layer):提供內(nèi)核操作相關(guān)接口進行統(tǒng)一封裝,屏蔽不同系統(tǒng)操作接口。

2.平臺驅(qū)動接口:提供Board部分驅(qū)動(例如:I2C/SPI/UART總線等平臺資源)支持,同時對Board硬件操作接口進行統(tǒng)一的適配抽象,開發(fā)者只需開發(fā)新硬件抽象接口,即可獲得新增Board部分驅(qū)動支持。

3.驅(qū)動模型:面向器件驅(qū)動,提供常見的驅(qū)動抽象模型,主要達成兩個目的:

1)提供標準化的器件驅(qū)動,開發(fā)者無需獨立開發(fā),通過配置即可完成驅(qū)動的部署。

2)提供驅(qū)動模型抽象,屏蔽驅(qū)動與不同系統(tǒng)組件間的交互,使得驅(qū)動更具備通用性。

為了進一步簡化HarmonyOS驅(qū)動開發(fā),HarmonyOS驅(qū)動框架支持多種驅(qū)動加載方式:

1.支持驅(qū)動動態(tài)加載和靜態(tài)加載,解除驅(qū)動代碼和框架間的直接代碼依賴,使得驅(qū)動程序可以獨立編譯和部署;

2.支持按需動態(tài)加載方式,避免設(shè)備驅(qū)動全量加載,可有效降低系統(tǒng)資源的占用。 本文主要分析HarmonyOS驅(qū)動加載過程,在正式介紹之前,首先了解HarmonyOS驅(qū)動架構(gòu)的組成、工作原理和機制,從而了解驅(qū)動加載的細節(jié)。

●官網(wǎng)相關(guān)介紹:

https://device.harmonyos.com/cn/docs/develop/drive/oem_drive_hdfdev-0000001051715456

2

HarmonyOS驅(qū)動架構(gòu)介紹

2.1 HarmonyOS驅(qū)動架構(gòu)組成

085f72c6-b567-11eb-bf61-12bb97331649.png

圖1 HarmonyOS驅(qū)動架構(gòu)

HarmonyOS驅(qū)動架構(gòu)主要由HDF驅(qū)動框架、驅(qū)動程序、驅(qū)動配置文件和驅(qū)動接口四個部分組成。

1)HDF驅(qū)動框架提供統(tǒng)一的硬件資源管理,驅(qū)動加載管理以及設(shè)備節(jié)點管理等功能。驅(qū)動框架采用的是主從模式設(shè)計,由Device Manager和Device Host組成。

Device Manager提供了統(tǒng)一的驅(qū)動管理,Device Manager啟動時根據(jù)Device Information提供驅(qū)動設(shè)備信息加載相應(yīng)的驅(qū)動Device Host,并控制Host完成驅(qū)動的加載。

Device Host提供驅(qū)動運行的環(huán)境,同時預(yù)置Host Framework與Device Manager進行協(xié)同,完成驅(qū)動加載和調(diào)用。根據(jù)業(yè)務(wù)的需求Device Host可以有多個實例。

說明

◆ Device Host顧名思義就是驅(qū)動宿主,提供驅(qū)動運行的環(huán)境。

◆ 當驅(qū)動部署在用戶態(tài)時,Device Host可以由獨立的進程進行承載。

◆ 當驅(qū)動在部署在內(nèi)核態(tài)時,Device Host僅表示邏輯隔離。

◆ Device Host的劃分原則:Device Host屬于一類設(shè)備聚合,如Camera、Audio、Display等。

◆ 驅(qū)動程序是部署在一個Device Host還是部署在不同的Device Host,主要考慮驅(qū)動程序之間是否存在業(yè)務(wù)耦合性,如果兩個驅(qū)動程序之間存在依賴,可以考慮將這部分驅(qū)動程序部署在統(tǒng)一Host。

2)驅(qū)動程序?qū)崿F(xiàn)驅(qū)動的具體功能,每個驅(qū)動由一個或者多個驅(qū)動程序組成,每個驅(qū)動程序都對應(yīng)著一個Driver Entry。Driver Entry主要完成驅(qū)動的初始化和驅(qū)動接口綁定功能。

3)驅(qū)動配置文件.hcs主要由設(shè)備信息(Device Information)和設(shè)備資源(Device Resource)組成。Device Information完成設(shè)備信息的配置,如配置接口發(fā)布策略,驅(qū)動加載的方式等。Device Resource完成設(shè)備資源的配置,如GPIO管腳、寄存器等資源信息的配置。

4)驅(qū)動接口HDI(Hardware Driver interface)提供標準化的接口定義和實現(xiàn),驅(qū)動框架提供IO Service和IO Dispatcher機制,使得不同部署形態(tài)下驅(qū)動接口趨于形式一致。

當驅(qū)動部署在RTOS(Real-Time Operating System)輕量化操作系統(tǒng)時,驅(qū)動接口和驅(qū)動程序之間采用的是Function Call方式調(diào)用,因此驅(qū)動接口僅提供定義,驅(qū)動接口實現(xiàn)由驅(qū)動程序提供。

2.2 HDF驅(qū)動框架工作原理

0873dc7a-b567-11eb-bf61-12bb97331649.png

圖2 HDF驅(qū)動框架工作原理

Device Manager提供了統(tǒng)一的驅(qū)動加載管理機制和驅(qū)動接口發(fā)布機制。當Device Host環(huán)境加載完成時,Device Manager根據(jù)Device Information信息,請求Host加載相應(yīng)的驅(qū)動程序,Device Host在收到請求時,進行以下操作:

1)根據(jù)請求加載設(shè)備信息,查找并加載指定路徑下驅(qū)動鏡像或從指定段地址(section)查找驅(qū)動程序入口;

2)查找驅(qū)動設(shè)備描述符,匹配對應(yīng)的設(shè)備驅(qū)動;

3)當驅(qū)動匹配成功時,加載指定驅(qū)動程序鏡像;

4)Host Framework在驅(qū)動鏡像加載成功后,調(diào)用驅(qū)動程序(Driver Entry)的綁定接口和初始化接口,實現(xiàn)與驅(qū)動程序的服務(wù)對象綁定,同時初始化設(shè)備驅(qū)動程序;

5)當Device Information的配置中的服務(wù)策略要求對外暴露驅(qū)動接口時,驅(qū)動框架就將驅(qū)動程序的服務(wù)對象添加到對外發(fā)布的服務(wù)對象列表中,外部客戶端程序就可以通過此列表來查詢并訪問相應(yīng)的服務(wù)接口。

2.3 驅(qū)動接口工作機制

08a5212c-b567-11eb-bf61-12bb97331649.png

圖3 驅(qū)動接口工作機制

驅(qū)動接口主要存在以下幾種實現(xiàn):

?當驅(qū)動以內(nèi)核組件部署時,客戶端程序訪問驅(qū)動程序需要通過system call方式調(diào)用,驅(qū)動接口通過IO Service請求將消息通過system call方式調(diào)用到內(nèi)核,并將消息分發(fā)到IO Dispatcher處理。

?當驅(qū)動以用戶態(tài)服務(wù)形式部署時,客戶端進程訪問驅(qū)動進程需要通過IPC方式通信,IO Service完成IPC通信的客戶端消息請求封裝,IO Dispatcher完成驅(qū)動服務(wù)端消息請求封裝,客戶端消息通過IPC通信到達服務(wù)端并分發(fā)給IO Dispatcher處理。

為了使客戶端和服務(wù)端驅(qū)動調(diào)用方式基本一致,驅(qū)動框架提供IO Service和IO Dispatcher機制屏蔽了調(diào)用消息傳遞方式的差異。

驅(qū)動接口實現(xiàn)統(tǒng)一采用遠程調(diào)用方式,客戶端驅(qū)動接口函數(shù)將請求序列化成內(nèi)存數(shù)據(jù),通過驅(qū)動框架提供的IO Service將消息發(fā)送到服務(wù)端處理,服務(wù)端在收到請求消息時通過IO Dispatcher機制將消息分發(fā)給消息處理函數(shù)處理,處理函數(shù)將反序列化內(nèi)存數(shù)據(jù)解析成相應(yīng)的請求。這樣做的好處是,開發(fā)者只需重點關(guān)注接口的定義,無需過多關(guān)注如何實現(xiàn)不同平臺上接口適配。

3

驅(qū)動加載過程分析

HarmonyOS驅(qū)動根據(jù)部署的不同方式,存在兩種驅(qū)動加載方式:?動態(tài)加載方式:采用傳統(tǒng)的so(共享庫) 加載方式,驅(qū)動程序通過指定Symbol找到驅(qū)動函數(shù)入口進行加載。?靜態(tài)加載方式:采用將驅(qū)動程序通過Scatter編譯方式,編譯到指定的Section,再通過訪問指定Section對應(yīng)的地址,找到驅(qū)動函數(shù)入口進行加載。 下面結(jié)合一個Sample示例代碼,講解驅(qū)動加載過程,重點分析靜態(tài)加載方式下內(nèi)核態(tài)驅(qū)動加載過程。

3.1 實現(xiàn)驅(qū)動程序初始化接口

在HDF驅(qū)動框架中,HdfDriverEntry對象被用來描述一個驅(qū)動實現(xiàn)。

struct HdfDriverEntry { int32_t moduleVersion; const char *moduleName; int32_t (*Bind)(struct HdfDeviceObject *deviceObject); int32_t (*Init)(struct HdfDeviceObject *deviceObject); void (*Release)(struct HdfDeviceObject *deviceObject);};

(左右滑動查看更多)

編寫一個簡單的驅(qū)動,首先需要實現(xiàn)驅(qū)動程序(Driver Entry)入口中的三個主要接口:?Bind接口:實現(xiàn)驅(qū)動接口實例化綁定,如果需要發(fā)布驅(qū)動接口,會在驅(qū)動加載過程中被調(diào)用,實例化該接口的驅(qū)動服務(wù)并和DeviceObject綁定。?Init接口:實現(xiàn)驅(qū)動的初始化,返回錯誤將中止驅(qū)動加載流程。?Release接口:實現(xiàn)驅(qū)動的卸載,在該接口中釋放驅(qū)動實例的軟硬件資源。

int SampleDriverBind(struct HdfDeviceObject *deviceObject){ HDF_LOGE(“SampleDriverBind enter!”); static struct IDeviceIoService testService = { .Dispatch = SampleServiceDispatch, .Open = NULL, .Release = NULL, }; deviceObject-》service = &testService; return HDF_SUCCESS;} int SampleDriverInit(struct HdfDeviceObject *deviceObject){ HDF_LOGE(“SampleDriverInit enter”); return HDF_SUCCESS;} void SampleDriverRelease(struct HdfDeviceObject *deviceObject){ HDF_LOGE(“SampleDriverRelease enter”); return;} struct HdfDriverEntry g_sampleDriverEntry = { .moduleVersion = 1, .moduleName = “sample_driver”, .Bind = SampleDriverBind, .Init = SampleDriverInit, .Release = SampleDriverRelease,}; HDF_INIT(g_sampleDriverEntry);

(左右滑動查看更多)

3.2 導出驅(qū)動程序入口符號

實現(xiàn)驅(qū)動程序初始化后,需要將驅(qū)動程序入口通過驅(qū)動聲明宏導出,這樣驅(qū)動框架才能在啟動時識別到驅(qū)動程序的存在,驅(qū)動才能被加載:

#define HDF_INIT(module) HDF_DRIVER_INIT(module)

(左右滑動查看更多)

這里將HDF_INIT宏展開:

#define HDF_SECTION __attribute__((section(“.hdf.driver”)))#define HDF_DRIVER_INIT(module) const size_t USED_ATTR module##HdfEntry HDF_SECTION = (size_t)(&(module))

(左右滑動查看更多)

下面是實現(xiàn)原理:

08d92828-b567-11eb-bf61-12bb97331649.png

圖4 Driver Entry內(nèi)存分布

可以看到HDF_INIT宏是定義了一個“驅(qū)動模塊名+HdfEntry”的符號放到“.hdf.driver” 所在section,該符號指向的內(nèi)存地址即為驅(qū)動程序入口結(jié)構(gòu)體的地址。這個特殊的section將用于開機啟動時查找設(shè)備驅(qū)動。

3.3 添加設(shè)備配置

在設(shè)備對應(yīng)的device_info.hcs添加sample驅(qū)動的配置:

sample_host :: host { hostName = “sample_host”; sample_device :: device { device0 :: deviceNode { policy = 2; priority = 100; preload = 1; permission = 0664; moduleName = “sample_driver”; serviceName = “sample_service”; } }}

(左右滑動查看更多)

在配置中定義的device將在加載過程中產(chǎn)生一個設(shè)備實例,通過moduleName字段指定設(shè)備對應(yīng)的驅(qū)動名稱,從而將設(shè)備與驅(qū)動關(guān)聯(lián)起來。其中,設(shè)備與驅(qū)動可以是一對多的關(guān)系,即可以實現(xiàn)一個驅(qū)動支持多個同類型設(shè)備。

3.4 驅(qū)動啟動過程

我們添加的驅(qū)動是如何被執(zhí)行的呢?簡單來說,在系統(tǒng)啟動時,驅(qū)動框架先啟動,通過解析配置文件獲取到設(shè)備列表,通過讀取“.hdf.driver”段讀取到驅(qū)動程序(Driver Entry)列表,然后遍歷設(shè)備列表與驅(qū)動程序列表進行匹配,并加載匹配成功的驅(qū)動。

驅(qū)動框架有兩大核心管理者:?DeviceManager:負責設(shè)備的管理,包括設(shè)備加載、卸載和查詢等設(shè)備相關(guān)功能。?DeviceServiceManager:負責管理設(shè)備發(fā)布的接口服務(wù),提供接口服務(wù)的發(fā)布和查詢等功能。

驅(qū)動加載主要由DeviceManager主導,首先DeviceManager要解析配置文件中的Host列表,根據(jù)Host列表中的信息來實例化對應(yīng)的Host對象。Host解析配置文件獲取到關(guān)聯(lián)的設(shè)備列表,遍歷設(shè)備列表去獲取與之匹配的驅(qū)動程序名稱,然后基于驅(qū)動程序名稱遍歷前面提到的“.hdf.driver” section獲得驅(qū)動程序地址。

下面介紹具體過程。

3.4.1 獲取設(shè)備列表

0902f0ae-b567-11eb-bf61-12bb97331649.png

圖5 設(shè)備列表結(jié)構(gòu)

配置文本編譯后會變成二進制格式的配置文件,其中設(shè)備相關(guān)信息被存放在一個用“hdf_manager”標記的device_info配置塊中,host的內(nèi)容以塊的形式在device_info塊中依次排列,host塊中記錄了host名稱、啟動優(yōu)先級和設(shè)備列表信息。設(shè)備信息中的moduleName字段將用于和驅(qū)動程序入口中的moduleName進行匹配,從而為設(shè)備匹配到正確的驅(qū)動程序。

3.4.2 獲取驅(qū)動程序列表

091ba69e-b567-11eb-bf61-12bb97331649.png

圖6 驅(qū)動程序(DriverEntry)內(nèi)存布局

HDF驅(qū)動框架通過驅(qū)動程序入口符號的地址集中存放到一個特殊的section來實現(xiàn)對驅(qū)動的索引,這個section的開頭和末尾插入了_hdf_drivers_start、_hdf_drivers_end兩個特殊符號,用于標記這個section的范圍,兩個特殊符號之間的數(shù)據(jù)即為驅(qū)動實現(xiàn)指針。

3.4.3 驅(qū)動程序加載流程

09381dce-b567-11eb-bf61-12bb97331649.png

圖7 HDF驅(qū)動加載流程

Device Manager遍歷設(shè)備列表,當查找到對應(yīng)驅(qū)動實現(xiàn)時,為設(shè)備創(chuàng)建Device對象實例,如果設(shè)備配置中的policy字段為需要對外發(fā)布驅(qū)動接口(SERVICE_POLICY_CAPACITY),那么驅(qū)動的Bind接口將首先被調(diào)用,用于關(guān)聯(lián)設(shè)備和服務(wù)實例。然后驅(qū)動的Init接口將被調(diào)用,用于完成驅(qū)動的相關(guān)初始化工作。如果驅(qū)動被卸載或者因為硬件等原因Init接口返回失敗,Release將被調(diào)用,用于釋放驅(qū)動申請的各類資源。

4

總結(jié)

本次和大家分享了HarmonyOS驅(qū)動的主要設(shè)計思想,重點分析了內(nèi)核態(tài)驅(qū)動加載的過程,關(guān)于HarmonyOS驅(qū)動其他內(nèi)容,后續(xù)會有更多技術(shù)文章向大家持續(xù)分享,敬請期待。

作者:chenfeng,yuanbo,華為驅(qū)動工程師

編輯:jq

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學習之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • 驅(qū)動接口
    +關(guān)注

    關(guān)注

    0

    文章

    10

    瀏覽量

    2761
  • HarmonyOS
    +關(guān)注

    關(guān)注

    80

    文章

    2147

    瀏覽量

    35609
  • HDF框架
    +關(guān)注

    關(guān)注

    0

    文章

    10

    瀏覽量

    2985
  • OpenHarmony
    +關(guān)注

    關(guān)注

    31

    文章

    3928

    瀏覽量

    20736

原文標題:HarmonyOS驅(qū)動加載過程分析

文章出處:【微信號:HarmonyOS_Dev,微信公眾號:HarmonyOS開發(fā)者】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。

收藏 人收藏
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

    評論

    相關(guān)推薦
    熱點推薦

    圖撲軟件 3D 場景預(yù)加載應(yīng)用實現(xiàn)

    預(yù)加載是在進入正式場景之前提前加載所需模型、材質(zhì)、圖片等資源的技術(shù)手段,其核心價值在于消除資源加載等待,確保場景首次渲染即可完整呈現(xiàn),從而提供無縫、流暢的用戶體驗。在復(fù)雜的 Web 3D 可視化
    的頭像 發(fā)表于 12-01 16:04 ?96次閱讀
    圖撲軟件 3D 場景預(yù)<b class='flag-5'>加載</b>應(yīng)用實現(xiàn)

    HarmonyOS 5 入門系列 】鴻蒙HarmonyOS示例項目講解

    HarmonyOS 5 入門系列 】鴻蒙HarmonyOS示例項目講解 ##鴻蒙開發(fā)能力 ##HarmonyOS SDK應(yīng)用服務(wù)##鴻蒙金融類應(yīng)用 (金融理財# 一、前言:移動開發(fā)聲明式 UI
    的頭像 發(fā)表于 07-07 11:57 ?822次閱讀
    【 <b class='flag-5'>HarmonyOS</b> 5 入門系列 】鴻蒙<b class='flag-5'>HarmonyOS</b>示例項目講解

    HarmonyOS Next】ArkUI-X休閑益智接水果【進階】

    本文通過ArkUI-X實現(xiàn)跨平臺接水果游戲,深入探究網(wǎng)絡(luò)圖片在HarmonyOS與iOS設(shè)備上的渲染差異,并提供專業(yè)級優(yōu)化方案?;赪ebView的混合架構(gòu),我們實現(xiàn)了單代碼庫雙端適配的高效開發(fā)
    發(fā)表于 06-28 22:14

    HarmonyOS next】ArkUI-X休閑益智記憶翻牌【進階】

    本文通過記憶翻牌游戲?qū)崿F(xiàn),揭秘網(wǎng)絡(luò)圖片在HarmonyOS與iOS設(shè)備上的渲染差異,并提供專業(yè)級優(yōu)化方案。基于ArkUI-X的Web組件技術(shù),我們實現(xiàn)了一套代碼雙端運行的混合架構(gòu)。 一、跨平臺
    發(fā)表于 06-28 22:12

    HarmonyOS NEXT應(yīng)用元服務(wù)布局優(yōu)化長列表使用懶加載與組件復(fù)用

    超過兩屏的列表情況,并且當內(nèi)容布局相對固定的情況下,配合組件復(fù)用的方式來減少滑動過程中的組件創(chuàng)建。在長列表加載性能優(yōu)化中,介紹了較為詳細的實踐案例,這里我們僅引用一些關(guān)鍵性能收益數(shù)據(jù)。 懶加載 針對
    發(fā)表于 06-27 16:08

    HarmonyOS入門指南

    1、文檔與教程 HarmonyOS開發(fā)文檔-應(yīng)用開發(fā)導讀 OpenHarmony--應(yīng)用開發(fā)導讀 倉頡編程語言官網(wǎng) 華為開發(fā)者博客 華為開發(fā)者問答專區(qū) 華為生態(tài)市場-鴻蒙生態(tài)市場
    的頭像 發(fā)表于 06-27 00:11 ?579次閱讀

    同步電機失步淺析

    純分享帖,需要者可點擊附件免費獲取完整資料~~~*附件:同步電機失步淺析.pdf【免責聲明】本文系網(wǎng)絡(luò)轉(zhuǎn)載,版權(quán)歸原作者所有。本文所用視頻、圖片、文字如涉及作品版權(quán)問題,請第一時間告知,刪除內(nèi)容!
    發(fā)表于 06-20 17:42

    HarmonyOS優(yōu)化應(yīng)用預(yù)置圖片資源加載耗時問題性能優(yōu)化

    提升要從收益和開銷兩部分進行分析: 1.收益 紋理壓縮的主要收益是在編譯過程中將預(yù)置圖片轉(zhuǎn)換為紋理格式,能直接被GPU讀取進行渲染,降低了CPU和DDR的負載,能更快的加載圖片。在Tab欄切換示例中將
    發(fā)表于 05-29 16:11

    HarmonyOS5云服務(wù)技術(shù)分享--應(yīng)用預(yù)加載提速指南

    手把手教你用預(yù)加載優(yōu)化應(yīng)用啟動速度 Hi,開發(fā)者朋友們!今天我們來聊聊如何通過預(yù)加載技術(shù)讓應(yīng)用啟動快人一步。在用戶體驗至上的時代,首屏加載速度直接關(guān)系到用戶留存率,快來掌握這個提升性能的利器吧! 一
    發(fā)表于 05-22 20:39

    HarmonyOS5云服務(wù)技術(shù)分享--云函數(shù)預(yù)加載文章整理

    無縫對接HarmonyOS應(yīng)用,實現(xiàn)預(yù)加載等高級功能。如果你在實踐過程中遇到問題,歡迎在評論區(qū)留言,或到華為開發(fā)者社區(qū)提問(記得帶上 #云函數(shù) 標簽哦~)。 ??最后,感謝你的耐心閱讀!?? ? 如果覺得有幫助,不妨點個贊或分享
    發(fā)表于 05-22 20:33

    HarmonyOS5云服務(wù)技術(shù)分享--ArkTS開發(fā)Node環(huán)境

    ? 你好呀,開發(fā)者小伙伴們!今天我們來聊聊如何在HarmonyOS(ArkTS API 9及以上)中玩轉(zhuǎn)云函數(shù),特別是結(jié)合Node.js和HTTP觸發(fā)器的開發(fā)技巧。文章會手把手帶你從零開始,用最接地
    發(fā)表于 05-22 17:21

    高質(zhì)量 HarmonyOS 權(quán)限管控流程

    高質(zhì)量 HarmonyOS 權(quán)限管控流程 在 HarmonyOS 應(yīng)用開發(fā)過程中,往往會涉及到 敏感數(shù)據(jù) 和 硬件資源 的調(diào)動和訪問,而這部分的調(diào)用就會涉及到管控這部分的知識和內(nèi)容了。我們需要對它有
    的頭像 發(fā)表于 04-02 18:29 ?1890次閱讀
    高質(zhì)量 <b class='flag-5'>HarmonyOS</b> 權(quán)限管控流程

    HarmonyOS NEXT 原生應(yīng)用/元服務(wù)-DevEco Profiler性能優(yōu)化過程

    優(yōu)化是一個不斷持續(xù)的周期性的過程,您需要在應(yīng)用開發(fā)過程中觀察應(yīng)用的運行表現(xiàn)來識別性能瓶頸,通過運行時數(shù)據(jù)來定界定位性能問題,定位根因后修復(fù)代碼并驗證優(yōu)化措施的可行性,循環(huán)往復(fù)直到應(yīng)用滿足您的性能指標
    發(fā)表于 02-19 15:28

    解決HarmonyOS應(yīng)用中Image組件白塊問題的有效方案

    HarmonyOS應(yīng)用開發(fā)過程中,通過Image組件加載網(wǎng)絡(luò)圖片時,通常會經(jīng)歷四個關(guān)鍵階段:組件創(chuàng)建、圖片資源下載、圖片解碼和刷新。當加載的圖片資源過大時,Image組件會等待圖片數(shù)
    的頭像 發(fā)表于 02-17 10:08 ?1594次閱讀
    解決<b class='flag-5'>HarmonyOS</b>應(yīng)用中Image組件白塊問題的有效方案

    EE-240: ADSP-BF533 Blackfin加載過程

    電子發(fā)燒友網(wǎng)站提供《EE-240: ADSP-BF533 Blackfin加載過程.pdf》資料免費下載
    發(fā)表于 01-05 10:00 ?0次下載
    EE-240: ADSP-BF533 Blackfin<b class='flag-5'>加載</b><b class='flag-5'>過程</b>