Android多进程应用之接口可靠性优化

你的AIDL接口是否可靠?

Posted by 夏敏的博客 on September 26, 2017

前言

我们都知道Android可以通过AIDL进行多进程通信, 既然是多进程, 服务方和客户端即不在一个进程里面,那么在调用方调用的时候服务方可能挂掉了.

什么?你的服务端代码稳定的很,就是不会挂. 那么用户去正在运行程序里面发现你有两个进程,手动干掉了你的服务端怎么办.

你的服务端程序是动态服务的, 在某种情况下有重启的需求, 即干掉自己重新初始化你怎么办.

我们知道AIDL调用时, ServiceConnection类里面有onServiceDisconnectedonServiceConnected方法, 在Disconnect时候会回调告诉我们.

同时,AIDL提供的接口有mService.asBinder().linkToDeath(mDeathRecipient, 0);这种linkToDeath的方法提供,在远程进程死亡时会告诉我们.

这么看好像问题是解决了. 那么调用方调用的时候是这么调用的么?

  1. bindservice
  2. onServiceConnected回调,然后调用自己想要调用的接口

很显然不可能,调用方不可能每次调用都去绑定服务, 正常我们会把服务的调用封装一个类, 这个类只需要初始化一次, 之后调用这个类的方法, 这个类再去调用服务.在这里暂且称之这个类为: MyServiceApiManager.

问题在于,这个类只初始化一次,也就是在构造函数时进行绑定服务,之后调用就行了.

那么在服务断开的时候, 这个类负责重连.我们都知道, 连接服务是异步的, 若在重连时,或者说服务需要停掉10秒,10秒后重连, 此时发生了外部调动, 即有程序调用了mMyServiceApiManager.A(int a, String b)方法.

可以思考一下,会发生什么?

我们的程序里,肯定会判断服务是否已经连接上,这个A方法的调用肯定会失败,因为服务还未连上.

现在我们就想让A方法成功!怎么办?

我们可以把A方法缓存下来,等服务连接上了再进行执行该方法,甚至说A方法还有回调都没问题?

那么问题来了, 如何缓存一个方法?

如何封装一个方法

其实容易, 我们平时写runnable时候,不就是把我们的方法写在run里面,而runnable是一个对象,可以被缓存. 我们可以山寨这种模式.

我们把所有的方法都封装成一个Action对象.我们知道, 既然都是调用服务的,那么我们的每个方法都需要服务的对像.

     /**
     * the method wapper
     * @param <R>
     */
    private interface Action<R> {
        R run(IMyService service) throws RemoteException;
    }

上面,我们将服务作为一个参数传了进去,而返回值类型使用泛型动态传入.

我们再写一个方法,用于执行Action.

    private <R> R runAction(Action<R> action, R errorResult) {
        ... 对于服务的各种检查
        mService != null啊, mService状态如何.
        ...
        //执行我们的方法
        return action.run(mService);
        ... 各种异常处理
        return errorResult
    }

那么我们之前调用的mMyServiceApiManager.A(int a, String b)该怎么写呢.

    private int A(final int a, final String b){
        return runAction(new Action<Integer>() {
            @Override
            public Integer run(IMyService service) throws RemoteException {
                return service.A(a, b);
            }
        }, -1);
    }

这样我们在调用A方法的时候, 就会走进runAction里面, 在runAction里面进行了一系列检查,若一些检查过不了,比如服务还未连接,可以把action这个参数缓存下来, 放进一个list里面. 等服务连接上了,再调用.比如这样

    private final List<Entry> mFailedList = new ArrayList<Entry>();

    /**
     * the class defined for recorder failed actions
     * @param <R> R: errorCode of Action
     */
    private class Entry<R> {
        Action<R> action;
        R errorResult;

        public Entry(Action<R> action, R error) {
            this.action = action;
            this.errorResult = error;
        }
    }

    // 添加进失败列表
    mFailedList.add(new Entry<R>(action, errorResult));

    //服务连接上时执行失败动作
    onServiceConnected(...){
        ...
        if (mFailedList.size() > 0) {
            Iterator<Entry> it = mFailedList.iterator();
            while (it.hasNext()) {
                Entry entry = it.next();
                runAction(entry.action, entry.errorResult);
                it.remove();
            }
        }
        ...
    }

总结

其实这样写的话,可以把很多重复的检查放到一起写, 简便了很多.虽然看上去好像是繁琐了很多,但是这种集中化处理的方式,对于需要检查的资源很多的情况或者需要统一操作的情况是很有效的.

作者:Anderson大码渣,欢迎关注我的简书: Anderson大码渣