使用 View.setBackgroundResource(resource) ​时，不能随意调用 View.getBackground().setAlpha()​，因为这会使得 alpha 直接作用于这个 resource，会影响到 App 中使用这个 resource 的所有地方。

案例：QMUITopBar​ 中提供了 setBackgroundAlpha() ​这个方法，是通过 getBackground().setAlpha()​ ​来实现的，因此使用 setBackgroundResource（R.drawable.xxx）和 setBackgroundResource（R.color.xxx）时都有可能影响到全局 resource，这也就埋下了坑点。

横竖屏切换时，如果 Activity 有设置 android:configChanges="orientation|keyboardHidden|screenSize" ​时， Activity 会调用 onConfigurationChanged ​。 否则，Activity 会销毁当前实例，重新构造新的实例，生命周期也会重新走一次：onPause() →onStop()→onDestroy()→onCreate()→onStart()→onResume() ​

ART 日志消息格式

​ART 不会为未明确请求的垃圾回收记录消息。只有在认为垃圾回收速度较慢时才会打印垃圾回收（垃圾回收暂停时间超过 5ms 或垃圾回收持续时间超过 100ms）

I/art: <GC_Reason> <GC_Name> <Objects_freed>(<Size_freed>) AllocSpace Objects, <Large_objects_freed>(<Large_object_size_freed>) <Heap_stats> LOS objects, <Pause_time(s)>

示例：

I/art : Explicit concurrent mark sweep GC freed 104710(7MB) AllocSpace objects, 21(416KB) LOS objects, 33% free, 25MB/38MB, paused 1.230ms total 67.216ms

解析

<GC_Reason>:

• Concurrent：不会暂停应用线程的并发垃圾回收。此垃圾回收在后台线程中运行，而且不会阻止分配。
• Alloc：应用在堆已满时尝试分配内存引起的垃圾回收
• Explicit：由应用明确请求的垃圾回收（会阻止分配线程并浪费不必要地 CPU 周期）​
• NativeAlloc：原生分配（如位图或 RenderScript 分配对象）导致出现原生内存压力，进而引起的回收
• CollectorTransition：由堆转换引起的回收；此回收由运行时切换垃圾回收引起。回收器转换包括将所有对象从空闲列表空间复制到碰撞指针空间（反之亦然）。当前，回收器转换仅在以下情况下出现：在 RAM 较小的设备上，应用将进程状态从可察觉的暂停状态变更为可察觉的非暂停状态（反之亦然）
• HomogeneousSpaceCompact：齐性空间压缩是空闲列表空间到空闲列表空间压缩，通常在应用进入到可察觉的暂停进程状态时发生。这样做的主要原因是减少 RAM 使用量并对堆进行碎片整理
• DisableMovingGc: 这不是真正的垃圾回收原因，但请注意，发生并发堆压缩时，由于使用了 GetPrimitiveArrayCritical，回收遭到阻止。一般情况下，强烈建议不要使用 GetPrimitiveArrayCritical，因为它在移动回收器方面具有限制。
• HeapTrim：这不是垃圾回收原因，但请注意，堆修剪完成之前回收会一直受到阻止

<GC_Name>:

• Concurrent mark sweep (CMS)​：整个堆回收器，会释放和回收映像空间以外的所有其他空间
• Concurrent partial mark sweep：几乎整个堆回收器，会回收除了映像空间和 zygote 空间以外的所有其他空间
• Concurrent sticky mark sweep：生成回收器，只能释放自上次垃圾回收以来分配的对象。此垃圾回收比完整或部分标记清除运行得更频繁，因为它更快速且暂停时间更短
• Marksweep + semispace：非并发、复制垃圾回收，用于堆转换以及齐性空间压缩（对堆进行碎片整理）

<Objects_freed>(<Size_freed>):

​此次垃圾回收从非大型对象空间回收的对象数量与大小

<Large_objects_freed>(<Large_object_size_freed>):

​此次垃圾回收从大型对象空间回收的对象数量与大小

<Heap_stats>:

​空闲百分比与（活动对象数量）/（堆总大小）

​<Pause_time(s)>:

