A. android 沉浸式/透明式状态栏、导航栏
Android 从4.4开始引进透明状态栏和导航栏的概念，并且在5.0进行了改进，将透明变成了半透明的效果。虽然此特性最早出现在ios，但不否认效果还是很赞的。
至于4.4以下的手机，就不要考虑此特性了，好在4.4以下的手机份额已经非常小了。
我们先来看一下透明状态栏的实现，两种常见效果图如下：
虚拟导航栏并不是所有的手机都有，华为的手机多比较常见，就是上图屏幕底部按钮那块区域。设置导航栏和状态栏类似：
这是官方的解释，大致意思就是我们在布局的最外层设置 android:fitsSystemWindows="true"，会在屏幕最上方预留出状态栏高度的padding。
由于fitsSystemWindows属性本质上是给当前控件设置了一个padding，所以我们设置到根布局的话，会导致状态栏是透明的，并且和窗口背景一样。
但是多数情况，我们并不在根布局设置这个属性，我们想要的无外乎是让内容沉浸在状态栏之中。所以我们经常设置在最上端的图片背景、Banner之类的，如果是Toolbar的，我们可以使用一层LinearLayout包裹，并把这个属性设置给LinearLayout，这样就可以避免Toolbar的内容下沉了。如：
上述方法可以解决普通页面的透明式状态栏需求，如有复杂需求可以参考下面这些：
Android 系统状态栏沉浸式/透明化完整解决方案
Android 沉浸式状态栏的实现
Android沉浸式状态栏(透明状态栏)最佳实现
还有开源库推荐： ImmersionBar
B. 如何使用Android ConstraintLayout
ConstraintLayout最低兼容Android 2.3；
目前Android Studio 2.3默认使用ConstraintLayout作为布局文件的根布局；
想要使用ConstraintLayout，需在项目的build.gradle添加com.android.support.constraint:constraint-layout：XXX版本号依赖；
C. 关于Android布局你不知道的
Android常见的5个布局，我想大家一定不会陌生。LinearLayout、RelativeLayout和FrameLayout也是使用频率较高的布局方式，做Android开发的一定使用过。
传统的5种布局方式：
不过我的问题并不是问面试者如何使用这些基础的布局，而是要看面试者怎么解决布局嵌套（影响性能）和屏幕适配问题。
我们都清楚Android界面的布局太复杂，嵌套层次过深，会使整个界面的测量、布局和绘制变得更复杂，对性能会造成影响。所以我们在写Layout文件时，也要尽量避免布局的嵌套层次过深的问题。
在怎么解决问题之前，我们得有一个好方法先判断当前的问题情况。Android SDK工具箱中有一个叫做Hierarchy Viewer的工具，能够在App运行时分析Layout。
注意： 在ROOT的手机，或者是安装开发版的ROM的手机可以直接使用Hierarchy Viewer。如果没有Root的手机(SDK 4.1及以上)，需要在你的PC端添加一个环境变量“ANDROID_HVPROTO=ddm”。
下面列举一些面试者常使用的方式。
merge merge标签的作用是合并UI布局，使用该标签能降低UI布局的嵌套层次。
merge标签可用于两种情况：
ViewStub ViewStub标签引入的布局默认不会inflate，既不会显示也不会占用位置。 ViewStub常用来引入那些默认不会显示，只在特殊情况下显示的布局，如数据加载进度布局、出错提示布局等。
需要在使用时手动inflate:
ViewStub在一定的程度可以起到减少嵌套层次的作用，特别是很多时候我们的程序可能不需要走到ViewStub的界面。
include 将可复用的组件抽取出来并通过include标签使用，但<include>标签能减少布局的层次吗？
我认为不能。include主要解决的是相同布局的复用问题，它并不能减少布局的层次。
用RelativeLayout代替LinearLayout
很多人为了减少布局层次喜欢用RelativeLayout代替LinearLayout，不过可能达到的效果并不会很明显。层次是减少了，但本身RelativeLayout就会比LinearLayout性能差一点。
有一些界面，比如一个图片和一个文本的布局（ListItem常见的布局方式），可以利用TextView有drawableLeft, drawableRight等属性，完全不需要RelativeLayout或者LinearLayout布局。
传统的布局方式存在一定的缺陷，如RelativeLayout要两次测量（measure）它的子View才能知道确切的高度；如果LinearLayout布局的子View有设置了layout_weight，那么它也需要测量两次才能获得布局的高度。
相对于传统的布局方式，Android官方还推出了两种新的布局方式：ConstraintLayout和FlexboxLayout。
ConstraintLayout ConstraintLayout即约束布局，在2016年由Google I/O推出。ConstraintLayout和RelativeLayout有点类似，控件之间根据依赖关系而存在，但比RelativeLayout更加灵活。创建大型复杂的布局仍然可以使用扁平的层级(不用嵌套View Group)，说的简单些就是，再复杂的界面也可以只有2层层次。
要使用ConstraintLayout需要在build.gradle中添加相关的support库：
使用ConstraintLayout可以有效的解决布局嵌套过多导致的性能问题，官方也对其渲染性能进行了优化，并且ConstraintLayout支持可视化的方式编写布局。
不过学会熟练使用ConstraintLayout会需要一点时间，但这是值得的。
FlexBoxLayout 做过前端开发（CSS方面）的同学对FlexBox一定不会陌生，最近我在做微信小程序开发时也涉及到FlexBox。FlexBox(弹性布局)是w3c在2009年提出的一种新的布局方案，解决以前那种传统css的盒模型的局限性。
Google开源了FlexboxLayout布局和前端CSS FlexBox布局具有相同的功能（肯定有不一样的地方），但已经足够在Android上改进布局的构建方式。
FlexBoxLayout可以理解成一种更高级的LinearLayout，不过比LinearLayout更加强大和灵活。如果我们使用LinearLayout布局的话，那么不同的分辨率，也许我们要重新调整布局，势必会需要跟多的布局文件放在不同的资源目录。而使用FlexBoxLayout来布局的话，它可以适应各种界面的改变（所以叫响应式布局）。
如果对前端的Flexbox不太了解的话，你还需要补一些概念，好在这些东西在网上很容易找到。
可能很多读者会觉这样的面试题是吹毛求疵，很多项目中哪有这么复杂的界面，根本就用不到这些优化措施。
可以说厉害的人，或者叫高手，可能只是比较多在意这些细节而已。在实践中的经历告诉我，很多难于解决的性能问题，并不是因为有一个影响性能的问题无法攻克，而是没有一个明显的制约因素，是有各种小问题一点一点堆积起来，最终积重难返。
所以，把细节做好，或者意识到细节的地方可能引发的问题，对我们解决问题是很有帮助的，不要浪费了让你可以成长的细节。
有需要更多Android高级进阶和面试资料的朋友可以私信我获取
D. 安卓视图层级大揭秘
最近接了一个语音控制的功能，UI上的具体实现就是在应用上遮盖一个透明防触层，在语音状态下阻止用户点击，但不能影响物理返回键的Dialog呼出即控制，同时对于非物理返回键呼出的Dialog也要阻止操作。功能看起来很绕，我们用一张图片来具体说明一下。
通过图片不难看出，我们要实现的语音控制层其实是介于应用视图与视图内部提示框之上，同时又在Back返回键弹窗之下的一个层级。因为一直以来对安卓视图层级的探究不是很深入，所以借着做这个功能对安卓视图层级这一块的知识进行了一下总结梳理。
首先让我们通过一张层级图来明确几个重要的概念Window，DecorView和mContentParent。
在Android中不管是Activity、Toast、ActionBar还是Dialog，他们的视图都是附加到Window上，其实基本上所有的view同时通过Window来呈现的，因此Window可以理解为是view的承载者和管理者。Window 有三种类型，分别是应用 Window、子 Window 和系统 Window。应用类 Window 对应一个 Acitivity，子 Window 不能单独存在，需要依附在特定的父 Window 中，比如常见的一些 Dialog 就是一个子 Window。系统 Window是需要声明权限才能创建的 Window，比如 Toast 和系统状态栏都是系统 Window。
DecorView是Windows中的View的最顶层View。其实DecorView是FrameLayout的子类，它里面包含了一个存有ActionBar以及mContentParent的LinearLayout。
mContentParent这个名字可能会有些陌生，其实他就是我们经常使用的应用根布局，即android.R.id.content。Activity中的setContentView其实就是通过LayoutInflater将XML布局转换成View并添加到mContentParent中。
每个Activity都会持有一个Window，而在安卓中，Window只有唯一的一个实现类PhoneWindow ，所以每个Activity都会持有一个PhoneWindow，在PhoneWindow中会持有顶层视图DecorView。那么Activity是怎么建立与PhoneWindow的联系的呢，让我们通过源码来探究一下：
在Activity的启动过程中会执行ActivityThread的performLaunchActivity方法，其中调用Activity的attach。在attach()方法中实例化Activity持有的mWindow。由于 Activity 实现了 Window 的 Callback 接口，因此当 Window 接受到外界的状态改变时就会回调 Activity 的方法。
可以看到，在PhoneWindow里面，出现了成员变量DecorView。而这里，DecorView则是PhoneWindow里面的一个内部类，它是继承于FrameLayout。
这是我们每次写Activity都会调用的setContentView方法，它的内部调用了getWindow()的setContentView，这个mWindow就是PhoneWindow。
我们看到在PhoneWindow中有三个setContentView的重载方法。在setContentView(int layoutResID)中，首先判断了mContentParent ，如果mContentParent 为空即为第一次调用的时候，就执行installDecor()方法，创建DecorView，并添加到mContentParent上。如果mContentParent不为空，那么将mContentParent中的view移除。接着通过mLayoutInflater将XML转换为View树，并且添加至mContentParent视图中。 添加完成后回调通知onContentChanged，表示完成界面加载。
首先判断mDecor是否为空，如果为空则通过generateDecor创建一个DecorView，紧接着设置DecorView的获取焦点能力为FOCUS_AFTER_DESCENDANTS，即先分发给Child View进行处理，如果所有的Child View都没有处理，则自己再处理。第一次DecorView未加载到mContentParent，所以mContentParent为空，调用generateLayout将setContentView内容添加到mContentParent。
定制过Acitivity的Actionbar或是Fullscreen的同学一定都知道，requesetFeature方法需要在setContentView之前调用，这就是原因。setContentView的实质显示是触发了Activity的resume状态，也就是触发了makeVisible方法。
这里将getWindow().getAttributes()作为了LayoutParams，在WindowManager中：
可以看到Activity的窗口类型是TYPE_APPLICATION，这个TYPE类型决定了在Window层的显示层级，TYPE类型总览如下：
Dialog不属于View，他是应用的子window，所以这也是为什么我们通过给mContentParent添加view无法实现遮挡Dialog的原因。Dialog 中 Window 同样是通过 PolicyManager 的 makeNewWindow 方法来完成的，普通的 Dialog 必须采用 Activity 的 Context，如果采用 Application 的 Context 就会报错。这是因为没有应用 token 导致的，而应用 token 一般只有 Activity 拥有。常规Dialog的TYPE为TYPE_APPLICATION_ATTACHED_DIALOG，通过不同的TYPE层级划分我们可以找到置于常规Dialog之上的WindowManager LayoutParams 属性，例如TYPE_SYSTEM_ALERT与TYPE_TOAST，设置了这两个属性的布局是可以将常规Dialog完全遮盖的。他们的区别在于一个是系统级别的Dialog一个是Toast，系统Dialog需要申请权限。所以我们的第一个方案就是可遮挡的Dialog使用常规Dialog，语音提示框采用TYPE_SYSTEM_ALERT。但是都知道安卓有一个无法逃避的问题，就是厂商定制，在MUI的framework层，出于对“安全”的考虑，默认为用户关闭了悬浮窗权限，也就是是说设置了TYPE_SYSTEM_ALERT属性的视图默认是无法显示的，需要用户手动开启权限以后方可显示。
虽然可以在用户启动的时候根据用户机型选择跳转开启权限页，但作为一个有情怀的开发这种不完美的体验还是不能接受的。根据之前对安卓视图层级的学习，我们有了第二套方案。应用视图是存放于mContentParent他与Activity同属TYPE_APPLICATION Window层级属于最下层，常规Dialog的层级是TYPE_APPLICATION_ATTACHED_DIALOG，所以我们将常规Dialog作为最上层不可遮挡的提示框，下面只需考虑可遮挡的弹窗与语音控制两层即可。因为语音控制层需要能够遮挡提示弹窗，所以需要语音控制层在弹窗的上层，经过之前的学习，我们把弹窗加入到mContentParent，把语音控制层添加到DecorView层即可完美的解决问题。mContentParent为一个FrameLayout，应用视图通过sentContentView率先添加到mContentParent中，作为提示弹窗，添加顺序一定相对应用视图置后，所以当提示弹窗再次向mContentParent添加的时候，即会添加到应用视图之上。而DecorView是mContentParent的父容器，也是一个FrameLayout，添加语音提示框的时候mContentParent一定已经存在，所以添加的时候一定会在mContentParent之上。
就这样，一个看似复杂的需求通过对安卓源码的探究完美的解决了，很多时候当我们遇到难以解决的问题，不妨试试回到问题的原点，思考一下问题的本质，很多时候都会有不一样的发现。
E. 关于android的购物车功能是怎么实现的
1.页面布局根布局用相对布局，其中有两个子布局，有一个子布局null_layout来放空数据时需要展示的页面visibility设为gone，另一个子布局就是你有数据显示的样子，请求服务器购物车或者本地数据库查询时，若无则将null_layout的visibility设为visible，有则又设成gone就行2.这个逻辑不对啊，商品列表点一下不是应该去商品详情，然后用户自己再选择加入购物车并选数量么，怎么就直接加入购物车了...一般做购物车都会做本地数据库，加入购物车按钮被点击就向本地插入一条数据到数据库并发请求告诉后台也同步，商品数量是用户选的，价格是自己算的（单价*数量），购物车显示时查这个表就行
F. Android 中 怎么动态修改布局xml文件中的根属性值 比如如下图的两个属性值 fitsSystemWindows 改为 false
给这个RelativeLayout设置一个id，比如 android:id="@+id/rl"
然后在class文件中获取此控件，再设置属性即可
java">RelativeLayoutrelativeLayout=(RelativeLayout)findViewById(R.id.rl);
relativeLayout.setFitsSystemWindows(false);