记录一个小坑

1 描述

从 version 26 开始，com.android.support:appcompat-v7 中的 findViewById 方法的返回值从 View 改成了 <T extends View>。

对于开发者来说，喜大普奔的好处当然是以后终于可以不用在每个 finViewById 方法前面加个丑陋的类型强转了。 但是福兮祸兮，好事的背后也难免会有一些不如意的地方。

比如，如果你在用 Kotlin 的话，项目中可能会有很多类似这样的代码：

1
2

// 代码 1 
val textView = findViewById(R.id.textView) as TextView

这是 Kotlin 的习惯写法，种写法实际上是跟下面这种写法是等价的

1
2

// 代码 2
val textView : TextView = findViewById(R.id.textView) as TextView

由于 Kotlin 的类型推导特性，我们可以在声明 textView 变量的时候不必显式说明，系统会自动从后面的赋值语句中推测出它的类型是 TextView 。

但是在 version 26 之后，代码 1 的这种写法就会报错了：

Type inference failed: Not enough information to infer parameter T in
fun findViewById ( id: Int ) : T!
Please specify it explicitly

意思是没有足够的信息来推断 findViewById 的返回类型。

2 原因

上述错误的本质是类型推导的冲突。

如上所说，我们对 textView 的定义并没有说明其类型，它的类型是从后面的赋值语句中推导出来的。
而新版本的 findViewById ，其返回类型是<T extends View>，这是一个泛型的声明，具体类型则是根据所赋值的变量类型来确定的。

—— 等号的左右两边互相依赖，互相还都没有指明，可不就冲突报错了么！

3 解决方案：

既然是因为『两个相互依赖的类行推导都没有指明类型』，那解决方案自然就是选其中一个指明类型咯。

3.1

在等号左边声明类型：

1
2

// 代码 3
val textView : TextView = findViewById(R.id.textView)

3.2

在等号右边表明类型。
诸如这种带泛型签名的函数也是可以在调用时显式地指明类型的：

1
2

// 代码 4
val textView = findViewById<TextView>(R.id.textView)

4 总结

1. 这只是个很简单的小问题，很好解决，但是了解其本质的过程才是更让人享受的过程~

2. 有意思的是：As 默认支持 Kotlin 跟 findViewById 更新这两件事 —— 都是在这次的 IO 大会上宣布的。而且现在（2017.06.05）用 AS 新建一个项目并开启 Kotlin 支持，然后把 support-v7 包升级到 26，就会发现默认的页面就会报这个错 🙈…… 希望 Google 能早日改正~

关于作者 :
http://www.barryzhang.com
https://github.com/barryhappy
http://www.jianshu.com/users/e4607fd59d0d

给定一个指定的正方形的区域，要求在该区域内画一个正N边形（正三角形、正方形、正五边形……）

1
2
3

public static void drawPolygon (RectF rect, Canvas canvas, Paint p, int n) {
    // draw……
}

分析

要用到一些三角函数的知识，于是我画了一幅灵魂画作👻：

分析：

• 计算出每个顶点的坐标，然后把它们连起来，就是一个正多边形啦~
• 圆心角a的度数为360/n，弧度计算为2π/n。
• 如果把圆心的坐标为(0,0)，那么顶点P1的坐标为[X1=cos(a),Y1=sin(a)]。
• 以此类推，顶点Pn坐标为[Xn=cos(a*n),Yn=sin(a*n)]。
• 圆心的实际坐标是外接矩形的中心：[Ox=(rect.right+rect.left)/2 , Oy=(rect.top+rect.bottom)/2]。
• 所以Pn的实际坐标是[Xn+Ox,Yn+Oy]。
• 把P0-P1…Pn连起来就是我们要的结果了。
• Java中可以使用Path来保存路径，最后使用canvas.drawPath来绘制出来。

实现

简化的伪代码：

1
2
3
4
5
6
7
8
9
10
11
12

float a = 2π / n ; // 角度
Path path = new Path();
for( int i = 0; i <= n; i++ ){
    float x = R * cos(a * i); 
    float y = R * sin(a * i);
    if (i = 0){
        path.moveTo(x,y); // 移动到第一个顶点   
    }else{
        path.lineTo(x,y); //    
    }
}
drawPath(path);

Java代码最终的完整代码，可以直接拿去用：

public static void drawPolygon (RectF rect, Canvas canvas, Paint paintByLevel, int number) {
    if(number < 3) {
        return;
    }
    float r = (rect.right - rect.left) / 2;
    float mX = (rect.right + rect.left) / 2;
    float my = (rect.top + rect.bottom) / 2;
    Path path = new Path();
    for (int i = 0; i <= number; i++) {
        // - 0.5 : Turn 90 ° counterclockwise
        float alpha = Double.valueOf(((2f / number) * i - 0.5) * Math.PI).floatValue();
        float nextX = mX + Double.valueOf(r * Math.cos(alpha)).floatValue();
        float nextY = my + Double.valueOf(r * Math.sin(alpha)).floatValue();
        if (i == 0) {
            path.moveTo(nextX, nextY);
        } else {
            path.lineTo(nextX, nextY);
        }
    }
    canvas.drawPath(path, paintByLevel);
}

#DEMO

这个项目里用到了这个函数，可以点进去看以及下载demo。
https://github.com/barryhappy/TContributionsView

Activity、FragmentActivity、Fragment中都有startActivityForResult()方法，也都有用以接收结果的onActivityResult()方法，那他们有什么区别吗？用法上有什么不同吗？

之所以注意到这个问题，是因为最近一次在Fragment中使用了getActivity().startActivityForResult()去调用图片选择器，结果发现在Fragment的onActivityResult无法接收到返回的结果。

仔细研究了一下原因，发现了一些以前没注意到的问题，于是写出来分享给大家。

2. 表现

假设有一个FragmentActivity中嵌套一个Fragment，它们各自使用startActivityForResult发起数据请求。
经测，目标所返回结果数据，能否被它们各自的onActivityResult方法所接收的情况如下：



