标签 webview 下的文章

最近发现客户端中android4.3上GS4手机上的WebApp应用特别容易crash。分析了源代码之后发现，在ActivityThread中回收内存时会调用EGLImpl里边去，回收RenderThread，进而调用到计算CPU FPS的逻辑，进而crash：

```bash
java.lang.Error: signal 11 (Address not mapped to object) at address 0xbe59dff0 [at libPowerStretch.so:0x2d4c (_ZN11LucidConfig13calcTargetFPSEi+0x1b)]

at system.lib.libPowerStretch_so.0x2d4c(LucidConfig::calcTargetFPS(int):0x1b:0)

at system.lib.libPowerStretch_so.0x2f23(LucidConfig::isLucidActive(bool):0x86:0)
```

因为在问题出在系统层而android应用回收内存这个message是ActivityManager发出，为正常且必要的行为，无法规避。最终选择如下方式将其绕过：

```java
public class H5WebViewRenderPolicy {
public static boolean shouldDisableHardwareRenderInLayer() {
// case 1: samsung GS4 on android 4.3 is know to cause crashes at libPowerStretch.so:0x2d4c
// use GT-I95xx to match more GS4 series devices though GT-I9500 is the typical device
final boolean isSamsungGs4 = android.os.Build.MODEL != null && android.os.Build.MODEL.contains("GT-I95") && android.os.Build.MANUFACTURER != null && android.os.Build.MANUFACTURER.equals("samsung");
final boolean isJbMr2 = Build.VERSION.SDK_INT == Build.VERSION_CODES.JELLY_BEAN_MR2;
if (isSamsungGs4 && isJbMr2) {
return true;
}

return false;
}
}
```
以上定义一个渲染策略类（方便以后维护），针对GS4 + android 4.3这种组合在WebView layer层面关闭硬件加速（这样就不会存在RenderThread，自然也就没法触发上文的crash）。

之后在自定义WebView中利用上以上渲染策略类：

```java
final boolean meetApiLevel11 = Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB;
if (H5WebViewRenderPolicy.shouldDisableHardwareRenderInLayer() && meetApiLevel11) {
final View underlyingWebView = webView.getUnderlyingWebView();
if (underlyingWebView != null && webView.getType().equals(WebViewType.SYSTEM_BUILD_IN)) {
try {
underlyingWebView.setLayerType(View.LAYER_TYPE_SOFTWARE, null);
} catch (Exception globalException) {
globalException.printStackTrace();
}
}
}
```

更新 2015/2/1
-------------------------------------------------------------
该现象表现在多款三星制造的搭载android 4.3系统的手机上，不仅限于GS4

最近踩了一个坑，有个非全屏的dialog遮住我的WebApp容器时，WebApp容器中JS代码操纵dom对象显示文本（input框中）巨慢（俗话描述就是“软键盘中输入了字，但是上屏很慢”）。

debug了一天之后发现。在WebView的onPause方法调用后，其内部JS引擎执行JS代码会慢好几倍。所以是否需要跟随Activity的生命周期调用onPause方法需要根据应用场景来区分：

若是应用中严格依赖JS做一些比较紧要的事情，则不应该onPause WebView。否则应该onPause WebView以释放一部分系统资源。

最近遇到一个应用打开WebApp后，将应用压入后台，出现比较耗电的问题。集合众多同学的智慧之后定位到原因：

在WebKit的内核中会引用从各个平台(android, linux pc, mac)注入的自己的服务比如：

* DeviceOrientationService
* DeviceMotionService

而这两个Service在android平台上的实现皆通过注册侦听器到SensorManager来获知来自于加速度器，磁力计的方位、手机姿势数据。

Sensor的使用是极其浪费电力的一件事情，所以就出现了上文所述问题。

解决方法：

1) 在Activity的onPause(), onResume()时调用WebView.onPause(), WebView.onResume()以尽量将JS执行线程以及其他WebCore中的线程给停住

2) 在onStop()时将WebView中当前load的url记住，然后让WebView.loadUrl("about:blank")，在onStart()时WebView.loadUrl({your_previous_url})

更新：
[2015/11]在最近的工作中还发现一种前端页面带来的耗电问题：当页面加载一些gif或者通过其他方式创建的动画效果，当webview变得不可见后这些动画如果没有被显式关掉，就会导致很严重的耗电问题。同时在桌面浏览器里边我也注意到页面里边持续运行的动画也会导致内存占用增大。

今天由测试同学反映两款手机（红米，三星GS4，均搭载Android 4.2.2）存在WebApp中收到回调后软键盘自动收起。

经过一段时间的研究，发现在Android 4.2.2上WebView.loadUrl()被调用后WebView会认为新的一个页面即将打开，而将软键盘收起。

android填坑之旅还要继续……

源代码如下(以android 4.0.4为例)：

```java
public synchronized String getUserAgentString() {
if (DESKTOP_USERAGENT.equals(mUserAgent) ||
IPHONE_USERAGENT.equals(mUserAgent) ||
!mUseDefaultUserAgent) {
return mUserAgent;
}

boolean doPostSync = false;
synchronized(sLockForLocaleSettings) {
Locale currentLocale = Locale.getDefault();
if (!sLocale.equals(currentLocale)) {
sLocale = currentLocale;
mUserAgent = getCurrentUserAgent();
mAcceptLanguage = getCurrentAcceptLanguage();
doPostSync = true;
}
}
if (doPostSync) {
postSync();
}
return mUserAgent;
}
```
其中后半段代码用于将当前locale设定同步到生成的UA中。所以该方法是有副作用的。

在一个使用了WebView的Activity里实例化完成和系统Configuration改变后都需要调用一次getUserAgentString()来让WebView的UA（前提是不要设置自己的UA，即没有针对此WebView调用过setUserAgentString）中locale分量与系统的设定保持一致。以免在访问多语言网站时出现适配问题。

  1. 1
  2. 2