干货|Android系统定制开发基础篇

一、Android源码目录结构

Android系统源码内容实在太广,其目录结构也实在庞大,每位开发者也无法做到对每一块都弄明白,工作中接触的也只是其中的一小部分。以下只从宏观上对系统源码的一级目录进行介绍,后续再慢慢完善更细致的内容。

图片

二、Android虚拟机

1.Android虚拟机之Dalvik虚拟机

Android虚拟机的使用,使得Android应用和Linux内核分离,这样做使得Android系统更稳定可靠,比如程序中即使包含恶意代码,也不会直接影响系统文件;也提高了跨平台兼容性。在Android4.4以前的系统中,Android系统均采用Dalvik作为运行Andorid程序的虚拟机,在Android发展中具有举足轻重的地位,而Android5.0及以后的系统使用ART虚拟机取代Dalvik,在性能上做了很大的优化。这里将对这两款虚拟机做一些介绍,主要内容如下:

图片

2.Dalvik在Android架构中所处的位置

图片

Android系统架构图。从上图可以看到,Dalvik虚拟机在Android Runtime中,在Linux Kernel之上。Android其实就是一个操作系统,其底层基于Linxu Kernel,这一层有许多的驱动程序,主要完成操作系统所具备的功能。Android Runtime,即android的运行环境,我们可以类比于java的jre,即java平台运行时环境。Java程序的开发、编译和运行需要java的核心包(jdk/lib/和jre/lib)支持,然后通过JVM来运行java程序,同样android程序的运行也是如此,Libraries就相当于java的jdk/lib,是开发/编译android程序所需要的库,Android Runtime里面的Core Libraries里就相当于java的jre/lib,是运行android程序所需要的核心库,自然而然,Dalvik虚拟机也就类比于java中的JVM,用于运行android程序。

3.Dalvik的作用

Dalvik虚拟机在Android操作系统上虚拟出一个设备,用来运行android 应用程序。Dalvik是apk运行的温床,其作为面向Linux、为嵌入式操作系统特别设计的虚拟机, 主要负责完成对象的生命周期管理、堆栈管理、线程管理、安全及异常管理、垃圾回收等。Dalvik充分利用Linux进程管理的特性,对其进行了面向对象的设计,使得可以同时运行多个程序,而传统的Java程序通常只能运行一个进程,这也是为什么Android不采用JVM的原因之一。在Android中,每一个app进程对应一个Dalvik,多个app进程在运行,就对应多个虚拟机的存在,这样设计的好处就是,当一个应用crash后,只会影响自己所在的dalvik,而不会影响到整个系统,不同的进程之间(即不同的Dalvik之间)通过进程间通信来实现交互。

4.Dalvik和JVM的区别与联系

图片

图片

5.Davik的孵化器Zygote进程

在Android系统中有个一特殊的虚拟机进程Zygote,他是虚拟机实例的孵化器。它在系统启动的时候就会产生,完成虚拟机的初始化、库的加载、预制类库和初始化操作。如果系统需要一个新的虚拟机实例,他会迅速复制自身,以最快的速度提供给系统。对于一些只读的系统库,所有的虚拟机实例都和Zygote共享一块区域。

6.Dalvik的致命缺点-拖慢Android系统速度

Dalvik有个致命的弱点,就是Dalvik虚拟机一直被用户指责为拖慢Android系统运行速度而不如IOS的根源。主要原因如下:

(1).开发者因素

(2).运营商因素

(3).Dalvik运行时机制因素

在编译Android程序的时候,首先java代码被编译成class文件,然后被java打包工具dx打包成.dex文件,然后.dex文件和资源文件一起被压缩成apk文件。Apk文件其实也是zip格式,只是后缀被修改为apk,读者可以自己解压一个apk试试看。Android应用的安装过程:复制apk安装包到data/app目录下,解压并扫描安装包,把dex文件保存到dalvik-cache目录下,并在data/data目录下创建对应的应用数据目录。这样每次用户点击图标运行android程序时,dalvik虚拟机就会用JIT(Android2.2及以后版本)的方法把dex文件翻译为机器码,然后再执行机器码。虽然Dalvik虚拟机已经被做过很多优化(.dex文件基础上被优化为.odex文件,o表示optimization,“优化”的意思),但因为此种机制的存在,先翻译再执行,所以Android在电量消耗和程序运行流畅程度上一直不太理想。


