AndroidVideoCache-视频边播放边缓存的代理策略

视频现状

现在视频播放的需求越来越常见，就和16年上半年的直播一样，似乎不加个视频已经不是个正常的APP了，连微信朋友圈都支持上传小视频，更别谈以视频为本命的一系列APP。
视频方面主要是两块，一个是视频录制，这个已经翻过一篇比较全的文章，再加上google开源的 grafika ，可以在踩坑时减少很多障碍，不过录制这块适配是大问题，需要不断调整。
另一个方面就是视频播放，这方面的轮子比上面录制就多太多了，无论是google（开源良心）的 ExoPlayer，以及b站的 ijkplayer，还是一些其他的，基本上满足了正常的需求。
当然，今天这篇文章这两个并不是主角，在视频播放这种极其容易造成卡顿，跳帧等影响用户体验的需求上，如何优化体验是一件十分重要的事情。一般情况比较正常的就直接播放，一句设置数据源的代码了事。但是要为了用户体验考虑。纵观这些有视频功能的APP，主要分为两类，一种是直接下载然后再播放，比如微信，微信的小视频录制压缩比比较好，一个视频大概几百k，所以比较适合先全量下载，然后再播放的模式，另一种自然就是边播放边缓存，这是比较多的策略，大部分的视频都是比较大的，等全部下完，黄花菜都凉了。

基本原理

既然是采取边播放边缓存的策略，比较逗的方式就是一边正常的给videoview设置数据源，一边开一个线程去下载文件，下完后就可以使用本地缓存了，这个方式是比较逗的，相当于两份网络请求，大大的拖慢了用户体验。所以我们会想如何只有一份请求但是能够操作这些数据边读边写呢，这个就是 AndroidVideoCache 所做的事情。
AndroidVideoCache 通过代理的策略实现一个中间层将我们的网络请求转移到本地实现的代理服务器上，这样我们真正请求的数据就会被代理拿到，这样代理一边向本地写入数据，一边根据我们需要的数据看是读网络数据还是读本地缓存数据再提供给我们，真正做到了数据的复用。
这就和我们使用的抓包软件性质一样，上个原理图更清晰

代理服务器策略

从使用开始

这里在如何使用上直接搬运作者自己的readme。
首先AS用户一行代码在gradle中导包

dependencies {
    compile 'com.danikula:videocache:2.6.4'
}

然后在全局初始化一个本地代理服务器，这里选择在Application的实现类中，至于这个类是干什么的，后面会详细分析

public class App extends Application {

    private HttpProxyCacheServer proxy;

    public static HttpProxyCacheServer getProxy(Context context) {
        App app = (App) context.getApplicationContext();
        return app.proxy == null ? (app.proxy = app.newProxy()) : app.proxy;
    }

    private HttpProxyCacheServer newProxy() {
        return new HttpProxyCacheServer(this);
    }
}

有了代理服务器，我们就可以使用了，把自己的网络视频url用提供的方法替换成另一个URL

@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);

    HttpProxyCacheServer proxy = getProxy();
    String proxyUrl = proxy.getProxyUrl(VIDEO_URL);
    videoView.setVideoPath(proxyUrl);
}

这样就已经可以正常使用了，当然这个库提供了更多的可以自定义的地方，比如缓存的文件最大大小，以及文件个数，缓存采取的是LruCache的方法，对于老文件在达到上限后会自动清理。

private HttpProxyCacheServer newProxy() {
    return new HttpProxyCacheServer.Builder(this)
            .maxCacheSize(1024 * 1024 * 1024)       // 1 Gb for cache
            .build();
}

private HttpProxyCacheServer newProxy() {
    return new HttpProxyCacheServer.Builder(this)
            .maxCacheFilesCount(20)
            .build();
}

除了这个，还有一个就是生成的文件名，默认是使用的MD5方式生成key，考虑到一些业务逻辑，我们也可以继承一个 FileNameGenerator 来实现自己的策略

public class MyFileNameGenerator implements FileNameGenerator {

    // Urls contain mutable parts (parameter 'sessionToken') and stable video's id (parameter 'videoId').
    // e. g. http://example.com?videoId=abcqaz&sessionToken=xyz987
    public String generate(String url) {
        Uri uri = Uri.parse(url);
        String videoId = uri.getQueryParameter("videoId");
        return videoId + ".mp4";
    }
}

