这篇文章主要说明回调机制是如何运作的，也是由于前段时间在做需求时有用到这个，但是当时自己不太会，上网查了很多也没有找到合适自己看的文章或回答，在自己研究了一段时间后，结合个人实践，试图用一文的内容讲清楚回调到底是什么。
本文一共三个例子，逐渐深入，结合例子末尾处将对回调作出解释。
简单案例1
Button button = (Button) findViewById(R.id.button);
button.setOnClickListener(View.OnClickListener(){
//do something
});
这是一个按钮，实现了View的OnClickListener接口，并重写接口里的方法OnClick，这是什么意思呢？意思是“按钮被点击时，我们会do something“，对吧？这其实就是一个最简单的回调。
简单案例2
println(1)
view.getAnimationOut().setAnimationListener(object : Animation.AnimationListener(){
override fun AnimationIn(animation : Animation){
println(2)
}
override fun AnimationEnd(animation : Animation){
println(3)
}
override fun AnimationRepeat(animation : Animation){
println(4)
}
})
println(5)
这是一个用kotlin写的动画事件的监听，因为笔者正好在做需求时有用到，在回调内外都有println函数用于打印一个数，那么，这五个数的打印顺序将会是什么呢？
不了解回调机制的同学肯定会觉得是12345，为什么？因为代码是从上而下写的嘛，但是我们结合一下上面的简单案例1中的说明“按钮被点击时，我们会do Something”，放到这里来，结合动画，是不是就意味着：
”当AnimationIn，动画进来时，我们do Something“
”当AnimationEnd，动画结束时，我们do Something“
”当AnimationRepeat，动画重复时，我们do Something“
是这样对吧，那么所以现在你觉得执行顺序是什么呢？你是不是还可能觉得顺序是12345，因为动画是先开始，再结束，再重复呢？没有关系，我们先放下疑惑，接着看最后一个例子
简单案例3
class NewsItemPresenter(val view : NewestFragment) {
private var newsItemModel = NewsItemModel()
private var newsList : MutableList<News.DataBean> = ArrayList()
fun refresh(){
asyncRequest(newsItemModel.initRetrofit("http://v.juhe.cn/"))
}
private fun asyncRequest(completeRetrofit : HttpRequest) {
completeRetrofit.call("guoji", 50, 30, 0, "2cb4dfb90827deb9158e0a1f4e4f1e45")
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.subscribe(object : Observer<News> {
override fun onSubscribe(d: Disposable?) {
Log.d("request", "onSubscribe")
}
override fun onNext(news: News?) {
Log.d("request", "onNext")
var newsDataBean : List<News.DataBean>? = news?.result?.data
if (newsDataBean != null) {
for(item in newsDataBean){
newsList.add(item)
}
}
}
override fun onError(e: Throwable?) {
e?.printStackTrace()
}
override fun onComplete() {
}
})
}
fun getNewsList() : List<News.DataBean>{
return newsList
}
}
这里出自笔者现在正在搭的项目，基于okHttp3+Retrofit2+RxJava3+MVP模式搭建，这里简单解释一下，因为不是所有东西我们都需要关注。
开头创建了一个可变list集合newsList，refresh函数不需要关注，我们看asyncRequest函数是基于RxJava的事件流处理，在onNext方法里进行数据的处理，熟悉MVP模式的朋友肯定知道，根据类名也可以推断出来，这是MVP模式里的Presenter层，用于处理View层和Model层的代码耦合，很明显我这里的意图是onNext方法执行结束后，将所有数据add添加进newsList，然后通过最后一个方法getNewsList返回给View层进行数据展示。逻辑上似乎可以，但是真的可以这样吗？
实际上，在这里通过debug，结果是执行getNewsList方法时，newsList的size为0，也就是说，数据根本没有添加进来。
解释
综合我们上面的例子，其实回调机制简述为一句话，就是“某件事情做好了，我们再do Something”。结合一个生活中的例子，我们给朋友A打电话，想问他一个问题，但是A现在在忙自己的事情，于是就会有这样的情况出现：
我：“A，问问你，1+2等于几啊？”
A：“我现在在忙，等我有空了告诉你”
我：“好的，我先挂了”
--------------十分钟后--------------
A：”1+2=3“
我：”噢！好的谢谢你“
这里才是正常的逻辑吧？如果我们的朋友A有事情，那么我们就先挂电话去做自己的事，毕竟之后他会给我们打过来。但这个”之后“是多长时间呢？我们不知道，这个是A决定的，而不是我们。因此我们不可能一直等A，毕竟如果他正在做一件很耗时的事情的话，我们可能会一直等一直等而没有结果。所以回调机制的意义在于哪里呢？其实就在这里，即”当一件事情做好了，我再通知你，你不用一直等我“。
所以我们可以看到，从案例一开始，即使Button的OnClick函数被声明在很靠前的位置，我们可能在其之后做了很多其他UI渲染之类的操作，但是我们会等OnClick函数执行了我们再去渲染吗？不会，这个OnClick函数只是声明在那里，就像我们打电话一样，我们只是打个电话告诉我们的朋友A我有个问题想请教你，但是具体我们什么时候才能得到答案呢？对应着我们的OnClick函数什么时候才能被执行呢？我们不知道，毕竟，需要我们的朋友A回个电话，或者”Click“一下按钮我们才知道。
那么案例二的顺序就应该是1523，4不一定执行。因为即使输出234的代码在输出5的代码上面，我们仍旧不知道它什么时候会执行，我们需要一个Animation来唤醒它，所以1和5必定在234之前执行，4不一定执行是因为，万一这个动画就放一次呢？
案例三其实也是一样的，我们知道RxJava专门用于处理异步操作，里面的四个回调方法同样也是”被触发了才会执行“，我们并不知道具体时机，但总不能让主线程一直空等造成ANR吧？所以我们的主线程会先执行getNewsList，然后再去执行回调，毕竟不能让主线程被卡住。
总结
我自己也是经历了从不懂到懂的过程，这是我自认为可以最简单让大家理解什么是回调以及如何去使用回调的最简单说明，如果大家有什么意见或指正，欢迎评论告诉我。
