刘志保的博客

常常在开发过程中使用自定义的View,而自定义的View的图形往往是onDraw里面实现的,这样就可能因为在父容器里面而因为父容器稍微的变更,就会重绘,重绘是需要很多内存消耗的,而且如果父容器有背景色,那么onDraw所画的一切图形色彩都是再父容器的基础上进行,从而导致某一个像素点上,进行了多次渲染,这是需要内存消耗的.专家的建议是:我们可以先按照通常的方式把View上的元素按照从后到前的方式

过度绘制:专家的理解如下:Overdraw(过度绘制)描述的是屏幕上的某个像素在同一帧的时间内被绘制了多次。在多层次重叠的UI结构里面，如果不可见的UI也在做绘制的操作，会导致某些像素区域被绘制了多次。这样就会浪费大量的CPU以及GPU资源过度绘制在以前做项目中优化性能的时候就涉及到了,检查过度绘制倒是挺简单的,进入手机设置APP页面,开发者选项->Debug GPU overdr

由于开发过程中经常要使用图片,特别是从互联网上面获取图片,如果要让设备获取互联网上面图片,就意味着连接网络,获取图片,但是从服务器获取图片是需要时间的,当图片非常多,或者图片有非常大的时候,这样获取是很危险的,可能常常遇见OOM的问题,导致APP不稳定,性能非常的差,而且频繁的联网获取,浪费流量和电量,有无数个不爽,所以android就引入LRU算法来改善图片加载的问题.大致的逻辑应该是这样的

最近刚好做图形处理方面,对图片像素进行处理,可想而知,一张图片如800*800的,那么像素点就有640000个,如果对这么大的一个数据进行运算操作,将会消耗大量内存空间,下面是自己在处理一张图片,让这张图片调整成一张老照片效果,具体操作如下: : 新建Android工程如下: : 工程里面还有其他的代码,这里只给出主要涉及的:DurianMainActivity.java

专家的参考建议:Lint是Android提供的一个静态扫描应用源码并找出其中的潜在问题的一个强大的工具.例如，如果我们在onDraw方法里面执行了new对象的操作，Lint就会提示我们这里有性能问题，并提出对应的建议方案。Lint已经集成到Android Studio中了，我们可以手动去触发这个工具，点击工具栏的Analysis -> Inspect Code，触发之后，Lint会开始工作，

最近看了网上面很多博客或者APP转发较多的一篇blog,说再也不用当心从服务器上面获取的图片有多大了,都能够轻松显示出来,不知道是不是没有仔细看那篇文章,还是什么,没有特别验证,感觉很奇怪,他不是通过压缩图片的方式显示,而是通过裁剪图片的方式然后显示出来,通过裁剪的方式压缩图片大小,个人觉得很奇怪,裁剪过的图片还有什么用呢?个人结合前面的一篇博客,通过压缩的办法,然后在结合在网上面看了一些推荐

前面的博客都涉及到了很多关于从服务器获取图片资源的方法,比如LRUCache,图片压缩等,下面介绍的是物理储存介质作为cache的介质,即图片资源临时保存到物理储存介质上. : 工程代码:不知道为什么居然有70多M,也是醉了!http://pan.baidu.com/s/1ntQcl3V工程代码有参照老外的code. : 基本的技术面如下:具体使用放到异步线程中 :

在很多APP经常会因为数据量大,或者一个页面占有内存较高,在切换到另外一个页面的时候,内存不能够暂时释放,导致切换到另外一个页面加载较慢...Android在4.0版本后推出了onLowMemory()和onTrimMemory(...)两个回调方法,提供给开发者,提示Android APP在低内存的状态.OnTrimMemory的主要作用就是指导应用程序在不同的情况下进行自身的内存释放，

这个需要看那些非常厉害的专家的blog,要缩短Activity启动时间,可以参考一下思路: : Activity 完整启动过程,更多的是属性framework部分;看熟Activity类,PhoneWindow类,DecorView这个内部类,ViewRootImpl类;只有熟悉真正的原理了,才知道为什么,为什么,为什么需要这样操作. : 一个隐蔽的方法;Activity.at

