簡介這是一份基于 Android Studio 的仿美團外賣菜單實戰(zhàn)項目源碼包面向已掌握安卓基礎、希望通過完整案例提升工程能力的開發(fā)者。項目圍繞菜單列表展示與交互展開涉及約束布局等界面設計、列表控件與適配器、本地數(shù)據(jù)庫和偏好存儲、網(wǎng)絡請求與數(shù)據(jù)解析、圖片加載緩存以及權限管理、版本兼容、單元測試和界面測試適合用于課程設計、畢業(yè)項目或技能進階參考。壓縮包采用 7z 格式共 541 個文件、約 10.31MB包含 93 個 xml 布局與配置、128 個 json 數(shù)據(jù)、143 個 flat 資源、12 個 dex、11 個 jar、8 個 java 源碼及 png、webp 圖片等覆蓋源碼、構建產(chǎn)物和資源文件。已有 12733 人學習便于對照完整目錄理解項目結構、梳理關鍵實現(xiàn)幫助讀者從界面到數(shù)據(jù)鏈路形成整體認識也可作為項目復盤樣例并積累實戰(zhàn)排錯經(jīng)驗。1. 仿外賣點餐頁的難點不在布局在雙列表聯(lián)動打開任何一個外賣 App 的店鋪頁左邊一列分類、右邊一長條菜品看著平平無奇。真用 Android Studio 從零搭一個仿外賣點餐菜單出來才會發(fā)現(xiàn)布局那一步十分鐘就寫完了剩下的時間全耗在「左邊點了右邊滾到哪」「右邊滑著左邊高亮跟著變」這兩件事上。分類選中態(tài)閃回、吸頂頭把第一條菜壓住、快速連點之后位置錯亂這些都不是大問題但每一個都能讓一個能跑的 Demo 變成不能用的半成品。這篇筆記按我自己的實現(xiàn)順序走先把菜單模型和布局骨架定死再把左側分類、右側吸頂頭和滾動反推一段段寫出來最后落到加購和購物車浮層。適合已經(jīng)能寫 RecyclerView、但聯(lián)動一直做得不順手的 Android 開發(fā)。2. 布局與數(shù)據(jù)結構先把菜單模型定死2.1 兩個 RecyclerView 還是一個多類型列表做仿外賣點餐菜單右側菜品區(qū)有三種典型寫法選錯了后面全在還債。第一種是「外層 RecyclerView 套內(nèi)層 RecyclerView」外層每個 item 是一個分類內(nèi)層再放一個橫向鋪滿的 RecyclerView 渲染這個分類下的菜。這個寫法看著分層清晰實際用起來最難受內(nèi)層列表要全部setNestedScrollingEnabled(false)否則滑動事件會被內(nèi)層吃掉每個分類都要單獨建一個 Adapter加購數(shù)量變化的時候得挨個通知內(nèi)層刷新分類一多一次性把十幾條菜全綁上來內(nèi)存和首幀都會難看。除非你的菜品區(qū)是那種「每個分類下面還帶橫向樓層」的結構否則別走這條路。第二種是「左右兩個獨立 RecyclerView 并排」。這是最常見的做法也是我推薦的。左側一個窄的RecyclerView只放分類右側一個寬的RecyclerView放「分類頭 菜品」的混合列表。兩個列表各自管各自的滾動互不干擾聯(lián)動完全靠監(jiān)聽和代碼控制。好處是每一幀只渲染可見的那十幾條滾動再快也不會卡壞處是需要自己處理同步也就是后面幾章要講的東西。第三種是「單個 RecyclerView用 ViewType 區(qū)分左側和右側」。這種寫法會把你拖進手動計算寬度、手動處理橫豎混排的深坑除了極少數(shù)定制場景沒有理由選它。所以最后的結構是rvCategory 分割線 rvDish底部一條購物車欄。右側那個RecyclerView承擔了吸頂頭、菜品項、滾動反推三件事是整頁的核心。2.2 菜單數(shù)據(jù)模型價格存整數(shù)分模型這塊的坑主要在價格上。用Double存金額購物車里累加幾次就會冒出39.999999這種數(shù)字再toString到角標上就是線上事故。所以單價從一開始就用整數(shù)存「分」只在顯示的時候除以 100。// Menu.kt —— 菜單模型金額統(tǒng)一用「分」存 Int避免浮點累加誤差 data class Category( val id: Int, val name: String, val dishList: ListDish ) data class Dish( val id: Int, val name: String, val priceFen: Int, // 單價單位分 val originPriceFen: Int? null, val soldCount: Int 0, // 月售用于展示「月售 300」 val desc: String , val imageUrl: String ) { // 只在渲染時轉成元展示層拿到的永遠是格式化好的字符串 val priceYuan: String get() %.2f.format(priceFen / 100f) } // 購物車條目和菜品是一對多關系用 dishId 做 key data class CartItem( val dish: Dish, var count: Int )priceFen用Int而不是Long是因為單個菜品的單價不可能超過 21 億分約 2100 萬元Int足夠但購物車總價要換成Long累加幾十個菜乘起來雖然也到不了上限但養(yǎng)成習慣更穩(wěn)。priceYuan寫成計算屬性是為了讓 Adapter 里只寫一句binding.tvPrice.text dish.priceYuan不在 UI 層做任何算術。2.3 XML 骨架與幾個必須定死的尺寸參數(shù)布局本身不復雜但有幾個尺寸必須在 XML 里一次定死后面所有偏移計算都要用到它們中途改一次會牽動一大片。androidx.constraintlayout.widget.ConstraintLayout xmlns:androidhttp://schemas.android.com/apk/res/android xmlns:apphttp://schemas.android.com/apk/res-auto android:layout_widthmatch_parent android:layout_heightmatch_parent !-- 左側分類寬度固定不隨屏幕伸縮 -- androidx.recyclerview.widget.RecyclerView android:idid/rvCategory android:layout_width96dp android:layout_height0dp android:background#F5F5F5 android:overScrollModenever app:layout_constraintBottom_toTopOfid/cartBar app:layout_constraintStart_toStartOfparent app:layout_constraintTop_toTopOfparent / View android:idid/divider android:layout_width0.5dp android:layout_height0dp android:background#EEEEEE app:layout_constraintBottom_toTopOfid/cartBar app:layout_constraintStart_toEndOfid/rvCategory app:layout_constraintTop_toTopOfparent / !-- 右側菜品寬度 0dp 撐滿剩余空間 -- androidx.recyclerview.widget.RecyclerView android:idid/rvDish android:layout_width0dp android:layout_height0dp android:clipToPaddingfalse android:paddingBottom8dp app:layout_constraintBottom_toTopOfid/cartBar app:layout_constraintEnd_toEndOfparent app:layout_constraintStart_toEndOfid/divider app:layout_constraintTop_toTopOfparent / include android:idid/cartBar layoutlayout/layout_cart_bar android:layout_width0dp android:layout_height56dp app:layout_constraintBottom_toBottomOfparent app:layout_constraintEnd_toEndOfparent app:layout_constraintStart_toStartOfparent / /androidx.constraintlayout.widget.ConstraintLayout參數(shù)取值為什么是這個值左側分類寬度96dp再窄中文分類名會折行再寬會壓縮菜品區(qū)窄屏機型可以用 88dp分割線寬度0.5dp1dp 在高密度屏上偏粗0.5dp 正好是一條視覺上的細線購物車欄高度56dp符合 Material 的最小可點區(qū)域低于 48dp 容易誤觸吸頂分類頭高度44dp與列表內(nèi)普通分類頭保持一致切換時不會有高度跳變菜品項左邊距12dp和分割線拉開呼吸感同時保證圖片不會貼邊clipToPaddingfalse這一行別省。右側列表給它加上paddingBottom之后如果不關掉裁剪最后一個分類滾到底會被切掉一截看起來像數(shù)據(jù)丟了實際是 padding 被裁掉了。這個現(xiàn)象我第一次遇到時排查了快半小時。3. 左側分類列表選中態(tài)、居中與點擊驅(qū)動3.1 分類 Adapter 與選中態(tài)刷新左側列表的 item 極簡只有一個文字但選中態(tài)的處理方式直接決定滑動時會不會掉幀。class CategoryAdapter( private val data: ListCategory ) : RecyclerView.AdapterCategoryAdapter.VH() { // 當前選中的分類下標唯一數(shù)據(jù)源 var selectedIndex 0 private set var onCategoryClick: ((Int) - Unit)? null // 只刷新「舊選中」和「新選中」兩個位置不做全量刷新 fun select(index: Int) { if (index selectedIndex) return // 判重是防抖動的第一道關 if (index !in data.indices) return val old selectedIndex selectedIndex index notifyItemChanged(old) notifyItemChanged(index) } inner class VH(val binding: ItemCategoryBinding) : RecyclerView.ViewHolder(binding.root) override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): VH { val binding ItemCategoryBinding.inflate( LayoutInflater.from(parent.context), parent, false ) return VH(binding) } override fun onBindViewHolder(holder: VH, position: Int) { val item data[position] holder.binding.tvName.text item.name // 用 isSelected 驅(qū)動 selector不在代碼里手動改背景色 holder.binding.tvName.isSelected position selectedIndex holder.binding.root.setOnClickListener { onCategoryClick?.invoke(position) } } override fun getItemCount() data.size }這里最關鍵的兩句是if (index selectedIndex) return和notifyItemChanged(old)。前者擋住重復回調(diào)——右側列表一次滑動會連續(xù)觸發(fā)幾十次onScrolled如果不判重每一幀都會走一遍notifyItemChanged左側列表在快速滑動時會出現(xiàn)肉眼可見的閃爍。后者避免了notifyDataSetChanged()那個方法會讓整個列表重新綁定分類一多就是明顯的掉幀。選中態(tài)本身交給 selector 處理res/color/category_text_selector.xml里寫兩個狀態(tài)state_selectedtrue給深色加粗默認給灰色。這樣切換選中態(tài)時不需要在 Adapter 里碰setTextColor也就不存在「上一個沒恢復」的問題。3.2 三個滾動 API 的差別以及我為什么只用其中一個RecyclerView 控制滾動位置有三個常用方法很多人混著用結果就是「點一下滾不到位」或者「滾過去又被彈回來」。val lm rvDish.layoutManager as LinearLayoutManager // 1瞬間定位沒有任何動畫。特點是執(zhí)行完立刻就到但用戶看不到過程 lm.scrollToPosition(targetPos) // 2平滑滾動有動畫。但它只保證「目標可見」不保證停在頂部 rvDish.smoothScrollToPosition(targetPos) // 3瞬間定位并讓目標條目頂部距離 RecyclerView 頂部 offset 像素 lm.scrollToPositionWithOffset(targetPos, offsetPx)第一個和第三個的區(qū)別在于「停在哪」。scrollToPosition只保證目標進可視區(qū)如果目標本來就可見它甚至不會滾scrollToPositionWithOffset是強制的一定把目標條目的頂部對齊到「父容器頂部 offsetPx」這個位置。左側點擊驅(qū)動右側要的正是「這個分類的第一條菜必須出現(xiàn)在頂部下方」所以只用第三個。第二個方法在這里幫不上忙它滾得慢用戶連點兩下就會看到列表來回晃體驗反而更差。// 吸頂頭高度從 dimen 里取別在代碼里寫死像素 private val stickyHeaderPx by lazy { resources.getDimensionPixelSize(R.dimen.dish_header_height) } private var suppressRightCallback false categoryAdapter.onCategoryClick { index - // 1. 左側自身先切選中態(tài) categoryAdapter.select(index) // 2. 找到這個分類第一條菜品在右側的 adapter position val target menuAdapter.positionOfCategory(index) // 3. 標記「這次滾動是代碼觸發(fā)的」防止右側反推又把選中改回去 suppressRightCallback true // 4. offset 傳吸頂頭高度否則第一條菜會被吸頂頭壓住 (rvDish.layoutManager as LinearLayoutManager) .scrollToPositionWithOffset(target, stickyHeaderPx) // 5. 讓左側被點的分類盡量滾到可視區(qū)中間 centerCategoryInList(index) // 兜底釋放防止右側沒觸發(fā)滾動時標志位一直掛著 rvDish.postDelayed({ suppressRightCallback false }, 120L) } // 左側自身滾動目標是讓選中項落在可視區(qū)中間而不是簡單滾到可見 private fun centerCategoryInList(index: Int) { val lm rvCategory.layoutManager as LinearLayoutManager val visibleCount lm.findLastVisibleItemPosition() - lm.findFirstVisibleItemPosition() 1 // 減去半個可視高度讓選中項居中 val target index - visibleCount / 2 rvCategory.smoothScrollToPosition( target.coerceIn(0, categoryAdapter.itemCount - 1) ) }scrollToPositionWithOffset的第二個參數(shù)單位是像素不是 dp。這是最常見的錯誤來源直接傳44以為傳的是 44dp在高密度屏上吸頂頭只有 44px 高菜品依然會被蓋住一半。正確做法是從dimen.xml里用getDimensionPixelSize取讓系統(tǒng)按密度換算好。centerCategoryInList里那個visibleCount / 2是讓選中項居中的關鍵。如果直接smoothScrollToPosition(index)選中項只會滾到「剛好可見」的邊界用戶點的時候視線在屏幕下方點完列表紋絲不動會以為沒響應。3.3 菜單數(shù)據(jù)從 assets 的 JSON 讀進內(nèi)存做 Demo 的時候菜品數(shù)據(jù)通常來自本地放在assets/menu.json里。結構跟數(shù)據(jù)類對齊解析的時候注意必填和選填的區(qū)分。object MenuRepository { fun load(context: Context): ListCategory { val json context.assets.open(menu.json) .bufferedReader().use { it.readText() } val arr JSONArray(json) val result ArrayListCategory(arr.length()) for (i in 0 until arr.length()) { val c arr.getJSONObject(i) // 分類名為空說明數(shù)據(jù)有問題直接跳過比渲染一個空分類更安全 val name c.optString(name) if (name.isBlank()) continue val dishArr c.optJSONArray(dishList) ?: JSONArray() val dishes ArrayListDish(dishArr.length()) for (j in 0 until dishArr.length()) { val d dishArr.getJSONObject(j) dishes.add( Dish( id d.getInt(id), // 必填缺失直接拋異常 name d.getString(name), priceFen d.getInt(priceFen), soldCount d.optInt(soldCount, 0), // 選填給默認值 desc d.optString(desc), imageUrl d.optString(imageUrl) ) ) } // 空分類不進列表右側沒有菜品可滾聯(lián)動會算出越界位置 if (dishes.isEmpty()) continue result.add(Category(c.getInt(id), name, dishes)) } return result } }必填字段用getInt/getString選填字段用optInt/optString帶默認值。這個區(qū)分不是風格問題必填字段缺失說明數(shù)據(jù)源有問題早點崩在解析階段比等到 UI 上出現(xiàn)一個叫 null 的分類更容易定位。optString在沒有這個 key 的時候返回空字符串而不是 null省掉了后面一層判空。兩個continue也很重要。空分類如果在列表里存在positionOfCategory會算出指向下一個分類頭的下標點下去右側滾到的是別的分類這種 bug 在數(shù)據(jù)少的時候完全看不出來上線接了真實接口才炸。4. 右側菜品列表吸頂分類頭與滾動反推4.1 MenuAdapter把分類和菜品拍平成一維列表右側列表里既有「分類頭」又有「菜品」最省事的做法不是嵌套而是把它們拍平成一個一維數(shù)組用 ViewType 區(qū)分。class MenuAdapter( private val data: ListCategory ) : RecyclerView.AdapterRecyclerView.ViewHolder() { companion object { const val TYPE_HEADER 0 const val TYPE_DISH 1 const val PAYLOAD_COUNT payload_count } // 拍平后的索引表position - (categoryIndex, dishIndex) // dishIndex -1 表示這一項是分類頭 private val flat ArrayListPairInt, Int() init { rebuild() } private fun rebuild() { flat.clear() data.forEachIndexed { ci, category - flat.add(ci to -1) // 分類頭 category.dishList.forEachIndexed { di, _ - flat.add(ci to di) // 菜品 } } } // 某個分類的第一條菜品位置 分類頭位置 1 fun positionOfCategory(categoryIndex: Int): Int { val headerPos flat.indexOfFirst { it.first categoryIndex it.second -1 } return if (headerPos 0) 0 else headerPos 1 } fun isHeader(position: Int): Boolean flat[position].second -1 fun categoryOf(position: Int): Int flat[position].first fun categoryName(categoryIndex: Int): String data[categoryIndex].name fun dishOf(position: Int): Dish { val (ci, di) flat[position] return data[ci].dishList[di] } override fun getItemViewType(position: Int): Int if (isHeader(position)) TYPE_HEADER else TYPE_DISH override fun getItemCount(): Int flat.size }flat這張表是整個聯(lián)動的地基。有了它position、分類下標、菜品下標三者之間的換算全是一次數(shù)組訪問不需要任何嵌套循環(huán)。positionOfCategory返回headerPos 1而不是headerPos是因為滾過去的落點應該是第一條菜不是分類頭本身——分類頭會被吸頂頭遮住滾到它沒有意義。這里有個隱含前提每個分類至少要有一條菜。3.3 里已經(jīng)過濾掉空分類了所以headerPos 1一定落在菜品上不會串到下一個分類頭。4.2 ItemDecoration 手寫吸頂頭吸頂分類頭有兩種實現(xiàn)一種是給每個分類頭一個「sticky」的標記在onDrawOver里把它畫到頂部另一種是用第三方庫。我一般手寫因為需求往往會有細微差別比如分類名右邊要帶一個「共 N 件」手寫改起來更自由。class StickyHeaderDecoration( private val adapter: MenuAdapter, private val headerHeight: Int, // px從 dimen 取 private val textSizePx: Float, // px從 dimen 取 private val bgColor: Int Color.WHITE ) : RecyclerView.ItemDecoration() { private val bgPaint Paint(Paint.ANTI_ALIAS_FLAG).apply { color bgColor } private val textPaint Paint(Paint.ANTI_ALIAS_FLAG).apply { color Color.parseColor(#333333) textSize textSizePx // 必須傳 px寫死 13f 在高密度屏上會小到看不清 } // 給每個分類的第一條菜品預留吸頂頭高度避免內(nèi)容被壓住 override fun getItemOffsets( outRect: Rect, view: View, parent: RecyclerView, state: RecyclerView.State ) { val pos parent.getChildAdapterPosition(view) if (pos RecyclerView.NO_POSITION) return // 分類頭本身也要占位這樣第一條菜品不會貼在吸頂頭下面 if (adapter.isHeader(pos)) { outRect.top 0 } else if (adapter.isHeader(pos - 1) || pos 0) { outRect.top 0 } } override fun onDrawOver(c: Canvas, parent: RecyclerView, state: RecyclerView.State) { val lm parent.layoutManager as? LinearLayoutManager ?: return val first lm.findFirstVisibleItemPosition() if (first RecyclerView.NO_POSITION) return val categoryIndex adapter.categoryOf(first) var offsetY 0f // 找到下一個可見的分類頭。如果它已經(jīng)頂?shù)轿旑^下方 // 就把吸頂頭往上推形成推擠效果 for (i in 0 until parent.childCount) { val child parent.getChildAt(i) val pos parent.getChildAdapterPosition(child) if (pos RecyclerView.NO_POSITION || pos first) continue if (adapter.isHeader(pos)) { if (child.top headerHeight) { offsetY (child.top - headerHeight).toFloat() } break } } // 吸頂頭背景 c.drawRect(0f, offsetY, parent.width.toFloat(), offsetY headerHeight, bgPaint) // 文字垂直居中baseline 要通過字體度量算不能用 headerHeight / 2 val title adapter.categoryName(categoryIndex) val baseline offsetY headerHeight / 2f - (textPaint.descent() textPaint.ascent()) / 2f c.drawText(title, parent.resources.displayMetrics.density * 12f, baseline, textPaint) } }這段代碼里有三個地方值得單獨說。第一getItemOffsets里我把outRect.top全部設成了 0看起來像沒做事。實際上空間是由 XML 里分類頭 item 自身的高度提供的getItemOffsets在這里主要起兜底作用——如果你后面改成「分類頭不占 item 空間」的方案才需要在這里給菜品加outRect.top headerHeight。兩種方案都能跑但只能選一種混用會導致間距翻倍。第二onDrawOver里的循環(huán)是找「下一個可見的分類頭」不是first 1。因為first 1可能是一條菜品adapter.isHeader判斷會失敗推擠效果就永遠不出現(xiàn)。遍歷childCount是 O(可見項數(shù))最多十幾個性能上可以忽略。第三文字 baseline 的計算不能偷懶寫offsetY headerHeight / 2f。那樣算出來的是文字的中間線實際渲染會整體偏下小半個字高。正確寫法是把descent ascent的平均值減掉這個細節(jié)在短文字上不明顯分類多的時候整列看起來會有點歪。注冊的方式和普通 ItemDecoration 一樣rvDish.addItemDecoration( StickyHeaderDecoration( adapter menuAdapter, headerHeight resources.getDimensionPixelSize(R.dimen.dish_header_height), textSizePx resources.getDimension(R.dimen.text_13sp) ) )注意resources.getDimension返回的已經(jīng)是 pxsp 會按字體縮放換算不需要再手動乘 density。4.3 滾動反推當前分類與防止抖動的標志位滾動反推的邏輯本身很短右側滾到什么位置就把左側對應的分類設為選中。rvDish.addOnScrollListener(object : RecyclerView.OnScrollListener() { private var lastUpdateTime 0L private val throttleMs 50L // 50ms 內(nèi)的連續(xù)回調(diào)只處理一次 override fun onScrolled(recyclerView: RecyclerView, dx: Int, dy: Int) { if (dy 0) return // 代碼觸發(fā)的滾動不回寫否則點分類會導致左閃閃閃 if (suppressRightCallback) return val now SystemClock.elapsedRealtime() if (now - lastUpdateTime throttleMs) return lastUpdateTime now val lm recyclerView.layoutManager as LinearLayoutManager val first lm.findFirstVisibleItemPosition() if (first RecyclerView.NO_POSITION) return val ci menuAdapter.categoryOf(first) if (ci ! categoryAdapter.selectedIndex) { categoryAdapter.select(ci) centerCategoryInList(ci) } } override fun onScrollStateChanged(recyclerView: RecyclerView, newState: Int) { // 滑動停止時釋放標志位這是最可靠的釋放時機 if (newState RecyclerView.SCROLL_STATE_IDLE) { suppressRightCallback false } } })這里不用判斷 ViewType。因為categoryOf(first)返回的是第一可見項所屬的分類下標不管是分類頭還是菜品都屬于同一個分類答案是一樣的。少一個分支就少一個出錯點。suppressRightCallback是整段邏輯里最容易被寫錯的地方。它的作用是區(qū)分「這次滾動是人手滑的」還是「代碼點分類觸發(fā)的」。如果不做區(qū)分點分類 → 右側滾動 →onScrolled觸發(fā) → 反推 → 又去改選中 → 又觸發(fā)滾動列表就會來回抖。釋放時機我踩過兩個版本。第一版是在post {}里釋放結果右側的onScrolled是分幀分發(fā)的post跑完了滾動事件還在來標志位已經(jīng)放了抖動照舊。第二版改成postDelayed(120ms)能跑但機器一卡就不準。最終定在onScrollStateChanged的IDLE因為滾動結束時狀態(tài)一定會回到 IDLE這是最穩(wěn)的信號。3.2 里的postDelayed兜底不能省它防的是「右側本來就在這個位置、根本沒觸發(fā)滾動」的情況沒有這個兜底下一次手動滑動右側時左側就不跟了。5. 聯(lián)動菜單避坑記錄從現(xiàn)象到解決的 5 條排查清單5.1 點分類后第一條菜被吸頂頭壓住現(xiàn)象點「主食」分類右側確實滾過去了但最上面那道菜只露出下半截上半截在分類頭底下。原因scrollToPositionWithOffset(target, 0)把目標條目頂?shù)搅?RecyclerView 的頂部邊緣而吸頂頭是onDrawOver畫上去的繪制層級在 item 之上于是蓋住了第一行。offset 傳 0 等于完全沒給吸頂頭讓位。解決offset 傳stickyHeaderPx讓目標條目頂部對齊到吸頂頭下沿。如果分類頭本身也占據(jù) item 空間我這里的方案那么 offset 只需要吸頂頭高度不要重復加分類頭高度。5.2 手動快速滑動右側左側高亮瘋狂閃爍現(xiàn)象手指快速上下滑右側菜品左側選中項像是壞了來回跳。原因一次手指滑動會連續(xù)觸發(fā)幾十次onScrolled每次都調(diào)用categoryAdapter.select(ci)。雖然select里有判重但快速滑過多個分類時ci每次都不一樣判重擋不住等于每一幀都在刷兩個 item。解決一是在onScrolled里加 50ms 節(jié)流滑動過程中每 50ms 才更新一次選中二是select里保留判重作為最后一道防線。實測加上節(jié)流之后連續(xù)滑過十幾個分類左手邊也只更新三四次視覺上完全夠用。5.3 連續(xù)快速點三個分類右側停在中間那個現(xiàn)象手快連點「熱銷」「套餐」「飲品」期望停在「飲品」實際停在「套餐」。原因scrollToPositionWithOffset是同步的但它觸發(fā)的onScrolled是異步分發(fā)的。第三次點擊時本文還有配套的精品資源點擊獲取