记录智学汇APP需要优化的地方
1.卡顿 丢帧
android不如ios流畅 因为在ios中ui渲染具有优先等级，而android不一样
需要优化几点:
- 编码中ui线程耗时操作尽量避免
- 布局尽量用最新的布局 有利于渲染 否则复杂布局无法在16ms内完成渲染 16ms是因为android运行流畅需要满足运行60帧/s 每帧的处理时间就不能超过16ms
- 同一时间动画执行次数过多 导致cpu或者gpu负载过重
- View过度绘制，导致一些像素在同一帧时间内被绘制多次，从而使cpu或者GPU负载过重
- 还有View频繁的触发的measure、layout 导致频繁重新计算重新渲染
- 内存频繁触发GC过多 同一帧中频繁创建内存，导致线程阻塞
- 冗余资源和逻辑 导致加载或者执行缓慢
2.播放视频 播放加载慢 播放器占用CPU内存过高
因为项目视频都是自己做的mp4格式 都存储在阿里 所以可以优化的地方例如：
- 复用 因为视频资源都在阿里，视频的域名都是相同的，这些链接都是可以复用的，网络建连的时间需要30ms到200ms不等，复用链接，这部分的时间是可以节省下来的。
- 预加载
播放器实例持有的数据非常大，player初始化的时候会初始化MediaCodec，MediaCodec对应底层的AVCodec，操作底层的/dev/codec-node，Android系统规定了系统最大持有的MediaCodec实例是16个，当然每个手机会有所不同，但总的来说不会有大的不同，就是MediaCodec的实例个数是有限的，不可能无限创建实例。
我们预加载多个播放器实例的时候，就会创建多个codec实例，超过codec实现限制，系统codec就无法正常工作，极易造成OOM或者ANR。
我们再平时解决问题的时候经常发现media.codec进程导致SystemServer卡死的。一般都是media.codec使用不当造成的。
那现在能否预加载不起播放器实例？本地代理可以实现将播放器的网络模块独立出来
我们预加载的目的是为了请求视频资源，其实只需要网路模块就可以的
- 播放器不直接和视频源服务器交互，中间通过本地代理层交互。
- 本地代理层的网络加载模块是独立于播放器的，可以是播放器发起请求，也可以是其他的外部调用发起请求。
- 最终setDataSource到播放器的url是一个http://127.0.0.1:port的请求，本地代理层会通过Socket向这个url中发送数据，播放器可以直接解析数据流。跟正常的播放流程完全一样。
这样我们可以全局持有一个播放器实例：既可以做到预加载，而且可以解决播放器占用资源过多的问题。一举多得。
- 指定MP4格式 H264的视频编码 音频AAC的音频编码 那播放器直接使用特定的封装格式去嗅探，直接起特定的解码器去解码，这样我们可以节省嗅探和MediaCodec检索的时间。
