Kc's blog Kc's blog
首页
分类
标签
Timeline
收藏夹
关于
GitHub (opens new window)

kcqingfeng

前端小学生
首页
分类
标签
Timeline
收藏夹
关于
GitHub (opens new window)
  • 提前下班小妙招

  • node版本的切换

  • 面试

    • 面试问答
    • 面试随记
    • googleNotebooklm
    • 收藏
    • 面试
    kc_shen
    2026-04-07
    目录

    googleNotebooklm

    # 1. 新闻信息流广告变现平台 (H5)

    1. 广告混排设计:通过在信息流的数据数组中预设“插槽”逻辑,根据后台配置的间隔规则(如每 5 条新闻插 1 条广告)进行动态切片插入,确保 UI 渲染层与业务逻辑解耦 1。
    2. 兜底策略实现:开发了策略配置模块,当主广告位加载超时或无填充时,系统会自动触发 onError 回调并根据优先级权重逻辑切换到备用广告源(如从 A 联盟切换到 B 联盟),保证填充率 1, 2。
    3. IntersectionObserver 优势:相比滚动监听,它是由浏览器原生提供的异步监测目标元素与视口交叉状态的 API,性能极高,不会阻塞主线程,且能精准捕获“真实曝光” 2。
    4. 埋点 SDK 架构:包含初始化、事件捕获、数据格式化和异步上报四个模块。利用 navigator.sendBeacon 或图片统计方式确保用户在关闭页面时埋点也能成功上报 2。
    5. 激励计时防作弊:前端利用 Page Visibility API 监听切换后台行为,配合后端进行点击行为校验和频率限制,防止恶意刷奖励 2。
    6. 地域屏蔽策略:基于用户 IP 或 GPS 信息,在广告请求前通过策略模块判断该地区是否在屏蔽名单内,以满足联盟合规要求 2。
    7. 基础反作弊:通过记录点击坐标位移、点击频率间隔以及非法 User-Agent 识别,过滤掉大部分模拟器或脚本产生的异常点击 2。
    8. H5 性能优化:除了按需加载,还采用了 图片懒加载、资源压缩以及利用 Webpack 进行代码分割,减少首屏 JS 执行耗时 2。
    9. 技术栈选型:由于是移动端信息流,选择轻量级的 Zepto 配合 TS 能在保证开发严谨性的同时,减少基础库的体积,提升加载速度 1。
    10. 合规性确保:在 UI 上严格遵循各联盟要求的“广告”标识、关闭按钮位置及反馈机制,通过代码逻辑强制校验展示规范 2。

    # 2. 运营管理系统 & 合作商数据平台

    1. RBAC 权限实现:设计了页面、按钮、数据三层控制。页面和按钮通过路由守卫和自定义指令控制;数据权限则通过接口请求头携带角色标识,由后端配合过滤 2。
    2. 多租户隔离:在前端请求拦截器中自动注入“合作商唯一标识”,确保所有查询接口都具备租户上下文,从 UI 层面杜绝跨租户访问的可能性 2。
    3. 策略模式应用:将不同的收益计算公式(如按点击、按转化、按时长)封装成独立的类,通过策略映射表动态匹配,新业务接入只需新增策略类而无需修改主流程代码 3。
    4. 包体积下降 30%:通过 CDN 外链 引入 ElementUI 等重型库,配合 Vite 的 代码分割(Code Splitting) 和动态 import,将非核心资源从主包中剥离 3。
    5. Vite 配置细节:在 vite.config.ts 中配置 rollupOptions.external 将库排除,并利用 html-plugin 在模板中注入 CDN 链接 3。
    6. 通用表格组件:封装了基于配置项驱动的表格,支持 schema 配置列信息、排序规则和分页参数,统一了整个平台的交互体验 3。
    7. OSS 文件处理:利用 OSS SDK 实现前端直传,通过 分片上传 优化大文件体验,并利用签名链接实现报表的高速下载 3。
    8. 浮点数精度:财务核算中使用 Big.js 或将金额统一转为“分”进行整数运算,确保收益对账的绝对准确 2。
    9. Pinia 优势:Pinia 支持更好的 TS 类型推导和模块化拆分,在多租户场景下可以更清晰地维护各合作商的状态 2。
    10. 交互规范推动:通过封装通用组件库并编写内部文档,配合 AI 工具(如 Cursor) 生成标准化代码,降低了团队的沟通与复现成本 1, 3。

    # 3. AI 拓客碰碰贴 (微信小程序)

    1. 分包策略:将 AI 生成模块、商家看板、个人中心划分为独立子包,主包仅保留核心启动逻辑和公共组件,首屏加载显著提速 3。
    2. AI 调用封装层:设计了一个统一的接口协议层,屏蔽了底层文案生成与视频脚本生成的接口差异,实现了 AI 能力的高度复用 3。
    3. 数据看板可视化:使用小程序适配版的图表库,通过 Canvas 绘制曝光、点击等核心指标,为商家提供直观的数据支持 3。
    4. WebSocket 应用:由于 AI 生成较慢,建立长连接后后端可主动推送“生成中 30%”、“生成成功”等状态,避免用户频繁轮询请求 4。
    5. 体验补偿优化:在生成过程中加入趣味性的加载动画和进度提示,利用骨架屏减少视觉上的等待焦虑 4。
    6. 资源压缩策略:在上传物料前,利用小程序原生 API 对图片和视频进行预压缩,降低流量消耗并提升上传稳定性 4。
    7. 社交分享路径:利用小程序 onShareAppMessage 结合动态生成的分享参数,一键引导用户跳转社交平台,提高曝光 4。
    8. 架构扩展性:采用模块化设计,当后端 AI 模型升级时,只需在调用层更换参数或端点,不影响前端 UI 展示逻辑 3。
    9. 异常引导:针对 AI 敏感词过滤或生成失败,设计了明确的提示和重试机制,确保流程闭环 4。
    10. 流量优化:对视频素材采用按需加载和分段读取,降低不必要的数据传输流量 4。

    # 4. AI 灵宝 (微信小程序)

    1. UniApp 实践:利用 UniApp + Vue3 实现跨端代码复用,通过条件编译处理微信小程序特有的 Canvas 接口差异 4。
    2. Prompt 优化逻辑:前端维护一套关键词模板,将用户的简单描述与预设的风格词、光影词进行模板化拼接,显著提升生成质量 5。
    3. Canvas 预览实现:通过 Canvas 的 drawImage 功能将生成的 AI 图像按比例、位置叠加到衣服模版图层上,实现即时预览效果 5。
    4. 高清处理流程:生成成功后,用户可选择“超清处理”,前端请求后端增强接口并实时反馈状态,最终获取适合印刷的高清原图 5。
    5. 电商闭环:基于小程序支付 API 构建从创意生成到购物车、订单创建及微信支付的完整电商流程 5。
    6. 内存压力处理:对于大图处理,先在前端进行缩略图展示,仅在必要环节(如 Canvas 合成)才加载原图,防止小程序闪退 5。
    7. 状态实时推送:即使切换页面,WebSocket 依然在全局状态中运行,确保用户能随时收到 AI 生成结果的通知 5。
    8. 通用 UI 封装:设计了通用的 AI 任务卡片、进度条和订单列表组件,确保商城与 AI 模块风格统一 4。
    9. 下单转化分析:通过埋点数据发现,提供了 Canvas 实时预览功能后,用户的购买意向显著增强,下单率得到有效提升 5。
    10. 技术难点解决:对接 Text-to-Image 接口时,主要挑战在于复杂参数的映射与多状态的同步,我通过构建状态机简化了该逻辑 4。

    # 5. 互动式用户增长应用 (快应用)

    1. 快应用语法:核心是类似 Web 的 HTML/CSS/JS,但标签(如 div 对应 div,img 对应 image)和样式支持有差异,需注意其特有的生命周期 5。
    2. 果树状态机:通过对象维护果树的“幼苗、成长期、成熟、收获”等状态,配合后端同步机制,确保用户状态不丢失 5。
    3. CSS3 动画优化:利用 transform 和 opacity 进行动画,避免触发重排(Reflow),在多动画并行场景下开启硬件加速 6。
    4. IconFont 优势:将数百个小图标合并为一个字体文件,极大减少了网络请求次数并显著缩减了包体积 6。
    5. 交互性能:通过组件复用和状态局部更新,避免整个页面的全量渲染,保持 60 帧的流畅体验 6。
    6. 父子组件通信:快应用通过 props 向下传递数据,通过 $emit 向上触发事件,与 Vue 的理念非常接近 6。
    7. 广告插入时机:在用户完成“任务奖励”或“浇水”后的交互反馈瞬间展示插屏广告,符合用户心理预期,填充率高 5。
    8. 用户留存手段:利用签到激励、任务循环和阶段性奖励(兑现现金)构建完整的激励闭环,驱动日活增长 5。
    9. 性能监控:在关键生命周期打点,记录页面从 onInit 到渲染完成的耗时,针对慢页面进行专项优化 6。
    10. 提现安全:前端在请求提现接口前,对金额和用户状态进行预校验,并配合全局的 Token 校验确保交易安全 5。

    # 6. 猜歌乐园 (快应用)

    1. 厂商适配:通过环境常量判断当前厂商(华为、小米等),针对不同厂商的广告 API 差异编写适配器(Adapter) 6。
    2. 广告 SDK 设计:抽象出 loadAd、showAd、onClose 等统一接口,隐藏底层不同联盟的调用细节,实现跨项目复用 6。
    3. 调度规则:支持通过配置中心下发权重,前端 SDK 根据权重随机或按序选择广告联盟进行展示 6。
    4. Fallback 链路:当联盟 A 返回“无广告”时,SDK 内部立即触发联盟 B 的请求,直到找到可用资源或尝试完所有联盟,确保收益最大化 6。
    5. 兼容性 Bug:例如某些厂商在销毁广告实例后仍有回调,我通过在回调中增加实例存在性校验来解决该类崩溃问题 6。
    6. 埋点准确性:通过 adID 唯一标识每一笔广告请求,在曝光和点击时上报该 ID,确保后端统计 PV/UV/CTR 的准确 6, 7。
    7. IDE 局限:部分广告功能在模拟器无法运行,我通过真机远程调试和构建调试版包,结合日志上报来排查广告异常 6。
    8. 填充率提升:由于接入了多家联盟并实现自动切换,广告填充率从单一渠道的 70% 提升到了 95% 以上 6。
    9. 合规合规:根据各厂商最新政策,动态调整用户隐私协议弹窗和广告展示频次,确保应用不被下架 7。
    10. 架构独立性:作为负责人,我采用了微内核架构思路,将广告变现与猜歌逻辑分离,方便未来快速复用至其他互动应用 6。

    核心技巧总结:在面试回答时,尽量提及你如何使用 AI 工具(如 Cursor) 来辅助这些复杂逻辑的编写和重构 1,这会展现你极高的开发效率和对前沿工具的掌握能力。

    编辑 (opens new window)
    上次更新: 2026/04/07, 2:04:00
    面试随记

    ← 面试随记

    最近更新
    01
    面试随记
    04-07
    02
    claude安装终端代理
    04-06
    03
    Homebrew使用指南
    04-06
    更多文章>
    Theme by Vdoing | Copyright © 2019-2026 kc shen | MIT License 豫ICP备2024074563号-3
    • 跟随系统
    • 浅色模式
    • 深色模式
    • 阅读模式