日常生活中的WebView：App的运维有哪些变化

使用 WebView 的决定通常是在项目开始时在讨论截止日期和预算的会议上做出的。在这次会议上几乎没有人讨论的是接下来会发生什么：这个应用程序在第二年将如何表现，谁将维护它，它如何更新，当操作系统发生变化时会出现什么问题。

这就是理论与现实的结合。 WebView 应用程序在发布时看起来可以节省大量成本，但可能会成为操作难题，或者仍然是最佳选择，具体取决于团队处理日常操作的方式。

本文适用于那些已经或将要实际运行基于 WebView 的应用程序的人。这不是概念的问题，而是操作的问题。关于那些维护、支持和开发此类产品的人的日常工作发生了哪些变化。因为选择是在日常生活中而不是在决策幻灯片上得到证明的。

大家都引用的运营优势

让我们从好的一面开始，这是真实的。 WebView最大的实际优势恰恰体现在操作上：无需经过商店即可更新内容和更正。

在纯原生应用中，任何更改，甚至纠正错误的文本，都需要生成新版本，提交到商店审核，等待批准并希望用户更新。这个周期需要几天的时间，并且不会立即到达每个人；总会有人坚持旧版本。

在WebView中，屏幕就是一个网页。您可以在服务器上更正它，并且所有用户下次打开该屏幕时都会收到更正的信息。对于需要快速反应、纠正错误、调整活动、更改业务规则的团队来说，这是运营黄金。这就像几小时或一周内扑灭火灾的区别。

在看到几个产品成熟之后，我的立场是 WebView 并没有消除成本，而是随着时间的推移转移成本。您在启动时投入的费用更少，而作为回报，您可以持续关注运营。

这不是缺陷。这是选择的本质。问题是，当团队将 WebView 视为“我们做到了，就是这样”时，就好像它是您发布后就忘记的本机应用程序一样。它不是。 WebView 应用程序依赖于其背后的实时 Web 基础设施、服务器、页面、性能、安全性，这些都需要永久维护。

明白这一点的人从一开始就计划行动。那些不明白的人会发现，在最糟糕的时刻，这个“便宜”的应用程序实际上有一项没有人预算的经常性成本。

本机应用程序有一个维护周期。 WebView 中的应用程序有两个：本机容器（进入商店的 shell）和 Web 内容（它显示的页面）。它们以不同的速度发展并因不同的原因而破裂。

这意味着您的团队需要在这两个方面都有能力，或者明确划分谁负责什么。当知识集中在一个了解“应用程序如何与网络对话的魔力”的人身上时，您就会面临单点故障的发生。

有一个细节让许多团队感到惊讶：WebView 组件是操作系统的一部分，并会随之变化。 Android 或 iOS 更新可以巧妙地改变页面的呈现方式。过去工作完美的东西在没有人接触代码的情况下开始表现不同。

因此，在 WebView 中维护应用程序需要在系统的当前版本上定期进行测试，而不仅仅是在启动时进行一次测试。健康的运营包括监控平台宣布的内容并在更改到达用户之前进行验证。

WebView 应用程序的流动性直接取决于其加载的页面的重量。随着时间的推移，页面自然会积累代码、库和功能，并变得更慢。发布时可以接受的内容可能会在没有人注意到的情况下逐月下降，直到用户抱怨为止。

维护性能就变成了例行公事：监控加载时间、监控页面增长、定期优化。在巴西，许多人使用中间设备和不稳定的网络，这种关心是将可用的应用程序与在最重要的地方崩溃的应用程序区分开来的。

当本机应用程序出现问题时，问题通常出在安装的版本上。在WebView中，问题可能出在shell、页面、服务器、用户的连接或者用户的系统版本。诊断有更多层次。

这改变了提供支持的人的工作。拥有良好的错误记录来区分故障发生的位置使得诊断变得可行，因为“应用程序无法加载”可能意味着非常不同的事情。如果没有这种可见性，团队就只能猜测，而用户就只能等待。

另一方面，还有一个操作上的缓解：当问题出在网页内容中时，您可以修复一次并为每个人解决它，而不需要依赖于用户更新。在服务器上集中纠正的能力是该模型在日常支持方面的最大优势之一。

由于 WebView 加载 Web 内容，因此它继承了 Web 的安全问题，并且这些问题是持续存在的，而不是一次性的。老化并产生已知缺陷的库、过期的证书、需要遵循最佳实践的配置：所有这些都是定期维护。

对于处理用户或公民数据的应用程序，这直接关系到 [LGPD0] 和服务连续性。受损的页面或过时的依赖项不是“站点”问题，而是应用程序问题，具有相同的法律和信任后果。将 Web 层安全性视为日常操作是维护 WebView 成本的一部分。

最常见的陷阱是应用程序被遗弃在内部。从外面看他还在店里，看上去还活着。在内部，它加载的页面已经有几个月没有受到关注，性能下降，依赖关系老化。应用程序“存在”，但操作已停止，这成为无声风险。

另一个陷阱是没有为运营制定预算。该项目有资金建设，但没有人保留用于维护。由于 WebView 将成本转移到了运营上，因此没有维护预算的产品必然会比同等的本机应用程序更快地腐烂。

三是缺乏主人。当不清楚谁负责应用程序的 Web 层时，双方都会假设对方负责处理。 shell 是“移动团队”，页面是“Web 团队”，两者之间的边界是孤立的，这正是问题最多出现的地方。

值得记住的一句话是：WebView 不是您一次做出的决定。这是您每月更新的运营承诺。只有事后认真对待操作，才能实现启动节省。

如果操作良好，WebView 应用程序可以提供纯本机应用程序所不具备的敏捷性、即时更正、始终最新的内容以及快速的演进周期。如果经营不善，它就会成为一种不冷不热且脆弱的产品，其声誉的代价就是其在开发过程中节省下来的代价。技术是一样的；改变的是那些维持纪律的人的纪律。

如果您在 WebView 中操作应用程序，并且感觉维护已变得被动，只有在发生故障时才进行更改，那么在成本突然出现之前构建此例程是值得的。我的博客上还有其他关于软件维护、移动和产品运营的文章，我可以与那些每天维护此类产品的人交流想法。