简介这是一份基于Java与Android Studio开发的保险理赔应用完整项目面向Android移动开发初学者、Java学习者以及保险科技领域的技术人员用于掌握理赔类App从界面设计到功能实现的全过程。项目覆盖用户登录注册、理赔表单填写、进度反馈等核心模块涉及XML布局构建、Intent与Activity跳转、SQLite/SharedPreferences数据存储、OkHttp网络请求以及Android 6.0动态权限适配等关键技能。压缩包共77个文件以XML布局和配置、Java源码、PNG图片资源为主另有Gradle构建脚本、Properties配置及README说明资源总大小约793KB目录结构简洁清晰。目前已有190人学习下载。借助该资料可获得完整的源码工程与界面资源既能对照学习保险理赔业务逻辑也可直接导入Android Studio二次开发适合课程设计、毕业项目或企业原型参考。 做保险理赔类App和做普通工具类App是两种完全不同的心态。我接这个项目前一直觉得理赔就是把表格搬到手机上填一填、传几张照片、点提交完事。后来真正跟理赔员跑了一次线下定损才知道一次理赔背后牵扯的流程有多长报案、查勘、定损、资料审核、理算、复核、打款任何一环缺材料都要回退用户看不到进度就会反复打电话催问。所以这个Insurance-Claims-App-for-Android说白了不是做表单而是做一条让用户和理赔系统都能看得到进度的数据通道。这篇文章我结合整个Android端的开发过程把业务拆解、材料上传、网络层设计、系统版本适配、数据安全这几个核心环节的系统性思考写出来。如果你正准备做一个类似的金融、保险或政务类Android应用或者已经在开发中遇到了FileProvider、文件存取、接口幂等这类问题这篇文章应该能帮你少走不少弯路。1. 先盘业务理赔App不是表单填完了事1.1 从线下理赔流程拆解出线上最小闭环我刚开始梳理需求时产品经理给了一堆功能在线报案、材料上传、进度查询、电子发票识别、定损金额预览、投诉建议、在线客服……如果照单全收这个项目半年都上不了线。所以我做的第一件事是把线下理赔全流程走了一遍画出角色和节点再对照线上App拆出最小闭环。一个标准车险理赔线下是这么走的用户出险后打电话报案调度员分配查勘员查勘员到场拍照、记录损失情况生成查勘报告用户拿着报告去维修或收集发票再提交理赔资料后台审核员核对保单、发票、驾驶证等信息确认无误后理算金额复核通过后打款。任何一个环节缺资料流程就打回重来。线上化之后Android端要承接的核心节点其实只有三个报案信息录入、理赔材料提交、进度与审核结果查看。其余查勘调度、理算这些属于后台系统App不需要参与。看清楚这条链路之后MVP的边界立刻清晰了我砍掉了在线客服、电子发票识别这类锦上添花的功能把资源全部砸在上传链路和状态流转上。事实证明这是对的第一版上线后用户反馈最多的功能就是材料上传和进度查询其他功能用到的频率非常低。1.2 功能优先级与MVP边界划在哪如果你的项目也面临功能过多的问题我建议按这个优先级排序第一梯队是用户登录、案件创建、材料上传、进度查询这是理赔业务的命脉没有这些App就是废的。第二梯队是消息推送、历史案件列表、个人中心这些能提升用户粘性但可以滞后一点。第三梯队才是AI识别、智能客服、电子签名这类增值功能应该全部放到二期。MVP边界划清楚之后开发节奏就非常快了。登录我们直接接手机号验证码没有做密码体系案件创建就是几个表单页加一个案件编号生成逻辑材料上传拆成单张拍照、批量选择、预览删除三个子模块。整个第一版从启动到能提交测试大概花了六周其中上传模块占了两周这我后面专门说。1.3 技术栈为什么选了原生Kotlin技术选型上我们没有犹豫就定了原生Kotlin而不是Flutter或React Native。原因很直接保险理赔涉及相机调用、文件存取、系统级权限、安全加密这些场景原生API最稳第三方框架封装的底层能力一旦遇到厂商适配问题排查成本远高于开发成本。另外金融类App上架审核时原生包更容易通过合规检查跨端框架有时候会被安全扫描标记出奇怪的依赖。当然纯原生UI开发效率确实比不过热重载的跨端方案所以我用Jetpack Compose把界面搭起来之后遇到复杂页面还是会用传统View体系兜底两者可以混用只要在gradle里配好依赖就行。实际体验下来核心页面用Compose写确实快但像图片九宫格这种交互复杂、需要精细控制焦点和滚动行为的组件还是老一套XMLRecyclerView更顺手。2. 材料上传是理赔命门FileProvider与本地图片存取的正确姿势2.1 一个content://路径把很多开发者卡住的真正原因理赔App里用户要传的东西无非是这几类事故现场照片、驾驶证行驶证照片、维修发票、银行账户信息。听起来很简单但实际开发中第一个拦路虎就是FileProvider。你可能在日志里见过类似content://com.baidu.searchbox.fileprovider/baiddpath/android/data/com.ba...这种路径第一反应是“这不是我的App的provider”对那是你测试手机里装的百度App注册的FileProvider跟你没关系但这恰好说明了一个问题Android系统里所有App的provider都是按authority区分注册的你自己的provider如果不小心把authority写成别人的或者两个库的manifest合并冲突了就会出现调用系统相机后拿不到图片Uri、直接崩溃的情况。我们用FileProvider不是为了别的是因为Android 7.0之后App之间传递file://类型的Uri会被系统直接抛出FileUriExposedException这是硬性限制。你要把用户选好的照片交给相机裁剪或者把图片Uri传给第三方图片压缩库处理都必须用content://的Uri并且通过provider的授权机制给对方临时读权限。这个机制听起来绕其实本质就是系统不允许你随便把文件路径暴露给别的App但允许你通过一个受控的provider把Uri临时授权出去。配置FileProvider的常规做法是在AndroidManifest里注册一个Provider节点然后单独维护一份file_paths.xml来声明哪些目录可以被共享访问。我踩过的一个坑是测试的时候把external-path的path写成了/storage/emulated/0/这种绝对路径在部分手机上直接访问不到正确做法是写.表示根目录或者具体到Pictures/claim/这样的细分目录。另外一定要记住file_paths.xml里的name属性只是标识不影响真实路径映射但路径部分千万不要配得过宽否则系统应用会收到你的整个存储权限。2.2 拍照、相册、文件三种取图路径的统一封装材料上传至少要兼容三种取图路径相机拍照、相册选取、文件管理器选取。三种路径的返回类型和数据特征都不一样相机返回的是你事先通过FileProvider创建的Uri相册返回的是系统媒体库的content Uri文件管理器返回的可能是content Uri也可能是DocumentFile的Uri。如果每个页面都写一套处理逻辑代码会变得非常难维护。我的做法是封装一个MediaPickerHelper类内部维护一套统一的PickResult数据结构包含原始Uri、拷贝后的本地缓存文件、MIME类型、文件大小这几个字段。所有页面拿到同一个类型的数据后续压缩、上传逻辑完全复用。核心思路是外部传入的Uri不管是什么来源先拷贝到App私有目录再处理避免直接操作外部存储导致权限问题。比如相册选择器返回的Uri在Android 11以上可以正常读取但Android 10及以下如果没申请存储权限就会读取失败统一拷贝到私有目录后这些差异全部抹平了。相机拍照这边有个细节从Android 11开始系统相机不能再通过MediaStore.ACTION_IMAGE_CAPTURE往外部公共目录写入图片必须在拍照前先创建好一个私有目录下的文件把FileProvider生成的Uri传给相机然后从onActivityResult里拿到这个Uri去读取。这不算什么新知识但是我在新版系统上实测如果不提前创建这个文件部分国产ROM的相机会直接返回取消连错误码都不给一个。2.3 图片压缩策略与上传进度的可续传设计理赔现场用户拍的照片动辄3MB到8MB不处理直接上传后台审核员打开图片要等好几秒而且用户流量也吃不消。我这边做了两层处理第一层是采样压缩利用BitmapFactory的inSampleSize按目标宽高比如1920px对图片做降采样第二层是用质量压缩把JPEG品质控制在85%实测同一张照片能从6MB降到600KB左右肉眼几乎看不出差别。上传进度这块建议不要只做个进度条动画要有真正的断点续传逻辑。保险理赔现场网络信号经常不稳定用户在地下停车场或事故路段可能传一半就断网了如果每次都从头传用户会很崩溃。我们的做法是后端接口支持分片上传前端先把文件切成2MB一片每传完一片记录下已完成的片索引全部传完后再调一个合并接口。如果中途失败重新拉起上传任务时直接从上次失败的片开始续传。这个方案成本不高但用户体感提升非常明显。3. 网络层设计理赔请求的防重复与抓包经验3.1 防重复提交是理赔场景的硬要求车辆出险理赔的提交操作有个很现实的问题用户在地下室或者信号不好的地方点了一次“提交理赔”按钮转圈圈好几秒没反应用户会本能地再点几下。如果后端没有做幂等处理同一个案件可能被创建出好几条理赔单后面的审核流程直接乱套。这种问题不能只靠后端加唯一索引解决前端也要配合。我们的做法是用户创建案件时客户端先生成一个UUID作为requestId后续所有跟这个案件相关的提交请求都带上同一个requestId后端依据这个ID做去重。前端在按钮点击后立即进入loading状态并置灰按钮同时网络层对相同requestId的请求做了拦截如果上一个请求还没返回直接丢弃新请求并提示“正在提交请勿重复操作”。// 提交理赔单时使用客户端生成的requestId做幂等 data class ClaimSubmitRequest( val claimId: String, val requestId: String, val materials: ListMaterialEntity, val bankAccount: String ) // 网络层拦截重复提交 if (pendingRequests.containsKey(requestId)) { // 提示用户正在提交中 return }这是我个人特别想强调的一点理赔类App的接口设计宁可多花一天时间跟后端对齐幂等协议也不要等到上线后被重复理赔单搞得焦头烂额。这个坑一旦踩了处理成本极高因为涉及财务和审核流程不是删一条数据库记录就能解决的。3.2 Fiddler抓包失败与证书校验的那些事开发阶段联调接口几乎人人都会用到抓包工具我自己常用Fiddler。但第一次抓理赔App的HTTPS请求时我一度以为Fiddler坏了——手机上的App能正常出数据Fiddler里却一片空白。后来排查发现这是因为App的OkHttp客户端做了证书校验默认不信任Fiddler的CA证书。解决方式有两种分别对应不同阶段。开发调试阶段可以在网络层的OkHttpClient里给CertificatePinner配置debug专用配置或者直接在Manifest的android:debuggabletrue模式下临时放行用户证书。正式环境则必须保留严格的证书校验防止中间人攻击。这里要特别提醒千万不要为了图省事在release包里去掉了证书校验金融类App一旦被中间人攻击用户隐私数据泄露就是大事。另外抓包的时候如果手机系统是Android 7.0以上很多App即使安装了用户证书默认也不会信任因为从Android 7.0开始App默认只信任系统CA证书。这时你需要在networkSecurityConfig里把debug模式单独配一份信任用户证书的配置release环境不放行。这个配置区分清楚了抓包才顺手。3.3 接口错误码设计把“理赔失败”变成可恢复的操作保险理赔的下游系统链路很长用户提交的材料可能因为照片模糊、发票信息不对、保单过期等各种原因被审核拒绝。如果App端把所有异常都弹一个“理赔失败”用户除了拨打客服电话没有任何办法客服那边压力会非常大。我们的做法是跟后端约定了一套结构化错误码体系。例如MATERIAL_BLURRY代表照片模糊INSURANCE_EXPIRED代表保单过期BANK_INFO_MISMATCH代表银行卡信息不一致。App端拦截到这些错误码后会跳转到对应的修正页面并提前把用户上一个已填写的信息带过去这样用户只需要重新拍张照片或者改一下卡号就能再次提交而不是从头开始填整个表单。这套错误码体系在开发期多花了大概三天时间但上线后客服的无效咨询量直接少了一半。我觉得这是整个项目中投入产出比最高的一次设计远远超过了某个具体动画或者某个花哨组件的价值。4. 系统版本与机型适配Android 11到14的坑4.1 Android 11的包可见性与网络权限变化Android 11API 30上线后系统引入了包可见性Package Visibility机制。简单说你的App默认情况下看不到设备上安装的其他应用只有在你声明了queries元素之后才能通过queryIntentActivities()等接口查找到特定包。这个机制对保险理赔App的一个重要影响是如果你要通过Intent拉起地图App导航到定损点或者拉起微信客服必须先声明对应的包名否则查询结果为空按钮点了没反应。我当时做一个“联系理赔员”的功能需要判断用户手机上装没装微信再决定是弹“微信联系”还是“电话联系”。由于没有在AndroidManifest里加queries声明在Android 11以上的设备上一直判断不到微信已经安装导致展示的入口不对。排查了半天才想到是包可见性问题加一行声明就解决了。还有一个小坑是Android 11对网络权限的默认行为变化如果App targetSdkVersion是30或以上默认情况下只有配了uses-permission android:nameandroid.permission.INTERNET /才能联网这个大多数App开发时已经加了。但如果你用了某个不常见的第三方库库的manifest没有自动合并INTERNET权限就可能出现release包无法联网、debug包却正常的诡异现象。遇到这个问题检查一下最终merged manifest是最快的。4.2 Android 14对根目录读取的限制Android 14API 34这一波改动里对我们影响最大的是对READ_MEDIA_VISUAL_USER_SELECTED等分区存储权限的进一步收紧以及系统对读取应用私有目录之外文件的限制变得更严格。实际业务中理赔App需要读取相册图片如果你用默认的ACTION_PICK或者Photo Picker基本没问题但如果你用了READ_EXTERNAL_STORAGE这类老权限在Android 14上会被直接拒绝。好消息是Google推出了系统的Photo Picker组件用户可以在不授予整个存储权限的情况下选择图片这对理赔这种对权限敏感的业务来说非常友好。我的建议是新开发的App相册选择一律用Photo Picker旧项目如果还用老的一套读取方式建议尽早迁过来否则在Android 14的机器上会有很多兼容性投诉。另外提一个跟存储相关的点Android 14上当你用FileProvider对外分享文件时如果对方App的targetSdk比较旧可能无法正确通过content://读取你分享的文件。这种问题不好通过代码层面兼容最佳策略是保证自己的FileProvider路径配置正确以及在文档里明确要求合作的第三方App升级targetSdk。4.3 存储空间不足与文件清理策略理赔App在用户手机上会积累大量图片缓存和上传日志一旦用户的手机存储空间不足App很容易出现莫名其妙的问题最典型的是拍照后返回的Uri对应的临时文件写入失败。我开发时遇到一个很懵的场景相册选图功能在存储剩余约500MB的机器上一切正常但到了剩余不到100MB的机器上选了图后预览直接白屏看日志才发现是临时文件写入时磁盘空间不足。这个问题不能完全依赖系统去提示理赔App自己要有一套缓存管理策略。我的方案是拍照和压缩产生的临时文件全部放到cacheDir或getExternalCacheDir()因为系统在存储压力大的时候会自动清理这些目录App内部维护一个文件生命周期管理上传成功的本地文件在后台静默删除只保留最近一周的缓存缩略图设定磁盘剩余空间阈值比如低于200MB在用户进入上传页面时主动提示“手机存储空间不足建议清理后继续上传”。这套机制上线后因为存储空间问题引发的用户投诉基本归零。5. 数据安全与合规保险App的底线5.1 本地敏感数据的加密与日志脱敏保险理赔涉及身份证号、银行卡号、电话号码、家庭住址等敏感个人信息这些数据一旦在客户端明文存储无论后端做得多安全都等于把用户隐私送到了攻击者嘴边。我在项目里把SharedPreferences全面停用改成基于Android Keystore的加密存储方案。具体做法是用Keystore生成一个不可导出的AES密钥再用它加密需要持久化的敏感字段密钥本身由系统级安全硬件保护即使手机被root攻击者也拿不到密钥。日志脱敏这块很多人容易忽略。开发阶段我会在Log里打印完整的请求体来排查问题但上线的release包绝不能这么做否则用户的身份证号、银行卡号会随着崩溃日志一起上传到日志平台。我的做法是网络层统一封装日志输出对sensitiveKeys集合里的字段做掩码处理身份证号只保留前3后4银行卡号只保留后4位。这个规则从项目一开始就定好后面就没出过泄露事故。5.2 防线逆向、防篡改的基础加固理赔App是典型的“高价值攻击目标”市面上有很多人通过反编译App去伪造理赔请求或者刷单所以不做加固等于裸奔。我用的方案是接入主流加固平台的免费或商用加固服务对DEX文件做整体加密同时开启反调试、防模拟器、防截屏等基础策略。这样做的直接效果是普通技术爱好者拿到你的APK想用jadx直接看代码是不可能的。但加固不是万能的它只能提高攻击门槛不能杜绝攻击。我同时做了服务端的签名校验和请求风控App每次请求都带上一个由客户端签名生成的token服务端校验签名是否合法对于理赔金额、银行卡号这类敏感接口服务端做严格的风控策略比如同一个设备短时间内提交多次理赔直接触发人工审核。这套组合拳下来至少把90%的脚本刷单挡在了门外。5.3 权限最小化与隐私检测合规这块权限申请是最容易翻车的环节。保险理赔App其实根本不需要短信读取权限、通话记录权限、精确地理位置权限但早期需求里产品经理把“获取当前定位辅助填写出险地点”这个功能加进来了结果一问技术方案直接要申请定位权限。我坚持把它改成了用户手动输入地址并且不上传GPS坐标因为出险地点的精确度要求根本没有那么高手动填写完全够用还能规避一个高危权限的隐私合规风险。上线前我用隐私扫描工具过了一遍重点检查有没有过度申请权限、有没有在未同意隐私政策前就开始采集设备信息、有没有第三方SDK偷偷上传设备指纹。这些点不仅影响应用商店审核还可能因为违反相关法规被通报。我的经验是跟所有第三方SDK都要确认清楚他们到底采集了什么数据很多免费SDK会默默拿你的设备信息和用户行为数据去做广告追踪这在保险类应用里是绝对不能接受的。6. 上线前的完整检查与后续迭代思路6.1 从签名到多渠道打包的发布清单App开发完了真正上线前还有一堆琐碎但致命的事情。最基础的是签名文件release签名和debug签名必须分开签名文件要妥善备份一旦丢失以后所有版本升级都是噩梦。我就见过有团队把签名文件放在公司SVN上结果离职员工清理SVN时把目录删了后面只能换包名重新上架之前积累的用户全丢了。然后是渠道包的问题。国内应用商店五花八门每个商店要求的隐私政策文本、权限说明格式都不完全一样。我们的做法是使用Gradle的productFlavors配置多个渠道每个渠道动态替换对应的渠道ID和隐私政策入口一口气打出十几二十个渠道包。还要注意不同商店的targetSdk最低版本要求有的商店要求targetSdk必须达到33或34如果项目targetSdk还停留在旧版本可能连提交的资格都没有。上线前测试清单里我特别圈出几项覆盖Android 10到14的兼容性测试、弱网络环境下的上传续传测试、杀进程重启后未提交草稿的恢复、手机存储不足时的异常提示。这些不是功能需求单上的显性需求但哪一项没做好上线后都会变成用户差评的来源。6.2 线上崩溃监控与体验优化正式上线后不要以为工作就结束了线上监控才是真正检验工程质量的时候。我们接入了崩溃监控平台同时服务端记录每一次关键接口的性能数据。第一周我就发现有一个崩溃点集中出现在三星和部分国产手机上崩溃栈显示是相机拍照返回时FileProvider的Uri解析失败。后来定位发现是这部分机型相机的com.android.camera.action.CROP返回的Uri可能是空值导致后续代码空指针。我加了空值兜底并在onActivityResult里对返回的Intent做了严格的data和clipData双重判断这个问题才算解决。还有一个优化点是从启动速度入手。理赔App的主页面包含案件列表、消息中心、个人中心几个tab首帧绘制时如果同时加载太多图片低端机上必然卡顿。我把列表图片改成懒加载占位图并且使用协程做分页加载首屏只请求第一页数据体验提升非常明显。6.3 后续可扩展的方向第一版跑通之后后面可以玩的东西其实很多。比如发票识别这块以前是用户拍照上传后台人工审核后面完全可以接OCR服务自动识别发票代码和金额用户拍完照就自动预填信息省掉一大截等待时间。再比如案件进度推送不单是App内推送还可以接入短信和微信服务号模板消息让用户不需要打开App也能知道理赔进度。还有一个小方向是智能定损预览。用户可以上传事故照片后App端先用图像识别做一个简单的受损区域标注然后根据历史理赔数据给出一个大致的预赔付区间让用户对结果有预期减少焦虑。技术上开源模型已经能跑但准确性还需要大量业务数据打磨这是一个值得持续投入的方向。总的来说做这样一款保险理赔App跟做那种“今天上线明天迭代”的工具类应用完全是两回事。业务上你得懂理赔流程技术上你得把文件存取、网络层、系统适配、数据安全这些链路全部打磨扎实还要在权限合规和用户体验之间反复权衡。尤其几个容易被忽略的点FileProvider的路径配置、Android 11的包可见性、Android 14的存储限制、网络请求的幂等保护、日志脱敏和加固每一项都是线上事故高发区。我最后再分享一个经验教训做这类App一定要把“用户一个操作可能被重复执行”“用户可能在弱网环境使用”“用户手机可能很旧很卡”这三个假设刻在脑子里。所有的设计决策从接口幂等到图片压缩再到缓存清理都是围绕这三个假设展开的。把这些问题想透了你的理赔App才经得起真实用户的考验。本文还有配套的精品资源点击获取