关于 View.offsetTopAndBottom (View.offsetLeftAndRight)：

1. 在 layout 之后，View.offsetTopAndBottom() ​的信息就会丢失，所以最好是 onLayout 配合 View.offsetTopAndBottom() ​使用，确保任意时刻，view 总处于我们期望的位置。
2. 在 Android API Level 23 之前，View.offsetTopAndBottom() 是存在 bug 的，这个 bug 的表现是：当 offset view 到界面外，然后切到后台， 再切回来，此时再调用 View.offsetTopAndBottom() 会无效。原因是它没有调用父 view 的 invalidate() 方法去更新某些私有 flag。幸运的是 Google 提供了 ViewCompat.offsetTopAndBottom() 和 ViewCompat.offsetLeftAndRight() 来修复存在的 bug。而且最好使用 support 24.2.0 以后的包，因为在这个版本后，ViewCompat.offsetTopAndBottom() 才针对各个版本差异化修补，更高效。

Android 的键盘处理比较奇葩，换行与确定不能兼得。如果要键盘的 Action 为发送、确定等时，一定要求 EditText 为单行，自动换行都做不到，差评！

使用 ApplicationContext 去 startActivity 在某些 Android 版本下必须要加上 FLAG_ACTIVITY_NEW_TASK，否则会 crash。 详情请见 ContextImpl.startActivity(Intent, Bundle) ​。（注：API 23 以下 和 API 23 及其以上的实现并不一样）

当我们想 TextView 在上使用跑马灯效果时， 我们会发现简单的设置 android:ellipsize="marquee" 和 android:singleLine="true" ​并不生效。我们还需要主动调用 setSelect(true) ​才行。

Dialog 的创建不能使用 ApplicationContext，会 crash。

RecyclerView 的 LinearLayoutManager 提供了两个比较好玩的 API ：reverseLayout 和 stackFromEnd

View.getWindowVisibleDisplayFrame(Rect rect) :

作用：​返回当前 view 所 attach 的 window 的可视区域的大小

影响因子：​statusBar（rect.top）、navigationBar（rect.bottom）、虚拟键盘（rect.bottom)

具体表现：​

    如果 window 不与 statusBar、navigationBar 和虚拟键盘重叠，那么 rect.top = 0，rect.bottom =  ​screenRealHeight - navigationBarHeight

    ​rect.​top = 全屏 ？0 :  （widow.layoutparam.height == MATCH_PARENT ?  状态栏高度 ： window 与状态栏高度重叠的高度）

    rect.bottom(键盘升起) =  widow.layoutparam.height == MATCH_PARENT ?  screenRealHeight - navigationBarHeight - keyboardHeight ：screenRealHeight - navigationBarHeight - 键盘与window重叠区域的高度

    rect.bottom(键盘未升起) = ​screenRealHeight - navigationBarHeight

当我们的 ListView 拥有多着类型的 itemView 时，一定要注意 adapter.getViewTypeCount 的维护，特别是后期添加类型时，经常忘记更改 getViewTypeCount，因此就会出现如下 crash :

如果对于老手，可能快速反应出问题的关键点，但对于新手或者不熟悉 ListView 多类型的开发者，就会有点不知所措了。对于 RecyclerView，就不会有这个问题了。

当 ListView 的 itemView 的子 view 存在点击事件或者 clickable 为 true 时， 那么点击 itemView 不会触发 ListView 的 mOnItemClickListener；反之，如果你不想 ListView 的 mOnItemClickListener 被触发，你可以设置 itemView.setClickable(true)

View 的 detach 和 attach 可能会因为 Animation 而变得混乱，不经意间就造成 View 假死，例如：

mView.startAnimation(disappearAnimation);
ViewGroup parent = (ViewGroup) mView.getParent();
parent.removeView(mView); // 移除 view 时伴随动画
//...
parent.addView(mView); // 动画未结束时又将 view 加回来
mView.startAnimation(appearAnimation);

现象：​mView 无法接收事件，使用 uiautomatorviewer 时也无法查看其信息

原因：当 mView.getAnimation() != null ​时，parent.removeView() 并不会detach 掉 mView，而是暂时将 mView 放入的成员变量 mDisappearingChildren 中，在 parent.dispatchDraw() 中当 mView.getAnimation() != null 且 动画已经结束时，才执行 mView 的 detach逻辑。但是当动画中途执行 mView.StartAnimation(newAnimation) 时， parent.dispatchDraw() 中 mView.getAnimation() 所获取的对象已经变了，那么 detach 的时机也就变了。

上述代码的执行顺序大致为：mView.startAnimation(disappearAnimation) -> parent.removeView -> mDisappearingChildren.add(mView) -> parent.addView -> mView.attach -> mView.startAnimation(appearAnimation) -> appearAnimation.end -> mDisappearingChildren.remove(mView) & mView.detach。最终 mView 处于 detach 状态，故而 View 会假死。

现实场景：​当 fragment A 切换到 fragment B 时，如果转场动画还没结束时就快速按返回键使 fragment B pop 掉，最终会造成页面假死在 fragment A 上。QMUI 上就遇到这个问题，具体解决措施也可参考参考

MIUI8 USB开发过程中禁用装包提示：设置->更多设置->开发者选项->关掉MIUI优化，重启，再进入安全中心->授权管理->右上角的小齿轮->关掉USB安装管理

