简介：这份资源面向具备一定 Java 基础、希望借助 Android Studio 实践界面开发的初学者与进阶学习者，围绕仿微信客户端界面这一典型场景，帮助读者打通从布局搭建到交互细节的完整链路。压缩包共 1041 个文件，约 24.25MB，以 flat、json、xml 等构建与布局配置为主，辅以 png、jpg 图片素材、java 源码、dex 与 class 编译产物及 gradle 构建脚本，完整保留了可运行的工程结构。内容覆盖 ConstraintLayout 布局、BottomNavigationView 底部导航、RecyclerView 聊天列表与适配器数据绑定、聊天气泡自定义 View、Glide 头像加载、VectorDrawable 图标、主题配色与页面切换动画等知识点，并附有版本控制与更新记录痕迹。已有 3103 人学习，适合对照工程源码理解仿微信界面的组织方式与实现思路。

1. 从一张聊天列表说起：为什么用 Android Studio 复刻微信界面值得认真做

很多同学接到「用 Android Studio 制作微信的界面」这个题目时，第一反应是打开布局文件拖控件，把头像、昵称、消息气泡摆得像模像样就交差。但真正做过完整项目的人都知道，界面复刻的难点从来不在「像不像」，而在「撑不撑得住」——消息列表滚动到第 200 条会不会卡、底部导航切换时 Fragment 会不会重叠、软键盘弹出后输入框会不会被顶飞。这些才是答辩时老师最爱追问、面试官最爱深挖的地方。

这套方案面向两类人：一是正在做 Android 课程设计或毕设、需要交一份结构完整可运行作品的学生；二是想通过一个高辨识度案例把 Activity、Fragment、RecyclerView、自定义 View 串起来的入门开发者。微信界面恰好覆盖了移动端最典型的几类 UI 模式——列表流、底部导航、聊天详情、朋友圈九宫格——把它拆透，等于把 Android UI 开发的主干走了一遍。下面按需求、架构、模块实现、避坑、验收的顺序展开，代码和结构都可以直接照着改。

2. 需求拆解与技术选型：四个页面、三层结构怎么定

2.1 功能边界：先划清「做什么」和「不做什么」

复刻微信界面最容易翻车的地方是范围失控。微信本身功能庞杂，如果一开始就想着把支付、小程序、视频号都塞进去，最后大概率是每个页面都半成品。我一般会先把范围压到「四个主 Tab + 一个聊天详情页」这个最小可交付集合：

明确「不做什么」同样重要：不做真实网络请求、不做账号体系、不做消息推送。数据全部用本地模拟，这样既保证可运行，又不会因为后端缺失导致答辩时页面空白。这个边界划清楚，后面所有设计都有了锚点。

2.2 技术选型：为什么是 Fragment + RecyclerView 这套组合

界面框架的选择直接决定了代码的可维护性。底部四个 Tab 的切换，常见有三种做法：多个 Activity 跳转、ViewPager 滑动、Fragment 容器替换。第一种会导致返回栈混乱，第二种在微信这种「Tab 之间不该滑动切换」的场景里体验不对，所以标准做法是单 Activity + 四个 Fragment + 底部自定义导航栏。

列表部分必须用 RecyclerView 而不是 ListView，原因很实在：ViewHolder 复用机制成熟、支持局部刷新、能配合 ItemDecoration 做分割线。聊天列表、通讯录、消息气泡三处列表全部复用同一套 RecyclerView 思路，只是 Adapter 的 item 布局不同。数据层用一个简单的本地 Repository 单例持有模拟数据，避免把数据散落在各个 Fragment 里。

依赖方面保持克制，除了 AndroidX 基础库和 Material 组件，不引入第三方 UI 框架。原因很简单：复刻微信界面的价值就在于自己写布局、自己调间距，套一个现成框架反而失去了练习意义，答辩时也讲不出东西。

2.3 工程目录：按功能分包而不是按类型分包

新手常犯的错是把所有 Activity 放一个包、所有 Adapter 放一个包，项目一大就找不到东西。我一般按功能模块分包，每个模块内部再分页面和数据：