• Fragment和FragmentActivity都能接收到自己的发起的请求所返回的结果
• FragmentActivity发起的请求，Fragment完全接收不到结果
• Fragment发起的请求，虽然在FragmentActivity中能获取到结果，但是requestCode完全对应不上

为什么会有这种表现呢？往下看。

3. 找原因：Show me your code !

仔细看文档的话，发现了一个以前没注意到的点：FragmentActivity相对于它的父类Activity，对startActivityForResult的描述是有些改动的。

FragmentActivity.startActivityForResult的文档是这样的：

修改了标准行为，以使它能够把结果传递到Fragment。
添加了一个限制：requestCode必须<=0xffff

这里的标准行为，自然指的是正常的Activity.startActivityForResult的功能。而新增加的对requestCode的大小限制看起来很蹊跷，估计是有什么猫腻在里面了。

OK，不卖关子，直接看源码！

3.1 Fragment.startActivityForResult

从Fragment的startActivityForResult开始：

1
2
3
4
5
6

public void startActivityForResult(Intent intent, int requestCode, @Nullable Bundle options) {
    if (mHost == null) {
        throw new IllegalStateException("Fragment " + this + " not attached to Activity");
    }
    mHost.onStartActivityFromFragment(this /*fragment*/, intent, requestCode, options);
}

Fragment.startActivityForResult本身的代码很简单，就是调用了一个mHost.onStartActivityFromFragment的方法。
—— Fragment被添加到一个FragmentActivity中之后，这里的mHost即是当前FragmentActivity的一个内部类FragmentActivity.HostCallbacks，它持有对FragmentActivity的引用，mHost.onStartActivityFromFragment被简单转发到当前FragmentActivity的
startActivityFromFragment()方法。

Fragment.startActivityForResult
↓
FragmentActivitymHost.HostCallbacks.onStartActivityFromFragment
↓
FragmentActivity.startActivityFromFragment

接下来到FragmentActivity.startActivityFromFragment：

3.2 FragmentActivity.startActivityFromFragment

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

public void startActivityFromFragment(Fragment fragment, Intent intent,
        int requestCode, @Nullable Bundle options) {
    mStartedActivityFromFragment = true;
    try {
        if (requestCode == -1) {
            ActivityCompat.startActivityForResult(this, intent, -1, options);
            return;
        }
        if ((requestCode&0xffff0000) != 0) {
            throw new IllegalArgumentException("Can only use lower 16 bits for requestCode");
        }
        int requestIndex = allocateRequestIndex(fragment);
        ActivityCompat.startActivityForResult(
            this, intent, ((requestIndex+1)<<16) + (requestCode&0xffff), options);
    } finally {
        mStartedActivityFromFragment = false;
    }
}

分析一下这段代码：
1，mStartedActivityFromFragment = true首先标记一下请求是来自于Fragment。
2，if(requestCode == 1)的内容不用管，它是来自于startActivity（没有ForResult）的情况。
3，然后的代码添加了对requestCode必须小于0xffff的限制 if((requestCode&0xffff0000) ！= 0){/*抛异常*/}
我们是从Fragment.startActivityForResult追踪到这里的，所以虽然文档没有明确说，但是从这里可以看出：Fragment.startActivityForResult的requestCode也是必须要<=0xffff的。

然后，下面是关键点了：

1
2

ActivityCompat.startActivityForResult(
            this, intent, ((requestIndex+1)<<16) + (requestCode&0xffff), options);

——其中ActivityCompat是一个帮助类，ActivityCompat.startActivityForResult最终还是调用的Activity.startActivityForResult，这个先不表。
这里的关键点就是，通过一个requestCode=>((requestIndex+1)<<16)+(requestCode&0xffff)的映射，Fragment.startActivityForResult最终还是调用了Activity.startActivityForResult。

调用了Activity.startActivityForResult其实是意料之中的事情，只是从requestCode到((requestIndex+1)<<16)+(requestCode&0xffff)是做了什么呢？

通过分析，得知requestIndex是请求的序号，值为从0递增的整数值。
又从前面得知，requestCode的本身的值是小于0xffff的，所以((requestIndex+1)<<16)+(requestCode&0xffff)简化一下就是：(requestIndex+1)*65536+requestCode。
——所以这个值是必定大于0xffff的。

在看一下FragmentActivity.startActivityForResult的代码：

3.3 FragmentActivity.startActivityForResult

1
2
3
4
5
6
7
8
9
10
11

@Override
public void startActivityForResult(Intent intent, int requestCode) {
    // If this was started from a Fragment we've already checked the upper 16 bits were not in
    // use, and then repurposed them for the Fragment's index.
    if (!mStartedActivityFromFragment) {
        if (requestCode != -1 && (requestCode&0xffff0000) != 0) {
            throw new IllegalArgumentException("Can only use lower 16 bits for requestCode");
        }
    }
    super.startActivityForResult(intent, requestCode);
}

可以看到，判断了一下如果请求不是来自于Fragment，也就是来自于FragmentActivity自身，就限制requestCode不能大于0xffff。

再加上前文所说的，Fragment.startActivityForResult最终映射的requestCode值必定大于0xffff，所以，现在可以得出了一个初步的结果：
SDK把Fragment和FragmentActivity的的ruquestCode都限制在了0xffff以内，然后对于Fragment所发起的请求，都通过一个映射，把最终的requestCode变成了一个大于0xffff的值。

——到现在，已经可以推测到：在获取的结果的时候，也是会通过跟0xffff这个数值来比较，来区分是要把结果交给FragmentActivity还是Fragment来处理。

来验证一下看看：

3.4 FragmentActivity.onActivityResult

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

