• 制定并主导公司移动端 “React Native (RN) 为主，Flutter为辅，原生兜底” 的混合技术战略，设计了 “三层Bridge优化模型”（通用JS桥、高性能原生模块、定制化TurboModule），将核心业务的跨端通信性能提升300%，RN页面性能指标逼近原生。
• 从0到1架构了公司 “统一动态化容器”，完美融合RN业务包、H5微应用与原生组件，支持所有业务线的线上热更新与A/B测试，将需求发布周期从4周缩短至2天，年均支撑1000+ 次灰度发布，成为业务增长的核心引擎。
• 攻克的 “Flutter与Native混合栈内存与路由管理” 的难题，通过自定义的 “混合栈生命週期同步与内存回收” 机制，彻底解决了页面跳转闪退与内存泄漏，稳定性达99.99%。
• 搭建团队级别的跨平台开发效能中台，封装通用组件库，包括导航栏、弹窗、数据图表等，以及基于Flutter Test+CI/CD的自动化测试工具，使新人上手效率提升70%，需求交付周期从7天缩短至3天，支撑公司3个核心业务线快速上线和迭代。

• 主导公司核心产品从纯原生向RN+原生的架构演进，通过 “基础库下沉、Native模块化、JSBundle差分增量” 等一系列方案，保障了超大型应用平滑迁移，iOS/Android双端人力投入减少40%。
• 深度优化RN列表性能，通过自研 “沉浸式虚拟列表、视图复用池、预渲染技术”，在千条数据量下的复杂列表滚动FPS稳定60Hz，ANR率降至0.01%。
• 攻克复杂动画性能瓶颈，使原滑动卡顿率从2.1%优化到0.4%，基于Flutter Skia引擎研发动画渲染框架，支持200+粒子同时流畅渲染，使用户停留时长增加18分钟/日。
• 实现 “跨端错误监控与全链路追踪” 系统，无缝集成Sentry、APM与自有日志平台，实现了从JS到Native错误的分钟级自动归因与告警，MTTR缩短80%。

邻趣生活App全链路性能优化工程

• 邻趣生活作为本地生活综合服务平台，用户量突破5000万后，核心场景性能瓶颈凸显——Android冷启动耗时3.2秒、iOS达3.0秒，首页列表滑动帧率低于55fps，订单详情页加载延迟2.8秒，直接导致次留下降8%。我作为移动端技术负责人，主导全链路性能优化项目，统筹Android、iOS双端及前端团队，目标将核心场景指标提升至行业优秀水平（启动≤2秒、帧率≥60fps、加载≤1.5秒），支撑用户增长与体验留存。
• 项目面临三大技术难点：①Android端第三方SDK（支付、定位）同步初始化占用启动耗时45%；②iOS端自定义订单Cell因离屏渲染+主线程图片解码引发滑动卡顿；③跨端缓存策略割裂，重复请求率达30%。我通过Systrace定位Android启动耗时链路，发现SDK在Application层同步初始化的问题；用Instruments Time Profiler捕获iOS Cell渲染时的YYLabel离屏渲染及SDWebImage同步解码瓶颈；跨端缓存因双端无统一失效机制，导致数据重复拉取。
• 我推动的针对性解决方案：Android侧将第三方SDK改为异步+懒加载，结合DexClassLoader预加载高频工具类，减少Class.forName反射耗时；iOS侧重构订单Cell，用Core Graphics替代离屏渲染，将图片解码移至后台线程，同时替换MJExtension为YYModel减少JSON解析时间30%；跨端设计统一缓存层，基于Redis存储核心数据，双端通过Retrofit（Android）和AFNetworking同步缓存过期策略，将重复请求率压降至5%以内。
• 项目上线后，Android冷启动耗时降至1.8秒、iOS1.6秒，首页滑动帧率稳定在60fps以上，订单详情页加载时间缩短至1.2秒；次留回升至优化前的92%，日活较优化前提升12%（约600万）。我主导了全链路方案设计与跨端协同，推动性能指标进入行业Top 10%，成为公司用户体验的核心壁垒。

多业务场景订单系统移动端重构

• 随着邻趣生活从单一外卖扩展到到店、酒店、生鲜等多场景，老订单系统因基于单一业务设计，出现严重耦合——代码冗余度达40%，新业务需求（如酒店订单房态同步、到店订单核销）需修改核心代码，每月因订单逻辑bug导致客诉超200单。我作为移动端核心开发，负责订单系统重构，目标打造支持多业务扩展的通用架构，降低维护成本，减少客诉。
• 重构面临两大关键挑战：①老系统订单状态机混乱，不同业务状态流转冲突（如外卖“配送中”与酒店“入住中”逻辑互斥）；②1亿+老订单数据迁移，需保证迁移中数据一致性与业务可用性。此外，双端原有订单模块接口适配成本高，易出现数据不一致。
• 我主导Clean Architecture分层设计：将订单模块拆分为Presentation（UI交互）、Domain（核心逻辑，含通用状态机、订单模型）、Data（数据层对接后端与缓存）三层。Domain层定义抽象OrderStateMachine接口，不同业务通过Impl实现具体状态流转（如外卖Impl处理配送、酒店Impl处理房态）；数据层用Protocol Buffers定义跨端订单协议，减少序列化开销；数据迁移采用“增量同步+全量校验”策略——新订单实时写入新系统，老订单分批次迁移，通过MD5校验双端数据一致性，确保零丢失。
• 重构后，订单模块代码冗余度降至15%，新业务迭代时间从7天缩短至3天，客诉率下降70%（每月不足60单）；数据迁移成功率99.99%，无重大数据事故。我解决了多业务扩展的核心架构问题，该架构至今支撑公司80%以上订单业务，成为多场景拓展的基础能力。

• 大二观察到毕业生离校时大量教材被废弃，而新生购书支出占生活费12%，便发起校园书籍教材循环计划。为解决传统二手书交易效率低的问题，我们开发微信小程序实现扫码估价、预约取件功能，并说服快递中心以成本价承接物流。
• 通过建立翻新消毒标准打消卫生顾虑，项目年流通教材1.2万册，累计为同学节省书费38万元。这段经历让我从商业小白成长为能设计闭环模式的实践者，项目不仅获省级创业金奖，更被纳入学校官方服务体系延续至今。