ListView、GridView 在 getView 时要避免调用 View 的 setLayoutParam。因为 setLayoutParam 会触发 requestLayout 导致 ListView 刷新 layout，而 ListView 重新 layout 时又可能触发 getView，导致多次甚至循环 layout。这种循环 layout 会产生以下几个现象：

1. 1. child 点击时背景消失或者无法触发点击行为
   
2. 2.  uiautomatorviewer 查看时部分节点无法选中，因此也无法查看其信息

当 Activity 设置了 android:windowIsTranslucent 后，其屏幕旋转取决于透明 Activity 背后的那个 Activity，我们可以把透明 Activity 当做一种特殊的 Dialog，这样大致可以理解 Android 开发团队为何要这样做了。如果我们需要动态修改旋转特性，我目前有两种方案：

1. 1. 添加 android:screenOrientation="sensor" ，让透明 Activity 的旋转完全取决于传感器，这样做的代价就是系统的屏幕旋转设置将失效。
   
2. 2. 修改透明 Activity 的 screenOrientation 同时，修改背后的那个 Activity 的 screenOrientation。如果你有建立自己的 ActivityManager，那你可以精确定位背后的那个 Activity，否则就只能通过 EventBus 传递这个通知，其它 Activity 在接收到通知时，如果自身依旧是可见状态，那么就处理这个消息。（透明 Activity 背后的那个 Activity 不会调用 onStop）

当 Activity 设置了 android:windowIsTranslucent 或者 android:windowIsFloating 后，默认情况下 onConfigurationChanged 就不再被调用到，因为这种情况下会触发透明 Activity 后的那个 Activity 的绘制（耗费性能），必要时候需要添加 android:screenOrientation="sensor" 强制使旋转生效。

ViewPager 的 PagerAdapter 存在一个方法 setPrimaryItem，在 item 被认为是 “primary” 时会被调用。但是其在 ViewPager.onMeasure 时也会调用到，如果使用不当，可能会造成死循环。

App 的 Context 的数量 = Activity 的数量 + Service 的数量 + 1（Application）

用 Activity A 去启动一个 Translucent Activity B，那么 Activity A 将不会调用 onStop 方法，因为 onStart 与 onStop 对应于 visible lifetime。只有当 Activity 不可见时，onStop才会调用。

Android Launch-Time Performance

自定义 View 在定义 attr 时需要注意： attr 的 name 不能是系统已有的，也不能是第三方库已经定义的，也不能是项目已经定义了的。推荐加上前缀来避免冲突。

RecylerView 使用 LinearLayoutManager 时，需要注意 LinearLayoutManager 的 generateDefaultLayoutParams() 默认返回的宽高都是 WRAP_CONTENT，如果我们希望 orientation 为 VERTICAL 且 子元素 宽度 MATCH_PARENT 时，我们需要重写 generateDefaultLayoutParams() 来达到目的。

clipToPadding 和 clipChildren 是我们经常用于更改 View 绘制区域的手段，但这二者的作用点并不相同，要注意区分：

• clipToPadding：是作用用 ViewGroup 自己，setClipToPadding(false) 是允许 children 在自己的padding区域绘制。
  
• clipChildren：是作用于 ViewGroup 的 children, setClipChildren(false) 是告诉 children 可以在自己的 Bounds 外绘制。

clipToPadding 在 ListView 等滚动容器能满足“默认存在padding, 而滚动时没有padding”的视觉效果。

clipChildren 经常用于 ViewGroup 的子元素的子元素需要扩大其绘制范围的情况（作用目标和 setClipChildren 的 View 跨级）。

Android 开发中，每个界面（Activity 或 Fragment）的 View 的 id 应当避免重复（像 ListView 的 itemView 这种原本就带有复用机制的View除外）。因为 View 状态的保存与恢复与 id 息息相关， 如果一个界面有多个相同的id， 在状态恢复时可能出错。详情请看： android中正确保存view的状态

一般情况下，我们不会去可以制造 id 重复的情况，但如果我们同一个界面使用了很多相同的组件，而这个组件内部有定义 id,  就有可能造成这种 View 状态混乱的情况

Android View 在使用 LayoutParam 时，需要根据其父 View 而使用相应的 LayoutParam，Android 5.0 以后有了较大的容错性，即使 LayoutParam 错误也不会有什么问题，但在 4.x 的手机上就会 crash。开发过程中需要注意，开发结束后也应当使用 4.x 的手机多验证验证。

android中资源访问有两个符合：“@” 和 “?”:

@：如@color、@string、@drawable，表示去取已经定义好的资源

?：?attr，表示去对应的 theme 中获取相应的资源，不同的 actvitiy 可以有不同的 theme， 因此取出来的值就可以不一样。

Android 冷启动白屏的原因和解决方案：

原因：当系统启动应用的 Activity 时，如果该Activity所属的Application还没有启动，那么系统会为这个Activity创建一个进程，进程创建完成后，Activity 才会继续自己的流程，由于创建进程需要花费时间，WindowManager会先加载APP里的主题样式里的窗口背景（windowBackground）作为预览元素。

解决方案：

方法一：设置窗口背景（windowBackground）为一张图片作为欢迎页。

方案二：设置第一个 Activity 为透明Activity, 再由第一个 Activity 启动业务 Activity，这样用户最开始看到的将依旧是桌面。