@Override
protected void onActivityResult(int requestCode, int resultCode, Intent data) {
    mFragments.noteStateNotSaved();
    int requestIndex = requestCode>>16;
    if (requestIndex != 0) {
        requestIndex--;
        String who = mPendingFragmentActivityResults.get(requestIndex);
        mPendingFragmentActivityResults.remove(requestIndex);
        if (who == null) {
            Log.w(TAG, "Activity result delivered for unknown Fragment.");
            return;
        }
        Fragment targetFragment = mFragments.findFragmentByWho(who);
        if (targetFragment == null) {
            Log.w(TAG, "Activity result no fragment exists for who: " + who);
        } else {
            targetFragment.onActivityResult(requestCode&0xffff, resultCode, data);
        }
        return;
    }
    super.onActivityResult(requestCode, resultCode, data);
}

OK，一目了然，证实了我们上面的推论。
在FragmentActivity.onActivityResult中，只有requestCode>0xffff时，这里得到的requestIndex才能满足requestIndex != 0，然后进入下面的逻辑：把requestCode通过反向之前的映射关系，还原成最初Fragment所指定的requestCode，交给Fragment.onActivityResult进行处理。

4. 解释最初的问题

所以，现在也能明白了为什么会有前面说的这几个表现：

1. Fragment和FragmentActivity都能接收到自己的发起的请求所返回的结果

   那当然，就是这么设计的。

2. FragmentActivity发起的请求，Fragment完全接收不到结果

   被FragmentActivity拦截了，没有转发到Fragment。

3. Fragment发起的请求，虽然在FragmentActivity中能获取到结果，但是requestCode完全对应不上

   如果是Fragment发起的请求，那么在FragmentActivity.onActivityResult获取到的requestCode，其实是经过映射之后一个的大于0xffff的值，已经不是最初Fragment发请求时的requestCode了。

5. 思考

为什么要用映射requestCode的方法来区分请求是否来自Fragment呢？绕这么一个弯子，直接使用一个变量来标记不行么？

直接使用一个变量来标记还真不行：

• 因为我们自己最终写业务代码MyFragmentActivity肯定是继承自FragmentActivity的，而MyFragmentActivity.onActivityResult的调用会先于FragmentActivity.onActivityResult。
• 所以无论是Fragment还是MyFragmentActivity所发起的startActivityForResult请求，最终在获取结果的时候是一定是会通过MyFragmentActivity.onActivityResult的。
• 如果在这里使用一个变量来标记请求的来源，那实质上就是依赖于开发者自己来判断——这是繁琐而且不可控的。
• 而相比较而言，使用一个简单的映射规则，就能把来自Fragment的请求和来自FragmentActivity自身请求区分开来——十分简单可靠。

6. 总结

1. 使用startActivityForResult的时候，requestCode一定不要大于0xffff(65535)。
2. 如果希望在Fragment的onActivityResult接收数据，就要调用Fragment.startActivityForResult，而不是Fragment.getActivity().startActivityForResult。
3. 看源码果然是学习的好方法~
4. Google的工程师果然牛逼。

关于作者 :
http://www.barryzhang.com
https://github.com/barryhappy

本文由BarryZhang原创，同时首发于diycode.cc、barryzhang.com 、github.com/barryhappy，非商业转载请注明作者和原文链接。

前言

开发做得久了，总免不了会遇到各种坑。
而在Android开发的路上，『软键盘挡住了输入框』这个坑，可谓是一个旷日持久的巨坑——来来来，我们慢慢看。

入门篇

最基本的情况，如图所示：在页面底部有一个EditText，如果不做任何处理，那么在软键盘弹出的时候，就有可能会挡住EditText。
对于这种情况的处理其实很简单，只需要在AndroidManifest文件中对activity设置：android:windowSoftInputMode的值adjustPan或者adjustResize即可，像这样：

1
2
3
4
5

<activity
	android:name=".MainActivity"
	android:windowSoftInputMode="adjustPan"  >
    ...
</activity>

一般来说，他们都可以解决问题，当然，adjustPan跟adjustResize的效果略有区别。

• adjustPan是把整个界面向上平移，使输入框露出，不会改变界面的布局；
• adjustResize则是重新计算弹出软键盘之后的界面大小，相当于是用更少的界面区域去显示内容，输入框一般自然也就在内了。

↑↑↑ OK，这只是入门，基本上地球上所有的Android工程师都能搞定。
别急，看下面~

加上WebView试试看？坑来了……

情况描述

上面的入门篇中，软键盘是由原生的EditText触发弹出的。而在H5、Hybrid几乎已经成为App标配的时候，我们经常还会碰到的情况是：软键盘是由WebView中的网页元素所触发弹出的。

这时候，情况就会变得复杂了:

1. 首先，页面是非全屏模式的情况下，给activity设置adjustPan会失效。
2. 其次，页面是全屏模式的情况，adjustPan跟adjustResize都会失效。

——解释一下，这里的全屏模式即是页面是全屏的，包括Application或activity使用了Fullscreen主题、使用了『状态色着色』、『沉浸式状态栏』、『Immersive Mode』等等——总之，基本上只要是App自己接管了状态栏的控制，就会产生这种问题。

下面这个表格可以简单列举了具体的情况。

为什么说它是个坑？”issue 5497”

上面表格的这种情况并非是Google所期望的，理想的情况当然是它们都能正常生效才对——所以这其实是Android系统本身的一个BUG。

为什么文章开头说这是个坑呢？
——因为这个BUG从Android1.x时代（2009年）就被报告了，而一直到了如今的Android7.0（2016年）还是没有修复……/(ㄒoㄒ)/
可以说这不仅是个坑，而且还是个官方挖的坑~

“issue 5497”，详情传送门 ☞ Issue 5497 - android -WebView adjustResize windowSoftInputMode breaks when activity is fullscreen - Android Open Source Project - Issue Tracker - Google Project Hosting

当然了，不管坑是谁挖的，最终还是要开发者来解决。

遇到坑之后，有两种方法可以过去：躲，或者填。

躲坑姿势

如前文所示，出现坑的条件是：带有WebView的activity使用了全屏模式或者adjustPan模式。
那么躲坑的姿势就很简单了——
如果activity中有WebView，就不要使用全屏模式，并且把它的windowSoftInputMode值设为adjustResize就好了嘛

怎么样，是不是很简单？😑

