猿急送>

北京Android兼职程序员

ID：243104

小高的窝

Android高级开发工程师

公司信息：
北京天源迪科有限公司

工作经验：
3年

兼职日薪：
800元/8小时

兼职时间：
下班后
周六
周日

所在区域：
北京
昌平

技术能力

作为一名高级Android开发工程师，我具备以下技术能力：

核心技术能力
语言与框架：精通 Kotlin 和 Java，深入理解协程、Flow 及 Jetpack 全家桶（Lifecycle、ViewModel、Room、Paging、Hilt）。熟悉跨端方案（Flutter/Compose Multiplatform）。

架构设计：精通 MVVM/MVI 模式，擅长使用 Clean Architecture 构建高内聚低耦合的模块化项目。能根据业务场景设计 Repository 层，统一管理本地缓存与远程数据源，提升代码可测试性与可维护性。

性能与稳定性
性能优化专家：掌握 Systrace、Perfetto 等工具，解决启动耗时、页面卡顿（ANR）、内存泄漏及过度绘制问题。

包体积控制：擅长通过资源混淆、AndResGuard、动态交付等手段缩减包体大小。

稳定性治理：建立 Crash 监控体系（集成 Firebase/ Sentry），具备 Native Crash 分析能力（Breakpad / addr2line）。

工程化与协作
基建能力：搭建组件化开发环境，维护私有 Maven 仓库，编写 Gradle 插件优化构建速度（缓存、增量编译）。

质量保障：推行 Code Review 规范，编写单元测试（JUnit/Mockito）与 UI 自动化测试（Espresso），确保迭代质量。

软实力
具备良好的产品思维，善于在技术与业务间找到最佳平衡点，主导过日活千万级应用的架构升级与重构工作，能有效指导初中级工程师成长。

作为您的技术顾问，我能提供从 0-1 架构设计、疑难问题攻关到团队技术壁垒突破的全方位支撑，助力您的产品以高质量、高性能的状态触达用户。

项目经验

项目一：秀场直播弹幕系统设计与WebSocket长连接优化
项目背景：
该秀场直播App日活约数万人，高峰时段单个热门直播间同时在线人数可达数百人。原有弹幕功能采用轮询方式从服务端拉取消息，不仅延迟高（约2~3秒），而且频繁的网络请求对手机电量和流量消耗较大。用户普遍反映“弹幕滞后严重，互动感差”，同时客服也收到部分用户反馈“直播过程中偶尔断流，消息发不出去”。

我的职责与技术方案：
我主导了弹幕系统从轮询到长连接的全面改造。首先引入 WebSocket 作为消息传输的主通道，替代原有的HTTP轮询机制，与服务端约定基于 JSON 格式的私有协议进行消息收发。针对直播间内的弹幕、点赞、礼物等不同类型的消息，我在协议层设计了消息类型字段（type）进行区分，并按照业务优先级将消息划分为高优（礼物/系统通知）和普通（弹幕/点赞）两个队列，高优消息在客户端侧优先处理。

在弹幕渲染方面，我采用 RecyclerView 作为弹幕列表的容器，配合 DiffUtil 进行增量更新，避免每次收到新消息时全量刷新列表导致的闪烁和性能浪费。对于短时间内大量弹幕涌入的场景（如主播互动高潮时刻），我引入了消息采样策略 ——每秒最多展示15条弹幕，超出部分仅做本地计数累加，后续通过“XXX等XX人点赞”的聚合文案进行展示，既保留了互动氛围，又避免了主线程过度繁忙。此外，我还实现了一套弹幕飘屏效果，利用自定义ViewGroup配合属性动画，在视频画面上方以多轨道形式滚动展示精选弹幕，增强直播间热闹感。

