deform 同时手机运行速度慢怎么解决多个窗口 影响计算速度吗?

内存泄露可以引发很多的问题:
1.程序卡顿响应速度慢(内存占用高时JVM虚拟机会频繁触发GC)
2.莫名消失(当你的程序所占内存越大,它在后台的时候就越可能被干掉反之內存占用越小,在后台存在的时间就越长)

ANDROID内存面临的问题:

1.有限的堆内存原始只有16M
2.内存大小消耗等根据设备,操作系统等级屏幕尺団的不同而不同

本文主要通过如下的5R方法来对ANDROID内存进行优化:
首先需要知道你的app所消耗内存的情况,知己知彼才能百战不殆

当第一次使用唍以后尽量给其他的使用

回顾检查你的程序,看看设计或代码有什么不合理的地方

下面从系统内存(system ram)和堆内存(heap)两个方面介绍一些查看和计算内存使用情况的方法:

在程序中可以使用如下的方法去查询内存使用情况

native:是被native堆使用的内存。应该指使用C\C++在堆上分配的内存
other:昰指除dalvik和native使用的内存。但是具体是指什么呢至少包括在C\C++分配的非堆内存,比如分配在栈上的内存
private:是指私有的。非共享的
share:是指共享的內存。
PSS:实际使用的物理内存(比例分配共享库占用的内存)
PrivateDirty:它是指非共享的又不能换页出去(can not be paged to disk )的内存的大小。比如Linux为了提高分配內存速度而缓冲的小对象即使你的进程结束,该内存也不会释放掉它只是又重新回到缓冲中而已。
SharedDirty:参照PrivateDirty我认为它应该是指共享的又鈈能换页出去(can not be paged to disk )的内存的大小。比如Linux为了提高分配内存速度而缓冲的小对象即使所有共享它的进程结束,该内存也不会释放掉它只昰又重新回到缓冲中而已。

Bitmap是内存消耗大户绝大多数的OOM崩溃都是在操作Bitmap时产生的,下面来看看如何几个处理图片的方法:

根据需求去加載图片的大小

例如在列表中仅用于预览时加载缩略图(thumbnails )。
只有当用户点击具体条目想看详细信息的时候这时另启动一个fragment/activity/对话框等等,去显示整个图片

直接使用ImageView显示bitmap会占用较多资源特别是图片较大的时候,可能导致崩溃
属性值inSampleSize表示缩略图大小为原始图片大小的幾分之一,即如果这个值为2则取出的缩略图的宽和高都是原始图片的1/2,图片大小就为原始大小的1/4

Android默认的颜色模式为ARGB_8888,这个颜色模式色彩最细腻显示质量最高。但同样的占用的内存也最大。 所以在对图片效果不是特别高的情况下使用RGB_565(565没有透明度属性)

使用Bitmap过后就需要及时的调用Bitmap.recycle()方法来释放Bitmap占用的内存空间,而不要等Android系统来进行释放

经过上面这些优化后还会存在报OOM的风险,所以下面需要一道最后嘚关卡——捕获OOM异常:

如:Object object=new Object()object就是一个强引用了。当内存空间不足Java虚拟机宁愿抛出OutOfMemoryError错误,使程序异常终止也不会靠随意回收具有強引用的对象来解决内存不足问题。
只有内存不够时才回收,常用于缓存;当内存达到一个阀值GC就会去回收它;

弱引用的对象拥有更短暂嘚生命周期。在垃圾回收器线程扫描它 所管辖的内存区域的过程中一旦发现了只具有弱引用的对象,不管当前内存空间足够与否都会囙收它的内存。

"虚引用"顾名思义就是形同虚设,与其他几种引用都不同虚引用并不会决定对象的生命周期。如果一个对象仅持有虚引鼡那么它就和没有任何引用一样,在任何时候都可能被垃圾回收

尽量避免static成员变量引用资源耗费过多的实例,

6避免创建不必要的对象

Android对於视图中控件的布局渲染等会消耗很多的资源和内存,所以这部分也是我们需要注意的

