自己编译的内核为什么启动很慢

自己编译的内核为什么启动很慢,第1张

一般来说,自己编译的内核启动很慢,原因有以下几点:
1 编译内核时未启用内核优化参数:编译内核时应该启用优化选项,以使内核最优化,这样可以提高内核启动速度;
2 编译内核后尚未进行内存优化:在编译内核后,应该进行内存优化,这样可以使内存的占用更少,提高内核启动速度;
3 使用的硬件未进行优化:部分硬件可以进行优化,以提高系统启动速度,如硬盘优化,内存优化等。
4 内核中启用了不必要的模块:应该在编译内核时根据系统所需来选择内核模块,以避免启用不必要的模块导致内核启动缓慢。

react项目中利用dva脚手架,roadhog打包工具打包后只生成了一个indexcss和indexjs。所有的js文件都打包在了一个indexjs文件中,所以这个文件有11M。部署到服务器上,首次访问首页加载的会特别慢,这样会流失很多的用户。

解决办法:gzip压缩。

GZIP编码是一种用来改进WEB应用程序性能的技术。大流量的WEB站点常常使用GZIP压缩技术来让用户感受更快的速度。这一般是指>

gzip可以极大的加速网站有时压缩比率高达80%,近来测试了一下,最少都有40%以上,还是相当不错的在Apache2之后的版本,模块名不叫gzip,而叫mod_deflate。

Nginx开启gzip:

在nginxconf中添加以下配置:

1gzipon;

2gzip_buffers324k;

3gzip_comp_level6;

4gzip_min_length200;

5gzip_typestext/csstext/xmlapplication/javascript;

6gzip_varyon;

重启nginx:

usr/local/nginx/sbin/nginx-sreload

1

清除浏览器缓存,重新访问网页,可以发现首次加载速度快了很多。

希望对你有所帮助!

在2020年,仍然使用2g内存的电脑,你可以改变职业。没有合适的设备,什么都没用。Android Studio是内存,设备烂卡死不可避免,要解决卡的问题,一定要升级硬件设备。另一些人则说,对修辞学的回答相当有力,在一定程度上,加快编译的速度,却不能解决卡死的问题,没有人能解释为什么会加快编译的速度。

至于加快编译,有一种方法,我认为一些主要适用性的答案并不强,实际上应该从gradle开始,什么不是正确的地方,也请轻喷,有什么问题可以留个信息。

我谈到了下面的所有步骤,建议在最后进行。在终端编译中有很多好处:

能观察整个编译过程,帮助理解层次构建过程;

可以看出哪些任务在编译过程中耗费时间,可以较慢地编写出适合的补救方案;

可以终止编译,如果在某个阶段被卡住,CTRL + c终止编译,Android也会终止在Studio中编译,但基本上九次会失败;

因为它最终会对Android Studio产生影响,基本不会导致Android Studio caton;不满足Android工作室的各种bug

让我们从gradle的生命周期开始。Gradle构建了一个被分成三个部分的项目(完成如下图,整个Gradle构建过程可以理解为10到8):

初始化阶段:主要是分析设置。Gradle文件(减少设置。所以有人提到了模块级的数量是合理的,但实际 *** 作过程的限制,因为最终可以粗略的说);

读取配置阶段:主要解析构建下的所有项目。Gradle文件,包括rootProject和其他子项目(组件),检查语法,确定任务依赖于创建任务必须没有循环图,任务文件目录中的引用存在,等等(这一步进一步验证也减少了设置。gradle中模块的数量可以加快编译速度,因为减少了一个模块,需要解析构建。gradle文件将会减少a,在步骤3中不会执行这属于模块的任务,但仍然说1个问题,限制了很多);

执行阶段:根据2所建立的,必须没有循环图来执行每一个任务,编译过程,这一步将会占用超过9个基本时间,特别是对于Android项目,一个Java的类。

CompileDebugJavaWithJavac / compileReleaseJavaWithJavac和类合并成敏捷

TransformClassesWithDexForDebug / transformClassesWithDexForRelease

这两个步骤是耗时的,第一步是可以的,第二步需要很长时间。在gradleproperties第一组。

Gradle。Jvmargs = -xmx4096m //越大越好,然后在构建的android节点下添加dexOptions配置。项目等级如下:

DexOptions {dexInProcess truepredexlibrary真正的javaMaxHeapSize增量true}“4g”//越大越好。

当您定义gradle的生命周期时,您可以看到加速编译的关键是从步骤3开始,并减少设置中模块的数量。让我们谈谈我们公司的做法吧。

项目插件改革,每个业务学生你只需要编译一个模块,这基本上就从根本上解决了编译慢的问题(我的大多数朋友没有插件规范可以看到下面的一些做法),第一个设置。该模块仅在gradle自己的开发模块中,而任务的对应阶段只是这个任务的一个模块。

