回归能做任何事情。

回归模型大致分为2个阶段，训练阶段和预测阶段， 训练阶段需要对历史确定结果的数据进行反馈训练，使得模型的参数适应当前的输入与预期输出， 预测阶段在完善模型的基础上对新的数据进行模拟输出。这两个阶段对于一个模型都至关重要。

回归模型广泛地应用于机器学习，深度学习，AI，人工智能等领域，在这里我们讲对它的应用进行 深入浅出的学习与探讨。

针对不同的数据(数值型和标称型)，我们一般有两种预测倾向，数值预测，类别预测，这两种预测有某种潜在的关系，可以说，分类是高层次及符合条件下的数量预测，它建立在数量预测的基础上(这个后面的章节会cover到)

这篇文章的研究环境，基于jupiter notebook， 依赖的python包有pydataset, scilearn, pandas, seaborn以及必要的线性代数，统计学及高等数学的知识。 [TOC]

线性回归模型

这是最简单的回归模型，也是最general的机器学习算法，也包含了机器学习与回归模型最朴素和使用的思考方法， 它基于一个朴素的假设：输入和输出之间存在简单的线性关系. \(y = h(\mathbf{x}) = \theta_0 + \theta_1*x_1 + \theta_2*x_1 + ...\theta_n*x_n = \mathbf{\theta}^T\mathbf{x}\) 其中y 是输出的数值,$x_i$ 是输入的数值,x_0 =1, n是输入的特征数量 \(\mathbf{x}=[x_0,x_1...x_n]^T\) \(\mathbf{\theta}=[\theta_0,\theta_1...\theta_n]\)

线性回归算法需要确定$\theta_j$使得平方误差的和最小, 构造损失函数: \(J(\theta)={1 \over 2}\sum_{i=1}^{m}(h_\theta(x^{(i)})-y^{(i)})^2\) 这里简单地给出选用误差函数为平方和的概率证明 首先我们提出了一个符合常理的假设：误差是服从均值为0，的高斯分布 的 \(y^{(i)}=\theta^Tx^{(i)}+\epsilon^{(i)}\) 即 \(\epsilon^{(i)} = y^{(i)}-\theta^Tx^{(i)} \sim N(0, \sigma^2)\) 最大似然估计 \(max { \prod_{i=1}^{m}p(y^{(i)}|x^{(i)}; \theta) } = max{ \prod_{i=1}^{m}} {1 \over {\sqrt{2\pi}\sigma}} e^{- { { ({y^{(i)} - \theta^T x^{(i)} })^2 } \over 2\sigma^2}}\) \(max\,{ log( \prod_{i=1}^{m}p(y^{(i)}|x^{(i)}; \theta) ) } = max\,{mlog({1 \over {\sqrt{2\pi}\sigma}}) - {1 \over 2\sigma^2}\sum_{i=1}^{m}(h_\theta(x^{(i)})-y^{(i)})^2}\) \(\Rightarrow min\,{1 \over 2}\sum_{i=1}^{m}(h_\theta(x^{(i)})-y^{(i)})^2 = min\,{J(\theta)}\)

最小二乘法

