简介仿哔哩哔哩B站的安卓客户端源码学习包面向希望在真实项目中进阶的Android初中级开发者也适合准备移动端面试或毕设项目的读者。源码围绕B站典型业务场景展开覆盖MVP架构、RecyclerView列表适配与复用、自定义View绘制交互、Retrofit与OkHttp网络请求、Room本地持久化、Glide图片加载与缓存、EventBus解耦通信、Dagger2依赖注入、LiveData与ViewModel生命周期感知以及弹幕解析渲染、RxJava异步事件流、运行时权限适配等多种核心技术点能帮助读者系统梳理移动开发常见难点的应对思路。资源以ZIP压缩包提供大小约9.79MB下载页未单独列出文件总数与类型明细解压后可直接对照源码工程与模块结构学习。该资源已有709人学习下载是同类仿写项目中关注度较高的参考。通过阅读这份源码既能理解分层架构在业务中的落地方式也能拆解弹幕模块在解析、渲染、碰撞检测等环节的实现并掌握主流开源库之间的协作思路积累可用于实际项目的工程经验。1. 仿哔哩哔哩项目到底在练什么为什么不直接叫“B站客户端”拿到“Android 仿哔哩哔哩B站源码”这个标题很多人的第一反应是找一个能直接跑的完整App装上APK看效果。但真正有价值的做法是把这类源码当成一套Android 中大型应用架构的活体教材B站首页的复杂Feed流、分区Tab、视频播放、弹幕、搜索、个人中心每一块都对应一个可以独立深挖的技术点。你能在一份源码里同时看到多类型列表、播放器封装、网络层设计、内存优化、Material控件取舍这种密度在普通Demo里几乎不可能出现。做这个项目目标不是“复刻一个B站”然后上架而是“用B站的界面形态做载体把Android开发的工程化能力完整练一遍”。适合的人群很明确已经能独立写页面、想进一步搞懂大型App模块化怎么落地的Android开发或者做毕业设计、作品集需要一个能讲出技术深度的开源项目。需要先说清一个边界本文只讲“仿制”和“源码阅读/重构”中普遍成立的技术方案不涉及任何破解、抓取加密接口或绕过风控的手段。2. 先看源码里最核心的骨架主界面框架与多类型Feed流2.1 首页Tab框架为什么用Fragment而不是ViewPager Activity绝大多数仿B站项目的主界面都是“底部导航 多个一级页面”常见的实现是MainActivity嵌套FragmentContainerView配合BottomNavigationView或者RadioGroup自定义底部栏。选Fragment不选Activity理由很直接Activity切换的代价远高于Fragment切换频繁切换会导致重建整个视图树而仿B站这种首页、频道、动态、我的四五个一级页面的场景Fragment可以配合show/hide保证状态不丢。看源码时重点看Tab的切换方式。常见的写法是这样private fun switchTab(position: Int) { supportFragmentManager.beginTransaction() .hide(currentFragment) .show(fragments[position]) .commit() currentFragment fragments[position] }这里有个关键细节初次创建时需要先add所有Fragment但不要直接commit多个事务。如果一次性 commit 多个操作可能出现IllegalStateException: Can not perform this action after onSaveInstanceState。处理方式是区分首次初始化和后续切换或者用commitNow()。另一个值得关注的点是底部导航的OnNavigationItemSelectedListener里要返回true否则导航项不会切换选中态。源码里如果还做了“切换时重新请求数据”那就要看它的生命周期是否跟setUserVisibleHint或onHiddenChanged挂钩很多仿B站项目在快速切换Tab时会丢请求根因就在这里。2.2 RecyclerView 多类型Item是仿B站首页的重头戏B站首页的信息流不是单一卡片而是轮播Banner、分区入口、视频卡片、运营位、直播入口混排。对应到代码里就是RecyclerView.Adapter的多种itemViewType。新手写多类型Item最容易写成一坨when塞满onBindViewHolder工程化一点的源码会做类型分发器。常见的结构是这样class FeedAdapter( private val types: ListFeedType, private val itemBinderMap: MapInt, ItemViewBinderAny, ViewHolder ) : RecyclerView.AdapterViewHolder() { override fun getItemViewType(position: Int): Int { return types[position].type } override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): ViewHolder { val binder itemBinderMap[viewType] ?: throw IllegalArgumentException(unknown view type: $viewType) return binder.onCreateViewHolder(parent) } override fun onBindViewHolder(holder: ViewHolder, position: Int) { itemBinderMap[getItemViewType(position)]?.onBindViewHolder(holder, types[position].data) } }这种写法把每种卡片类型的创建和绑定都隔离在各自的ItemViewBinder里新增一种卡片时不需要改动Adapter主体只需要注册新的itemType和对应的Binder。看源码时搞清楚它是否用了ConcatAdapter——这是官方提供的思路适合模块间完全解耦的场景但缺点是每个子Adapter都要独立监听滚动事件。2.3 轮播Banner和流式布局的取舍B站首页顶部 Banner 一般是ViewPager2或循环RecyclerView实现。用ViewPager2做轮播时无限循环的常见做法是设置一个很大的初始值binding.bannerViewPager.registerOnPageChangeCallback(object : OnPageChangeCallback() { override fun onPageSelected(position: Int) { val realPosition position % itemCount // 更新指示器 } })有些源码会直接把itemCount设为Int.MAX_VALUE配合setCurrentItem(Int.MAX_VALUE / 2, false)实现两个方向的无限滑动。这个方法本身可用但要处理RecyclerView在极端位置下的性能问题通常还要配合offscreenPageLimit的设置。“分区入口”这类宫格布局源码里有时候用GridLayoutManager包进RecyclerView的某个itemType有时候直接用FlexboxLayout。两种做法的差异在于前者和整个Feed流共用滚动后者每行高度独立。推荐的做法是后者因为宫格内的图标数量比如12个入口不是固定的运营配置变了会直接改变整行高度用FlexboxLayout或GridLayout在自适应上更灵活。3. 网络层这么搭仿B站项目才不算白做3.1 从源码能学到的最实用套路OkHttp Retrofit 统一签名仿B站项目的网络层一般选用Retrofit因为B站首页、视频详情、用户信息这些接口天然是RESTful风格。源码里最值得抄的部分是Interceptor的链式设计日志拦截、公共参数注入、Token刷新、异常重试每一层只干一件事。B站的访问需要处理 WBI 签名和buvid等参数签名计算逻辑通常位于一个独立的加密工具类中。如果你拿到的源码没有登录态只做游客模式那么至少要看它有没有统一处理 Cookie 持久化。Android 上存取 Cookie常用PersistentCookieJar仿照 OkHttp 官方 wiki 的实现class PersistentCookieJar : CookieJar { private val cache mutableMapOfString, MutableListCookie() override fun saveFromResponse(url: HttpUrl, cookies: ListCookie) { cache[url.host] cookies.toMutableList() } override fun loadForRequest(url: HttpUrl): ListCookie { return cache[url.host] ?: emptyList() } }这段代码是最简版本。工程化写法要把cache换成SharedPreferences或 SQLite 持久化并对过期时间做校验判断cookie.expiresAt是否早于System.currentTimeMillis()过期的不放进返回列表。很多仿B站项目播放视频时“PV需要验证”或“返回412”往往就是 Cookie 持久化不到位。3.2 接口数据有的是JSON嵌套层数极深怎么解析最不容易崩B站接口的响应结构通常是{ code: 0, message: 0, data: {...} }这种包裹格式嵌套层数深、字段可空率高。如果源码用的是Gson重点看它有没有处理JsonSyntaxException。一个常见坑是接口返回data为null时Gson 会直接给整个 data 对象置空但不会抛异常。如果代码里直接response.data.list[0]就会产生 NPE。好一点的源码会做统一的数据脱壳例如class ApiResponseT { val code: Int 0 val message: String? null val data: T? null } inline fun reified T parseResponse(response: ApiResponseT): T? { return if (response.code 0) response.data else null }还有一类问题是解析耗时。B站首页视频卡片的数据在 JSON 里有很多无用字段Gson 反射解析全部字段会白白消耗时间。源码里如果用了Expose注解或者专门的 parser说明作者意识到了这个问题。如果没做用JsonReader手动挑字段也是一种可接受的做法但要权衡代码量。3.3 图片加载选 Glide 还是 Coil仿B站项目里差在哪B站首页每屏有大量封面图、头像、轮播图图片库的选择直接影响内存表现。Glide 是这类项目的主流选择因为它在生命周期绑定、缓存策略上非常成熟。源码里如果直接用ImageView加载要留意是否设置过placeholder和error。B站图片有不同尺寸的 cdn 后缀例如320w_200h.webp参数Glide 可以直接拼接 URL 后缀来按需加载减少流量。override(320, 200)配合.format(DecodeFormat.PREFER_RGB_565)是 ListView/RecyclerView 场景下降低内存开销的标准操作。如果源码用到Coil它的优势在于 Kotlin 协程原生支持、扩展函数简洁。但 Coil 在大型复杂项目中的缓存控制不如 Glide 成熟尤其是需要做 GIF、WebP 和进度监听的混合场景。仿B站项目里视频封面和缩略图尺寸很多样Glide 的DiskCacheStrategy.DATA和RESOURCE区分缓存策略更可靠。4. 播放器与弹幕仿B站项目里最考验功力的部分4.1 用 ExoPlayer 而不是 MediaPlayer理由要充分不管仿的是哪个版本的B站视频播放是躲不开的模块。MediaPlayer在ListView场景下滑动卡顿、音频焦点处理差、HLS/DASH 支持弱ExoPlayer在 Android 官方地位已经是默认播放器。用 ExoPlayer 时源码里至少要体现三个点val player ExoPlayer.Builder(context) .setLoadControl(DefaultLoadControl.Builder() .setBufferDurationsMs(5000, 15000, 2500, 5000) .build()) .build()参数说明5000是最小缓冲时长15000是最大缓冲时长2500是缓冲重试起点5000是缓冲重试上限。在首页列表滑动场景这些值不能调太高否则用户滑到视频时加载等待时间过长如果做的是视频详情页单视频播放可以把最小缓冲调到 15 秒减少播放中卡顿的概率。播放器与列表的联动关键是RecyclerView.OnScrollListener中做“滑停播放”逻辑。常见的做法是列表onScrollStateChanged中判断是否SCROLL_STATE_IDLE获取当前可见的第一个和最后一个position找到其中类型是视频卡的 Item定位它的VideoViewHolder调用player.playWhenReady true这个逻辑与 B 站首页“视频自动播放”的体验相似而且不依赖第三方库。源码里如果直接给每个 item 都创建独立 player那就是糟糕的实现会导致内存暴涨。4.2 弹幕系统是怎么设计和落在画布上的弹幕是区分“普通视频App”和“仿B站”的重要指标。很多源码采用的是CustomView中绘制弹幕核心思路是用Handler或Choreographer做帧循环每条弹幕对象包含文本、坐标、移动速度、颜色在onDraw中根据时间戳计算每条弹幕的 x 坐标弹幕道的分配算法是这里的难点。经典简单方案是按“轨道编号”轮流分配但会出现在同一时刻同一轨道弹幕挤在一起的问题。工程化一点的方案是维护ListBoolean表示每条轨道是否占用分配弹幕时选择满足宽度约束且当前为空闲的轨道。这个宽度约束就是“弹幕宽度 屏幕宽度 剩余可移动距离”。data class DanmakuItem( val text: String, val baseY: Float, var x: Float, val speed: Float, val color: Int )弹幕渲染不放在onDraw里做文本测量会更靠谱。文本宽度的测量很耗时每个弹幕在进入前就应算好宽度避免在绘制循环中反复调用Paint.measureText()。另外弹幕的移动要基于帧时间差而不是每帧固定减少多少像素——不同设备的刷新率不同固定步长在 120Hz 设备上会显得比 60Hz 设备快一倍。源码里如果没做时间差修正这里也正好是你重构优化的第一站。4.3 生命周期绑定在播放器模块里怎么才能不崩ExoPlayer默认持有音频焦点和唤醒锁如果不在onStop里释放就会出现退出页面后“声音还在放”的情况。仿B站项目里常见的封装方式是自定义PlayerManager单例播放器实例全局维护进详情页时关联新的 UI退出时解绑但保留播放进度。具体到 Fragment 场景要在onDestroyView时player.setVideoSurface(null)而不是直接release()。一个典型事故是Activity 旋转Fragment 重建旧 VideoView 与播放器解绑但通知走的是onDetachedFromWindow如果这里没有清掉视频 Surface新界面上看不到画面但能听到声音。调试时遇到这种情况先检查是否有多处给player.addAnalyticsListener重复注册导致日志里出现两条onVideoSizeChanged。5. 列表优化仿B站源码里最容易拉开层次的部分5.1 布局层级和卡顿的真凶很多仿B站项目的首页Item用 LinearLayout 嵌套一层套一层导致measure耗时严重。每张视频卡片至少是“封面层 时长角标 标题 UP主信息 播放数据”一个 item 的视图可能有 40 个节点。RecyclerView 的onCreateViewHolder要等这么深的层级全部 inflate列表在快速滑动时会频繁 GC帧率直接掉到什么时候DropFrame 率会明显升高。优化第一步是遍历item_feed_video.xml把所有能合并的 View 合并。比如封面和时长角标可以用一个FrameLayout标题和UP主信息放在同一个ConstraintLayout里。第二步是用ViewStub懒加载那些不到最后一刻不需要渲染的视图比如“三连按钮区域”“关注按钮”。但要注意不要把所有子视图都塞进ViewStub因为findViewById的访问在ViewStub.inflate之前会返回 null代码里频繁判空更容易出错。5.2 图片缓存的三级联动Glide 用内存缓存、磁盘缓存、网络源三级联动。源码里经常能看到对ImageLoader做统一封装核心逻辑是用RequestOptions做统一配置val options RequestOptions() .placeholder(R.drawable.img_cover_placeholder) .error(R.drawable.img_cover_error) .centerCrop() .diskCacheStrategy(DiskCacheStrategy.AUTOMATIC) .format(DecodeFormat.PREFER_RGB_565)一个细节PREFER_RGB_565只适合不透明的图片如果封面图有透明度要求比如播放按钮悬浮半透明角标会导致边缘出现色彩噪点。B站封面基本都是不透明矩形图可以放心用。列表头图的 WebP 动图比如头像带w_100.webp后缀的图片用 Glide 默认支持但要防止加载raw原图再缩放。推荐做法是加载前在 URL 上直接拼接 CDN 参数例如http://i0.hdslb.com/bfs/archive/xxx.jpg160w_100h.webp让服务器返回目标尺寸而不是让 Glide 做全尺寸解码后再缩放。5.3 RecyclerView 的复用陷阱check 状态和数据错乱B站首页 Feed 流中如果包含“点赞/收藏/关注”状态复用会导致一个经典 BugonBindViewHolder中设置的“已关注”按钮滚出屏幕再滚回来时状态错乱。原因是复用机制保留了上次的isChecked状态。遇到这种问题首要原则是任何视图状态都要在 onBindViewHolder 里显式赋值不能依赖默认值或上次状态。override fun onBindViewHolder(holder: ViewHolder, position: Int) { val item list[position] holder.binding.btnFollow.isSelected item.isFollowed holder.binding.btnFollow.setOnClickListener { // 在这里处理关注逻辑注意 position 要用 holder.bindingAdapterPosition } }数据源里如果没有isFollowed字段只靠点击事件的临时缓存就必须在点击时把list[position]拷贝一份更新再notifyItemChanged(position)否则删除或插入元素后 position 错位UI 的显示就是脏的。有些源码干脆不做状态维护只在内存里用SparseBooleanArray缓存这种方法在分页拉取新数据时会失效。6. 最后看三个代码细节把仿B站的源码变成自己的作品6.1 不要照搬项目里的包名和网络地址替换注册的是 ComponentName拿到源码后第一件事不是急着跑而是全局替换包名。Android 的activity-alias、ContentProvider、FileProvider的authorities、sharePreferences文件名都可能写死包名。尤其是FileProvider不替换authorities会导致应用间共享文件时直接闪退provider android:nameandroidx.core.content.FileProvider android:authorities${applicationId}.fileprovider android:exportedfalse android:grantUriPermissionstrue meta-data android:nameandroid.support.FILE_PROVIDER_PATHS android:resourcexml/file_paths / /provider用tools:replaceandroid:authorities处理 manifest merger 冲突是所有仿开源项目接入自己签名时必然要处理的一步。6.2 用 LeakCanary 验证播放器是否真的被回收了播放器相关的内存泄漏经常藏得很深。在项目Application里临时接入LeakCanary然后反复执行“进入视频详情页 → 退出 → 进入另一个视频详情页”如果出现泄漏信息重点检查三处视频封面ImageView是否被Player.Listener引用PlayerManager单例里是否持有Context特别是 Activity ContextLifecycleObserver是否反注册常见的修复方式是把单例中对 Context 的引用改成applicationContext避免 Activity 销毁后仍被持有。6.3 自己的分支上做一个小功能视频详情页的“相关推荐”预加载在源码基础上尝试做一个小改造从视频详情页的“相关推荐”接口拉取数据后提前调用Glide.with(context).load(...).preload()让推荐列表真正显示时不再白屏。这个功能不需要动架构但能体会到列表数据预取与播放器缓冲之外的第三维度优化。从这一小点开始就完全脱离了对源码的“抄”进入到了“造”的状态。本文还有配套的精品资源点击获取
简介仿哔哩哔哩B站的安卓客户端源码学习包面向希望在真实项目中进阶的Android初中级开发者也适合准备移动端面试或毕设项目的读者。源码围绕B站典型业务场景展开覆盖MVP架构、RecyclerView列表适配与复用、自定义View绘制交互、Retrofit与OkHttp网络请求、Room本地持久化、Glide图片加载与缓存、EventBus解耦通信、Dagger2依赖注入、LiveData与ViewModel生命周期感知以及弹幕解析渲染、RxJava异步事件流、运行时权限适配等多种核心技术点能帮助读者系统梳理移动开发常见难点的应对思路。资源以ZIP压缩包提供大小约9.79MB下载页未单独列出文件总数与类型明细解压后可直接对照源码工程与模块结构学习。该资源已有709人学习下载是同类仿写项目中关注度较高的参考。通过阅读这份源码既能理解分层架构在业务中的落地方式也能拆解弹幕模块在解析、渲染、碰撞检测等环节的实现并掌握主流开源库之间的协作思路积累可用于实际项目的工程经验。1. 仿哔哩哔哩项目到底在练什么为什么不直接叫“B站客户端”拿到“Android 仿哔哩哔哩B站源码”这个标题很多人的第一反应是找一个能直接跑的完整App装上APK看效果。但真正有价值的做法是把这类源码当成一套Android 中大型应用架构的活体教材B站首页的复杂Feed流、分区Tab、视频播放、弹幕、搜索、个人中心每一块都对应一个可以独立深挖的技术点。你能在一份源码里同时看到多类型列表、播放器封装、网络层设计、内存优化、Material控件取舍这种密度在普通Demo里几乎不可能出现。做这个项目目标不是“复刻一个B站”然后上架而是“用B站的界面形态做载体把Android开发的工程化能力完整练一遍”。适合的人群很明确已经能独立写页面、想进一步搞懂大型App模块化怎么落地的Android开发或者做毕业设计、作品集需要一个能讲出技术深度的开源项目。需要先说清一个边界本文只讲“仿制”和“源码阅读/重构”中普遍成立的技术方案不涉及任何破解、抓取加密接口或绕过风控的手段。2. 先看源码里最核心的骨架主界面框架与多类型Feed流2.1 首页Tab框架为什么用Fragment而不是ViewPager Activity绝大多数仿B站项目的主界面都是“底部导航 多个一级页面”常见的实现是MainActivity嵌套FragmentContainerView配合BottomNavigationView或者RadioGroup自定义底部栏。选Fragment不选Activity理由很直接Activity切换的代价远高于Fragment切换频繁切换会导致重建整个视图树而仿B站这种首页、频道、动态、我的四五个一级页面的场景Fragment可以配合show/hide保证状态不丢。看源码时重点看Tab的切换方式。常见的写法是这样private fun switchTab(position: Int) { supportFragmentManager.beginTransaction() .hide(currentFragment) .show(fragments[position]) .commit() currentFragment fragments[position] }这里有个关键细节初次创建时需要先add所有Fragment但不要直接commit多个事务。如果一次性 commit 多个操作可能出现IllegalStateException: Can not perform this action after onSaveInstanceState。处理方式是区分首次初始化和后续切换或者用commitNow()。另一个值得关注的点是底部导航的OnNavigationItemSelectedListener里要返回true否则导航项不会切换选中态。源码里如果还做了“切换时重新请求数据”那就要看它的生命周期是否跟setUserVisibleHint或onHiddenChanged挂钩很多仿B站项目在快速切换Tab时会丢请求根因就在这里。2.2 RecyclerView 多类型Item是仿B站首页的重头戏B站首页的信息流不是单一卡片而是轮播Banner、分区入口、视频卡片、运营位、直播入口混排。对应到代码里就是RecyclerView.Adapter的多种itemViewType。新手写多类型Item最容易写成一坨when塞满onBindViewHolder工程化一点的源码会做类型分发器。常见的结构是这样class FeedAdapter( private val types: ListFeedType, private val itemBinderMap: MapInt, ItemViewBinderAny, ViewHolder ) : RecyclerView.AdapterViewHolder() { override fun getItemViewType(position: Int): Int { return types[position].type } override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): ViewHolder { val binder itemBinderMap[viewType] ?: throw IllegalArgumentException(unknown view type: $viewType) return binder.onCreateViewHolder(parent) } override fun onBindViewHolder(holder: ViewHolder, position: Int) { itemBinderMap[getItemViewType(position)]?.onBindViewHolder(holder, types[position].data) } }这种写法把每种卡片类型的创建和绑定都隔离在各自的ItemViewBinder里新增一种卡片时不需要改动Adapter主体只需要注册新的itemType和对应的Binder。看源码时搞清楚它是否用了ConcatAdapter——这是官方提供的思路适合模块间完全解耦的场景但缺点是每个子Adapter都要独立监听滚动事件。2.3 轮播Banner和流式布局的取舍B站首页顶部 Banner 一般是ViewPager2或循环RecyclerView实现。用ViewPager2做轮播时无限循环的常见做法是设置一个很大的初始值binding.bannerViewPager.registerOnPageChangeCallback(object : OnPageChangeCallback() { override fun onPageSelected(position: Int) { val realPosition position % itemCount // 更新指示器 } })有些源码会直接把itemCount设为Int.MAX_VALUE配合setCurrentItem(Int.MAX_VALUE / 2, false)实现两个方向的无限滑动。这个方法本身可用但要处理RecyclerView在极端位置下的性能问题通常还要配合offscreenPageLimit的设置。“分区入口”这类宫格布局源码里有时候用GridLayoutManager包进RecyclerView的某个itemType有时候直接用FlexboxLayout。两种做法的差异在于前者和整个Feed流共用滚动后者每行高度独立。推荐的做法是后者因为宫格内的图标数量比如12个入口不是固定的运营配置变了会直接改变整行高度用FlexboxLayout或GridLayout在自适应上更灵活。3. 网络层这么搭仿B站项目才不算白做3.1 从源码能学到的最实用套路OkHttp Retrofit 统一签名仿B站项目的网络层一般选用Retrofit因为B站首页、视频详情、用户信息这些接口天然是RESTful风格。源码里最值得抄的部分是Interceptor的链式设计日志拦截、公共参数注入、Token刷新、异常重试每一层只干一件事。B站的访问需要处理 WBI 签名和buvid等参数签名计算逻辑通常位于一个独立的加密工具类中。如果你拿到的源码没有登录态只做游客模式那么至少要看它有没有统一处理 Cookie 持久化。Android 上存取 Cookie常用PersistentCookieJar仿照 OkHttp 官方 wiki 的实现class PersistentCookieJar : CookieJar { private val cache mutableMapOfString, MutableListCookie() override fun saveFromResponse(url: HttpUrl, cookies: ListCookie) { cache[url.host] cookies.toMutableList() } override fun loadForRequest(url: HttpUrl): ListCookie { return cache[url.host] ?: emptyList() } }这段代码是最简版本。工程化写法要把cache换成SharedPreferences或 SQLite 持久化并对过期时间做校验判断cookie.expiresAt是否早于System.currentTimeMillis()过期的不放进返回列表。很多仿B站项目播放视频时“PV需要验证”或“返回412”往往就是 Cookie 持久化不到位。3.2 接口数据有的是JSON嵌套层数极深怎么解析最不容易崩B站接口的响应结构通常是{ code: 0, message: 0, data: {...} }这种包裹格式嵌套层数深、字段可空率高。如果源码用的是Gson重点看它有没有处理JsonSyntaxException。一个常见坑是接口返回data为null时Gson 会直接给整个 data 对象置空但不会抛异常。如果代码里直接response.data.list[0]就会产生 NPE。好一点的源码会做统一的数据脱壳例如class ApiResponseT { val code: Int 0 val message: String? null val data: T? null } inline fun reified T parseResponse(response: ApiResponseT): T? { return if (response.code 0) response.data else null }还有一类问题是解析耗时。B站首页视频卡片的数据在 JSON 里有很多无用字段Gson 反射解析全部字段会白白消耗时间。源码里如果用了Expose注解或者专门的 parser说明作者意识到了这个问题。如果没做用JsonReader手动挑字段也是一种可接受的做法但要权衡代码量。3.3 图片加载选 Glide 还是 Coil仿B站项目里差在哪B站首页每屏有大量封面图、头像、轮播图图片库的选择直接影响内存表现。Glide 是这类项目的主流选择因为它在生命周期绑定、缓存策略上非常成熟。源码里如果直接用ImageView加载要留意是否设置过placeholder和error。B站图片有不同尺寸的 cdn 后缀例如320w_200h.webp参数Glide 可以直接拼接 URL 后缀来按需加载减少流量。override(320, 200)配合.format(DecodeFormat.PREFER_RGB_565)是 ListView/RecyclerView 场景下降低内存开销的标准操作。如果源码用到Coil它的优势在于 Kotlin 协程原生支持、扩展函数简洁。但 Coil 在大型复杂项目中的缓存控制不如 Glide 成熟尤其是需要做 GIF、WebP 和进度监听的混合场景。仿B站项目里视频封面和缩略图尺寸很多样Glide 的DiskCacheStrategy.DATA和RESOURCE区分缓存策略更可靠。4. 播放器与弹幕仿B站项目里最考验功力的部分4.1 用 ExoPlayer 而不是 MediaPlayer理由要充分不管仿的是哪个版本的B站视频播放是躲不开的模块。MediaPlayer在ListView场景下滑动卡顿、音频焦点处理差、HLS/DASH 支持弱ExoPlayer在 Android 官方地位已经是默认播放器。用 ExoPlayer 时源码里至少要体现三个点val player ExoPlayer.Builder(context) .setLoadControl(DefaultLoadControl.Builder() .setBufferDurationsMs(5000, 15000, 2500, 5000) .build()) .build()参数说明5000是最小缓冲时长15000是最大缓冲时长2500是缓冲重试起点5000是缓冲重试上限。在首页列表滑动场景这些值不能调太高否则用户滑到视频时加载等待时间过长如果做的是视频详情页单视频播放可以把最小缓冲调到 15 秒减少播放中卡顿的概率。播放器与列表的联动关键是RecyclerView.OnScrollListener中做“滑停播放”逻辑。常见的做法是列表onScrollStateChanged中判断是否SCROLL_STATE_IDLE获取当前可见的第一个和最后一个position找到其中类型是视频卡的 Item定位它的VideoViewHolder调用player.playWhenReady true这个逻辑与 B 站首页“视频自动播放”的体验相似而且不依赖第三方库。源码里如果直接给每个 item 都创建独立 player那就是糟糕的实现会导致内存暴涨。4.2 弹幕系统是怎么设计和落在画布上的弹幕是区分“普通视频App”和“仿B站”的重要指标。很多源码采用的是CustomView中绘制弹幕核心思路是用Handler或Choreographer做帧循环每条弹幕对象包含文本、坐标、移动速度、颜色在onDraw中根据时间戳计算每条弹幕的 x 坐标弹幕道的分配算法是这里的难点。经典简单方案是按“轨道编号”轮流分配但会出现在同一时刻同一轨道弹幕挤在一起的问题。工程化一点的方案是维护ListBoolean表示每条轨道是否占用分配弹幕时选择满足宽度约束且当前为空闲的轨道。这个宽度约束就是“弹幕宽度 屏幕宽度 剩余可移动距离”。data class DanmakuItem( val text: String, val baseY: Float, var x: Float, val speed: Float, val color: Int )弹幕渲染不放在onDraw里做文本测量会更靠谱。文本宽度的测量很耗时每个弹幕在进入前就应算好宽度避免在绘制循环中反复调用Paint.measureText()。另外弹幕的移动要基于帧时间差而不是每帧固定减少多少像素——不同设备的刷新率不同固定步长在 120Hz 设备上会显得比 60Hz 设备快一倍。源码里如果没做时间差修正这里也正好是你重构优化的第一站。4.3 生命周期绑定在播放器模块里怎么才能不崩ExoPlayer默认持有音频焦点和唤醒锁如果不在onStop里释放就会出现退出页面后“声音还在放”的情况。仿B站项目里常见的封装方式是自定义PlayerManager单例播放器实例全局维护进详情页时关联新的 UI退出时解绑但保留播放进度。具体到 Fragment 场景要在onDestroyView时player.setVideoSurface(null)而不是直接release()。一个典型事故是Activity 旋转Fragment 重建旧 VideoView 与播放器解绑但通知走的是onDetachedFromWindow如果这里没有清掉视频 Surface新界面上看不到画面但能听到声音。调试时遇到这种情况先检查是否有多处给player.addAnalyticsListener重复注册导致日志里出现两条onVideoSizeChanged。5. 列表优化仿B站源码里最容易拉开层次的部分5.1 布局层级和卡顿的真凶很多仿B站项目的首页Item用 LinearLayout 嵌套一层套一层导致measure耗时严重。每张视频卡片至少是“封面层 时长角标 标题 UP主信息 播放数据”一个 item 的视图可能有 40 个节点。RecyclerView 的onCreateViewHolder要等这么深的层级全部 inflate列表在快速滑动时会频繁 GC帧率直接掉到什么时候DropFrame 率会明显升高。优化第一步是遍历item_feed_video.xml把所有能合并的 View 合并。比如封面和时长角标可以用一个FrameLayout标题和UP主信息放在同一个ConstraintLayout里。第二步是用ViewStub懒加载那些不到最后一刻不需要渲染的视图比如“三连按钮区域”“关注按钮”。但要注意不要把所有子视图都塞进ViewStub因为findViewById的访问在ViewStub.inflate之前会返回 null代码里频繁判空更容易出错。5.2 图片缓存的三级联动Glide 用内存缓存、磁盘缓存、网络源三级联动。源码里经常能看到对ImageLoader做统一封装核心逻辑是用RequestOptions做统一配置val options RequestOptions() .placeholder(R.drawable.img_cover_placeholder) .error(R.drawable.img_cover_error) .centerCrop() .diskCacheStrategy(DiskCacheStrategy.AUTOMATIC) .format(DecodeFormat.PREFER_RGB_565)一个细节PREFER_RGB_565只适合不透明的图片如果封面图有透明度要求比如播放按钮悬浮半透明角标会导致边缘出现色彩噪点。B站封面基本都是不透明矩形图可以放心用。列表头图的 WebP 动图比如头像带w_100.webp后缀的图片用 Glide 默认支持但要防止加载raw原图再缩放。推荐做法是加载前在 URL 上直接拼接 CDN 参数例如http://i0.hdslb.com/bfs/archive/xxx.jpg160w_100h.webp让服务器返回目标尺寸而不是让 Glide 做全尺寸解码后再缩放。5.3 RecyclerView 的复用陷阱check 状态和数据错乱B站首页 Feed 流中如果包含“点赞/收藏/关注”状态复用会导致一个经典 BugonBindViewHolder中设置的“已关注”按钮滚出屏幕再滚回来时状态错乱。原因是复用机制保留了上次的isChecked状态。遇到这种问题首要原则是任何视图状态都要在 onBindViewHolder 里显式赋值不能依赖默认值或上次状态。override fun onBindViewHolder(holder: ViewHolder, position: Int) { val item list[position] holder.binding.btnFollow.isSelected item.isFollowed holder.binding.btnFollow.setOnClickListener { // 在这里处理关注逻辑注意 position 要用 holder.bindingAdapterPosition } }数据源里如果没有isFollowed字段只靠点击事件的临时缓存就必须在点击时把list[position]拷贝一份更新再notifyItemChanged(position)否则删除或插入元素后 position 错位UI 的显示就是脏的。有些源码干脆不做状态维护只在内存里用SparseBooleanArray缓存这种方法在分页拉取新数据时会失效。6. 最后看三个代码细节把仿B站的源码变成自己的作品6.1 不要照搬项目里的包名和网络地址替换注册的是 ComponentName拿到源码后第一件事不是急着跑而是全局替换包名。Android 的activity-alias、ContentProvider、FileProvider的authorities、sharePreferences文件名都可能写死包名。尤其是FileProvider不替换authorities会导致应用间共享文件时直接闪退provider android:nameandroidx.core.content.FileProvider android:authorities${applicationId}.fileprovider android:exportedfalse android:grantUriPermissionstrue meta-data android:nameandroid.support.FILE_PROVIDER_PATHS android:resourcexml/file_paths / /provider用tools:replaceandroid:authorities处理 manifest merger 冲突是所有仿开源项目接入自己签名时必然要处理的一步。6.2 用 LeakCanary 验证播放器是否真的被回收了播放器相关的内存泄漏经常藏得很深。在项目Application里临时接入LeakCanary然后反复执行“进入视频详情页 → 退出 → 进入另一个视频详情页”如果出现泄漏信息重点检查三处视频封面ImageView是否被Player.Listener引用PlayerManager单例里是否持有Context特别是 Activity ContextLifecycleObserver是否反注册常见的修复方式是把单例中对 Context 的引用改成applicationContext避免 Activity 销毁后仍被持有。6.3 自己的分支上做一个小功能视频详情页的“相关推荐”预加载在源码基础上尝试做一个小改造从视频详情页的“相关推荐”接口拉取数据后提前调用Glide.with(context).load(...).preload()让推荐列表真正显示时不再白屏。这个功能不需要动架构但能体会到列表数据预取与播放器缓冲之外的第三维度优化。从这一小点开始就完全脱离了对源码的“抄”进入到了“造”的状态。本文还有配套的精品资源点击获取
