鸿蒙内核源码分析(ninja应用篇) | 简单而快速的构建系统 | 百篇博客分析HarmonyOS源码 | v61.01
作者:互联网
百篇博客系列篇.本篇为:
v61.xx 鸿蒙内核源码分析(ninja应用篇) | 简单而快速的构建系统 | 51 .c .h .o
编译构建模块相关篇为:
- v60.xx 鸿蒙内核源码分析(gn应用篇) | gn语法及在鸿蒙的使用 | 51 .c .h .o
- v59.xx 鸿蒙内核源码分析(构建工具篇) | 顺瓜摸藤调试鸿蒙构建过程 | 51 .c .h .o
- v58.xx 鸿蒙内核源码分析(环境脚本篇) | 编译鸿蒙原来如此简单 | 51 .c .h .o
- v57.xx 鸿蒙内核源码分析(编译过程篇) | 简单案例窥视GCC编译全过程 | 51 .c .h .o
- v50.xx 鸿蒙内核源码分析(编译环境篇) | docker编译鸿蒙真的很香 | 51 .c .h .o
ninja是什么?
ninja
是一个重视速度的构建系统,与其对标的是Make
,它们都依赖于文件的时间戳进行检测重编.
- 它的设计目的是让更高级别的构建系统生成其输入端文件,其并不希望你手动去编
.ninja
文件,可以生成.ninja
的工具有gn
,cmake
,premake
,甚至你自己都可以写个ninja
生成工具. ninja
非常高效,可理解为构建系统中的汇编语言。ninja
文件没有分支、循环的流程控制,是被指定了一堆规则的文件,所以要比Makefile
简单很多- 目前已知的
GoogleChrome
,Android
的一部分,LLVM
,V8
, 方舟编译器, 鸿蒙 等大型系统都使用到了ninja
构建.
基本概念
概念 中译 解释
edge 边 即build语句,指定目标(输出)、规则与输入,是编译过程拓扑图中的一条边(edge)。
target 目标 编译过程需要产生的目标,由build语句指定。
output 输出 build语句的前半段,是target的另一种称呼。
input 输入 build语句的后半段,用来产生output的文件或目标,另一种称呼是依赖。
rule 规则 通过指定command与一些内置变量,决定如何从输入产生输出。
pool 池 一组rule或edge,通过指定其depth,可以控制并行上限。
scope 作用域 变量的作用范围,有rule与build语句的块级,也有文件级别。rule也有scope。
--------------------------------------------------------------------------------------------
关键字 作用
build 定义一个edge。
rule 定义一个rule。
pool 定义一个pool。
default 指定默认的一个或多个target。
include 添加一个ninja文件到当前scope。
subninja 添加一个ninja文件,其scope与当前文件不同。
phony 一个内置的特殊规则,指定非文件的target。
简单的ninja
首先 ninja
一定是简单的,呆板的.凡是能被工具生成的东西,一定是在不断的重复某种简单,众多的简单按一定的规则有效叠加起来就能解决复杂的问题,请仔细想想是不是这个道理.ninja
简单到没什么语法,只是几个概念和规则. 以至于 ninja参考手册 比 gn参考手册 简单的太多.
看个示例:
cflags = -Wall -Werror #全局变量
rule cc
command = gcc $cflags -c $in -o $out
build foo.o: cc foo.c
build special.o: cc special.c
cflags = -Wall #局部变量,范围只在编译special.c上有效
解读
cflags
:定义一个用户变量,用于给规则传参.rule
:定义一个叫cc
的规则.command
:将生成bash命令,接收外部三个参数
- 第一个
build
,将foo.c
用cc
规则编译成foo.o
- 最终编译选项:
gcc -Wall -Werror -c foo.c -o foo.o
- 最终编译选项:
- 第二个
build
,将special.c
用cc
规则编译成special.o
- 最终编译选项:
gcc -Wall -c foo.c -o foo.o
- 最终编译选项:
in
,out
是ninja
的两个内置变量.
phony规则
跟称呼弗拉基米尔·弗拉基米罗维奇·普京
为普总
一样, 有些文件路径会很长,ninja
提供取别名的功能,这仅仅是为了方便.
build ability: phony ./libability.so
build ability_notes: phony obj/foundation/aafwk/aafwk_lite/frameworks/ability_lite/ability_notes.stamp
build ability_test: phony obj/foundation/aafwk/aafwk_lite/services/abilitymgr_lite/unittest/ability_test.stamp
build ability_test_pageAbilityTest_group_lv0: phony obj/foundation/aafwk/aafwk_lite/services/abilitymgr_lite/unittest/test_lv0/page_ability_test/ability_test_pageAbilityTest_group_lv0.stamp
有了上面的铺垫,读懂鸿蒙的ninja
部分应该没多大障碍了.
鸿蒙 | ninja
在v60.xx 鸿蒙内核源码分析(gn应用篇) | gn语法及在鸿蒙的使用 | 51 .c .h .o 篇的末尾已说明通过 gn gen
生成了以下文件和目录
turing@ubuntu:/home/openharmony/code-v1.1.1-LTS/out/hispark_aries/ipcamera_hispark_aries$ ls
args.gn build.ninja build.ninja.d NOTICE_FILE obj test_info toolchain.ninja
args.gn
:一些参数build.ninja
:ninja
的主文件build.ninja.d
:记录生成所有.ninja
所依赖的BUILD.gn文件路劲列表,一个BUILD.gn就生成一个.ninja文件- obj :各组件模块构建/编译文件输出地.
- toolchain :放置ninja规则,将被 subninja 进 build.ninja
build.ninja
build.ninja
内容如下:
ninja_required_version = 1.7.2
rule gn
command = ../../../../tools/gn --root=../../.. -q --dotfile=../../../build/lite/.gn --script-executable=python3 gen .
description = Regenerating ninja files
build build.ninja: gn
generator = 1
depfile = build.ninja.d
subninja toolchain.ninja
build ability: phony ./libability.so
build ability_notes: phony obj/foundation/aafwk/aafwk_lite/frameworks/ability_lite/ability_notes.stamp
build ability_test: phony obj/foundation/aafwk/aafwk_lite/services/abilitymgr_lite/unittest/ability_test.stamp
build ability_test_pageAbilityTest_group_lv0: phony obj/foundation/aafwk/aafwk_lite/services/abilitymgr_lite/unittest/test_lv0/page_ability_test/ability_test_pageAbilityTest_group_lv0.stamp
#此处省略诸多 phony ..
build all: phony $
./libcameraApp.so $
obj/applications/sample/camera/cameraApp/cameraApp_hap.stamp $
./libgallery.so $
...
default all
解读
- 前面部分是定义一个
gn
规则,用于干嘛呢? 重新生成一遍*ninja
文件 subninja
相当于#include
文件default all
,指定默认的一个或多个target
toolchain | 定义规则
toolchain.ninja
定义了编译c,c++,汇编器,链接,静态/动态链接库,时间戳,拷贝等规则. 内容如下:
rule cxx
command = /root/llvm/bin/clang++ ${defines} ${include_dirs} ${cflags_cc} -c ${in} -o ${out}
description = clang++ ${out}
depfile = ${out}.d
deps = gcc
rule alink
command = /root/llvm/bin/llvm-ar -cr ${out} @"${out}.rsp"
description = AR ${out}
rspfile = ${out}.rsp
rspfile_content = ${in}
rule link
command = /root/llvm/bin/clang ${ldflags} ${in} ${libs} -o ${output_dir}/bin/${target_output_name}${output_extension}
description = LLVM LINK ${output_dir}/bin/${target_output_name}${output_extension}
rspfile = ${output_dir}/bin/${target_output_name}${output_extension}.rsp
rspfile_content = ${in}
rule solink
command = /root/llvm/bin/clang -shared ${ldflags} ${in} ${libs} -o ${output_dir}/${target_output_name}${output_extension}
description = SOLINK ${output_dir}/${target_output_name}${output_extension}
rspfile = ${output_dir}/${target_output_name}${output_extension}.rsp
rspfile_content = ${in}
rule stamp
command = /usr/bin/touch ${out}
description = STAMP ${out}
rule asm
command = /root/llvm/bin/clang ${include_dirs} ${asmflags} -c ${in} -o ${out}
description = ASM ${out}
depfile = ${out}.d
deps = gcc
rule cc
command = /root/llvm/bin/clang ${defines} ${include_dirs} ${cflags} ${cflags_c} -c ${in} -o ${out}
description = clang ${out}
rule copy
command = cp -afd ${in} ${out}
description = COPY ${in} ${out}
-
注意这些规则中的描述
description
字段,其后面的内容会打到控制台上,每一条输出都是一次build
,如图所示,通过这些描述就知道使用了什么规则去构建.
组件编译
本篇以编译ability
组件为例说明 ninja
对组件的编译情况.每个组件都有自己的.ninja
,描述组件的编译细节.而整个鸿蒙系统就是由众多的类似.ninja
构建编译完成的.
├── foundation
│ ├── aafwk
│ │ └── aafwk_lite
│ │ ├── frameworks
│ │ │ ├── ability_lite
│ │ │ │ └── ability.ninja
ability.ninja
内容如下:
defines = -DOHOS_APPEXECFWK_BMS_BUNDLEMANAGER \
-D_XOPEN_SOURCE=700 -DOHOS_DEBUG \
-D_FORTIFY_SOURCE=2 \
-D__LITEOS__ -D__LITEOS_A__
include_dirs = -I../../../foundation/aafwk/aafwk_lite/frameworks/abilitymgr_lite/include \
-I../../../foundation/aafwk/aafwk_lite/frameworks/want_lite/include \
-I../../../foundation/aafwk/aafwk_lite/interfaces/innerkits/abilitymgr_lite \
-I../../../foundation/aafwk/aafwk_lite/interfaces/kits/want_lite \
-I../../../foundation/aafwk/aafwk_lite/interfaces/kits/ability_lite \
-I../../../foundation/appexecfwk/appexecfwk_lite/utils/bundle_lite \
-I../../../foundation/appexecfwk/appexecfwk_lite/interfaces/kits/bundle_lite \
-I../../../foundation/appexecfwk/appexecfwk_lite/frameworks/bundle_lite/include \
-I../../../foundation/graphic/ui/frameworks -I../../../foundation/graphic/surface/interfaces/kits \
-I../../../foundation/distributedschedule/samgr_lite/interfaces/kits/registry \
-I../../../foundation/distributedschedule/samgr_lite/interfaces/kits/samgr \
-I../../../foundation/communication/ipc_lite/frameworks/liteipc/include \
-I../../../kernel/liteos_a/kernel/include \
-I../../../kernel/liteos_a/kernel/common \
-I../../../third_party/bounds_checking_function/include \
-I../../../third_party/freetype/include \
-I../../../utils/native/lite/kv_store/innerkits \
-I../../../utils/native/lite/include \
-I../../../foundation/aafwk/aafwk_lite/frameworks/ability_lite/include \
-I../../../foundation/aafwk/aafwk_lite/frameworks/ability_lite \
-I/root/llvm/include/c++/v1 \
-I../../../prebuilts/lite/sysroot/usr/include/arm-liteos \
-I../../../base/hiviewdfx/hilog_lite/interfaces/native/innerkits/hilog \
-I../../../base/hiviewdfx/hilog_lite/interfaces/native/innerkits \
-I../../../third_party/bounds_checking_function/include \
-I../../../third_party/bounds_checking_function/include \
-I../../../foundation/communication/ipc_lite/interfaces/kits \
-I../../../utils/native/lite/include
cflags = -Wall -Wno-format -Wno-format-extra-args -fPIC \
--target=arm-liteos \
--sysroot=/home/openharmony/prebuilts/lite/sysroot \
-Oz -flto -mfloat-abi=softfp -mcpu=cortex-a7 -nostdlib -fno-common -fno-builtin -fno-strict-aliasing -Wall -fsigned-char -mno-unaligned-access -fno-omit-frame-pointer -fstack-protector-all -fPIC
cflags_cc = -Wall -Wno-format -Wno-format-extra-args -fPIC \
--target=arm-liteos \
--sysroot=/home/openharmony/prebuilts/lite/sysroot \
-Oz -flto -mfloat-abi=softfp -mcpu=cortex-a7 -nostdlib -fno-common -fno-builtin -fno-strict-aliasing -Wall -mno-unaligned-access -fno-omit-frame-pointer -fstack-protector-all -fexceptions -std=c++11 -fPIC
target_output_name = libability
build obj/foundation/aafwk/aafwk_lite/frameworks/ability_lite/src/libability.ability.o: cxx ../../../foundation/aafwk/aafwk_lite/frameworks/ability_lite/src/ability.cpp
build obj/foundation/aafwk/aafwk_lite/frameworks/ability_lite/src/libability.ability_context.o: cxx ../../../foundation/aafwk/aafwk_lite/frameworks/ability_lite/src/ability_context.cpp
build obj/foundation/aafwk/aafwk_lite/frameworks/ability_lite/src/libability.ability_env.o: cxx ../../../foundation/aafwk/aafwk_lite/frameworks/ability_lite/src/ability_env.cpp
build obj/foundation/aafwk/aafwk_lite/frameworks/ability_lite/src/libability.ability_env_impl.o: cxx ../../../foundation/aafwk/aafwk_lite/frameworks/ability_lite/src/ability_env_impl.cpp
build obj/foundation/aafwk/aafwk_lite/frameworks/ability_lite/src/libability.ability_event_handler.o: cxx ../../../foundation/aafwk/aafwk_lite/frameworks/ability_lite/src/ability_event_handler.cpp
build obj/foundation/aafwk/aafwk_lite/frameworks/ability_lite/src/libability.ability_loader.o: cxx ../../../foundation/aafwk/aafwk_lite/frameworks/ability_lite/src/ability_loader.cpp
build obj/foundation/aafwk/aafwk_lite/frameworks/ability_lite/src/libability.ability_main.o: cxx ../../../foundation/aafwk/aafwk_lite/frameworks/ability_lite/src/ability_main.cpp
build obj/foundation/aafwk/aafwk_lite/frameworks/ability_lite/src/libability.ability_scheduler.o: cxx ../../../foundation/aafwk/aafwk_lite/frameworks/ability_lite/src/ability_scheduler.cpp
build obj/foundation/aafwk/aafwk_lite/frameworks/ability_lite/src/libability.ability_thread.o: cxx ../../../foundation/aafwk/aafwk_lite/frameworks/ability_lite/src/ability_thread.cpp
build ./libability.so: solink \
obj/foundation/aafwk/aafwk_lite/frameworks/ability_lite/src/libability.ability.o \
obj/foundation/aafwk/aafwk_lite/frameworks/ability_lite/src/libability.ability_context.o \
obj/foundation/aafwk/aafwk_lite/frameworks/ability_lite/src/libability.ability_env.o \
obj/foundation/aafwk/aafwk_lite/frameworks/ability_lite/src/libability.ability_env_impl.o \
obj/foundation/aafwk/aafwk_lite/frameworks/ability_lite/src/libability.ability_event_handler.o \
obj/foundation/aafwk/aafwk_lite/frameworks/ability_lite/src/libability.ability_loader.o \
obj/foundation/aafwk/aafwk_lite/frameworks/ability_lite/src/libability.ability_main.o \
obj/foundation/aafwk/aafwk_lite/frameworks/ability_lite/src/libability.ability_scheduler.o \
obj/foundation/aafwk/aafwk_lite/frameworks/ability_lite/src/libability.ability_thread.o \
./libabilitymanager.so ./libbundle.so ./libhilog_shared.so ./libliteipc_adapter.so \
./libsec_shared.so ./libutils_kv_store.so || obj/utils/native/lite/kv_store/kv_store.stamp
ldflags = -lstdc++ \
--target=arm-liteos \
--sysroot=/home/openharmony/prebuilts/lite/sysroot \
-L/root/llvm/lib/arm-liteos/c++ \
-L/home/openharmony/prebuilts/lite/sysroot/usr/lib/arm-liteos \
-L/root/llvm/lib/clang/9.0.0/lib/arm-liteos \
-lclang_rt.builtins -lc -lc++ -lc++abi \
--sysroot=/home/openharmony/prebuilts/lite/sysroot \
-mcpu=cortex-a7 -lc \
-L/home/openharmony/out/hispark_aries/ipcamera_hispark_aries \
-Wl,-rpath-link=/home/openharmony/out/hispark_aries/ipcamera_hispark_aries -Wl,-z,now -Wl,-z,relro -Wl,-z,noexecstack
libs =
frameworks =
output_extension = .so
output_dir = .
解读
defines
,include_dirs
,cflags_cc
都是用户自定义变量,为了给rule cxx
准备参数,对.cpp
的编译使用了这个规则rule cxx command = /root/llvm/bin/clang++ ${defines} ${include_dirs} ${cflags_cc} -c ${in} -o ${out} description = clang++ ${out} depfile = ${out}.d deps = gcc
in
,out
是两个内置变量,无须定义,值由build
提供,如此就编译成了一个个的.o
文件.- 在最后在当前目录下使用了
solink
规则,生成一个动态链接库libability.so
.rule solink command = /root/llvm/bin/clang -shared ${ldflags} ${in} ${libs} -o ${output_dir}/${target_output_name}${output_extension} description = SOLINK ${output_dir}/${target_output_name}${output_extension} rspfile = ${output_dir}/${target_output_name}${output_extension}.rsp rspfile_content = ${in}
ability | 最终生成文件
turing@ubuntu:/home/openharmony/code-v1.1.1-LTS/out/hispark_aries/ipcamera_hispark_aries/obj/foundation/aafwk/aafwk_lite/frameworks/ability_lite$ tree
.
├── aafwk_abilitykit_lite.stamp
├── ability.ninja
├── ability_notes.stamp
└── src
├── libability.ability_context.o
├── libability.ability_env_impl.o
├── libability.ability_env.o
├── libability.ability_event_handler.o
├── libability.ability_loader.o
├── libability.ability_main.o
├── libability.ability.o
├── libability.ability_scheduler.o
└── libability.ability_thread.o
1 directory, 12 files
turing@ubuntu:/home/openharmony/code-v1.1.1-LTS/out/hispark_aries/ipcamera_hispark_aries/obj/foundation/aafwk/aafwk_lite/frameworks/ability_lite$ stat ability_notes.stamp
File: ability_notes.stamp
Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: 805h/2053d Inode: 1217028 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ turing) Gid: ( 0/ root)
Access: 2021-07-21 00:38:52.237373740 -0700
Modify: 2021-07-21 00:34:30.207312566 -0700
Change: 2021-07-21 00:34:30.207312566 -0700
百篇博客.往期回顾
在加注过程中,整理出以下文章。内容立足源码,常以生活场景打比方尽可能多的将内核知识点置入某种场景,具有画面感,容易理解记忆。说别人能听得懂的话很重要! 百篇博客绝不是百度教条式的在说一堆诘屈聱牙的概念,那没什么意思。更希望让内核变得栩栩如生,倍感亲切.确实有难度,自不量力,但已经出发,回头已是不可能的了。 :P
与代码有bug需不断debug一样,文章和注解内容会存在不少错漏之处,请多包涵,但会反复修正,持续更新,.xx
代表修改的次数,精雕细琢,言简意赅,力求打造精品内容。
-
v61.xx 鸿蒙内核源码分析(ninja应用篇) | 简单而快速的构建系统 | 51 .c .h .o
-
v60.xx 鸿蒙内核源码分析(gn应用篇) | gn语法及在鸿蒙的使用 | 51 .c .h .o
-
v59.xx 鸿蒙内核源码分析(构建工具篇) | 顺瓜摸藤调试鸿蒙构建过程 | 51 .c .h .o
-
v58.xx 鸿蒙内核源码分析(环境脚本篇) | 编译鸿蒙原来如此简单 | 51 .c .h .o
-
v57.xx 鸿蒙内核源码分析(编译过程篇) | 简单案例窥视GCC编译全过程 | 51 .c .h .o
-
v56.xx 鸿蒙内核源码分析(进程映像篇) | ELF是如何被加载运行的? | 51 .c .h .o
-
v55.xx 鸿蒙内核源码分析(重定位篇) | 与国际接轨的对外部发言人 | 51 .c .h .o
-
v54.xx 鸿蒙内核源码分析(静态链接篇) | 完整小项目看透静态链接过程 | 51 .c .h .o
-
v53.xx 鸿蒙内核源码分析(ELF解析篇) | 你要忘了她姐俩你就不是银 | 51 .c .h .o
-
v52.xx 鸿蒙内核源码分析(静态站点篇) | 五一哪也没去就干了这事 | 51 .c .h .o
-
v51.xx 鸿蒙内核源码分析(ELF格式篇) | 应用程序入口并不是main | 51 .c .h .o
-
v50.xx 鸿蒙内核源码分析(编译环境篇) | docker编译鸿蒙真的很香 | 51 .c .h .o
-
v49.xx 鸿蒙内核源码分析(信号消费篇) | 谁让CPU连续四次换栈运行 | 51 .c .h .o
-
v48.xx 鸿蒙内核源码分析(信号生产篇) | 年过半百,依然活力十足 | 51 .c .h .o
-
v47.xx 鸿蒙内核源码分析(进程回收篇) | 临终前如何向老祖宗托孤 | 51 .c .h .o
-
v46.xx 鸿蒙内核源码分析(特殊进程篇) | 龙生龙凤生凤老鼠生儿会打洞 | 51 .c .h .o
-
v45.xx 鸿蒙内核源码分析(Fork篇) | 一次调用,两次返回 | 51 .c .h .o
-
v44.xx 鸿蒙内核源码分析(中断管理篇) | 江湖从此不再怕中断 | 51 .c .h .o
-
v43.xx 鸿蒙内核源码分析(中断概念篇) | 海公公的日常工作 | 51 .c .h .o
-
v42.xx 鸿蒙内核源码分析(中断切换篇) | 系统因中断活力四射 | 51 .c .h .o
-
v41.xx 鸿蒙内核源码分析(任务切换篇) | 看汇编如何切换任务 | 51 .c .h .o
-
v40.xx 鸿蒙内核源码分析(汇编汇总篇) | 汇编可爱如邻家女孩 | 51 .c .h .o
-
v39.xx 鸿蒙内核源码分析(异常接管篇) | 社会很单纯,复杂的是人 | 51 .c .h .o
-
v38.xx 鸿蒙内核源码分析(寄存器篇) | 小强乃宇宙最忙存储器 | 51 .c .h .o
-
v37.xx 鸿蒙内核源码分析(系统调用篇) | 开发者永远的口头禅 | 51 .c .h .o
-
v36.xx 鸿蒙内核源码分析(工作模式篇) | CPU是韦小宝,七个老婆 | 51 .c .h .o
-
v35.xx 鸿蒙内核源码分析(时间管理篇) | 谁是内核基本时间单位 | 51 .c .h .o
-
v34.xx 鸿蒙内核源码分析(原子操作篇) | 谁在为原子操作保驾护航 | 51 .c .h .o
-
v33.xx 鸿蒙内核源码分析(消息队列篇) | 进程间如何异步传递大数据 | 51 .c .h .o
-
v32.xx 鸿蒙内核源码分析(CPU篇) | 整个内核就是一个死循环 | 51 .c .h .o
-
v31.xx 鸿蒙内核源码分析(定时器篇) | 哪个任务的优先级最高 | 51 .c .h .o
-
v30.xx 鸿蒙内核源码分析(事件控制篇) | 任务间多对多的同步方案 | 51 .c .h .o
-
v29.xx 鸿蒙内核源码分析(信号量篇) | 谁在负责解决任务的同步 | 51 .c .h .o
-
v28.xx 鸿蒙内核源码分析(进程通讯篇) | 九种进程间通讯方式速揽 | 51 .c .h .o
-
v27.xx 鸿蒙内核源码分析(互斥锁篇) | 比自旋锁丰满的互斥锁 | 51 .c .h .o
-
v26.xx 鸿蒙内核源码分析(自旋锁篇) | 自旋锁当立贞节牌坊 | 51 .c .h .o
-
v25.xx 鸿蒙内核源码分析(并发并行篇) | 听过无数遍的两个概念 | 51 .c .h .o
-
v24.xx 鸿蒙内核源码分析(进程概念篇) | 进程在管理哪些资源 | 51 .c .h .o
-
v23.xx 鸿蒙内核源码分析(汇编传参篇) | 如何传递复杂的参数 | 51 .c .h .o
-
v22.xx 鸿蒙内核源码分析(汇编基础篇) | CPU在哪里打卡上班 | 51 .c .h .o
-
v21.xx 鸿蒙内核源码分析(线程概念篇) | 是谁在不断的折腾CPU | 51 .c .h .o
-
v20.xx 鸿蒙内核源码分析(用栈方式篇) | 程序运行场地由谁提供 | 51 .c .h .o
-
v19.xx 鸿蒙内核源码分析(位图管理篇) | 谁能一分钱分两半花 | 51 .c .h .o
-
v18.xx 鸿蒙内核源码分析(源码结构篇) | 内核每个文件的含义 | 51 .c .h .o
-
v17.xx 鸿蒙内核源码分析(物理内存篇) | 怎么管理物理内存 | 51 .c .h .o
-
v16.xx 鸿蒙内核源码分析(内存规则篇) | 内存管理到底在管什么 | 51 .c .h .o
-
v15.xx 鸿蒙内核源码分析(内存映射篇) | 虚拟内存虚在哪里 | 51 .c .h .o
-
v14.xx 鸿蒙内核源码分析(内存汇编篇) | 谁是虚拟内存实现的基础 | 51 .c .h .o
-
v13.xx 鸿蒙内核源码分析(源码注释篇) | 鸿蒙必定成功,也必然成功 | 51 .c .h .o
-
v12.xx 鸿蒙内核源码分析(内存管理篇) | 虚拟内存全景图是怎样的 | 51 .c .h .o
-
v11.xx 鸿蒙内核源码分析(内存分配篇) | 内存有哪些分配方式 | 51 .c .h .o
-
v10.xx 鸿蒙内核源码分析(内存主奴篇) | 皇上和奴才如何相处 | 51 .c .h .o
-
v09.xx 鸿蒙内核源码分析(调度故事篇) | 用故事说内核调度过程 | 51 .c .h .o
-
v08.xx 鸿蒙内核源码分析(总目录) | 百万汉字注解 百篇博客分析 | 51 .c .h .o
-
v07.xx 鸿蒙内核源码分析(调度机制篇) | 任务是如何被调度执行的 | 51 .c .h .o
-
v06.xx 鸿蒙内核源码分析(调度队列篇) | 内核有多少个调度队列 | 51 .c .h .o
-
v05.xx 鸿蒙内核源码分析(任务管理篇) | 任务池是如何管理的 | 51 .c .h .o
-
v04.xx 鸿蒙内核源码分析(任务调度篇) | 任务是内核调度的单元 | 51 .c .h .o
-
v03.xx 鸿蒙内核源码分析(时钟任务篇) | 触发调度谁的贡献最大 | 51 .c .h .o
-
v02.xx 鸿蒙内核源码分析(进程管理篇) | 谁在管理内核资源 | 51 .c .h .o
-
v01.xx 鸿蒙内核源码分析(双向链表篇) | 谁是内核最重要结构体 | 51 .c .h .o
关于 51 .c .h .o
看系列篇文章会常看到 51 .c .h .o
,希望这对大家阅读不会造成影响. 分别对应以下四个站点的首个字符,感谢这些站点一直以来对系列篇的支持和推荐,尤其是 oschina gitee ,很喜欢它的界面风格,简洁大方,让人感觉到开源的伟大!
- 51cto
- csdn
- harmony
- oschina
而巧合的是.c .h .o
是C语言的头/源/目标文件,这就很有意思了,冥冥之中似有天数,将这四个宝贝以这种方式融合在一起. 51 .c .h .o
, 我要CHO ,嗯嗯,hin 顺口 : )
百万汉字注解.百篇博客分析
百万汉字注解 >> 精读鸿蒙源码,中文注解分析, 深挖地基工程,大脑永久记忆,四大码仓每日同步更新< gitee | github | csdn | coding >
百篇博客分析 >> 故事说内核,问答式导读,生活式比喻,表格化说明,图形化展示,主流站点定期更新中< 51cto | csdn | harmony | osc >
关注不迷路.代码即人生
热爱是所有的理由和答案 - turing
原创不易,欢迎转载,但麻烦请注明出处.
https://www.361zimeiti.cn/402647.html |
https://www.361zimeiti.cn/402649.html |
标签:ability,..,aafwk,HarmonyOS,源码,鸿蒙,v61.01,lite 来源: https://www.cnblogs.com/0591jb/p/15058784.html