对$\mathbf{\theta}$求导得到: \(J'(\theta)=X^T(Y-X\theta)=0\) \(\Rightarrow \theta = (X^TX)^{-1}X^TY\)

梯度下降法

选定learning rate $\alpha$,对 $\mathbf{\theta}$ 的每个分量求偏导去更新$\theta_j$: \(tmp_j=\theta_j-\alpha*{\partial \over \partial\theta_j}J(\theta)\) 其中 \(\mathbf{\theta} = [tmp_0, tmp_1...tmp_n]^T\) \({\partial \over \partial\theta_j}J(\theta)={\partial \over \partial\theta_j}{1 \over 2m}\sum_{i=1}^{m}(\theta_0x_0^{(i)}+...\theta_nx_n^{(i)} - y^{(i)})^2\) \(\Rightarrow {\partial \over \partial\theta_j}J(\theta)={\partial \over \partial\theta_j}{1 \over m}\sum_{i=1}^{m}((h_\theta(x^{(i)}) - y^{(i)})x^{(i)}\) 对于n=1时，$y=mx+b$, python梯度下降代码如下：

def stepGradient(b_current, m_current, points, learningRate):
    b_gradient = 0
    m_gradient = 0
    N = float(len(points))
    for i in range(0, len(points)):
        b_gradient += -(2/N) * (points[i].y - ((m_current*points[i].x) + b_current))
        m_gradient += -(2/N) * points[i].x * (points[i].y - ((m_current * points[i].x) + b_current))
    new_b = b_current - (learningRate * b_gradient)
    new_m = m_current - (learningRate * m_gradient)
    return [new_b, new_m]

重复执行stepGradient后得到$J(\theta)$与执行次数的关系:

下面是sklearn的线性模型的应用:

from sklearn import datasets
from sklearn.cross_validation import cross_val_predict
from sklearn import linear_model
import matplotlib.pyplot as plt

lr = linear_model.LinearRegression()
boston = datasets.load_boston()
y = boston.target

# cross_val_predict returns an array of the same size as `y` where each entry
# is a prediction obtained by cross validated:
predicted = cross_val_predict(lr, boston.data, y, cv=10)

fig, ax = plt.subplots()
ax.scatter(y, predicted)
ax.plot([y.min(), y.max()], [y.min(), y.max()], 'k--', lw=4)
ax.set_xlabel('Measured')
ax.set_ylabel('Predicted')
plt.show()

回归的正则化与特征选择

为了避免过拟合的问题，使模型更general一些，正则化的理念被提了出来，正则化被用来减小单个$\theta_j$的影响,基本原理是在全局损失函数中加入惩罚函数

Elastic net方法

L1(曼哈顿距离)正则化,也叫Ridge regression， 它将$sum_{i=0}^{n}|\theta_i|$ 作为惩罚函数, 它保留一个$\theta_j$而使其他的应变量趋向于0 L2(欧几里得距离)正则化,也叫Lasso regression，它将$sum_{i=0}^{n}|\theta_i|^2$作为惩罚函数, 它使得所有的$\theta_j$依存变量拥有相同的影响

将两者结合后亦即elastic net惩罚，我们的损失函数就成了: \(J(\theta)={1 \over 2}\sum_{i=1}^{m}(h_\theta(x^{(i)})-y^{(i)})^2 + \lambda({\alpha}sum_{j=0}^{n}|\theta_j| + (1-\alpha)sum_{j=1}^{n}|\theta_j|^2)\) 可以看出,$\alpha$是我们对于L1和L2正则化的偏向，$\lambda$代表正则化的程度,然后使用前面提到的正规方程或者梯度下降来求解, 求得正则化后的$\theta_j$

令$\lambda_1=\lambda\alpha$, $\lambda_2=\lambda(1-\alpha)$, 对于给定的数据(X,Y), $\lambda$,$\alpha$ 定义一个数据集$(X^*, Y^*)$.

\({Y_{n+p}}^*=\begin{pmatrix} Y \\ 0 \\ \end{pmatrix}\) 令$\gamma=\lambda_1/\sqrt{(1+\lambda_2)}, \beta^*=\sqrt{(1+\lambda_2)}\beta$, 则： \(||Y-X\theta||^2+\lambda_2\,sum_{j=1}^{p}\theta_j^2+\lambda_1\,sum_{j=1}^{p}|\theta_j| =||Y^*-X^*\theta^*||^2+\gamma\,sum_{j=1}^{p}|\theta_j^*|\) \(\Rightarrow \hat \theta_{(Elastic Net)}={1 \over \sqrt{(1+\lambda_2)}}{\hat \theta^*} = {1 \over \sqrt{(1+\lambda_2)}} arg min{||Y^*-X^*\theta^*||^2 + \gamma\,sum_{j=1}^{p}{|\theta_j^*|}}\) 这便转化为了普通的套索问题

参考： 似然函数 最小二乘法 矩阵，向量求导 极大似然估计 广义线性模型基于Elastic+Net的变量选择方法研究

了解Android的多线程与多进程模型有助于我们对Android app的整个开发模型有更深的理解,这里记录下一些理解与思考.

Android中的线程

对于初学java的人都知道thread的概念，而到了android thread的概念变味了，出现了譬如service, asynctask, intent service, handler thread, async query loader, threadpool executor等纷繁复杂的概念， android对于线程的处理机制如下。

• 主线程
  • 所有Android基础组件均在指定进程的主线程中初始化
  • 所有系统对于基础组件的回调事件均在主线程中分发
    • 组件中的系统回调方法在指定进程的主线程中执行
    • 所有的基础组件不应该在系统回调代码中执行耗时操作
  • 所有不能立即完成的操作都应该被放在非UI线程中执行
    • 线程对象使用标准的java代码来创建
  • Android提供一些方便的类来管理线程:
    • Looper作为ThreadLocal的单例变量用来循环处理消息队列(MessageQueue)
    • Handler提供消息/Runable的发送以及回调操作
    • HandlerThread提供启动拥有Looper线程的简易方法

针对不同的使用场景，在线程，线程池，handler等基础上我们拓展了一些易用的线程处理组件：

Android 中的进程

• 当应用的第一个组件需要被执行时，Android Framework会为此启动一个有单线程(主线程,即UI线程)运行环境的Linux进程
• 当Android系统资源紧缺时会终止一些进程的执行
• 对于特定的Android组件 ，我们可以通过android:process来指定 它运行的进程
  • 每个组件可以运行在它所指定的进程中
  • 一些组件会共享一个进程， 而其他的不在其中
  • 不同application中的组件可以在同一个进程中执行
• 我们可以通过设置的process属性指定应用所有组件的默认运行进程

Android中的rpc

Android进程间通讯实际上可以看做2个进程中的线程消息传递，作为cs架构，其实现依赖binder机制

binder机制解析:

分层示例

进程间通讯binder机制client,server实现代码示例：

git clone https://github.com/marakana/FibonacciBinderDemo.git

参考链接： http://events.linuxfoundation.org/images/stories/slides/abs2013_gargentas.pdf http://www.cubrid.org/blog/dev-platform/binder-communication-mechanism-of-android-processes/

因为我们应用中大量常用view中出现图标概率很大，正常使用拉取图标较多，对图标的流量问题优化的投入产出比会很高,对于图片的选择和使用就尤为重要。 android分段屏幕的物理尺寸如下:

现在有三个物理长宽分别为2寸、3寸, 4 寸， 屏幕密度分别为120dpi、160dpi、240dpi的手机 在这三个屏幕上，将三个手机屏幕的宽分为三等份，则根据dpi的定义， 三个屏幕中每等份分别容纳80px, 160px, 320px 若只有drawable下的图片：则所以在hdpi屏幕上系统会按比例将drawable下的图片扩 大为原来的1.5倍，在ldpi屏幕上系统会按比例将drawable下的图片缩小为原来的0.75倍

Android 中的图片预处理

• 对于图标的处理: *drable-xdpi: Android中对于drawable的定义比较规整，为了更好的适应各种屏幕，我们选择了几种或全部适配范围，其图片大小和像素大小对应关系如下：

Android 寻找icon的过程

在Android2.1以及之后，出现了drawable-ldpi、drawable-mdpi、 drawable-hdpi、drawable-xhdpi、drawable-xxhdpi。在这些文件 下提供的图片大小最好是3:4:6:8:12。程序在不同的屏幕密度下运行时，会 首先去符合当前屏幕密度的文件夹下找对应的资源，如果没有，系统会以最省力为 前提去别的文件夹下找对应的资源并对其进行相应的缩放，如果还没有，就回去默 认的drawable文件夹下找，然后按照Android2.1之前的规则缩放。如果还没有找到， 应用就会报错或者直接crash掉了。

Android中图片的加载

*对于bitmap的加载

On Android2.3.2(API level 10) and lower, the backing pixel data for a bitmap is stored in native memory. It is separate from the bitmap itself, which is stored in the Dalvik heap. The pixel data in native memory is not released in a predictable manaer, potentially causing an application to briefly exceed its memory limits and crash. *As of Android 3.0 (API level 11), the pixel data is stored on the Dalvik heap along with the associated bitmap. 对于bitmap的处理，其canvas的属性有4种，每种占用的内存差别很大 例如在列表中仅用于预览时加载缩略图（thumbnails ） Android中图片有四种属性，分别是：

ImageCache 图片缓存，包含内存和Sdcard缓存 典型的图片加载策略: 根据屏幕需要的宽高选择inSampleSize的值进行decode和load

• 获取insamplesize

  public static int calculateInSampleSize(
  BitmapFactory.Options options, int reqWidth, int reqHeight) {
  // Raw height and width of image
  final int height = options.outHeight;
  final int width = options.outWidth;
  int inSampleSize = 1;
  if (height > reqHeight || width > reqWidth) {
  final int halfHeight = height / 2;
  final int halfWidth = width / 2;
  // Calculate the largest inSampleSize value that is a power of 2 and keeps both
  // height and width larger than the requested height and width.
  while ((halfHeight / inSampleSize) >= reqHeight
  && (halfWidth / inSampleSize) >= reqWidth) {
  inSampleSize *= 2;
  }
  }
  return inSampleSize;
  }
  

• Decodebitmap

  public static Bitmap decodeSampledBitmapFromResource(Resources res, int resId,
  int reqWidth, int reqHeight) {
  // First decode with inJustDecodeBounds=true to check dimensions
  final BitmapFactory.Options options = new BitmapFactory.Options();
  options.inJustDecodeBounds = true;
  BitmapFactory.decodeResource(res, resId, options);
  // Calculate inSampleSize
  options.inSampleSize = calculateInSampleSize(options, reqWidth, reqHeight);
  // Decode bitmap with inSampleSize set
  options.inJustDecodeBounds = false;
  return BitmapFactory.decodeResource(res, resId, options);
  }
  

  参考链接: http://iconhandbook.co.uk/reference/chart/android/ http://mtc.baidu.com/academy/detail/article/105 https://developer.android.com/guide/practices/screens_support.html

在android开发中，由于程序员的疏忽，对于android framework处理组件对象的声明周期不够了解，导致了一些内存没有释放。

目前Android上处理处理内存问题的方法均是基于强大的hprof文件的分析，包括android studio memory dump, leakcanary和eclipse mat(standalone)工具，本文主要针对通用的hporf分析，这也会适用于leakcanry无法检测的情况.

下面将通过eclipse mat2，adb等工具的配合使用来找到示例工程中内存泄漏所出现问题的地方

内存对象实时监测

• 安装mat示例程序后，为了观察内存中各个对象的使用情况，运行一下命令:

       while true;  do adb shell dumpsys com.example.jefforeilly.mat ; sleep ;        
  

  • 打开应用后，内存使用情况
  • 然后我们正常使用应用（包含2次登录登出，打开主页面，打开fragment，关闭fragment）使用后

内存泄漏分析

android studio memory dump

• 遇到这种内存泄漏问题，我们可以先用android studio2的memoery dump功能查看reference tree,选择打开dominator_tree
  其中activity是我们最关心的组件之一，应为它们占用的内存较大，也更容易发现，按图所示步骤，第图中四步，我们发现viewpropertyanimatorcompat listener没有被释放，这个是我们自己产生的对象，显然有问题。

eclipse mat分析

• 不过，大多数情况，我们创建的对象可能更多，他们的ref 深度也超出我们可以随意查找的范围，这就需要使用更加请更加专业的分析工具Eclipse Memory Analyzer了， 在刚才应用的路径Myapplication/captures下 首先转换android hporf 格式

       hprof-conv com.example.jefforeilly.myapplication_2016.07.22_09.18.hprof converted.hprof 
  

• 转换android vm的hprof格式之后，就可以使用eclipse mat做分析了,

  • 首先搜索任意我们认为应该被回收的对象名称，如这个例子中的MainActivity, 这里发现了5个入口, 为简单处理，我们全选所有对象， 右键选择 merge shorttest paths to gc roots(exclude weak references), 得到距离gc root 更近的节点.

  • 依次展开这些节点， 发现了当前线程函数栈中有animator，也是我们new出的对象，这个Thread就是MainThread, 没有手动释放的animator还在运行, 这就很明确告诉我们对它处理的相关代码有问题了

上面寻找内存泄漏的方法也同样使用于内存优化的过程，如果所有对象和内存能够合理释放，在dominator tree中找到dominator node，看它是否可以释放，如果可以就release掉它，这样由他支配的其他节点也会被回收，如此这样内存便可以持续优化了。

提起android端的webview，它既是天使，又是魔鬼。

在混合型app中它是主角，一切由它呈现，如58同城，赶集网等；在另一些超级app中亦有它的影子，微信，qq，支付宝，没有一个超级app能少了它，既能展示最新最潮的实时资讯，又能扮演盘踞一方的全功能型网站，与native结合后又能扮演诸如公众号之内的应用等等，其能力可想而知。

webview在android端的演化可谓曲折，2015年google宣布不在支持4.4版本一下的webview¹，这意味着目前扔有近四分之一的Android用户因无法获得Google的支持而受到安全威胁。对于深度依赖webview的巨头开始自家的内核及上层sdk以求提升整体稳定性及其性能,腾讯x5内核是比较通用的一种.

目前大致的webview内存处理方式分为两类:

1.独立的web进程，与主进程隔开

这个方法被运用于类似qq，微信这样的超级app中，这也是解决任何webview内存问题屡试不爽的方法 对于封装的webactivity，在manifest.xml中设置

<activity android:name=".webview.WebViewActivity" android:launchMode="singleTop" android:process=":remote" android:screenOrientation="unspecified" />

然后在关闭webactivity时销毁进程

@Overrideprotected void onDestroy() {                
     super.onDestroy(); 
     System.exit(0);
}

关闭浏览器后便销毁整个进程，这样一般95%的情况下不会造成内存泄漏之类的问题，但这就涉及到android进程间通讯，比较不方便处理， 优劣参半，也是可选的一个方案.

2.封装过的webview

相比系统内置的webview的支持自2005年之后就没有了，而首推google的chrome。 腾讯的x5webview对h5的兼容性与稳定性与安全性逐渐凸显出来，并自成一系, 下面以使用x5webview为例做说明:

• 首先使用webview的时候，不在xml里面声明，而是直接代码new个对象，传入application context防止activity引用滥用.

  webView =  new BridgeWebView(getContext().getApplicationContext());
  webFrameLayout.addView(webView, 0);
  

  在使用了这个方式后，基本上90%的webview内存泄漏的问题便得以解决.

• 而在android4.4版本以下，会出现android webview无法自动释放，如在fragment中,使用ondetach的释放webview是比较好的时机[^note-time]

  public void onDetach() {
    releaseWebViews();
    super.onDetach();
  }
  public synchronized void releaseWebViews() {
    if(webView != null) {
        try {
            if(webView.getParent() != null) {
                ((ViewGroup) webView.getParent()).removeView(webView);
            }
  //                if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.JELLY_BEAN_MR2) {
  //this is causing the segfault occasionally below 4.2
            webView.destroy();
    //                }
        }catch (IllegalArgumentException e) {
            DLog.p(e);
        }
        RefWatcher refWatcher = FApplication.getRefWatcher();
        refWatcher.watch(webView);
        webView = null;
    }
  }
  

  其中webview自身的销毁代码如下：

  @Override
  public void destroy()
  //flushMessageQueue();
    clearCache(true);
    clearFormData();
    clearMatches();
    clearSslPreferences();
    clearDisappearingChildren();
    clearHistory();
    //@Deprecated
    //clearView();
    clearAnimation();
    loadUrl("about:blank");
    removeAllViews();
    freeMemory();
    super.destroy();
  }
  

• 如果以上的方案还不管用，实时加入反射来清理webview的引用：

  public void setConfigCallback(WindowManager windowManager) {
    try {
        Field field = WebView.class.getDeclaredField("mWebViewCore");
        field = field.getType().getDeclaredField("mBrowserFrame");
        field = field.getType().getDeclaredField("sConfigCallback");
        field.setAccessible(true);
        Object configCallback = field.get(null);
        if (null == configCallback) {
            return;
        }
        field = field.getType().getDeclaredField("mWindowManager");
        field.setAccessible(true);
        field.set(configCallback, windowManager);
    } catch(Exception e) {
    }
  }
  

  然后在activity中加入

  public void onCreate(BundlesavedInstanceState){
    super.onCreate(savedInstanceState);
    setConfigCallback((WindowManager);
    getApplicationContext().getSystemService(Context.WINDOW_SERVICE));
  }
  publicvoidonDestroy()
  {
    setConfigCallback(null);
    super.onDestroy();
  }
  

• 对于application 级别的可能的misbehaving callbacks，加入

  private static String[] misbehavingClasses = new String[]{
    "com.google.android.gms.ads",
    "com.android.org.chromium.android_webview.AwContents$AwComponentCallbacks",
  };
  public static boolean isMisbehavingCallBacks(String name){
    for(String s : misbehavingClasses){
        if(name.startsWith(s)){
            return true;
        }
    }
    return false;
  }
  

  然后重写applicaiton类记录这些callback, 并在适当的时机删掉：

@Override
public void registerComponentCallbacks(ComponentCallbacks callback) {
    super.registerComponentCallbacks(callback);
    ComponentCallbacksBehavioralAdjustmentToolIcs.INSTANCE.onComponentCallbacksRegistered(callback);
}

@Override
public void unregisterComponentCallbacks(ComponentCallbacks callback) {
    ComponentCallbacksBehavioralAdjustmentToolIcs.INSTANCE.onComponentCallbacksUnregistered(callback);
    super.unregisterComponentCallbacks(callback);
}

public void forceUnregisterComponentCallbacks() {
    ComponentCallbacksBehavioralAdjustmentToolIcs.INSTANCE.unregisterAll(this);
}


private static class ComponentCallbacksBehavioralAdjustmentToolIcs {
    private static final String TAG = "componentCallbacks";
    static ComponentCallbacksBehavioralAdjustmentToolIcs INSTANCE = new ComponentCallbacksBehavioralAdjustmentToolIcs();

    private WeakHashMap<ComponentCallbacks, ApplicationErrorReport.CrashInfo> mCallbacks = new WeakHashMap<>();
    private boolean mSuspended = false;

    public void onComponentCallbacksRegistered(ComponentCallbacks callback) {
        Throwable thr = new Throwable("Callback registered here.");
        ApplicationErrorReport.CrashInfo ci = new ApplicationErrorReport.CrashInfo(thr);

        if (FApplication.DEBUG) DLog.w(TAG, "registerComponentCallbacks: " + callback.getClass().getName(), thr);

        if (!mSuspended) {
            if (BugFix.isMisbehavingCallBacks(callback.getClass().getName())) {
                mCallbacks.put(callback, ci);
            }
            // TODO: other classes may still prove to be problematic?  For now, only watch for .gms.ads, since we know those are misbehaving
        } else {
            if (FApplication.DEBUG) DLog.e(TAG, "ComponentCallbacks was registered while tracking is suspended!");
        }
    }

    public void onComponentCallbacksUnregistered(ComponentCallbacks callback) {
        if (!mSuspended) {
            if (FApplication.DEBUG) {
                DLog.i(TAG, "unregisterComponentCallbacks: " + callback, new Throwable());
            }

            mCallbacks.remove(callback);
        }
    }

    public void unregisterAll(Context context) {
        mSuspended = true;
        for (Map.Entry<ComponentCallbacks, ApplicationErrorReport.CrashInfo> entry : mCallbacks.entrySet()) {
            ComponentCallbacks callback = entry.getKey();
            if (callback == null) continue;

            if (FApplication.DEBUG) {
                DLog.w(TAG, "Forcibly unregistering a misbehaving ComponentCallbacks: " + entry.getKey());
                DLog.w(TAG, entry.getValue().stackTrace);
            }

            try {
                context.unregisterComponentCallbacks(entry.getKey());
            } catch (Exception exc) {
                if (FApplication.DEBUG) DLog.e(TAG, "Unable to unregister ComponentCallbacks", exc);
            }
        }

        mCallbacks.clear();
        mSuspended = false;
    }
}

为方便webactivity的debug

• 在application的oncreate里面，我们加入

  private static void enableStrictMode() {
  StrictMode.ThreadPolicy.Builder threadPolicyBuilder =
    new StrictMode.ThreadPolicy.Builder()
    .detectAll()
    .penaltyLog();
    StrictMode.VmPolicy.Builder vmPolicyBuilder =
    new StrictMode.VmPolicy.Builder()
    .detectAll()
    .penaltyLog();
    threadPolicyBuilder.penaltyFlashScreen();
    vmPolicyBuilder.setClassInstanceLimit(WebActivity.class, 1);
    StrictMode.setThreadPolicy(threadPolicyBuilder.build());
    StrictMode.setVmPolicy(vmPolicyBuilder.build());
  }
  

• 在webview中，对于android4.4以上的版本，我们开启调试模式

  if (FApplication.DEBUG && Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
    WebView.setWebContentsDebuggingEnabled(true);
  }
  

• 最后不可缺少的是, leakcanary的加入来跟踪这些消耗内存的组件: 在webfragment，webactivity，webview ondestory后加上

    RefWatcher refWatcher = FApplication.getRefWatcher();
    refWatcher.watch(obj);
  

总结: 如果你只是简单地用 webview 做呈现, 使用application context启动webview已经足够了，但如果你需要webview来播放视频，处理弹窗等复杂工作, 新建一个进程来处理会更可靠.

](http://www.leiphone.com/news/201501/1NkxWlVGV1IVMUyr.html) [^note-time]:this is how I fixed my WebView leak inside a fragment