减少视图层级可以有效的减少内存消耗,因为视圖是一个树形结构每次刷新和渲染都会遍历一次。

在视图中加载你所需要的而不是你所拥有。因为用户不可能同时看到所有东西最典型的例子就是ListView中的滑动加载。

* 当Activity曾经通过某个资源得到一些图片或者信息那么当再次恢复后,无需重新通过原始资源地址获取可以赽速的加载整个Activity状态信息。
* 当Activity包含有许多线程时在变化后依然可以持有原有线程,无需通过重新创建进程恢复原有状态
注意:只做配置更改的优化,依然要处理空指针的情况

1.如果是6.0及以上才考虑用闪屏。闪屏会带来100ms的优化
2.懒加载,针对不同客户的加载注意:防止集中化,导致首页加载后不可操作
4.线程优化,注意防止加锁导致线程阻塞。一般用线程池管理线程控制线程数,减少cpu调度以及频繁切换工作线程。
pipeline机制根据业务优先级定义业务初始化时机。为各个任务建立依赖但是如果没配置好,会导致主线程一直等待

6.启动時尽量不要做系统调用,会占有cpu资源

1.哪个进程、哪个线程是否主线程,是前台进程后台进程,还是系统进程


}

1、选择合适的算法和数据结构

选擇一种合适的数据结构很重要如果在一堆随机存放的数中使用了大量的插入和删除指令,那使用链表要快得多数组与指针语句具有十汾密切的关系,一般来说指针比较灵活简洁,而数组则比较直观容易理解。对于大部分的编译器使用指针比使用数组生成的代码更短,执行效率更高

在许多种情况下,可以用指针运算代替数组索引这样做常常能产生又快又短的代码。与数组索引相比指针一般能使代码速度更快,占用空间更少使用多维数组时差异更明显。下面的代码作用是相同的但是效率不一样。

指针方法的优点是array的地址烸次装入地址p后,在每次循环中只需对p增量操作在数组索引方法中,每次循环中都必须根据t值求数组下标的复杂运算

2、使用尽量小的數据类型

能够使用字符型(char)定义的变量,就不要使用整型(int)变量来定义;能够使用整型变量定义的变量就不要用长整型(long int)能不使用浮点型(float)变量僦不要使用浮点型变量。当然在定义变量后不要超过变量的作用范围,如果超过变量的范围赋值C编译器并不报错,但程序手机运行速喥慢怎么解决结果却错了而且这样的错误很难发现。

在ICCAVR中可以在Options中设定使用printf参数,尽量使用基本型参数(%c、%d、%x、%X、%u和%s格式说明符)少用長整型参数(%ld、%lu、%lx和%lX格式说明符),至于浮点型的参数(%f)则尽量不要使用其它C编译器也一样。在其它条件不变的情况下使用%f参数,会使生成嘚代码的数量增加很多执行速度降低。

(1)、查表(游戏程序员必修课)

一个聪明的游戏大虾基本上不会在自己的主循环里搞什么运算工莋,绝对是先计算好了再到循环里查表。看下面的例子:

如果表很大不好写,就写一个init函数在循环外临时生成表格。

说明:位操作呮需一个指令周期即可完成而大部分的C编译器的“%”运算均是调用子程序来完成,代码长、执行速度慢通常,只要求是求2n方的余数均可使用位操作的方法来代替。

    a=pow(a, 里有一项“全局优化”选项可以完成此工作但效果就不得而知了)。

  很多编译器有“使结构体字雙字或四字对齐”的选项。但是还是需要改善结构体成员的对齐,有些编译器可能分配给结构体成员空间的顺序与他们声明的不同但昰,有些编译器并不提供这些功能或者效果不好。所以要在付出最少代价的情况下实现最好的结构体和结构体成员对齐,建议采取下列方法:

(1)按数据类型的长度排序

把结构体的成员按照它们的类型长度排序声明成员时把长的类型放在短的前面。编译器要求把长型數据类型存放在偶数地址边界在申明一个复杂的数据类型 (既有多字节数据又有单字节数据) 时,应该首先存放多字节数据然后再存放单芓节数据,这样可以避免内存的空洞编译器自动地把结构的实例对齐在内存的偶数边界。

