簡介這是一套2023年發(fā)布的雙端相冊與通訊錄獲取系統(tǒng)源碼覆蓋安卓與iOS端面向具備PHP和移動(dòng)端開發(fā)基礎(chǔ)的工程師用于快速搭建可運(yùn)行的相冊與通訊錄獲取管理平臺(tái)。源碼包共含2000個(gè)文件壓縮包大小約51.06MB主要文件構(gòu)成包括1589個(gè)PHP文件承擔(dān)后端接口與業(yè)務(wù)邏輯74個(gè)CSS與57個(gè)JS渲染后臺(tái)管理界面510個(gè)PNG與41個(gè)JPG提供頁面UI素材同時(shí)附有APK與IPA安裝包可直接安裝體驗(yàn)。部署說明隨包提供明確Apache 2.4.53、MySQL 5.6、PHP 5.6運(yùn)行環(huán)境修改app/database.php完成數(shù)據(jù)庫連接、運(yùn)行目錄指向public、開啟TP偽靜態(tài)并關(guān)閉跨站后即可搭建服務(wù)端后臺(tái)管理入口及默認(rèn)賬號(hào)admin/123456均已標(biāo)明安卓端APK還支持反編譯后替換服務(wù)器IP重新打包便于實(shí)際聯(lián)調(diào)。目前已有4618人學(xué)習(xí)下載適合需要完整掌握雙端獲取類系統(tǒng)部署流程或在此基礎(chǔ)上進(jìn)行二次開發(fā)的工程師參考。1. 雙端相冊通訊錄系統(tǒng)它解決的不是讀取而是交付這套2023雙端完美獲取相冊通訊錄系統(tǒng)源碼解決的是移動(dòng)端開發(fā)里最容易被低估的一塊如何把系統(tǒng)相冊和通訊錄高效、合規(guī)、可用地交到業(yè)務(wù)層手里。做過會(huì)員注冊、工單系統(tǒng)、私域運(yùn)營工具的人都知道用戶愿意一鍵授權(quán)讀取本機(jī)通訊錄比手動(dòng)輸入體驗(yàn)好太多但雙端權(quán)限模型差異、Android 13 的細(xì)粒度媒體權(quán)限、iOS 相冊的“僅添加照片”模式隨便一個(gè)適配不到位就是閃退或者返回空數(shù)據(jù)。這套源碼的價(jià)值在于它把兩端讀取鏈路徹底打通適合接手后直接內(nèi)嵌到自己 App 里的開發(fā)者也適合想跑通完整權(quán)限申請、數(shù)據(jù)遍歷、批量導(dǎo)出流程的移動(dòng)端新手。它不新奇但確實(shí)能把雙端讀取的坑提前幫你踩完。2. 架構(gòu)設(shè)計(jì)一套數(shù)據(jù)規(guī)范加兩個(gè)原生適配殼2.1 雙端共用的讀取鏈路模型整個(gè)系統(tǒng)的核心不是“怎么讀”而是“讀完給誰”。源碼里的調(diào)用鏈被抽象成了三層權(quán)限申請層、數(shù)據(jù)讀取層、結(jié)果序列化層。權(quán)限申請層負(fù)責(zé)按系統(tǒng)版本區(qū)分權(quán)限請求方式數(shù)據(jù)讀取層屏蔽了 Android 的 Cursor 與 iOS 的 CNContact/PHAsset 差異結(jié)果序列化層統(tǒng)一輸出成 JSON 結(jié)構(gòu)業(yè)務(wù)層只需要處理一個(gè) List 類型。業(yè)務(wù)層 → 統(tǒng)一接口getContacts() / getAlbums() → 權(quán)限申請器PermissionRequestor → 平臺(tái)讀取器AndroidContactsContract / MediaStoreiOSContacts / PhotoKit → 結(jié)果封裝JSON / Model這套設(shè)計(jì)有一個(gè)明顯好處新增一個(gè)業(yè)務(wù)場景比如只需要讀取號(hào)碼不需要姓名時(shí)不用動(dòng)讀取器只改結(jié)果封裝層就行。在二次開發(fā)里你基本只需要盯住序列化層和權(quán)限申請層大部分坑也集中在這兩層。2.2 工程目錄結(jié)構(gòu)速覽源碼按雙端拆成兩個(gè)獨(dú)立工程但共享一份接口文檔和數(shù)據(jù)模型約定。Android 側(cè)采用 Kotlin MVVMiOS 側(cè)采用 Swift UIKit沒有引入跨平臺(tái)框架主要原因是相冊通訊錄這類系統(tǒng)級(jí)能力原生 API 最穩(wěn)踩坑最少。├── android/ │ ├── app/src/main/java/com/xxx/ │ │ ├── permission/ # 權(quán)限申請與回調(diào) │ │ ├── reader/ # 通訊錄、相冊讀取器 │ │ ├── model/ # 統(tǒng)一數(shù)據(jù)模型 │ │ └── serialization/ # JSON 序列化與壓縮 │ └── app/src/main/AndroidManifest.xml ├── ios/ │ ├── PermissionManager/ # 權(quán)限狀態(tài)機(jī) │ ├── Readers/ # ContactReader / PhotoReader │ ├── Models/ # 數(shù)據(jù)模型 │ └── Utils/ # 圖片壓縮、批量導(dǎo)出 └── docs/ ├── 雙端接口約定.md └── 權(quán)限適配清單.md2.3 統(tǒng)一返回的數(shù)據(jù)模型無論哪一端最終返回給業(yè)務(wù)層的數(shù)據(jù)字段是一致的。通訊錄字段為 name、phone、email、organization、note相冊字段為 assetId、uri、width、height、duration、dateTaken、size。這么設(shè)計(jì)的好處是前端和接口對接方只看一套字段規(guī)范不用關(guān)心數(shù)據(jù)來源是 Android 還是 iOS。源碼里用了一個(gè) Contract 常量類來維護(hù)字段名避免硬編碼字符串散落各處。{ code: 0, data: [ { name: 張三, phone: 138****1234, email: , organization: 某公司, note: } ], message: success }這段 JSON 是所有讀取結(jié)果的最終出口。code 為 0 代表成功非 0 是權(quán)限拒絕或讀取異常編號(hào)。業(yè)務(wù)層拿到這個(gè)結(jié)構(gòu)后做列表展示或者批量上傳都很省事。3. 通訊錄模塊拆解從權(quán)限申請到批量導(dǎo)出的完整鏈路3.1 Android 端通訊錄讀取與權(quán)限適配Android 端讀取通訊錄的核心類 ContactsContract。源碼里在 MainActivity 啟動(dòng)時(shí)先走權(quán)限流程然后執(zhí)行查詢。凡是在 Android 6.0 以上運(yùn)行的系統(tǒng)都需要?jiǎng)討B(tài)申請 READ_CONTACTS 權(quán)限這一塊如果不做運(yùn)行時(shí)判斷直接去查通訊錄會(huì)立刻拋 SecurityException。// PermissionManager.kt class PermissionManager(private val activity: Activity) { fun requestContacts(callback: (Boolean) - Unit) { if (Build.VERSION.SDK_INT Build.VERSION_CODES.M) { val permission Manifest.permission.READ_CONTACTS if (ContextCompat.checkSelfPermission(activity, permission) ! PackageManager.PERMISSION_GRANTED) { ActivityCompat.requestPermissions( activity, arrayOf(permission), REQUEST_CONTACTS_CODE ) } else { callback(true) } } else { callback(true) } } }這段代碼做了兩件事檢查當(dāng)前系統(tǒng)是否大于等于 Android 6.0再檢查權(quán)限是否已授予。低于 6.0 的系統(tǒng)在安裝時(shí)授權(quán)不需要?jiǎng)討B(tài)申請所以直接回調(diào)成功?；卣{(diào)邏輯需要在 Activity 的 onRequestPermissionsResult 里補(bǔ)上源碼里用了一個(gè)接口回調(diào)的方式把結(jié)果拋到上層。拿到權(quán)限之后真正的查詢邏輯在 ContactReader 里。它通過 ContentResolver 查詢通訊錄的 Phone.CONTENT_URI遍歷 Cursor 取出字段。這里有個(gè)常見的性能坑通訊錄一旦上千條主線程直接查詢會(huì)卡界面源碼里的做法是放到協(xié)程的 IO 線程執(zhí)行。// ContactReader.kt suspend fun readContacts(context: Context): ListContactModel withContext(Dispatchers.IO) { val list mutableListOfContactModel() val resolver context.contentResolver val uri ContactsContract.CommonDataKinds.Phone.CONTENT_URI val projection arrayOf( ContactsContract.CommonDataKinds.Phone.DISPLAY_NAME, ContactsContract.CommonDataKinds.Phone.NUMBER, ContactsContract.CommonDataKinds.Phone.EMAIL_ADDRESS, ContactsContract.CommonDataKinds.Phone.COMPANY, ContactsContract.CommonDataKinds.Phone.NOTES ) resolver.query(uri, projection, null, null, null)?.use { cursor - val nameIndex cursor.getColumnIndex(projection[0]) val numberIndex cursor.getColumnIndex(projection[1]) val emailIndex cursor.getColumnIndex(projection[2]) val companyIndex cursor.getColumnIndex(projection[3]) val noteIndex cursor.getColumnIndex(projection[4]) while (cursor.moveToNext()) { val name cursor.getString(nameIndex) ?: val phone cursor.getString(numberIndex) ?: val email cursor.getString(emailIndex) ?: val company cursor.getString(companyIndex) ?: val note cursor.getString(noteIndex) ?: list.add(ContactModel(name, phone, email, company, note)) } } list }參數(shù)說明projection 數(shù)組決定查詢哪些列查詢的字段越多耗時(shí)越長如果業(yè)務(wù)只需要號(hào)碼建議只保留 NUMBER 和 DISPLAY_NAME。cursor.use{} 是 Kotlin 擴(kuò)展函數(shù)能保證 Cursor 最終被關(guān)閉避免內(nèi)存泄漏。整個(gè)函數(shù)被 withContext(Dispatchers.IO) 包裹讀取大量聯(lián)系人時(shí)不會(huì)阻塞 UI 線程。3.2 iOS 端通訊錄讀取與權(quán)限分級(jí)iOS 端使用的是 Contacts 框架。和 Android 不同iOS 的通訊錄權(quán)限只區(qū)分“允許”和“拒絕”沒有 Android 那套一次性授權(quán)的概念一旦用戶拒絕除非去系統(tǒng)設(shè)置里手動(dòng)打開否則 App 里無法再次彈窗。源碼里因此在第一次請求前做了充分準(zhǔn)備避免用戶誤拒后無法再引導(dǎo)。// ContactReader.swift import Contacts class ContactReader: NSObject { func fetchContacts(completion: escaping ([ContactModel]) - Void) { let store CNContactStore() switch CNContactStore.authorizationStatus(for: .contacts) { case .notDetermined: store.requestAccess(for: .contacts) { granted, _ in if granted { let contacts self.fetchFromStore(store) DispatchQueue.main.async { completion(contacts) } } else { completion([]) } } case .authorized: let contacts self.fetchFromStore(store) DispatchQueue.main.async { completion(contacts) } default: completion([]) } } private func fetchFromStore(_ store: CNContactStore) - [ContactModel] { let keys [CNContactGivenNameKey, CNContactFamilyNameKey, CNContactPhoneNumbersKey, CNContactEmailAddressesKey, CNContactOrganizationNameKey] as [CNKeyDescriptor] let request CNContactFetchRequest(keysToFetch: keys) var result: [ContactModel] [] try? store.enumerateContacts(with: request) { contact, _ in let name contact.givenName contact.familyName let phone contact.phoneNumbers.first?.value.stringValue ?? let email contact.emailAddresses.first?.value as String? ?? let org contact.organizationName result.append(ContactModel(name: name, phone: phone, email: email, organization: org)) } return result } }邏輯說明先檢查授權(quán)狀態(tài)notDetermined 時(shí)才彈窗請求authorized 直接讀取其余狀態(tài)一律返回空數(shù)組。這套狀態(tài)機(jī)保證了 App 不會(huì)在權(quán)限被拒后反復(fù)彈窗也更符合 App Store 審核規(guī)范。fetchFromStore 里只請求了必要字段沒有把所有屬性全部拉下來iOS 端這個(gè)懶加載性能優(yōu)化很關(guān)鍵聯(lián)系人幾千條時(shí)差異明顯。3.3 批量導(dǎo)出與去重策略通訊錄最容易出現(xiàn)臟數(shù)據(jù)——同一個(gè)聯(lián)系人有多個(gè)號(hào)碼或者重復(fù)錄入兩遍。源碼里在導(dǎo)出前做了一次規(guī)則去重以“姓名 第一個(gè)手機(jī)號(hào)”作為唯一鍵后續(xù)重復(fù)數(shù)據(jù)直接丟棄。fun deduplicate(list: ListContactModel): ListContactModel { val seen HashSetString() return list.filter { contact - val key ${contact.name}_${contact.phone} if (seen.contains(key)) { false } else { seen.add(key) true } } }這個(gè)去重邏輯很樸素字符串拼接做 key效果在絕大多數(shù)場景下夠用。如果遇到同名同號(hào)但不同公司的情況可以再把 organization 拼進(jìn)去但那樣做會(huì)把更多樣本判定為不同聯(lián)系人。實(shí)際使用中建議保持簡單畢竟通訊錄本身就是用戶自己維護(hù)的數(shù)據(jù)過多干預(yù)反而會(huì)引發(fā)投訴。4. 相冊模塊拆解MediaStore 與 PhotoKit 的增量讀取4.1 Android 13 相冊權(quán)限適配Android 相冊讀取是這套源碼里最值得看的適配點(diǎn)。Android 13API 33把 READ_EXTERNAL_STORAGE 拆成了 READ_MEDIA_IMAGES、READ_MEDIA_VIDEO 和 READ_MEDIA_AUDIO如果項(xiàng)目 targetSdk 升到 33 之后還在用舊權(quán)限系統(tǒng)會(huì)直接不授予。源碼里做了一個(gè)兼容寫法API 33 以上申請新權(quán)限以下申請舊權(quán)限。// AndroidManifest.xml uses-permission android:nameandroid.permission.READ_EXTERNAL_STORAGE android:maxSdkVersion32 / uses-permission android:nameandroid.permission.READ_MEDIA_IMAGES / uses-permission android:nameandroid.permission.READ_MEDIA_VIDEO /Manifest 里同時(shí)聲明兩個(gè)權(quán)限但給舊權(quán)限加了 maxSdkVersion32意思是 Android 12 及以下才需要。Android 13 的設(shè)備會(huì)自動(dòng)忽略舊權(quán)限聲明只認(rèn)新權(quán)限。這種寫法比代碼里動(dòng)態(tài)判斷后再申請更干凈系統(tǒng)層面就替你做了一次分流。讀取相冊本身用的是 MediaStore。源碼里做的是“增量讀取”也就是每次只取新增的圖片這個(gè)能力在系統(tǒng)相冊動(dòng)輒萬張圖片的情況下特別重要。判斷新增的字段是 DATE_ADDED記錄上一次讀取時(shí)間下次查詢時(shí)只查該時(shí)間之后的圖片。// PhotoReader.kt suspend fun readIncremental(context: Context, lastTime: Long): ListPhotoModel withContext(Dispatchers.IO) { val list mutableListOfPhotoModel() val uri MediaStore.Images.Media.EXTERNAL_CONTENT_URI val projection arrayOf( MediaStore.Images.Media._ID, MediaStore.Images.Media.DATA, MediaStore.Images.Media.WIDTH, MediaStore.Images.Media.HEIGHT, MediaStore.Images.Media.DATE_TAKEN, MediaStore.Images.Media.DATE_ADDED, MediaStore.Images.Media.SIZE ) val selection ${MediaStore.Images.Media.DATE_ADDED} ? val selectionArgs arrayOf(lastTime.toString()) resolver.query(uri, projection, selection, selectionArgs, null)?.use { cursor - // 遍歷 cursor 并組裝 PhotoModel } list }selection 和 selectionArgs 這個(gè)組合是防止 SQL 注入的標(biāo)準(zhǔn)姿勢源碼里沒有直接用字符串拼接 lastTime這點(diǎn)值得借鑒。首次使用可以傳 lastTime 0下次用最后一次讀取結(jié)果里的最大值傳入就能做到持續(xù)性增量同步。朋友圈備份、云相冊同步這類功能都可以基于這一段改造。4.2 iOS 端 PHPicker 與 PhotoKit 選擇iOS 讀相冊有兩種思路一種是直接用 PHPickerViewController這是 iOS 14 之后蘋果推薦的系統(tǒng)級(jí)選擇器不需要申請相冊權(quán)限隱私保護(hù)最好另一種是使用 PhotoKit 的 PHAsset 枚舉能拿到全量資源但必須觸發(fā)相冊權(quán)限彈窗。源碼里把兩種方式都實(shí)現(xiàn)了默認(rèn)走 PHPicker適合業(yè)務(wù)上只需要用戶選圖的場景也暴露了 PhotoKit 的全量讀取接口供后臺(tái)同步類功能使用。// PhotoPickerManager.swift import PhotosUI class PhotoPickerManager: NSObject, PHPickerViewControllerDelegate { func presentPicker(from viewController: UIViewController) { var config PHPickerConfiguration() config.filter .images config.selectionLimit 0 // 0 表示不限數(shù)量 let picker PHPickerViewController(configuration: config) picker.delegate self viewController.present(picker, animated: true) } func picker(_ picker: PHPickerViewController, didFinishPicking results: [PHPickerResult]) { picker.dismiss(animated: true) for result in results { result.itemProvider.loadObject(ofClass: UIImage.self) { image, _ in // 處理選中的圖片 } } } }PHPicker 的好處是你拿到的每一張圖片都經(jīng)過用戶明確勾選App 無法偷偷讀取整個(gè)相冊這在隱私合規(guī)審查里是加分項(xiàng)。selectionLimit 為 0 代表多選如果只想單選就改成 1。loadObject 是異步加載回調(diào)可能不在主線程做 UI 更新時(shí)記得切回主隊(duì)列。4.3 圖片壓縮與分頁加載相冊數(shù)據(jù)量大一次性把原圖路徑全部返回給業(yè)務(wù)層內(nèi)存直接爆掉。源碼里在讀取階段不做壓縮只返回 uri 和尺寸信息真正要顯示或上傳的時(shí)候才壓縮。壓縮參數(shù)據(jù)寫在個(gè) Constants 類里默認(rèn)限制最長邊為 1280 像素、質(zhì)量 85%這段邏輯在兩端各實(shí)現(xiàn)了一遍但參數(shù)完全一致。val MAX_EDGE 1280 val COMPRESS_QUALITY 85這段常量看起來不起眼實(shí)際上決定了上傳帶寬和縮略圖展示速度。如果想降低傳輸成本把 MAX_EDGE 改成 800圖片體積能減少一半以上如果做原圖備份就改成 4096 或者保存原始 DATA 路徑。壓縮算法在 Android 用 BitmapFactory MatrixiOS 用 UIGraphicsImageRenderer源碼里都有現(xiàn)成實(shí)現(xiàn)直接復(fù)用即可。5. 雙端適配避坑權(quán)限版本差異與數(shù)據(jù)查詢的六個(gè)常見問題5.1 小米和三星手機(jī)上通訊錄權(quán)限返回已授予但查詢結(jié)果一直為空現(xiàn)象同一套代碼在模擬器上能查到聯(lián)系人在部分國產(chǎn)手機(jī)上永遠(yuǎn)返回空列表權(quán)限明明已經(jīng)授予了。原因部分廠商系統(tǒng)里通訊錄權(quán)限拆成了“讀取聯(lián)系人”和“讀取通話記錄”兩個(gè)開關(guān)ContactsContract 查詢依賴的核心權(quán)限是 READ_CONTACTS但個(gè)別 ROM 會(huì)默認(rèn)關(guān)閉“讀取設(shè)備通話記錄”的子權(quán)限導(dǎo)致 query 拿到了一個(gè)空 Cursor。解決在權(quán)限申請成功后主動(dòng)做一次探針查詢例如查通訊錄的聯(lián)系人總數(shù)如果等于 0 但設(shè)置里授權(quán)是開著的就跳轉(zhuǎn)系統(tǒng)設(shè)置頁提示用戶檢查權(quán)限細(xì)分項(xiàng)。源碼里的 PermissionProbe 類專門干這件事血淚經(jīng)驗(yàn)是別完全信任 checkSelfPermission 的返回值。5.2 Android 13 上申請了 READ_MEDIA_IMAGES還在報(bào) SecurityException現(xiàn)象targetSdk 已升級(jí)到 33Manifest 里也加了新權(quán)限運(yùn)行時(shí)申請也提示成功但訪問 MediaStore 仍然拋權(quán)限異常。原因沒有給舊權(quán)限加 maxSdkVersion32。系統(tǒng)在高版本上看到 Manifest 同時(shí)存在新舊兩個(gè)權(quán)限聲明會(huì)采用更嚴(yán)格的解析策略此時(shí)只授予了新權(quán)限但代碼里某處還在用舊權(quán)限常量做校驗(yàn)。解決按 4.1 節(jié)的寫法在舊權(quán)限聲明上強(qiáng)制加 maxSdkVersion32。檢查全項(xiàng)目是否還有 READ_EXTERNAL_STORAGE 的引用尤其是第三方 SDK 的依賴?yán)锶绻暶髁诉@個(gè)權(quán)限也會(huì)干擾新權(quán)限授予。5.3 iOS 通訊錄權(quán)限被用戶拒絕一次后再也彈不出授權(quán)框現(xiàn)象第一次彈窗用戶點(diǎn)了“不允許”后續(xù) App 里怎么調(diào)用 requestAccess 都沒有彈窗直接返回 denied。原因iOS 的設(shè)計(jì)就是這樣權(quán)限狀態(tài)一旦變成 denied系統(tǒng)不會(huì)再向用戶彈出授權(quán)界面只能由用戶自己去“設(shè)置 隱私”里手動(dòng)開啟。解決在回調(diào)中檢測到 .denied 狀態(tài)時(shí)跳轉(zhuǎn) UIApplication.openSettingsURLString 打開系統(tǒng)設(shè)置頁并在界面文案里說明為什么要用通訊錄。源碼里封裝了一個(gè) goToSettings() 輔助方法。注意不要自己彈一個(gè)假的授權(quán)彈窗審核容易被拒。5.4 Cursor 未關(guān)閉導(dǎo)致的內(nèi)存泄漏與重復(fù)讀取現(xiàn)象通訊錄反復(fù)讀取后 App 內(nèi)存持續(xù)升高甚至出現(xiàn) native heap 溢出崩潰。原因Cursor 是一個(gè)持有底層數(shù)據(jù)庫資源的對象不用時(shí)必須 close。很多新手只寫了 query 沒寫 close系統(tǒng) GC 又不會(huì)立刻回收底層資源導(dǎo)致泄漏。解決統(tǒng)一用 Kotlin 的 use 擴(kuò)展函數(shù)包裹 Cursor 操作確保查詢結(jié)束自動(dòng)關(guān)閉。源碼里所有 query 都遵循這個(gè)模式C 端在線程切換上再注意一點(diǎn)就能徹底解決問題。5.5 iOS 模擬器上通訊錄讀取正常真機(jī)上偶發(fā) crash現(xiàn)象同一套代碼模擬器流暢跑完真機(jī)上偶發(fā)直接崩潰點(diǎn)開相冊圖片時(shí) CPU 暴增。原因真機(jī)的相冊圖片分辨率遠(yuǎn)高于模擬器加載原圖到 UIImage 會(huì)一次性占用幾百 MB 內(nèi)存觸發(fā) Jetsam 機(jī)制直接殺掉進(jìn)程。模擬器共享電腦內(nèi)存不容易爆掩蓋了問題。解決使用增量加載從 PHAsset 取圖時(shí)用 PHImageManager 的 requestImage 并指定 targetSize不要直接請求原始尺寸。源碼里把 targetSize 設(shè)為列表縮略圖需要的尺寸大約 600x600這樣既清晰又不會(huì)撐爆內(nèi)存。5.6 通訊錄號(hào)碼格式不統(tǒng)一有的帶 86 前綴有的帶空格和橫杠現(xiàn)象讀取回來的 phone 字段五花八門用戶在列表搜索時(shí)明明輸入對了一部分卻匹配不上。原因系統(tǒng)通訊錄本身沒有強(qiáng)制號(hào)碼格式化規(guī)則用戶在錄入時(shí)手輸了什么就存什么Android 返回的甚至可能是 SIP 協(xié)議開頭的內(nèi)容。解決在序列化層統(tǒng)一做一次號(hào)碼清洗去掉空格、橫杠、括號(hào)把 86 替換為空保留純數(shù)字和分機(jī) X 后綴。這個(gè)工作放在整條鏈路的最后一步業(yè)務(wù)層拿到的就是相對干凈的號(hào)碼。源碼里 CleanPhoneUtil 這段工具函數(shù)不復(fù)雜但價(jià)值很高。6. 二次開發(fā)把讀取能力改造成自己的通訊錄同步服務(wù)如果你拿這套源碼不是為了學(xué)習(xí)而是直接要落地到自己的產(chǎn)品里我的建議是先砍掉一半功能再接入。絕大多數(shù)業(yè)務(wù)場景只需要通訊錄的手機(jī)號(hào)字段不需要 email 和 organization相冊只需要縮略圖和上傳回調(diào)不需要原始數(shù)據(jù)流。第一步就是精簡數(shù)據(jù)模型把不需要的字段從 projection 里刪掉這不僅讓讀取更快也讓隱私合規(guī)的說明文檔更好寫。實(shí)際改造時(shí)我會(huì)按三步走。第一步換數(shù)據(jù)出口把序列化層從本地 List 改成網(wǎng)絡(luò)上報(bào)。原代碼已經(jīng)把結(jié)果封裝成 JSON你只需要寫一個(gè) Retrofit 或 Alamofire 的上報(bào)類把 JSON 體 POST 到你的服務(wù)端。注意加一個(gè)本地緩存隊(duì)列弱網(wǎng)環(huán)境下上報(bào)失敗后自動(dòng)重試避免用戶授權(quán)了數(shù)據(jù)卻傳不上去。fun submitContacts(contacts: ListContactModel) { val params JSONObject().apply { put(app_id, APP_ID) put(data, JSONArray(contacts.map { it.toJsonObject() })) } // 通過 OKHttp / URLSession 發(fā)送到服務(wù)端失敗則寫入本地隊(duì)列 }第二步是加一個(gè)同步狀態(tài)位。讀取成功后給每個(gè)聯(lián)系人記錄一個(gè) hash 值下次啟動(dòng)時(shí)先比對 hash 再?zèng)Q定是否上報(bào)。這一步在通訊錄類應(yīng)用里極其重要否則每次冷啟動(dòng)都上傳全量通訊錄服務(wù)端壓力大用戶流量也吃不消。第三步是驗(yàn)證。雙端項(xiàng)目最怕改了 Android 忘了 iOS我的習(xí)慣是維護(hù)一份參數(shù)對照表把兩端用到的權(quán)限常量、查詢字段、壓縮參數(shù)列在一張表里每次改完一邊就同步核對另一邊。這套源碼的 Contract 類已經(jīng)替你做了一大半遵守它的約定就不會(huì)出現(xiàn)兩端行為不一致的問題。這套源碼適合當(dāng)做一個(gè)基礎(chǔ)設(shè)施引擎來使用不要試圖理解每一行系統(tǒng) API 的原理先把業(yè)務(wù)跑起來。等出現(xiàn)性能和兼容性問題再回頭讀對應(yīng)模塊效率最高。從那以后我每次接手雙端項(xiàng)目都會(huì)強(qiáng)制先跑一遍兩端的權(quán)限場景矩陣把授予、拒絕、撤銷、僅使用期間允許這幾種狀態(tài)全部過一遍再確認(rèn)數(shù)據(jù)出口。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取