前一段时间项目开发遇到一个需求，以最快的速度开启视频播放。
如何做到这一点呢，需要对项目中播放相关的逻辑做整体规划，所有与播放相关的逻辑都要以最快速度开启播放为目标而努力。
措施一：在我们的项目中，播放可能发生在列表中，也可能发生在单个专门为播放所做的页面中，要分情况对待：
在列表中的视频，往往只有视频信息，而没有播放地址，因此，需要在本地对列表播放地址做提前加载，也就是在拉取列表数据之后，还要再拉取各条目的播放地址，当然，为了节省处理性能及网络带宽，多条数据要合并到一个请求中。专门的播放页就简单多了，先拿播放地址，播起来之后再取视频信息即可。
措施二：部分播放地址可能存在有效期的情况，针对该情况，需要在本地做有效期策略，设两个门榏：以有效期的一半时间为触发取新门榏，即有效期超过一半时间，但未达到另一个门榏时，可以使用该地址进行播放，但在播放进行中，要在后台对该地址进行更新。第二个门榏为失效门榏，以有效期的90%时间限定，超过该时间限，则认为播放地址失效，必须先取播放地址，才可进行播放。
措施三：精确定制界面的UI框架，压缩界面层集，在我们的项目实践中，发现RelativeLayout的性能在各容器中是较差的，它的绘制运算onMeasure要执行两次，这样，如果是多层RelativeLayout的话，就会出现指数的增长，五层RelativeLayout会有64次调用，优化方案为少用或不用RelativeLayout，经分析，只需要一个该控件即可达到目的。以此类推，其他界面元素的优化不一一指出，精确控制各界面元素的使用，压缩界面层集可以起到非常好的作用。
措施四：巧用ViewStub进行懒加载，感兴趣的同学可以研究下ViewStub的原理，在此不再展开。合理的理用ViewStub，可以精确定制各界面元素的创建时间，而不是传统的，一窝蜂的堆在onCreate附近，节省下界面初始化时间，用于尽快打开播放，在我们的项目中，除播放的VideoView，其他控件一律在播放之后才绘制，比如：暂停按钮。
措施五：延后网络请求，以列表播放为例，在列表中，我们已经预加载了播放地址，理论上，我们在播放之前只需要两步：
1.装载最基本的界面元素：Activity或Fragment容器及VideoView
2.将播放地址交给VideoView开始播放
期间不应该有网络请求，有一些统计行为也要延后执行。
措施六：有一部分页面用到了ViewPager类的容器盛放播放控件，也要进行策略改进，先加载播放控件，然后再挂载ViewPager，将播放控件放入ViewPager中。
措施七：经过上面的六个方法，我们的应用将开启播放速度由1.5s降到了0.4s，速度已经相当快了，但视觉上还未达到最佳，还需要在视觉上下点功夫：
a.一个Loading优化，做了一个时间门限--2s，如果在2s以下就开启播放，则不再显示Loading，否则将显示Loading（也就是说只有在网络特别差的时候才能看到Loading的那朵菊花）
b.封面图做延时动画消失，可以避免加载的0.4s内画面出现黑色的闪屏（SurfaceView的背景是黑的）
经过上述七项措施，播放开启速度有了质的提升，归纳一下，不外乎三点：
1.不是最必要的，就延后到播放开启后执行
2.最必要的，比如VideoView，要做到效率最优。
3.在视觉上让用户感觉到连贯性