RecycleView设置顶部分割线(记录一个坑)

大家都知道,想给RecycleView设置分割线可以重写RecyclerView.ItemDecoration

项目过程中,遇到一个需求:RecycleView顶部有一条灰色的间隔,我想到了给RecycleView设置分割线的方法,当然只给第一个Item设置,而且在上方。

 

在onDrawOver方法中可以绘制分割线。

这里有一个需要注意的坑,调试了很久,最终才发现,难受。

在onDrawOver里面,一开始我设置top = 0;因为绘制在顶部嘛。结果出现了一个现象,顶部分割线一直停留在顶部,不会跟着移动。最后改为int top = child.getTop() – params.topMargin – mDivider.getIntrinsicHeight();才成功了。为什么呢?

因为直接写top = 0;这是绝对位置了,要让分割线也跟着滑动,需要用的是相对位置,相对于item的位置,这样才能够跟着item滑动

 

调用

recyclerView.addItemDecoration(new MyDividerItemDecoration(this, R.drawable.item_decoration));

item_decoration代码如下:


 

或者我们可以直接代码中创建Drawable,然后传进去:


 

尊重劳动成果,转载请标明出处:http://77blogs.com/?p=569

java.util.ConcurrentModificationException 异常问题详解

转载自:https://www.cnblogs.com/snowater/p/8024776.html

 

环境:JDK 1.8.0_111

在Java开发过程中,使用iterator遍历集合的同时对集合进行修改就会出现java.util.ConcurrentModificationException异常,本文就以ArrayList为例去理解和解决这种异常。

一、单线程情况下问题分析及解决方案

1.1 问题复现

先上一段抛异常的代码。

复制代码

复制代码

在这个代码中展示了两种能抛异常的实现方式。

1.2、问题原因分析

先来看实现方法一,方法一中使用Iterator遍历ArrayList, 抛出异常的是iterator.next()。看下Iterator next方法实现源码

复制代码

复制代码

在next方法中首先调用了checkForComodification方法,该方法会判断modCount是否等于expectedModCount,不等于就会抛出java.util.ConcurrentModificationExcepiton异常。

我们接下来跟踪看一下modCount和expectedModCount的赋值和修改。

modCount是ArrayList的一个属性,继承自抽象类AbstractList,用于表示ArrayList对象被修改次数。

整个ArrayList中修改modCount的方法比较多,有add、remove、clear、ensureCapacityInternal等,凡是设计到ArrayList对象修改的都会自增modCount属性。

在创建Iterator的时候会将modCount赋值给expectedModCount,在遍历ArrayList过程中,没有其他地方可以设置expectedModCount了,因此遍历过程中expectedModCount会一直保持初始值20(调用add方法添加了20个元素,修改了20次)。

遍历的时候是不会触发modCount自增的,但是遍历到integer.intValue() == 5的时候,执行了一次arrayList.remove(integer),这行代码执行后modCount++变为了21,但此时的expectedModCount仍然为20。

在执行next方法时,遇到modCount != expectedModCount方法,导致抛出异常java.util.ConcurrentModificationException。

明白了抛出异常的过程,但是为什么要这么做呢?很明显这么做是为了阻止程序员在不允许修改的时候修改对象,起到保护作用,避免出现未知异常。引用网上的一段解释,点击查看解释来源

Iterator 是工作在一个独立的线程中,并且拥有一个 mutex 锁。 Iterator 被创建之后会建立一个指向原来对象的单链索引表,当原来的对象数量发生变化时,这个索引表的内容不会同步改变。 当索引指针往后移动的时候就找不到要迭代的对象,所以按照 fail-fast 原则 Iterator 会马上抛出 java.util.ConcurrentModificationException 异常。 所以 Iterator 在工作的时候是不允许被迭代的对象被改变的。但你可以使用 Iterator 本身的方法 remove() 来删除对象, Iterator.remove() 方法会在删除当前迭代对象的同时维护索引的一致性。

