前言
好久没有写关于技术类型的文章了,很多朋友都催我写写,这也快到年底了,所有抽了点时间写一篇,希望能借此来回馈大家在过去一年中对我的支持。
PS:本文中有3张GIF效果图太大,没办法上传,追求看完美效果的朋友可以摆驾链接:百度网盘 请输入提取码 提取码:xad4 插件高清GIF效果。
需求
今天要分享的技术方案是我在写bg-boom这款插件当中一小块的代码实现方案,先从需求说起吧,其模块整体的需求是丰富idea的背景功能,具体需求为:
效果
以上需求文字理解较为晦涩难懂,就先看看最终的实现效果,感受一下需求最终实现的效果吧:
PS:由于gif太大,在这里我只放了一张网络视频的效果图,要听声音的朋友可以转看,效果更佳: Idea炫酷的视频背景插件Bg-boom_哔哩哔哩_bilibili
现状分析
简单理解以上需求后,总是要撸起袖子干事情的,就先从idea现状对背景的支持开始吧,经过一番源码的阅读操作,最终可以发现idea背景功能支持有些简单,如下:
2021.2.3版本的背景功能截图如下(不同产品和版本可能存在差异):
架构设计
通过对idea现状分析后,可以清晰的得出一个结论就是:要实现自己的需求,那么基本是对背景功能的重新实现。Do it!
第一步:拆分需求功能
先归纳一下在需求描述中对于实现的关键点,是让idea支持图片、gif图片、视频、直播、广播、在线音乐的支持。就这样理解还是不够直观,那就再做一次抽象转换:
经过这次转换我们就可以清楚的发现,需求中提出的功能实际对于idea来说就是单独放图片、单独放声音、同时放图片和声音的需求,是不是顿时简单好理解一大半。
总结:拆分后的需求就是要求idea可以背景播放图片和声音,图片和声音可在一定条件下单独开启。
第二步:架构设计
看到这里,不容易,看会电视先休息一下吧~~
技术选型
以上需求要实现,用到的技术其实并不多,简单介绍一下以上方案的关键技术选型:
技术实现
性能优化
感兴趣代码实现的朋友可以同上述方式,自行领取资料。在这里我主要分享一下实现完成功能之后对代码的优化过程。
01、完成第一版发现问题
功能基本实现完成之后,发现运行效果能达到预期,但是CPU占用非常高,如下图:
02、拆包定位性能消耗点
在com.madou.app.vedio.core和thread包中都有多个实现类,不够直观发现那个类会有问题,因此建立多个包,每个包下只放一个类文件,再次运行:
PS:下图中第一次CPU占406%,第二次占270%,这是由计算机自身的状态产生的偏差,在此忽略。
从下图可以看出:
03、原因分析
先分析com.madou.app.vedio.print包,其下面只有一个用于把Image绘制到Idea背景区域显示的程序,非常简单,貌似此代码的优化空间不太大,先跳过。
private void drawGraphics(Image image, Graphics2D g, Rectangle dstBounds) {
if(image!=null) {
g.drawImage(image,dstBounds.x,dstBounds.y,
Double.valueOf(dstBounds.getWidth()).intValue(),
Double.valueOf(dstBounds.getHeight()).intValue(),null);
}
}
解密帧数据
public byte[] parseToByte(Buffer[] samples) {
if(samples==null){
return null;
}
int k;
buf = samples;
switch(sampleFormat){
case avutil.AV_SAMPLE_FMT_FLTP://平面型左右声道分开。
leftData = (FloatBuffer)buf[0];
TLData = floatToByteValue(leftData,vol);
rightData = (FloatBuffer)buf[1];
TRData = floatToByteValue(rightData,vol);
tl = TLData.array();
tr = TRData.array();
combine = new byte[tl.length+tr.length];
k = 0;
for(int i=0;i<tl.length;i=i+2) {//混合两个声道。
for (int j = 0; j < 2; j++) {
combine[j+4*k] = tl[i + j];
combine[j + 2+4*k] = tr[i + j];
}
k++;
}
return combine;
case avutil.AV_SAMPLE_FMT_S16://非平面型左右声道在一个buffer中。
ILData = (ShortBuffer)buf[0];
TLData = shortToByteValue(ILData,vol);
tl = TLData.array();
return tl;
case avutil.AV_SAMPLE_FMT_FLT://float非平面型
leftData = (FloatBuffer)buf[0];
TLData = floatToByteValue(leftData,vol);
tl = TLData.array();
return tl;
case avutil.AV_SAMPLE_FMT_S16P://平面型左右声道分开
ILData = (ShortBuffer)buf[0];
IRData = (ShortBuffer)buf[1];
TLData = shortToByteValue(ILData,vol);
TRData = shortToByteValue(IRData,vol);
tl = TLData.array();
tr = TRData.array();
combine = new byte[tl.length+tr.length];
k = 0;
for(int i=0;i<tl.length;i=i+2) {
for (int j = 0; j < 2; j++) {
combine[j+4*k] = tl[i + j];
combine[j + 2+4*k] = tr[i + j];
}
k++;
}
return combine;
default:
break;
}
return null;
}
再分析com.madou.app.vedio.audio包,其PlayAudio类主要是用于解密帧数据和播放帧数据、还有检查声卡缓存剩余数据
播放帧数据
public void play(byte[] data) {
if(sourceDataLine!=null&&data!=null){
sourceDataLine.write(data,0,data.length);
}
}
检查声卡剩余播放数据
public boolean shouldLoadVoice(){
if(sourceDataLine!= null&&sourceDataLine.isRunning()){
return sourceDataLine.available()>sourceDataLine.getBufferSize()*9/10;
}
return false;
}
04、声音解码优化
从以上分析可以初步定位到声音解码最有可能引起CPU占用高。因此优先对此优化。那么优化的思路是怎样的呢?大致有以下几种方式:
经过以上分析,从内存上缓存来减少CPU的使用的方案是优先方案,因此先证明一下可行性。
04.1 测试几个视频的声卡数据,看缓存方案是否可行
先提取几个视频的声卡数据,通过大小判断一下是否内存能够缓存存储,于是测试了3个视频,结果如下:
序号 | 视频大小 | 声卡数据大小 |
---|---|---|
1 | 3M | 1.7M |
2 | 122M | 34M |
3 | 6G | 1.8G |
通过上述简单的测试,我们的需求中定位的视频大小在100M以内,声卡在34M左右,一般电脑的内存都能够完全存储,因此内存方案基本可行。但是如果万一有用户弄4K高清视频怎么办呢?上G的声卡数据并不是每个用户都能负担的,因此完全缓存又似乎不可行。
小插曲:比如下面有哥们真用idea真试了试播放了4K高清的007电影,电影文件6.87G,观赏一下效果吧~~~
没错上面放4K高清电影的哥们就是本人,作为一个技术控,绝不容忍IDEA不能放电影做背景,因此必须解决大视频声卡缓存数据的问题。那么怎么解决了,如果声卡数据都缓存,内存不够,不缓存CPU又高。这种情况呀就只能找一个平衡点,依然使用内存缓存声卡数据,但是要设置一个缓存上限,防止大视频声卡数据超出 JVM 堆大小,进而引起GC,GC导致画面卡顿。但是选这个缓存上限应该设置多少呢?每个用户的内存大小不相同,这个上限点不好定义,怎么办?可不可以动态设置内存缓存空间大小呢?答案是可以的。
经过上述纠结后,最终定的方案是依然使用内存缓存声卡数据,并依据空闲内存大小动态设置缓存上限,防止大视频声卡数据超出JVM堆大小,进而引起GC,GC导致画面卡顿。
内存上限计算公式为:动态缓存上限帧数 = JVM 空闲内存大小 / 2 / 每帧音频大小中值
以上公式的基本理解是,把用户电脑中 JVM 一半的空闲空间拿来作为帧数据缓存空间,并除以平均每帧音频大小,即得到总的缓存帧数。
04.2 测试几个视频的每帧音频大小
通过以下粗糙的测试,简单取65KB作为平均每帧音频的大小。
序号 | 视频大小 | 声卡数据大小 | 每帧音频大小 |
---|---|---|---|
1 | 3M | 1.7M | 20KB |
2 | 122M | 34M | 73KB |
3 | 6G | 1.8G | 65KB |
04.3 实现动态音频缓存
明白以上计算公式之后,其实实现就较为简单了,但是在这里一定要提醒一下各位,JAVA中缓存的实现一定要用软引用去实现,以保障在IDEA程序大量使用内存的时候可以有效的释放音频帧的缓存,毕竟IDEA的功能是优先需要去保障的。
/**
* 缓存音频资源,减少CPU资源的消耗
*/
SoftReference<ConcurrentHashMap<Long,PlayFrame>> voiceLocalCache = new SoftReference<ConcurrentHashMap<Long,PlayFrame>>(new ConcurrentHashMap<>());
/**
* 动态计算最大的缓存数量
*/
volatile int maxLocalCache = 0;
/**
* 动态计算最大的缓存数量,在第一次播放完成后,动态调整计算
*/
volatile int avgLocalCache = 0;
04.4 验证第一版本优化思路
下图中标记为3的图片就是优化后的性能,发现CPU有所下降,但是不明显,难道我们搞错了?
05、最终优化
经过对上述声音解码的优化效果并不明显,那么说明程序CPU消耗点并不在此上面。因此继续分析,上面提到的声卡就是写数据,不可能存在性能问题,即使存在也优化不了,所以先跳过,再排查"检查声卡剩余播放数据"的程序,通过日志打印的方式,发现上层「多媒体播放线程」每微妙就会调用"检查声卡剩余播放数据"程序,导致CPU过高。(PS:多媒体播放线程中是一个循环计时程序,每循环一次就检查一次声卡是否还有播放的数据,如果不够,就立即写入新的声卡数据,实现逻辑是正常的)。定位到这个问题之后,其实解决起来就比上述优化简单多了,直接通过休眠线程来减少对"检查声卡剩余播放数据"程序的调用即可,最终优化后成功降下了CPU指标。
结束
经过上述优化,插件性能指标能够基本使用,但是CPU还是占用太高,所以优化会再继续,无止境!有意思的是我和迅雷影音比较过CPU使用率,在播放开始的时候CPU消耗差不多,但是随着播放的时间推移,迅雷影音就会下降一半CPU占用率。这是否得益于迅雷影音使用了硬件加速?怀揣好奇的心态尝试了把java中BufferedImage图片换成了支持硬件加速的VolatileImage图片,发现JAVA中死活都开启不了硬件加速,就等于VolatileImage的性能是无效的,研究了一天,无结果,就先把这个版本先提交了吧!下个版本再来优化~