做APP和小程序项目的人几乎都会在某个阶段被信息收集这四个字绊一下。有人是接了新项目要写立项报告有人是要给小程序做备案备注、填类目和说明有人是要评估一个现成产品值不值得抄作业或者对标还有人单纯是想知道自己手上这个包到底装了什么、拿了哪些权限、调了哪些域名。这些场景看起来差得远但底层动作其实是同一件事把一个APP或者小程序当成一个待分析的对象从公开层、资质层、技术层、数据层四个方向把信息扒清楚、记下来、结构化。我做过不少这类活儿从早期的安卓原生包到现在的各种跨端方案从最简单的展示型小程序到带蓝牙外设、带支付、带积分后台的复合型产品踩过的坑基本能凑成一本小册子。这篇东西就是把这套流程拆开讲清楚。不管你是刚入行的开发者、做产品调研的运营、负责合规自查的负责人还是想接私活报价前先摸个底的自由职业者都能从中找到能直接抄的部分。我会按先定框架、再抓公开信息、再进技术层、最后落表格的顺序走中间夹一些我自己的实操心得和踩坑记录。1. 先把信息收集这件事的边界画清楚1.1 为什么APP和小程序不能用同一套收集模板很多人一上手就想找一份万能表格APP、小程序、H5、快应用全往里套。实测下来这是最容易返工的做法。APP和小程序在信息形态上有本质差异最典型的就是分发渠道和包体形态这两块。APP的信息大头在发布渠道和应用商店页面上你能看到版本号、更新时间、权限清单、隐私政策链接、开发者主体、下载量区间、评论内容这些字段相对稳定抓取方式也比较统一。而小程序的信息大头在自己的后台和平台侧的展示信息里前台能看到的只有名称、主体、类目、简介、部分权限声明代码包本身是分包加异步加载的你下载下来看到的往往只是主包。更麻烦的是小程序是活的。行业里常说的小程序动态设置标题就是一个典型例子同一个页面在不同入口、不同登录态下导航栏标题可能是完全不同的。你按静态页面记录的信息第二天可能就对不上了。所以小程序的信息收集必须带时间戳和触发条件否则数据没有复现价值。我自己的做法是准备两套模板字段交集部分主体、类目、核心功能、联系方式统一差异部分各留各的字段组。APP侧重包体、权限、渠道覆盖小程序侧重页面路径、入口来源、动态配置项。1.2 五层信息框架经过多次整理我最后固定下来的是五层框架从外到内依次是层级收集内容主要来源更新频率L1 主体与资质开发者名称、主体类型、备案信息、类目平台展示页、备案公示信息低L2 产品与业务核心功能、目标人群、商业模式、竞品关系商店描述、小程序简介、体验流程中L3 技术形态技术栈、跨端框架、包体结构、渲染方式包体分析、运行时观察中L4 运行配置导航栏、字体、主题、动态标题规则、页面路径真机体验、配置项观察高L5 数据与接口请求域名、字段结构、登录态机制授权范围内的接口观测高这张表最大的价值在于给你一个停止条件。信息收集最容易失控——你以为再看一个页面就够了结果越看越多。有了分层你就能明确说我这次只做到L3剩下的下次再说。1.3 不同角色该重点看什么同一份信息不同人关心的点完全不同硬要一份全量报告只会浪费双方时间。产品经理更该盯L2和L4。竞品的功能拆解、页面流转、文案策略这些直接决定你的需求文档怎么写。我见过有团队花两周分析竞品的技术栈结果自家功能设计还是拍脑袋这就本末倒置了。开发同学重点在L3和L5。你关心的是对方用了什么跨端方案、有没有用原生混合渲染、接口粒度的粗细、登录态怎么维护。实话说如果对方用的是uni-app这类常见方案你能从包体结构里看出来一些线索这对评估工期很有帮助。做合规自查或者备案的同学重点全在L1。尤其是给小程序填备案备注信息的时候很多人的卡点不是不会填而是不知道该写多细。我的经验是备注写业务实际动作不要写行业套话。比如做商城小程序与其写提供商品展示与交易服务不如写清用户浏览商品、加入购物车、下单支付、查询物流这个链路审核侧看得明白返工率低。运营和市场侧关注L2里的评价数据、评分变化、版本节点这些能反推对方的迭代节奏和用户口碑拐点很有参考价值。2. 公开渠道能拿到的信息比你想的多2.1 应用商店字段逐项拆解应用商店页面看起来就是一个介绍页实际上是个信息富矿。我习惯把每个商店的字段拆成三类记录结构化字段包名、版本号、更新日期、文件大小、下载量区间、开发者、隐私政策URL、权限清单。这类可以直接抄进表格不需要加工。半结构化字段应用介绍、更新日志、特色功能列表。这类需要你自己提取关键点比如从更新日志里判断对方最近在补哪个方向的能力。非结构化字段用户评论、评分分布、开发者回复。这类量最大价值也最不平均需要做筛选。关于权限清单有个细节值得说同一版本在不同商店上报的权限列表可能不一致有的商店会做聚合展示有的会把可选项也列进去。所以如果要写进正式报告以真机安装后的实际申请权限为准商店列表只作为参考。还有个老生常谈但总有人踩的坑不同商店的版本更新时间有延迟尤其是安卓侧经常出现A商店显示3天前更新、B商店还是一周前的版本。做竞品版本跟踪的时候务必以同一个商店为基准连续记录否则做出来的迭代频率曲线完全是噪音。2.2 小程序侧的公开信息入口微信小程序的公开信息相对克制但也不是没有。名称、主体、类目、部分服务声明、隐私协议入口这些在小程序资料页都能看到。关键是主体验证——很多小程序名称高度相似你不核对主体很容易把两个不同公司的产品记成同一个。我的做法是建一个主体-产品映射表用统一社会信用代码或者主体全称作为主键产品名称作为属性。这样即使对方改了小程序名称历史数据也不会断。这个习惯是从一次翻车经历里学来的我追踪的一个小程序半年内改了三次名字早期记录全是用名称做的索引最后对不上号白干。另外小程序的功能类目会影响到它能不能用某些能力。做调研时如果发现某个功能对方没做先别急着下结论说对方产品设计有问题很可能只是类目没开。2.3 备案与备注信息的填写实操这部分是问得最多的。小程序备案备注信息怎么填核心就三条原则第一写业务实质不写技术实现。审核侧关心的是你用它干什么不是你用什么框架写的。第二覆盖完整链路。如果小程序包含支付就明确写支付环节如果有用户内容发布就写明内容类型和管理方式。含糊的表述很容易被要求补充说明。第三与类目保持一致。你选的类目和备注描述对不上是最常见的退回原因。我整理过一个简化的填写对照按业务类型分业务类型备注重点描述容易漏的点电商商城商品浏览、下单、支付、售后是否含分销、是否含虚拟商品工具类具体工具功能、是否需要登录是否采集位置、通讯录内容展示内容类型、来源、审核机制用户评论、投稿功能会员积分积分获取与消耗路径是否涉及线下核销预约服务预约对象、时间段、取消规则是否含支付定金表格里的容易漏的点是我从实际退回记录里剪出来的比正文描述更容易被忽略。2.4 版本迭代与评论数据的整理版本数据的价值在趋势不在单点。个人建议至少连续记录12次更新才能看出节奏。记录时除版本号和日期我还会加两列更新类型功能新增/性能优化/Bug修复/合规适配和我的判断依据。第二列非常重要因为半年后你回看如果不写依据根本想不起来当时为什么这么分类。评论数据的坑更多。商店评论有大量无效内容刷的、情绪宣泄的、跟产品无关的都有。我一般做三层过滤先按长度过滤掉过短的再按关键词过滤掉明显广告最后人工扫一遍前200条。真正有价值的是带具体场景的差评这类内容能直接指出产品的薄弱环节。提示评论抓取和整理时只做内部参考使用不要在对外材料里原样引用他人评论内容。3. 技术侧信息收集从包体结构到接口清单3.1 安装包与小程序包的结构观察安卓安装包本质是个压缩容器解压后能看到资源目录、原生库目录、清单文件等。对信息收集来说值钱的主要是资源目录里的图片、配置文件和原生库文件名。原生库的名字经常能透露出对方用了什么引擎或者第三方能力比如音视频、地图、推送。这里必须强调一句所有分析都应在获得授权的前提下进行对自己负责的产品、对已获许可的竞品样本或者使用官方开放的分析工具。未经授权的逆向操作有法律风险也违背基本的职业操守。小程序包的形态更碎。主包加分包的结构决定了你一次只能看到一部分很多逻辑在分包里按需加载。所以小程序的结构观察更适合记录页面路径清单和分包划分方式后者能反映对方的模块划分思路。如果一个商城小程序的商品详情和订单页被分在同一个分包里说明对方是按业务链路分的如果按功能类型分那就是另一种架构观。3.2 运行时配置标题、导航栏、字体这些细节这几项看着小但对做UI还原和二次开发的人特别重要。微信小程序顶部导航栏高度是绕不开的。默认情况下导航栏高度由状态栏高度加标题栏高度组成而状态栏高度在不同机型上不一样所以正确做法是拿系统信息里的状态栏高度去算而不是写死一个数字。我见过有人直接写44像素在部分机型上标题会偏。小程序头部标题的处理方式有三种常见形态全局配置里统一设置、单页面配置里覆盖、以及运行时通过接口动态修改。第三种就是热词里说的小程序动态设置标题典型用法是商品详情页把标题设成商品名聊天页把标题设成对方昵称。做信息收集时如果对方用了动态标题你记录页面名称就不能只记标题要记页面路径。字体设置同理。APP侧的字体设置通常有全局主题、页面级覆盖、富文本内联样式三层小程序侧主要是全局和页面级。收集这一项的时候我一般只记录是否支持用户自定义字号和是否存在主题切换细节样式不深挖性价比不高。3.3 网络请求与接口清单的整理原则接口信息是最敏感也最需要克制的一块。合规的做法是在获得明确授权的测试环境中观察自己产品的请求整理出域名清单、请求方法、字段结构、登录态字段名。这些信息用于内部文档、性能优化、安全自查都是正当的。经常有人问为什么常规分析手段会失败。原因通常有几类一是客户端做了证书校验普通方式看不到内容二是请求体做了签名参数被加密三是用了双向校验。这些机制本身是产品的安全设计遇到这类情况正确的做法是走官方渠道找接口文档或者联系对方商务而不是想办法绕。绕过去既有法律风险也很难维护。接口清单我一般记这几列域名、路径、请求方法、是否需要登录态、关键字段、用途推测、采集时间。最后一列必须有因为接口会变。3.4 跨端框架带来的信息差异技术栈不同能收集到的信息颗粒度也不同。原生安卓工程比如用Android Studio从零建的结构规范资源命名通常有规律容易看出模块划分。用Django这类后端框架建的工程能看出的主要是路由和应用的划分思路对理解产品的后端组织方式有帮助但和客户端信息基本无关。跨端方案里uni-app和类似方案的项目配置文件的组织方式比较有辨识度页面路由集中管理收集路径清单很方便。用开发工具直接发行到小程序平台的流程也会在目录结构里留下痕迹。游戏类小程序另说包体大、资源多收集重点应该放在资源加载策略和分包上而不是页面路径。带硬件交互的产品比如蓝牙控制类的APP信息收集要额外加两块一是蓝牙相关权限和协议声明二是设备配对的流程节点。这类产品的信息如果漏了配对流程等于没收集。4. 把零散信息变成可用的表格4.1 字段设计信息收集做多了就会发现真正的瓶颈不是采不到而是采回来对不上。所以字段设计要提前想清楚。我目前用的基础字段集是这样的可以按需裁剪product: name: 产品名称 alias: 别名历史 subject: 开发主体全称 subject_code: 统一社会信用代码 platform: [android, ios, wechat_mini, alipay_mini] category: 类目 status: 在架/下架 tech: framework: 推测技术栈 package_name: 包名或appid sub_package_count: 分包数 min_version_supported: 最低支持版本 runtime: nav_height_rule: 导航栏高度计算方式 title_mode: 静态/动态 font_customizable: 是否支持自定义字号 login_required: 是否强制登录 data: domains: 域名列表 auth_field: 登录态字段名 collect_time: 采集时间这份结构的好处是分层清晰导出成表格后每层一列组不会全挤在一起。4.2 清洗、去重与版本管理采集回来的第一版永远是不能直接用的。我的清洗顺序是先统一主体名称同一家公司可能有多个写法再合并重复条目按包名或appid判重然后补全缺失字段最后标注置信度。置信度这一列很多人不加我觉得挺可惜。信息收集的结果天然有推测成分比如推测技术栈就是猜的。标上高/中/低三档看报告的人心里有数你自己半年后翻出来也不会把猜测当事实。版本管理就更简单了每次采集存一份带日期的快照不要覆盖。用简单的目录加日期命名就够了别一上来就搞复杂的系统。4.3 采集流程的自动化骨架如果只是十几个产品的调研纯手工没问题。上到几十上百个就得考虑半自动化。我一般写个小脚本处理重复度最高的部分比如从商店页面提取结构化字段、批量比对版本号变化。import csv from datetime import date def load_snapshot(path): with open(path, encodingutf-8) as f: return {row[package_name]: row for row in csv.DictReader(f)} def diff_versions(old, new): changes [] for pkg, row in new.items(): prev old.get(pkg) if prev and prev[version] ! row[version]: changes.append({ package_name: pkg, from: prev[version], to: row[version], date: date.today().isoformat(), }) return changes这段代码没什么技术含量价值在于把版本变化这个动作固化下来。每次采集完跑一遍变更列表自动出来比人眼比对靠谱得多。注意自动化采集务必遵守目标平台的服务条款和robots约定只采集公开可见内容控制请求频率。5. 常见问题与排查实录5.1 高频问题速查表下面这些是我被问得最多、也最容易卡住新人的问题整理成表方便对照。现象常见原因处理思路商店版本与真机不一致商店缓存或灰度放量以真机为准记录采集时间小程序页面路径找不到页面在分包内按需加载走完整业务流程再记录标题记录后第二天变了用了动态标题记录路径而非标题标注触发条件导航栏在部分机型错位状态栏高度写死改为运行时计算接口分析拿不到内容存在校验或签名机制走官方文档或商务渠道不绕权限清单各商店不同展示策略差异以真机安装后的申请为准备注信息被退回描述与类目不符按业务链路重写不写套话主体名称对不上简称、曾用名、子公司建主体映射表用代码做主键5.2 几个踩过的坑第一个坑是过度采集。有次做竞品分析我一股脑收集了七八个维度最后写报告发现真正用上的只有三个剩下全是浪费。后来我改成一个规矩开采集前先写一句这份数据要回答什么问题答不出来的字段直接砍掉。第二个坑是把推测写成事实。早期报告里我写该产品使用某某框架后来被同行指出证据不足。从那以后凡是推测都加推测二字或者写清判断依据。第三个坑是忽略登录态带来的信息差异。很多产品在未登录和登录后展示的内容完全不同未登录时收集的页面清单可能只有登录后的一半。现在我固定两轮采集未登录一轮登录后一轮分别存快照。第四个坑是备注和类目脱节。有次帮人代填小程序备案备注写得很详细但类目选偏了来回改了三轮。后来的经验是先定类目再按类目能覆盖的能力范围去写备注顺序反过来能省很多时间。第五个坑是依赖单一渠道。早期我只从一家商店抓数据结果对方在另一家商店有完全不同的运营策略都没发现。现在至少覆盖两个渠道做交叉验证。最后一个心得是关于交付形态。信息收集的成果不要只给一张大表最好拆成速览页和明细页两层。速览页一屏看完关键结论明细页放着所有原始记录备查。看报告的人九成只会看速览页你把精力平均分配是浪费。这个习惯我坚持了好几年回访反馈基本都是正面的。后续如果要把这套流程沉淀下来我建议从主体映射表和变更日志这两样开始它们是最容易被复用、也最能省时间的两个资产。
APP与小程序信息收集全流程：公开信息、包体接口、备案备注与表格化
做APP和小程序项目的人几乎都会在某个阶段被信息收集这四个字绊一下。有人是接了新项目要写立项报告有人是要给小程序做备案备注、填类目和说明有人是要评估一个现成产品值不值得抄作业或者对标还有人单纯是想知道自己手上这个包到底装了什么、拿了哪些权限、调了哪些域名。这些场景看起来差得远但底层动作其实是同一件事把一个APP或者小程序当成一个待分析的对象从公开层、资质层、技术层、数据层四个方向把信息扒清楚、记下来、结构化。我做过不少这类活儿从早期的安卓原生包到现在的各种跨端方案从最简单的展示型小程序到带蓝牙外设、带支付、带积分后台的复合型产品踩过的坑基本能凑成一本小册子。这篇东西就是把这套流程拆开讲清楚。不管你是刚入行的开发者、做产品调研的运营、负责合规自查的负责人还是想接私活报价前先摸个底的自由职业者都能从中找到能直接抄的部分。我会按先定框架、再抓公开信息、再进技术层、最后落表格的顺序走中间夹一些我自己的实操心得和踩坑记录。1. 先把信息收集这件事的边界画清楚1.1 为什么APP和小程序不能用同一套收集模板很多人一上手就想找一份万能表格APP、小程序、H5、快应用全往里套。实测下来这是最容易返工的做法。APP和小程序在信息形态上有本质差异最典型的就是分发渠道和包体形态这两块。APP的信息大头在发布渠道和应用商店页面上你能看到版本号、更新时间、权限清单、隐私政策链接、开发者主体、下载量区间、评论内容这些字段相对稳定抓取方式也比较统一。而小程序的信息大头在自己的后台和平台侧的展示信息里前台能看到的只有名称、主体、类目、简介、部分权限声明代码包本身是分包加异步加载的你下载下来看到的往往只是主包。更麻烦的是小程序是活的。行业里常说的小程序动态设置标题就是一个典型例子同一个页面在不同入口、不同登录态下导航栏标题可能是完全不同的。你按静态页面记录的信息第二天可能就对不上了。所以小程序的信息收集必须带时间戳和触发条件否则数据没有复现价值。我自己的做法是准备两套模板字段交集部分主体、类目、核心功能、联系方式统一差异部分各留各的字段组。APP侧重包体、权限、渠道覆盖小程序侧重页面路径、入口来源、动态配置项。1.2 五层信息框架经过多次整理我最后固定下来的是五层框架从外到内依次是层级收集内容主要来源更新频率L1 主体与资质开发者名称、主体类型、备案信息、类目平台展示页、备案公示信息低L2 产品与业务核心功能、目标人群、商业模式、竞品关系商店描述、小程序简介、体验流程中L3 技术形态技术栈、跨端框架、包体结构、渲染方式包体分析、运行时观察中L4 运行配置导航栏、字体、主题、动态标题规则、页面路径真机体验、配置项观察高L5 数据与接口请求域名、字段结构、登录态机制授权范围内的接口观测高这张表最大的价值在于给你一个停止条件。信息收集最容易失控——你以为再看一个页面就够了结果越看越多。有了分层你就能明确说我这次只做到L3剩下的下次再说。1.3 不同角色该重点看什么同一份信息不同人关心的点完全不同硬要一份全量报告只会浪费双方时间。产品经理更该盯L2和L4。竞品的功能拆解、页面流转、文案策略这些直接决定你的需求文档怎么写。我见过有团队花两周分析竞品的技术栈结果自家功能设计还是拍脑袋这就本末倒置了。开发同学重点在L3和L5。你关心的是对方用了什么跨端方案、有没有用原生混合渲染、接口粒度的粗细、登录态怎么维护。实话说如果对方用的是uni-app这类常见方案你能从包体结构里看出来一些线索这对评估工期很有帮助。做合规自查或者备案的同学重点全在L1。尤其是给小程序填备案备注信息的时候很多人的卡点不是不会填而是不知道该写多细。我的经验是备注写业务实际动作不要写行业套话。比如做商城小程序与其写提供商品展示与交易服务不如写清用户浏览商品、加入购物车、下单支付、查询物流这个链路审核侧看得明白返工率低。运营和市场侧关注L2里的评价数据、评分变化、版本节点这些能反推对方的迭代节奏和用户口碑拐点很有参考价值。2. 公开渠道能拿到的信息比你想的多2.1 应用商店字段逐项拆解应用商店页面看起来就是一个介绍页实际上是个信息富矿。我习惯把每个商店的字段拆成三类记录结构化字段包名、版本号、更新日期、文件大小、下载量区间、开发者、隐私政策URL、权限清单。这类可以直接抄进表格不需要加工。半结构化字段应用介绍、更新日志、特色功能列表。这类需要你自己提取关键点比如从更新日志里判断对方最近在补哪个方向的能力。非结构化字段用户评论、评分分布、开发者回复。这类量最大价值也最不平均需要做筛选。关于权限清单有个细节值得说同一版本在不同商店上报的权限列表可能不一致有的商店会做聚合展示有的会把可选项也列进去。所以如果要写进正式报告以真机安装后的实际申请权限为准商店列表只作为参考。还有个老生常谈但总有人踩的坑不同商店的版本更新时间有延迟尤其是安卓侧经常出现A商店显示3天前更新、B商店还是一周前的版本。做竞品版本跟踪的时候务必以同一个商店为基准连续记录否则做出来的迭代频率曲线完全是噪音。2.2 小程序侧的公开信息入口微信小程序的公开信息相对克制但也不是没有。名称、主体、类目、部分服务声明、隐私协议入口这些在小程序资料页都能看到。关键是主体验证——很多小程序名称高度相似你不核对主体很容易把两个不同公司的产品记成同一个。我的做法是建一个主体-产品映射表用统一社会信用代码或者主体全称作为主键产品名称作为属性。这样即使对方改了小程序名称历史数据也不会断。这个习惯是从一次翻车经历里学来的我追踪的一个小程序半年内改了三次名字早期记录全是用名称做的索引最后对不上号白干。另外小程序的功能类目会影响到它能不能用某些能力。做调研时如果发现某个功能对方没做先别急着下结论说对方产品设计有问题很可能只是类目没开。2.3 备案与备注信息的填写实操这部分是问得最多的。小程序备案备注信息怎么填核心就三条原则第一写业务实质不写技术实现。审核侧关心的是你用它干什么不是你用什么框架写的。第二覆盖完整链路。如果小程序包含支付就明确写支付环节如果有用户内容发布就写明内容类型和管理方式。含糊的表述很容易被要求补充说明。第三与类目保持一致。你选的类目和备注描述对不上是最常见的退回原因。我整理过一个简化的填写对照按业务类型分业务类型备注重点描述容易漏的点电商商城商品浏览、下单、支付、售后是否含分销、是否含虚拟商品工具类具体工具功能、是否需要登录是否采集位置、通讯录内容展示内容类型、来源、审核机制用户评论、投稿功能会员积分积分获取与消耗路径是否涉及线下核销预约服务预约对象、时间段、取消规则是否含支付定金表格里的容易漏的点是我从实际退回记录里剪出来的比正文描述更容易被忽略。2.4 版本迭代与评论数据的整理版本数据的价值在趋势不在单点。个人建议至少连续记录12次更新才能看出节奏。记录时除版本号和日期我还会加两列更新类型功能新增/性能优化/Bug修复/合规适配和我的判断依据。第二列非常重要因为半年后你回看如果不写依据根本想不起来当时为什么这么分类。评论数据的坑更多。商店评论有大量无效内容刷的、情绪宣泄的、跟产品无关的都有。我一般做三层过滤先按长度过滤掉过短的再按关键词过滤掉明显广告最后人工扫一遍前200条。真正有价值的是带具体场景的差评这类内容能直接指出产品的薄弱环节。提示评论抓取和整理时只做内部参考使用不要在对外材料里原样引用他人评论内容。3. 技术侧信息收集从包体结构到接口清单3.1 安装包与小程序包的结构观察安卓安装包本质是个压缩容器解压后能看到资源目录、原生库目录、清单文件等。对信息收集来说值钱的主要是资源目录里的图片、配置文件和原生库文件名。原生库的名字经常能透露出对方用了什么引擎或者第三方能力比如音视频、地图、推送。这里必须强调一句所有分析都应在获得授权的前提下进行对自己负责的产品、对已获许可的竞品样本或者使用官方开放的分析工具。未经授权的逆向操作有法律风险也违背基本的职业操守。小程序包的形态更碎。主包加分包的结构决定了你一次只能看到一部分很多逻辑在分包里按需加载。所以小程序的结构观察更适合记录页面路径清单和分包划分方式后者能反映对方的模块划分思路。如果一个商城小程序的商品详情和订单页被分在同一个分包里说明对方是按业务链路分的如果按功能类型分那就是另一种架构观。3.2 运行时配置标题、导航栏、字体这些细节这几项看着小但对做UI还原和二次开发的人特别重要。微信小程序顶部导航栏高度是绕不开的。默认情况下导航栏高度由状态栏高度加标题栏高度组成而状态栏高度在不同机型上不一样所以正确做法是拿系统信息里的状态栏高度去算而不是写死一个数字。我见过有人直接写44像素在部分机型上标题会偏。小程序头部标题的处理方式有三种常见形态全局配置里统一设置、单页面配置里覆盖、以及运行时通过接口动态修改。第三种就是热词里说的小程序动态设置标题典型用法是商品详情页把标题设成商品名聊天页把标题设成对方昵称。做信息收集时如果对方用了动态标题你记录页面名称就不能只记标题要记页面路径。字体设置同理。APP侧的字体设置通常有全局主题、页面级覆盖、富文本内联样式三层小程序侧主要是全局和页面级。收集这一项的时候我一般只记录是否支持用户自定义字号和是否存在主题切换细节样式不深挖性价比不高。3.3 网络请求与接口清单的整理原则接口信息是最敏感也最需要克制的一块。合规的做法是在获得明确授权的测试环境中观察自己产品的请求整理出域名清单、请求方法、字段结构、登录态字段名。这些信息用于内部文档、性能优化、安全自查都是正当的。经常有人问为什么常规分析手段会失败。原因通常有几类一是客户端做了证书校验普通方式看不到内容二是请求体做了签名参数被加密三是用了双向校验。这些机制本身是产品的安全设计遇到这类情况正确的做法是走官方渠道找接口文档或者联系对方商务而不是想办法绕。绕过去既有法律风险也很难维护。接口清单我一般记这几列域名、路径、请求方法、是否需要登录态、关键字段、用途推测、采集时间。最后一列必须有因为接口会变。3.4 跨端框架带来的信息差异技术栈不同能收集到的信息颗粒度也不同。原生安卓工程比如用Android Studio从零建的结构规范资源命名通常有规律容易看出模块划分。用Django这类后端框架建的工程能看出的主要是路由和应用的划分思路对理解产品的后端组织方式有帮助但和客户端信息基本无关。跨端方案里uni-app和类似方案的项目配置文件的组织方式比较有辨识度页面路由集中管理收集路径清单很方便。用开发工具直接发行到小程序平台的流程也会在目录结构里留下痕迹。游戏类小程序另说包体大、资源多收集重点应该放在资源加载策略和分包上而不是页面路径。带硬件交互的产品比如蓝牙控制类的APP信息收集要额外加两块一是蓝牙相关权限和协议声明二是设备配对的流程节点。这类产品的信息如果漏了配对流程等于没收集。4. 把零散信息变成可用的表格4.1 字段设计信息收集做多了就会发现真正的瓶颈不是采不到而是采回来对不上。所以字段设计要提前想清楚。我目前用的基础字段集是这样的可以按需裁剪product: name: 产品名称 alias: 别名历史 subject: 开发主体全称 subject_code: 统一社会信用代码 platform: [android, ios, wechat_mini, alipay_mini] category: 类目 status: 在架/下架 tech: framework: 推测技术栈 package_name: 包名或appid sub_package_count: 分包数 min_version_supported: 最低支持版本 runtime: nav_height_rule: 导航栏高度计算方式 title_mode: 静态/动态 font_customizable: 是否支持自定义字号 login_required: 是否强制登录 data: domains: 域名列表 auth_field: 登录态字段名 collect_time: 采集时间这份结构的好处是分层清晰导出成表格后每层一列组不会全挤在一起。4.2 清洗、去重与版本管理采集回来的第一版永远是不能直接用的。我的清洗顺序是先统一主体名称同一家公司可能有多个写法再合并重复条目按包名或appid判重然后补全缺失字段最后标注置信度。置信度这一列很多人不加我觉得挺可惜。信息收集的结果天然有推测成分比如推测技术栈就是猜的。标上高/中/低三档看报告的人心里有数你自己半年后翻出来也不会把猜测当事实。版本管理就更简单了每次采集存一份带日期的快照不要覆盖。用简单的目录加日期命名就够了别一上来就搞复杂的系统。4.3 采集流程的自动化骨架如果只是十几个产品的调研纯手工没问题。上到几十上百个就得考虑半自动化。我一般写个小脚本处理重复度最高的部分比如从商店页面提取结构化字段、批量比对版本号变化。import csv from datetime import date def load_snapshot(path): with open(path, encodingutf-8) as f: return {row[package_name]: row for row in csv.DictReader(f)} def diff_versions(old, new): changes [] for pkg, row in new.items(): prev old.get(pkg) if prev and prev[version] ! row[version]: changes.append({ package_name: pkg, from: prev[version], to: row[version], date: date.today().isoformat(), }) return changes这段代码没什么技术含量价值在于把版本变化这个动作固化下来。每次采集完跑一遍变更列表自动出来比人眼比对靠谱得多。注意自动化采集务必遵守目标平台的服务条款和robots约定只采集公开可见内容控制请求频率。5. 常见问题与排查实录5.1 高频问题速查表下面这些是我被问得最多、也最容易卡住新人的问题整理成表方便对照。现象常见原因处理思路商店版本与真机不一致商店缓存或灰度放量以真机为准记录采集时间小程序页面路径找不到页面在分包内按需加载走完整业务流程再记录标题记录后第二天变了用了动态标题记录路径而非标题标注触发条件导航栏在部分机型错位状态栏高度写死改为运行时计算接口分析拿不到内容存在校验或签名机制走官方文档或商务渠道不绕权限清单各商店不同展示策略差异以真机安装后的申请为准备注信息被退回描述与类目不符按业务链路重写不写套话主体名称对不上简称、曾用名、子公司建主体映射表用代码做主键5.2 几个踩过的坑第一个坑是过度采集。有次做竞品分析我一股脑收集了七八个维度最后写报告发现真正用上的只有三个剩下全是浪费。后来我改成一个规矩开采集前先写一句这份数据要回答什么问题答不出来的字段直接砍掉。第二个坑是把推测写成事实。早期报告里我写该产品使用某某框架后来被同行指出证据不足。从那以后凡是推测都加推测二字或者写清判断依据。第三个坑是忽略登录态带来的信息差异。很多产品在未登录和登录后展示的内容完全不同未登录时收集的页面清单可能只有登录后的一半。现在我固定两轮采集未登录一轮登录后一轮分别存快照。第四个坑是备注和类目脱节。有次帮人代填小程序备案备注写得很详细但类目选偏了来回改了三轮。后来的经验是先定类目再按类目能覆盖的能力范围去写备注顺序反过来能省很多时间。第五个坑是依赖单一渠道。早期我只从一家商店抓数据结果对方在另一家商店有完全不同的运营策略都没发现。现在至少覆盖两个渠道做交叉验证。最后一个心得是关于交付形态。信息收集的成果不要只给一张大表最好拆成速览页和明细页两层。速览页一屏看完关键结论明细页放着所有原始记录备查。看报告的人九成只会看速览页你把精力平均分配是浪费。这个习惯我坚持了好几年回访反馈基本都是正面的。后续如果要把这套流程沉淀下来我建议从主体映射表和变更日志这两样开始它们是最容易被复用、也最能省时间的两个资产。
