默默的点滴

1. 普通WebView如何截取长图
2. 针对X5内核中WebView如何截取长图

日常开发中，遇到为WebView截取长图算是一种常见的需求。网上聪明的程序员们提供了多种截取WebView长图的方法，这为我们的开发提供了很多便利。现在，也有很多APP是集成了X5内核的，网上对于X5内核的截长图方案介绍比较少，所以这里我整理了对WebView截取长图的比较通用可行的方法，并且对使用了x5内核的WebView的截图方法进行分享。

普通WebView截长图方案

普通WebView截取长图，这里是指项目中没有集成X5内核的情况。利用Google文档上的api可以顺利截图。以Android5.0为版本分界线，截图采用不同的处理方式。

1. Android5.0以下版本

2. Android5.0及以上版本

在Android5.0及以上版本，Android对WebView进行了优化，为了减少内存使用和提高性能，使用WebView加载网页时只绘制显示部分。如果我们不做处理，仍然使用上述代码截图的话，就会出现只截到屏幕内显示的WebView内容，其它部分是空白的情况。
这时候，我们通过调用WebView.enableSlowWholeDocumentDraw()方法可以关闭这种优化，但要注意的是，该方法需要在WebView实例被创建前就要调用，否则没有效果。

另外这个方法一旦开启，会影响到整个进程中的WebView实例，并且没有办法关闭。

这个代码的本质是设置了一个全局变量，并且没有提供关闭接口。其真实调用的代码如下：

我们在WebView实例被创建前加入代码：

另外，当应用存在多个进程的时候，比如消息推送进程，LBS定位进程存在的情况下，务必确保只在主进程中初始化这个设置，否则运行时可能报错。

根据Google文档中描述，capturePicture()方法已不鼓励使用，推荐我们通过webView的onDraw(Canvas)去获取图像，所以这里我们去拿到网页的宽高后，就调用webView.draw(Canvas)方法生成webView截图。

X5内核截取长图

使用X5内核截取长图有两种方法，并且都可以不用考虑版本问题，这为我们提供了方便。在X5内核下，如果使用WebView的onDraw(Canvas)方法，会出现或多或少的问题，所以对这个方法弃坑了。以下是两个截图方法：

1. 使用X5内核方法snapshotWholePage(Canvas, boolean, boolean)

在X5内核中提供了一个截取整个WebView界面的方法snapshotWholePage(Canvas, boolean, boolean)，但是这个方法有个缺点，就是不以屏幕上WebView的宽高截图，只是以WebView的contentWidth和contentHeight为宽高截图，所以截出来的图片会不怎么清晰，但作为缩略图效果还是不错了。

2. 使用capturePicture()截取清晰长图

如果想要在X5内核下截到清晰的长图，不能使用snapshotWholePage()，依然可以采用capturePicture()。X5内核下使用capturePicture()进行截图，可以直接拿到WebView的清晰长图，但这是个Deprecated的方法，使用的时候要做好异常处理。

总结

以上是WebView截长图方法的总结和分享，对X5内核的截图也是尝试了多种途径最后找到满意的解决方案。另外，截长图会占用大量内存，容易触发OOM，所以代码中也要注意对OOM的处理。

在使用了X5内核的项目中，使用WebView截取长图的判断逻辑可以是：

目前(2020/08/01)之前版本的X5 SDK，如果编译APK的时候指定targetSdkVersion版本高于 28(Android O)的情况下，调用snapshotWholePage(Canvas, boolean, boolean)可能会无法获取到截图，图片内容全黑。

观察日志发生如下报错：

原因为从API 29(Android P)开始，Google对于某些反射调用私有方法的行为进行了限制，比如动态反射赋值android.graphics.Canvas.java的私有变量mBitmap。这些调用会被抛出异常阻止。

参考链接

---

• android x5webview截长图
• [贝聊科技] WebView截长图解决方案
• 适配Android P之非SDK接口限制的排查方法

For the past decade, AysncTask has been one of the most widely used solutions for writing concurrent code in Android. However, it earned very controversial reputation. On the one hand, AsyncTask powered, and still powers, many Android applications. On the other hand, most professional Android developers openly dislike this API.

All in all, I’d say that Android community has love-hate relationship with AsyncTask. But there are big news: the era of AsyncTask is about to end because a commit that deprecated it had just landed in Android Open Source Project.

In this post I’ll review the official statement motivating AsyncTask’s deprecation, as well as the real reasons why it had to be deprecated. As you’ll see, these are different sets of reasons. In addition, towards the end of this article, I’ll share my thoughts on the future of Android’s concurrency APIs.

Official Reason for Deprecation of AsyncTask

The official deprecation of AsyncTask, as well as the motivation for that decision, were introduced with this commit. The newly added first paragraph of Javadoc states:

AsyncTask was intended to enable proper and easy use of the UI thread. However, the most common use case was for integrating into UI, and that would cause Context leaks, missed callbacks, or crashes on configuration changes. It also has inconsistent behavior on different versions of the platform, swallows exceptions from doInBackground, and does not provide much utility over using Executors directly.

While that’s the official statement by Google, there are several inaccuracies there which are worth pointing out.

Fist of all, AsyncTask has never been intended to “enable proper and easy use of the UI thread”. It was intended to offload long-running operations from UI thread to background threads, and then deliver the results of these operations back to UI thread. I know, I’m nitpicking here. However, in my opinion, when Google deprecates API that they themselves invented and promoted for years, it would be more respectful towards developers who use this API today, and will continue to use for years to come, to invest more effort into deprecation message to prevent further confusion.

That said, the more interesting part of this deprecation message is this: “that would cause Context leaks, missed callbacks, or crashes on configuration changes”. So, Google basically states that the most common use case for AsyncTask automatically results in very serious problems. However, there are many high-quality applications out there which use AsyncTask and work flawlessly. Even some classes inside AOSP itself use AsyncTask. How comes they don’t experience these problems?

To answer this question, let’s discuss the relationship between AsyncTask and memory leaks in details.

继续阅读AsyncTask is Deprecated, Now What?

The way your web content behaves on mobile can be dramatically different from the desktop experience. Remote debugging with Chrome DevTools lets you

继续阅读通过Chrome浏览器进行Android调试/Remote Debugging on Android with Chrome