写在前面:
说来阅读android源码也有一段时间了，虽然经历了很多痛苦，但是学习android这种极具艺术性的编程方法还是很快乐的，特别是当对于某个难点理解的时候，那种恍然大悟的感觉是非常美妙的。
由于最近项目主要关注的是android WifiDisplay这一块，所以在之后的一系列博客中将对 android 的 WifiDisplay技术进行一定的分析（包括对源码的分析和自己所了解到的关于WifiDisplay的一些知识），希望和大家一起探讨。
相关技术介绍
WifiDisplay是WIFI联盟推出的一种致力于解决设备之间通过无线技术共享屏幕的技术，在andorid 系统上对该技术的支持便叫做 android WifiDisplay (很多研究android中的WifiDisplay的都这么叫，不知道官方是不是这么叫得)。
与该技术有相同功效因此也形成竞争关系的有 Apple的 Airplay 和 google 的另一项非常受欢迎的技术chromeCast（由次可以看出google的布局确实是非常广的，同时从android平台和chrome平台（尽管chromeCast可以在android 的app层面提供对屏幕投送的支持，但鉴于其在app层面支持的不玩善性（需要针对google cast API 重新开发app）所以在这里把chromeCast 归入chrome平台）布局来占领多屏互动这一块）。当然上面列出的是当前比较流行的多屏互动技术，其共性是效果比较好，但是需要硬件层的支持（虽然airplay在apple TV和iphone直接不需要加入额外的硬件，但相对于一般使用来说apple TV的限制已经算是额外的硬件了）其他还有一些冲软件的实现技术如比较有名的DLNA技术。以为本专题主要分析的使android wifidisplay相关的问题，所以在这里只讨论与其比较相近的airplay和chromecast技术。
三种技术的对比
对于wifidisplay、airplay 以及chromecast 这三种技术，简单的说哪种技术好，哪种技术差是不妥的。在这里只简单的谈一谈我认识的wifiDisplay的优势。
1、相对与airplay的完全闭源与chromecast这种半闭源（其实也可以说是闭源，首先其接收端的chromecast toggle的技术细节是无法探之的，其次在source端的浏览器插件开发或者是android\iphone app开发都是在google提供的google cast API接口层进行的，可供开发者探索和折腾的空间有限），wifiDisplay这种完全开源（也是本专题实现的基础）的特点是开发这所钟情的;
2、相对与airplay与chromecast发送端（source）和接收端(sink）需要同时介入本地局域网的特点来说，wifiDisplay利用wifiP2p而实现完全自己创建网络的这种自给自足的特点也是用户所喜欢的;
3、相对与airplay 这种构建于iphone以及apple TV这种高端设备之上的奢华格调以及chromeCast这种只能用在chrome浏览器以及有限的部分app上的不完善性，wifiDisplay这种普罗万象的特性（比较新的android手机+普通的支持高清接口的电视+智能盒子）显然是用户更喜欢的。
关于android版本的说明
android 对 WifiDisplay技术的支持是从其4.2版本开始的，在该版本中android对Source端和Sink端都提供了framework级的支持，但是对Source端的支持明显要更近一步，提供了JAVA层实现的完整支持，而Sink端则只是提供了framework层的实现，没有提供JAVA层的实现，需要开发者自己调用framework层的api来实现。
随着andoird版本从4.2到4.3再到5.0我们会发现其对于JAVA层的Source端的代码重构是比较大的，而framework层的代码逻辑则变更很小；而对与Sink端仅有的framework层代码google采取了逐渐将其从源码中剔除的策略，从4.3开始的每个版本其都对Sink端的代码进行了削减，以至于到了5.0之后完全将Sink端从android的代码中踢了出去（好残暴啊！！！）。虽然关于google为什么将Sink端代码从其源码中剔除出去的战略性意义现在还没看明白（想来这种巨无霸公司做这样的决定，一定是有其深层次道理的），但是google在其代码中重Source轻Sink的策略确实是一直从在的，自己认为应该是其对WifiDisplay这种技术定位于手机端与TV端的通信场景所致。
