android开发过程中踩过的坑

1) 4.X下 viewgroup 不一定会向下传递requestLayout,当onlayout的速度比较慢(比如子View比较复杂之类的原因),系统会跳帧!此时子View下层的view可能就不会再被调用requestLayout的onMeasure和onLayout了。

  解决方法就是优化程序,减少子View的层数,比如非常复杂的布局,使用GridLayout之类的方式来解决,而不只是用LinearLayout和FrameLayout。如果优化也不能解决问题,考虑到机器性能也受到其它因素影响,可以考虑针对性调用必须要刷新View的requestLayout。界面慢些比界面出错要好接受一些。

2)4.1.1下ImageView的图片出现花屏。(此问题在4.2以上版本不会出现)

  背景说明:我为了控制内存,把所有需要加载大图片的drawable都做了一层代理,底层使用LruCache来管理图片占用的内存,避免一次加载太多图片时出现内存溢出。

  问题分析:对于主view打开从view后,连续打开很多张大图后,会出现主view已经显示的图片实际上在内存中已经释放,系统使用硬件加速的方式进行绘制时该内存区域已经清空,导致出现花屏现象。 而我重新加载图片的地方是在Drawable的draw方法中,在4.1.1下,如果硬件加速则不会再次调用此方法,所以此时需要在对应的ImageView中调用View.setLayerType(View.LAYER_TYPE_HARDWARE, null);

  更多资料可见:http://zuiniuwang.blog.51cto.com/3709988/721798/

时间: 2024-10-18 04:01:11

android开发过程中踩过的坑的相关文章

Android 开发中踩过的坑之六:几个关于View的tips

这几个点, 不算是坑, 但是也确实浪费了我一些时间 1.ScrollView的高设置成"wrap_content"会缩的很小,  ScrollView内只允许嵌套一个View, 并且不要将他的高度设置为"wrap_content", 否则它会缩小到很短的样子. ListView也是一样. 2.ListView中的Item如果有不同的样式,最好使用getItemViewType()来区别 事实上, 在ListView的Item完全可以用一种View布局来控制Visia

Android 开发中踩过的坑之十一: 团队协作的坑

工作中,android的坑很多,一部分是android源码自身的逻辑陷阱, 但跟多的是自己和同事们由于种种原因埋下的坑. 提高面向对象的能力,并恰当的实现在代码中,能够极大的减少坑人和被坑几率. 面向对象的最大特征是复用, 复用的目的是减少工作量,减少错误几率,提高工作效率. 总结几个自己的体会,以自勉: 1 在编码前明确代码的模块框架, 定义最简单的接口. 有人也许说, 书生造反,十年不成, 在工期紧张或者其他类似敏捷编程的大背景下, 先干起来才是硬道理. 事实上, 工期紧张也许正是因为之前的

Android 开发中踩过的坑之八:多进程问题

这是个需要细心处理的坑. 1 内存: 在manifest中可以对各个组件声明其所在的进程: android:process=":name" 然后对应的Acitivity, Receiver, Service就会运行在相应的进程中. 但是有些类会在所有进程中运行, 比如一些Utils工具类, 比如Application类. 当遇到多个进程并行的时候, 厘清进程所对应的代码, 避免在进程A里跑了进程B的代码. 比如有一个工具类Utils_procA. 只需要在进程A中工作, 那对于进程B来

Android 开发中踩过的坑之十: 谨慎处理动画的开始和结束

Android提供多种动画机制, 从面相对象的方式到直接实现底层onDraw的方式, 给予了足够的控件实现希望的效果, 无论时使用哪种方式实现动画, 都要谨慎的处理动画的两个状态, 开始和结束 需要关注的问题有: 1 动画开始的时候是否需要重新初始化内存? 对于需要重复展示的动画, 应当避免每次都new新的内存, 否则在动画展示过程, 内存会不断增加, 而gc合适回收, 是不确定的. 也许当gc时, 你已经在OOM的边缘了. 2 动画开始时是否是从某个中间状态开始的? 动画从某个中间状态开始,

Android 开发中踩过的坑之七:尽量避免使用Acitivity当做Context

这坑容易埋, 却不容易发现. 比如启动一个页面, 需要用到一个单例的工具类Utils, 初始化Utils需要一个Context参数, 直接传入Activity.this. 然后这个单例的Utils就会一直持有Activity.this, 导致整个Acitivity不能被GC. 而如果代码中大量的使用Utils, 又不能确认到底谁最先初始化了Utils, 使得内存泄露成了灵异事件难以发现. 所以, 正确的使用方式是: activity.this.getApplicationContext(); g

Android 开发中踩过的坑之二: 16ms的UI线程时间才不会卡顿

AndroidUI卡顿, 是总会遇到的问题, 这个坑经常遇到, 通常在优化时才会重点关注. 通常在Adapter.getView()方法中比较突出. 人眼的原因, 1秒24帧的动画才能感到顺畅. 所以每帧的时间大概有41ms多一点点(1000ms/24). 但是但是, 注意了, 这41ms不是全都留给你java代码, 而是所有java native 屏幕等等的, 最后留给我们用java级别发挥的时间, 只有16~17ms了. 所以,当你优化视觉效果时, 留意UI线程的时间, 超过16ms, 就需

Android 开发中踩过的坑之九: 发布一个aar的注意事项

现在Android支持aar格式发布一个模块, 提供给其他人使用. aar其实是jar和一些资源文件的zip包. 解决了过去jar包不能分享资源的局限. 1 要尽量避免定义内部接口, 这其实是一个编程习惯, 接口interface最好是独立定义, 避免定义在类的内部. 因为当你发布aar时, 内部的接口在混淆后会独立成一个外部的接口Outer$InnerInterface. 然后麻烦来了, 别人在实现这个类的时候必须也写成XXX implement Outer$InnerInterface{}的

LigerUI开发过程中踩过的坑

一.使用ligerForm创建初始化查询表单.并在查询方法中获取表单中的值,传到后台的时候 会报错,因为日期类型的如果不填值的话,往后台默认传的的null, 需要进行非null判断,如果为null,不传 1.创建表单 1 $(function() { 2 //创建表单结构 3 var form = $("#form").ligerForm( { 4 inputWidth : 170, 5 labelWidth : 90, 6 space : 40, 7 fields : [ { 8 d

Android 开发中踩过的坑之四:低版本使用AsyncTask

这个坑比较隐晦, 一般不容易出现. 有可能在使用AsyncTask时, 明明就是在postResult()方法里设置UI, 却被告知不能在非UI线程设置UI的异常. 这实际上应用App启动时的一个bug. AsyncTask是在初始化的时候, 自己取当前的线程获取Looper. 但是问题来了, 当前线程可能并不是UI线程, 所以就导致了postResult()等原本应该在UI线程工作方法, 实际上在非UI线程. 谷歌在4.1以后版本里解决这个bug, 就是在应用启动时, 在UI线程里先调用了一次