填坑姿势

但总有些时候，是需要全屏模式跟WebView兼得的，这时候，躲坑就不行了，我们需要一个新的填坑的姿势。幸好，开发者的智慧是无穷的，这个坑出现了这么多年，还是有人找到了一些解决方案的。

AndroidBug5497Workaround

我个人认为最好的解决方案是这个：AndroidBug5497Workaround，只需要一个神奇的AndroidBug5497Workaround类。

使用步骤：

1. 把AndroidBug5497Workaround类复制到项目中
2. 在需要填坑的activity的onCreate方法中添加一句AndroidBug5497Workaround.assistActivity(this)即可。

经过测试，基本在各个Android版本上都可用，效果基本与设置了adjustResize相当。
看一个对比图：

来自我厂App的某个使用WebView的全屏模式Activity页面，从左到右分别是：没有软键盘的样式、软键盘挡住输入框的效果、以及使用AndroidBug5497Workaround之后的最终效果。

它的原理是什么？

这个炫酷AndroidBug5497Workaround类，其实并不是很复杂，只有几十行代码，先贴在这里：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

public class AndroidBug5497Workaround {
    // For more information, see https://code.google.com/p/android/issues/detail?id=5497
    // To use this class, simply invoke assistActivity() on an Activity that already has its content view set.
    public static void assistActivity (Activity activity) {
        new AndroidBug5497Workaround(activity);
    }
    private View mChildOfContent;
    private int usableHeightPrevious;
    private FrameLayout.LayoutParams frameLayoutParams;
    private AndroidBug5497Workaround(Activity activity) {
        FrameLayout content = (FrameLayout) activity.findViewById(android.R.id.content);
        mChildOfContent = content.getChildAt(0);
        mChildOfContent.getViewTreeObserver().addOnGlobalLayoutListener(new ViewTreeObserver.OnGlobalLayoutListener() {
            public void onGlobalLayout() {
                possiblyResizeChildOfContent();
            }
        });
        frameLayoutParams = (FrameLayout.LayoutParams) mChildOfContent.getLayoutParams();
    }
    private void possiblyResizeChildOfContent() {
        int usableHeightNow = computeUsableHeight();
        if (usableHeightNow != usableHeightPrevious) {
            int usableHeightSansKeyboard = mChildOfContent.getRootView().getHeight();
            int heightDifference = usableHeightSansKeyboard - usableHeightNow;
            if (heightDifference > (usableHeightSansKeyboard/4)) {
                // keyboard probably just became visible
                frameLayoutParams.height = usableHeightSansKeyboard - heightDifference;
            } else {
                // keyboard probably just became hidden
                frameLayoutParams.height = usableHeightSansKeyboard;
            }
            mChildOfContent.requestLayout();
            usableHeightPrevious = usableHeightNow;
        }
    }
    private int computeUsableHeight() {
        Rect r = new Rect();
        mChildOfContent.getWindowVisibleDisplayFrame(r);
        return (r.bottom - r.top);// 全屏模式下： return r.bottom
    }
}

代码大致是做了这么几件事：

1.找到activity的根View

看一下入口的代码：

1
2

FrameLayout content = (FrameLayout) activity.findViewById(android.R.id.content);
mChildOfContent = content.getChildAt(0);

其中，第一行中的android.R.id.content所指的View，是Android所有Activity界面上开发者所能控制的区域的根View。

• 如果Activity是全屏模式，那么android.R.id.content就是占满全部屏幕区域的。
• 如果Activity是普通的非全屏模式，那么android.R.id.content就是占满除状态栏之外的所有区域。
• 其他情况，如Activity是弹窗、或者7.0以后的分屏样式等，android.R.id.content也是弹窗的范围或者分屏所在的半个屏幕——这些情况较少，就暂且不考虑了。

我们经常用的setContentView(View view)/setContent(int layRes)其实就是把我们指定的View或者layRes放到android.R.id.content里面，成为它的子View。

所以，然后，第二行content.getChildAt(0)获取到的mChildOfContent，其实也就是用以获取到我们用setContentView放进去的View。

2.设置一个Listener监听View树变化

1
2
3

mChildOfContent.getViewTreeObserver().addOnGlobalLayoutListener({ //简化了写法
        possiblyResizeChildOfContent();
});

View.getViewTreeObserver()可以获取一个ViewTreeObserver对象——这个对象是一个观察者，专门用以监听当前View树所发生的一些变化。这里所注册的addOnGlobalLayoutListener，就是会在当前的View树的全局布局（GlobalLayout）发生变化、或者其中的View可视状态有变化时，进行通知回调。

——『软键盘弹出』，则是会触发这个事件的一个源。 (软键盘弹出会使GlobalLayout发生变化)

也就是说，现在能监听到『软键盘弹出』的事件了。

3.界面变化之后，获取”可用高度”

当软键盘弹出了之后，接下来的事情是获取改变之后的界面的可用高度（可以被开发者用以显示内容的高度）。
直接看代码：

1
2
3
4
5
6

private int computeUsableHeight() {
    Rect rect = new Rect();
    mChildOfContent.getWindowVisibleDisplayFrame(rect);
    // rect.top其实是状态栏的高度，如果是全屏主题，直接 return rect.bottom就可以了
    return (rect.bottom - rect.top);
}

View.getWindowVisibleDisplayFrame(Rect rect)，这行代码能够获取到的Rect——就是界面除去了标题栏、除去了被软键盘挡住的部分，所剩下的矩形区域——如图所示，红框中的区域。

↑也可以看出：

• rect.top值，其实就是标题栏的高度。（实际上，这也常常被用作为获取标题栏高度的方法）
• 屏幕高度-rect.bottom，是软键盘的高度。（获取软键盘高度的方法也出现了）

这时，就有：

• 全屏模式下，可用高度 = rect.bottom
• 非全屏模式，可用高度 = rect.bottom - rect.top

4.最后一步，重设高度