Android Lint工具相对开发者而言,要比测试者使用更加重要和有效.当自己差不多开发完一个工程后,发现工程代码中有一堆测试代码,到处都是,想一个一个的去删除,那真的是揪心;还有一些代码,同样的类型,这个地方是这种写法,那个地方是那种写法,反正写法有无数种;资源res文件中还有一堆一堆没有用的属性,值,可能由于很多种原因造成的,一个本来1kb的资源,硬是逼成了2kb(app瘦身绝对

这个是个老话题了,前面有一些提及过了,专家的建议如下:提升布局性能的关键点是尽量保持布局层级的扁平化，避免出现重复的嵌套布局。例如下面的例子，有2行显示相同内容的视图，分别用两种不同的写法来实现，他们有着不同的层级当然还的知道为什么需要这样调整:Android需要把XML布局文件转换成GPU能够识别并绘制的对象。这个操作是在DisplayList的帮助下完成的。DisplayList持

在自定义View 里面如果又有很多个子View相互重叠,比如,开发者在一张canvas上面画了N张图片,而N张图片存在重叠,那么很显然就会存在过度绘制的现象.专家分析的意见如下:前面有提到过，对不可见的UI组件进行绘制更新会导致Overdraw。例如Nav Drawer从前置可见的Activity滑出之后，如果还继续绘制那些在Nav Drawer里面不可见的UI组件，这就导致了Overdr

学习网上面以为厉害的博主的文章,自己跟着学习的节奏,也一步一步的进行学着分析,加深印象,更重要的是自己能够熟悉里面的细节部分,细节决定一些性能.首先写了一个测试demo程序如下:  新建Android工程,工程树如下: : 程序如下:DurianMainActivity.javapackage com.durian.durianperformanceview;impor

为了防止APP可能出现的ANR问题,google引入StrictMode检查机制,有效预防app可能产生ANR的问题:Android提供了一个叫做Strict Mode的工具，我们可以通过手机设置里面的开发者选项，打开Strict Mode选项，如果程序存在潜在的隐患，屏幕就会闪现红色。我们也可以通过StrictMode API在代码层面做细化的跟踪，可以设置StrictMode监听那些潜在问

如果有钱,有资源,有精力,你可以24小时折腾,但是很可惜,目前的智能设备,要内存没内存,要电量没电量,所以一天容不得过多折腾.那么做事就要讲究方法,要有计划,才能在短时间,消耗更少的资源,节省更多的电量把事情做完.下面三个方面可以考虑: :  定时器-AlarmManager :但是如果理解它按照要求定时的work就没什么意思了,它一般有两种工作模式 : : 精确定时;

下面参考了一些专家的建议和平时天天因为程序的不规范,天天都能够见到的.下面几种都有一个共同的地方:java的非静态内部类都会有外部累的隐式引用,有隐式引用就会有依赖关系.内存之所以泄露,是因为该回收的资源无法回收,导致分配出去的内存还在被使用,但是这种使用已经是无意义的,本来是需要回收的,结果发觉外部坠毁的时候,它还在被引用(即被使用);这个可以打一个比方:我们平时使用windows系统的时候

前面好几篇中涉及到WeakReference类的使用下面归纳一下java的四种引用区别:首先大致画一个GC回收机制模型:看到上面这张图片:每次给一个对象分配内存的时候,都会有一种机制跟踪这个对象的内存使用情况,有一种指向性,这样在GC发生时,虚拟机根据这些指向就知道,这些都需要全部回收.再看下面上面这张图:对象在开始的时候,仍然还是有指向的,但是后来由于某种原因指向性没有了

其实针对网络优化的内容还是非常非常多的,耗电,内存空间,图形渲染,图片压缩缓存等等太多了,这里根据专家的参考建议,做了一个HttpResponseCache类的测试:具体程序工程如下:package org.durian.durianhttpresponsecache;import android.content.Context;import android.graphi

在开发android app的过程中,常常需要使用图片资源,然而在使用图片资源的过程中,常常因为内存不够导致OOM crash事故.google 和牛人提供了一下建议,希望能够解决和改善使用图片资源带来的内存使用过度的现象.使用更小的图片:在设计给到资源图片的时候，我们需要特别留意这张图片是否存在可以压缩的空间，是否可以使用一张更小的图片。尽量使用更小的图片不仅仅可以减少内存的使用，还可

按照专家的建议,为了改善内存的使用,以及程序的优良性,建议引入对象池技术,以最大程度改善程序性能,个人看了相关资料,主要有两方面的有点,优点一:不需要VM反复为"同一个对象"去创建,同时也不需要,也就是不会引入新的内存空间,占用新的内存地址;优点二:由于一些对象创建了以后,不就又被释放了,如果再使用的话,就需要重新创建新的对象,这样重新创建需要消耗更多的时间.专家的建议:大

原文地址:Android Performance Patterns: Rescue tips : 避免“坏”表现: 避免堵塞主线程　　避免可能引发大范围重绘的不必要的重绘　　用 RelativeLayout 来减少布局层级　　避免在 LinearLayout 中使用嵌套的 weight 属性(因为weight属性会使每个子View进行两次measure)