简介《宝可梦图鉴》是一款基于Android平台、以查询宝可梦详细数据为核心功能的游戏小程序源码包面向移动开发初学者、宝可梦爱好者及想了解Android应用架构的开发者。压缩包共981个文件以920个png图片资源为主搭配js、json、wxml、wxss等前端逻辑与配置文件整体仅2.44MB轻量且结构清晰。已有333人学习下载。源码涵盖SQLite数据存储、RecyclerView列表绑定、搜索过滤、动画效果等典型实现包含AndroidManifest、build.gradle、src与res等标准目录便于对照学习Activity生命周期、Intent使用、网络请求与数据解析。通过阅读代码可以掌握从数据获取到UI展示的完整流程为自定义扩展宝可梦图鉴或开发同类查询工具提供良好起点。1. 宝可梦图鉴类小程序的本质是把数据模型做成产品体验拿到一个“宝可梦图鉴游戏小程序”的需求多数人的第一反应是去找现成的图鉴数据源然后直接往页面上堆列表和详情。但真正上线过的人都知道这种做法的结果就是一个可以演示、没法长期运营的静态页面。宝可梦图鉴形态的游戏小程序难点并不在 UI 长什么样而在于三件事数据从哪来、数据怎么存、交互怎么让用户觉得“我是在玩一个游戏”而不是“我在查一个资料库”。本文适合两类人一类是刚接触微信小程序游戏开发、想做一个收集类图鉴练手的开发者另一类是做小程序外包或自研项目、需要把“图鉴收集进度”这套逻辑说清楚的技术负责人。我会顺着数据建模、界面交互、游戏化机制、性能优化这条路径把一套可以直接落地的方案讲完。代码用微信小程序原生语法写但中间的建模思路和存储策略同样适用于 uniapp 微信小程序或者其他跨端框架。2. 图鉴数据模型设计脱离网络也能跑是收集类小程序的底线2.1 为什么必须做本地数据优先宝可梦图鉴的常见设计是图鉴列表、详情页、搜索筛选、捕获状态。如果每次打开图鉴列表都请求服务器那么页面加载体验、弱网状态下的可用性、服务器成本都会成为问题更不用说小程序包体积和请求频率的限制。常见做法是把宝可梦基础数据打包进小程序包内做成离线优先的模式。服务器只负责后续的动态内容——比如用户自定义笔记、云端同步捕获记录——而不是每次渲染都要跑一次请求。离线优先的第二个原因是留存。游戏小程序的核心指标是“用户愿意反复打开”如果首屏依赖网络用户在电梯、地铁里的打开意愿会大打折扣。数据内置包内之后列表页秒开图鉴的“收集感”才立得住。2.2 数据结构的字段规划宝可梦图鉴的核心数据可以拆成两块静态数据和用户数据。静态数据指宝可梦本身的属性用户数据指用户是否捕获、捕获时间、个人标记等。下面是一份精简的静态数据 JSON 结构示例{ id: 001, name: 妙蛙种子, nameEn: bulbasaur, types: [grass, poison], height: 0.7, weight: 6.9, stats: { hp: 45, attack: 49, defense: 49, speed: 45 }, evolutionChain: [001, 002, 003], description: 出生时背上就长着种子经常在阳光下打盹。, imageUrl: /assets/images/pokemon/001.png, rarity: common }这份结构里有两个字段值得特别说。types用数组而不是字符串因为宝可梦有双属性设定搜索“草毒”这种组合时数组过滤比字符串includes判断要干净得多。imageUrl用小写英文字母作为路径避免中文文件名在部分 Android 机型上出现路径编码问题。2.3 数据获取的常见路径与版权边界数据从哪来是绕不开的问题。常见做法是写一个 Node.js 爬虫去公开的图鉴社区或开源的宝可梦数据仓库抓取结构化数据然后清洗成自己需要的 JSON 格式。也有直接从游戏解包数据里提取图鉴文本和属性的做法但这涉及版权风险不适合商用项目。学习用途的 demo 可以这么跑通但公开发布前需要确认数据来源的授权边界。下面是一个精简的爬虫脚本示例输入是图鉴详情页的 URL 列表输出是清洗后的 JSONconst axios require(axios); const cheerio require(cheerio); const fs require(fs); async function fetchPokemonData(url) { const { data } await axios.get(url, { headers: { User-Agent: Mozilla/5.0 } }); const $ cheerio.load(data); const pokemon { id: $(.pokemon-id).text().trim(), name: $(.pokemon-name).text().trim(), types: [], stats: {} }; $(.type-badge).each((_, el) { pokemon.types.push($(el).text().trim().toLowerCase()); }); $(.stat-row).each((_, el) { const statName $(el).find(.stat-name).text().trim(); const statValue parseInt($(el).find(.stat-value).text().trim(), 10); pokemon.stats[statName] statValue; }); return pokemon; } async function main() { const urls [https://example-pokedex.com/pokemon/001]; const results []; for (const url of urls) { const data await fetchPokemonData(url); results.push(data); } fs.writeFileSync(./pokedex.json, JSON.stringify(results, null, 2)); } main();脚本逻辑不复杂用axios拿页面 HTMLcheerio解析 DOM然后按选择器提取字段最后写进 JSON 文件。需要注意for...of配合await会串行请求宝可梦数量大时耗时很长。要提速就把urls.map(fetchPokemonData)改成Promise.all并发拉取但并发数控制在 5 左右避免被目标站点封 IP。3. 搜索筛选和列表渲染图鉴类小程序的交互核心3.1 小程序端的数据过滤与渲染策略数据打包进本地后在页面上的呈现方式决定了这个图鉴是“能用”还是“好用”。列表页需要承载三个常见操作关键词搜索、属性筛选、列表滚动加载。搜索建议在前端做全量过滤不请求服务器。宝可梦数据全量也才一千条左右不同世代数据量不同内存过滤的性能问题完全不存在。下面是搜索筛选的完整实现// pages/index/index.js const POKEMON_DATA require(../../data/pokedex.json); Page({ data: { keyword: , activeTypes: [], filteredList: [], allTypes: [grass, fire, water, electric, poison, flying] }, onLoad() { this.setData({ filteredList: POKEMON_DATA }); }, onSearchInput(e) { const keyword e.detail.value.trim().toLowerCase(); this.setData({ keyword }); this.applyFilter(); }, onToggleType(e) { const type e.currentTarget.dataset.type; const activeTypes this.data.activeTypes.includes(type) ? this.data.activeTypes.filter(t t ! type) : [...this.data.activeTypes, type]; this.setData({ activeTypes }); this.applyFilter(); }, applyFilter() { const { keyword, activeTypes } this.data; let result POKEMON_DATA; if (keyword) { result result.filter(item item.name.includes(keyword) || item.nameEn.includes(keyword) || item.id.includes(keyword) ); } if (activeTypes.length 0) { result result.filter(item activeTypes.every(type item.types.includes(type)) ); } // 模拟异步渲染避免高频搜索时 UI 卡顿 clearTimeout(this.filterTimer); this.filterTimer setTimeout(() { this.setData({ filteredList: result }); }, 100); } });过滤逻辑里有两个关键点。第一类型筛选用的是every而不是some。如果用户勾选 “grass” 和 “poison”意味着要同时包含这两个属性而不是只要命中其中一个就算。这个交互语义在需求评审阶段就要和产品确认否则后期改会牵动搜索逻辑。第二setTimeout做了一层防抖虽然本地过滤很快但setData在低端安卓机上的渲染开销不小100 毫秒的延迟换滑动流畅是划算的。3.2 WXML 渲染和长列表优化列表页的 WXML 结构遵循小程序常规写法用wx:for渲染卡片每个卡片绑定了>view classfilter-bar input placeholder搜索名称或编号 bindinputonSearchInput confirm-typesearch / scroll-view scroll-x classtype-tabs view wx:for{{allTypes}} wx:key*this classtype-tab {{activeTypes.includes(item) ? active : }} >wx.setNavigationBarTitle({ title: activeTypes.length 0 ? ${activeTypes.join()} 属性宝可梦 : 宝可梦图鉴 });导航栏高度适配的问题出现在自定义导航栏场景。如果项目用了navigationStyle: custom需要在onLoad里读取胶囊按钮位置计算顶部占位。用系统默认导航栏就简单很多不同机型的适配由微信自动处理初期开发建议用默认导航栏。4. 捕获机制与收集进度游戏小程序的核心正反馈4.1 捕获状态存储本地优先同步兜底图鉴类游戏小程序区别于普通查询工具的核心是捕获机制。用户浏览宝可梦详情页时点击捕获按钮捕获成功后对应宝可梦的图鉴状态变为“已捕获”首页的收集进度随之更新。捕获状态的存储选型很关键。常见做法是通过独角兽的wx.setStorageSync做本地存储把已捕获的 ID 数组单独存一份不修改基础数据文件。下面给出捕获操作的完整实现// pages/detail/detail.js const POKEMON_DATA require(../../data/pokedex.json); Page({ data: { pokemon: null, isCaptured: false, captureDate: }, onLoad(options) { const pokemon POKEMON_DATA.find(item item.id options.id); const capturedList wx.getStorageSync(capturedList) || []; const captureInfo capturedList.find(item item.id pokemon.id); this.setData({ pokemon, isCaptured: !!captureInfo, captureDate: captureInfo ? captureInfo.date : }); }, onCapture() { const { pokemon } this.data; const capturedList wx.getStorageSync(capturedList) || []; // 防止重复捕获 if (capturedList.some(item item.id pokemon.id)) { wx.showToast({ title: 已在图鉴中, icon: none }); return; } capturedList.push({ id: pokemon.id, date: new Date().toISOString() }); wx.setStorageSync(capturedList, capturedList); this.setData({ isCaptured: true, captureDate: 刚刚 }); wx.showToast({ title: 捕获 ${pokemon.name} 成功, icon: success }); } });存储结构里存的是数组而不是对象好处是追加操作简单坏处是频繁写入时整个数组要序列化一次。当捕获数量达到几百个以后可以考虑改成key-value结构captured_001: true这样查询单个 ID 更快但统计总数时必须遍历所有 key各有利弊。4.2 完成度计算与进度展示收集进度的展示直接影响用户的持续使用意愿。“图鉴完成度 68%” 比 “已捕获 680 只” 更有游戏感。完成度计算在首页onShow时做因为用户从详情页返回后需要立即看到数字变化// pages/index/index.js onShow() { const capturedList wx.getStorageSync(capturedList) || []; const total POKEMON_DATA.length; const progress Math.round((capturedList.length / total) * 100); this.setData({ capturedCount: capturedList.length, totalCount: total, progressPercent: progress }); // 更新导航栏标题下方的进度条组件 this.selectComponent(#progress-bar).updateProgress(progress); }进度条建议做成单独的组件props 接收percent和capturedCount。组件内部用 CSS 动画实现宽度过渡捕获一只之后回来能看到进度条“涨”一点微小的视觉反馈比数字更能触发收集欲。4.3 图鉴列表上的捕获状态标记列表页的每个卡片除了宝可梦名称和编号外还需要一个捕获状态角标。这个状态应该从 storage 中读取而不是放到POKEMON_DATA基础数据里。原因很简单基础数据是静态的、多人共享的状态是用户的、动态的。混在一起会导致setData频繁更新整个数组白消耗性能。在applyFilter结束后加一段状态合并逻辑applyFilter() { // ...原有过滤逻辑... const capturedList wx.getStorageSync(capturedList) || []; const capturedIds new Set(capturedList.map(item item.id)); result result.map(item ({ ...item, isCaptured: capturedIds.has(item.id) })); this.setData({ filteredList: result }); }用Set做has查询是 O(1) 复杂度比includes的 O(n) 高效。状态合并放在过滤之后避免对全量数据做无意义的展开和拷贝。5. 包体积控制与首屏加载优化图鉴项目上线前的最后一道工序图鉴类小程序的数据包和图片资源是体积超标的两个重灾区。一千只宝可梦的结构化数据 JSON 通常能压缩到几百 KB但图片如果全量打包轻松突破微信小程序主包 2MB 的限制。首选的优化方案是主包只放核心代码和第一代宝可梦的图片其他世代通过分包加载。微信小程序的分包配置很简单// app.json { pages: [ pages/index/index, pages/detail/detail ], subpackages: [ { root: pkg-johto, pages: [pages/johto-list/johto-list] }, { root: pkg-hoenn, pages: [pages/hoenn-list/hoenn-list] } ] }分包的核心原则是用户进入主包时不需要加载的资源全部塞进分包。具体到图鉴项目列表页的图片如果不分包首屏就会因为图片解码卡顿。或者换一种思路不把图片放小程序包内图片全部走 CDN用wx.getImageInfo预下载热门宝可梦的图片缓存到本地冷门宝可梦按需加载。两种方案都可以分包胜在离线可用CDN 胜在包体积小取舍点在于目标用户是否高频在弱网环境使用。图片本身的体积优化也值得花时间。常见做法是把 PNG 转成 WebP体积通常能缩小 60% 以上而 400 像素以内的图鉴缩略图在手机屏幕上完全够用。超过 400 像素的原图只保留在详情页使用列表页统一用压缩后的缩略图。跑一批脚本就能完成批量转换没有理由在前端做实时压缩。验证优化效果的推荐方式是在微信开发者工具的“性能面板”中查看页面加载耗时和内存占用。首屏从点击到列表可滚动的时间控制在 1 秒内是合理的基准线超过 2 秒则需要检查是图片解码瓶颈还是setData数据量过大。用wx.getPerformance也可以拿到关键指标const performance wx.getPerformance(); const observer performance.createObserver((entryList) { const entry entryList.getEntriesByName(first-contentful-paint)[0]; console.log(首屏内容绘制时间, entry.startTime); }); observer.observe({ type: render });小程序图鉴最后要过的不是功能关而是体验关。数据原生内置、捕获状态本地存储、列表渲染防抖、导航栏标题动态适配这几个细节叠加起来才是一个用户可以反复打开的产品。老手和新手的差距往往不在业务逻辑复杂度而在于这些颗粒度的处理是否成体系。本文还有配套的精品资源点击获取
简介《宝可梦图鉴》是一款基于Android平台、以查询宝可梦详细数据为核心功能的游戏小程序源码包面向移动开发初学者、宝可梦爱好者及想了解Android应用架构的开发者。压缩包共981个文件以920个png图片资源为主搭配js、json、wxml、wxss等前端逻辑与配置文件整体仅2.44MB轻量且结构清晰。已有333人学习下载。源码涵盖SQLite数据存储、RecyclerView列表绑定、搜索过滤、动画效果等典型实现包含AndroidManifest、build.gradle、src与res等标准目录便于对照学习Activity生命周期、Intent使用、网络请求与数据解析。通过阅读代码可以掌握从数据获取到UI展示的完整流程为自定义扩展宝可梦图鉴或开发同类查询工具提供良好起点。1. 宝可梦图鉴类小程序的本质是把数据模型做成产品体验拿到一个“宝可梦图鉴游戏小程序”的需求多数人的第一反应是去找现成的图鉴数据源然后直接往页面上堆列表和详情。但真正上线过的人都知道这种做法的结果就是一个可以演示、没法长期运营的静态页面。宝可梦图鉴形态的游戏小程序难点并不在 UI 长什么样而在于三件事数据从哪来、数据怎么存、交互怎么让用户觉得“我是在玩一个游戏”而不是“我在查一个资料库”。本文适合两类人一类是刚接触微信小程序游戏开发、想做一个收集类图鉴练手的开发者另一类是做小程序外包或自研项目、需要把“图鉴收集进度”这套逻辑说清楚的技术负责人。我会顺着数据建模、界面交互、游戏化机制、性能优化这条路径把一套可以直接落地的方案讲完。代码用微信小程序原生语法写但中间的建模思路和存储策略同样适用于 uniapp 微信小程序或者其他跨端框架。2. 图鉴数据模型设计脱离网络也能跑是收集类小程序的底线2.1 为什么必须做本地数据优先宝可梦图鉴的常见设计是图鉴列表、详情页、搜索筛选、捕获状态。如果每次打开图鉴列表都请求服务器那么页面加载体验、弱网状态下的可用性、服务器成本都会成为问题更不用说小程序包体积和请求频率的限制。常见做法是把宝可梦基础数据打包进小程序包内做成离线优先的模式。服务器只负责后续的动态内容——比如用户自定义笔记、云端同步捕获记录——而不是每次渲染都要跑一次请求。离线优先的第二个原因是留存。游戏小程序的核心指标是“用户愿意反复打开”如果首屏依赖网络用户在电梯、地铁里的打开意愿会大打折扣。数据内置包内之后列表页秒开图鉴的“收集感”才立得住。2.2 数据结构的字段规划宝可梦图鉴的核心数据可以拆成两块静态数据和用户数据。静态数据指宝可梦本身的属性用户数据指用户是否捕获、捕获时间、个人标记等。下面是一份精简的静态数据 JSON 结构示例{ id: 001, name: 妙蛙种子, nameEn: bulbasaur, types: [grass, poison], height: 0.7, weight: 6.9, stats: { hp: 45, attack: 49, defense: 49, speed: 45 }, evolutionChain: [001, 002, 003], description: 出生时背上就长着种子经常在阳光下打盹。, imageUrl: /assets/images/pokemon/001.png, rarity: common }这份结构里有两个字段值得特别说。types用数组而不是字符串因为宝可梦有双属性设定搜索“草毒”这种组合时数组过滤比字符串includes判断要干净得多。imageUrl用小写英文字母作为路径避免中文文件名在部分 Android 机型上出现路径编码问题。2.3 数据获取的常见路径与版权边界数据从哪来是绕不开的问题。常见做法是写一个 Node.js 爬虫去公开的图鉴社区或开源的宝可梦数据仓库抓取结构化数据然后清洗成自己需要的 JSON 格式。也有直接从游戏解包数据里提取图鉴文本和属性的做法但这涉及版权风险不适合商用项目。学习用途的 demo 可以这么跑通但公开发布前需要确认数据来源的授权边界。下面是一个精简的爬虫脚本示例输入是图鉴详情页的 URL 列表输出是清洗后的 JSONconst axios require(axios); const cheerio require(cheerio); const fs require(fs); async function fetchPokemonData(url) { const { data } await axios.get(url, { headers: { User-Agent: Mozilla/5.0 } }); const $ cheerio.load(data); const pokemon { id: $(.pokemon-id).text().trim(), name: $(.pokemon-name).text().trim(), types: [], stats: {} }; $(.type-badge).each((_, el) { pokemon.types.push($(el).text().trim().toLowerCase()); }); $(.stat-row).each((_, el) { const statName $(el).find(.stat-name).text().trim(); const statValue parseInt($(el).find(.stat-value).text().trim(), 10); pokemon.stats[statName] statValue; }); return pokemon; } async function main() { const urls [https://example-pokedex.com/pokemon/001]; const results []; for (const url of urls) { const data await fetchPokemonData(url); results.push(data); } fs.writeFileSync(./pokedex.json, JSON.stringify(results, null, 2)); } main();脚本逻辑不复杂用axios拿页面 HTMLcheerio解析 DOM然后按选择器提取字段最后写进 JSON 文件。需要注意for...of配合await会串行请求宝可梦数量大时耗时很长。要提速就把urls.map(fetchPokemonData)改成Promise.all并发拉取但并发数控制在 5 左右避免被目标站点封 IP。3. 搜索筛选和列表渲染图鉴类小程序的交互核心3.1 小程序端的数据过滤与渲染策略数据打包进本地后在页面上的呈现方式决定了这个图鉴是“能用”还是“好用”。列表页需要承载三个常见操作关键词搜索、属性筛选、列表滚动加载。搜索建议在前端做全量过滤不请求服务器。宝可梦数据全量也才一千条左右不同世代数据量不同内存过滤的性能问题完全不存在。下面是搜索筛选的完整实现// pages/index/index.js const POKEMON_DATA require(../../data/pokedex.json); Page({ data: { keyword: , activeTypes: [], filteredList: [], allTypes: [grass, fire, water, electric, poison, flying] }, onLoad() { this.setData({ filteredList: POKEMON_DATA }); }, onSearchInput(e) { const keyword e.detail.value.trim().toLowerCase(); this.setData({ keyword }); this.applyFilter(); }, onToggleType(e) { const type e.currentTarget.dataset.type; const activeTypes this.data.activeTypes.includes(type) ? this.data.activeTypes.filter(t t ! type) : [...this.data.activeTypes, type]; this.setData({ activeTypes }); this.applyFilter(); }, applyFilter() { const { keyword, activeTypes } this.data; let result POKEMON_DATA; if (keyword) { result result.filter(item item.name.includes(keyword) || item.nameEn.includes(keyword) || item.id.includes(keyword) ); } if (activeTypes.length 0) { result result.filter(item activeTypes.every(type item.types.includes(type)) ); } // 模拟异步渲染避免高频搜索时 UI 卡顿 clearTimeout(this.filterTimer); this.filterTimer setTimeout(() { this.setData({ filteredList: result }); }, 100); } });过滤逻辑里有两个关键点。第一类型筛选用的是every而不是some。如果用户勾选 “grass” 和 “poison”意味着要同时包含这两个属性而不是只要命中其中一个就算。这个交互语义在需求评审阶段就要和产品确认否则后期改会牵动搜索逻辑。第二setTimeout做了一层防抖虽然本地过滤很快但setData在低端安卓机上的渲染开销不小100 毫秒的延迟换滑动流畅是划算的。3.2 WXML 渲染和长列表优化列表页的 WXML 结构遵循小程序常规写法用wx:for渲染卡片每个卡片绑定了>view classfilter-bar input placeholder搜索名称或编号 bindinputonSearchInput confirm-typesearch / scroll-view scroll-x classtype-tabs view wx:for{{allTypes}} wx:key*this classtype-tab {{activeTypes.includes(item) ? active : }} >wx.setNavigationBarTitle({ title: activeTypes.length 0 ? ${activeTypes.join()} 属性宝可梦 : 宝可梦图鉴 });导航栏高度适配的问题出现在自定义导航栏场景。如果项目用了navigationStyle: custom需要在onLoad里读取胶囊按钮位置计算顶部占位。用系统默认导航栏就简单很多不同机型的适配由微信自动处理初期开发建议用默认导航栏。4. 捕获机制与收集进度游戏小程序的核心正反馈4.1 捕获状态存储本地优先同步兜底图鉴类游戏小程序区别于普通查询工具的核心是捕获机制。用户浏览宝可梦详情页时点击捕获按钮捕获成功后对应宝可梦的图鉴状态变为“已捕获”首页的收集进度随之更新。捕获状态的存储选型很关键。常见做法是通过独角兽的wx.setStorageSync做本地存储把已捕获的 ID 数组单独存一份不修改基础数据文件。下面给出捕获操作的完整实现// pages/detail/detail.js const POKEMON_DATA require(../../data/pokedex.json); Page({ data: { pokemon: null, isCaptured: false, captureDate: }, onLoad(options) { const pokemon POKEMON_DATA.find(item item.id options.id); const capturedList wx.getStorageSync(capturedList) || []; const captureInfo capturedList.find(item item.id pokemon.id); this.setData({ pokemon, isCaptured: !!captureInfo, captureDate: captureInfo ? captureInfo.date : }); }, onCapture() { const { pokemon } this.data; const capturedList wx.getStorageSync(capturedList) || []; // 防止重复捕获 if (capturedList.some(item item.id pokemon.id)) { wx.showToast({ title: 已在图鉴中, icon: none }); return; } capturedList.push({ id: pokemon.id, date: new Date().toISOString() }); wx.setStorageSync(capturedList, capturedList); this.setData({ isCaptured: true, captureDate: 刚刚 }); wx.showToast({ title: 捕获 ${pokemon.name} 成功, icon: success }); } });存储结构里存的是数组而不是对象好处是追加操作简单坏处是频繁写入时整个数组要序列化一次。当捕获数量达到几百个以后可以考虑改成key-value结构captured_001: true这样查询单个 ID 更快但统计总数时必须遍历所有 key各有利弊。4.2 完成度计算与进度展示收集进度的展示直接影响用户的持续使用意愿。“图鉴完成度 68%” 比 “已捕获 680 只” 更有游戏感。完成度计算在首页onShow时做因为用户从详情页返回后需要立即看到数字变化// pages/index/index.js onShow() { const capturedList wx.getStorageSync(capturedList) || []; const total POKEMON_DATA.length; const progress Math.round((capturedList.length / total) * 100); this.setData({ capturedCount: capturedList.length, totalCount: total, progressPercent: progress }); // 更新导航栏标题下方的进度条组件 this.selectComponent(#progress-bar).updateProgress(progress); }进度条建议做成单独的组件props 接收percent和capturedCount。组件内部用 CSS 动画实现宽度过渡捕获一只之后回来能看到进度条“涨”一点微小的视觉反馈比数字更能触发收集欲。4.3 图鉴列表上的捕获状态标记列表页的每个卡片除了宝可梦名称和编号外还需要一个捕获状态角标。这个状态应该从 storage 中读取而不是放到POKEMON_DATA基础数据里。原因很简单基础数据是静态的、多人共享的状态是用户的、动态的。混在一起会导致setData频繁更新整个数组白消耗性能。在applyFilter结束后加一段状态合并逻辑applyFilter() { // ...原有过滤逻辑... const capturedList wx.getStorageSync(capturedList) || []; const capturedIds new Set(capturedList.map(item item.id)); result result.map(item ({ ...item, isCaptured: capturedIds.has(item.id) })); this.setData({ filteredList: result }); }用Set做has查询是 O(1) 复杂度比includes的 O(n) 高效。状态合并放在过滤之后避免对全量数据做无意义的展开和拷贝。5. 包体积控制与首屏加载优化图鉴项目上线前的最后一道工序图鉴类小程序的数据包和图片资源是体积超标的两个重灾区。一千只宝可梦的结构化数据 JSON 通常能压缩到几百 KB但图片如果全量打包轻松突破微信小程序主包 2MB 的限制。首选的优化方案是主包只放核心代码和第一代宝可梦的图片其他世代通过分包加载。微信小程序的分包配置很简单// app.json { pages: [ pages/index/index, pages/detail/detail ], subpackages: [ { root: pkg-johto, pages: [pages/johto-list/johto-list] }, { root: pkg-hoenn, pages: [pages/hoenn-list/hoenn-list] } ] }分包的核心原则是用户进入主包时不需要加载的资源全部塞进分包。具体到图鉴项目列表页的图片如果不分包首屏就会因为图片解码卡顿。或者换一种思路不把图片放小程序包内图片全部走 CDN用wx.getImageInfo预下载热门宝可梦的图片缓存到本地冷门宝可梦按需加载。两种方案都可以分包胜在离线可用CDN 胜在包体积小取舍点在于目标用户是否高频在弱网环境使用。图片本身的体积优化也值得花时间。常见做法是把 PNG 转成 WebP体积通常能缩小 60% 以上而 400 像素以内的图鉴缩略图在手机屏幕上完全够用。超过 400 像素的原图只保留在详情页使用列表页统一用压缩后的缩略图。跑一批脚本就能完成批量转换没有理由在前端做实时压缩。验证优化效果的推荐方式是在微信开发者工具的“性能面板”中查看页面加载耗时和内存占用。首屏从点击到列表可滚动的时间控制在 1 秒内是合理的基准线超过 2 秒则需要检查是图片解码瓶颈还是setData数据量过大。用wx.getPerformance也可以拿到关键指标const performance wx.getPerformance(); const observer performance.createObserver((entryList) { const entry entryList.getEntriesByName(first-contentful-paint)[0]; console.log(首屏内容绘制时间, entry.startTime); }); observer.observe({ type: render });小程序图鉴最后要过的不是功能关而是体验关。数据原生内置、捕获状态本地存储、列表渲染防抖、导航栏标题动态适配这几个细节叠加起来才是一个用户可以反复打开的产品。老手和新手的差距往往不在业务逻辑复杂度而在于这些颗粒度的处理是否成体系。本文还有配套的精品资源点击获取