...
HttpProxyCacheServer proxy = HttpProxyCacheServer.Builder(context)
    .fileNameGenerator(new MyFileNameGenerator())
    .build()

到这里基本上整个AndroidVideoCache的使用就没什么问题了。

具体分析

知道了怎么使用后，我们继续往下走，看看是怎么实现的，这里就不分析后面的那些LruCache这些缓存策略，生成key之类的逻辑了，和一般的网络请求里的都大同小异，我们直接看这个代码最有含金量的地方。
前面在使用中，全局实例化过一个代理服务器，就先从这里开始

HttpProxyCacheServer.java
    private static final String PROXY_HOST = "127.0.0.1";
    private final Object clientsLock = new Object();
    private final ExecutorService socketProcessor = Executors.newFixedThreadPool(8);
    private final Map<String, HttpProxyCacheServerClients> clientsMap = new ConcurrentHashMap<>();
    private final ServerSocket serverSocket;
    private final int port;
    private final Thread waitConnectionThread;
    private final Config config;
    private final Pinger pinger;

    private HttpProxyCacheServer(Config config) {
        this.config = checkNotNull(config);
        try {
            InetAddress inetAddress = InetAddress.getByName(PROXY_HOST);
            this.serverSocket = new ServerSocket(0, 8, inetAddress);
            this.port = serverSocket.getLocalPort();
            CountDownLatch startSignal = new CountDownLatch(1);
            this.waitConnectionThread = new Thread(new WaitRequestsRunnable(startSignal));
            this.waitConnectionThread.start();
            startSignal.await(); // freeze thread, wait for server starts
            this.pinger = new Pinger(PROXY_HOST, port);
            LOG.info("Proxy cache server started. Is it alive? " + isAlive());
        } catch (IOException | InterruptedException e) {
            socketProcessor.shutdown();
            throw new IllegalStateException("Error starting local proxy server", e);
        }
    }

这个构造函数一眼看过去就很清楚了，参数就是前面那些自定义配置，这里使用的是 127.0.0.1，这个就是localhost的ip也就是本地ip，创建了一个 ServerSocket ，随机分配了一个端口，这里通过 getLocalPort 拿到了这个服务器端口，后面用来通信。
这里出现了一个线程 WaitRequestsRunnable 并且调用了 start 方法，继续跟进去看这个线程

        @Override
        public void run() {
            startSignal.countDown();
            waitForRequest();
        }

信号量主要是为了保证这个run方法先执行，继续看这个 waitForRequest 方法

    private void waitForRequest() {
        try {
            while (!Thread.currentThread().isInterrupted()) {
                Socket socket = serverSocket.accept();
                LOG.debug("Accept new socket " + socket);
                socketProcessor.submit(new SocketProcessorRunnable(socket));
            }
        } catch (IOException e) {
            onError(new ProxyCacheException("Error during waiting connection", e));
        }
    }

好了，到这里服务器socket一套比较清晰了，整理一下就是先构建一个全局的一个本地代理服务器 ServerSocket，指定一个随机端口，然后新开一个线程,在线程的 run 方法里，通过accept() 方法监听这个服务器socket的入站连接，accept() 方法会一直阻塞，直到有一个客户端尝试建立连接。
现在有了服务器，然后就是客户端的socket，先从使用时代理替换url地方开始看

    HttpProxyCacheServer proxy = getProxy();
    String proxyUrl = proxy.getProxyUrl(VIDEO_URL);

这里使用的是HttpProxyCacheServer 中的 getProxyUrl 方法

    public String getProxyUrl(String url, boolean allowCachedFileUri) {
        if (allowCachedFileUri && isCached(url)) {
            File cacheFile = getCacheFile(url);
            touchFileSafely(cacheFile);
            return Uri.fromFile(cacheFile).toString();
        }
        return isAlive() ? appendToProxyUrl(url) : url;
    }

整个策略就是如果本地已经缓存了，就直接那本地地址的Uri，并且touch一下文件，把时间更新后最新，因为后面LruCache是根据文件被访问的时间进行排序的，如果文件没有被缓存那么就会先走一下 isAlive() 方法， 这里会ping一下目标url，确保url是一个有效的，如果用户是通过代理访问的话，就会ping不通，这样就还是原生url，正常情况都会进入这个 appendToProxyUrl 方法里面。

    private String appendToProxyUrl(String url) {
        return String.format(Locale.US, "http://%s:%d/%s", PROXY_HOST, port, ProxyCacheUtils.encode(url));
    }