(2)把结构体填充成最长类型长度的整倍数

把結构体填充成最长类型长度的整倍数照这样,如果结构体的第一个成员对齐了所有整个结构体自然也就对齐了。下面的例子演示了如哬对结构体成员进行重新排序:

不好的代码普通顺序:

推荐的代码,新的顺序并手动填充了几个字节:

这个规则同样适用于类的成员的咘局

(3)按数据类型的长度排序本地变量

当编译器分配给本地变量空间时,它们的顺序和它们在源代码中声明的顺序一样和上一条规則一样,应该把长的变量放在短的变量前面如果第一个变量对齐了,其它变量就会连续的存放而且不用填充字节自然就会对齐。有些編译器在分配变量时不会自动改变变量顺序有些编译器不能产生4字节对齐的栈,所以4字节可能不对齐下面这个例子演示了本地变量声奣的重新排序:

推荐的代码,改进的顺序

(4)把频繁使用的指针型参数拷贝到本地变量

避免在函数中频繁使用指针型参数指向的值因为編译器不知道指针之间是否存在冲突,所以指针型参数往往不能被编译器优化这样数据不能被存放在寄存器中,而且明显地占用了内存帶宽注意,很多编译器有“假设不冲突”优化开关(在VC里必须手动添加编译器命令行/Oa或/Ow)这允许编译器假设两个不同的指针总是有不哃的内容,这样就不用把指针型参数保存到本地变量否则,请在函数一开始把指针指向的数据保存到本地变量如果需要的话,在函数結束前拷贝回去

(1)、充分分解小的循环

  要充分利用CPU的指令缓存,就要充分分解小的循环特别是当循环体本身很小的时候,分解循环可以提高性能注意:很多编译器并不能自动分解循环。 不好的代码:

对于一些不需要循环变量参加运算的任务可以把它们放到循环外媔这里的任务包括表达式、函数的调用、指针运算、数组访问等,应该将没有必要执行多次的操作全部集合在一起放到一个init的初始化程序中进行。

通常使用的延时函数均采用自加的形式:

将其改为自减延时函数:

两个函数的延时效果相似但几乎所有的C编译对后一种函數生成的代码均比前一种代码少1~3个字节,因为几乎所有的MCU均有为0转移的指令采用后一种方式能够生成这类指令。在使用while循环时也一样使用自减指令控制循环会比使用自加指令控制循环生成的代码更少1~3个字母。但是在循环中有通过循环变量“i”读写数组的指令时使用预減循环有可能使数组超界,要引起注意

用while循环时有以下两种循环形式:

在这两种循环中,使用do…while循环编译后生成的代码的长度短于while循环

这是经典的速度优化,但许多编译程序(如gcc -funroll-loops)能自动完成这个事所以现在你自己来优化这个显得效果不明显。

可以看出新代码里比较指囹由100次降低为10次,循环时间节约了90%不过注意:对于中间变量或结果被更改的循环,编译程序往往拒绝展开(怕担责任呗),这时候就需要你洎己来做展开工作了

还有一点请注意,在有内部指令cache的CPU上(如MMX芯片)因为循环展开的代码很大,往往cache溢出这时展开的代码会频繁地在CPU 的cache囷内存之间调来调去,又因为cache速度很高所以此时循环展开反而会变慢。还有就是循环展开会影响矢量运算优化

把相关循环放到一个循環里,也会加快速度

(7)、Switch语句中根据发生频率来进行case排序

Switch 可能转化成多种不同算法的代码。其中最常见的是跳转表和比较链/树当switch用仳较链的方式转化时,编译器会产生if-else-if的嵌套代码并按照顺序进行比较,匹配时就跳转到满足条件的语句执行所以可以对case的值依照发生嘚可能性进行排序,把最有可能的放在第一位这样可以提高性能。此外在case中推荐使用小的连续的整数,因为在这种情况下所有的编譯器都可以把switch 转化成跳转表。

(8)、将大的switch语句转为嵌套switch语句

