企业官网建设流程全解析

1. 从零到上线的完整路径：为什么选 WorkBuddy 做 App

用 WorkBuddy 搭一个能真正上线的 App，这件事我从头到尾跑了一遍，前后踩了十六个坑，最后整理出六个阶段的可复用流程。如果你手头正好有一个想快速验证的产品想法，或者你是一个前端转移动端、不想一上来就啃原生 Android 的开发者，这套路径应该能帮你省掉不少返工时间。WorkBuddy 这类 AI 辅助开发工具的核心价值，不在于替你写完全部代码，而在于把“项目脚手架、页面结构、接口对接、打包配置”这些重复度极高的环节压缩成可对话、可迭代的流程，让你把精力放在业务逻辑和体验打磨上。

我这次做的 App 是一个内容聚合加轻交互的工具类应用，目标平台是 Android，内部用 WebView 承载主要页面，外层用原生壳做启动、权限、更新和分享。选择 WebView 混合方案的原因很直接：团队里前端资源多，H5 迭代快，发版不需要每次走应用商店审核，热更新内容也方便。但混合方案不是没有代价，WebView 的版本兼容、文件访问协议、进度条反馈、唤起安装这些问题，一个都躲不掉。热搜词里出现的webview历史版本合集、android8.1支持的webview版本、content://com.baidu.searchbox.fileprovider这些，恰恰说明很多人在真实项目里被 WebView 的碎片化折磨过。

这篇文章会按六个阶段展开：需求收敛与工具选型、项目初始化与目录结构、WebView 容器与原生桥接、核心页面与交互实现、打包签名与上线准备、线上问题排查与迭代。每个阶段我都会把当时做的选择、背后的理由、以及踩到的坑讲清楚。十六个坑我不会单独列一个清单草草带过，而是把它们嵌在对应阶段里，这样你看到问题的时候，正好能看到上下文和解决思路。适合谁看？适合已经会一点 HTML/CSS/JS、想快速做出一个能安装、能打开、能用的 Android App 的人；也适合用 WorkBuddy 或类似 AI 辅助工具做开发、但卡在“本地跑得通、打包就出错”这个环节的人。

2. 六个阶段总览与工具选型逻辑

2.1 阶段划分与交付物

我把整个项目拆成六个阶段，每个阶段都有明确的交付物，避免“感觉快做完了但一直上不了线”的状态。

这个划分不是拍脑袋来的。我试过一上来就写业务页面，结果到打包阶段发现 WebView 配置不对，所有页面都要回头改。也试过先把壳做得特别完善，结果业务需求一变，壳里的桥接方法全废。六个阶段的顺序，本质上是把“不确定性高的决策”放在前面，把“机械性劳动”放在后面。工具选型、WebView 方案、目录结构这些一旦定错，后面返工成本极高；而页面样式、文案调整这些，随时可以改。

2.2 为什么用 WorkBuddy 而不是纯手写

WorkBuddy 在这类项目里的定位，更像一个“懂 Android 项目结构的结对伙伴”。我实际用下来的感受是，它在几个环节特别省事：生成build.gradle配置、创建 Activity 和布局文件、写 WebView 的初始化代码、处理权限声明。这些代码本身不难，但琐碎且容易漏。比如AndroidManifest.xml里少一个INTERNET权限，本地调试可能没事，一打包就白屏；WebView的settings少开domStorageEnabled，H5 里的 localStorage 直接失效。

但 WorkBuddy 不是银弹。它生成的代码需要你理解每一行的作用，否则出了问题根本不知道从哪查。我踩过的坑里，至少有三个是因为“直接用了生成的配置但没看懂”导致的。所以我的建议是：用 WorkBuddy 加速，但关键配置必须自己过一遍，尤其是build.gradle的minSdkVersion、targetSdkVersion，以及WebView相关的setJavaScriptEnabled、setDomStorageEnabled、setAllowFileAccess这几项。

2.3 热搜词背后的真实需求拆解

热搜词里有一批很具体的技术词，比如content://com.baidu.searchbox.fileprovider、content://com.tencent.wework.fileprovider、snssdk1128://webview。这些其实是 Android 里FileProvider和Scheme跳转的典型问题。FileProvider用于在应用间安全地共享文件，如果你在 WebView 里上传文件或者调用相机，没有配置FileProvider，就会直接崩溃。snssdk1128://这种是特定 App 的 Scheme，用于从浏览器或外部应用唤起目标 App 的指定页面。

