WebView 性能和用户体验优化

回顾系统 WebView 进化史

• 从Android4.4系统开始，Chromium内核取代了Webkit内核。
• 从Android5.0系统开始，WebView移植成了一个独立的apk，可以不依赖系统而独立存在和更新。
• 从Android7.0 系统开始，如果用户手机里安装了 Chrome ， 系统优先选择 Chrome 为应用提供 WebView 渲染。
• 从Android8.0系统开始，默认开启WebView多进程模式，即WebView运行在独立的沙盒进程中。

随着技术的发展 ， Google 推出了 PWA Web 形态App ，微信推出小程序 ，Facebook 推出 React ， 前端变得越来越广泛（复杂的前端环境） ， 所以移动端的 Web 性能变得越来越重要 ， 虽然随着 Google 不断的对 WebView 内核升级 ， 性能也跟上了脚步 ，但是在移动端还是有很多方面值得我们去优化 。

内核初始化

第一次打开 Web 页面 ， 使用 WebView 加载页面的时候特别慢 ，第二次打开就能明显的感觉到速度有提升 ，为什么 ？ 是因为在你第一次加载页面的时候 WebView 内核并没有初始化 ， 所以在第一次加载页面的时候需要耗时去初始化 WebView 内核 。提前初始化 WebView 内核 ，例如如下把它放到了 Application 里面去初始化 , 在页面里可以直接使用该 WebView

public class App extends Application {

    private WebView mWebView ;
    @Override
    public void onCreate() {
        super.onCreate();
        mWebView = new WebView(new MutableContextWrapper(this));
        
    }

}

复用 WebView

复用思想在移动端是一种很重要的思想 ， 像 ListView ，RecyclerView 复用子View 一样 ， 大大提高了性能和节俭内存 ， 如果你大量使用 WebView 那么我建议你可以考虑一下复用 WebView ， 如果你的应用只是在某些页面使用了 WebView 那么我建议你放弃复用 WebView ， 因为复用 WebView 并不会给你带来多大的性能提升而且会带来一些问题 ，而且在内存吃紧移动端 ，内存显得特别珍贵 ， 下面给出一些测试代码和数据。

验证复用 WebView 和提前初始化 WebView 必要性

private void testWebViewInitUsedTime(){
        long p = System.currentTimeMillis();
        WebView mWebView = new WebView(this);
        long n = System.currentTimeMillis();
        Log.i("Info", "testWebViewFirstInit use time:" + (n-p));
    }

 testWebViewInitUsedTime();
 testWebViewInitUsedTime();

//测试环境 Android 7.0  三星S7
testWebViewFirstInit use time:182
testWebViewFirstInit use time:4

上面是测试 WebView 初始耗时的一些代码 , 可以看出第一次提前初始化还是很有必要的 ， 第二初始化只耗时 4 毫秒 , 也就是说一般情况创建一个 WebView 只需要4毫秒 ，如果单纯几个页面是复用 WebView 这种优化意义不大 ， 因为稍微处理不妥当就会出现泄漏 。

下面给出复用 WebView 的一些关键代码

public class WebPools {


    private final Queue<WebView> mWebViews;

    private Object lock = new Object();
    private static WebPools mWebPools = null;

    private static final AtomicReference<WebPools> mAtomicReference = new AtomicReference<>();
    private static final String TAG=WebPools.class.getSimpleName();

    private WebPools() {
        mWebViews = new LinkedBlockingQueue<>();
    }


    public static WebPools getInstance() {

        for (; ; ) {
            if (mWebPools != null)
                return mWebPools;
            if (mAtomicReference.compareAndSet(null, new WebPools()))
                return mWebPools=mAtomicReference.get();

        }
    }


    public void recycle(WebView webView) {
        recycleInternal(webView);
    }



    public WebView acquireWebView(Activity activity) {
        return acquireWebViewInternal(activity);
    }

