这个问题在Android上是个难点。    Android在诞生之初对声音的播放和录音延时并没有非常严格的要求。手机厂商之前也都不在意延时指标，这几年才慢慢有改观。Android最近几年的新版本也一直在逐步改善延时问题，不过各大手机厂有多重视就不得而知了。
    部分K歌软件为了减少延时，也费了不少精力，使用各种越过中间层的方法，直接使用底层音频接口。就目前的现状来说，手机上用的Linux内核并非实时系统，只依赖Android/Linux的现有音频架构，大部分手机还是没法满足麦克实时返送的要求。    
    先来大致看看手机的音频系统（以下为通俗演义，非严谨专业解释，参考需谨慎）:  
     录音   麦克风---模拟音频信号---> 音频编解码器 ---数字音频信号---音频总线 ---> 主CPU ---> 音频驱动 ---> 软件音频系统 ---> 录音APP    
     播放    音乐APP ---> 软件音频系统 ---> 音频驱动 ---> 主CPU ---> 音频总线 ---数字音频信号---音频解码器---> 模拟音频信号---喇叭    从音频编码器到录音APP，以及从音乐APP到音频解码器，中间的每个环节都会有延迟。  
       之前的老版Android手机，无论播放还是录音，延迟都可能达到100ms以上，这个延迟是人可以明显感觉到的。现在最新的Andriod手机，单录音或播放大多也有50毫秒以上的延迟。    
       就题主提到这几个问题分别来聊聊:    实时耳返    实时耳返是把麦克风录到声音及时从喇叭/耳机播放出来，软件开发上最简单的耳返做法是在APP层录音并立即播放，这样会让声音跑完从麦克风到APP再折返会喇叭的整个路程，所有的延时一个不落，累计延时非常大，听到基本上不是耳返的效果，更像是一个人在学你说话。为了尽量减少延时，部分APP会略过Android的软件音频系统，直接使用驱动提供的接口来做耳返，有所改善，但在绝大多数手机上还是有明显滞后，效果很差。可以在音频编解码器之后添加专用音频DSP模块（有的是跟主CPU集成在同一芯片上），不依赖CPU及CPU上的Android/Linux软件系统，直接在进CPU之前就做好混音回放，几乎没有延时，但这种成本高，开发难度较大。 
          录音合成误差    先看看录音合成的过程: 用户点击播放按钮，软件开始播放动作，此时录音动作也同时开始。但由于APP下向下发送了播放数据，要一层层往下走很多环节才能从喇叭出来，这个时差是不确定的，会受到各种因素影响，比如CPU忙不忙，有没有升降频等，这里的不确定不是指延时很长，是指它可能这回K歌是100毫秒，下回是150毫秒，再下回是120毫秒。录音那边也同样存在的不确定延迟。这会导致录音合成时没有确定的基准。如果延迟值始终固定，哪怕他很大也不要紧，合成是减去延迟偏移就好。当然，如果整体延时值很小，这个不确定性也会变小，到一定程度也可忽略。在不可避免的情况下，要解决这个问题，要么让播放录音延迟值固定（Android系统几乎做不到，各个厂家各个型号各个ROM以及系统无时不刻在变的负载），要么加DSP做合成（成本高，难度大）。 
             现在Type C接口的耳麦接口，中间插入了USB转换器件，若不做特别优化，确实会引入可闻的延时，比以往更差。    音频延迟一直是多媒体和即时语音通讯领域研究的重点之一，Android上暂时没有较好的低成本解决方法。    没研究过iPhone的系统，暂不知其实现方式。一方面它有和好的软硬件基础，延迟本就小;另一方面，系统封闭，条件相对单一，各软件处理起来会简单很多。