com.example.wechatui ├── main/ # 主容器 │ ├── MainActivity.java │ └── BottomNavView.java # 自定义底部导航 ├── chat/ # 微信 Tab │ ├── ChatListFragment.java │ ├── ChatListAdapter.java │ └── ChatDetailActivity.java ├── contact/ # 通讯录 Tab │ ├── ContactFragment.java │ └── ContactAdapter.java ├── discover/ # 发现 Tab ├── profile/ # 我 Tab ├── data/ # 模拟数据与 Repository │ ├── ChatRepository.java │ └── model/ # 实体类 └── widget/ # 通用自定义 View ├── AvatarView.java └── BadgeView.java # 未读红点

这样分包的好处是：改聊天列表只动 chat 包，通用控件沉到 widget 包，数据统一走 data 包。答辩时老师问「你的项目结构怎么组织的」，这套目录本身就是答案。

3. 主框架与导航实现：单 Activity 容器怎么搭稳

3.1 底部导航栏：自定义 View 比 BottomNavigationView 更可控

系统自带的 BottomNavigationView 能用，但微信底部导航有几个细节它不好处理：选中态图标变色、未读红点叠加、点击时图标有轻微缩放。所以我一般自己写一个BottomNavView，内部用 LinearLayout 横排四个 item，每个 item 是一个图标加文字的垂直组合。