Android中/data目录

图片

/data/app目录

图片

/data/app目录下应用的信息

图片

/data/dalvik-cache目录下的内容

图片

/data/data目录下应用数据目录,存储对应应用运行中产生的一些数据

图片

7.ART虚拟机取代Dalvik虚拟机

由于Dalvik虚拟机机制的问题,拖慢了android应用的速度。由此,ART(即Android RunTime)虚拟机应运而生,在Android4.4中可以在设置中切换选择Dalvik或ART作为虚拟机,在Android L(5.0)中就直接删除了Dalvik,而全面使用ART。ART在机制上做了优化,可以在第一次安装应用时,字节码就会预编译(即AOT编译:Ahead-of-time)成机器码,使其成为真正的本地应用。在点击桌面的应用图标运行时,无需再翻译字节码,而是直接运行机器码,从而提升了启动速度。另外,ART在英语单词中是“艺术”的意思,可见,ART虚拟机的设计是匠心独运,同时也是被其设计中所高度赞誉的。

8.Dalvik和ART对.dex文件的处理的对比情况

图片

9.ART的优缺点

优点

ART的AOT方式相比于Dalvik的JIT方式(Just-In-Time,即时编译,,参见JIT_百度百科),主要由如下的有优势:

(1).ART抛弃了Dalvik的JIT方式,而采用AOT预编译方式,在安装apk的过程中,将.odex文件(.dex优化后的文件)预编译为二进制机器码,存储在设备中,以后每次启动应用的时候,直接运行机器码,而无需再翻译.odex,这样极大地提高了应用的启动速度。

(2).每次运行时所做的工作也少了,这样占用了更少的CPU资源,也消耗了更少的电池资源。

(3).ART也在开发者工具和垃圾回收器上做了改善。

Dalvik和ART在性能上的对比

图片

缺点

硬币有正反面,ART的预编译,也带来了一定的劣势

(1).增加了安装时间。在安装的时候需要预编译,无疑增大了安装的工作量,从而增大了安装时间,对于一些大的应用,可能需要几分钟的时间才能安装完。

(2).需要更多的空间存储预编译后的机器码,无疑占用了更多的存储空间。当然,现在硬件设备更新换代很快,性能也非常好,相比于ART带来的优点,该缺点几乎没什么影响。

10.Android N对ART的优化

ART的机制使得apk在安装的时候比较耗时,为了改变这种状态,在Android N(Android7.0)中对此做了优化。Android N实现了一个使用AOT、解释、JIT混合模式的运行环境,这里使用的JIT是改进后的JIT,ART也提供了一种新的、更快的解释器。这种方式在apk安装的过程中不再进行预编译,第一次运行该应用相关程序后,在手机处于idle状态和充电的时候再将运行过的程序编译为机器码并存储在设备中。JIT提供了一套追踪机制来决定哪一部分代码需要在手机idle和充电的时候来编译(即热区域hot method的确定),这个追踪技术被称为Profile Guided Compilation,其工作原理如下:

(1).应用程序第一次启动的时候,只会通过解释器执行,同时JIT会介入并针对hot methods执行优化工作。代码在执行期间会被分析,分析结果被保存起来,同步输出一种被称为profile information的信息保存到文件中。该文件中记录了需要离线优化的hot methods,影响程序启动速度的Classes,它们主要用于进一步优化程序的启动速度。

(2).当设备处于idle状态并且在充电,就会进入Profile Guided Compilation服务,使用第一步中的profile information,生成二进制机器码,用于替代原始应用程序的相应部分。

(3).应用程序在后续启动时,就可以根据实际情况在AOT/JIT/Interpreter中选择最合适的执行方式了。

通过以上的步骤可以得知,因为有了Profile Guided Compilation,同一app会因为不同的用户行为产生不同的编译结果。

11.可以概括性地做一个总结:

第一次运行到某些模块的程序的时候(此次JIT信息不会持久化),产生一个文件来记录这些被执行的程序信息,从而实现了将以往在安装过程中预编译生成机器码的过程,延迟到手机处于idle和充电的时候来完成,最终实现既能避免漫长的安装等待,又不影响程序启动速度,还节约了空间(因为有些功能程序一直不被使用,就不需要编译为机器码占用空间),cpu资源,电池资源等的目的。 

三、Android系统架构和源码的联系

