项目中为什么选择使用 View 而非 Fragment？已知该项目通过 Map 实现 View 缓存、模拟 Activity 栈实现回退功能，同时需要处理 View 的连续点击 / 多次点击问题，以及连续点击 View 导致缓存膨胀引发的 OOM 问题，请谈谈该技术选型的考量
在Android项目开发中，选择View而非Fragment作为核心页面载体，并非是对Fragment功能的否定，而是基于项目实际业务场景、性能需求以及技术实现成本的综合权衡，结合项目中已明确的View缓存、模拟Activity栈、防连续点击和OOM规避等配套方案，该选型具备极强的合理性和针对性，具体考量可从以下多个维度展开：
一、 核心选型底层逻辑：轻量化与性能最优解
Fragment作为Android提供的页面片段载体，其本身存在不可忽视的性能开销和生命周期复杂度。Fragment拥有一套完整且独立的生命周期，从onAttach、onCreate、onCreateView到onDestroyView、onDetach等，每个生命周期方法都需要与宿主Activity的生命周期进行联动同步，这种联动不仅会增加代码的耦合性，还会在页面切换时产生额外的系统调度开销。尤其是在高频页面切换的场景下，Fragment的生命周期回调频繁触发，可能会导致页面切换卡顿、响应延迟等问题。
而View作为Android界面的基础组成单元，其本质是可视化控件的抽象，不存在独立的生命周期，仅需依赖宿主Activity的生命周期进行视图的创建、绘制和销毁，整体轻量化程度更高。在页面切换时，View的切换本
