簡介這是一份面向Android開發初學者與課程設計者的二手圖書交易平臺安卓端完整項目源碼聚焦移動端二手書交易場景涵蓋用戶注冊、登錄、圖書瀏覽與發布等核心功能模塊。資源包共286個文件含109個Java業務邏輯文件、94個XML界面布局文件、60個PNG圖標資源及7個JPG圖片素材輔以Gradle構建腳本3個.gradle、配置文件2個.properties和版本控制相關文件2個.gitignore整體壓縮后僅4.52MB結構清晰、輕量易上手。已有56人學習下載適合用于Android Studio實戰練習、畢業設計參考或MVP架構入門理解。項目采用全局常量類AppConstants統一管理API地址需替換IP即可對接服務端README.md提供基礎使用說明引導頁與實際運行截圖已集成便于快速驗證功能完整性與UI交互效果。 接手這個項目的時候我最初以為只是一個普通的課程設計級別應用——用戶注冊登錄、圖書列表、詳情頁、下單撐死再加個搜索。但真正把需求梳理清楚、進入編碼階段之后才發現二手圖書交易平臺這個選題難點根本不在功能多而在于“交易”兩個字帶來的狀態流轉、信任機制和數據一致性。尤其是安卓端作為一個直接面向C端用戶的入口既要保證體驗流暢又要兼顧圖片加載、網絡容錯、離線狀態、內存占用這些移動端特有的問題。如果你正在準備做一個類似的安卓項目或者剛拿到一份“二手圖書交易平臺 安卓端.zip”的源碼想二次開發這篇文章應該能幫你省下不少彎路。我會從項目整體拆解、技術選型、核心模塊的落地細節、實際開發中踩過的坑、性能優化一直講到最后打包交付的完整流程。整個過程基于真實開發經驗提供可以直接拿走的代碼思路和配置方案。1. 先別急著寫代碼二手圖書交易平臺的業務邊界在哪很多同學拿到這類項目第一反應是打開 Android Studio 直接建工程。我的建議恰恰相反——先花一兩天把業務模型想清楚尤其是“二手交易”和“新書商城”的差異。這個差異決定了你的數據庫表設計、界面布局乃至整個接口約定。1.1 二手交易的核心痛點是“品相”和“信任”新書商城賣的是標準化商品核心字段是書名、作者、出版社、ISBN、庫存、價格。但二手圖書不一樣兩個關鍵問題立刻浮現第一同一本書可以有 N 個賣家每個賣家的品相、售價、可議價空間都不同。這意味著商品表不能以“書”為唯一維度而是要以“賣家發布的某本書的某個副本”為維度。設計上我建議拆成圖書基本信息表BookInfo和商品發布表Product兩張表前者存 ISBN、書名、封面、作者、出版社等靜態信息后者存賣家ID、售價、原價比例、品相描述、實拍圖URL、是否包郵等動態信息。第二交易信任建立在細節描述上。二手書最重要的篩選條件不是價格而是品相。我在做需求分析時把品相分成了五檔全新、近全新、輕微使用痕跡、明顯磨損、有筆記劃線。每一檔在 UI 上要有對應的標簽色和圖標在數據庫里存整數字段1-5同時允許用戶填寫自定義描述比如“第37頁有鉛筆劃線不影響閱讀”。這些細節在安卓端看起來只是幾個控件但直接影響搜索排序和用戶下單決策。1.2 Android端的功能邊界如何劃分如果做的是純安卓端項目沒有配套服務端源碼那大概率是用本地數據庫模擬遠程數據或者接一個現成的 BaaS 服務。我在實際開發中建議按照 MVC 的職責把功能分成三層用戶側注冊登錄手機號驗證碼或賬號密碼、個人中心、我發布的商品、我買到的、我賣出的、收貨地址管理。商品側發布商品拍照/相冊選圖、填品相、定價、商品列表分類篩選、關鍵詞搜索、價格/品相排序、商品詳情多圖輪播、賣家信息、評論區/留言。交易側加入購物車、立即購買、下單確認地址運費、訂單狀態跟蹤待付款/待發貨/待收貨/已完成/已取消、訂單留言。這里有個常見的誤區第一版就把 IM 聊天、在線支付、推送全做進去。我建議把聊天簡化為“留言板”支付做成“模擬支付”點擊后直接跳轉模擬成功頁推送可以完全不做用下拉刷新代替。把核心交易閉環跑通才是這個項目的價值所在。如果后續要擴展這些模塊再逐步替換。1.3 數據模型的實體關系直接決定開發效率我經歷過一次因為表設計不合理導致的大重構所以現在做項目第一步永遠是畫 ER 圖。二手圖書交易平臺的核心實體我建議這樣設計Useruid主鍵、nickname、avatarUrl、phone、createTime。BookInfobookId主鍵、isbn、title、author、publisher、coverUrl、categoryId。ProductproductId主鍵、bookId、sellerId、price、conditionLevel1-5、conditionDesc、coverImagesJSON數組存多圖、status0下架 1在售 2已售 3審核中、createTime。OrderorderId主鍵、productId、buyerId、sellerId、addressId、totalPrice、freightPrice、status0待付款 1待發貨 2待收貨 3已完成 4已取消 5退款中、createTime、payTime、shipTime、finishTime。用 Room 還是直接 SQLite我建議 Room理由后面會講。但無論用哪種表關系必須提前定清楚。Product 和 BookInfo 是多對一多個賣家賣同一本書Order 和 Product 是一對一一個商品只能屬于一個訂單Order 和 User 是多對一。這些關系定清楚了寫 DAO 的時候基本是機械工作。2. 技術選型的取舍為什么我選 MVVM Retrofit Glide Room安卓開發的技術棧選擇很多但對于“二手圖書交易平臺”這個體量的項目我的建議是“主流穩定優先不做實驗性嘗試”。下面把每項選型的原因和替代方案講清楚。2.1 架構模式MVVM 比 MVC 更適合這個項目MVC 在 Activity 里堆邏輯一旦頁面復雜起來Activity 會膨脹到上千行。二手圖書的詳情頁什么都有——圖片輪播、品相標簽、賣家信息、留言列表、底部操作欄加上網絡請求的狀態管理加載中/成功/失敗/空數據如果用 MVC代碼會非常難維護。MVVM 的核心是 ViewModel LiveData或 StateFlowActivity 只負責渲染和事件分發業務邏輯全部下沉到 ViewModel數據變化通過觀察者模式通知 UI。我用的組合是ViewModel持有頁面狀態處理用戶交互事件。LiveDataUI 感知的生命周期組件避免內存泄漏。Repository 倉庫層統一管理數據來源網絡 or 本地ViewModel 只面向 Repository 接口。在這個項目里我寫了 ProductRepository、OrderRepository、UserRepository 三個倉庫類每個倉庫負責對應模塊的數據獲取和緩存策略。例如 ProductRepository 的getProductList(categoryId, page)方法先從網絡獲取第一頁數據同時緩存到本地 Room下次打開 App 如果網絡不通就加載緩存——這個機制在弱網環境下體驗提升非常明顯。2.2 網絡層Retrofit2 OkHttp 的套路化配置Retrofit 是安卓網絡請求的事實標準沒有太多懸念。但有幾個配置細節值得注意第一統一添加公共參數。比如 userId、deviceId、appVersion用 OkHttp 的 Interceptor 實現在請求頭里自動注入不用每個接口都手動傳。class CommonParamsInterceptor : Interceptor { override fun intercept(chain: Interceptor.Chain): Response { val originalRequest chain.request() val newRequest originalRequest.newBuilder() .header(Content-Type, application/json) .header(deviceId, DeviceUtils.getDeviceId()) .build() return chain.proceed(newRequest) } }第二統一處理錯誤碼。后端接口通常會返回類似{ code: 0, message: success, data: {...} }的結構。我在 ApiResponse 泛型里封裝了 code 和 message在 Repository 層統一判斷 code 是否為 0非 0 直接拋業務異常UI 層只需要關心成功與否不需要每個頁面重復判斷。第三超時時間設長一點。二手圖書的詳情頁會加載多張實拍圖弱網下 3 秒超時很容易失敗。我把連接超時設為 10 秒讀取超時設為 15 秒寫入超時 15 秒。實測穩定很多。2.3 圖片加載Glide 4.x 的緩存策略要調二手書交易平臺的特殊性在于圖片量大、且很多是用戶手機里的實拍圖分辨率參差不齊。Glide 依然是首選但有三點必須配置好第一自定義 OkHttp 網絡模塊。Glide 默認使用 HttpURLConnection但項目的網絡層是 OkHttp統一用 OkHttp 可以共享連接池和攔截器避免重復握手。通過AppGlideModule實現GlideModule class MyAppGlideModule : AppGlideModule() { override fun registerComponents(context: Context, glide: Glide, registry: Registry) { registry.replace(GlideUrl::class.java, InputStream::class.java, OkHttpUrlLoader.Factory()) } }第二磁盤緩存策略設置為 DATA 和 RESOURCE 都緩存。對于多次展示的商品封面圖緩存原始圖和裁剪圖都能顯著加快二次加載速度。第三縮略圖加載。詳情頁的輪播圖加載大圖時先用thumbnail(0.1f)加載低分辨率縮略圖占位再加載高清圖。視覺上體驗會好很多尤其在高清圖加載慢時不會出現空白。2.4 本地存儲Room 解決了 SQLite 的樣板代碼問題如果不做本地緩存SQLite 手寫 SQLiteOpenHelper 也能跑通。但項目里需要緩存商品列表、搜索歷史、用戶信息手寫 Cursor 轉實體類實在痛苦。Room 的編譯期 SQL 校驗能提前發現 SQL 錯誤配合 Flow 做響應式查詢非常舒服。建議建三個 EntityBookInfoEntity、ProductEntity、UserEntity。DAO 層用掛起函數 Flow例如Dao interface ProductDao { Query(SELECT * FROM product WHERE categoryId :categoryId ORDER BY createTime DESC LIMIT :pageSize OFFSET :offset) fun getProductsByCategory(categoryId: Int, pageSize: Int, offset: Int): FlowListProductEntity Insert(onConflict OnConflictStrategy.REPLACE) suspend fun insertProducts(products: ListProductEntity) }使用 Flow 的好處是當緩存表更新時UI 會自動收到新數據天然實現了“網絡刷新后 UI 同步”。3. 核心功能落地的關鍵細節狀態機、圖片上傳、搜索與訂單業務模型清楚了技術棧選好了下面講幾個最容易寫出 bug 的地方。這些模塊寫好了項目質量會明顯上一個臺階。3.1 商品狀態機設計別再到處寫 if-else 了二手商品在生命周期中會有多次狀態變化草稿 - 審核中 - 在售 - 已售或下架/刪除。一開始我是在 Product 實體里直接加一個 status 字段每個頁面判斷 status 的值來決定顯示什么按鈕。結果訂單頁要判斷、詳情頁要判斷、個人中心“我發布的”要判斷邏輯散落各處改一個狀態牽扯一大片。后來我重構為狀態機模式把狀態流轉集中在一個類里管理每個狀態定義允許的事件和對應的目標狀態。例如enum class ProductStatus(val value: Int) { DRAFT(0), REVIEWING(1), ON_SALE(2), SOLD(3), OFF_SHELF(4); fun canTransitTo(target: ProductStatus): Boolean { return when (this) { DRAFT - target REVIEWING || target OFF_SHELF REVIEWING - target ON_SALE || target OFF_SHELF ON_SALE - target SOLD || target OFF_SHELF SOLD - false OFF_SHELF - target ON_SALE || target REVIEWING } } }在發布商品時表單校驗通過后調用productRepository.changeStatus(productId, ProductStatus.ON_SALE)Repository 內部先檢查當前狀態和下一狀態是否合法不合法直接拋異常。這樣就把“用戶點按鈕 - 狀態變更”的合法性收斂到了一處不會出現“已售出的商品還能下架”這種詭異情況。3.2 圖片上傳壓縮、多圖、進度一個都不能少商品發布的圖片上傳模塊看起來簡單實際上有很多隱藏要求。用戶從相冊選 9 張圖每張可能 5-10MB直接傳到服務器不僅慢還容易失敗。我的處理方案是三段式選圖后立即壓縮使用Luban庫現在可以自己寫或用魯班算法將圖片壓縮到最長邊不超過 1280px、質量 80%這樣單張通常能壓到 300KB 以內。上傳前顯示進度用一個WorkManager或后臺線程池逐個上傳每上傳一張更新 UI 的進度條。這里建議用 OkHttp 的RequestBody重寫監聽上傳字節數。上傳完成后返回 URL 列表把返回的 URL 列表按順序保存到 Product 的coverImages字段前端展示時按此順序渲染輪播圖。多圖上傳的并發策略也很重要。我建議串行上傳第一張傳完再傳第二張。雖然比并發慢但失敗重試邏輯簡單且不會占滿帶寬導致列表頁圖片加載變慢。3.3 搜索基于關鍵詞 分類 排序的聯合查詢二手圖書的搜索和普通商品搜索不同用戶往往會帶上“考研”“計算機”“小說”這種關鍵詞同時希望按價格、品相、發布時間排序。數據庫查詢可以這樣設計Query( SELECT * FROM product INNER JOIN bookInfo ON product.bookId bookInfo.bookId WHERE (:keyword IS NULL OR bookInfo.title LIKE % || :keyword || % OR bookInfo.author LIKE % || :keyword || % OR bookInfo.isbn LIKE % || :keyword || %) AND (:categoryId IS NULL OR bookInfo.categoryId :categoryId) AND (:minPrice IS NULL OR product.price :minPrice) AND (:maxPrice IS NULL OR product.price :maxPrice) ORDER BY CASE WHEN :sortType 1 THEN product.price END ASC, CASE WHEN :sortType 2 THEN product.price END DESC, CASE WHEN :sortType 3 THEN product.createTime END DESC ) fun searchProducts( keyword: String?, categoryId: Int?, minPrice: Double?, maxPrice: Double?, sortType: Int ): FlowListProductEntity注意 SQL 中用CASE WHEN實現動態排序避免拼接字符串帶來的 SQL 注入風險。如果項目接的是服務端搜索接口那客戶端只需要傳參數但本地緩存搜索是離線模式的基礎能力。搜索的歷史記錄也建議用 Room 存一張 SearchHistory 表在搜索頁用瀑布流標簽形式展示最近 10 條點擊歷史標簽直接搜索體驗非常順手。3.4 訂單流程防重復下單和并發扣庫存訂單模塊是交易平臺最緊張的地方。兩個高發 bug用戶連點兩次“立即購買”創建了兩筆訂單同一個商品被兩個用戶同時下單但庫存只有一本。防重復下單的解決方式下單接口設置一個訂單防重 Token。用戶在點擊購買時客戶端先生成一個唯一的 requestIdUUID提交訂單時帶上這個 requestId服務端用 Redis 或數據庫唯一索引做冪等。但純安卓本地項目沒有服務端怎么辦我當時的方案是在本地訂單表給requestId加唯一約束插入時用OnConflictStrategy.IGNORE沖突就提示“請勿重復提交”。并發搶單的問題比較麻煩。如果做的是帶后端的完整項目建議用數據庫樂觀鎖UPDATE product SET status 2 WHERE productId ? AND status 1如果影響行數為 1說明搶單成功為 0說明商品已被別人買走。客戶端這邊只需要在下單前檢查商品狀態下單后重新拉取詳情更新 UI。4. 真實開發中的踩坑記錄圖片 OOM、Fragment 重建、列表卡頓這一部分是我最想分享的。網上搜源碼往往只能看到功能怎樣實現但開發過程中那些“怎么會這樣”的問題才是真正消耗時間的地方。我把遇到過的三個典型問題完整復盤一遍。4.1 商品列表快速滑動導致的內存暴增從 80MB 到 200MB第一次用 RecyclerView 加載商品列表時我直接用 Glide 加載封面圖占位圖用了一個很大的本地 drawable加載完成后沒做任何處理。快速滑動 100 條數據內存瞬間從 80MB 飆到 200MB最后直接 OOM 崩潰。排查過程是這樣的先用 Android Studio 的 Memory Profiler 抓內存快照發現byte[]占據了大頭進一步定位到 Glide 的 BitmapPool 一直在增長。原因有兩個一是每張原圖是 4000x3000 像素的實拍圖而列表 item 只需要 400x400 pxGlide 默認加載的是原始尺寸除非顯式指定override()二是占位圖是一張 1MB 的大圖導致每個 item 都持有一個大 Bitmap。修復方法很簡單Glide.with(itemView.context) .load(product.coverImages[0]) .override(480, 480) // 按列表 item 實際尺寸指定 .format(DecodeFormat.PREFER_RGB_565) // 不透明圖片用 RGB_565 省一半內存 .placeholder(R.drawable.ic_book_placeholder) .error(R.drawable.ic_book_error) .into(ivCover)另外把占位圖換成矢量 Drawable 或小尺寸 PNG幾百 KB 級別就夠。修復后快速滑動內存穩定在 100MB 內。這個問題的本質是“移動端加載圖片必須按需加載”原圖只應該在詳情頁做大圖展示時才加載。4.2 Fragment 重建導致的“頁面狀態丟失”項目里商品首頁、分類頁、我的頁面都用 Fragment BottomNavigationView 實現。一開始我直接在 Activity 的onCreate里 add 三個 Fragment沒有處理配置變更比如屏幕旋轉時的狀態保存。結果一轉屏Fragment 重建了ViewModel 雖然還在但 RecyclerView 的滾動位置、選中的 Tab、搜索頁輸入框的文字全部丟失。后來我引入了 Navigation Component 來管理 Fragment并配合 ViewModel 持有界面狀態。具體做法每個頁面的數據加載狀態和列表數據放到 ViewModel 的 LiveData / StateFlow 中。頁面上的純 UI 狀態比如滾動位置、Tab 選中項在onSaveInstanceState中保存到 Bundle。Fragment 重建后先從 ViewModel 恢復數據再從 Bundle 恢復 UI 狀態。這里特別強調一種容易忽略的場景從詳情頁返回列表頁列表頁的 Fragment 被系統回收后重建如果列表數據沒有緩存用戶看到的是空白頁。我當時的解決方案是在 Repository 層加了內存緩存ConcurrentHashMap列表數據加載一次后緩存重建頁面時直接從緩存恢復同時后臺刷新。4.3 評論/留言列表的嵌套滾動卡頓商品詳情的留言區是嵌套在 ScrollView 里的 RecyclerView。這樣做有幾個天然問題嵌套滾動事件沖突、滑動卡頓、RecyclerView 復用作廢。一開始怎么調都卡后來干脆放棄嵌套改用單一 RecyclerView 多類型 Item的方案。詳情頁頂部信息圖片輪播、標題、價格、品相描述作為 Header Item下面是留言列表 Item。這樣整個頁面只有一個滾動容器滑動流暢且復用正常。如果你只是臨時展示少量留言可以用NestedScrollView包 RecyclerView 并且設置android:nestedScrollingEnabledfalse讓 RecyclerView 不攔截滑動事件。但數據量超過 20 條后建議還是用多類型 Item 方案我實測差距非常明顯。5. 性能優化與交付從“能跑”到“好用”的差距項目功能做完只是第一步。真正讓人感覺“這個 App 質量不錯”的往往是那些看不見的優化。這一節我不講大道理只講在這個項目里親自落地過的優化項。5.1 啟動速度優化冷啟動從 2.3 秒壓到 1.2 秒冷啟動時間受 Application 初始化影響很大。我一開始在 Application 的onCreate里初始化了 Glide、LeakCanary、極光推送、網絡庫等一堆東西導致啟動時阻塞嚴重。現在的做法是分階段初始化必須在 Application 中同步初始化網絡庫、數據庫實例。因為這些是頁面啟動后立刻要用到的。可以放到首個頁面加載之后再初始化圖片加載庫可以延遲到頁面真正加載圖片時初始化、統計 SDK、推送 SDK 用異步線程初始化。具體實現可以用IdleHandler或WorkManager的initialize異步執行。我實測將 LeakCanary 和推送 SDK 放到主頁面onResume之后再初始化冷啟動時間從 2.3 秒降到 1.2 秒效果非常明顯。5.2 APK 體積控制從 45MB 瘦身到 28MB二手圖書項目的 APK 體積主要被三塊占據圖片資源、第三方庫、多架構 so 文件。我做過的有效瘦身手段開啟資源混淆android.enableResourceOptimizationstrue在 gradle.properties 中配合shrinkResources移除無用資源。移除多余 ABI如果只發布國內安卓市場abiFilters只保留arm64-v8a和armeabi-v7a去掉x86和x86_64體積瞬間減少很多。當然如果要在模擬器上測試需要保留 x86。圖片資源 WebP 化將啟動圖、默認頭像、占位圖全部轉換為 WebP 格式通常能比 PNG 再小 30%-50%。動態特性模塊如果項目足夠大可以把留言模塊、客服模塊做成 Dynamic Feature用戶按需下載。但對這個體量的項目這一步不是必須的。5.3 內存泄漏的排查工具鏈越是這種設計到大量圖片和網絡請求的 App越容易在退出后殘留內存泄漏。我每次開發到中后期都會用 LeakCanary 做一輪全量檢測。它檢測出的典型泄漏點有兩個Activity 被靜態變量持有比如單例里保存了 Activity 引用。我遇到過在 UserManager 里用靜態變量保存了當前用戶信息里面有 Bitmap 頭像間接持有了 Activity Context導致整個頁面無法回收。Handler / 回調未解綁。頁面銷毀后異步任務回調還在操作 View。修復方式所有跨頁面共享的 Context 一律使用getApplicationContext()Activity 相關的引用隨用隨取、用完即置空所有訂閱在onDestroy中取消。另外我做了一輪Memory Profiler 的 Heap Dump 分析發現商品列表頁退出后Glide 的緩存仍然占著 30MB 內存。這是正常的因為 Glide 有 LRU 緩存策略。但如果擔心緩存壓力可以在低內存時onTrimMemory回調中調用glide.clearMemory()和glide.clearDiskCache()。6. 打包與交付Zip 里應該有什么才能算一個完整的安卓項目到了項目交付和二次開發階段很多只發一個 .zip 壓縮包的朋友可能忽略了打包結構的完整性。一個合格的“二手圖書交易平臺 安卓端.zip”除了源碼應該包含讓接手者能立刻跑起來的一切。6.1 Gradle 配置里的坑如果你拿到手的 zip 里帶 local.properties里面寫著本機的 SDK 路徑那是無用的甚至可能導致別人打開工程時報錯。正確的做法是不提交 local.properties讓 Android Studio 自動生成。build.gradle里的compileSdk、targetSdk、minSdk要寫清楚。我用的是compileSdk 34,targetSdk 34,minSdk 24。注意targetSdk 34或更高版本會默認啟用分區存儲所以涉及圖片上傳的時候需要處理READ_MEDIA_IMAGES權限和ActivityResultContracts.PickVisualMedia這類新 API不能用老的READ_EXTERNAL_STORAGE。依賴庫的版本統一放到versions.gradle或ext中管理避免不同模塊依賴沖突。6.2 二次開發最需要看的三個文件如果這份 zip 是你要學習的源碼拿到手建議按這個順序閱讀文件/目錄作用app/src/main/java/.../di/或AppContainer.kt依賴注入入口看清單例和對象創建順序理解數據流。app/src/main/java/.../repository/Repository 層所有數據獲取邏輯在這里能看出數據來自網絡還是本地緩存。app/src/main/java/.../ui/按模塊劃分的包頁面和 ViewModel重點看商品列表和訂單流程的狀態管理。有了這三個文件的結構認知即使沒有完整文檔也能快速定位改動位置。6.3 多渠道打包和上架的注意事項如果你打算把這套代碼上架到應用市場有幾點得提前處理簽名文件.jks 簽名文件一定不能提交到 zip 里但要在 README 里說明需要自己生成。上架后簽名丟失是無法找回的所以項目初期就應該建立簽名備份機制。渠道包productFlavors配置不同渠道的applicationId后綴和渠道號騰訊樂固、360、應用寶等平臺需要識別渠道信息。可以用manifestPlaceholders注入渠道號。隱私合規如果集成了友盟統計、極光推送等 SDK在 targetSdk 34 下上架時隱私政策彈窗必須在其初始化之前展示并征得同意。7. 寫在最后做交易類項目的一點個人體會這個項目做完之后我最大的體會是交易類 App 的重點不是炫技而是把狀態管理和異常流程處理干凈。圖片加載、列表流暢度這些都是常規操作真正體現功底的是用戶在弱網下點下單、連續點兩次購買、商品中途被下架、支付成功但回調丟失這些場景下App 能不能給出合理的反饋。如果你正在做這份工程的二次開發我給三個具體建議第一優先打通一條完整的交易鏈路登錄 - 搜索 - 詳情 - 下單 - 支付 - 查看訂單。這條路走通項目的主干就成了其他功能都是枝葉。第二在列表頁和詳情頁之間傳遞數據時不要用 Internt 傳大對象。傳 productId 或 bookId 就夠詳情頁根據 ID 去倉庫重新讀取最新數據。因為列表頁的數據可能已經過期詳情頁顯示的價格、庫存必須是最新狀態。第三保持簡單不要過度設計。很多朋友一上來就用 Dagger Hilt、Paging 3、DataStore 替換所有組件結果排錯成本急劇上升。這些庫本身沒錯但在一個以二手圖書交易為核心的項目里ViewModel Repository LiveData Retrofit Glide 這個組合已經足夠穩定可靠。先跑通業務再考慮架構升級。最后再分享一件小事項目發布前我做了三輪真機測試最值錢的一輪是讓一個完全不懂 app 的同學上手操作看她會不會在發布商品的表單頁卡住、會不會困惑按鈕的位置。她反饋“上傳九張圖太麻煩”于是我把必填圖片從九張降到了三張并增加“使用示例圖”的快捷入口。這個改動帶來的好評率提升比任何代碼優化都明顯。做安卓開發始終要把自己當成最挑剔的用戶。本文還有配套的精品資源點擊獲取 二手圖書交易平臺安卓端開發實戰：架構設計、狀態機與性能優化
簡介這是一份面向Android開發初學者與課程設計者的二手圖書交易平臺安卓端完整項目源碼聚焦移動端二手書交易場景涵蓋用戶注冊、登錄、圖書瀏覽與發布等核心功能模塊。資源包共286個文件含109個Java業務邏輯文件、94個XML界面布局文件、60個PNG圖標資源及7個JPG圖片素材輔以Gradle構建腳本3個.gradle、配置文件2個.properties和版本控制相關文件2個.gitignore整體壓縮后僅4.52MB結構清晰、輕量易上手。已有56人學習下載適合用于Android Studio實戰練習、畢業設計參考或MVP架構入門理解。項目采用全局常量類AppConstants統一管理API地址需替換IP即可對接服務端README.md提供基礎使用說明引導頁與實際運行截圖已集成便于快速驗證功能完整性與UI交互效果。 接手這個項目的時候我最初以為只是一個普通的課程設計級別應用——用戶注冊登錄、圖書列表、詳情頁、下單撐死再加個搜索。但真正把需求梳理清楚、進入編碼階段之后才發現二手圖書交易平臺這個選題難點根本不在功能多而在于“交易”兩個字帶來的狀態流轉、信任機制和數據一致性。尤其是安卓端作為一個直接面向C端用戶的入口既要保證體驗流暢又要兼顧圖片加載、網絡容錯、離線狀態、內存占用這些移動端特有的問題。如果你正在準備做一個類似的安卓項目或者剛拿到一份“二手圖書交易平臺 安卓端.zip”的源碼想二次開發這篇文章應該能幫你省下不少彎路。我會從項目整體拆解、技術選型、核心模塊的落地細節、實際開發中踩過的坑、性能優化一直講到最后打包交付的完整流程。整個過程基于真實開發經驗提供可以直接拿走的代碼思路和配置方案。1. 先別急著寫代碼二手圖書交易平臺的業務邊界在哪很多同學拿到這類項目第一反應是打開 Android Studio 直接建工程。我的建議恰恰相反——先花一兩天把業務模型想清楚尤其是“二手交易”和“新書商城”的差異。這個差異決定了你的數據庫表設計、界面布局乃至整個接口約定。1.1 二手交易的核心痛點是“品相”和“信任”新書商城賣的是標準化商品核心字段是書名、作者、出版社、ISBN、庫存、價格。但二手圖書不一樣兩個關鍵問題立刻浮現第一同一本書可以有 N 個賣家每個賣家的品相、售價、可議價空間都不同。這意味著商品表不能以“書”為唯一維度而是要以“賣家發布的某本書的某個副本”為維度。設計上我建議拆成圖書基本信息表BookInfo和商品發布表Product兩張表前者存 ISBN、書名、封面、作者、出版社等靜態信息后者存賣家ID、售價、原價比例、品相描述、實拍圖URL、是否包郵等動態信息。第二交易信任建立在細節描述上。二手書最重要的篩選條件不是價格而是品相。我在做需求分析時把品相分成了五檔全新、近全新、輕微使用痕跡、明顯磨損、有筆記劃線。每一檔在 UI 上要有對應的標簽色和圖標在數據庫里存整數字段1-5同時允許用戶填寫自定義描述比如“第37頁有鉛筆劃線不影響閱讀”。這些細節在安卓端看起來只是幾個控件但直接影響搜索排序和用戶下單決策。1.2 Android端的功能邊界如何劃分如果做的是純安卓端項目沒有配套服務端源碼那大概率是用本地數據庫模擬遠程數據或者接一個現成的 BaaS 服務。我在實際開發中建議按照 MVC 的職責把功能分成三層用戶側注冊登錄手機號驗證碼或賬號密碼、個人中心、我發布的商品、我買到的、我賣出的、收貨地址管理。商品側發布商品拍照/相冊選圖、填品相、定價、商品列表分類篩選、關鍵詞搜索、價格/品相排序、商品詳情多圖輪播、賣家信息、評論區/留言。交易側加入購物車、立即購買、下單確認地址運費、訂單狀態跟蹤待付款/待發貨/待收貨/已完成/已取消、訂單留言。這里有個常見的誤區第一版就把 IM 聊天、在線支付、推送全做進去。我建議把聊天簡化為“留言板”支付做成“模擬支付”點擊后直接跳轉模擬成功頁推送可以完全不做用下拉刷新代替。把核心交易閉環跑通才是這個項目的價值所在。如果后續要擴展這些模塊再逐步替換。1.3 數據模型的實體關系直接決定開發效率我經歷過一次因為表設計不合理導致的大重構所以現在做項目第一步永遠是畫 ER 圖。二手圖書交易平臺的核心實體我建議這樣設計Useruid主鍵、nickname、avatarUrl、phone、createTime。BookInfobookId主鍵、isbn、title、author、publisher、coverUrl、categoryId。ProductproductId主鍵、bookId、sellerId、price、conditionLevel1-5、conditionDesc、coverImagesJSON數組存多圖、status0下架 1在售 2已售 3審核中、createTime。OrderorderId主鍵、productId、buyerId、sellerId、addressId、totalPrice、freightPrice、status0待付款 1待發貨 2待收貨 3已完成 4已取消 5退款中、createTime、payTime、shipTime、finishTime。用 Room 還是直接 SQLite我建議 Room理由后面會講。但無論用哪種表關系必須提前定清楚。Product 和 BookInfo 是多對一多個賣家賣同一本書Order 和 Product 是一對一一個商品只能屬于一個訂單Order 和 User 是多對一。這些關系定清楚了寫 DAO 的時候基本是機械工作。2. 技術選型的取舍為什么我選 MVVM Retrofit Glide Room安卓開發的技術棧選擇很多但對于“二手圖書交易平臺”這個體量的項目我的建議是“主流穩定優先不做實驗性嘗試”。下面把每項選型的原因和替代方案講清楚。2.1 架構模式MVVM 比 MVC 更適合這個項目MVC 在 Activity 里堆邏輯一旦頁面復雜起來Activity 會膨脹到上千行。二手圖書的詳情頁什么都有——圖片輪播、品相標簽、賣家信息、留言列表、底部操作欄加上網絡請求的狀態管理加載中/成功/失敗/空數據如果用 MVC代碼會非常難維護。MVVM 的核心是 ViewModel LiveData或 StateFlowActivity 只負責渲染和事件分發業務邏輯全部下沉到 ViewModel數據變化通過觀察者模式通知 UI。我用的組合是ViewModel持有頁面狀態處理用戶交互事件。LiveDataUI 感知的生命周期組件避免內存泄漏。Repository 倉庫層統一管理數據來源網絡 or 本地ViewModel 只面向 Repository 接口。在這個項目里我寫了 ProductRepository、OrderRepository、UserRepository 三個倉庫類每個倉庫負責對應模塊的數據獲取和緩存策略。例如 ProductRepository 的getProductList(categoryId, page)方法先從網絡獲取第一頁數據同時緩存到本地 Room下次打開 App 如果網絡不通就加載緩存——這個機制在弱網環境下體驗提升非常明顯。2.2 網絡層Retrofit2 OkHttp 的套路化配置Retrofit 是安卓網絡請求的事實標準沒有太多懸念。但有幾個配置細節值得注意第一統一添加公共參數。比如 userId、deviceId、appVersion用 OkHttp 的 Interceptor 實現在請求頭里自動注入不用每個接口都手動傳。class CommonParamsInterceptor : Interceptor { override fun intercept(chain: Interceptor.Chain): Response { val originalRequest chain.request() val newRequest originalRequest.newBuilder() .header(Content-Type, application/json) .header(deviceId, DeviceUtils.getDeviceId()) .build() return chain.proceed(newRequest) } }第二統一處理錯誤碼。后端接口通常會返回類似{ code: 0, message: success, data: {...} }的結構。我在 ApiResponse 泛型里封裝了 code 和 message在 Repository 層統一判斷 code 是否為 0非 0 直接拋業務異常UI 層只需要關心成功與否不需要每個頁面重復判斷。第三超時時間設長一點。二手圖書的詳情頁會加載多張實拍圖弱網下 3 秒超時很容易失敗。我把連接超時設為 10 秒讀取超時設為 15 秒寫入超時 15 秒。實測穩定很多。2.3 圖片加載Glide 4.x 的緩存策略要調二手書交易平臺的特殊性在于圖片量大、且很多是用戶手機里的實拍圖分辨率參差不齊。Glide 依然是首選但有三點必須配置好第一自定義 OkHttp 網絡模塊。Glide 默認使用 HttpURLConnection但項目的網絡層是 OkHttp統一用 OkHttp 可以共享連接池和攔截器避免重復握手。通過AppGlideModule實現GlideModule class MyAppGlideModule : AppGlideModule() { override fun registerComponents(context: Context, glide: Glide, registry: Registry) { registry.replace(GlideUrl::class.java, InputStream::class.java, OkHttpUrlLoader.Factory()) } }第二磁盤緩存策略設置為 DATA 和 RESOURCE 都緩存。對于多次展示的商品封面圖緩存原始圖和裁剪圖都能顯著加快二次加載速度。第三縮略圖加載。詳情頁的輪播圖加載大圖時先用thumbnail(0.1f)加載低分辨率縮略圖占位再加載高清圖。視覺上體驗會好很多尤其在高清圖加載慢時不會出現空白。2.4 本地存儲Room 解決了 SQLite 的樣板代碼問題如果不做本地緩存SQLite 手寫 SQLiteOpenHelper 也能跑通。但項目里需要緩存商品列表、搜索歷史、用戶信息手寫 Cursor 轉實體類實在痛苦。Room 的編譯期 SQL 校驗能提前發現 SQL 錯誤配合 Flow 做響應式查詢非常舒服。建議建三個 EntityBookInfoEntity、ProductEntity、UserEntity。DAO 層用掛起函數 Flow例如Dao interface ProductDao { Query(SELECT * FROM product WHERE categoryId :categoryId ORDER BY createTime DESC LIMIT :pageSize OFFSET :offset) fun getProductsByCategory(categoryId: Int, pageSize: Int, offset: Int): FlowListProductEntity Insert(onConflict OnConflictStrategy.REPLACE) suspend fun insertProducts(products: ListProductEntity) }使用 Flow 的好處是當緩存表更新時UI 會自動收到新數據天然實現了“網絡刷新后 UI 同步”。3. 核心功能落地的關鍵細節狀態機、圖片上傳、搜索與訂單業務模型清楚了技術棧選好了下面講幾個最容易寫出 bug 的地方。這些模塊寫好了項目質量會明顯上一個臺階。3.1 商品狀態機設計別再到處寫 if-else 了二手商品在生命周期中會有多次狀態變化草稿 - 審核中 - 在售 - 已售或下架/刪除。一開始我是在 Product 實體里直接加一個 status 字段每個頁面判斷 status 的值來決定顯示什么按鈕。結果訂單頁要判斷、詳情頁要判斷、個人中心“我發布的”要判斷邏輯散落各處改一個狀態牽扯一大片。后來我重構為狀態機模式把狀態流轉集中在一個類里管理每個狀態定義允許的事件和對應的目標狀態。例如enum class ProductStatus(val value: Int) { DRAFT(0), REVIEWING(1), ON_SALE(2), SOLD(3), OFF_SHELF(4); fun canTransitTo(target: ProductStatus): Boolean { return when (this) { DRAFT - target REVIEWING || target OFF_SHELF REVIEWING - target ON_SALE || target OFF_SHELF ON_SALE - target SOLD || target OFF_SHELF SOLD - false OFF_SHELF - target ON_SALE || target REVIEWING } } }在發布商品時表單校驗通過后調用productRepository.changeStatus(productId, ProductStatus.ON_SALE)Repository 內部先檢查當前狀態和下一狀態是否合法不合法直接拋異常。這樣就把“用戶點按鈕 - 狀態變更”的合法性收斂到了一處不會出現“已售出的商品還能下架”這種詭異情況。3.2 圖片上傳壓縮、多圖、進度一個都不能少商品發布的圖片上傳模塊看起來簡單實際上有很多隱藏要求。用戶從相冊選 9 張圖每張可能 5-10MB直接傳到服務器不僅慢還容易失敗。我的處理方案是三段式選圖后立即壓縮使用Luban庫現在可以自己寫或用魯班算法將圖片壓縮到最長邊不超過 1280px、質量 80%這樣單張通常能壓到 300KB 以內。上傳前顯示進度用一個WorkManager或后臺線程池逐個上傳每上傳一張更新 UI 的進度條。這里建議用 OkHttp 的RequestBody重寫監聽上傳字節數。上傳完成后返回 URL 列表把返回的 URL 列表按順序保存到 Product 的coverImages字段前端展示時按此順序渲染輪播圖。多圖上傳的并發策略也很重要。我建議串行上傳第一張傳完再傳第二張。雖然比并發慢但失敗重試邏輯簡單且不會占滿帶寬導致列表頁圖片加載變慢。3.3 搜索基于關鍵詞 分類 排序的聯合查詢二手圖書的搜索和普通商品搜索不同用戶往往會帶上“考研”“計算機”“小說”這種關鍵詞同時希望按價格、品相、發布時間排序。數據庫查詢可以這樣設計Query( SELECT * FROM product INNER JOIN bookInfo ON product.bookId bookInfo.bookId WHERE (:keyword IS NULL OR bookInfo.title LIKE % || :keyword || % OR bookInfo.author LIKE % || :keyword || % OR bookInfo.isbn LIKE % || :keyword || %) AND (:categoryId IS NULL OR bookInfo.categoryId :categoryId) AND (:minPrice IS NULL OR product.price :minPrice) AND (:maxPrice IS NULL OR product.price :maxPrice) ORDER BY CASE WHEN :sortType 1 THEN product.price END ASC, CASE WHEN :sortType 2 THEN product.price END DESC, CASE WHEN :sortType 3 THEN product.createTime END DESC ) fun searchProducts( keyword: String?, categoryId: Int?, minPrice: Double?, maxPrice: Double?, sortType: Int ): FlowListProductEntity注意 SQL 中用CASE WHEN實現動態排序避免拼接字符串帶來的 SQL 注入風險。如果項目接的是服務端搜索接口那客戶端只需要傳參數但本地緩存搜索是離線模式的基礎能力。搜索的歷史記錄也建議用 Room 存一張 SearchHistory 表在搜索頁用瀑布流標簽形式展示最近 10 條點擊歷史標簽直接搜索體驗非常順手。3.4 訂單流程防重復下單和并發扣庫存訂單模塊是交易平臺最緊張的地方。兩個高發 bug用戶連點兩次“立即購買”創建了兩筆訂單同一個商品被兩個用戶同時下單但庫存只有一本。防重復下單的解決方式下單接口設置一個訂單防重 Token。用戶在點擊購買時客戶端先生成一個唯一的 requestIdUUID提交訂單時帶上這個 requestId服務端用 Redis 或數據庫唯一索引做冪等。但純安卓本地項目沒有服務端怎么辦我當時的方案是在本地訂單表給requestId加唯一約束插入時用OnConflictStrategy.IGNORE沖突就提示“請勿重復提交”。并發搶單的問題比較麻煩。如果做的是帶后端的完整項目建議用數據庫樂觀鎖UPDATE product SET status 2 WHERE productId ? AND status 1如果影響行數為 1說明搶單成功為 0說明商品已被別人買走。客戶端這邊只需要在下單前檢查商品狀態下單后重新拉取詳情更新 UI。4. 真實開發中的踩坑記錄圖片 OOM、Fragment 重建、列表卡頓這一部分是我最想分享的。網上搜源碼往往只能看到功能怎樣實現但開發過程中那些“怎么會這樣”的問題才是真正消耗時間的地方。我把遇到過的三個典型問題完整復盤一遍。4.1 商品列表快速滑動導致的內存暴增從 80MB 到 200MB第一次用 RecyclerView 加載商品列表時我直接用 Glide 加載封面圖占位圖用了一個很大的本地 drawable加載完成后沒做任何處理。快速滑動 100 條數據內存瞬間從 80MB 飆到 200MB最后直接 OOM 崩潰。排查過程是這樣的先用 Android Studio 的 Memory Profiler 抓內存快照發現byte[]占據了大頭進一步定位到 Glide 的 BitmapPool 一直在增長。原因有兩個一是每張原圖是 4000x3000 像素的實拍圖而列表 item 只需要 400x400 pxGlide 默認加載的是原始尺寸除非顯式指定override()二是占位圖是一張 1MB 的大圖導致每個 item 都持有一個大 Bitmap。修復方法很簡單Glide.with(itemView.context) .load(product.coverImages[0]) .override(480, 480) // 按列表 item 實際尺寸指定 .format(DecodeFormat.PREFER_RGB_565) // 不透明圖片用 RGB_565 省一半內存 .placeholder(R.drawable.ic_book_placeholder) .error(R.drawable.ic_book_error) .into(ivCover)另外把占位圖換成矢量 Drawable 或小尺寸 PNG幾百 KB 級別就夠。修復后快速滑動內存穩定在 100MB 內。這個問題的本質是“移動端加載圖片必須按需加載”原圖只應該在詳情頁做大圖展示時才加載。4.2 Fragment 重建導致的“頁面狀態丟失”項目里商品首頁、分類頁、我的頁面都用 Fragment BottomNavigationView 實現。一開始我直接在 Activity 的onCreate里 add 三個 Fragment沒有處理配置變更比如屏幕旋轉時的狀態保存。結果一轉屏Fragment 重建了ViewModel 雖然還在但 RecyclerView 的滾動位置、選中的 Tab、搜索頁輸入框的文字全部丟失。后來我引入了 Navigation Component 來管理 Fragment并配合 ViewModel 持有界面狀態。具體做法每個頁面的數據加載狀態和列表數據放到 ViewModel 的 LiveData / StateFlow 中。頁面上的純 UI 狀態比如滾動位置、Tab 選中項在onSaveInstanceState中保存到 Bundle。Fragment 重建后先從 ViewModel 恢復數據再從 Bundle 恢復 UI 狀態。這里特別強調一種容易忽略的場景從詳情頁返回列表頁列表頁的 Fragment 被系統回收后重建如果列表數據沒有緩存用戶看到的是空白頁。我當時的解決方案是在 Repository 層加了內存緩存ConcurrentHashMap列表數據加載一次后緩存重建頁面時直接從緩存恢復同時后臺刷新。4.3 評論/留言列表的嵌套滾動卡頓商品詳情的留言區是嵌套在 ScrollView 里的 RecyclerView。這樣做有幾個天然問題嵌套滾動事件沖突、滑動卡頓、RecyclerView 復用作廢。一開始怎么調都卡后來干脆放棄嵌套改用單一 RecyclerView 多類型 Item的方案。詳情頁頂部信息圖片輪播、標題、價格、品相描述作為 Header Item下面是留言列表 Item。這樣整個頁面只有一個滾動容器滑動流暢且復用正常。如果你只是臨時展示少量留言可以用NestedScrollView包 RecyclerView 并且設置android:nestedScrollingEnabledfalse讓 RecyclerView 不攔截滑動事件。但數據量超過 20 條后建議還是用多類型 Item 方案我實測差距非常明顯。5. 性能優化與交付從“能跑”到“好用”的差距項目功能做完只是第一步。真正讓人感覺“這個 App 質量不錯”的往往是那些看不見的優化。這一節我不講大道理只講在這個項目里親自落地過的優化項。5.1 啟動速度優化冷啟動從 2.3 秒壓到 1.2 秒冷啟動時間受 Application 初始化影響很大。我一開始在 Application 的onCreate里初始化了 Glide、LeakCanary、極光推送、網絡庫等一堆東西導致啟動時阻塞嚴重。現在的做法是分階段初始化必須在 Application 中同步初始化網絡庫、數據庫實例。因為這些是頁面啟動后立刻要用到的。可以放到首個頁面加載之后再初始化圖片加載庫可以延遲到頁面真正加載圖片時初始化、統計 SDK、推送 SDK 用異步線程初始化。具體實現可以用IdleHandler或WorkManager的initialize異步執行。我實測將 LeakCanary 和推送 SDK 放到主頁面onResume之后再初始化冷啟動時間從 2.3 秒降到 1.2 秒效果非常明顯。5.2 APK 體積控制從 45MB 瘦身到 28MB二手圖書項目的 APK 體積主要被三塊占據圖片資源、第三方庫、多架構 so 文件。我做過的有效瘦身手段開啟資源混淆android.enableResourceOptimizationstrue在 gradle.properties 中配合shrinkResources移除無用資源。移除多余 ABI如果只發布國內安卓市場abiFilters只保留arm64-v8a和armeabi-v7a去掉x86和x86_64體積瞬間減少很多。當然如果要在模擬器上測試需要保留 x86。圖片資源 WebP 化將啟動圖、默認頭像、占位圖全部轉換為 WebP 格式通常能比 PNG 再小 30%-50%。動態特性模塊如果項目足夠大可以把留言模塊、客服模塊做成 Dynamic Feature用戶按需下載。但對這個體量的項目這一步不是必須的。5.3 內存泄漏的排查工具鏈越是這種設計到大量圖片和網絡請求的 App越容易在退出后殘留內存泄漏。我每次開發到中后期都會用 LeakCanary 做一輪全量檢測。它檢測出的典型泄漏點有兩個Activity 被靜態變量持有比如單例里保存了 Activity 引用。我遇到過在 UserManager 里用靜態變量保存了當前用戶信息里面有 Bitmap 頭像間接持有了 Activity Context導致整個頁面無法回收。Handler / 回調未解綁。頁面銷毀后異步任務回調還在操作 View。修復方式所有跨頁面共享的 Context 一律使用getApplicationContext()Activity 相關的引用隨用隨取、用完即置空所有訂閱在onDestroy中取消。另外我做了一輪Memory Profiler 的 Heap Dump 分析發現商品列表頁退出后Glide 的緩存仍然占著 30MB 內存。這是正常的因為 Glide 有 LRU 緩存策略。但如果擔心緩存壓力可以在低內存時onTrimMemory回調中調用glide.clearMemory()和glide.clearDiskCache()。6. 打包與交付Zip 里應該有什么才能算一個完整的安卓項目到了項目交付和二次開發階段很多只發一個 .zip 壓縮包的朋友可能忽略了打包結構的完整性。一個合格的“二手圖書交易平臺 安卓端.zip”除了源碼應該包含讓接手者能立刻跑起來的一切。6.1 Gradle 配置里的坑如果你拿到手的 zip 里帶 local.properties里面寫著本機的 SDK 路徑那是無用的甚至可能導致別人打開工程時報錯。正確的做法是不提交 local.properties讓 Android Studio 自動生成。build.gradle里的compileSdk、targetSdk、minSdk要寫清楚。我用的是compileSdk 34,targetSdk 34,minSdk 24。注意targetSdk 34或更高版本會默認啟用分區存儲所以涉及圖片上傳的時候需要處理READ_MEDIA_IMAGES權限和ActivityResultContracts.PickVisualMedia這類新 API不能用老的READ_EXTERNAL_STORAGE。依賴庫的版本統一放到versions.gradle或ext中管理避免不同模塊依賴沖突。6.2 二次開發最需要看的三個文件如果這份 zip 是你要學習的源碼拿到手建議按這個順序閱讀文件/目錄作用app/src/main/java/.../di/或AppContainer.kt依賴注入入口看清單例和對象創建順序理解數據流。app/src/main/java/.../repository/Repository 層所有數據獲取邏輯在這里能看出數據來自網絡還是本地緩存。app/src/main/java/.../ui/按模塊劃分的包頁面和 ViewModel重點看商品列表和訂單流程的狀態管理。有了這三個文件的結構認知即使沒有完整文檔也能快速定位改動位置。6.3 多渠道打包和上架的注意事項如果你打算把這套代碼上架到應用市場有幾點得提前處理簽名文件.jks 簽名文件一定不能提交到 zip 里但要在 README 里說明需要自己生成。上架后簽名丟失是無法找回的所以項目初期就應該建立簽名備份機制。渠道包productFlavors配置不同渠道的applicationId后綴和渠道號騰訊樂固、360、應用寶等平臺需要識別渠道信息。可以用manifestPlaceholders注入渠道號。隱私合規如果集成了友盟統計、極光推送等 SDK在 targetSdk 34 下上架時隱私政策彈窗必須在其初始化之前展示并征得同意。7. 寫在最后做交易類項目的一點個人體會這個項目做完之后我最大的體會是交易類 App 的重點不是炫技而是把狀態管理和異常流程處理干凈。圖片加載、列表流暢度這些都是常規操作真正體現功底的是用戶在弱網下點下單、連續點兩次購買、商品中途被下架、支付成功但回調丟失這些場景下App 能不能給出合理的反饋。如果你正在做這份工程的二次開發我給三個具體建議第一優先打通一條完整的交易鏈路登錄 - 搜索 - 詳情 - 下單 - 支付 - 查看訂單。這條路走通項目的主干就成了其他功能都是枝葉。第二在列表頁和詳情頁之間傳遞數據時不要用 Internt 傳大對象。傳 productId 或 bookId 就夠詳情頁根據 ID 去倉庫重新讀取最新數據。因為列表頁的數據可能已經過期詳情頁顯示的價格、庫存必須是最新狀態。第三保持簡單不要過度設計。很多朋友一上來就用 Dagger Hilt、Paging 3、DataStore 替換所有組件結果排錯成本急劇上升。這些庫本身沒錯但在一個以二手圖書交易為核心的項目里ViewModel Repository LiveData Retrofit Glide 這個組合已經足夠穩定可靠。先跑通業務再考慮架構升級。最后再分享一件小事項目發布前我做了三輪真機測試最值錢的一輪是讓一個完全不懂 app 的同學上手操作看她會不會在發布商品的表單頁卡住、會不會困惑按鈕的位置。她反饋“上傳九張圖太麻煩”于是我把必填圖片從九張降到了三張并增加“使用示例圖”的快捷入口。這個改動帶來的好評率提升比任何代碼優化都明顯。做安卓開發始終要把自己當成最挑剔的用戶。本文還有配套的精品資源點擊獲取