Android虚拟机、Android的系统架构,其实在Native Libraries层和Linux Kernel层之间还有一层HAL层,即Hardware Abstract Layer,硬件抽象层。

Android源码官网中Android系统架构图

https://source.android.google.cn/

图片

对于Android系统架构每一层,Android源码结构中都有相关目录与之对应。下图展示了在Android源码一级目录中,各框架层和部分目录的对应关系:

图片

理解Android系统结构和Android系统源码的对应关系,有助于帮助咱们理解Anroid系统源码。当然这幅思维导图中只介绍了源码一级目录和系统架构的对应关系,深入各个目录,每个系统架构层还可以找到很多源码与之对应,读者可以再深入研究研究。与此同时,同一个目录下的源码,也可能涉及多个系统架构层的内容,比如frameworks层中就有frameworks/base/packages/SystemUI这个目录,众所周知,SystemUI是一款系统App,是属于应用层的。所以,对某个目录的对应的系统架构层,也不能一概而论。

Android源码阅读工具介绍

https://source.android.google.cn/http://androidxref.com/http://aospxref.com/

查看并选择系统版本

进入首页后,可以看到Google发布的各个系统版本,按照发布时间排序,包括版本别名,版本号,内核号等

图片

源码查找主界面功能点

图片

搜索条件的解锁及使用

进行全文搜索,属于模糊查询,忽略大小写,会匹配所有的单词、字符串、标识符以及数字等,包括注释在内。如下图所示,为全文搜索“Activity”的结果,也显示了所在文件的路径,可以点击进入对应的文件。

图片

Android系统所有版本
https://www.androidos.net.cn/sourcecode

Android Kernel系统所有版本
https://www.androidos.net.cn/sourcecode

Android系统核心服务
https://www.androidos.net.cn/androidservice

https://download.mokeedev.com/
https://wiki.lineageos.org/devices/

https://github.com/MoKee
https://github.com/LineageOS

鸿蒙Harmony OS核心架构

鸿蒙系统(HarmonyOS)应用开发入门篇

Ubuntu20.04.2.0环境的安装与配置过程

Android10系统源码的下载与编译方法(完美编译)

Android11系统源码的下载与编译方法(解决内存、磁盘不足问题)

Ubuntu虚拟机环境搭建Android系统源码编译环境及问题解决方法

Ubuntu18.04/20.04虚拟机编译Android4/5/6/7/8/9/10/11系统源码的问题解决

Ubuntu环境Python3版本的更新升级使用方法

Ubuntu安装配置切换Python3版本的解决方法

ndk配置内核交叉编译环境(1)

内核交叉编译配置定制和编译(2)

内核篇加载内核模块(Android10)

内核系统调用openat Hook

Android8.1虚拟化定制系统定制

Android9一键安全手机

Android10系统源码的下载与编译方法(完美编译)

Android11系统源码的下载与编译方法(解决内存、磁盘不足问题)

原文链接

经典|Android系统定制开发基础篇

图片

  • 12
    点赞
  • 98
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 5
    评论
