踩坑记录2

27、Android studio 编译时会出现意外项目路径太长出错问题，解决方法是在buil。gradle中的allprojects节点加上buildDir = "E:/build/${rootProject.name}/${project.name}" 出现自定义build的文件夹地址
28、在View post 或线程执行时，要在run函数中再判断所用对象非空
29、在recyclerView 的item复用机制中注意，item缓存大小，复用时机，数据绑定时机，item中图片资源释放可以使用自定义ImageView，当图片不可见是赶紧释放
30、使用Picasso或Glid 或Fresco 都要认真查看各个库自定义的Lrucache 实现，一般要自己实现LRUCache
31、使用findBugs插件审查自己的代码
32、导出hprof文件查看内存消耗
33、traceview 查看耗时情况

34、提升性能，APP效率 的话不要偷懒使用第三方注解绑定，个人见解

35、要用Python 和MonkeyRunner 编写测试用例，不能只是跑跑monkey测试；Android studio和UiAutomator页可以

37、DecorView是顶级View，内部有titlebar和contentParent两个子元素，contentParent的id是content，而我们设置的main.xml布局则是contentParent里面的一个子元素
38、区别就是binderDied()方法跑在Binder Thread中，onServiceDisconnected方法跑在客户端的UI线程中
39、Touch 事件分析
▐ 事件分发：public boolean dispatchTouchEvent(MotionEvent ev)
Touch 事件发生时 Activity 的 dispatchTouchEvent(MotionEvent ev) 方法会以隧道方式（从根元素依次往下传递直到最内层子元素或在中间某一元素中由于某一条件停止传递）将事件传递给最外层 View 的 dispatchTouchEvent(MotionEvent ev) 方法，并由该 View 的 dispatchTouchEvent(MotionEvent ev) 方法对事件进行分发。dispatchTouchEvent 的事件分发逻辑如下：
如果 return true，事件会分发给当前 View 并由 dispatchTouchEvent 方法进行消费，同时事件会停止向下传递；
如果 return false，事件分发分为两种情况：
如果当前 View 获取的事件直接来自 Activity，则会将事件返回给 Activity 的 onTouchEvent 进行消费；
如果当前 View 获取的事件来自外层父控件，则会将事件返回给父 View 的  onTouchEvent 进行消费。
如果返回系统默认的 super.dispatchTouchEvent(ev)，事件会自动的分发给当前 View 的 onInterceptTouchEvent 方法。
▐ 事件拦截：public boolean onInterceptTouchEvent(MotionEvent ev) 
在外层 View 的 dispatchTouchEvent(MotionEvent ev) 方法返回系统默认的 super.dispatchTouchEvent(ev) 情况下，事件会自动的分发给当前 View 的 onInterceptTouchEvent 方法。onInterceptTouchEvent 的事件拦截逻辑如下：
如果 onInterceptTouchEvent 返回 true，则表示将事件进行拦截，并将拦截到的事件交由当前 View 的 onTouchEvent 进行处理；
如果 onInterceptTouchEvent 返回 false，则表示将事件放行，当前 View 上的事件会被传递到子 View 上，再由子 View 的 dispatchTouchEvent 来开始这个事件的分发；
如果 onInterceptTouchEvent 返回 super.onInterceptTouchEvent(ev)，事件默认会被拦截，并将拦截到的事件交由当前 View 的 onTouchEvent 进行处理。
▐ 事件响应：public boolean onTouchEvent(MotionEvent ev)
在 dispatchTouchEvent 返回 super.dispatchTouchEvent(ev) 并且 onInterceptTouchEvent 返回 true 或返回 super.onInterceptTouchEvent(ev) 的情况下 onTouchEvent 会被调用。onTouchEvent 的事件响应逻辑如下：
如果事件传递到当前 View 的 onTouchEvent 方法，而该方法返回了 false，那么这个事件会从当前 View 向上传递，并且都是由上层 View 的 onTouchEvent 来接收，如果传递到上面的 onTouchEvent 也返回 false，这个事件就会“消失”，而且接收不到下一次事件。
如果返回了 true 则会接收并消费该事件。
如果返回 super.onTouchEvent(ev) 默认处理事件的逻辑和返回 false 时相同。
到这里，与 Touch 事件相关的三个方法就分析完毕了。下面的内容会通过各种不同的的测试案例来验证上文中三个方法对事件的处理逻辑
40、 EventBus 2.x 是采用反射的方式对整个注册的类的所有方法进行扫描来完成注册，当然会有性能上的影响。EventBus3.0中EventBus提供了EventBusAnnotationProcessor注解处理器来在编译期通过读取@Subscribe()注解并解析、处理其中所包含的信息，然后生成java类来保存所有订阅者关于订阅的信息，这样就比在运行时使用反射来获得这些订阅者的信息速度要快
41、EventBus 3由于使用了注解，比起使用反射来遍历方法的2.4版本逊色不少。但开启了索引后性能像打了鸡血一样，远远超出之前的版本
41、一般意义上的锁是不公平的，不一定先来的线程能先得到锁，后来的线程就后得到锁。不公平的锁可能会产生饥饿现象。
公平锁的意思就是，这个锁能保证线程是先来的先得到锁。虽然公平锁不会产生饥饿现象，但是公平锁的性能会比非公平锁差很多
42、Future最令人诟病的就是要等待，要自己去检查任务是否完成了，在Future中，任务完成的时间是不可控的。而 CompletableFuture的最大改进在于，任务完成的时间也开放了出来