再来分析下第二种for循环抛异常的原因:

复制代码

复制代码

在for循环中一开始也是对expectedModCount采用modCount进行赋值。在进行for循环时每次都会有判定条件modCount == expectedModCount,当执行完arrayList.remove(integer)之后,该判定条件返回false退出循环,然后执行if语句,结果同样抛出java.util.ConcurrentModificationException异常。

这两种复现方法实际上都是同一个原因导致的。

1.3 问题解决方案

上述的两种复现方法都是在单线程运行的,先来说明单线程中的解决方案:

复制代码

复制代码

这种解决方案最核心的就是调用iterator.remove()方法。我们看看该方法源码为什么这个方法能避免抛出异常

复制代码

复制代码

在iterator.remove()方法中,同样调用了ArrayList自身的remove方法,但是调用完之后并非就return了,而是expectedModCount = modCount重置了expectedModCount值,使二者的值继续保持相等。

针对forEach循环并没有修复方案,因此在遍历过程中同时需要修改ArrayList对象,则需要采用iterator遍历。

上面提出的解决方案调用的是iterator.remove()方法,如果不仅仅是想调用remove方法移除元素,还想增加元素,或者替换元素,是否可以呢?浏览Iterator源码可以发现这是不行的,Iterator只提供了remove方法。

但是ArrayList实现了ListIterator接口,ListIterator类继承了Iter,这些操作都是可以实现的,使用示例如下:

复制代码

复制代码

二、 多线程情况下的问题分析及解决方案

单线程问题解决了,再来看看多线程情况。

2.1 问题复现

复制代码

复制代码

在个测试代码中,开启两个线程,一个线程遍历,另外一个线程遍历加修改。程序输出结果如下

复制代码

复制代码

2.2 问题分析

从上面代码执行结果可以看出thread2 遍历结束后,thread1 sleep完1000ms准备遍历第二个元素,next的时候抛出异常了。我们从时间点分析一下抛异常的原因

时间点 arrayList.modCount thread1 iterator.expectedModCount thread2 iterator.expectedModCount
thread start,初始化iterator 20 20 20
thread2.remove()调用之后 21 20 21

 

 

 

两个thread都是使用的同一个arrayList,thread2修改完后modCount = 21,此时thread2的expectedModCount = 21 可以一直遍历到结束;thread1的expectedModCount仍然为20,因为thread1的expectedModCount只是在初始化的时候赋值,其后并未被修改过。因此当arrayList的modCount被thread2修改为21之后,thread1想继续遍历必定会抛出异常了。

在这个示例代码里面,两个thread,每个thread都有自己的iterator,当thread2通过iterator方法修改expectedModCount必定不会被thread1感知到。这个跟ArrayList非线程安全是无关的,即使这里面的ArrayList换成Vector也是一样的结果,不信上测试代码:

复制代码

复制代码

执行后输出结果为:

复制代码

复制代码

test5()方法执行结果和test4()是相同的,那如何解决这个问题呢?

2.3 多线程下的解决方案

2.3.1 方案一:iterator遍历过程加同步锁,锁住整个arrayList

复制代码

复制代码

这种方案本质上是将多线程通过加锁来转变为单线程操作,确保同一时间内只有一个线程去使用iterator遍历arrayList,其它线程等待,效率显然是只有单线程的效率。

2.3.2 方案二:使用CopyOnWriteArrayList,有坑!要明白原理再用,否则你就呆坑里吧。

我们先来看代码,很有意思咯

复制代码

复制代码

先不分析,看执行结果,这个执行结果重点关注字体加粗部分。

复制代码

复制代码

我们先分析thread2的输出结果,第一次遍历将4 5 6都输出,情理之中;第一次遍历后删除掉了一个元素,第二次遍历输出4 6,符合我们的预期。