我们计算出的可用高度，是目前在视觉效果上能看到的界面高度。但当前界面的实际高度是比可用高度要多出一个软键盘的距离的。
所以，最后一步，就是把界面高度置为可用高度——大功告成。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

private void possiblyResizeChildOfContent() {
    int usableHeightNow = computeUsableHeight();
    if (usableHeightNow != usableHeightPrevious) {
        int usableHeightSansKeyboard = mChildOfContent.getRootView().getHeight();
        int heightDifference = usableHeightSansKeyboard - usableHeightNow;
        if (heightDifference > (usableHeightSansKeyboard/4)) {
            // keyboard probably just became visible
            frameLayoutParams.height = usableHeightSansKeyboard - heightDifference;
        } else {
            // keyboard probably just became hidden
            frameLayoutParams.height = usableHeightSansKeyboard;
        }
        mChildOfContent.requestLayout();
        usableHeightPrevious = usableHeightNow;
    }
}

上面的代码里添加了一个”heightDifference > (usableHeightSansKeyboard/4)”的判断，这是为了去除无谓的干扰。因为能触发OnGlobalLayout事件的原因有很多，不止是软键盘的弹出变化，还包括各种子View的隐藏显示变化等，它们对界面高度的影响有限。加上了这个判断之后，只有界面的高度变化超过1/4的屏幕高度，才会进行重新设置高度，基本能保证代码只响应软键盘的弹出。

总结

总结起来，就是这样：

1. 普通Activity（不带WebView），直接使用adjustpan或者adjustResize
2. 如果带WebView：
   • a) 如果非全屏模式，可以使用adjustResize
   • b) 如果是全屏模式，则使用AndroidBug5497Workaround进行处理。

OK，以上就是一段关于『软键盘挡住输入框』的爬坑之旅。

其他

有用的链接：
https://code.google.com/p/android/issues/detail?id=5497
http://stackoverflow.com/a/19494006
https://developer.android.com/reference/android/view/ViewTreeObserver.html

1. Kotlin是什么？

Kotlin是一门编程语言，由JetBrains公司开发的。JetBrains就是那个开发了无数个牛逼IDE的公司，Android Studio就是建立在他家的Intellij之上的。
Kotlin是基于JVM的，所以开发者可以什么方便地用它来进行Android开发——支持Kotlin和Java的混合编写。

2. 为什么要使用Kotlin？

我觉得它之所以适合Android开发，主要是因为以下的特点：

2.1 简洁、优雅

写了很多年的Java之后，再写Kotlin，真是觉得如沐春风。
除了不用写分号以及天然支持Lambda表达式之外，它的语法本身就比Java简洁许多。

举几个小例子，比如，类型推导：

1
2
3
4
5

val a : Int = 1 // 正常的声明、赋值
val b = 2 // 类型推导，可以省略Int声明 
/* 定义函数：自动推导函数的返回值类型 */
fun sum(a: Int, b: Int) = a + b

字符串模板：

1
2
3

val name = "Barry"
val age = 15
print("My name is ${name}, I am ${age} ")  // 会打印出： My name is Barry, I am 15

下面这个例子，可以对比体会一下他们的不同—— 遍历一个列表，打印其中的奇数。
如果用java写:

1
2
3
4
5
6
7
8
9

List list = Arrays.asList("H",1,3,10,5,9,20,199);
for(Object number : list){
    if(!(number instanceof  Integer)) {
        continue;
    }
    if((Integer)number % 2 == 0){
        System.out.println((Integer)number);
    }
}

而用Kotlin的话，显然会更清晰、简洁、优雅（注意这里的lambda表达式）：

1
2
3
4

val list = Arrays.asList("H", 1, 3, 10, 5, 9, 20, 199)
list.filter { it is Int }
        .filter { it as Int % 2 != 0 }
        .forEach { println(it) }

在Kotlin中，诸如此类的语法糖还有很多：函数默认值、内联函数、ranges、kv遍历Map、lazy属性、数据对象声明、运算符重载…… 如果展开来说的话，每个都可以说很多。

当习惯这些之后，很容易就会有这种感觉：写Kotlin相比较写Java，就像高铁之于绿皮火车、iPhone之于山寨机、4K屏之于800*600……没有它之前觉得老的东西也能用，但是一旦习惯，再改回去的话就觉得浑身难受。

另外，简洁的语法不仅使代码读起来清晰流畅，也让它自然简单易学——基本上花上半天时间，把官方文档看上一遍，就可以开始coding了。

2.2 安全

在Java里，我们常常要进行许多非空判断：

1
2
3
4
5

public void fun1 (String str){
   if(str != null) {
       System.out.println("Length = " + str.length());
   }
}

而在Kotlin中，即使不进行这些额外的判断，代码也是健壮的：

1
2
3
4

// 如果str=null，会打印：Length = null
fun fun1 (str: String?) {
    println("Length = " + str?.length) 
}

还有，Java中经常出现的ClassCastException，在Kotlin中，也可以通过安全的类型转换进行避免：

1
2

val l2 = listOf("A",1,3,6,8,'c')
l2.forEach { println(it as? Int) }

2.3 函数、属性扩展

Kotlin提供了一种方法——可以在既不需要继承父类，也不需要使用类似装饰器设计模式的情况下，对类进行扩展。简直是黑科技！
比如，给String类添加一个扩展方法，用以返回它的第一个字符。只需要这样：

1
2
3
4

// 函数扩展
fun String.firstChar() : String? {
    return if(this.length > 0) this.substring(0,1) else "NULL"
}

这个扩展函数可以在任何地方声明，然后其他任何地方String对象就都可以使用这个方法了:

1
2
3

val s = "Hello".firstChar())  // s的值为"H"
println("你好".firstChar())   // 打印： 你
println("".firstChar())   // 打印： NULL

2.4 兼容Java

一个语言能否被广泛使用，除了它本身要好用之外，还要有一个良好的生态。 尤其在是如今，各种应用层的开发实际上很依赖于各种开源库、第三方组件等，如果一个应用层的语言没有这些支持的话，是很难被广泛使用的。
而对于Kotlin来说，这个问题是不存在的，因为它跟Java是无缝连接的，可以相互操作。
这意味着：