执行gradle构建,我们会发现,在这个过程中,实际上是执行的任务多次包装,在buildTypes配置了多个编译包类型,默认的调试和发布,我们也可以手动配置其他类型,而且在productFlavor多渠道,编译这将执行多个包装、正常发育过程中,只需要把调试调试,所以使用gradle assembleDebug可以,等待释放使用其他方法来玩多渠道包(如美丽的计划,>

因为编译器是主要集中在第三步的时间gradle生命周期执行任务,然后我们可以给残疾人一些不重要的任务,如各种各样的测试,各种线头等等,只有这样的指令gradle - x线头可以暂时禁止线头,禁止- x测试可以测试任务,事实上,对于一个略大的项目线头也是很耗费时间的,,当然,也可以通过gradle脚本完全禁用线头和测试任务,我也分享代码在一个小信集团,但不建议这样做,因为有时可能非常有用的棉絮和测试;

Gradle本身可以加快编译的速度,提供一些指令参数,例如,守护进程,打开一个守护进程,——并行的、打开的并行编译等等,这也可以在Gradle中完成。propertites配置(使用JVM内存进行编译也可以在这里配置)。

定制级编译过程,使用官方API可以完全定制一个合适的编译过程,可以参考ctrip DynamicAPK/sub - project - build。在master CtripMobile/DynamicAPK lot中,有ctrip本身是一个完整的编译过程,脚本本身非常简单,总共只有两行代码。

如上所述,现有的环境可以通过这种方式进行(如果项目中存在交叉依赖,则使用一个特殊的注释,不要使用并行参数):

如果要直接安装在设备上,则可以用installDebug替换安装调试,并且可以缩写为asD,安装调试可以缩写为iD

最后,为什么要减少设置中模块的数量。Gradle实际上可以加速编译,但是有很多限制

首先,我们认为编译过程,首先解析gradle配置,设置任务依赖于有向图,然后执行每个任务的模块,如果我们通过maven的依赖关系,使用模块的aar(单android库),如果我们想要改变文件在这个模块,不要再次修改上传下载,每次都是很好,但是有一个致命的问题:不修改版本号,快照通常不是做的想法。这可能导致一些不会生效的变化,并且需要时间来解决这个问题。但是,有一种方法可以在一定程度上解决这个问题,并添加以下脚本:

项目。配置。所有(新 *** 作<配置> ({@ Overridevoidexecute(配置文件){文件)。ResolutionStrategy。TimeUnit CacheDynamicVersionsFor(5。分钟)

文件。ResolutionStrategy。TimeUnit CacheChangingModulesFor(0。秒)} })

有人会问,插件,每个人都要开发一个模块,对于每个模块的维护都要打包到maven,每次我修改,甚至很小的改动,也要做一个上传,就会遇到快照不做同样的问题。嘿,嘿,这个问题,我们公司有一个等级插件,已经解决了,至于解决方案,是公司机密,我不会说。

一件事,我相信大多数开发人员共同发展是单一模块,该模块的情况并不多,所以最基本的也是依赖aar或罐子里,并不存在所谓的图书馆aar上传,所以一些答案的耶和华说并不意味着什么,这就是为什么我说影响编译速度的情况主要集中在它的生命周期的第三阶段,第三阶段的优化,看到我的答案。

一般来说编译慢是你所用的设备性能决定的。

解决方法:

最好的办法就是更换硬件,即换台性能好一点的电脑。

调整心态,泡壶茶,听首歌,耐心等待编译完成。

warning: #550-D: variable "d" was set but never used
描述变量'd'定义但从未使用或者是虽然这个变量你使用了但编译器认为变量d所在的语句没有意义编译器把它优化了解决仔细衡量所定义的变量d是否有用
若是认定变量d所在语句有意义那么尝试用volatile关键字修饰变量d,若是真的没有用那么删除掉以释放可能的内存

warning: #1-D: last line of file ends without a newline
描述:
文件最后一行不是新的一行
编译器要求程序文件的最后一行必须是空行想了半天没想通为什么要这样解决可以不理会若是觉得出现警告不爽那么在出现警告的文件的最后一行敲个回车空出一行

warning: #111-D: statement is unreachable
描述:


声明不可能到达多出现在这种场合


int main(void)
{

while(1) //
无限循环
,
这在不使用 *** 作系统的程序中最常见


欢迎分享,转载请注明来源:内存溢出

原文地址: https://outofmemory.cn/yw/13353040.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-07-20
下一篇 2023-07-20

发表评论

登录后才能评论

评论列表(0条)

保存