为了营造完全重叠的前提，两个 Button 的父布局设置为 FrameLayout 或者 RelativeLayout。然后分别在代码里添加点击事件监听，打印相应 log，就像这样，
btn1.setOnClickListener(v ->{
LogUtils.d("button 1 get")
});
btn2.setOnClickListener(v ->{
LogUtils.d("button 2 get")
});
//btn2 显示在 btn1 上面，这个情况下，我们看不到 btn1
//如果这么点击，很显然打印的是 btn2 的 log
借此机会回顾下点击事件分发机制，我们俗称的点击事件被系统封装成 MotionEvent 类对象，事件分为四类，分别是 DOWN, MOVE, UP 和 CANCEL。一个完成的点击事件处理一般是从 DOWN 开始，UP 或者 CANCEL 结束。事件产生之后，会先经过 Activity，由 Activity 进行分发，而 Activity 又会交给 PhoneWindow 对象转给根视图 DecorView 进行事件分发。所以接下去就是从 DecorView 开始进行的事件传递，对于 ViewGroup 子类（即容器类）需要进行分发和判断是否拦截（默认不拦截）；对于 View 子类（这里指具体控件，例如 Button）需要决定是否进行事件消费（即事件处理）。如果容器类不拦截，就倒叙遍历子View 进行分发事件，如果拦截那就自己决定是否处理事件，具体控件如果要处理，那事件就被消费掉不会再继续流转，如果不消费，就流转给下一个，如果都不处理，事件就一层层的又回到 Activity。
在具体控件或者容器类自己判断要不要处理事件时，首先会看是否设置了 OnTouchListener，并且回调方法 onTouch() 返回是否为 true，接着会调用 onTouchEvent() 方法看是否可点击，如果都不满足就不会消费事件了。那什么情况算可点击呢？只要调用了 setOnClickListener(), setOnLongClickListener(), setOnContextClickListener() 任意一个方法，即使 xml 布局里设置了不可点击，那对控件来说也是可点击的。如果可点击，就会在 DOWN 事件里执行 onLongClick 回调，在 UP 事件里执行 onClick 回调。
像我们上面这样的代码，就会在 btn2 的 UP 事件触发回调。
实现思路
思路 1
不给 btn2 设置点击事件监听了，并且 xml 布局里配置 clickable 为 false（上面说可点击有 3 种配置，我也在 xml 试过都设置成 false，但是和只设置一种效果一样）。
这样子点击 btn2 肯定不会消费了，果然 btn1 的 log 打印了出来，但是神奇的是 btn1 好像显示在了 btn2 的上面（难道这位置还会变？后面就都展示 btn1 了，除非销毁页面重来，这个有待研究为啥会这样）思路 2
还是不给 btn2 设置点击事件监听，但 xml 也不配置 clickable 为 false，就默认配置了宽高，文本，另外再附加一个，将背景设置为透明，这样就可以直接看到 btn1 了。按照以前开发时遇到的情况，透明背景会造成事件穿透。
<!--为了好辨识，我稍微改了文本颜色，位置-->
<RelativeLayout
android:layout_width="match_parent"
android:layout_height="100dp">
<Button
android:id="@+id/btn_btn1"
android:layout_width="180dp"
android:layout_height="49dp"
android:text="按钮1"
android:gravity="left"
android:textColor="@color/red"/>
<Button
android:id="@+id/btn_btn2"
android:layout_width="180dp"
android:layout_height="49dp"
android:text="按钮2"
android:gravity="right"
android:background="@color/transparent"/>
</RelativeLayout>
不过经过实验，这个假设不成立，看来是当初的我太菜了，瞎猜的结论吧，好菜哟~。
思路 3
还是不给 btn2 设置点击事件监听，xml 配置也是最普通的，如果这么点击，事件会被 btn2 消费。接着我想能否从事件分发的返回值入手，如果返回 false 不就表示没消费么。那么写个子类继承 Button，替换 btn2 为子类，就叫它 CjButton 吧。这个子类除了构造方法，就重写 onTouchEvent 方法。
这里重写有两种方式，第一种是清空，只写一句 return false，这样实现的效果和「思路 1」是一样的，连那个奇怪的现象都是一样，另一种是执行 super.onTouchEvent(event) 之后 return false。这种也能达到效果，但是 btn2 的背景就一直是暗的（就是点击 button 不放的效果）。
这个思路看着也还行。思路 4
顺着「思路3」看看能不能在 setOnTouchListener 上面做点文章，试了下发现也可以。这个野路子就是，首先给 btn2 设置 Touch 监听，好处在于 1. 可以通过 onTouch() 方法返回值控制事件消费，2. onTouch() 方法比 onClick() 回调方法好的一点在于，事件会传出来。利用这两点，我先让 btn2 通过 onTouch() 方法把事件消费掉（即返回 true，这样 btn2 的 onClick() 方法就不会走了）接着，把事件手动的分发给 btn1，就像这样，
btn2.setOnTouchListener((v, event) ->{
//这个 dispatchTouchEvent 方法是我凑巧发现是 public 的，原本我是想直接调 onClick 方法的
//但好像直接调 onClick 行不通
btn1.dispatchTouchEvent(event);
return true;
});
//这样实现的效果也和「思路1」一样，包括那个神奇的现象
后来我又将返回值改成 false，其他不动，这样子的话，事件会流给 btn2 的 onClick 方法（如果 btn2 设置点击监听的话，这里暂时先不设置）。实验结果是，也达到了效果，并且还没有那个奇怪现象。
再来推理下，既然事件会流给 btn2 的 onClick，那么这个事件会不会被他们同时消费呢？我们把 btn2 的点击监听加回来，实验证明两个 button 的 log 都打印了，但其实有先后，因为在 btn2 的 onTouch() 方法里分发给 btn1 那么 btn1 的 onClick 会先于 btn2 的。
思路 5
野路子可行的话，那我们再上升一层，通过他们的父类，调整事件分发的顺序，看似点击 btn2 但先分给 btn1 这样理论上好像也可行，就是有点赖皮了。思路 6
这个和「思路3」差不多原理，这次我们重写 CjButton 的 dispatchTouchEvent() 方法，从源头就告诉父 View 我不会消费事件的，这样一来事件就流给 btn1 了。最终效果和「思路3」是一致的。
结论
综上所述，我通过原理分析加实验的形式得出 5 种方式来实现题目的要求。大佬们如果有更好的，不吝赐教。