还有ios浏览器唤起安装app、android进度条、app字体设置这些，说明用户对“安装引导、加载反馈、字体适配”有强需求。我在项目里也遇到了：H5 页面在 WebView 里字体偏小，需要根据系统设置动态调整；加载外部页面时没有进度条，用户以为卡死；从 H5 里点击“下载 App”按钮，需要正确唤起安装器。这些都不是核心业务逻辑，但直接影响上线后的用户留存。

3. 阶段一：需求收敛与工具选型

3.1 功能清单的“三刀切”方法

需求收敛最怕的就是“这个也想要，那个也想要”。我用了一个很粗暴但有效的方法：把功能分成三刀。第一刀，砍掉所有“没有它 App 也能上线”的功能；第二刀，砍掉所有“需要后端大改”的功能；第三刀，砍掉所有“平台审核风险高”的功能。三刀下去，剩下的才是第一版必须做的。

具体到我的项目，第一版只保留：首页内容列表、详情页 WebView 展示、分享按钮、检查更新。像用户登录、评论、收藏这些，全部放到第二版。这样做的好处是，第一版的上线周期从预估的一个月压缩到两周，而且打包和审核环节的问题暴露得更早。很多人做 App 卡住，不是因为技术难，而是因为第一版塞了太多东西，每个功能都差一点，最后哪个都上不了线。

3.2 WorkBuddy 与 CodeBuddy 的配合方式

热搜词里同时出现了workbuddy和codebuddy，这两个工具在定位上有区别。WorkBuddy 更偏向项目级、流程级的辅助，比如帮你规划目录、生成配置、解释报错；CodeBuddy 更偏向代码片段级的补全和生成。我实际用的时候，是先用 WorkBuddy 把项目骨架和关键配置搭起来，然后在写具体页面逻辑时用 CodeBuddy 补全。

但要注意，不要同时让两个工具改同一个文件。我踩过一次坑：WorkBuddy 生成了MainActivity.java，我又让 CodeBuddy 在这个文件里加方法，结果两边生成的 import 冲突，编译报了几十个错。后来我定了一个规矩：配置文件只由 WorkBuddy 生成，业务代码只由 CodeBuddy 补全，两边不交叉。这个规矩听起来简单，但能省掉大量排查时间。

3.3 技术方案选型：WebView 还是原生

这个决策我纠结了很久。原生方案性能好、体验流畅，但开发周期长，前端资源用不上。WebView 方案开发快、迭代灵活，但性能和兼容性是硬伤。最后我选 WebView，理由有三个：第一，我的页面以内容展示为主，交互不复杂，WebView 完全够用；第二，团队前端资源充足，H5 迭代速度远快于原生；第三，我需要热更新能力，WebView 可以直接加载远程页面，原生做不到。

但 WebView 方案有几个必须提前想清楚的问题。一是WebView版本碎片化，Android 8.1 以下的设备，系统 WebView 版本可能很老，某些 CSS 特性不支持。二是文件访问协议，Android 7.0 以后file://协议被限制，必须用FileProvider。三是返回键处理，WebView 里的页面栈和原生 Activity 栈要同步，否则用户按返回键会直接退出 App。这些问题我在后面阶段都会展开。

4. 阶段二：项目初始化与目录结构

4.1 用 WorkBuddy 生成项目骨架

项目初始化这一步，WorkBuddy 能帮上大忙。我当时的操作是：在 WorkBuddy 里描述项目类型（Android 原生壳 + WebView）、目标 SDK 版本、需要的权限，让它生成build.gradle、AndroidManifest.xml、MainActivity.java和基础布局文件。生成之后，我没有直接跑，而是先做了一件事：把minSdkVersion从默认的 21 改成 23。

为什么改？因为 Android 6.0（API 23）开始才有运行时权限，minSdkVersion低于 23 的话，权限处理要写两套逻辑，非常麻烦。而 API 23 以下的设备占比已经很低了，放弃这部分设备对上线影响不大。targetSdkVersion我设的是 33，因为应用商店对 targetSdk 有要求，太低会影响上架。这两个参数看起来简单，但设错了后面全是坑。

4.2 目录结构设计：按功能还是按类型

目录结构我试过两种方案。第一种是按类型分：activities/、fragments/、adapters/、utils/。第二种是按功能分：home/、detail/、share/、update/。最后我选了按功能分，原因是这个项目功能边界清晰，按功能分之后，每个包里的文件少，找起来快。按类型分的话，activities/里会堆十几个文件，改一个功能要跳好几个包。