再来看下thread1的输出结果,有意思的事情来了,thread1 仍然输出了4 5 6,什么鬼?thread1和thread2都是遍历list,list在thread1遍历第二个元素的时候就已经删除了一个元素了,为啥还能输出5?

为了了解这个问题,需要了解CopyOnWriteArrayList是如何做到一边遍历的同时还能一边修改并且还不抛异常的。

在这里不想再深入分析CopyOnWriteArrayList代码,后续会专门出一篇博客来解释这个类的源码的。

这里说一下CopyOnWriteArrayList的解决思路,其实很简单:

CopyOnWriteArrayList本质上是对array数组的一个封装,一旦CopyOnWriteArrayList对象发生任何的修改都会new一个新的Object[]数组newElement,在newElement数组上执行修改操作,修改完成后将newElement赋值给array数组(array=newElement)。

因为array是volatile的,因此它的修改对所有线程都可见。

了解了CopyOnWriteArrayList的实现思路之后,我们再来分析上面代码test6为什么会出现那样的输出结果。先来看下thread1和thread2中用到的两种遍历方式的源码:

复制代码

复制代码

 

复制代码

复制代码

这两种遍历方式有个共同的特点:都在初始化的时候将当前数组保存下来了,之后的遍历都将会遍历这个数组,而不管array如何变化。

时间点 CopyOnWriteArrayList的array thread1 iterator 初始化的Object数组 thread2 第一次遍历forEach初始化的Object数组 thread2 第二次遍历forEach初始化的Object数组
thread start 假设为A A A /
thread2 调用remove方法之后 假设为B A A B

 

 

 

有了这个时间节点表就很清楚了,thread1和thread2 start的时候都会将A数组初始化给自己的临时变量,之后遍历的也都是这个A数组,而不管CopyOnWriteArrayList中的array发生了什么变化。因此也就解释了thread1在thread2 remove掉一个元素之后为什么还会输出5了。在thread2中,第二次遍历初始化数组变成了当前的array,也就是修改后的B,因此不会有Integer.valueOf(5)这个元素了。

从test6执行结果来看,CopyOnWriteArrayList确实能解决一边遍历一边修改并且还不会抛异常,但是这也是有代价的:

(1) thread2对array数组的修改thread1并不能被动感知到,只能通过hashCode()方法去主动感知,否则就会一直使用修改前的数据

(2) 每次修改都需要重新new一个数组,并且将array数组数据拷贝到new出来的数组中,效率会大幅下降

此外CopyOnWriteArrayList中的ListIterator实现是不支持remove、add和set操作的,一旦调用就会抛出UnsupportedOperationException异常,因此test6注释代码34-41行中如果运行是会抛异常的。

参考文献:

http://lz12366.iteye.com/blog/675016

http://www.cnblogs.com/dolphin0520/p/3933551.html

http://blog.csdn.net/androiddevelop/article/details/21509345

Java list.remove( )方法需要注意的地方

List integerList = new ArrayList<>();

当我们要移除某个Item的时候

remove(int position):移除某个位置的Item

remove(object object):移除某个对象

 

那么remove(12)到底是移除第12的item,还是移除内容为12的Item。

那就要看12到底是int类型还是Integer类型,如果是int类型那么就是移除第12的item,如果是第Integer类型,那么就是移除内容为12的Item。

 转载请标明:http://77blogs.com/?p=572

调用android的getColor()方法出现 java.lang.NoSuchMethodError: android.content.res.Resources.getColor

1.java.lang.NoSuchMethodError: android.content.res.Resources.getDrawable/getColor
或者 java.lang.NoSuchMethodError:android.content.Context.getDrawable/geColor

 

原因:Context类的getDrawable(res)/geColor(res)方法和Resources的getDrawable(res,theme)/getColor(res.theme)都是API21才添加的,低版本系统无法找到该方法所以报异常。

 

解决办法:
使用Resources的getDrawable(res),但是该方法在API22已废弃。
使用ContextCompat.getDrawable(context,res)。

