摘要:本文主要介紹應(yīng)用程序加載如何做到毫秒級(jí)耗時(shí)。圖不同視角看左邊是從匯編器和鏈接器的視角來(lái)看這個(gè)文件,開頭的描述了體系結(jié)構(gòu)和操作系統(tǒng)等基本信息,并指出和在文件中的什么位置,在匯編和鏈接過(guò)程中沒(méi)有用到,所以是可有可的,中保存了所有的描述信息。
AliOS Thing 是AliOS家族旗下面向IoT領(lǐng)域的、高可伸縮的物聯(lián)網(wǎng)操作系統(tǒng),AliOS Thing v3.2[1]以后的版本提供了內(nèi)核和應(yīng)用程序分離的功能,內(nèi)核和應(yīng)用分別運(yùn)行在不同的虛擬地址空間,即使應(yīng)用程序出現(xiàn)問(wèn)題也不會(huì)影響到內(nèi)核的運(yùn)行。內(nèi)核和應(yīng)用程序的隔離,不僅可以達(dá)到安全的目的,還可以有效降低應(yīng)用開發(fā)的成本,并且應(yīng)用程序以標(biāo)準(zhǔn)的ELF (Executable and Linkable Format)[2]文件存在,系統(tǒng)需要運(yùn)行哪一個(gè)應(yīng)用程序,只需要加載該應(yīng)用程序的ELF文件即可。
本文主要介紹AliOS Things應(yīng)用程序加載如何做到“毫秒級(jí)”耗時(shí)。
圖1-1 AliOS Things
????ELF文件格式提供了兩種不同的視角,在匯編器和鏈接器看來(lái),ELF文件是由Section Header Table描述的一系列Section的集合,而執(zhí)行一個(gè)ELF文件時(shí),在加載器Loader看來(lái)它是由Program Header Table描述的一系列Segment的集合。
圖2-1 不同視角看ELF
????左邊是從匯編器和鏈接器的視角來(lái)看這個(gè)文件,開頭的ELF Header描述了體系結(jié)構(gòu)和操作系統(tǒng)等基本信息,并指出Section Header Table和Program Header Table在文件中的什么位置,Program Header Table在匯編和鏈接過(guò)程中沒(méi)有用到,所以是可有可的,Section Header Table中保存了所有Section的描述信息。右邊是從加載器的視角來(lái)看這個(gè)文件,開頭是ELF Header,Program Header Table中保存了所有Segment的描述信息,Section Header Table在加載過(guò)程中沒(méi)有用到,所以是可有可無(wú)的。注意Section Header Table和Program Header Table并不是一定要位于文件開頭和結(jié)尾的,其位置由ELF Header指出,上圖這么畫只是為了清晰。
????我們?cè)趨R編程序中用.section
聲明的Section會(huì)成為目標(biāo)文件中的Section,此外匯編器還會(huì)自動(dòng)添加一些Section(比如符號(hào)表),Segment是指在程序運(yùn)行時(shí)加載到內(nèi)存的具有相同屬性的區(qū)域,由一個(gè)或多個(gè)Section組成,比如有兩個(gè)Section都要求加載到內(nèi)存后可讀可寫,就屬于同一個(gè)Segment。有些Section只對(duì)匯編器和鏈接器有意義,在運(yùn)行時(shí)用不到,也不需要加載到內(nèi)存,那么就不屬于任何Segment。目標(biāo)文件需要鏈接器做進(jìn)一步處理,所以一定有Section Header Table;可執(zhí)行文件需要加載運(yùn)行,所以一定有Program Header Table;而共享庫(kù)既要加載運(yùn)行,又要在加載時(shí)做動(dòng)態(tài)鏈接,所以既有Section Header Table又有Program Header Table。
圖3-1 AliOS Things?ELF
????目前的AliOS Things應(yīng)用程序ELF文件暫不支持類似于.so
文件的動(dòng)態(tài)加載和地址重定位,ELF文件一旦編譯生成之后,該ELF加載之后運(yùn)行的虛擬地址就固定(由鏈接腳本確定)下來(lái)了,如圖3-1中的Program Header中的LOAD對(duì)應(yīng)的虛擬地址起始地址是0x10000000
,相較于整個(gè)ELF文件的偏移量是0x010000
。
以前的傳統(tǒng)加載方式,分成四個(gè)步驟,如圖4-1所示:
.text
,ARM.exidx
,.ctors
,.rodata
,.ARM.extab
,.ARM.extab.text.u
,.data
,.got
,.FSymTab
部分搬運(yùn)到 虛擬地址范圍app_text_start ~ app_text_end對(duì)應(yīng)的存儲(chǔ)區(qū),同時(shí)把虛擬地址范圍app_zero_start ~ app_zero_end對(duì)應(yīng)的存儲(chǔ)區(qū)全部清零。圖4-1 傳統(tǒng)加載方式示意
通過(guò)上述步驟可以發(fā)現(xiàn)如下2個(gè)問(wèn)題:
上述2個(gè)方面也是我們新的加載器(分段快速加載引擎)重點(diǎn)優(yōu)化的兩個(gè)方面;
圖5-1?AliOS Things分段加載引擎
圖5-2?AliOS Things示意圖
????基于IP Camera客戶的應(yīng)用程序測(cè)試發(fā)現(xiàn),整個(gè)虛擬地址空間只需要映射1/4部分程序就可以正常運(yùn)行,整個(gè)ELF文件只需要讀取ELF Header和Program Header Table獲取LOAD segment字段描述信息,根據(jù)這些信息設(shè)置好缺頁(yè)中斷即可運(yùn)行,應(yīng)用程序完全運(yùn)行起來(lái),只需要加載和映射大概1/4內(nèi)容,借助于分段快速加載引擎(bengine_dload)加載2M Bytes大小的ELF文件的速度可以從500 ms優(yōu)化到80 ms左右部分,內(nèi)存開銷從3.5 MB (2MB code + 1.5MB BSS)降低到1.25 MB (256KB code + 1MB bss)。分段快速加載引擎可以對(duì)應(yīng)用程序的加載速度提高6倍以上,內(nèi)存開銷降低2.8倍。
?
如需更多技術(shù)支持,可加入釘釘開發(fā)者群,或者關(guān)注微信公眾號(hào)。
更多技術(shù)與解決方案介紹,請(qǐng)?jiān)L問(wèn)HaaS官方網(wǎng)站https://haas.iot.aliyun.com
?
文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址:http://systransis.cn/yun/121966.html
摘要:而且需要在特定的菜單位置上顯示待辦事項(xiàng)的數(shù)量。以我的博客某篇文章加載為例最右邊有個(gè)紅框標(biāo)識(shí)的就是每條資源的加載耗時(shí),我們可以看到第一條是服務(wù)端的處理速度。接下來(lái)我們就可以直接去看代碼了。在大腦中構(gòu)思了一下,其實(shí)這些完全可以通過(guò)遞歸來(lái)實(shí)現(xiàn)嘛。 原文是在我自己博客中,小伙伴也可以點(diǎn)閱讀原文進(jìn)行跳轉(zhuǎn)查看,還有好聽的背景音樂(lè)噢背景音樂(lè)已取消~ 2333333 大爺我就算功能重做,模塊重構(gòu),我...
摘要:在軟件項(xiàng)目中,定時(shí)器也被應(yīng)用到了各方各面,本文將從項(xiàng)目入手,講述定時(shí)器,本文的例子都以為例。定時(shí)器總類定時(shí)器有兩種對(duì)應(yīng)重復(fù)任務(wù)和一次性任務(wù)。 在大規(guī)模分布式系統(tǒng)中,每個(gè)業(yè)務(wù)都可能是集群,每個(gè)業(yè)務(wù)機(jī)都會(huì)產(chǎn)生定時(shí)任務(wù),不同的業(yè)務(wù)會(huì)有不同的任務(wù)管理需求,統(tǒng)一的任務(wù)調(diào)度和管理變得非常有必要。 定時(shí)如何準(zhǔn)確,大量的定時(shí)被同時(shí)觸發(fā)怎么辦? 定時(shí)結(jié)束的時(shí)候,怎么通知業(yè)務(wù)機(jī)去處理呢? 某臺(tái)業(yè)務(wù)機(jī)下線...
摘要:在軟件項(xiàng)目中,定時(shí)器也被應(yīng)用到了各方各面,本文將從項(xiàng)目入手,講述定時(shí)器,本文的例子都以為例。定時(shí)器總類定時(shí)器有兩種對(duì)應(yīng)重復(fù)任務(wù)和一次性任務(wù)。 在大規(guī)模分布式系統(tǒng)中,每個(gè)業(yè)務(wù)都可能是集群,每個(gè)業(yè)務(wù)機(jī)都會(huì)產(chǎn)生定時(shí)任務(wù),不同的業(yè)務(wù)會(huì)有不同的任務(wù)管理需求,統(tǒng)一的任務(wù)調(diào)度和管理變得非常有必要。 定時(shí)如何準(zhǔn)確,大量的定時(shí)被同時(shí)觸發(fā)怎么辦? 定時(shí)結(jié)束的時(shí)候,怎么通知業(yè)務(wù)機(jī)去處理呢? 某臺(tái)業(yè)務(wù)機(jī)下線...
摘要:初步分析提升可從兩方面入手,一個(gè)是增加并發(fā)數(shù),其二是減少平均響應(yīng)時(shí)間。大部分的時(shí)間花在系統(tǒng)與數(shù)據(jù)庫(kù)的交互上,到這,便有了一個(gè)優(yōu)化的主題思路最大限度的降低平均響應(yīng)時(shí)間。不要輕易否定一項(xiàng)公認(rèn)的技術(shù)真理,要拿數(shù)據(jù)說(shuō)話。 本文最早發(fā)表于個(gè)人博客:PylixmWiki 應(yīng)項(xiàng)目的需求,我們使用tornado開發(fā)了一個(gè)api系統(tǒng),系統(tǒng)開發(fā)完后,在8核16G的虛機(jī)上經(jīng)過(guò)壓測(cè)qps只有200+。與我們當(dāng)...
閱讀 1786·2023-04-26 01:41
閱讀 3085·2021-11-23 09:51
閱讀 2748·2021-10-09 09:43
閱讀 9063·2021-09-22 15:13
閱讀 2463·2021-09-07 09:59
閱讀 2636·2019-08-30 15:44
閱讀 1141·2019-08-30 12:45
閱讀 2628·2019-08-30 12:43