    private WebView acquireWebViewInternal(Activity activity) {

        WebView mWebView = mWebViews.poll();

        LogUtils.i(TAG,"acquireWebViewInternal  webview:"+mWebView);
        if (mWebView == null) {
            synchronized (lock) {
                return new WebView(new MutableContextWrapper(activity));
            }
        } else {
            MutableContextWrapper mMutableContextWrapper = (MutableContextWrapper) mWebView.getContext();
            mMutableContextWrapper.setBaseContext(activity);
            return mWebView;
        }
    }



    private void recycleInternal(WebView webView) {
        try {

            if (webView.getContext() instanceof MutableContextWrapper) {

                MutableContextWrapper mContext = (MutableContextWrapper) webView.getContext();
                mContext.setBaseContext(mContext.getApplicationContext());
                LogUtils.i(TAG,"enqueue  webview:"+webView);
                mWebViews.offer(webView);
            }
            if(webView.getContext() instanceof  Activity){
//            throw new RuntimeException("leaked");
                LogUtils.i(TAG,"Abandon this webview  ， It will cause leak if enqueue !");
            }

        }catch (Exception e){
            e.printStackTrace();
        }


    }

}

注意在 WebView 进入 WebPools 之前 ， 需要重置 WebView ，包括清空注入 WebView 的注入对象 ， 否则非常容易泄露。

WebView 独立进程 ， 进程预加载 。

因为 WebView 内存泄露 ， 以及多进程内存拓展 ， 相信有一部分开发人员会把 WebView 放在一个独立的进程里面 ， 那么第一次加载 WebView 页面 ，加上系统需要时间 Fork 出新进程 ， 那么加载变得更慢了 ， 因为进程的创建也是一件耗时的事情 ， 所谓的预加载进程 ， 就是提前把进程创建出来 ， 提升加载速度 ,大致的做法如下

        <service
            android:name=".PreWebService"
            android:process=":web"/>
        <activity
            android:name=".WebActivity"
            android:process=":web"
            />

其实不一定要 Service ， 启动「web」 进程 Broadcast 广播也是可以的 ， 提前在进入 WebView 页面之前 ， 先启动 PreWebService 把 「web」 进程创建了 ，当系统在启动 WebActivity 的时候 ， 系统发现了 「web」 进程已经创建存在了 ， 系统就不需要耗费时间 Fork 出新的「web」进程了。

提前显示进度条

提前显示进度条不是提升性能 ， 但是对用户体验来说也是很重要的一点 ， WebView.loadUrl("url") 不会立马就回调 onPageStarted 或者 onProgressChanged 因为在这一时间段 ， WebView 有可能在初始化内核 ， 也有可能在与服务器建立连接 ， 这个时间段容易出现白屏 ， 白屏用户体验是很糟糕的 ， 所以我建议

private void go(String url) {
        this.mWebView.loadUrl(url); 
        this.mIndicator.show() //显示进度条
}

在loadUrl 之后立马就把进度条显示出来 ， 给用户一个明显视觉 。

开启软硬件加速

开启软硬件加速这个性能提升还是很明显的，但是会耗费更大的内存 。

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {
            webView.setLayerType(View.LAYER_TYPE_HARDWARE, null);
} else if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
            webView.setLayerType(View.LAYER_TYPE_HARDWARE, null);
 } else if (Build.VERSION.SDK_INT < Build.VERSION_CODES.KITKAT) {
            webView.setLayerType(View.LAYER_TYPE_SOFTWARE, null);
}

总结

上面提出这些性能优化都不是那么完美无缺的，基本都会带来一部分系统资源的消耗 ， 比如在 Application 里面提前初始化WebView ， 虽然提升了 WebView 页面的启动速度， 但是缺拖慢了 App 的冷启动速度 ，独立进程和开启软硬件加速也都会带来内存更大的开销 ，所以凡事都是存在利和弊，至于在项目中利与弊怎么权衡，都是需要根据用户需求和各种因素来量度的。

最后

留下一个基于 WebView 的强大库的传送门 GitHub 。