具体结构是这样的：

app/src/main/java/com/example/app/ ├── home/ │ ├── HomeActivity.java │ └── HomeFragment.java ├── detail/ │ └── DetailActivity.java ├── share/ │ └── ShareHelper.java ├── update/ │ └── UpdateChecker.java ├── webview/ │ ├── WebViewContainer.java │ └── WebViewClientImpl.java └── util/ ├── FileUtil.java └── LogUtil.java

这个结构不是 WorkBuddy 默认生成的，是我手动调整过的。WorkBuddy 默认按类型分，但你可以直接告诉它“按功能模块组织目录”，它会照做。这里的关键是，目录结构一旦定下来，后面新增文件就按这个规矩放，不要今天按功能、明天按类型，否则半年后你自己都找不到文件。

4.3 依赖管理与版本锁定

依赖冲突是 Android 项目里最烦人的问题之一。我踩的坑是：WorkBuddy 生成的build.gradle里用了implementation 'androidx.appcompat:appcompat:1.6.1'，但我后来手动加了一个第三方库，它依赖的是appcompat:1.4.0，结果编译时版本冲突，报了一堆Duplicate class错误。

解决办法是用gradle dependencies命令查看依赖树，找到冲突的库，然后用exclude排除掉旧版本，或者用resolutionStrategy强制指定版本。更稳妥的做法是，在项目初始化阶段就把所有依赖版本写在一个ext块里，统一管理。比如：

ext { appcompatVersion = '1.6.1' webkitVersion = '1.6.0' constraintLayoutVersion = '2.1.4' }

然后在各模块里引用$appcompatVersion。这样改版本只需要改一处，不会出现这个模块用 1.6.1、那个模块用 1.4.0 的情况。这个习惯我从第二个项目开始一直保持，省了很多事。

5. 阶段三：WebView 容器与原生桥接

5.1 WebView 初始化：必须开的配置项

WebView 的初始化配置，是整个项目里最容易漏、也最容易出问题的地方。我整理了一份必须开的配置清单，每一项都对应一个实际踩过的坑。

WebView webView = findViewById(R.id.webview); WebSettings settings = webView.getSettings(); // 必须开：否则 H5 里的 JS 全部失效 settings.setJavaScriptEnabled(true); // 必须开：否则 localStorage、sessionStorage 不可用 settings.setDomStorageEnabled(true); // 必须开：否则 H5 里的数据库操作失败 settings.setDatabaseEnabled(true); // Android 5.0 以上默认禁止混合内容，如果 H5 里有 http 资源，需要放开 settings.setMixedContentMode(WebSettings.MIXED_CONTENT_ALWAYS_ALLOW); // 允许文件访问，但 Android 7.0 以后要用 FileProvider settings.setAllowFileAccess(true); // 设置缓存模式，根据业务需求选 settings.setCacheMode(WebSettings.LOAD_DEFAULT); // 自适应屏幕 settings.setUseWideViewPort(true); settings.setLoadWithOverviewMode(true);

这里面setDomStorageEnabled和setDatabaseEnabled是最容易漏的。我踩的坑是：H5 页面在浏览器里跑得好好的，一放进 WebView 就白屏，查了半天发现是 localStorage 不可用，页面初始化逻辑直接挂了。还有setMixedContentMode，如果你的 H5 是 https，但里面引用了 http 的图片或接口，不开这个配置，资源全部加载失败。

5.2 文件访问与 FileProvider 配置

Android 7.0（API 24）开始，file://协议被StrictMode禁止，应用间共享文件必须用FileProvider。热搜词里出现的content://com.baidu.searchbox.fileprovider和content://com.tencent.wework.fileprovider，就是其他 App 的 FileProvider 路径。你自己的 App 也需要配置一个。

配置步骤分三步。第一步，在AndroidManifest.xml里声明FileProvider：

<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>

第二步，在res/xml/file_paths.xml里定义可共享的路径：

<paths> <external-path name="external_files" path="." /> <cache-path name="cache_files" path="." /> </paths>

第三步，在代码里生成content://URI：

File file = new File(getExternalFilesDir(null), "test.jpg"); Uri uri = FileProvider.getUriForFile(this, getPackageName() + ".fileprovider", file);

这里有个坑：authorities必须和代码里的getPackageName() + ".fileprovider"一致，否则会报IllegalArgumentException。我踩过一次，因为applicationId和packageName不一致（有 flavor 的情况下），导致 authorities 对不上。解决办法是统一用${applicationId}占位符，代码里也用BuildConfig.APPLICATION_ID。

