3 篇博文 含有标签「mobile」

大多数构建端侧 LLM 功能的工程师，将时间花在解决那些显而易见的问题上：量化、延迟、内存限制。模型能装进手机，推理速度够快，演示效果也很好看。然后他们向数百万台设备发布，才发现一个更难的问题——从来没人提前告诉他们：你现在有数百万个独立的计算节点，运行着你 AI 模型的不同版本，而你根本没有可靠的方式知道任何一个用户运行的是哪个版本。

云端推理在最好的意义上是无聊的。你更新模型，重新部署服务器，几分钟内整个用户群就都在运行新版本了。端侧推理则彻底打破了这个假设。一个三个月前最后一次打开你应用的用户，仍在运行那时当前的模型——而且没有干净的方法强制更新，没有服务器端回滚，也没有简单的方法在没有你从一开始就构建的监控埋点的情况下检测到版本不匹配。

这种版本碎片化是端侧 AI 的核心运营挑战，其后果远不止缓慢的发布。它造成无声的能力漂移，使事故响应复杂化，并将你的"AI 功能"变成一个由独立运行的异构系统组成的庞大集群——你对其负责，却无法直接控制。

大多数团队决定使用端侧 LLM 推理的方式，就像他们决定重写数据库时一样：冲动行事，仅仅是为了应对原本可以用更廉价方案解决的问题。推介词总是令人心动——无需网络往返、完全隐私、零推理成本——而且初始原型也验证了这一点。然而，在发布六个月后，模型开始悄无声息地输出更差的结果，新的操作系统更新打破了量化兼容性，而那些使用廉价安卓手机的用户正在运行一个你无法推送更新的版本。

本指南旨在让你在看清现实的情况下做出决策。在特定场景下，端侧推理确实是正确的选择，但其成本结构与团队预期的不同，且生产环境中的失效模式与云端 LLM 部署几乎完全不同。

我们为什么要在架构上费心思？​

答案是：为了减少在每做一个功能的时候所耗费的人力资源。

移动开发人员会在以下三个层面上评估一个架构的好坏：

1. 各个功能分区的职责分配是否均衡
2. 是否具有易测试性
3. 是否易于使用和维护

	职责分配的均衡性	易测试性	易用性
紧耦合MVC	❌	❌	✅
Cocoa MVC	❌ V和C是耦合的	❌	✅⭐
MVP	✅ 独立的视图生命周期	✅	一般：代码较多
MVVM	✅	一般：视图（View）存在对UIKit的依赖	一般
VIPER	✅⭐️	✅⭐️	❌

紧耦合MVC​

举一个例子，在一个多页面的网页Web应用程序中，当你点击一个链接导航至其他页面的时候，该页面就会被全部重新加载。该架构的问题在于视图（View）与控制器（Controller）和模型（Model）是紧密耦合的。

Cocoa MVC​

Cocoa MVC 是苹果公司建议iOS开发者使用的架构。理论上来说，该架构可以通过控制器（Controller）将模型（Model）与视图（View）剥离开。

然而，在实际操作过程中，Cocoa MVC 鼓励大规模视图控制器的使用，最终使得视图控制器完成所有操作。

尽管测试这样的耦合大规模视图控制器是十分困难的，然而在开发速度方面，Cocoa MVC是现有的这些选择里面表现最好的。

MVP​

在MVP中，Presenter与视图控制器（view controller）的生命周期没有任何关系，视图可以很轻易地被取代。我们可以认为UIViewController实际上就是视图（View）。

还有另外一种类型的MVP：带有数据绑定的MVP。如下图所示，视图（View）与模型（Model）和控制器（Controller）是紧密耦合的。

MVVM​

MVVM与MVP相似不过MVVM绑定的是视图（View）与视图模型（View Model）。

VIPER​

不同于MV(X)的三层结构，VIPER具有五层结构（VIPER View, Interactor, Presenter, Entity, 和 Routing）。这样的结构可以很好地进行职责分配但是其维护性较差。

相较于MV(X)，VIPER有下列不同点：

1. Model 的逻辑处理转移到了 Interactor 上，这样一来，Entities 没有逻辑，只是纯粹的保存数据的结构。
2. ==UI相关的业务逻辑分在Presenter中，数据修改功能分在Interactor中==。
3. VIPER为实现模块间的跳转功能引入了路由模块 Router 。