AVPlayer 和 MPMoivePlayerController的区别

AVPlayer：

AVPlayer gives you a lot more flexibility but is pretty poorly documented. Using this API will force you to create your own UI. AVFoundation (the framework that brings you AVPlayer) generally is a bit hard on the user (coder) as it forces you to use Key-Value Observing a lot for checking states. The concept of KVO is great, do not get me wrong - still, for unexperienced developers it can be painful to learn. Apple sometimes omits the information on which properties are actually KVO compliant and that will force you to do some experimentation.

One big advantage of AVPlayer over MPMoviePlayerController would for example be its extended version, AVQueuePlayer as that one is able to do gapless playback of multiple movie sources. Another advantage certainly is the feature rich AVFoundation framework allowing you to do things like on-the-fly movie composition / encoding / converting.

Yet another huge advantage of AVPlayer is the fact that you may actually play multiple video sources concurrently (e.g. side by side) without any problem.

MPMoviePlayerController：

MPMoviePlayerController is easy to use and covers most needs out of the box. Using this API will give you a good looking and commonly understood UI. The UI however can be disabled and or replaced with a custom one.

For status changes, MPMoviePlayerController uses a few NSNotifications covering everything the regular App needs.

Under the hood, MPMoviePlayerController builds on top of AVPlayer - but that actually happens entirely transparent to the user - you have no access to that layer while using MPMoviePlayerController.

MPMoviePlayerController uses the underlaying AVPlayer as a singleton instance, hence it is not possible to use multiple instances of MPMoviePlayerController to play videos concurrently.

On the other hand, as soon as you are trying to extend the functionality of MPMoviePlayerController with your own features, code quickly gets nasty - e.g. you will possibly start using multiple timers for covering things like a proper starve-detection (actually, that feature got included into iOS5's version of this class), custom UI updates, ... Or you may end up having more than a handful of state properties trying to cover things like gracefully aborting of the playback while the player is still pre-buffering.