public class BottomNavView extends LinearLayout { private int currentIndex = 0; private OnTabSelectedListener listener; public BottomNavView(Context context, AttributeSet attrs) { super(context, attrs); setOrientation(HORIZONTAL); // 四个 Tab 的图标与文字资源 int[] icons = {R.drawable.ic_chat, R.drawable.ic_contact, R.drawable.ic_discover, R.drawable.ic_me}; String[] titles = {"微信", "通讯录", "发现", "我"}; for (int i = 0; i < icons.length; i++) { View item = inflate(context, R.layout.item_bottom_nav, this); ImageView icon = item.findViewById(R.id.nav_icon); TextView title = item.findViewById(R.id.nav_title); icon.setImageResource(icons[i]); title.setText(titles[i]); final int index = i; item.setOnClickListener(v -> selectTab(index)); } } public void selectTab(int index) { if (index == currentIndex) return; currentIndex = index; // 遍历刷新选中态：选中变绿，未选中变灰 for (int i = 0; i < getChildCount(); i++) { View child = getChildAt(i); boolean selected = (i == index); ((ImageView) child.findViewById(R.id.nav_icon)) .setColorFilter(selected ? 0xFF07C160 : 0xFF999999); ((TextView) child.findViewById(R.id.nav_title)) .setTextColor(selected ? 0xFF07C160 : 0xFF999999); } if (listener != null) listener.onTabSelected(index); } }

这段代码的关键点有三个：一是selectTab里先判断index == currentIndex直接返回，避免重复点击触发无谓的 Fragment 重建；二是选中色用微信标志性的绿色0xFF07C160，未选中用灰色，颜色值集中在这里方便统一调整；三是通过OnTabSelectedListener把切换事件抛给 MainActivity，导航栏本身不持有 Fragment 逻辑，职责单一。参数上，图标资源建议用矢量图 VectorDrawable，这样一套图能适配所有屏幕密度，不用准备多套 png。

3.2 Fragment 容器：用 show/hide 而不是 replace

MainActivity 里承载四个 Fragment，切换方式有两种：replace和show/hide。replace每次都会销毁重建 Fragment，聊天列表滚动位置会丢失，体验很差。正确做法是初始化时一次性 add 四个 Fragment，之后只做 show/hide：

private void switchFragment(int index) { FragmentTransaction tx = getSupportFragmentManager().beginTransaction(); for (int i = 0; i < fragments.size(); i++) { Fragment f = fragments.get(i); if (i == index) { tx.show(f); } else { tx.hide(f); } } tx.commit(); }

这里有个血泪经验：四个 Fragment 在onCreate里一次性 add 时，一定要给每个 Fragment 设置 tag 或者用集合持有引用，否则配置变更（比如旋转屏幕）后getSupportFragmentManager恢复的 Fragment 和你手里的引用对不上，就会出现「切到通讯录却显示聊天列表」的玄学问题。稳妥的做法是在onCreate里先判断savedInstanceState == null，为空才执行初始化 add，不为空则从 FragmentManager 里按 tag 找回。

3.3 状态保存：旋转屏幕不丢数据的兜底

界面类项目最容易被忽略的是配置变更。用户在聊天详情页输入了一半文字，转个屏内容没了，这种 bug 答辩时被当场演示就很尴尬。处理方式分两层：输入框内容用onSaveInstanceState存到 Bundle；列表滚动位置 RecyclerView 自带LinearLayoutManager的状态保存，只要 Adapter 数据源没被清空就能自动恢复。对于「我」页面这种静态展示，不需要额外处理。这套兜底做完，才算一个能经得起折腾的界面。

4. 核心页面实现：聊天列表与消息气泡怎么落地

4.1 聊天列表：多类型 Item 与未读红点

微信聊天列表的 item 结构是固定的：左侧头像、中间昵称加最后一条消息、右侧时间加未读红点。用 RecyclerView 实现时，Adapter 的onBindViewHolder负责把数据填进去，红点用自定义的BadgeView控制显隐：

@Override public void onBindViewHolder(ViewHolder holder, int position) { ChatItem item = dataList.get(position); holder.name.setText(item.getName()); holder.lastMsg.setText(item.getLastMessage()); holder.time.setText(item.getTime()); // 未读数大于 0 才显示红点，超过 99 显示 99+ if (item.getUnread() > 0) { holder.badge.setVisibility(View.VISIBLE); holder.badge.setText(item.getUnread() > 99 ? "99+" : String.valueOf(item.getUnread())); } else { holder.badge.setVisibility(View.GONE); } // 头像用本地资源，实际项目可换 Glide 加载 holder.avatar.setImageResource(item.getAvatarRes()); }

设计说明：BadgeView继承 TextView，在onDraw里画一个红色圆角背景，文字居中。未读数超过 99 显示「99+」是微信的真实规则，这个细节写进去答辩时很加分。头像这里用本地资源是为了保证离线可运行，如果后续要接网络图片，把setImageResource换成图片加载库即可，接口不变。列表分割线用ItemDecoration实现，左边留出头像宽度，这样分割线不会顶到屏幕边缘，和微信的视觉效果一致。

4.2 消息气泡：用 9-patch 还是自定义 Drawable

聊天详情页的消息气泡是整套界面里最考验细节的部分。气泡要有小三角指向头像方向，左右两侧消息三角方向相反。实现方式有两种：9-patch 图片和自定义 Drawable。9-patch 简单但需要准备两套图，自定义 Drawable 灵活但代码稍多。我一般选后者，用LayerDrawable组合一个圆角矩形加一个旋转 45 度的正方形来模拟三角：

<!-- res/drawable/bubble_left.xml 左侧接收气泡 --> <layer-list> <item> <shape android:shape="rectangle"> <solid android:color="#FFFFFF"/> <corners android:radius="8dp"/> </shape> </item> <item android:left="-6dp" android:top="12dp" android:bottom="12dp"> <rotate android:fromDegrees="45" android:pivotX="50%" android:pivotY="50%"> <shape android:shape="rectangle"> <solid android:color="#FFFFFF"/> <size android:width="12dp" android:height="12dp"/> </shape> </rotate> </item> </layer-list>

逻辑说明：底层是圆角矩形做气泡主体，上层是一个旋转 45 度的正方形，通过负的 left 偏移让它露出一半形成三角。右侧气泡把android:left改成android:right="-6dp"即可镜像。参数上，圆角 8dp、三角边长 12dp 是视觉上比较接近微信的比例，实际调的时候以真机预览为准。消息列表同样用 RecyclerView，发送消息后调用notifyItemInserted并scrollToPosition到底部，这两步缺一不可，只刷新不滚动用户会以为没发出去。

4.3 输入框与软键盘：adjustResize 的正确用法

聊天输入框被软键盘遮挡是高频问题。解决方案是在 AndroidManifest 里给 ChatDetailActivity 设置android:windowSoftInputMode="adjustResize"，同时根布局不要用固定高度，让内容区随键盘压缩。如果发现设置后无效，八成是 Activity 用了全屏主题或者根布局是 ScrollView 包裹导致测量异常。稳妥做法是根布局用 ConstraintLayout，消息列表layout_height="0dp"加layout_weight撑满剩余空间，输入框贴底，这样键盘弹出时列表自动缩短，输入框始终可见。

5. 避坑与排查：五个最容易翻车的点

5.1 现象：切换 Tab 后 Fragment 重叠

原因通常是replace和add混用，或者初始化时重复 add 了同一个 Fragment。解决方式是统一用 show/hide，并在onCreate里判断savedInstanceState是否为空，为空才初始化，不为空从 FragmentManager 按 tag 找回已有实例。

5.2 现象：列表滑动卡顿、图片错位

原因多半是在onBindViewHolder里做了耗时操作，或者图片加载没有复用机制导致错位。解决方式是把数据绑定逻辑控制在轻量级，图片加载统一走缓存库，并在绑定前先重置占位图，避免复用时显示上一条的数据。

5.3 现象：未读红点位置偏移

原因是 BadgeView 的父布局约束不对，红点用了绝对定位。解决方式是把红点放在头像的 FrameLayout 里，用layout_gravity="top|end"加负 margin 微调，这样无论头像尺寸怎么变，红点始终贴着右上角。

5.4 现象：软键盘弹出后输入框消失

原因是windowSoftInputMode没设或设成了adjustPan。解决方式是改成adjustResize，并检查根布局是否有固定高度或全屏属性。如果还不行，在代码里监听布局变化手动滚动列表到底部。

5.5 现象：真机上字体和间距与设计稿对不上

原因是设计稿用的 px 而布局用的 dp，或者没考虑状态栏高度。解决方式是统一用 dp 和 sp，状态栏高度通过WindowInsets动态获取，不要写死 24dp。这个坑几乎每个新手都会踩一次，提前统一单位能省很多返工。

6. 验收与答辩：怎么证明这套界面「真的能用」

验收这套界面，我一般分三步走，每一步都有可量化的检查点。第一步是功能走查：四个 Tab 逐个点击，确认切换无重叠、选中态正确；聊天列表滚动到第 100 条以上，观察是否掉帧；进入聊天详情发送三条消息，确认上屏顺序和滚动位置正确；旋转屏幕，确认输入框内容和列表位置不丢。第二步是边界测试：未读数设为 0、99、100 三个值，确认红点显隐和「99+」逻辑；通讯录字母索引滑到首尾，确认不越界；软键盘弹出收起反复五次，确认输入框不漂移。第三步是代码审查：检查是否有硬编码颜色和尺寸、Fragment 是否有内存泄漏风险、Adapter 是否用了 ViewHolder。

答辩时老师最爱问的三个问题，提前准备好答案：一是「为什么用 Fragment 不用 Activity」，答返回栈管理和状态保持；二是「RecyclerView 比 ListView 好在哪」，答 ViewHolder 强制复用和局部刷新；三是「你的项目怎么保证可扩展」，答按功能分包加 Repository 统一数据源。演示环节建议准备一份「异常演示脚本」，主动展示旋转屏幕、快速切换 Tab、长列表滚动这几个场景，比被动等老师挑刺从容得多。

从那以后我每次做界面类项目，都会在提交前强制走一遍「旋转屏幕 + 快速切换 + 长列表」这三连测，因为翻车往往就藏在这些最不起眼的操作里。希望这套结构和实现思路能帮到你，把这份界面作业做成一份拿得出手的作品。

本文还有配套的精品资源，点击获取