• Kotlin可以使用所有用Java写的组件：（RxJava、Retrofit、EventBus、Fresco……这些都不是问题！）
• 在现有的用Java写的项目中可以局部使用Kotlin，混合开发
• Java->Kotlin，可以逐步迁移而不是非黑即白
• 使用Kotlin开发时，万一遇到问题，可以瞬间切换回Java~

2.5 工具完善

来，我们再理一下这个关系树：
JetBrains
|–> Intellij IDEA –> Android Studio
|–> Kotlin
Kotlin是JetBrains公司出的；JetBrains向来以做各种牛逼的IDE著称；Android的官方开发工具AndroidStudio就是基于JetBrains公司出品的Intellij改造的。
↑ 以上是背景。
从实际体验角度来说，Kotlin的开发也是十分方便快捷的。
只需花几分钟给AndroidStudio安装一个Kotlin的扩展插件，就可以迅速开始体验使用Kotlin的快感了。
一开始的时候，你甚至都不需要会使用Kotlin！这是因为Kotlin插件提供了一个Java->Kotlin的转换功能，可以一键把现有的Java代码转换为Kotlin代码，你可以通过阅读它转换后的Kotlin代码，进行学习。
（实际上，我在学习Kotlin的时候，就大量使用了这种方法：当我不知道某个功能用Kotlin怎么写的时候，就会先用Java把它写出来，然后使用转换功能，生成Kotlin代码，从而就知道了Kotlin的写法）

3. 如何开始

因为是一篇纯粹的说明文，所以我把如何开始单独抽离出来，写了这篇文章：《只需五分钟，开始使用Kotlin开发Android》
☞ 链接看这里：
http://www.barryzhang.com/archives/476
http://www.jianshu.com/p/5fa2c1eda64c

其他：

有用的链接们：

• Kotlin官网 Kotlin官网：中文
• Kotlin in Chinese
  中文翻译的Kotlin官方文档 by @huanglizhuo。
  另一个地址，访问速度会略快一些。
• 中文版：Kotlin for Android Developers
• 厚着脸皮放一个自己的Kotlin项目
• 如何评价 Kotlin 语言？——知乎
• Android开发必备知识：为什么说Kotlin值得一试

关于作者 :
http://www.barryzhang.com
https://barryhappy.github.io
http://www.jianshu.com/users/e4607fd59d0d/latest_articles
http://blog.csdn.net/barryhappy

好了，正文开始：

对于开发者来说，我们正处于一个美好的时代。得益于互联网的发展、工具的进步，我们现在学习一门新技术的成本和难度都比过去低了很多。
假设你之前没有使用过Kotlin，那么从头开始写一个HelloWorld的app也只需要这么几步：

首先，你要有一个Android Studio。

我正在用的是2.2.1版本，其它版本应该也大同小异。

其次，安装一个Kotlin的插件。

依次打开：Android Studio > Preferences > Plugins，然后选择『Browse repositories』，在搜索框中搜索Kotlin，结果列表中的『Kotlin』插件，就是我们要找的目标了。
点击安装，安装完成之后，重启Android Studio。

新建一个Android项目

重新打开Android Studio，新建一个Android项目吧，添加一个默认的MainActivity
——像以前一样即可。

Java to Kotlin

安装完插件的AndroidStudio现在已经拥有开发Kotlin的新能力了，那么如何体现这个能力呢？
我们先来尝试它的转换功能：Java -> Kotlin，可以把现有的java文件翻译成Kotlin文件。

打开MainActivity文件，在Code菜单下面可以看到一个新的功能：Convert Java File to Kotlin File。

点击转换，可以看到结果：
java文件：MainActivity.java

1
2
3
4
5
6
7
8
9
10
11
12
13

package com.barryzhang.kotlinhello;
import android.support.v7.app.AppCompatActivity;
import android.os.Bundle;
public class MainActivity extends AppCompatActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
    }
}

转换后的Kotlin文件：MainActivity.kt

1
2
3
4
5
6
7
8
9
10
11
12

package com.barryzhang.kotlinhello
import android.support.v7.app.AppCompatActivity
import android.os.Bundle
class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
    }
}

Kotlin的转换功能是十分实用的，对于我们重用过去的java代码、或者网上搜索到的java代码片段很有帮助。（当然，Kotlin是直接兼容java的，如果不想转换，也可以直接调用Java的方法）

配置gradle文件

MainActivity已经被转换成了Kotlin实现，但是项目目前还不可以用，还需要配置一下，让项目支持grade的编译、运行。
当然，这一步也不需要我们做太多工作——在java转换成Kotlin之后，打开MainActivity.kt文件，编译器会提示”Kotlin not configured”，点击一下Configure按钮，IDE就会自动帮我们配置好了！（所以说Kotlin的工具完善可不是吹的，毕竟Kotlin的老爹JetBrains就是专门做工具的啊）

这个自动配置，实际上是做了这些改动。
项目的build.gradle添加：

1
2
3
4
5
6

buildscript {
    ext.kotlin_version = '1.0.4'
    dependencies { 
        classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"
    }
}

module里的build.gradle添加：

1
2
3
4
5
6
7
8
9
10
11
12

apply plugin: 'kotlin-android'
android { 
    sourceSets {
        main.java.srcDirs += 'src/main/kotlin'
    }
}
dependencies { 
    compile "org.jetbrains.kotlin:kotlin-stdlib:$kotlin_version"
}
repositories {
    mavenCentral()
}

↑↑↑ 熟悉了之后自己手写也是阔以的。

Run

配置之后，等sync完成，就可以运行了~ （如果你sync失败或者耗时过长，赶紧检讨一下自己有没有科学上网？）

biu~起飞，欢迎来到新世界的大门。

准备工作

• 手机和电脑需要在同一个局域网
• 准备一条数据线——（what？不是说无线连接吗？！别着急，这只是第一次设置时用到的，以后再连接就不需要数据线了）
• 你需要知道怎么执行adb命令（不知道的话请自行Google）