​通常情况下，暂停时间与垃圾回收运行时修改的对象引用数量成正比。当前，ART CMS 垃圾回收仅在垃圾回收即将完成时暂停一次。移动的垃圾回收暂停时间较长，会在大部分垃圾回收期间持续出现

内存耗用：

• VSS(Virtual Set Size)​: 虚拟耗用内存（包含共享库占用的内存
• RSS(Resident Set Size): 实际使用物理内存（包含共享库占用的内存）
• PSS(Proportional Set Size): 实际使用的物理内存（比例分配共享库占用的内存）
  
• USS(Unique Set Size): 进程独自占用的物理内存（不包含共享库占用的内存）

备注：1，2，3，4 表示 ABI 优先级递减。应用安装到设备时，只有该设备的 CPU 架构支持的最优 so 库才会被安装。

Android 开启 开发者模式 -> GPU呈现模式 ​可以方便我们观察界面是否丢帧：

绿色水平线：代表16ms，要确保一秒内打到 60fps，你需要确保这些帧的每一条线都在绿色的 16ms 标记线之下。

Android 6+ 柱形图颜色说明：

Android 4.x 和 Android 5.x 柱形图颜色说明：

官网地址：https://developer.android.com/studio/profile/inspect-gpu-rendering

在开发过程中，我们很容易遇到一个现象：界面上 ViewPager 或者 RecyclerView 或者 ListView 显示空白，但是有数据，用 Layout Inspector 查看时，显示正常。 有时候滚动就能恢复正常。

那这是什么原因呢？

一个可能的因素就是多个 RecyclerView(ViewPager, ListView) 设置了同一个 Adapter。一个场景就是 Fragment -> onCreateView 每次都重新 new 一个RecyclerView，然后设置同一个 Adapter，这样再从新界面返回时，旧的 RecyclerView 还没释放时，就存在多个 RecyclerView 引用同一个 Adapter。当然还存在其它场景，这值得我们注意！

context.getResources().getDisplayMetrics().heightPixels ​的含义：

一般情况下，它等于屏幕真实高度 - 导航栏高度。然后在 Android P 上， 它等于 屏幕真实高度 - 导航栏高度 - 刘海高度。

​​但是总有意外发生，某些全面屏手机（例如小米、vivo），在设置上提供了 导航栏/全面屏手势 选项，如果选择全面屏手势，界面是不存在导航栏的，但是 context.getResources().getDisplayMetrics().heightPixels 的值依然会减掉这个不存在的导航栏的高度，这就导致依赖它的相关计算就会不准确。。。。

RecyclerView 在 ItemAnimator 的辅助下，item 的“增”、“删”动画非常完美，但是“改”的动画并不总是被需要，容易给用户闪烁的感觉。因而，官方在 SimpleItemAnimator 里添加了方法 setSupportsChangeAnimations 来供开发者选择是否需要“改”的动画。

val  itemAnimator = DefaultItemAnimator()
itemAnimator.supportsChangeAnimations = false
mRecyclerView.itemAnimator = itemAnimator

使用 EditText 的 setInputType ​方法的一个麻烦点在于: 很多时候设置一个属性是不生效的，往往需要同时设置多个属性才能生效。 例如：

// 密码
EditorInfo.TYPE_CLASS_TEXT | EditorInfo.TYPE_TEXT_VARIATION_PASSWORD
// 纯数字密码
EditorInfo.TYPE_CLASS_NUMBER | EditorInfo.TYPE_NUMBER_VARIATION_PASSWORD
// 小数
InputType.TYPE_CLASS_NUMBER | InputType.TYPE_NUMBER_FLAG_DECIMAL

Android Studio 3.0 会默认在 debug 包的 manifest 文件里添加 android:testOnly="true"属性，导致 IDE 中跑出的 apk 在大部分手机上只能用 adb install -t <apk>来安装，在 oppo, vivo 等手机上甚至安装不了，会出现下列错误提示：

Failed to install app-debug.apk: Failure [INSTALL_FAILED_TEST_ONLY: installPackageLI]

这个时候可以在 gradle.properties 文件中添加下列配置：

# gradle.properties
android.injected.testOnly=false

Android 从 API 24 版本开始支持 multiple windows。那么 app 就可能处于 visible 状态而不处于 active 状态，即处于 onStart 状态。

关于 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）