做视频点播的同学用这个框架话要注意啦，这个框架是先缓存后播，而不是边播边缓存！

这个框架的原理是：将网络视频的url传给这个框架，框架返还给播放器一个file类型的uri，然后由框架直接开线程进行网络下载，播放器间接的去读取框架下载到本地的数据进行播放。
这样就会有一个很严重的问题：**播放器无法控制缓冲进度！**
例如，一个视频有200M，用户只看了四分之一，假设是50M，目前市面上的播放器大都有设置缓冲进度的功能，这样一来，设置将无效，框架仍然会将完整的200M视频全量下载，用户将耗费大量的数据流量，因为播放器设置的最大缓冲进度是播放器从本地读取的最大缓冲进度，而不是网络下载的进度。
Here's the above content translated automatically with Google Translate，maybe not very accurate, but still worth a look
Title : Friends who do video on demand should pay attention to this framework. This framework is caching first and then playing, not caching while playing!
The principle of this framework is: pass the URL of the network video to this framework, the framework returns a file type uri to the player, and then the framework directly opens the thread for network download, and the player indirectly reads the data downloaded by the framework to the local data Play.
There will be a serious problem: **The player cannot control the buffering progress!**
For example, a video has 200M, and the user only sees a quarter. Assuming it is 50M, most players on the market currently have a function to set the buffering progress. In this way, the setting will be invalid, and the frame will still complete the 200M video. For full downloads, users will consume a lot of data traffic, because the maximum buffering progress set by the player is the maximum buffering progress that the player reads locally, not the progress of the network download.

报告中没有指定文件、测试或入口点。调查 framework 如何下载所提供的 URL 并公开本地文件 URI；应通过由 player 控制的缓冲来证明已完成，同时不得发生非预期的完整下载。

由索引模型根据 Issue 内容生成。