### 回答1: Spark Streaming 和 Flink 都是流处理框架,但在一些方面有所不同。 1. 数据处理模型 Spark Streaming 基于批处理模型,将流数据分成一批批进行处理。而 Flink 则是基于流处理模型,可以实时处理数据流。 2. 窗口处理 Spark Streaming 的窗口处理是基于时间的,即将一段时间内的数据作为一个窗口进行处理。而 Flink 的窗口处理可以基于时间和数据量,可以更加灵活地进行窗口处理。 3. 状态管理 Spark Streaming 的状态管理是基于 RDD 的,需要将状态存储在内存中。而 Flink 的状态管理是基于内存和磁盘的,可以更加灵活地管理状态。 4. 容错性 Flink 的容错性比 Spark Streaming 更加强大,可以在节点故障时快速恢复,而 Spark Streaming 则需要重新计算整个批次的数据。 总的来说,Flink 在流处理方面更加强大和灵活,而 Spark Streaming 则更适合批处理和数据仓库等场景。 ### 回答2: Spark Streaming 和 Flink 都是流处理框架,它们都支持低延迟的流处理和高吞吐量的批处理。但是,它们在处理数据流的方式和性能上有许多不同之处。下面是它们的详细比较: 1. 处理模型 Spark Streaming 采用离散化流处理模型(DPM),将长周期的数据流划分为离散化的小批量,每个批次的数据被存储在 RDD 中进行处理,因此 Spark Streaming 具有较好的容错性和可靠性。而 Flink 采用连续流处理模型(CPM),能够在其流处理过程中进行事件时间处理和状态管理,因此 Flink 更适合处理需要精确时间戳和状态管理的应用场景。 2. 数据延迟 Spark Streaming 在处理数据流时会有一定的延迟,主要是由于对数据进行缓存和离散化处理的原因。而 Flink 的数据延迟比 Spark Streaming 更低,因为 Flink 的数据处理和计算过程是实时进行的,不需要缓存和离散化处理。 3. 机器资源和负载均衡 Spark Streaming 采用了 Spark 的机器资源调度和负载均衡机制,它们之间具有相同的容错和资源管理特性。而 Flink 使用 Yarn 和 Mesos 等分布式计算框架进行机器资源调度和负载均衡,因此 Flink 在大规模集群上的性能表现更好。 4. 数据窗口处理 Spark Streaming 提供了滑动、翻转和窗口操作等灵活的数据窗口处理功能,可以使用户更好地控制数据处理的逻辑。而 Flink 也提供了滚动窗口和滑动窗口处理功能,但相对于 Spark Streaming 更加灵活,可以在事件时间和处理时间上进行窗口处理,并且支持增量聚合和全量聚合两种方式。 5. 集成生态系统 Spark Streaming 作为 Apache Spark 的一部分,可以充分利用 Spark 的分布式计算和批处理生态系统,并且支持许多不同类型的数据源,包括Kafka、Flume和HDFS等。而 Flink 提供了完整的流处理生态系统,包括流SQL查询、流机器学习和流图形处理等功能,能够灵活地适应不同的业务场景。 总之,Spark Streaming 和 Flink 都是出色的流处理框架,在不同的场景下都能够发挥出很好的性能。选择哪种框架取决于实际需求和业务场景。 ### 回答3: Spark Streaming和Flink都是流处理引擎,但它们的设计和实现方式有所不同。在下面的对比中,我们将比较这两种流处理引擎的主要特点和差异。 1. 处理模型 Spark Streaming采用离散流处理模型,即将数据按时间间隔分割成一批一批数据进行处理。这种方式可以使得Spark Streaming具有高吞吐量和低延迟,但也会导致数据处理的粒度比较粗,难以应对大量实时事件的高吞吐量。 相比之下,Flink采用连续流处理模型,即数据的处理是连续的、实时的。与Spark Streaming不同,Flink的流处理引擎能够应对各种不同的实时场景。Flink的实时流处理能力更强,因此在某些特定的场景下,它的性能可能比Spark Streaming更好。 2. 窗口计算 Spark Streaming内置了许多的窗口计算支持,如滑动窗口、滚动窗口,但支持的窗口计算的灵活性较低,只适合于一些简单的窗口计算。而Flink的窗口计算支持非常灵活,可以支持任意窗口大小或滑动跨度。 3. 数据库支持 在处理大数据时,存储和读取数据是非常重要的。Spark Streaming通常使用HDFS作为其数据存储底层的系统。而Flink支持许多不同的数据存储形式,包括HDFS,以及许多其他开源和商业的数据存储,如Kafka、Cassandra和Elasticsearch等。 4. 处理性能 Spark Streaming的性能比Flink慢一些,尤其是在特定的情况下,例如在处理高吞吐量的数据时,在某些情况下可能受制于分批处理的架构。Flink通过其流处理模型和不同的调度器和优化器来支持更高效的实时数据处理。 5. 生态系统 Spark有着庞大的生态系统,具有成熟的ML库、图处理库、SQL框架等等。而Flink的生态系统相对较小,但它正在不断地发展壮大。 6. 规模性 Spark Streaming适用于规模小且不太复杂的项目。而Flink可扩展性更好,适用于更大、更复杂的项目。Flink也可以处理无限制的数据流。 综上所述,Spark Streaming和Flink都是流处理引擎,它们有各自的优缺点。在选择使用哪一个流处理引擎时,需要根据实际业务场景和需求进行选择。如果你的业务场景较为复杂,需要处理海量数据并且需要比较灵活的窗口计算支持,那么Flink可能是更好的选择;如果你只需要简单的流处理和一些通用的窗口计算,Spark Streaming是更为简单的选择。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 5
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

哆啦安全

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值