Unity安卓APK版本更新完整方案：检测、下载、MD5校验与安装适配

做Unity安卓项目，最躲不开的东西就是“更新”。无论是修复线上崩溃、上线新玩法，还是替换过期的配置文件，只要应用发出去，官方商店审核的节奏往往是跟着版本周期走的，自有渠道或者测试包反而等不起。直接让玩家点链接下载APK再手动安装的体验太粗暴了，而且七八年前的Android机型装上还会因为文件来源问题直接打不开。后来我把整套APK版本更新链路收敛到Unity内部，从版本检测、下载、MD5校验到拉起系统安装器，全部在C#层搞定，不需要额外写原生Activity，也不用接入第三方SDK。这篇文章就把这套方案完整拆出来，从技术选型到Android各版本适配的坑一次说清，适合在Unity 2019/2020/2021上做过Android导出、但没系统处理过更新链路的开发者参考。

1. 更新链路设计：先搭框架，再谈APK下载安装

1.1 为什么需要一套独立的APK版本更新链路

很多团队的第一反应是“直接用商店更新不就行了”。这个想法在Google Play和国内主流商店确实成立，但放到自有渠道、官网下载站、定向测试、海外小众市场这些场景就很尴尬。商店更新需要上架审核，灰度包和测试包根本走不了这个流程。另一个绕不开的现实是，Unity打包出来的APK体积动不动就是两三百兆，横跨多个Android大版本，系统安装器对未知来源的限制越来越严，如果只是丢一个下载链接给用户，激活率会非常难看。

更核心的需求在于“可控”。版本更新不只是让用户装新包，它还得能表达“这个版本是强制还是建议”，能告诉用户更新了什么，能处理下载失败、校验失败、已下载过一半的缓存文件。这些逻辑放在服务器端动态下发，客户端按约定执行，才叫一套完整的更新链路，而不是临时写一个跳转链接。把检测和下载都收到Unity内部之后，策划和运营可以直接在后端配置更新策略，客户端不用发版就能调整，这套东西才真正具备生产价值。

1.2 完整链路拆解：版本检查、下载、安装三件事

整个APK版本更新链路可以切成三段。第一段是客户端向服务器请求版本清单，清单里包含最新版本号、APK下载地址、文件MD5、是否强制更新、更新日志。第二段是本地版本号比较，一旦发现远端版本更高，就弹出更新面板，同时根据强制属性决定用户能否跳过。第三段是下载新APK到应用沙盒目录，校验完MD5后，通过系统安装器拉起安装界面，用户点击确认后完成覆盖安装。

为什么要让客户端来做版本号比较而不是服务器直接返回“需要更新”？因为版本比较涉及本地的versionCode，只有客户端自己最清楚。服务器如果维护一个“每个包名当前版本”的状态，在多渠道多包名场景下逻辑会变得很笨重。反过来，服务器只需要提供一个静态JSON文件，客户端拿到后按约定比较，更新策略的改动完全不需要客户端发版，一套服务端配置可以同时服务多个不同包名的应用。这个设计从一开始就把复杂度放到了客户端，但换来的是非常灵活的运营节奏。

1.3 更新策略取舍：全量APK、资源更新还是热更新方案

聊到版本更新，一定会有人问“为什么不用热更新”。这取决于项目的技术栈。如果用Unity官方AssetBundle或各家的热更框架，代码逻辑通过IL2CPP解释执行，资源走分包加载，确实可以做到不装APK就换玩法。但热更方案天然有一套复杂的构建、加密、回退和版本管理成本，而且Unity引擎本身和AndroidManifest、Application类等原生层改动仍然需要发新包。APK全量更新和热更新不是替代关系，而是互补关系：引擎级改动、原生SDK改动、targetSdk提升，这些只能通过APK更新；业务资源逻辑迭代，才适合走热更。

全量APK更新最大的问题就是流量和等待时间。几百兆的包在白天空闲下载还能接受，但在弱网环境下很容易半途失败。因此这套方案里一定要有断点续传的替代手段和MD5校验，避免用户反复下载损坏的包。如果团队资源充裕，还可以做二进制差分更新，把新老APK的diff包下发到客户端再本地合成，但那个方案对服务器构建链路要求更高，一般项目没必要一上来就上。先把全量APK更新做稳健，已经能覆盖90%的场景。

2. 服务端版本清单与版本判断：别在versionName上做大小比较

2.1 版本清单的数据结构设计