开始

1. 打开手机的5555端口

让手机在指定的端口可以接收到TCP/IP连接。（当然，也可以不用5555，用5556或者9999等都可以，只要你喜欢）

1. 确保手机开启了usb调试
2. 用usb线把手机和电脑连接起来

3. 执行命令：

   adb tcpip 5555

执行成功后就可以把usb线拔掉了。

2. 找到手机的IP地址

一般在 设置-关于手机-状态信息-IP地址可以找到。
比如，我这里看到手机的IP地址是192.168.1.108

3. 通过IP地址和端口连接手机

执行命令：
adb connect 192.168.1.108:5555

3.1 如果提示

connected to 192.168.1.108:5555

则表示连接成功

3.2 如果提示

unable to connect to 192.168.1.108:5555: Operation timed out

——可能你的IP地址输错了;或者adb服务不可用;或者手机跟电脑没有正确地处在一个局域网中；或者链接被代理Block了等等等…

3.3 如果提示

unable to connect to 192.168.1.108:5555: Connection refused

—— 可能你手机的5555端口没有正确打开；或者有防火墙拦截等…

4. 如果没有连接成功

如果出现了3.2或3.3的错误提示，或者其他任何错误，都可以尝试重启一下adb服务：

adb kill-server

然后再重新进行尝试。

5. 连接成功

如果连接成功的话，执行以下命令查看当前连接的设备列表：
adb devices
可以看到连接的设备，像这样

$ adb devices
List of devices attached
192.168.1.108:5555 device

——恭喜你，从此可以摆脱对数据线的依赖了。

总结&其他

1. 更换一个网络环境（比如把手机和电脑从公司带回了家里），一般只需要按照新的手机IP重新进行一下connect即可。
2. 但是如果手机重启了，就需要重新连接数据线再次开启5555端口了。
3. 当然开启5555端口也并非必须通过adb，也有一些方法可以直接在手机上操作打开。但这些方法一般都需要root权限，如果你想要尝试在手机上进行开启，请注意安全。
4. 有利就有弊——无线调试较有线调试而言，优势自不必说，缺点是无线数据的传输会比有线要慢一些。
5. 还有一点，自从用了无线调试之后，我那常年满电的测试机，现在需要时不时的进行充电了~~~
   o(╯□╰)o

有用的链接：
https://developer.android.com/studio/command-line/adb.html
http://stackoverflow.com/questions/23936781/unable-to-connect-android-device-over-adb-tcp-ip

Also in:
http://www.barryzhang.com
https://barryhappy.github.io
http://www.jianshu.com/users/e4607fd59d0d/latest_articles
http://blog.csdn.net/barryhappy

1. 旧版的onReceiveError

在API23之前，该方法的签名是：

1

public void onReceivedError(WebView view, int errorCode,String description, String failingUrl);

文档是：

Report an error to the host application. These errors are unrecoverable (i.e. the main resource is unavailable). The errorCode parameter corresponds to one of the ERROR_* constants.

简单来说，onReceivedError只有在遇到不可用的(unrecoverable)错误时，才会被调用）。
比如，当WebView加载链接www.barryzhang.com时，”不可用”的情况有可以包括有：

• 没有网络连接
• 连接超时
• 找不到页面www.barryzhang.com

而下面的情况则不会被报告：

• 网页内引用其他资源加载错误，比如图片、css不可用
• js执行错误

2. 应用：显示个自定义ERROR界面

基于以上特性，所以它可以用来处理网页加载不出来的情况，比如显示一段友好的提示语、一个重试按钮等。
比如像这样：

1
2
3
4
5
6

@Override
public void onReceivedError(WebView view, int errorCode, String description, String failingUrl) {
	super.onReceivedError(view, errorCode, description, failingUrl);
	layoutError.setVisibility(View.VISIBLE); 
	textViewErrorMessage.setText("(错误码:" + errorCode + "  " + description + ")"  );
}

——这么做的还有一个原因是，虽然默认的网页错误样式每个ROM都可能不一样，但是却是一样的丑……，来个对比图感受一下，从左到右依次是：MIUI(Android5.0.2)、Nexus5X(Android7)、以及自定义之后的效果：

3. 新版的onReceiveError

So far so good, but~
API23(Android6)，Google对onReceiveError进行了一次改版重载，并且把老版本的废弃了，ㄒoㄒ~~
签名改成了这样：

1

public void onReceivedError(WebView view, WebResourceRequest request, WebResourceError error);

文档改成了：

Report web resource loading error to the host application. These errors usually indicate inability to connect to the server. Note that unlike the deprecated version of the callback,the new version will be called for any resource (iframe, image, etc), not just for the main page. Thus, it is recommended to perform minimum required work in this callback.

新版的onReceiveError能接收到的错误更多，不再局限于之前的”不可用”的情况——好像是比之前更强大了。
但是，这时候如果我们依然用使用旧版本的方式来使用新版，像这样：

1
2
3
4
5
6
7

@Override
public void onReceivedError(WebView view, WebResourceRequest request, WebResourceError error) {
    // ！！在新版的onReceivedError中，沿用之前的处理逻辑（这是错误的示例！！）
	super.onReceivedError(view, errorCode, description, failingUrl);
	layoutError.setVisibility(View.VISIBLE); 
	textViewErrorMessage.setText("(错误码:" + error.getErrorCode() + "  " + error.getDescription().toString() + ")"  );
}

这会导致的问题是：在Android6以上的机器上，网页中的任意一个资源获取不到（比如字体），网页就很可能显示自定义的错误界面。尤其是如果Html用了本地化技术，’ERR_FILE_NOT_FOUND’开始变得特别常见。

4. 如何像在老版本一样工作？

4.1 继续用老版本呢？

Bingo！可以，起码从目前来看，测试结果表明至少在Andoid6以及Android7上是可以工作的。
然而，终究，使用已废弃的API终究是不太优雅——说不定哪个版本就突然不能用了，仿佛像个定时炸弹一样。

