RemoteViews 中暗藏的坑

前言

前几天一直在调查一个重启问题，本以为是 fd 泄露导致的，没想到最终发现是 RemoteViews 中的坑导致的。下面我们就以 setImageViewBitmap(int viewId, Bitmap bitmap) 方法为例，讲解一下这个坑。

setImageViewBitmap 中的坑

首先看一下其具体实现：
RemoteViews.java

    /**
     * Equivalent to calling ImageView.setImageBitmap
     *
     * @param viewId The id of the view whose bitmap should change
     * @param bitmap The new Bitmap for the drawable
     */
    public void setImageViewBitmap(int viewId, Bitmap bitmap) {
        setBitmap(viewId, "setImageBitmap", bitmap);
    }

我想大家看到这个 api 的定义，首先就会认为存储 bitmap 的结构是个以 viewId 为 key，bitmap 为 value 的 map list 的形式，调用这个 api 会直接替换掉之前相同 viewId 的 bitmap（毕竟我之前就是这么认为的），但是实际呢？我们沿着其实现继续看下去：

RemoteViews.java

    public void setBitmap(int viewId, String methodName, Bitmap value) {
        addAction(new BitmapReflectionAction(viewId, methodName, value));
    }

    private void addAction(Action a) {
        if (hasLandscapeAndPortraitLayouts()) {
            ...
        }
        if (mActions == null) {
            mActions = new ArrayList<Action>();
        }
        mActions.add(a);

        // update the memory usage stats
        a.updateMemoryUsageEstimate(mMemoryUsageCounter);
    }

从上面可以看到，我们想象中的替换并没有发生，而是新创建了一个 BitmapReflectionAction 对象，并将其添加到了 mActions 这个 ArrayList<Action> 中，我们再来看一下 BitmapReflectionAction 的构造函数：

RemoteViews.java

    private class BitmapReflectionAction extends Action {
        int bitmapId;
        Bitmap bitmap;
        String methodName;

        BitmapReflectionAction(int viewId, String methodName, Bitmap bitmap) {
            this.bitmap = bitmap;
            this.viewId = viewId;
            this.methodName = methodName;
            bitmapId = mBitmapCache.getBitmapId(bitmap);
        }
    }

再看一下 getBitmapId 的实现：

RemoteViews.java

    private static class BitmapCache {
        ArrayList<Bitmap> mBitmaps;

        public BitmapCache() {
            mBitmaps = new ArrayList<Bitmap>();
        }

        public int getBitmapId(Bitmap b) {
            if (b == null) {
                return -1;
            } else {
                if (mBitmaps.contains(b)) {
                    return mBitmaps.indexOf(b);
                } else {
                    mBitmaps.add(b);
                    return (mBitmaps.size() - 1);
                }
            }
        }

        public void writeBitmapsToParcel(Parcel dest, int flags) {
            int count = mBitmaps.size();
            dest.writeInt(count);
            for (int i = 0; i < count; i++) {
                mBitmaps.get(i).writeToParcel(dest, flags);
            }
        }
    }

 可以看到这个方法会返回 bitmap 在 mBitmaps 中的 index，如果 mBitmaps 中不包含此 bitmap，则将其添加进去。
 有的人可能会说没关系啊，只不过多存一点而已啊，显示的时候又不会出问题。但是，请看一下上面的 writeBitmapsToParcel 方法，在跨进程传输的时候，每个 mBitmaps 中的 bitmap 都是要 writeToParcel 的。
 这意谓着如果 bitmap 是通过 writeBlob 这种方式存入 Parcel 对象中的话，那么每个 bitmap 传输都要打开一个 fd，如果 mBitmaps 中 bitmap 数量很多的话，直接有可能导致 app 或者 system_server 挂掉。
 我的另一篇博文 由一份 log 看 Binder 中的异常就是由于这个原因导致的。

 即使没有上面提到的问题，也势必会影响到 app 和系统的性能。因此，开发者在平常开发中一定要注意不要在同一个 RemoteViews 实例中频繁多次地调用 setImageViewBitmap 这类的方法。