版本清单本质上就是一个Json文件，放在CDN或者任何静态文件服务上，客户端用UnityWebRequest拉取。我建议在字段设计上一步到位，避免后面频繁扩展字段导致解析兼容问题。下面是我在多个项目里沉淀下来的结构：

{ "versionCode": 1024, "versionName": "3.2.0", "updateType": 0, "apkUrl": "https://cdn.example.com/packages/com.example.game_1024.apk", "fileSize": 314572800, "md5": "0a2f4c6d91e3f0b5a6b7c8d9e0f1a2b3", "releaseNotes": "修复了若干崩溃\n新增活动功能\n性能优化", "minVersionCode": 1000 }

versionCode必须是整数，它才是Android系统真正用来判断版本新旧的关键字段。versionName只是给人看的。updateType用0和1表示可选更新与强制更新，比字符串类型更不容易出错。minVersionCode可以用来做“低于某个版本必须强更”的精细控制，比如客户端当前版本实在太老、后台服务协议已经不兼容时，即使服务端没有把updateType设成1，客户端也可以根据minVersionCode自己判断成强制更新。这个字段很实用，前置版本可以不用，但字段要留下。

fileSize和md5这两个字段绝大多数开发者会忽略，但它们直接决定了下载体验。fileSize可以用来在下载前检查本地存储空间，提前告诉用户空间不足。md5则是防止下了个残缺APK的最后一道防线。releaseNotes直接用换行符分隔，客户端展示更新日志时按行拆开即可，不需要在服务器端维护富文本。

2.2 版本号比较的核心规则

版本比较绝对不能靠versionName做字符串排序，比如"9.0.0"字符串比较会大于"10.0.0"，这是典型翻车现场。Android端的正确做法是读取应用自身的versionCode，它是自增的整数，新版本一定比旧版本大。Unity C#侧没有直接获取versionCode的API，得通过AndroidJavaObject和PackageManager去拿。下面的代码是从Unity里读取当前应用versionCode的通用写法：

