混合开发（Hybrid）是移动应用的一种常见架构：用原生做外壳和底层能力，用Web技术（H5）做页面和业务。它的价值在于「动态更新、多端复用」，代价是性能与体验。理解这套架构的组成与协作方式，才能判断它适不适合你的业务。在成都做这类项目，最容易出问题的往往不是页面本身，而是容器与桥接的稳定性。
混合应用通常由三层组成：原生容器层、Web页面层、桥接层。
原生容器负责应用生命周期、权限、系统能力调用；Web页面层负责界面和业务逻辑；桥接层负责两者之间的通信。
三层配合，才构成一个「能跑、能用、能更新」的混合应用。任何一层设计不好，整体体验都会打折。
容器是混合应用的「地基」。它负责启动、加载Web页面、管理页面栈、处理返回、调用系统能力。
常见实现有系统WebView、自研容器、或跨平台框架自带的容器。不同实现，性能和支持的能力不同。
容器还要处理「安全」：域名白名单、JS注入防护、权限控制。容器不稳，上层再好的页面也白搭。
页面层是用户看到的部分，用HTML/CSS/JS（或Vue/React等框架）实现。它的优势是「改一次、全端生效」。
页面层要处理「适配」：不同屏幕、不同系统、不同容器的差异。不处理，页面就会「这端好、那端乱」。
性能是页面层的软肋：长列表、复杂动画、频繁DOM操作都会卡。要用虚拟列表、离屏渲染、节流等技术优化。
桥接是原生与Web通信的通道。Web调用原生能力（相机、支付、定位），原生把结果回传给Web。
桥接的设计影响性能和稳定性：调用太多、太频繁，会拖慢；桥接失败没有兜底，功能就不可用。
实践中要「减少桥接、批量调用、异步处理」，还要有「失败降级」。桥接做得好，混合应用才「像原生」。
混合应用的一大优势是「动态更新」：页面改动只需更新服务端资源包，用户无需重新下载App。成都一些项目上线后才暴露出缓存与更新机制没设计好，返工成本很高。
更新机制要设计「版本管理、增量更新、回滚」。更新出错能退回，才敢频繁发版。
但动态更新有「合规边界」：不能借更新绕过应用市场审核，发布重大功能变更。这一点必须守住。
首屏速度：预加载、骨架屏、资源缓存，避免「白屏转圈」。
滚动流畅：虚拟列表、图片懒加载、减少重排重绘。
交互响应：减少桥接次数、异步处理、避免长任务阻塞主线程。
内存管理：及时释放资源、避免内存泄漏，否则长时间使用会卡顿甚至崩溃。
误区一：以为「混合就是套个WebView」。真正的混合架构要处理桥接、缓存、更新、降级，套个WebView只是「能显示网页」，离「能用」还差很远。
误区二：把所有页面都做成Web。核心页（首页、支付、用户中心）用Web会明显拖慢体验，更合理的做法是「核心原生、内容Web」。
误区三：忽视离线与弱网。H5页面依赖网络，弱网时会白屏。要做本地缓存、骨架屏、失败重试。
实践建议：先从「一个页面」试水，验证容器、桥接、更新的稳定性，再逐步扩大；同时把「性能预算」定下来（首屏多久、帧率多少），作为验收标准。
适合：内容型、营销型、频繁改版的页面，以及需要多端复用的业务。
不适合：重度游戏、实时音视频、复杂动画、深度硬件交互。这些场景，原生更合适。
成熟的做法是「混合分层」：核心功能原生、内容页面Web，各取所长。架构不是「二选一」，而是「组合」。对成都的团队来说，先把「一个页面」跑通、再谈全面混合，是更稳的路径。