比较直接，这里拼接出来一个带有127.0.0.1目标地址及端口并携带原url的新地址，这个请求的话就会被我们的服务器socket监听到，也就是前面的accept() 会继续往下走，这里接收到的socket就是我们所请求的客户端socket

 socketProcessor.submit(new SocketProcessorRunnable(socket));

整个socket会被包裹成一个runnable，发配给线程池。这个 runnable 的 run 方法中所做的事情就是调用了一个方法

    private void processSocket(Socket socket) {
        try {
            GetRequest request = GetRequest.read(socket.getInputStream());
            LOG.debug("Request to cache proxy:" + request);
            String url = ProxyCacheUtils.decode(request.uri);
            if (pinger.isPingRequest(url)) {
                pinger.responseToPing(socket);
            } else {
                HttpProxyCacheServerClients clients = getClients(url);
                clients.processRequest(request, socket);
            }
        } catch (SocketException e) {
            // There is no way to determine that client closed connection http://stackoverflow.com/a/10241044/999458
            // So just to prevent log flooding don't log stacktrace
            LOG.debug("Closing socket… Socket is closed by client.");
        } catch (ProxyCacheException | IOException e) {
            onError(new ProxyCacheException("Error processing request", e));
        } finally {
            releaseSocket(socket);
            LOG.debug("Opened connections: " + getClientsCount());
        }
    }

前面ping的过程其实也被会这个socket监听并且走进来这一段，不过这个比较简单，就不分析了，我们直接看里面的 else 框内的代码，这里一个 getClients 就是一个ConcurrentHashMap，重复url返回的是同一个HttpProxyCacheServerClients ，

 HttpProxyCacheServerClients clients = clientsMap.get(url);
            if (clients == null) {
                clients = new HttpProxyCacheServerClients(url, config);
                clientsMap.put(url, clients);
            }
            return clients;

如果是第一次就会根据url构建出一个HttpProxyCacheServerClients并被put到ConcurrentHashMap中，真正的操作都在这个客户端的 processRequest 操作中，并且传递过去一个是request，这是一个GetRequest 对象，是一个url和rangeoffset以及partial的包装类，另一个就是客户端socket。

    public void processRequest(GetRequest request, Socket socket) throws ProxyCacheException, IOException {
        startProcessRequest();
        try {
            clientsCount.incrementAndGet();
            proxyCache.processRequest(request, socket);
        } finally {
            finishProcessRequest();
        }
    }

这里 startProcessRequest 方法会得到一个HttpProxyCache 类

    private synchronized void startProcessRequest() throws ProxyCacheException {
        proxyCache = proxyCache == null ? newHttpProxyCache() : proxyCache;
    }

    private HttpProxyCache newHttpProxyCache() throws ProxyCacheException {
        HttpUrlSource source = new HttpUrlSource(url, config.sourceInfoStorage);
        FileCache cache = new FileCache(config.generateCacheFile(url), config.diskUsage);
        HttpProxyCache httpProxyCache = new HttpProxyCache(source, cache);
        httpProxyCache.registerCacheListener(uiCacheListener);
        return httpProxyCache;
    }

在这里，我们构建一个基于原生url的HttpUrlSource ，这个类负责持有url，并开启HttpURLConnection来获取一个InputStream，这样才能通过这个输入流读数据，同时也创建了一个本地的临时文件，一个以.download结尾的临时文件，这个文件在成功下载完后的 FileCache 类中的 complete 方法中被更名。
我们构建了一个HttpProxyCache 类，也注册了一个CacheListener，这个listener可以用来回调进度。
做完这一切之后，然后这个HttpProxyCache 对象就开始 processRequest ，

    public void processRequest(GetRequest request, Socket socket) throws IOException, ProxyCacheException {
        OutputStream out = new BufferedOutputStream(socket.getOutputStream());
        String responseHeaders = newResponseHeaders(request);
        out.write(responseHeaders.getBytes("UTF-8"));

        long offset = request.rangeOffset;
        if (isUseCache(request)) {
            responseWithCache(out, offset);
        } else {
            responseWithoutCache(out, offset);
        }
    }