private int GetLocalVersionCode() { #if UNITY_ANDROID && !UNITY_EDITOR try { using (var player = new AndroidJavaClass("com.unity3d.player.UnityPlayer")) using (var activity = player.GetStatic<AndroidJavaObject>("currentActivity")) using (var packageManager = activity.Call<AndroidJavaObject>("getPackageManager")) using (var packageInfo = packageManager.Call<AndroidJavaObject>("getPackageInfo", Application.identifier, 0)) { return packageInfo.Get<int>("versionCode"); } } catch (Exception e) { Debug.LogError("读取versionCode失败: " + e.Message); return 0; } #else return 1; #endif }

这段代码需要注意几点。第一，Unity的Application.identifier在Android上就是包名，不需要写死。第二，getPackageInfo的参数0表示不需要额外返回签名等信息，只拿基本信息，速度更快。第三，老的Unity版本在编辑器下没有AndroidJavaClass环境，所以一定要用UNITY_ANDROID和UNITY_EDITOR做条件编译隔离。拿到本地versionCode后，和服务器返回的versionCode做整数比较，remoteVersionCode > localVersionCode才认为有新版本，逻辑非常干净。

2.3 强制更新与可选更新的判定逻辑

有了versionCode、updateType、minVersionCode之后，判定逻辑就可以统一写成这样：先看远端versionCode是否大于本地versionCode，如果不大于，直接进入游戏；如果大于，再看本地版本是否小于minVersionCode，或者updateType是否等于1，只要满足其中一个条件就走强制更新流程，否则走可跳过更新流程。

强制更新和可选更新的交互差异是决定性的。可选更新弹窗需要给三个按钮：立即更新、以后再说、忽略此版本。点了忽略要记住当前版本号，下次启动时相同版本不再弹窗，可以通过PlayerPrefs存一个字段来实现。强制更新则不给任何关闭入口，只显示更新内容和一个下载按钮，用户不更新就停留在更新面板。这里有一个容易被忽略的细节：服务器端如果只想对部分用户发灰度强更，versionCode和minVersionCode可以配合用户ID的服务端逻辑动态生成不同清单，而客户端代码完全不用改动。这就是把决策逻辑放到客户端比较、把决策数据放到服务端生成的价值所在。

3. Unity端实现：检测、下载、校验、拉起安装

3.1 版本检测模块：从网络拿版本清单

版本清单下载我用UnityWebRequest.GET，超时时间设成10秒。不建议用WWW类，老API在新版本Unity里已经退居二线，处理字节流和异常都不够清晰。下面是版本清单请求的协程实现：

private IEnumerator GetVersionData() { using (var uwr = UnityWebRequest.Get(versionJsonUrl)) { uwr.timeout = 10; yield return uwr.SendWebRequest(); if (uwr.result == UnityWebRequest.Result.Success) { remoteVersion = JsonUtility.FromJson<VersionData>(uwr.downloadHandler.text); Debug.Log("版本清单: " + uwr.downloadHandler.text); } else { Debug.LogError("版本清单请求失败: " + uwr.error); } } }

这里有一个经常会遇到的坑：JsonUtility不支持直接在类字段上定义为属性，而且对于可空字段支持很差。所以VersionData这个类必须设计成普通字段类型，并且所有字段都要有默认值。像fileSize如果用long，JsonUtility能正确解析。md5字段可能为空也没关系，后续校验逻辑里做判空处理。另外服务器的HTTP响应头Content-Type不要设置成text/html之类的，要用application/json，否则某些网关或解析库会异常，实际项目中我就遇到过CDN回源后Content-Type被改写导致Unity无法正常解析的问题。

3.2 APK下载与进度回调

下载大APK最忌讳的是把整个文件先读到内存再写磁盘，务必用DownloadHandlerFile，Unity会直接边下载边写文件，内存占用控制在非常低的水位上。下载协程需要挂在MonoBehaviour上，因为要持续返回yield null来刷新进度。核心代码如下：

private IEnumerator DownloadApk(string url, string targetPath) { var directory = Path.GetDirectoryName(targetPath); if (!string.IsNullOrEmpty(directory)) Directory.CreateDirectory(directory); using (var uwr = UnityWebRequest.Get(url)) { var dhf = new DownloadHandlerFile(targetPath); dhf.removeFileOnAbort = true; uwr.downloadHandler = dhf; uwr.timeout = 60; var operation = uwr.SendWebRequest(); while (!operation.isDone) { downloadProgress = operation.progress; OnDownloadProgress(downloadProgress); yield return null; } if (uwr.result != UnityWebRequest.Result.Success) { if (File.Exists(targetPath)) File.Delete(targetPath); Debug.LogError("APK下载失败: " + uwr.error); } } }

DownloadHandlerFile的removeFileOnAbort必须设置成true，这样下载被中断或失败时Unity会自动删除残留的临时文件，否则你会在沙盒目录里累积大量损坏的.apk文件。下载进度用operation.progress就能拿到0到1的浮点数，直接赋值给UI的Slider或Image.fillAmount。需要提醒的是，operation.progress是一个平滑估算值，在HTTP下载大文件时可能会有轻微延迟，但对用户展示完全够用。如果你需要更精确的下载字节数，可以自己解析服务器返回的Content-Length响应头，再通过DownloadHandler的下载字节回调来算，不过日常项目里没这个必要。

还有一个值得做的优化是缓存校验。如果目标APK文件已经存在，而且MD5和服务器返回的一致，那就可以跳过下载直接进入安装流程。这就避免用户上次下载完成后没装、下次还傻傻地重新下载一遍。代码如下：

bool needDownload = true; if (File.Exists(apkSavePath)) { var localMd5 = GetFileMd5(apkSavePath); if (localMd5 == remoteVersion.md5) needDownload = false; else File.Delete(apkSavePath); }

3.3 下载后校验MD5：内容完整性的底线

因为下载过程可能被网络波动、磁盘写入等原因破坏文件，甚至CDN节点本身会返回损坏内容，所以下载完成后必须做MD5校验。C#计算MD5没有平台差异，直接用System.Security.Cryptography即可：

private string GetFileMd5(string filePath) { if (!File.Exists(filePath)) return ""; using (var stream = File.OpenRead(filePath)) using (var md5 = MD5.Create()) { var hash = md5.ComputeHash(stream); var sb = new StringBuilder(); foreach (var b in hash) sb.Append(b.ToString("x2")); return sb.ToString(); } }

对大文件调用ComputeHash会流式读完，不会一次性把文件载入内存，所以几百兆的APK算MD5也很快，基本上两三秒内能出结果。校验不一致就直接删除文件，不能修复，也没有修复的必要。有一种情况需要重点留意：服务器上传APK后如果自己重新生成MD5，这个MD5必须是APK文件的二进制摘要，而不是文件名或文件大小的哈希。我踩过一次坑，运营直接在网上下载了个“MD5计算工具”，算出来的结果格式是大写十六进制，而客户端代码比较的是小写，结果每次都判定文件损坏。建议服务端统一生成小写MD5，或者客户端比较时统一转小写。

3.4 拉起系统安装器的Android桥接

安装APK这一步绕不开Android原生的Intent机制。Android 7.0之后，直接用file://路径启动安装界面会抛FileUriExposedException，必须通过FileProvider把真实路径包装成content://URI，并临时授权给系统安装器读取。Unity C#侧用AndroidJavaObject调用Java接口的代码如下：

public void InstallApk(string apkPath) { #if UNITY_ANDROID && !UNITY_EDITOR using (var player = new AndroidJavaClass("com.unity3d.player.UnityPlayer")) using (var activity = player.GetStatic<AndroidJavaObject>("currentActivity")) using (var file = new AndroidJavaObject("java.io.File", apkPath)) using (var fileProvider = new AndroidJavaClass("androidx.core.content.FileProvider")) using (var uri = fileProvider.CallStatic<AndroidJavaObject>("getUriForFile", activity, Application.identifier + ".fileProvider", file)) using (var intent = new AndroidJavaObject("android.content.Intent")) { intent.Call<AndroidJavaObject>("setAction", "android.intent.action.VIEW"); intent.Call<AndroidJavaObject>("setDataAndType", uri, "application/vnd.android.package-archive"); intent.Call<AndroidJavaObject>("addFlags", 0x00000001); // FLAG_GRANT_READ_URI_PERMISSION intent.Call<AndroidJavaObject>("addFlags", 0x10000000); // FLAG_ACTIVITY_NEW_TASK activity.Call("startActivity", intent); } #endif }

这里最关键的是FileProvider的authority，也就是getUriForFile的第二个参数。它必须跟AndroidManifest里配置的provider authorities完全一致，我用的是“包名.fileProvider”。如果两边不一致，调用getUriForFile时会直接抛出IllegalArgumentException，而且崩溃日志不容易一眼找到根因。准备好了APK路径之后，授权flag必须加0x00000001，系统安装器才能读写这个content URI；0x10000000保证这个Intent是跨任务启动的，没有这个flag在Unity的Activity上下文中启动会失败。

3.5 Android工程配置：FileProvider与安装未知来源权限

Unity不像Android Studio那样直观管理Manifest，但通过Assets/Plugins/Android/AndroidManifest.xml覆盖默认配置是完全可行的。先声明安装未知来源需要的权限和FileProvider：

<uses-permission android:name="android.permission.REQUEST_INSTALL_PACKAGES" />

<application> <provider android:name="androidx.core.content.FileProvider" android:authorities="${applicationId}.fileProvider" android:exported="false" android:grantUriPermissions="true"> <meta-data android:name="android.support.FILE_PROVIDER_PATHS" android:resource="@xml/file_paths" /> </provider> </application>

接着在Assets/Plugins/Android/res/xml/目录下新建file_paths.xml，告诉FileProvider哪些路径可以对外暴露：

<?xml version="1.0" encoding="utf-8"?> <paths> <files-path name="update_apk" path="Update/" /> </paths>

这里和代码里的保存路径必须严格配套。我把APK下载到Application.persistentDataPath + "/Update/"目录下，在Android上它对应的是Context.getFilesDir()，而 正好映射filesDir，所以path写成Update/。如果只用外部公共存储目录Download文件夹，就要用 ，但那样会引入存储权限问题，分区存储之后特别麻烦。尽量把APK保存到应用沙盒目录，FileProvider帮你把授权搞定，省掉一堆运行时权限申请。

4. Android适配与打包：不同系统版本的更新坑

4.1 Android 7.0：FileUriExposedException的高发地带

很多老项目的代码是在Android 6及更早机型上写的，用Uri.fromFile直接抛给安装器。Android 7.0开始，这种file://URI会触发FileUriExposedException，应用直接崩溃。最气人的是这类崩溃只在部分国产ROM的特定版本上复现，测试机不覆盖就发现不了。解决方案只能是用FileProvider，没有捷径。如果你同时还在用第三方分享SDK或系统相册，也需要检查它们的URI传输方式，FileProvider的配置可以同时服务多个场景，但authority要区分。还有一点，Unity打包时如果发现自己添加的provider和某个SDK里的provider冲突，会报DuplicateProvider错误，这种通常发生在两个aar都声明了相同的authority，排查时直接搜索“authorities”关键字即可。

4.2 Android 8.0与更高版本：未知来源权限的二次确认

Android 8.0开始允许用户安装未知来源应用的权限被拆得更细，每个应用都必须单独授权，直接跳系统安装界面有可能被系统拦截，没有任何提示。所以要给玩家一个明确的授权入口。Unity侧可以利用PackageManager的canRequestPackageInstalls方法判断是否已经授权：

private bool CanRequestPackageInstalls() { #if UNITY_ANDROID && !UNITY_EDITOR using (var player = new AndroidJavaClass("com.unity3d.player.UnityPlayer")) using (var activity = player.GetStatic<AndroidJavaObject>("currentActivity")) using (var pm = activity.Call<AndroidJavaObject>("getPackageManager")) { return pm.Call<bool>("canRequestPackageInstalls"); } #else return true; #endif }

未授权时，跳转系统设置页让用户打开“允许来自此来源的应用”开关：

public void OpenUnknownSourceSetting() { #if UNITY_ANDROID && !UNITY_EDITOR using (var player = new AndroidJavaClass("com.unity3d.player.UnityPlayer")) using (var activity = player.GetStatic<AndroidJavaObject>("currentActivity")) using (var intent = new AndroidJavaObject("android.content.Intent", "android.settings.MANAGE_UNKNOWN_APP_SOURCES")) using (var uri = new AndroidJavaClass("android.net.Uri").CallStatic<AndroidJavaObject>("parse", "package:" + Application.identifier)) { intent.Call<AndroidJavaObject>("setData", uri); activity.Call("startActivity", intent); } #endif }

实际体验最好的做法是：检测到未授权，弹一个讲解弹窗，解释为什么要开这个权限，再跳转到设置页。返回游戏后再检查一次授权状态，如果已经授权，自动继续安装流程。注意这类特殊权限不能通过运行时权限弹窗直接授予，必须走设置页。

4.3 Android 10及以上：分区存储对下载路径的影响

Android 10开始强制分区存储，应用不能随意往公共目录写文件，但这对于我们的方案反而是利好，因为APK从一开始就写在应用私有目录里，绕开了所有分区存储限制。真正要注意的是FileProvider的 映射不要写错，尤其不能把persistentDataPath误认为外部存储。Unity文档里Application.persistentDataPath在Android上就是/data/user/0/包名/files，我用 覆盖这个目录正好合理。

Android 11还有一个包可见性概念，应用默认看不到其它应用Partial的package信息。不过系统安装器是系统组件，ACTION_VIEW安装APK不依赖包可见性，所以目前不需要额外声明QUERY_ALL_PACKAGES。但如果你在更新模块里还要做“判断本机是否已经安装某应用”之类的操作，就需要在Manifest里添加 节点，否则PackageManager查询不到。这个先留个印象，等真遇到对应需求再补。

4.4 Unity打包导出设置与Gradle依赖

Unity导出Android工程时，默认Gradle模板在高版本Unity中已经启用AndroidX。如果你的项目还在用Android Support库，FileProvider的类名要改成android.support.v4.content.FileProvider，依赖也要换成com.android.support:support-compat:28.0.0。我建议新项目一律走AndroidX，因为Android Support库早已停止维护，各家SDK也都在强制迁移。

如果Unity构建时提示找不到androidx.core.content.FileProvider，在Assets/Plugins/Android/mainTemplate.gradle的dependencies块里加一行：

dependencies { implementation 'androidx.core:core:1.9.0' }

然后在ProjectSettings里确认选中“Custom Main Gradle Template”，否则这个文件不会被应用。另外还有一个和APK更新直接相关的设置：Player Settings里的Package Name必须和实际发布包名一致，因为FileProvider的authority拼接和读取versionCode都依赖包名。测试包和正式包如果用了不同包名，一定要把authority的取值也改掉，不然会出现测试包安装不上、正式包FileProvider找不到URI的诡异问题。

5. 实战问题排查：更新失败基本都是这几类原因

5.1 安装包打不开或点击更新无响应

最常见的第一种现象是点击“立即更新”后，系统没有任何反应，也不弹安装器。先排查Intent有没有成功启动：在AndroidManifest里给provider配置了exported=false，这个是正确的，不必改。问题通常出在FileProvider的authority不一致，或APK路径不在file_paths配置的范围内。可以把Android日志过滤出来，搜“ActivityNotFoundException”或者“SecurityException”，基本能定位到。另一个原因是Unity侧的Activity上下文不对，一定要用UnityPlayer.currentActivity，不要自己new一个没有生命周期的Context。

5.2 解析包出现错误

“解析包出现错误”是用户更新反馈的高频词，背后的原因主要有三类：APK下载损坏、APK不是完整的安装包、安装包签名和当前应用不一致。如果走完了MD5校验仍然解析失败，先怀疑签名问题。系统要求升级安装的APK签名必须和旧包一致，否则会在安装阶段提示包冲突或签名不一致。很多团队为了方便测试用调试签名打包，正式发布拿另一个keystore签名，测试机上升级就翻车。解决方法是所有对外包统一用正式签名，测试机卸载旧包再安装新包只能临时解决，不能作为常态。

我还会建议在解析失败之前，用PackageManager的getPackageArchiveInfo先解析要安装的APK，看看能不能拿到包信息和签名。能拿到说明文件完好且格式正确，拿不到直接判定包损坏。这个检测在Unity的C#层里写起来稍显繁琐，但确实能提前给玩家一个准确的错误提示。

5.3 明明更新了却仍然弹更新框

这通常不是逻辑问题，而是服务器VersionData缓存或者客户端本地versionCode没有刷新。常见的坑是本地版本号从Unity的PlayerSettings.bundleVersion读取，而不是从PackageManager读versionCode。如果导出时没有每次提升版本号，服务器上已经是新版，本地拿到的版本号还是旧值，就会永远提示更新。解决方案就是统一用versionCode，并且养成每次发版都在Unity里修改androidVersionCode的好习惯。

另一个被忽略的缓存点在PlayerPrefs，忽略此版本字段如果存的是versionCode而不是versionName，当服务器推高版本时就不会误判为同一版本。如果存的是versionName字符串，一旦版本名从1.0.1跳到1.0.2，比较逻辑还要额外处理字符串，容易出错。统一用整数versionCode存，干净利落。

5.4 大版本更新时报存储空间不足

下载大APK之前不检查空间，走到一半系统提示空间不足，然后删除文件让用户重新下载，体验极差。做法是在下载前通过AndroidJNI调用StatFs获取应用沙盒所在分区的可用字节数：

private long GetAvailableStorageBytes() { #if UNITY_ANDROID && !UNITY_EDITOR try { using (var player = new AndroidJavaClass("com.unity3d.player.UnityPlayer")) using (var activity = player.GetStatic<AndroidJavaObject>("currentActivity")) { var statFs = new AndroidJavaObject("android.os.StatFs", activity.Call<AndroidJavaObject>("getFilesDir").Call<string>("getAbsolutePath")); long blockSize = statFs.Call<long>("getBlockSizeLong"); long availableBlocks = statFs.Call<long>("getAvailableBlocksLong"); return blockSize * availableBlocks; } } catch (Exception e) { Debug.LogError("获取存储空间失败: " + e.Message); return long.MaxValue; } #else return long.MaxValue; #endif }

用remoteVersion.fileSize和这个可用空间做比较，如果空间不足，直接提示清理，同时把要下载的APK大小显示给玩家。注意这个检查只能作为预检，下载过程中仍然可能被其它应用占用空间挤掉，所以下载协程里依然要对WriteError等情况做兜底。

5.5 常见错误速查表

注意：强制更新并不能真正意义上“锁死”Android返回键和桌面Home键去防止用户退出应用，这是系统限制。合理做法是进入强制更新面板后不断让UI置顶，同时后台服务端记录玩家退出行为，后续通过补偿策略引导回归。

结尾：这套方案在真实项目里的落地经验

我最早做APK更新时，想得很简单，下载完Intent打开就行，结果单是FileProvider适配就折腾了两天。后来把所有逻辑收敛成一套UpdateManager模块，才发现之前的大部分问题都不在下载本身，而在版本数据协议、路径映射和权限适配这些“看不见的细节”上。像我这种只维护一个Unity客户端的人，最舒服的维护模式是：版本清单由后端一次性配置，客户端只信versionCode和MD5，所有下载路径都限制在应用沙盒目录内，更新面板的文案统一从releaseNotes读。这样每次发版，我只需要在构建机更新一次版本号，上传APK和md5到CDN，然后改一行JSON配置，整个更新流程就自动生效，不用再碰客户端代码。

最后还有一个容易被忽略的小技巧：更新面板的下载按钮在开始下载后，建议把进度数字和百分比都展示出来，同时允许用户取消下载。如果用户中途取消，删除半成品文件并回到初始状态。这个“可取消”能力看着很小，但在大包场景下非常影响用户体验，能大幅减少因网络不稳定导致的差评。希望这篇文章能把你的APK更新链路一次搭稳，后面换成商店分发或者做差分更新，这套骨架也能顺势平滑过渡。