原文链接:https://blog.csdn.net/qq_22256565/article/details/52133565

配置ADB到Windows环境变量

adb 命令可以帮我们快速的管理连接的手机设备,例如执行一些安装apk,卸载apk命令,对于熟悉linux系统的人,可以方便的管理手机目录操作手机文件,还可以通过adb命令查看手机的系统日志等操作。

接下来讲一讲如何在windows系统下配置ADB环境变量:

  1. “计算机”右击属性进入系统设计界面,如下图所示。选择“高级系统设置”

    配置ADB到Windows环境变量
  2. 进入后选择“高级”–“环境变量”

    配置ADB到Windows环境变量
  3. 在系统变量中找到“path”,选中后点击“编辑”

    配置ADB到Windows环境变量
  4. 将ADB文件路径放在最后,注意使用英文输入法的  ;   隔开。

    笔者的ADB文件路径在:D:\platform-tools  请读者根据自己的路径参考。

    配置ADB到Windows环境变量
  5. 测试ADB

    在命令行中输入adb,看到如下信息说明完成配置ADB到Windows环境变量。

    配置ADB到Windows环境变量
    配置ADB到Windows环境变量

Paint.FontMetrics

要了解TextView对文本的绘制,那么就需要了解Paint.FontMetircs。

官方对该类的解释是:Class that describes the various metrics for a font at a given text size., 意思是说,这玩意儿是绘制文本内容时存储该文本内容位置信息的一个类。

 

这个类里面存储的字段有哪些?有下面五个字段:

 

而这五个字段除了leading,其余的都是根据BaseLine来确定,也就是基线。

 

1、何为BaseLine

 

2、接下来说说里面字段的具体含义,请看下图:

根据上图可知:

    • ascent
      文字内容的顶部到基线的距离。即 ascent=文字内容顶部Y坐标 – 基线Y坐标。由于android中坐标系是 右下为正,所以得到的ascent实际是一个负数。
    • descent
      文字内容的底部到基线的距离。即 descent=文字内容底部Y坐标 – 基线Y坐标。
    • 基线
      在图中,基线的坐标用Y表示。实际上,基线的Y坐标=文字内容中间线Y坐标+1/2 (文字内容高度)
    • top
      对应图中 文字所在行的top 坐标
    • bottom
      对应图中 文字所在行的bottom 坐标
      需要注意:如果设置了行间距,且文本内容产生了换行,那么这个bottom 也会将行间距包裹。所以, 图中蓝色的文字内容中间线的Y轴坐标并不一定等于 (bottom+top)/2

参考链接:https://www.cnblogs.com/huolongluo/p/7057973.html

 

Bitmap上下合成图片

合成两张图片,上下叠加的效果:


 

 

EventBus 3.0使用详解

EventBus 3.0使用详解

01 前言

当我们进行项目开发的时候,往往是需要应用程序的各组件、组件与后台线程间进行通信,比如在子线程中进行请求数据,当数据请求完毕后通过Handler或者是广播通知UI,而两个Fragment之家可以通过Listener进行通信等等。当我们的项目越来越复杂,使用Intent、Handler、Broadcast进行模块间通信、模块与后台线程进行通信时,代码量大,而且高度耦合。现在就让我们来学习一下EventBus 3.0吧。

02 什么是EventBus

EventBus Github地址
进入官网,看看人家是怎么解释的:

  • simplifies the communication between components
    decouples event senders and receivers
    performs well with Activities, Fragments, and background threads
    avoids complex and error-prone dependencies and life cycle issues
  • makes your code simpler
  • is fast
  • is tiny (~50k jar)
  • is proven in practice by apps with 100,000,000+ installs
  • has advanced features like delivery threads, subscriber priorities, etc.

大概的意思就是:EventBus能够简化各组件间的通信,让我们的代码书写变得简单,能有效的分离事件发送方和接收方(也就是解耦的意思),能避免复杂和容易出错的依赖性和生命周期问题。