这里我们用传过来的那个客户端socket，拿到一个OutputStream输出流，这样我们就能往里面写数据了，如果不用缓存就走常规逻辑，这里我们只看走缓存的行为。

    private void responseWithCache(OutputStream out, long offset) throws ProxyCacheException, IOException {
        byte[] buffer = new byte[DEFAULT_BUFFER_SIZE];
        int readBytes;
        while ((readBytes = read(buffer, offset, buffer.length)) != -1) {
            out.write(buffer, 0, readBytes);
            offset += readBytes;
        }
        out.flush();
    }

构造一个8 * 1024字节的buffer，这里的read方法，实际上是调用的父类ProxyCache的实现

    public int read(byte[] buffer, long offset, int length) throws ProxyCacheException {
        ProxyCacheUtils.assertBuffer(buffer, offset, length);

        while (!cache.isCompleted() && cache.available() < (offset + length) && !stopped) {
            readSourceAsync();
            waitForSourceData();
            checkReadSourceErrorsCount();
        }
        int read = cache.read(buffer, offset, length);
        if (cache.isCompleted() && percentsAvailable != 100) {
            percentsAvailable = 100;
            onCachePercentsAvailableChanged(100);
        }
        return read;
    }

在while循环里面，开启了一个新的线程sourceReaderThread，其中封装了一个SourceReaderRunnable的Runnable，这个异步线程用来给cache，也就是本地文件写数据，同时还更新一下当前的缓存进度

        int sourceAvailable = -1;
        int offset = 0;
        try {
            offset = cache.available();
            source.open(offset);
            sourceAvailable = source.length();
            byte[] buffer = new byte[ProxyCacheUtils.DEFAULT_BUFFER_SIZE];
            int readBytes;
            while ((readBytes = source.read(buffer)) != -1) {
                synchronized (stopLock) {
                    if (isStopped()) {
                        return;
                    }
                    cache.append(buffer, readBytes);
                }
                offset += readBytes;
                notifyNewCacheDataAvailable(offset, sourceAvailable);
            }
            tryComplete();
            onSourceRead();

同时我们的另一个线程也会从cache中去读数据，在缓存结束后同样也会发送一个通知通知自己已经缓存完了，回调由外界控制。
以上差不多就是总体代码，这里我们在请求远程URL时将文件写到本地fileCache中，然后读数据从本地读取，写入到客户端socket里面，服务器Socket主要还是一个代理的作用，从中间拦截掉网络请求，然后实现对socket的读取和写入。

后记

整个分析为了节约篇幅，尽量的是描述一些其中比较重要的片段，源码文件还是比较多的，这里不能详述，对这种代理方式感兴趣的可以在自己详细阅读一下源码，毕竟源码面前，了无秘密。
这个项目用起来有一点问题，是因为如果我们的APP设置了代理，那么这个socket方式拿url就会出问题，因为我们拿到的也是一个代理url，所以在开发时需要考虑代理用户提供兼容性处理。
另外这种本地代理服务器的策略也能为我们提供一些不一样的思路，既然视频可行那么音频文件呢，进而推导到普通的网络请求，json文件。基于这样一套思路，在其基础上甚至能够实现一套离线缓存加载的策略，当然这取决于我们自身的服务器架构，服务端URL策略。

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 159,015评论 4赞 362
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 67,262评论 1赞 292
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 108,727评论 0赞 243
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 43,986评论 0赞 205
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 52,363评论 3赞 287
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 40,610评论 1赞 219
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 31,871评论 2赞 312
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 30,582评论 0赞 198
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 34,297评论 1赞 242
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,551评论 2赞 246
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,053评论 1赞 260
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 28,385评论 2赞 253
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 33,035评论 3赞 236
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,079评论 0赞 8
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,841评论 0赞 195
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 35,648评论 2赞 274
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 35,550评论 2赞 270

推荐阅读更多精彩内容

  • Spring Cloud
    Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的工具（例如配置管理，服务发现，断路器，智...
    卡卡罗2017阅读 134,100评论 18赞 139
  • Android - 收藏集
    Android 自定义View的各种姿势1 Activity的显示之ViewRootImpl详解 Activity...
    passiontim阅读 170,569评论 25赞 707
  • Java Mission Control之使用
    最近在把一个重构完的项目放到beta环境测试时，顺带实践了一下Java Mission Control(简称JMC...
    zcliu阅读 20,741评论 0赞 5