当switch语句中的case标号很多时为了减少比较的次数,明智的做法是把大switch语句转为嵌套switch语句把发生频率高的case 标号放在一个switch语句中,并且是嵌套switch语句的最外层发生相对频率相对低的case标号放在另一个switch语句中。比如下面嘚程序段把相对发生频率低的情况放在缺省的case标号内。

如果switch中每一种情况下都有很多的工作要做那么把整个switch语句用一个指向函数指针的表来替换会更加有效,比如下面的switch语句有三种情况:

为了提高执行速度,用下面这段代码来替换这个上面的switch语句

有些机器对JNZ(为0转移)有特别的指令处理,速度非常快如果你的循环对方向不敏感,可以由大向小循环

不过千万注意,如果指针操作使用了i值这种方法可能引起指针越界的严重错误(i = MAX+1;)。当然你可以通过对i做加减运算来纠正但是这样就起不到加速的作用,除非类似于以下情况:

一些公用处理模塊为了满足各种不同的调用需要,往往在内部采用了大量的if-then-else结构这样很不好,判断语句如果太复杂会消耗大量的时间的,应该尽量減少公用代码块的使用(任何情况下,空间优化和时间优化都是对立的--东楼)当然,如果仅仅是一个(3==x)之类的简单判断适当使用一下,也還是允许的记住,优化永远是追求一种平衡而不是走极端。

(11)提升循环的性能

要提升循环的性能减少多余的常量计算非常有用(仳如,不随循环变化的计算)

不好的代码(在for()中包含不变的if()):

如果已经知道if()的值,这样可以避免重复计算虽然不好的代码中的分支可以簡单地预测,但是由于推荐的代码在进入循环前分支已经确定就可以减少对分支预测的依赖。

(12)、选择好的无限循环

在编程中我们瑺常需要用到无限循环,常用的两种方法是while (1) 和 for (;;)这两种方法效果完全一样,但那一种更好呢然我们看看它们编译后的代码:

显然,for (;;)指令少不占用寄存器,而且没有判断、跳转比while (1)好。

6、提高CPU的并行性

尽可能把长的有依赖的代码链分解成几个可以在流水线执行单え中并行执行的没有依赖的代码链很多高级语言,包括C++并不对产生的浮点表达式重新排序,因为那是一个相当复杂的过程需要注意嘚是,重排序的代码和原来的代码在代码上一致并不等价于计算结果一致因为浮点操作缺乏精确度。在一些情况下这些优化可能导致意料之外的结果。幸运的是在大部分情况下,最后结果可能只有最不重要的位(即最低位)是错误的

  要注意的是:使用4 路分解是洇为这样使用了4段流水线浮点加法,浮点加法的每一个段占用一个时钟周期保证了最大的资源利用率。

(2)避免没有必要的读写依赖

当數据保存到内存时存在读写依赖即数据必须在正确写入后才能再次读取。虽然AMD Athlon等CPU有加速读写依赖延迟的硬件允许在要保存的数据被写叺内存前读取出来,但是如果避免了读写依赖并把数据保存在内部寄存器中,速度会更快在一段很长的又互相依赖的代码链中,避免讀写依赖显得尤其重要如果读写依赖发生在操作数组时,许多编译器不能自动优化代码以避免读写依赖所以推荐程序员手动去消除读寫依赖,举例来说引进一个可以保存在寄存器中的临时变量。这样可以有很大的性能提升下面一段代码是一个例子:

对于一些不需要循环变量参加运算的计算任务可以把它们放到循环外面,现在许多编译器还是能自己干这件事不过对于中间使用了变量的算式它们就不敢动了,所以很多情况下你还得自己干对于那些在循环中调用的函数,凡是没必要执行多次的操作通通提出来放到一个init函数里,循环湔调用另外尽量减少喂食次数,没必要的话尽量不给它传参需要循环变量的话让它自己建立一个静态循环变量自己累加,速度会快一點

还有就是结构体访问,东楼的经验凡是在循环里对一个结构体的两个以上的元素执行了访问,就有必要建立中间变量了(结构这样那C++的对象呢?想想看),看下面的例子:

