建议给组件添加destroy API和ID3解析 API

[janryWang]

destroy接口对于SAP应用来说非常重要，视图切换后如果没有销毁组件，内存占用会非常大
ID3解析，如果是自己用第三方库来做的话，它们每次都需要发两个请求才能真正解析出数据，这明显可以在内核级别扩展出来的功能哦，就没必要浪费请求了

[hustKiwi]

现在初始化 MuPlayer 是单实例，一般而言，即便是SAP应用，只要合理的控制页面渲染，比如留好页面内容的占位，每次切换页面只是更改占位中的DOM，这样按说不会影响到 muplayer。MuPlayer在初始化时，会默认把audio和swf的容器放在body内容的最后。因此，即便是SAP，只要合理规划，MuPlayer并不需要初始化后被销毁的情况，也不会存在内容泄露问题。可以用手机访问一下我们百度音乐的webapp：http://music.baidu.com/ ，看一下我们的处理方式。

不过我可以加一个 destroy 方法，但不保证达到你说的销毁内存的效果。据我所知，在前端，内存的销毁需满足三点：1. 对应的dom节点被移除 2. 绑在该实例上的事件全部被解绑 3. 该实例没有被赋值到其他全局变量上。

即便全部做到，也不一定保证立即触发内存回收机制。反而往往因为使用方的误用，例如，混乱的事件绑定，或全局变量使用，会导致内存无法被回收。因此，我会提供一个destroy方法做dom销毁及muplayer示例上的事件解绑，除此之外，是否真能被完美回收，也依赖调用方的使用。

关于ID3，我个人觉得依赖ID3存储歌曲的元信息不一定是一个产品级的解决方案，即便用，最好根据音频构建自己的曲库资源，讲解析放在后端通过API提供。如有需要，后面会以插件形式提供一个ID3解析的方式，不过估计优先级不高。年前我还有一周就休假了，还有别的事情要处理，不一定有时间去实现。后面会考虑提供一下，如果你比较熟悉，也欢迎提交 pull request

[janryWang]

对，其实我需要也就是dom销毁和事件解绑，这样已经够了，完美回收内存的确得看使用者，当然，对于id3这块的话，如果要给大家做插件的话，只需要留出可以访问buffer数据的接口就行了

[hustKiwi]

@janryWang 如之上讨论，添加了destroy方法（清理dom并解绑事件），但没有做详细的内存占用的测试，你如果使用时可以帮忙测测看。
注意，如果将player实例绑在其他全局变量上，在调用destroy方法后，须将player delete掉或赋值为null。这些应该业务端自己保证。另外ID3解析，我单独开了个issue：#77 ，之后会考虑提供。我下周就休年假了，估计得3月份回来再实现了。

[janryWang]

好的，没问题，谢谢了哈