做Android开发的朋友应该都有感受这几年几乎所有主流App都标配了侧滑菜单。我当时第一次在项目里接到“做个侧滑菜单”的需求时第一反应是找第三方库后来踩了一堆坑才明白系统自带的DrawerLayout(官方侧滑菜单)才是最适合大多数场景的方案。这个控件解决的是导航空间不足的问题主界面塞不下太多入口那就把高频功能藏在左侧抽屉里需要时手指一滑就出来不需要时往右一拨就收回。它的好处是官方维护、手势成熟、和Toolbar联动非常顺滑而且不需要引入额外的第三方依赖。这篇博文面向刚接触Android布局的初学者也适合那些用了很久第三方侧滑库但想回归原生方案的人。我会从布局结构、关键参数、完整实现步骤到常见坑点全部过一遍保证你跟着操作就能做出一个能跑起来的侧滑菜单Demo。1. 为什么非要用DrawerLayout不可1.1 侧滑菜单到底解决了什么问题先说说需求背景。移动端屏幕就那么大底部导航和顶部Tab能承载的入口数量非常有限。一旦功能模块超过五六个导航就成了难题。侧滑菜单的思路是给App增加一个“隐形空间”正常情况下完全不可见不占屏幕面积用户想看的时候轻轻一滑就能把整组入口呼出来。除了充当功能入口的目录侧滑菜单还承担着展示用户信息、放设置项、放关于页的作用。我在实际项目里最常见的布局结构是顶部Toolbar放汉堡包按钮主内容区放默认页面左侧抽屉放用户头像、昵称、菜单列表底部再放一个退出登录按钮。这种结构比在主页面上堆满按钮要清爽得多也让产品经理有了一个“什么都能往里塞”的统一收纳区。如果把这种导航做成自定义View像素级控制滑动手势、边界阻尼、遮罩透明度工作量相当大。而DrawerLayout把这些底层逻辑都封装好了开发者只需要在XML里声明布局在Activity里调几个方法侧滑交互就完整了。对初学者来说它是最短路径对老手来说它是不会出错的兜底方案。1.2 对比第三方侧滑库原生方案好在哪当年市面上确实流行过一些第三方侧滑菜单库各有特色有的能支持左右双侧滑出有的能做缩放和视差动画视觉效果确实花哨。但用久了你会发现一个尴尬事实第三方库的维护频率不可控一旦系统升级、兼容性出问题你就得被迫改代码甚至换库。DrawerLayout作为官方组件优先级更高兼容性也有保证。它不需要额外下载依赖在绝大多数开发环境里配置好的基础依赖里就已经包含。使用官方控件还有一个很大的优势系统级的手势语义。比如抽屉打开状态下用户按返回键时DrawerLayout默认就会拦截这个事件优先关闭侧滑菜单而不是直接退出Activity。这个返回语义是第三方库很难完全做齐的但在官方方案里是默认行为。另外DrawerLayout和系统导航栏、状态栏、Toolbar的配合文档和示例非常多网上遇到问题几乎都能搜到答案。这也是我后来坚定使用原生方案的原因——少折腾多完成业务功能才是工程效率的正道。2. 把DrawerLayout的套路摸清楚再动手2.1 布局结构是三层嵌套的“潜规则”刚开始接触DrawerLayout的人最容易犯的错误是布局结构不对。DrawerLayout的使用有一条硬性规定它必须作为根布局且里面第一个子View是主内容区第二个子View才是侧滑菜单。顺序不能反过来这个顺序决定了主内容区和抽屉区域的重叠关系。主内容区一般用FrameLayout或者你原本的页面根布局充当它的宽高必须写成match_parent。第二个子View是侧滑菜单我一般用NavigationView也可以用自定义的LinearLayout但有一点绝对不能含糊必须给它设置layout_gravity属性指定方向比如start表示从左边缘滑出。如果不写这个属性DrawerLayout就不知道这个View该从哪一侧滑入运行时直接报错。我来贴一个最基础的结构示例androidx.drawerlayout.widget.DrawerLayout xmlns:androidhttp://schemas.android.com/apk/res/android xmlns:apphttp://schemas.android.com/apk/res-auto android:idid/drawer_layout android:layout_widthmatch_parent android:layout_heightmatch_parent !-- 主内容区索引0 -- FrameLayout android:idid/main_content android:layout_widthmatch_parent android:layout_heightmatch_parent TextView android:layout_widthwrap_content android:layout_heightwrap_content android:layout_gravitycenter android:text这是主内容区域 / /FrameLayout !-- 侧滑菜单索引1 -- com.google.android.material.navigation.NavigationView android:idid/nav_view android:layout_width240dp android:layout_heightmatch_parent android:layout_gravitystart app:menumenu/drawer_menu / /androidx.drawerlayout.widget.DrawerLayout这段代码里有个细节值得注意侧滑菜单宽度我直接给死了240dp。这不是随意写的Material Design规范里抽屉菜单宽度一般就是240dp到280dp之间。太窄了文字放不下太宽了主内容区被遮挡得太多交互体验会很压抑。在实际适配中我也建议你不要用wrap_content因为菜单项长度不可控适配容易出问题固定宽度是最稳的方案。2.2 关键属性一次说清gravity、scrim、lockMode之前做项目时我整理过一份DrawerLayout常用属性清单现在最常用的是下面几个。第一个是layout_gravity。刚才提过start和left在大部分场景效果一致但start是逻辑方向跟随系统语言左右切换left是物理方向永远在左边。现在的Android开发里我建议统一使用start同时配套使用GravityCompat.START来替代Gravity.LEFT这样在RTL语言环境下也能正确表现。第二个是scrimColor。侧滑菜单滑出来时主内容区上方会覆盖一层半透明遮罩这个遮罩的默认颜色是黑色半透明。如果你想调整深浅可以用app:scrimColor属性指定比如app:scrimColor#66000000。这个遮罩的主要作用是让视线聚焦到侧滑菜单上同时把主内容区压暗形成层级感。不要把它写成完全透明的否则主内容区没有被遮挡的视觉反馈用户会感觉菜单和内容是叠在一起的平板缺少景深。第三个是DrawerLayout的锁模式。有些页面上我们不希望用户滑出抽屉比如玩全屏游戏、看视频的时候。这时候用setDrawerLockMode最合适// 关闭手势和代码调用 drawerLayout.setDrawerLockMode(DrawerLayout.LOCK_MODE_LOCKED_CLOSED); // 恢复正常 drawerLayout.setDrawerLockMode(DrawerLayout.LOCK_MODE_UNLOCKED);锁模式有三种状态UNLOCKED、LOCKED_CLOSED、LOCKED_OPEN。LOCKED_OPEN是让抽屉保持打开且无法滑动关闭用的场景很少我一般只在前两种之间切换。这个属性的价值在于它在系统层面帮你禁止了手势不需要你去拦截TouchEvent非常省心。最后一个我认为值得提的是fitsSystemWindows。如果你需要让侧滑菜单的内容延伸到状态栏下面实现沉浸式效果就要给DrawerLayout设置android:fitsSystemWindowstrue同时给菜单子View也设置同样的属性。这里的坑在于两边都要配合只设置一边会导致状态栏颜色或者布局错乱。我在初学的时候就是只给DrawerLayout设置了属性结果菜单顶部多了一块空白排查了半天才发现是两边不一致导致的。3. 完整实操从零搭建一个侧滑菜单Demo3.1 第一步搭建菜单资源与布局XML动手做Demo之前先把菜单项资源准备好。在res/menu目录下新建一个drawer_menu.xml文件用来声明侧滑菜单里显示哪些条目。menu xmlns:androidhttp://schemas.android.com/apk/res/android item android:idid/nav_home android:icondrawable/ic_home android:title首页 / item android:idid/nav_messages android:icondrawable/ic_message android:title消息 / item android:idid/nav_settings android:icondrawable/ic_settings android:title设置 / /menu这里的icon资源我假设你已经准备好实际开发中可以从UI切图里拿或者用矢量图。如果你只是快速测试用系统自带的android.R.drawable.ic_menu_edit这类资源也可以。然后回到主布局XML按照刚才讲的“根布局-第一个孩子-第二个孩子”结构写完。这里有一个新手容易忽略的细节侧滑菜单子View必须紧跟在主内容区后面写不要中间插入其他同级View。如果插入第三个子ViewDrawerLayout会把它也当作一个抽屉来处理逻辑就乱套了。布局写好之后打开预览面板你应该能看到主内容区占据整个屏幕往左划的时候菜单才会出现。如果预览里直接看到菜单覆盖在主内容区上说明你的layout_gravity忘记写了回去检查一下。3.2 第二步在Activity里把抽屉“接”出来布局就绪后接下来写Activity代码。核心工作是三件绑定控件、设置监听、联动Toolbar。public class MainActivity extends AppCompatActivity { private DrawerLayout drawerLayout; Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); drawerLayout findViewById(R.id.drawer_layout); // 给抽屉设置滑动手势监听 drawerLayout.addDrawerListener(new DrawerLayout.DrawerListener() { Override public void onDrawerSlide(NonNull View drawerView, float slideOffset) { // 抽屉滑动过程中回调slideOffset从0到1 } Override public void onDrawerOpened(NonNull View drawerView) { // 抽屉完全打开时回调 } Override public void onDrawerClosed(NonNull View drawerView) { // 抽屉完全关闭时回调 } Override public void onDrawerStateChanged(int newState) { // 状态切换时回调STATE_IDLE / STATE_DRAGGING / STATE_SETTLING } }); // 代码方式打开/关闭抽屉 // drawerLayout.openDrawer(GravityCompat.START); // drawerLayout.closeDrawer(GravityCompat.START); } }这一段看起来简单但onDrawerSlide里的slideOffset参数非常有价值。它表示抽屉当前滑动比例0代表完全关闭1代表完全打开。很多视觉动效比如让头像旋转、让菜单项根据滑出距离渐变透明度都是在这个回调里根据slideOffset计算实现的。我做过一个需求侧滑菜单背景是一张大图要求菜单滑出时图片跟着做视差移动其实就是让图片的translationX等于slideOffset乘以菜单宽度的一半效果立马就出来了。所以别急着把这个监听器只留空实现多想想它还能用在哪些动画场景。3.3 第三步汉堡包按钮联动让侧滑栏“有入口也有出口”光靠手势滑动打开菜单还不够用户习惯了点击左上角汉堡包按钮来切换抽屉状态。传统写法要手动处理按钮点击事件现在用ActionBarDrawerToggle可以一步到位。Toolbar toolbar findViewById(R.id.toolbar); setSupportActionBar(toolbar); ActionBarDrawerToggle toggle new ActionBarDrawerToggle( MainActivity.this, drawerLayout, toolbar, R.string.navigation_drawer_open, R.string.navigation_drawer_close); toggle.syncState(); drawerLayout.addDrawerListener(toggle);这段代码的作用很直接把DrawerLayout和Toolbar绑定在一起点击汉堡包按钮时自动打开或关闭抽屉同时抽屉滑出时汉堡包图标自动切换成返回箭头。syncState()用来同步当前抽屉状态避免因状态不一致导致图标方向错乱。注意用的不是过时的android.support.v7.app.ActionBarDrawerToggle而是androidx.appcompat.app.ActionBarDrawerToggle。网上很多旧教程还在用support包新项目如果依赖的是AndroidX直接照搬旧代码会报错这个细节值得留意。到这里一个能跑通的侧滑菜单Demo就已经成型了左手从屏幕边缘往右划可以打开菜单点汉堡包按钮也能打开点菜单区域外面或者点返回键都能关闭。接下来我们把这个Demo扩展到真实项目场景处理一下菜单项点击跳转和选中状态。NavigationView navigationView findViewById(R.id.nav_view); navigationView.setNavigationItemSelectedListener(new NavigationView.OnNavigationItemSelectedListener() { Override public boolean onNavigationItemSelected(NonNull MenuItem item) { int id item.getItemId(); if (id R.id.nav_home) { // 切到首页Fragment } else if (id R.id.nav_messages) { // 切到消息Fragment } else if (id R.id.nav_settings) { // 切到设置页 } // 点击后关闭抽屉 drawerLayout.closeDrawer(GravityCompat.START); return true; } });做这块的时候有两个习惯值得养成。第一个是点击菜单项之后务必调用closeDrawer关闭抽屉否则跳转过去抽屉还撑着半边屏幕用户会觉得很奇怪。第二个是onNavigationItemSelected的返回值要返回true表示这个事件已经被消费不该被继续传播。在真实项目里主内容区通常不是直接切换setContentView的内容而是用Fragment替换主区域容器。这时候整个结构依然是DrawerLayout作为根布局主内容区放一个FragmentContainerView侧滑菜单放NavigationView。菜单点击时用FragmentTransaction替换主区域里的Fragment侧滑菜单保持独立这样主内容切换完全不影响抽屉的滑出逻辑。4. 常见问题与排查技巧实录4.1 菜单滑不出来先检查这三处遇到过很多初学者跑Demo时发现侧滑菜单怎么都划不出来或者点了汉堡包按钮毫无反应。这个问题90%的情况下出在下面三个位置。第一处是布局里的layout_gravity缺失或写错位置。我之前提到过第二个子View必须设置layout_gravitystart你检查它是不是挂在DrawerLayout的直接子View上。如果挂在了内层某个LinearLayout上DrawerLayout根本不会把它识别成抽屉抽屉自然滑不出来。第二处是主内容区的宽度没有写match_parent。有些教程为了省事写成了wrap_content结果主内容区大小不确定DrawerLayout在进行滑动测量时计算错乱手势就失效了。建议任何情况下主内容区都固定用match_parent。第三处是根布局写错了。把DrawerLayout嵌套在另一个LinearLayout里面这种做法不推荐。官方设计要求DrawerLayout本身就是根布局它需要测量整个窗口来做滑动决策。如果你因为某些原因必须套一层壳请确保那个壳的宽度和高度都是match_parent否则依然会出现手势失效。另外如果以上排查都没问题检查一下是不是不小心调用了setDrawerLockMode(LOCK_MODE_LOCKED_CLOSED)或者LOCK_MODE_LOCKED_OPEN。前者手势和代码打不开后者无法关闭。这是我调试时经常被忽略的点。4.2 内容区露馅与遮罩失效的门道侧滑菜单滑出时主内容区应该呈现被遮罩压暗的效果如果你发现主内容区完全裸露或者菜单透出在主内容区之上多半和下面几点有关。先看scrimColor。如果设置成了全透明或者颜色值写错比如把#88000000写成了#880000遮罩看起来就会发红而不是正常的暗化效果。稳妥的做法是先用系统默认值跑通后再调整。再看菜单的宽度。如果菜单的layout_width写成了match_parent那菜单就会占满整个屏幕用户滑动时会感觉像打开了一个新页面看不到任何“抽屉”的层次感。侧滑菜单的宽度应该用固定值240dp是大家常用的基准值高端大屏设备上可以适当调到280dp。还有一个不容易发现的问题主内容区里面如果有View设置了android:elevation属性特别是更高一点的可能在绘制顺序上盖住遮罩层。原因是DrawerLayout的遮罩本质上是绘制在主内容区之上的一层特殊View如果主内容区的子View elevation过高就可能出现遮罩盖不住的视觉瑕疵。出现这种情况时可以给DrawerLayout也设置一个elevation让遮罩图层整体抬高。实际遇到时可以逐层试先关掉子View的elevation再开DrawerLayout的elevation。4.3 返回键和手势冲突的处理细节DrawerLayout打开时按返回键默认会先关闭抽屉而不是退出Activity这是它的内置逻辑。但如果你在Activity里重写了onBackPressed记得先判断抽屉状态Override public void onBackPressed() { if (drawerLayout.isDrawerOpen(GravityCompat.START)) { drawerLayout.closeDrawer(GravityCompat.START); } else { super.onBackPressed(); } }这个判断几乎是每个使用DrawerLayout的项目必备的跳过的话用户会觉得返回键“失灵”其实只是抽屉直接退出了应用。手势冲突的问题主要发生在菜单里放可滚动组件时。比如NavigationView的菜单项展开后里面有一个RecyclerView列表上下滑动的时候容易和DrawerLayout的横向滑动手势抢事件。针对这种情况系统内置的手势判定其实已经做了方向区分横向滑动触发抽屉纵向滑动触发列表。但如果你自定义了菜单布局里面放了横向滚动的组件就要注意了。可以在菜单子View上套一层NestedScrollView或者在列表的onTouchEvent里主动请求父View不要拦截recyclerView.addOnItemTouchListener(new RecyclerView.SimpleOnItemTouchListener() { Override public void onInterceptTouchEvent(NonNull RecyclerView rv, NonNull MotionEvent e) { if (e.getAction() MotionEvent.ACTION_MOVE) { rv.getParent().requestDisallowInterceptTouchEvent(true); } } });这种写法能有效防止父View在菜单内部继续滑动时把手势抢走。不过大多数情况下官方NavigationView自带的菜单列表已经处理好了新手自定义菜单布局时才会遇到这个场景。4.4 沉浸式状态栏与侧滑菜单的兼容方案说到沉浸式这是个老生常谈又容易翻车的场景。谈到状态栏透明化DrawerLayout有个历史遗留问题旧的设置状态栏透明的方法会让侧滑菜单的布局顶到状态栏后面导致菜单头部内容被状态栏遮挡。推荐的做法是让DrawerLayout自己处理系统栏内边距。在API 21以上给DrawerLayout设置android:fitsSystemWindowstrue同时给侧滑菜单子View也设置fitsSystemWindowstrue这样抽屉内容会自动避开状态栏高度。如果你需要完全沉浸到状态栏后面也可以手动给菜单顶部View加paddingTop值为状态栏高度获取方式如下int statusBarHeight 0; int resourceId getResources().getIdentifier(status_bar_height, dimen, android); if (resourceId 0) { statusBarHeight getResources().getDimensionPixelSize(resourceId); }这段代码获取的是系统状态栏的标准高度值拿到后可以动态设置给菜单内容。整个过程不算复杂但一定要在主内容的布局上也保持一致的沉浸策略否则一边顶到状态栏、另一边留白视觉上会很不协调。我在一个项目里因为两边策略不一致改了三轮才统一好现在都习惯写进项目的BaseActivity里统一管理。最后再分享一个小技巧DrawerLayout的滑动监听器里onDrawerStateChanged这个方法三种状态STATE_IDLE、STATE_DRAGGING、STATE_SETTLING分别表示静止、拖动中、自动回弹中。每次抽屉滑动结束进入静态状态我都会在这里做一些状态同步操作比如保存菜单选中项、埋点统计。等滑动动画完全结束再去更新数据不会因为动画打断导致UI闪烁这个小习惯让我少了很多莫名其妙的bug。