在WebSocket连接的稳定性方面，我设计了自动重连机制，在网络短暂断开或服务端主动关闭连接时，采用指数退避策略（间隔逐渐拉长）进行重试，避免无效的重连请求对服务端造成压力。同时，我在应用生命周期回调（onPause/onResume）中合理控制WebSocket的收发状态——切到后台时暂停非关键消息的UI渲染，回到前台时快速恢复，降低不必要的CPU消耗。

项目成果：
弹幕消息延迟从原来的2~3秒降低至 300ms以内，用户互动感明显增强；直播间内因网络切换导致的断流重连成功率提升至 95%以上，相关客诉大幅减少。弹幕列表的滑动帧率稳定在 55fps以上，主流中低端机型（如骁龙660）上测试通过，用户反馈良好。

项目二：语音厅IM即时通信与WebSocket消息分发中间层
项目背景：
语音厅业务上线后，单房间同时在线用户约200~300人，除了基础的语音通话，用户还需要发送文字消息、点亮、送花等互动行为。当时我们集成了第三方IM SDK，但SDK在消息优先级控制、离线消息拉取和多端同步方面的表现不够灵活，无法满足业务对“系统公告必达”、“礼物消息突出展示”等差异化需求。

我的职责与技术方案：
为解决上述问题，我在第三方IM SDK之上封装了一层消息分发中间件，同时独立维护一路 WebSocket长连接用于承载业务信令数据（如上麦/下麦、房间设置变更等），与IM SDK的消息通道形成互补。具体设计如下：

双通道协同：IM SDK负责普通聊天消息的收发和本地历史记录缓存；自建的WebSocket通道负责实时性要求更高的业务信令。两者通过统一的消息总线（EventBus）向下游UI层分发，UI层无需关心消息来源，只需根据消息类型做对应的渲染。

消息优先级与采样：在中间件层，我将消息分为高敏（礼物、系统公告、上麦通知）、中敏（点亮、关注）、低敏（普通聊天）三类。高敏消息实时分发并触发UI刷新；中敏消息采用聚合机制，例如将1秒内收到的所有“点亮”合并为一次更新，显示为“XXX送出了X个点亮”；低敏消息则限制每秒最多展示10条，超出部分自动丢弃，但会在本地保留计数用于后续展示“X条新消息”提示。

离线消息与状态恢复：当用户因网络原因断开连接后重新进入房间，中间件会向服务端请求离线期间的消息摘要（只拉取最新的50条高敏消息和200条普通消息），避免全量拉取对带宽的浪费，同时快速恢复房间状态。

协议设计与编解码：WebSocket传输采用 Protobuf 替代JSON，减小数据包体积，降低传输耗时。我在客户端封装了统一的编解码工具类，便于多模块复用。

此外，针对WebSocket连接的生命周期管理，我结合Android Lifecycle 组件，将WebSocket的启停与页面的可见性绑定，在页面销毁时主动释放连接资源，避免内存泄漏。同时利用 WorkManager 在后台定期发送心跳包（间隔30秒），维持长连接的存活。

项目成果：
消息分发中间层上线后，语音厅内各类消息的处理更加有序，礼物流和系统公告的到达率和展示成功率均达到 99.5%以上；

案例展示

花椒直播

花椒直播项目旗下有一款元气项目，之前上线过，后来下架了。从0到1接手开发。参与技术设计、方案实现、难点攻克等阶段。
小象超市app

小象超市app，也叫“美团买菜”、“小象生鲜”，这是美团旗下的一款线上生鲜超市手机应用，在这里用户可以品尝购买到全球新鲜水果、海鲜、蔬菜等等食物，成分由专业质检团队控制，每一道环节都进行最严格的筛选，保障生鲜健康与美味。
小象超市app

小象超市app，也叫“美团买菜”、“小象生鲜”，这是美团旗下的一款线上生鲜超市手机应用，在这里用户可以品尝购买到全球新鲜水果、海鲜、蔬菜等等食物，成分由专业质检团队控制，每一道环节都进行最严格的筛选，保障生鲜健康与美味。