mupdf不支持直接的多线程.multithread.c我也没看明白,android直接调用多线程就会莫名其妙的事,要么崩溃,要么渲染出的页面不对.
pdfium倒是可以直接多线程.但是解码速度要慢不少.
解码优化
解码优化有好多方面可以做;
队列优化,把当前显示中间的项,优先进行解码.
如果有缩略图,要优化解码.
解码前判断是否可见,因为队列是单线程的,当轮到它解码时,可能页面已经滑动过去
队列优化
这个目前没有处理.排队还是原来的.挨个进行
队列优化的思路:添加新的task到队列,取出来解码时,先处理缩略图的任务.再处理解码node的任务.
如果是这种策略,原来的代码修改就要大变动了,下面的方法是在解码node前处理了缩略图.
需要提供一个算法来处理缩略图优先.然后当前要显示的页面的task优先.如果要处理task的优先级,就要对每一个task进行处理,当前它是在显示区还是不在显示区,但是在显示的page中.
在vudroid里面的解码队列这样处理后,会有一些优化效果.
用recyclerview实现的页面,不需要这么复杂,直接切边,然后解码页面,甚至不需要缩略图,滑动起来效果还是不错的,前提是把额外空间设置一个页面的高度,利用它的预加载能力.
recyelerview已经处理了页面的布局,可见性,回收,预加载等操作,而自定义的view是没有这些的.
缩略图优化
涉及到体验,如果图片未解码,显示的是黑白色,看画布的颜色了.这体验是不好的.
所以优先设置一张缩略图,然后把这图先放上去,每一块解码时,把这些填充上,就会有一个渐变的过程,从模糊到清晰的过程,这种体验比较好.尤其在缩放值比较大的时候.比如放大3倍了.滑动的时候,每一块解码耗时都不小.
设置缩略图.就要先解析缩略图.
所以当node进行解码时,先判断有没有缩略图.没有的话,先解码缩略图.然后放入缓存中,再画出来.在vudroid的page中去画.pagetreenode中的decode,添加进参数.缩略图的key生成一个与page相关的唯一值.
绘制缩略图
protected String getKey() {
return String.format("%s-%s", index, documentView.decodeService);
}
这时的draw就要修改了
public void draw(Canvas canvas) {
if (!isVisible()) {
return;
}
//canvas.drawRect(bounds, fillPaint);
Bitmap thumb = BitmapCache.getInstance().getBitmap(getKey());
Log.d("", String.format("index:%s,%s, %s", index, getKey(), thumb));
if (null != thumb) {
Rect src = new Rect(0, 0, thumb.getWidth()