5.3 原生与 H5 的桥接设计

桥接是混合 App 的核心。我设计了两种桥接方式：addJavascriptInterface和shouldOverrideUrlLoading。前者用于 H5 调用原生方法，后者用于原生拦截 H5 的跳转请求。

addJavascriptInterface的用法：

webView.addJavascriptInterface(new JsBridge(), "NativeBridge"); class JsBridge { @JavascriptInterface public void share(String title, String url) { // 调用原生分享 } @JavascriptInterface public String getAppVersion() { return BuildConfig.VERSION_NAME; } }

H5 里这样调用：

window.NativeBridge.share('标题', 'https://example.com');

这里有个安全坑：addJavascriptInterface在 API 17 以下有远程代码执行漏洞，所以minSdkVersion必须至少 17。我设的是 23，所以没问题。另外，所有暴露给 H5 的方法都必须加@JavascriptInterface注解，否则 H5 调不到。我踩过一次，方法忘了加注解，H5 一直报undefined，查了半天。

shouldOverrideUrlLoading用于拦截 H5 里的特殊 Scheme，比如snssdk1128://这种。如果 H5 里点击了一个链接，你想让原生处理而不是 WebView 加载，就在这里拦截：

@Override public boolean shouldOverrideUrlLoading(WebView view, WebResourceRequest request) { String url = request.getUrl().toString(); if (url.startsWith("myapp://")) { // 处理自定义 Scheme return true; } return false; }

返回true表示原生已处理，WebView 不再加载；返回false表示交给 WebView 加载。这个逻辑要小心，如果所有链接都返回true，H5 里的正常跳转也会失效。

6. 阶段四：核心页面与交互实现

6.1 加载进度条：用户体验的关键细节

热搜词里有android进度条，说明很多人关心这个。WebView 加载外部页面时，如果没有进度反馈，用户会以为 App 卡死。我的做法是在布局里加一个ProgressBar，在WebViewClient的onPageStarted和onPageFinished里控制显示和隐藏。

webView.setWebViewClient(new WebViewClient() { @Override public void onPageStarted(WebView view, String url, Bitmap favicon) { progressBar.setVisibility(View.VISIBLE); progressBar.setProgress(0); } @Override public void onPageFinished(WebView view, String url) { progressBar.setVisibility(View.GONE); } });

但这样有个问题：onPageFinished不一定在页面完全渲染后触发，有时候图片还没加载完就调用了。更精确的做法是用WebChromeClient的onProgressChanged：

webView.setWebChromeClient(new WebChromeClient() { @Override public void onProgressChanged(WebView view, int newProgress) { progressBar.setProgress(newProgress); if (newProgress == 100) { progressBar.setVisibility(View.GONE); } } });

这个方案更平滑，进度条会跟着实际加载进度走。我实测下来，onProgressChanged的触发频率足够高，用户体验比单纯显示/隐藏好很多。

6.2 返回键处理：避免直接退出 App

WebView 里的页面栈和原生 Activity 栈是两套系统。用户按返回键时，如果 WebView 里还有历史页面，应该先回退 WebView，而不是直接退出 App。处理逻辑在onBackPressed里：

@Override public void onBackPressed() { if (webView.canGoBack()) { webView.goBack(); } else { super.onBackPressed(); } }

这个逻辑看起来简单，但有个坑：如果 H5 里用了history.pushState，canGoBack会返回true，但goBack可能不会触发页面刷新。解决办法是在 H5 里监听popstate事件，或者用webView.evaluateJavascript手动通知 H5。我踩过一次，用户按返回键后页面没变，以为卡死了，其实是 H5 的路由没响应。

6.3 字体适配与屏幕适配

热搜词里有app字体设置，这个在 WebView 里确实是个问题。WebView 默认的字体大小可能和系统设置不一致，用户如果在系统里调大了字体，WebView 里的文字可能不变。解决办法是在WebSettings里设置setTextZoom：

// 跟随系统字体大小 settings.setTextZoom(getResources().getConfiguration().fontScale * 100);

但setTextZoom会影响所有文字，包括 H5 里用px定义的字号。更精细的做法是在 H5 里用rem或vw单位，然后通过evaluateJavascript动态设置根字号。我最后用的是折中方案：setTextZoom设为 100，H5 里用rem，根字号根据屏幕宽度计算。这样字体在不同设备上表现一致，也不会因为系统字体设置而错乱。

屏幕适配方面，setUseWideViewPort(true)和setLoadWithOverviewMode(true)是必须的，否则 H5 页面在手机上会显示成桌面版布局，字小得看不清。另外，如果 H5 里有固定定位的元素，要注意 WebView 的viewport设置，否则底部按钮可能被系统导航栏遮挡。

7. 阶段五：打包签名与上线准备

7.1 签名配置：一次配好，终身受用

签名是 Android 打包最容易出问题的环节。我踩的坑是：第一次打包用 Android Studio 自动生成的签名，第二次换了一台电脑，签名文件找不到了，导致无法覆盖安装。后来我定了一个规矩：签名文件统一放在项目根目录的keystore/文件夹里，密码写在gradle.properties里，并且把keystore/和gradle.properties加入版本控制（私有仓库）。

build.gradle里的签名配置：

android { signingConfigs { release { storeFile file('../keystore/release.jks') storePassword project.property('RELEASE_STORE_PASSWORD') keyAlias project.property('RELEASE_KEY_ALIAS') keyPassword project.property('RELEASE_KEY_PASSWORD') } } buildTypes { release { signingConfig signingConfigs.release minifyEnabled true proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro' } } }

这里有个坑：minifyEnabled true会开启代码混淆，如果 WebView 的桥接类被混淆了，H5 就调不到原生方法。解决办法是在proguard-rules.pro里保留桥接类：

-keepclassmembers class com.example.app.webview.JsBridge { public *; } -keepattributes JavascriptInterface

-keepattributes JavascriptInterface这一行特别重要，没有它，@JavascriptInterface注解会被混淆掉，H5 调用直接失败。我踩过一次，debug 包正常，release 包 H5 调不到原生方法，查了一整天才发现是混淆问题。

7.2 权限声明与运行时请求

AndroidManifest.xml里声明的权限，在 Android 6.0 以上需要运行时请求。我需要的权限有：INTERNET、ACCESS_NETWORK_STATE、WRITE_EXTERNAL_STORAGE（用于下载更新包）。INTERNET和ACCESS_NETWORK_STATE是普通权限，安装时自动授予；WRITE_EXTERNAL_STORAGE是危险权限，需要运行时请求。

运行时请求的代码：

if (ContextCompat.checkSelfPermission(this, Manifest.permission.WRITE_EXTERNAL_STORAGE) != PackageManager.PERMISSION_GRANTED) { ActivityCompat.requestPermissions(this, new String[]{Manifest.permission.WRITE_EXTERNAL_STORAGE}, REQUEST_CODE_STORAGE); }

这里有个坑：如果用户拒绝了权限，下次请求时系统可能不再弹窗。解决办法是在请求前用shouldShowRequestPermissionRationale判断，如果返回true，先弹一个解释对话框，再请求权限。如果返回false且权限未授予，说明用户勾选了“不再询问”，需要引导用户去设置页手动开启。

7.3 应用商店上架前的自查清单

打包完成后，不要急着上传。我整理了一份自查清单，每次发版前过一遍：

其中“混淆配置”和“网络配置”是最容易漏的。我踩过一次，release 包上传后审核通过，但用户下载后打开白屏，最后发现是混淆导致 WebView 的某个类被删了。还有一次，H5 里引用了 http 的接口，Android 9.0 以上默认禁止明文流量，需要在AndroidManifest.xml里加android:usesCleartextTraffic="true"或者配置network_security_config。

8. 阶段六：线上问题排查与迭代

8.1 白屏问题的排查思路

白屏是 WebView 混合 App 最常见的问题。排查思路按优先级排：第一，检查网络权限是否声明；第二，检查 WebView 的 JS 是否开启；第三，检查 H5 页面本身是否有报错；第四，检查混淆是否影响了桥接类；第五，检查mixedContentMode是否配置。

我遇到过一次白屏，排查了两小时，最后发现是 H5 页面里用了localStorage，但setDomStorageEnabled没开。还有一次是 release 包白屏，debug 包正常，原因是混淆把WebViewClient的某个回调方法删了。所以每次发 release 包前，一定要在真机上完整跑一遍核心流程。

8.2 常见问题速查表

这张表里的每一项，我都在实际项目里遇到过。最坑的是“安装包解析失败”，当时换了三台设备测试，最后发现是签名文件用错了。所以签名文件一定要备份，最好放在两个不同的地方。

8.3 版本迭代与热更新策略

WebView 方案的一个优势是热更新。我的策略是：原生壳只负责容器和桥接，业务页面全部放在 H5 里，通过远程加载。这样发版时，如果只是页面逻辑改动，不需要重新打包，直接更新 H5 即可。但要注意，H5 的缓存策略要配好，否则用户可能一直看到旧页面。

缓存策略我试过几种。LOAD_DEFAULT会根据 HTTP 缓存头决定是否用缓存；LOAD_NO_CACHE每次都从网络加载；LOAD_CACHE_ELSE_NETWORK优先用缓存。最后我选的是LOAD_DEFAULT，然后在 H5 的 URL 里加版本号参数，比如index.html?v=1.0.1。这样每次发版改版本号，用户就会加载新页面，平时则用缓存加速。

但这里有个坑：如果 H5 页面依赖了本地 JS 或 CSS 文件，版本号只加在 HTML 上不够，JS 和 CSS 的引用也要加版本号，否则浏览器可能用旧的缓存。我踩过一次，HTML 更新了，但 JS 还是旧的，页面报错。解决办法是在构建 H5 时自动给所有静态资源加 hash 或版本号。

9. 十六个坑的完整复盘与经验总结

9.1 配置类坑（六个）

第一个坑：minSdkVersion设太低，权限处理复杂。改成 23 后省事很多。第二个坑：targetSdkVersion设太低，应用商店上架被拒。第三个坑：build.gradle依赖版本冲突，用resolutionStrategy解决。第四个坑：AndroidManifest.xml漏了INTERNET权限，本地调试正常，打包白屏。第五个坑：FileProvider的authorities和代码不一致，上传文件崩溃。第六个坑：network_security_config没配，Android 9.0 以上明文流量被禁。

这六个坑的共同点是：它们都不会在开发阶段暴露，只在打包或上线后出现。所以我的经验是，项目初始化阶段就把这些配置全部过一遍，不要等到打包时再查。

9.2 代码类坑（五个）

第七个坑：addJavascriptInterface方法忘了加@JavascriptInterface注解，H5 调不到。第八个坑：shouldOverrideUrlLoading返回true太宽泛，H5 正常跳转失效。第九个坑：onBackPressed没处理canGoBack，用户按返回键直接退出。第十个坑：setDomStorageEnabled没开，H5 的 localStorage 不可用。第十一个坑：setTextZoom没设，字体和系统设置不一致。

这五个坑都是代码层面的，特点是 debug 包可能正常，release 包出问题。所以每次发 release 包前，必须用真机完整测试核心流程，不能只看 debug 包。

9.3 打包与上线类坑（五个）

第十二个坑：签名文件丢失，无法覆盖安装。第十三个坑：混淆没保留桥接类，release 包 H5 调不到原生方法。第十四个坑：versionCode没递增，应用商店拒绝上传。第十五个坑：隐私政策页面缺失，审核被拒。第十六个坑：H5 静态资源缓存没更新，用户看到旧页面。

这五个坑里，签名和混淆是最致命的。签名丢了，应用就废了；混淆配错，release 包直接不可用。我的建议是，签名文件至少备份两份，混淆规则在项目初期就配好，不要等到发版前才加。

9.4 可复用的经验清单

跑完整个项目后，我整理了一份可复用的经验清单，下一个项目直接照着做：

• 项目初始化时，minSdkVersion设 23，targetSdkVersion设最新稳定版。
• 依赖版本统一在ext块管理，避免冲突。
• WebView 初始化时，setJavaScriptEnabled、setDomStorageEnabled、setDatabaseEnabled、setMixedContentMode四项必开。
• FileProvider的authorities用${applicationId}.fileprovider，代码里用BuildConfig.APPLICATION_ID。
• 桥接类必须加@JavascriptInterface，混淆规则必须保留。
• 返回键处理必须判断canGoBack。
• 进度条用onProgressChanged，不要用onPageFinished。
• 签名文件备份两份，密码写在gradle.properties里。
• release 包必须真机测试 H5 桥接和核心流程。
• H5 静态资源加版本号或 hash，避免缓存问题。

这份清单看起来简单，但每一条背后都是一个真实的坑。我下一个项目直接照着这份清单做，至少省了三天排查时间。如果你也在用 WorkBuddy 或类似工具做混合 App，希望这些经验能帮你少走弯路。最后再分享一个小技巧：每次发版前，把这份清单打印出来，逐项打勾，比凭记忆靠谱得多。