03 关于EventBus的概述

三要素

  • Event 事件。它可以是任意类型。
  • Subscriber 事件订阅者。在EventBus3.0之前我们必须定义以onEvent开头的那几个方法,分别是onEvent、onEventMainThread、onEventBackgroundThread和onEventAsync,而在3.0之后事件处理的方法名可以随意取,不过需要加上注解@subscribe(),并且指定线程模型,默认是POSTING。
  • Publisher 事件的发布者。我们可以在任意线程里发布事件,一般情况下,使用EventBus.getDefault()就可以得到一个EventBus对象,然后再调用post(Object)方法即可。

四种线程模型

EventBus3.0有四种线程模型,分别是:

  • POSTING (默认) 表示事件处理函数的线程跟发布事件的线程在同一个线程。
  • MAIN 表示事件处理函数的线程在主线程(UI)线程,因此在这里不能进行耗时操作。
  • BACKGROUND 表示事件处理函数的线程在后台线程,因此不能进行UI操作。如果发布事件的线程是主线程(UI线程),那么事件处理函数将会开启一个后台线程,如果果发布事件的线程是在后台线程,那么事件处理函数就使用该线程。
  • ASYNC 表示无论事件发布的线程是哪一个,事件处理函数始终会新建一个子线程运行,同样不能进行UI操作。

04 EventBus的基本用法

举个例子,我需要在一个Activity里注册EventBus事件,然后定义接收方法,这跟Android里的广播机制很像,你需要首先注册广播,然后需要编写内部类,实现接收广播,然后操作UI。所以,在EventBus中,你同样得这么做。

自定义一个事件类


 

 

这里有些同学,会有一些疑问,为什么要建立这样一个类,有什么用途。其实这个类就是一个Bean类,里面定义用来传输的数据的类型。

注册事件

 

当我们需要在Activity或者Fragment里订阅事件时,我们需要注册EventBus。我们一般选择在Activity的onCreate()方法里去注册EventBus,在onDestory()方法里,去解除注册。

解除注册


 

发送事件

 

处理事件


 

前面我们说过,处理消息的方法名字可以随便取。但是需要加一个注解@Subscribe,并且要指定线程模型。

05 EventBus使用实战

以上我们讲了EventBus的基本用法,没有用过的同学也不要担心不会用,小编在这里举个小栗子。

第一步:添加依赖


 

第二步:定义消息事件类


 

第三步:注册和解除注册

分别在FirstActivity的onCreate()方法和onDestory()方法里,进行注册EventBus和解除注册。


 

事件处理

在这里,事件的处理线程在主线程,是因为,我要让TextView去显示值。
在 SecondActivity里去进行事件的发送。


 

很简单,当点击按钮的时候,发送了一个事件。

运行程序。

 
1.PNG

 

 

在FirstActivity中,左边是一个按钮,点击之后可以跳转到SecondActivity,在按钮的右边是一个TextView,用来进行结果的验证。

 
2.PNG

这是SecondActivity,在页面的左上角,是一个按钮,当点击按钮,就会发送了一个事件,最后这个Activity就会销毁掉。

 

 
3.PNG

 

此时我们可以看到,FirstActivity里的文字已经变成了,我们在SecondActivity里设置的文字。

总结

经过这个简单的例子,我们发现EventBus使用起来是如此的方便,当我们的代码量变得很多的时候,使用EventBus后你的逻辑非常的清晰,并且代码之间高度解耦,在进行组件、页面间通信的时候,EventBus是一个不错的选择。

谢谢小伙伴啦

赞赏支持

 

 

scrollTo不起作用

最近,我在HorizontalScrollview中使用scrollTo不起作用?

……

以上省略N个字。

我只想说:

 

在使用scrollTo的时候,要先保证该HorizontalScrollview已经初始化完毕,要是无法保证,那么,可以在HorizontalScrollview中这样写

这样便能够保证在view初始化完成之后再执行scrollTo()