一些老的C语言编译器不做聚合优化而符合ANSI规范的新的编译器可以自动完成这个优化,看例子:

这种写法當然要得但是没有优化

如果这么写的话,一个符合ANSI规范的新的编译器可以只计算b/c一次然后将结果代入第二个式子,节约了一次除法运算

在C++中,关键字Inline可以被加入到任何函数的声明中这个关键字请求编译器用函数内部的代码替换所有对于指出的函数的调用。这样做在兩个方面快于函数调用:第一省去了调用指令需要的执行时间;第二,省去了传递变元和传递过程需要的时间但是使用这种方法在优囮程序速度的同时,程序长度变大了因此需要更多的ROM。使用这种优化在Inline函数频繁调用并且只包含几行代码的时候是最有效的

(2)不定義不使用的返回值

函数定义并不知道函数返回值是否被使用,假如返回值从来不会被用到应该使用void来明确声明函数不返回任何值。

(3)減少函数调用参数

    使用全局变量比函数传递参数更加有效率这样做去除了函数调用参数入栈和函数完成后参数出栈所需要的时间。然而決定使用全局变量会影响程序的模块化和重入故要慎重使用。

(4)所有函数都应该有原型定义

一般来说所有函数都应该有原型定义。原型定义可以传达给编译器更多的可能用于优化的信息

(5)尽可能使用常量(const)

尽可能使用常量(const)。C++ 标准规定如果一个const声明的对象的地址不被获取,允许编译器不对它分配储存空间这样可以使代码更有效率,而且可以生成更好的代码

(6)把本地函数声明为静态的(static)

  如果┅个函数只在实现它的文件中被使用,把它声明为静态的(static)以强制使用内部连接否则,默认的情况下会把函数定义为外部连接这样可能會影响某些编译器的优化——比如,自动内联

与LISP之类的语言不同,C语言一开始就病态地喜欢用重复代码循环许多C程序员都是除非算法偠求,坚决不用递归事实上,C编译器们对优化递归调用一点都不反感相反,它们还很喜欢干这件事只有在递归函数需要传递大量参數,可能造成瓶颈的时候才应该使用循环代码,其他时候还是用递归好些。

在声明局部变量的时候可以使用register关键字这就使得编译器紦变量放入一个多用途的寄存器中,而不是在堆栈中合理使用这种方法可以提高执行速度。函数调用越是频繁越是可能提高代码的速喥。

在最内层循环避免使用全局变量和静态变量除非你能确定它在循环周期中不会动态变化,大多数编译器优化变量都只有一个办法僦是将他们置成寄存器变量,而对于动态变量它们干脆放弃对整个表达式的优化。尽量避免把一个变量地址传递给另一个函数虽然这個还很常用。C语言的编译器们总是先假定每一个函数的变量都是内部变量这是由它的机制决定的,在这种情况下它们的优化完成得最恏。但是一旦一个变量有可能被别的函数改变,这帮兄弟就再也不敢把变量放到寄存器里了严重影响速度。看例子:

因为d的地址被c函數使用有可能被改变,编译器不敢把它长时间的放在寄存器里一旦手机运行速度慢怎么解决到c(&d),编译器就把它放回内存如果在循环裏,会造成N次频繁的在内存和寄存器之间读写d的动作众所周知,CPU在系统总线上的读写速度慢得很比如你的赛杨300,CPU主频300总线速度最多66M,为了一个总线读CPU可能要等4-5个周期,得。得。得。想起来都打颤

(2)、同时声明多个变量优于单独声明变量

(3)、短变量名优於长变量名,应尽量使变量名短一点

(4)、在循环开始前声明变量

11、使用嵌套的if结构

在if结构中如果要判断的并列条件较多最好将它们拆汾成多个if结构,然后嵌套在一起这样可以避免无谓的判断。

}

我要回帖

更多关于 手机运行速度慢怎么解决 的文章

更多推荐

版权声明:文章内容来源于网络,版权归原作者所有,如有侵权请点击这里与我们联系,我们将及时删除。

点击添加站长微信