linux系统内存不够怎么办
在嵌入式系统中，内存是比较紧缺的资源，特别是在消费类产品中， 为了节省成本，一般都会将硬件资源应用到极致。在开发过程中，就经常会遇到，运行内存(ram)就还差一点，但就是不够用的情况，比如：
需要在原系统上添加一个小算法
ota只能将固件放到内存上时
需要动态分配比较大的空间
需要放置一些比较大的临时文件
如果你原来设备内存已经使用到90%甚至更高，要实现上面功能，大概率会影响系统的整体性能，甚至会出现系统异常。那该怎么办？
在不考虑硬件增加ram大小的情况下，软件上还有没有其它的方式，可以挤出一点点空间呢？答案是可以的，但是需要综合评估带来的问题和风险。
下面以君正t31zc为实例，来介绍一下它的内存使用情况，以及如何挤出更加多的内存空间。
一、内存使用情况分析
t31zc 是一款基于mips架构的主处理器，上面集成了512mbit的ddr2内存，使用的是linux操作系统。
1、物理内存分布
512mbit的物理内存，也就是64mbyte,在实际使用的时候，它被划分为了两块，rmem 和 mem
rmem 用于多媒体，比如音视频编码、裁剪、osd等功能
mem 是用于linux系统内存
它通过tag部分的cmdline来设置：
[root@zeratul:~]# cat /proc/cmdline console=ttys0,115200n8 mem=40m@0x0 rmem=24m@0x2800000 root=/dev/ram0 rw rdinit=/linuxrc mtdparts=jz_sfc:256k(boot),352k(tag),5m(kernel),6m(rootfs),2560k(recovery),1440k(system),512k(config),16m@0(all) lpj=6955008 quiet senv;[hw];init_vw=1920;init_vh=1080;nrvbs=2;mode=0;eenv; lzo_size=5907415 rd_start=0x80600000 rd_size=0xd35c00[root@zeratul:~]# 这里我们看到40m分配给了linux系统，24m分配给了多媒体。
通过 dmesg 命令可以看到更多内存的使用情况：
rd_start=0x80600000 rd_size=0xd35c00
这个是用来存放根文件系统的起始位置，以及这个空间的大小。
memory: 20680k/40960k
40960k 是linux系统可使用的总大小，也就是上面设置的40mb，20680k 是系统实际可以使用的内存。
剩下的 40960k - 20680k = 20280k 内存到哪里去了？
3868k kernel code, 20280k reserved, 1052k data, 196k init, 0k highmem
一部分是给内核使用，包括内核代码段、数据段、以及 init 段
剩下的20280k - 3868k -1052k - 196k = 15164k
这剩下的1516k 是预留给ramfs 使用的。
2、mem使用情况
linux 系统启动后，不运行其它的应用程序，我们查看的内存使用情况如下：
cat /proc/meminfo
可用的实际物理内存大小还剩余12872 kb
分配给linux系统使用的内存有40m，但是应用程序都还没开始运行，内存就只剩下12872k,内存都到哪里去了！
总结归纳如下：
总物理内存64m,24m分配给了多媒体，40m分配给了linux系统
总大小 多媒体内存 linux系统
64m 24m 40m
linux系统内存中，可使用的内存为20680k，预留的内存为20280k
linux系统 available reserved
40960k 20680k 20280k
linux系统中可使用的内存，内核模块加载，缓冲缓存等系统服务占用7768k，剩余的为应用可使用的内存
available memfree modules/others
20680k 12912k 7768k
linux系统中预留的内存，主要是预留给kernel和根文件系统，其中kernel中主要有代码段，数据段，init段。剩下的主要是根文件系统占用的空间。
reserved kernel code kernel data kernel init ramfs others
20280k 3868k 1052k 196k 13527k 1637k
二、优化方向
从上面的分析来看，可以优化的方向有：
减少模块加载，系统服务
kernel 优化
rootfs 优化
1、减少模块加载，系统服务
这个可优化的空间有限，这里不做详细讨论，可以通过命令查看实际模块加载情况：cat /proc/modules
2、kernel 优化
将内核的调试信息去除掉，可以在menuconfig 中取消 load all symbols for debugging/ksymoops 选项，这里可以省出少量的空间。
3、rootfs 优化
从上面的分析，我们看到为ramfs预留的空间为13527k，这是个非常大的空间。从启动cmdline中我们看到flash的分区信息如下:
256k(boot),352k(tag),5m(kernel),6m(rootfs),2560k(recovery),1440k(system),512k(config),16m@0(all)
（1）flash为rootfs预留的空间为6m，而内存为rootfs预留的是13527k，为何相差如此之大？
主要的原因是我们rootfs在烧录到flash的时候是压缩过的，在加载rootfs的时候，首先是将rootfs从flash中读取出来，再解压到内存指定的地址去，然后再将解压后的rootfs挂载成ramfs文件系统加载起来。
rootfs的打包命令如下:
cd ./_rootfs_camerafind . | cpio -h newc -o > ../rootfs_camera.cpiocd ..lzop -9 -f rootfs_camera.cpio -o rootfs_camera.cpio.lzo./mark_rootfs_pc rootfs_camera.cpio.lzo 将_rootfs_camera 目录下的所有文件归档到上一目录的rootfs_camera.cpio文件中
使用lzop 命令使用最高等级(9)的压缩方式把rootfs_camera.cpio 压缩到rootfs_camera.cpio.lzo 文件，-f 表示强制执行，如果rootfs_camera.cpio.lzo已经存在则覆盖它
mark_rootfs_pc 是用来更新rootfs_camera.cpio.lzo的实际文件大小，实际是将压缩后的文件大小写入到rootfs_camera.cpio.lzo的最开始位置(4字节)。
（2）为什么要使用ramfs文件系统？
ramfs 适合用于临时存储、临时文件、内核模块载入等临时性应用，其中数据不需要长期保存的场景，它是linux内核中的虚拟文件系统，不需要指定特定的挂载选项。
优点有：
快速读写操作
零延迟
轻量级
易于创建和销毁
缺点有:
不具备持久性
内存限制
不适合大型文件
需要足够的内存
君正t31zc是属于低功耗soc，实时性，快速启动要求比较高。一般应用场景是有另外的mcu来控制它上下电，有事件触发的时候，soc上电处理事件，事件处理完成后，soc下电，只留mcu工作，以达到省功耗的目的，所以使用ramfs 也是合理的选择。
官方手册上的建议是这样的：
rootfs中只存放对快起有要求的必要程序和库文件，如果对快起没有要求的程序或库文件建议放到 system 分区,以达到快速启动和节省内存的目的。
三、另类解决方案
1、问题分析
根据上面的分析，如果系统使用的是ramfs,优化空间最大的就是根文件系统，减小根文件系统的大小可以直接节省内存。
上面官方给的建议中需要面对另外一个问题，就是需要在应用程序启动之后，再去system分区使用dl_open加载所需要的动态库。如果你程序主要使用的是静态库，那这种方式就达不到想要的效果。
查看rootfs 文件系统里面的内容，占用空间大的，一个是stone目录，另外一个是lib目录。
./stone 目录下放置的是需要运行的main程序
./lib 目录下放置的主要是一些动态库，ko驱动文件，以及一个wifi使用的 bin 文件
-rwxrwxr-x 1 biao biao 6.2m oct 15 18:14 main-rwxrwxrwx 1 biao biao 1003k aug 21 10:04 cywdhd.ko-rwxrwxrwx 1 biao biao 404k aug 21 10:04 fw_bcm43438a1.bin 2、解决方案
main 执行程序在启动的时候就执行
./etc/init.d/rcs:/stone/main &
wifi 驱动也是在启动的时候被加载
insmod /lib/modules/cywdhd.ko firmware_path=/lib/firmware/fw_bcm43438a1.bin nvram_path=/lib/firmware/nvram.txt iface_name=wlan0
是否可以这样：
在启动的时候，main 执行文件，cywdhd.ko驱动,驱动固件fw_bcm43438a1.bin被加载完之后，就把它们删除，以达到释放内存的目的？
因为这些文件都是放置在内存上，删除它们并不会影响flash中的文件，下次上电可以重新从flash中读取出来，删除它们也确实是可以释放一部分内存。
以我上面的例子，删除 main 文件就可以释放6.2m的空间，确实也是可以达到释放内存的目的。
但是，这样操作是否有风险？
四、删除elf文件是否有影响
我们知道，程序运行是被段页式加载到内存的，那要怎么知道在删除main程序执行文件的时候，main程序里面的内容已经被全部加载到内存中去了呢？
同样，删除ko文件和bin固件数据文件的时候同样会遇到相同的疑问。
1、删除 cywdhd.ko 驱动
通过 cat /proc/modules 命令可以查看模块的加载情况
[root@zeratul:bin]# cat /proc/modules | grep cywdhdcywdhd 671712 0 - live 0xc0215000jzmmc 17113 1 cywdhd, live 0xc010f000mmc_core 90139 3 mmc_block,cywdhd,jzmmc, live 0xc00e5000 我们看到 cywdhd.ko被加载到内存的0xc0215000 这个地址，live 表示已经加载到内核并且在在运行。671712 表示它的大小。
为什么我们前面看cywdhd.ko 大小是1003k ，加载到内核中去却只剩下67171 ？
我们使用 file 命令查看cywdhd.ko文件信息，发现它是elf文件格式，并且是not stripped，也就是它里面还包含一些调试信息和调试符号表等内容
biao@ubuntu: file cywdhd.ko cywdhd.ko: elf 32-bit lsb relocatable, mips, mips32 version 1 (sysv), buildid[sha1]=a00e1928dd77ac04bb813b22cd485156f3392741, not stripped strip 处理之后，文件大小变成了657788
biao@ubuntu: mips-linux-uclibc-gnu-strip cywdhd.ko biao@ubuntu:ll-rwxrwxrwx 1 biao biao 657788 oct 15 19:42 cywdhd.ko 综合上面信息，我们可以大致判断删除cywdhd.ko文件是没有风险的。
还有一种确认方式是：通过查看 /proc/kallsyms 文件信息
/proc/kallsyms 包含了内核符号表信息，其中包括已加载模块的地址范围。如果模块的地址范围包括整个模块，那么它通常已经完全加载到内存中。
2、删除fw_bcm43438a1.bin固件
fw_bcm43438a1.bin 是作为cywdhd.ko 驱动的一个固件被加载到内核上的，至于它是什么时候使用，或者说是否一次全部加载到内存上了，应该取决于cywdhd.ko驱动
因此我个人认为删除fw_bcm43438a1.bin是会有比较大的风险的
3、删除main程序
在linux系统中， 执行文件，动态库，驱动文件都是属于elf文件格式。elf文件里面分很多段，常见的有代码段，数据段,bss 段。
可以使用命令 readelf -s your_program 来具体查看：
我们看到代码段的大小是0x46a6b0，在很多操作系统中，为了节省内存空间，都是使用动态加载的方式,也就是段页式加载方式。
根据局部性原理，一般程序在执行的时候，都是将当前执行位置附近的数据加载到内存上运行。
但是对于ramfs文件系统，因为它已经是被全部加载到内存上了，那在它上面的main文件，在执行的时候，它是一次性加载(全局加载)还是按需加载(段页式加载)呢？
如果它是在运行的时候一次性加载到内存上，那么，在它运行之后，把main文件删除是没有风险的，否则会引入系统风险。
对于执行文件在ramfs文件系统上的加载，暂时没有找到更详细的介绍资料，熟悉这一领域的同学可以给点建议。
五、手动释放内存
可以使用命令手动释放内存：
echo 1 > /proc/sys/vm/drop_caches
关于drop_caches 的介绍，可以通过 man proc 的介绍来了解，这里不做过多说明
六、总结
综合上面介绍的内容，在嵌入式linux系统内存不足的情况下，可以使用下面几种方式进行优化：
将kernel的调试信息符号表去除，减少内核镜像文件大小
将文件系统上的elf文件(包括执行文件、动态库和ko驱动文件)strip处理，去除多余的信息
将动态库放置到其它分区上，程序运行后再通过dl_open来加载
执行文件或是驱动文件，在使用过后把它们删除(可能存在风险)
手动释放内存
具体使用哪种方式，可以根据实际使用情况进行评估和选择。
瑞丰目前针对LED硫化推出创新解决方案
荣耀获得2021京东618十佳全渠道合作伙伴 携手共建全场景智慧生活
太阳能手机充电器的原理和安装调试
未来谁将抢占AI竞争高地?
马自达的最新超跑明年上市，这样的外观就不输给兰博基尼！您觉得怎么样？
linux系统内存不够怎么办
哪个骨传导蓝牙耳机的好？骨传导蓝牙耳机推荐
谷歌DeepMind发现更快排序算法，已集成到C++库
Microchip新系统BodyCom：让身体成为安全认证过程
当前制造企业为什么急需要进行智能化升级
如何动态可视化地分析数据变化和原因
设备验收不达标起诉韩设备厂商SNTEK，仲裁申请金额达7000万元
PCA-6003V-00A1 模块
PCB设计中信号完整性分析的作用
未来5G移动互联网应用普及化，显示产业的5G春天到了
惊呆了！智能手机连接无人机可以准点送货
ARM公司联合创始人：中国将取代美国主导芯片市场
HDGX地下金属管线测试仪运行电缆的信号发射方法
适合圣诞送礼的蓝牙耳机，选择这几款高性价比蓝牙耳机绝不出错
2017年OLED这口“火山”能爆发吗？
需要在原系统上添加一个小算法
ota只能将固件放到内存上时
需要动态分配比较大的空间
需要放置一些比较大的临时文件
如果你原来设备内存已经使用到90%甚至更高，要实现上面功能，大概率会影响系统的整体性能，甚至会出现系统异常。那该怎么办？
在不考虑硬件增加ram大小的情况下，软件上还有没有其它的方式，可以挤出一点点空间呢？答案是可以的，但是需要综合评估带来的问题和风险。
下面以君正t31zc为实例，来介绍一下它的内存使用情况，以及如何挤出更加多的内存空间。
一、内存使用情况分析
t31zc 是一款基于mips架构的主处理器，上面集成了512mbit的ddr2内存，使用的是linux操作系统。
1、物理内存分布
512mbit的物理内存，也就是64mbyte,在实际使用的时候，它被划分为了两块，rmem 和 mem
rmem 用于多媒体，比如音视频编码、裁剪、osd等功能
mem 是用于linux系统内存
它通过tag部分的cmdline来设置：
[root@zeratul:~]# cat /proc/cmdline console=ttys0,115200n8 mem=40m@0x0 rmem=24m@0x2800000 root=/dev/ram0 rw rdinit=/linuxrc mtdparts=jz_sfc:256k(boot),352k(tag),5m(kernel),6m(rootfs),2560k(recovery),1440k(system),512k(config),16m@0(all) lpj=6955008 quiet senv;[hw];init_vw=1920;init_vh=1080;nrvbs=2;mode=0;eenv; lzo_size=5907415 rd_start=0x80600000 rd_size=0xd35c00[root@zeratul:~]# 这里我们看到40m分配给了linux系统，24m分配给了多媒体。
通过 dmesg 命令可以看到更多内存的使用情况：
rd_start=0x80600000 rd_size=0xd35c00
这个是用来存放根文件系统的起始位置，以及这个空间的大小。
memory: 20680k/40960k
40960k 是linux系统可使用的总大小，也就是上面设置的40mb，20680k 是系统实际可以使用的内存。
剩下的 40960k - 20680k = 20280k 内存到哪里去了？
3868k kernel code, 20280k reserved, 1052k data, 196k init, 0k highmem
一部分是给内核使用，包括内核代码段、数据段、以及 init 段
剩下的20280k - 3868k -1052k - 196k = 15164k
这剩下的1516k 是预留给ramfs 使用的。
2、mem使用情况
linux 系统启动后，不运行其它的应用程序，我们查看的内存使用情况如下：
cat /proc/meminfo
可用的实际物理内存大小还剩余12872 kb
分配给linux系统使用的内存有40m，但是应用程序都还没开始运行，内存就只剩下12872k,内存都到哪里去了！
总结归纳如下：
总物理内存64m,24m分配给了多媒体，40m分配给了linux系统
总大小 多媒体内存 linux系统
64m 24m 40m
linux系统内存中，可使用的内存为20680k，预留的内存为20280k
linux系统 available reserved
40960k 20680k 20280k
linux系统中可使用的内存，内核模块加载，缓冲缓存等系统服务占用7768k，剩余的为应用可使用的内存
available memfree modules/others
20680k 12912k 7768k
linux系统中预留的内存，主要是预留给kernel和根文件系统，其中kernel中主要有代码段，数据段，init段。剩下的主要是根文件系统占用的空间。
reserved kernel code kernel data kernel init ramfs others
20280k 3868k 1052k 196k 13527k 1637k
二、优化方向
从上面的分析来看，可以优化的方向有：
减少模块加载，系统服务
kernel 优化
rootfs 优化
1、减少模块加载，系统服务
这个可优化的空间有限，这里不做详细讨论，可以通过命令查看实际模块加载情况：cat /proc/modules
2、kernel 优化
将内核的调试信息去除掉，可以在menuconfig 中取消 load all symbols for debugging/ksymoops 选项，这里可以省出少量的空间。
3、rootfs 优化
从上面的分析，我们看到为ramfs预留的空间为13527k，这是个非常大的空间。从启动cmdline中我们看到flash的分区信息如下:
256k(boot),352k(tag),5m(kernel),6m(rootfs),2560k(recovery),1440k(system),512k(config),16m@0(all)
（1）flash为rootfs预留的空间为6m，而内存为rootfs预留的是13527k，为何相差如此之大？
主要的原因是我们rootfs在烧录到flash的时候是压缩过的，在加载rootfs的时候，首先是将rootfs从flash中读取出来，再解压到内存指定的地址去，然后再将解压后的rootfs挂载成ramfs文件系统加载起来。
rootfs的打包命令如下:
cd ./_rootfs_camerafind . | cpio -h newc -o > ../rootfs_camera.cpiocd ..lzop -9 -f rootfs_camera.cpio -o rootfs_camera.cpio.lzo./mark_rootfs_pc rootfs_camera.cpio.lzo 将_rootfs_camera 目录下的所有文件归档到上一目录的rootfs_camera.cpio文件中
使用lzop 命令使用最高等级(9)的压缩方式把rootfs_camera.cpio 压缩到rootfs_camera.cpio.lzo 文件，-f 表示强制执行，如果rootfs_camera.cpio.lzo已经存在则覆盖它
mark_rootfs_pc 是用来更新rootfs_camera.cpio.lzo的实际文件大小，实际是将压缩后的文件大小写入到rootfs_camera.cpio.lzo的最开始位置(4字节)。
（2）为什么要使用ramfs文件系统？
ramfs 适合用于临时存储、临时文件、内核模块载入等临时性应用，其中数据不需要长期保存的场景，它是linux内核中的虚拟文件系统，不需要指定特定的挂载选项。
优点有：
快速读写操作
零延迟
轻量级
易于创建和销毁
缺点有:
不具备持久性
内存限制
不适合大型文件
需要足够的内存
君正t31zc是属于低功耗soc，实时性，快速启动要求比较高。一般应用场景是有另外的mcu来控制它上下电，有事件触发的时候，soc上电处理事件，事件处理完成后，soc下电，只留mcu工作，以达到省功耗的目的，所以使用ramfs 也是合理的选择。
官方手册上的建议是这样的：
rootfs中只存放对快起有要求的必要程序和库文件，如果对快起没有要求的程序或库文件建议放到 system 分区,以达到快速启动和节省内存的目的。
三、另类解决方案
1、问题分析
根据上面的分析，如果系统使用的是ramfs,优化空间最大的就是根文件系统，减小根文件系统的大小可以直接节省内存。
上面官方给的建议中需要面对另外一个问题，就是需要在应用程序启动之后，再去system分区使用dl_open加载所需要的动态库。如果你程序主要使用的是静态库，那这种方式就达不到想要的效果。
查看rootfs 文件系统里面的内容，占用空间大的，一个是stone目录，另外一个是lib目录。
./stone 目录下放置的是需要运行的main程序
./lib 目录下放置的主要是一些动态库，ko驱动文件，以及一个wifi使用的 bin 文件
-rwxrwxr-x 1 biao biao 6.2m oct 15 18:14 main-rwxrwxrwx 1 biao biao 1003k aug 21 10:04 cywdhd.ko-rwxrwxrwx 1 biao biao 404k aug 21 10:04 fw_bcm43438a1.bin 2、解决方案
main 执行程序在启动的时候就执行
./etc/init.d/rcs:/stone/main &
wifi 驱动也是在启动的时候被加载
insmod /lib/modules/cywdhd.ko firmware_path=/lib/firmware/fw_bcm43438a1.bin nvram_path=/lib/firmware/nvram.txt iface_name=wlan0
是否可以这样：
在启动的时候，main 执行文件，cywdhd.ko驱动,驱动固件fw_bcm43438a1.bin被加载完之后，就把它们删除，以达到释放内存的目的？
因为这些文件都是放置在内存上，删除它们并不会影响flash中的文件，下次上电可以重新从flash中读取出来，删除它们也确实是可以释放一部分内存。
以我上面的例子，删除 main 文件就可以释放6.2m的空间，确实也是可以达到释放内存的目的。
但是，这样操作是否有风险？
四、删除elf文件是否有影响
我们知道，程序运行是被段页式加载到内存的，那要怎么知道在删除main程序执行文件的时候，main程序里面的内容已经被全部加载到内存中去了呢？
同样，删除ko文件和bin固件数据文件的时候同样会遇到相同的疑问。
1、删除 cywdhd.ko 驱动
通过 cat /proc/modules 命令可以查看模块的加载情况
[root@zeratul:bin]# cat /proc/modules | grep cywdhdcywdhd 671712 0 - live 0xc0215000jzmmc 17113 1 cywdhd, live 0xc010f000mmc_core 90139 3 mmc_block,cywdhd,jzmmc, live 0xc00e5000 我们看到 cywdhd.ko被加载到内存的0xc0215000 这个地址，live 表示已经加载到内核并且在在运行。671712 表示它的大小。
为什么我们前面看cywdhd.ko 大小是1003k ，加载到内核中去却只剩下67171 ？
我们使用 file 命令查看cywdhd.ko文件信息，发现它是elf文件格式，并且是not stripped，也就是它里面还包含一些调试信息和调试符号表等内容
biao@ubuntu: file cywdhd.ko cywdhd.ko: elf 32-bit lsb relocatable, mips, mips32 version 1 (sysv), buildid[sha1]=a00e1928dd77ac04bb813b22cd485156f3392741, not stripped strip 处理之后，文件大小变成了657788
biao@ubuntu: mips-linux-uclibc-gnu-strip cywdhd.ko biao@ubuntu:ll-rwxrwxrwx 1 biao biao 657788 oct 15 19:42 cywdhd.ko 综合上面信息，我们可以大致判断删除cywdhd.ko文件是没有风险的。
还有一种确认方式是：通过查看 /proc/kallsyms 文件信息
/proc/kallsyms 包含了内核符号表信息，其中包括已加载模块的地址范围。如果模块的地址范围包括整个模块，那么它通常已经完全加载到内存中。
2、删除fw_bcm43438a1.bin固件
fw_bcm43438a1.bin 是作为cywdhd.ko 驱动的一个固件被加载到内核上的，至于它是什么时候使用，或者说是否一次全部加载到内存上了，应该取决于cywdhd.ko驱动
因此我个人认为删除fw_bcm43438a1.bin是会有比较大的风险的
3、删除main程序
在linux系统中， 执行文件，动态库，驱动文件都是属于elf文件格式。elf文件里面分很多段，常见的有代码段，数据段,bss 段。
可以使用命令 readelf -s your_program 来具体查看：
我们看到代码段的大小是0x46a6b0，在很多操作系统中，为了节省内存空间，都是使用动态加载的方式,也就是段页式加载方式。
根据局部性原理，一般程序在执行的时候，都是将当前执行位置附近的数据加载到内存上运行。
但是对于ramfs文件系统，因为它已经是被全部加载到内存上了，那在它上面的main文件，在执行的时候，它是一次性加载(全局加载)还是按需加载(段页式加载)呢？
如果它是在运行的时候一次性加载到内存上，那么，在它运行之后，把main文件删除是没有风险的，否则会引入系统风险。
对于执行文件在ramfs文件系统上的加载，暂时没有找到更详细的介绍资料，熟悉这一领域的同学可以给点建议。
五、手动释放内存
可以使用命令手动释放内存：
echo 1 > /proc/sys/vm/drop_caches
关于drop_caches 的介绍，可以通过 man proc 的介绍来了解，这里不做过多说明
六、总结
综合上面介绍的内容，在嵌入式linux系统内存不足的情况下，可以使用下面几种方式进行优化：
将kernel的调试信息符号表去除，减少内核镜像文件大小
将文件系统上的elf文件(包括执行文件、动态库和ko驱动文件)strip处理，去除多余的信息
将动态库放置到其它分区上，程序运行后再通过dl_open来加载
执行文件或是驱动文件，在使用过后把它们删除(可能存在风险)
手动释放内存
具体使用哪种方式，可以根据实际使用情况进行评估和选择。
瑞丰目前针对LED硫化推出创新解决方案
荣耀获得2021京东618十佳全渠道合作伙伴 携手共建全场景智慧生活
太阳能手机充电器的原理和安装调试
未来谁将抢占AI竞争高地?
马自达的最新超跑明年上市，这样的外观就不输给兰博基尼！您觉得怎么样？
linux系统内存不够怎么办
哪个骨传导蓝牙耳机的好？骨传导蓝牙耳机推荐
谷歌DeepMind发现更快排序算法，已集成到C++库
Microchip新系统BodyCom：让身体成为安全认证过程
当前制造企业为什么急需要进行智能化升级
如何动态可视化地分析数据变化和原因
设备验收不达标起诉韩设备厂商SNTEK，仲裁申请金额达7000万元
PCA-6003V-00A1 模块
PCB设计中信号完整性分析的作用
未来5G移动互联网应用普及化，显示产业的5G春天到了
惊呆了！智能手机连接无人机可以准点送货
ARM公司联合创始人：中国将取代美国主导芯片市场
HDGX地下金属管线测试仪运行电缆的信号发射方法
适合圣诞送礼的蓝牙耳机，选择这几款高性价比蓝牙耳机绝不出错
2017年OLED这口“火山”能爆发吗？