摘要:本文主要介绍应用程序加载如何做到毫秒级耗时。图不同视角看左边是从汇编器和链接器的视角来看这个文件,开头的描述了体系结构和操作系统等基本信息,并指出和在文件中的什么位置,在汇编和链接过程中没有用到,所以是可有可的,中保存了所有的描述信息。
AliOS Thing 是AliOS家族旗下面向IoT领域的、高可伸缩的物联网操作系统,AliOS Thing v3.2[1]以后的版本提供了内核和应用程序分离的功能,内核和应用分别运行在不同的虚拟地址空间,即使应用程序出现问题也不会影响到内核的运行。内核和应用程序的隔离,不仅可以达到安全的目的,还可以有效降低应用开发的成本,并且应用程序以标准的ELF (Executable and Linkable Format)[2]文件存在,系统需要运行哪一个应用程序,只需要加载该应用程序的ELF文件即可。
本文主要介绍AliOS Things应用程序加载如何做到“毫秒级”耗时。
图1-1 AliOS Things
ELF文件格式提供了两种不同的视角,在汇编器和链接器看来,ELF文件是由Section Header Table描述的一系列Section的集合,而执行一个ELF文件时,在加载器Loader看来它是由Program Header Table描述的一系列Segment的集合。
图2-1 不同视角看ELF
左边是从汇编器和链接器的视角来看这个文件,开头的ELF Header描述了体系结构和操作系统等基本信息,并指出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是指在程序运行时加载到内存的具有相同属性的区域,由一个或多个Section组成,比如有两个Section都要求加载到内存后可读可写,就属于同一个Segment。有些Section只对汇编器和链接器有意义,在运行时用不到,也不需要加载到内存,那么就不属于任何Segment。目标文件需要链接器做进一步处理,所以一定有Section Header Table;可执行文件需要加载运行,所以一定有Program Header Table;而共享库既要加载运行,又要在加载时做动态链接,所以既有Section Header Table又有Program Header Table。
图3-1 AliOS Things ELF
目前的AliOS Things应用程序ELF文件暂不支持类似于.so
文件的动态加载和地址重定位,ELF文件一旦编译生成之后,该ELF加载之后运行的虚拟地址就固定(由链接脚本确定)下来了,如图3-1中的Program Header中的LOAD对应的虚拟地址起始地址是0x10000000
,相较于整个ELF文件的偏移量是0x010000
。
以前的传统加载方式,分成四个步骤,如图4-1所示:
.text
,ARM.exidx
,.ctors
,.rodata
,.ARM.extab
,.ARM.extab.text.u
,.data
,.got
,.FSymTab
部分搬运到 虚拟地址范围app_text_start ~ app_text_end对应的存储区,同时把虚拟地址范围app_zero_start ~ app_zero_end对应的存储区全部清零。图4-1 传统加载方式示意
通过上述步骤可以发现如下2个问题:
上述2个方面也是我们新的加载器(分段快速加载引擎)重点优化的两个方面;
图5-1 AliOS Things分段加载引擎
图5-2 AliOS Things示意图
基于IP Camera客户的应用程序测试发现,整个虚拟地址空间只需要映射1/4部分程序就可以正常运行,整个ELF文件只需要读取ELF Header和Program Header Table获取LOAD segment字段描述信息,根据这些信息设置好缺页中断即可运行,应用程序完全运行起来,只需要加载和映射大概1/4内容,借助于分段快速加载引擎(bengine_dload)加载2M Bytes大小的ELF文件的速度可以从500 ms优化到80 ms左右部分,内存开销从3.5 MB (2MB code + 1.5MB BSS)降低到1.25 MB (256KB code + 1MB bss)。分段快速加载引擎可以对应用程序的加载速度提高6倍以上,内存开销降低2.8倍。
如需更多技术支持,可加入钉钉开发者群,或者关注微信公众号。
更多技术与解决方案介绍,请访问HaaS官方网站https://haas.iot.aliyun.com
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/121966.html
摘要:而且需要在特定的菜单位置上显示待办事项的数量。以我的博客某篇文章加载为例最右边有个红框标识的就是每条资源的加载耗时,我们可以看到第一条是服务端的处理速度。接下来我们就可以直接去看代码了。在大脑中构思了一下,其实这些完全可以通过递归来实现嘛。 原文是在我自己博客中,小伙伴也可以点阅读原文进行跳转查看,还有好听的背景音乐噢背景音乐已取消~ 2333333 大爷我就算功能重做,模块重构,我...
摘要:在软件项目中,定时器也被应用到了各方各面,本文将从项目入手,讲述定时器,本文的例子都以为例。定时器总类定时器有两种对应重复任务和一次性任务。 在大规模分布式系统中,每个业务都可能是集群,每个业务机都会产生定时任务,不同的业务会有不同的任务管理需求,统一的任务调度和管理变得非常有必要。 定时如何准确,大量的定时被同时触发怎么办? 定时结束的时候,怎么通知业务机去处理呢? 某台业务机下线...
摘要:在软件项目中,定时器也被应用到了各方各面,本文将从项目入手,讲述定时器,本文的例子都以为例。定时器总类定时器有两种对应重复任务和一次性任务。 在大规模分布式系统中,每个业务都可能是集群,每个业务机都会产生定时任务,不同的业务会有不同的任务管理需求,统一的任务调度和管理变得非常有必要。 定时如何准确,大量的定时被同时触发怎么办? 定时结束的时候,怎么通知业务机去处理呢? 某台业务机下线...
摘要:初步分析提升可从两方面入手,一个是增加并发数,其二是减少平均响应时间。大部分的时间花在系统与数据库的交互上,到这,便有了一个优化的主题思路最大限度的降低平均响应时间。不要轻易否定一项公认的技术真理,要拿数据说话。 本文最早发表于个人博客:PylixmWiki 应项目的需求,我们使用tornado开发了一个api系统,系统开发完后,在8核16G的虚机上经过压测qps只有200+。与我们当...
阅读 1739·2023-04-26 01:41
阅读 3025·2021-11-23 09:51
阅读 2695·2021-10-09 09:43
阅读 8813·2021-09-22 15:13
阅读 2386·2021-09-07 09:59
阅读 2595·2019-08-30 15:44
阅读 1070·2019-08-30 12:45
阅读 2576·2019-08-30 12:43