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