4.2 isForMainFrame

我们注意到新版的onReceivedError跟老版相比，多了一个WebResourceRequest参数，而WebResourceRequest有一个方法叫做isForMainFrame，描述为：

Gets whether the request was made for the main frame
获取当前的网络请求是否是为main frame创建的.

加上这个条件判断是来试试？

1
2
3
4
5
6
7

@Override
public void onReceivedError(WebView view, WebResourceRequest request, WebResourceError error) {
	super.onReceivedError(view, errorCode, description, failingUrl);
	if(request.isForMainFrame()){// 在这里加上个判断
	    // 显示错误界面
	}
}

实验证明这个方法是有效的。

4.3 当然,也还有其他方法

可以这样，直接上代码：

1
2
3
4
5
6
7

@Override
public void onReceivedError(WebView view, WebResourceRequest request, WebResourceError error) {
	super.onReceivedError(view, errorCode, description, failingUrl);
	 if (request.getUrl().toString() .equals(getUrl())) {// 在这里加上个判断
	    // 显示错误界面
	}
}

原理是：用请求的url来判断，如果出错的url跟webView当前加载的url一致，就显示错误页面。
↑↑经测试，也能通过~

总结

总而言之，最终的代码这样写，可以同时兼容新旧版本：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

// 旧版本，会在新版本中也可能被调用，所以加上一个判断，防止重复显示
@Override
public void onReceivedError(WebView view, int errorCode, String description, String failingUrl) {
	super.onReceivedError(view, errorCode, description, failingUrl);
	if(Build.VERSION.SDK_INT >= Build.VERSION_CODES.M){
		return;
	}	
	// 在这里显示自定义错误页
}
// 新版本，只会在Android6及以上调用
@TargetApi(Build.VERSION_CODES.M)
@Override
public void onReceivedError(WebView view, WebResourceRequest request, WebResourceError error) { 
	super.onReceivedError(view, request, error);
	if (request.isForMainFrame()){ // 或者： if(request.getUrl().toString() .equals(getUrl()))
		// 在这里显示自定义错误页
	}
}

众所周知，with和height是所有View的基础属性。用一个二维坐标系来描述手机屏幕，那么它们就分别表示了View在坐标系上x、y方向上值 ——这是我们一直都习惯的自然表示。
然而，从Android5.0(API21)开始，Google引入了一个z值，把二维坐标系强行改成了三维。

在Android API21，新添加了一个属性：android:elevation，用以在xml定义View的深度(高度)，也即z方向的值。
除了elevation之外，类似于已有的translationX、translationY，也相对应地新增了一个translationZ，用以在属性动画中动态改变Z值（使用View.setTranslationZ()）。

Z = elevation + translationZ

有什么用处呢？

在引入了这个属性之后，主要影响有两个：

1. 影响View的阴影
2. 影响View相互阻挡顺序

1. 影响View的阴影

Z值会对View的阴影外观造成影响，但是不是对View大小造成影响。
拥有更大Z值的View会有一个更大但是更柔和的阴影——这跟我们生活的实际体验是一致的，官方给的效果图：

2. 影响View相互阻挡顺序

拥有更大Z值的View会挡住Z值比较小的View——即更大Z值的View会在最上层。
譬如，在正常的FrameLayout中，子View的绘制顺序是从上到下，也就是说，最后一个子View会显示到最上面，如果位置跟前面的View有重合，则会盖住前面的View。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

<FrameLayout xmlns:android="http://schemas.android.com/apk/res/android"
              android:orientation="vertical"
              android:layout_width="match_parent"
              android:layout_height="match_parent">
    <TextView
        android:id="@+id/viewA"
        android:background="#f00"
        android:text="A"
        android:gravity="center"
        android:layout_width="100dp"
        android:layout_height="100dp" />
    <TextView
        android:id="@+id/viewB"
        android:background="#0f0"
        android:text="B"
        android:gravity="center"
        android:layout_marginLeft="60dp"
        android:layout_marginTop="60dp"
        android:layout_width="100dp"
        android:layout_height="100dp" />
    <!--ViewC有了一个elevation属性 -->
    <TextView
        android:id="@+id/viewC"
        android:layout_marginLeft="180dp"
        android:background="#f00"
        android:text="C"
        android:gravity="center"
        android:elevation="1dp"
        android:layout_width="100dp"
        android:layout_height="100dp" />
    <TextView
        android:id="@+id/viewD"
        android:background="#0f0"
        android:text="D"
        android:gravity="center"
        android:layout_marginLeft="240dp"
        android:layout_marginTop="60dp"
        android:layout_width="100dp"
        android:layout_height="100dp" />
</FrameLayout>

比如，上面的xml代码，效果如下图所示：

• 先看ViewA、ViewB，因为ViewB是第二个子View，ViewA是第一个，所以B会覆盖在A的上面。
• 然后ViewC、D，跟AB相比较，区别就在于ViewC多了一个elevation属性，有了一个比ViewD更大的Z值，所以，即使它在ViewD的前面，但是依然能够盖住D~ （ViewC：因为朕站的更高，哇哈哈~ ）

还有CardView

为什么会提到CardView呢？因为CardView可以算作是一个官方使用的Z值的示例了。

CardView 扩展 FrameLayout 类别并让您能够显示卡片内的信息，这些信息在整个平台中拥有一致的呈现方式。CardView 小组件可拥有阴影和圆角。

CardView是在v7支持包里面的，在API<21时，实现方式是padding+绘制阴影；而在在api>=21时，就是用elevation属性来实现的啦！

知道了这些，也可以解释一些以前觉得诡异的View覆盖的问题了，比如：我明明在CardView的上层放了一个Button，为什么Button看不到了？？？
（傻孩子，因为CardView默认的elevation的呀）

可能有用的链接：
https://developer.android.com/training/material/shadows-clipping.html
https://developer.android.com/training/material/lists-cards.html
https://developer.android.com/reference/android/support/v7/widget/CardView.html