AUTOSAR最小系统配置实战：S32K312消红叉与Os/Rte映射

简介这是一份面向零基础学习者的AUTOSAR实战课程文档围绕在S32K312平台上创建并配置AUTOSAR工程最小系统展开适合汽车电子嵌入式开发入门者以及需要熟悉DaVinci工具链的工程师对照练习。资源包为1个PDF文件大小约12.48MB采用图文步骤组织便于按工具准备、工程新建、组件配置与错误处理等环节清晰查阅。文档以实际单核工程为例先说明DaVinci Developer、DaVinci Configurator和S32DS的用途再梳理添加vBaseEnv、vBRS、Base、Det、BswM、EcuM等基础组件的过程并针对常见配置报错给出自动修复与手动处理思路涉及晶振与主频参数、OsType选择、EcuM初始化流程、Os任务映射及Rte关联实例等细节。目前已有3224人学习对刚接触AUTOSAR的读者来说可先逐步理解各组件职责再跟着文档完成参数补全与问题定位为后续启动代码、编译调试和更复杂项目打下基础。1. AUTOSAR 最小系统的真正难点不在“加组件”而在“消红叉”大多数人第一次打开 AUTOSAR 配置工具时的预期很朴素新建工程、加几个模块、点生成三步收工。真按《AUTOSAR 零基础实战教程》里的路径走一遍就会发现加完 vBaseEnv、vBRS、Os、Rte 这一串组件之后工程树上会瞬间铺满红色错误图标少则几十条多则上百条其中只有一部分能靠工具的一键修复消掉。这份教程的价值就在这儿——它拿 S32K312 这块单核 MCU 当靶子把“建工程 → 从 SIP 加组件 → 逐条消错 → 生成代码”整条链路拆成可照着点的步骤每个红叉都标了该看哪个字段、该填什么值、哪些必须手填。适合刚接触 AUTOSAR、手上有一块 S32K3 系列板子但不知道从哪个 BSW 模块下手的嵌入式工程师也适合被 Rte 和 Os 的 Instance 报错困住半天、想找一份完整最小系统参照的人。2. 工具链摆盘SIP、DaVinci、S32DS 三件套谁管哪一段先把工具关系捋顺否则后面每走一步都会怀疑自己装错了东西。AUTOSAR 的开发链路天然是分层的应用层软件组件SWC由 DaVinci Developer 设计基础软件BSW由 DaVinci Configurator 配置两者共用同一个 SIP 里的模块来源最后由 S32DS 负责编辑、编译、下载调试。这份教程只覆盖到“生成代码”为止启动代码、最小系统编译和调试运行被拆到另一份文档里所以拿到手的是一份配置阶段的完整作业指导不是端到端全流程。2.1 SIP 是零件库不是配置工具SIP 全称 Software Integration Package是针对某个具体项目或某个芯片系列的软件集成包。你可以把它理解成一箱已经分好类的乐高零件BSW 模块的描述文件、MCAL 驱动、版本信息、模块之间的依赖声明都在里面。DaVinci Configurator 本身只是个装配台它不生产零件所有“”号加进来的组件都是从 SIP 里取的。这也是新手最容易翻车的地方装了配置工具、打开界面一切正常等到要添加组件时发现列表是空的或者加进来一堆模块全是红叉。原因通常不是工具没装好而是工程绑定的 SIP 路径不对或者手上的 SIP 根本不支持目标芯片。教程里特别点明“本例子要用到支持 S32K3xx 底层的包”这句话看着轻描淡写实际是整个流程能不能跑通的前提。S32K3 系列有单核也有多核型号包里带的模块描述是按整个系列铺开的所以后面配 Os 时会看到一些与多核相关的提示——那些不是错误是 Information 级别的信息。常见做法是新建工程时就把 SIP 路径一次性指对中途不要换。换 SIP 等于换零件箱已经配好的参数大概率对不上号。2.2 Developer 与 Configurator 的分工边界两个工具名字都带 DaVinci功能却完全不重叠工具管什么最小系统阶段用到多少DaVinci DeveloperSWC 设计、端口与接口定义、Runnable 声明少量只在需要补 SWC 描述时用DaVinci ConfiguratorBSW 模块配置、参数校验、arxml 与 C 代码生成全部主要工作都在这里SIP模块与驱动来源添加组件时读取S32DS编辑、编译、调试教程不覆盖另一份文档展开S32K312 开发板目标硬件提供 12MHz 晶振与 120MHz 主频基准在最小系统这个阶段你几乎可以只在 Configurator 里干活。但那句“Full Swc description…”的自动修复按钮之所以会出现是因为 Configurator 需要一份 SWC 侧的描述来补全 BSW 模块的 Service Port——这部分描述由 Developer 侧的工程结构提供。所以两个工具不是二选一的关系而是一个供描述、一个做配置。2.3 新建工程的六个动作每个都有取舍教程把新建流程压成了六步其中只有第三步真正需要判断输入项目名和路径路径里不要有中文和空格后面生成代码时容易出问题默认Next默认Next选芯片架构 S32K312编译器选 GCC默认Next默认Finish第四步是唯一的分叉点。芯片选错后面 vBaseEnv 里能选的 MCU 型号就全错vBRS 里的时钟参数也对不上引脚定义编译器选错生成的启动文件、链接脚本、汇编语法全都要重来。教程原文写“当然你也可以选 IAR”这句话背后的代价是GCC 和 IAR 在中断向量表写法、内联汇编语法、段属性宏上都不一样一旦工程建好再改等价于推倒重来。我一般的做法是先在纸面上把编译器定死团队里谁用什么编译器必须统一别出现 A 同学用 GCC、B 同学用 IAR、最后代码合不到一块的情况。工程建完之后先别急着加组件花两分钟确认三件事SIP 路径已写入工程配置、工程目标芯片显示为 S32K312、编译器显示为预期的那一个。这三项任何一个不对后面所有配置都是白工。2.4 加组件的入口只有一条路但顺序有讲究添加组件的位置固定在【Project】→【Project Setting】→【Module】点“”号选择从“SIP”添加勾选需要的组件Finish。界面操作没什么技术含量难的是知道该加哪些、按什么顺序加。最小系统需要的组件是vBaseEnv、vBRS、BaseMCAL 的 BASE、Det、BswM、EcuM、Os、Rte。这八个模块构成了一条完整的依赖链——vBaseEnv 定硬件环境vBRS 定启动与时钟Base 提供 MCAL 公共依赖OsIf 需要 Os 的类型Det 被几乎所有模块引用BswM 管 BSW 模式调度EcuM 管 ECU 状态机Rte 最后把所有 MainFunction 串起来。一次性全加进去看着痛快实际会得到一屏无法定位的红叉因为下游模块的报错很多是上游没配引发的连锁反应。教程的做法是加完之后按模块一个个消这是对的我更倾向于分批加先把 vBaseEnv、vBRS、Base 这三个和硬件强相关的配干净再加 Det、BswM、EcuM最后加 Os 和 Rte每批加完立刻消错问题范围永远可控。3. 组件清单与消错顺序谁先配、谁能一键修、谁必须手填这一章是整份教程最实在的部分。八个组件里工具有能力自动修复的大概占一半剩下的一半必须人来做决策。把“哪些能自动修、哪些不能”提前分清能省掉大量反复点击的时间。3.1 八个组件各自解决什么问题组件全称/定位在最小系统里的职责工具能否自动修复vBaseEnv虚拟基础环境声明当前配置面向哪颗 MCU否需手选 S32K312vBRSBasic Runtime System系统启动参数、晶振与主频否参数必须手填BaseMCAL 公共基础为 S32K3xx 的 MCAL 提供公共依赖部分OsType 可自动补DetDefault Error Tracer错误跟踪被 SWC 与 BSW 普遍引用是一键补全描述BswMBSW Management按规则执行各 BSW 模块的序列化操作是生成默认框架EcuMECU State Manager启动、运行、关机、休眠、唤醒源管理否时序相关参数必须手填OsAUTOSAR OSTask、Counter、Alarm、资源与内存保护否全部手填RteRuntime Environment生成运行环境串联各 MainFunction部分Instance 可补Mapping 要手动关联这张表建议直接抄进自己的笔记。看着红叉多的时候先扫一眼它在哪一行——落在“是”的那几行放心点自动修复落在“否”的那几行认命去翻参数。3.2 vBaseEnv 与 vBRS把 12MHz 晶振推到 120MHzvBaseEnv 只需要一步展开 vBaseEnvGeneral把 MCU 选成 S32K312。这一步选错后面所有时钟参数的含义都会变因为不同型号的 PLL 分频系数、总线时钟上限完全不同。vBRS 稍微复杂一点它管的是 Basic Runtime System配置系统启动相关的参数硬件参数也在里面。教程给的三个值是晶振 Clock 选 12MHz板上实际焊的那颗晶体的频率填错会导致所有定时全偏MCU 主频配 120MHz最终要跑到的核心频率Clock Reference 指向 CMU 组件里已经配好的那个时钟第三条是很多人忽略的坑。Clock Reference 不是让你填一个数字而是让你从已有时钟源里挑一个引用。如果 CMU 侧还没配好参考时钟这个下拉框要么是空的要么只有一个默认项你选了之后编译器不报错但实际生成的时钟树是错的。常见做法是先在 CMU 里把 PLL 的输入参考、倍频系数、各路分频器算清楚再回来选引用。12MHz 推到 120MHz 是 10 倍关系实际配置时并不是直接填一个“×10”而是通过 PLL 的反馈分频N、输入分频M、输出分频P三个参数组合出来具体数值跟芯片参考手册里的 PLL 约束有关教程没展开的部分要自己翻手册。我一般会在这一步做个手算记录晶振 12MHz → 输入分频后参考频率 → 乘 N 得到 VCO → 除 P 得到 120MHz 核心频率 → 总线与 Flash 时钟各自再分频。这张纸留着后面 Os 的 tick 换算要用。3.3 Base 与 OsIf一键修复到底创建了什么Base 里能自动修的典型是 OsIf。展开 Base鼠标悬停在 OsIfGeneral 的红色图标上工具会直接给出解决方案“Choose/TS_.../OsIfAutosarOsType”。点一下错误消失。这里要看懂它做了什么否则换个工程又不会了。OsIf 是 OS 接口层它的作用是给上层提供统一的 OS 服务调用入口屏蔽底层用的是 AUTOSAR OS 还是非 AUTOSAR OS。这个抽象需要一个 OsType 类型的定义来告诉它“我要对接哪种 OS”。工具点下去之后实际是在配置里创建了一个名为 OsIfAutosarOsType 的类型实例并把它挂到 OsIf 上。明白这一点你就知道为什么有些工程点不动这个按钮如果 SIP 里没有对应的描述或者 Os 模块还没加进来工具就不知道能创建哪些类型按钮自然没反应。所以顺序上Base 的 OsIf 建议在 Os 之后或同时处理。3.4 Det 与 BswM这两块可以放心交给工具Det 是 Default Error Tracer做错误跟踪用。它的配置项看起来简单但几乎所有 SWC 和 BSW 模块都会引用它来上报开发期错误所以一旦缺失报错会像多米诺骨牌一样在其他模块里冒出来。教程里直接点“Full Swc description…”就修好了。BswM 是基础软件管理模块根据来自 BSW 或 SWC 的特定输入在满足一定规则条件时执行对各 BSW 模块的序列化操作。它在最小系统里其实不做复杂调度工具会生成一套默认的规则框架点“Full Swc description…”补全描述即可。这两个模块之所以能一键修是因为它们的缺失属于“结构性缺失”——少了一个描述或一个端口工具按模板补上就对了不涉及项目决策。反过来说只要你的项目开始写具体的 BswM 规则比如某个模式请求触发某个模块初始化工具就修不了了那属于业务逻辑。3.5 EcuM工具修不了的那一半才是最小系统的核心EcuM 是 ECU 状态管理教程把它拆成五块Startup 初始化流程状态管理ECU 运行状态管理ShutDown 流程状态管理Sleep 流程状态管理Wakeup Source 管理这五块里工具能帮你补的只有结构参数必须自己填。原因很直白启动顺序、休眠策略、唤醒源选择是项目级决策工具不知道你的板子上有没有外部唤醒引脚、有没有低功耗需求、上电后先初始化哪个驱动。教程原文写得很清楚“并不是所有组件的错误都可以靠工具自动修复的例如这个 EcuM 中有很多参数是需要手动输入配置的软件工具做不到那么智能化。”这句话是整个配置过程中最重要的一句提醒。最小系统里 EcuM 至少要落实到启动时调用的初始化列表、MainFunction 的调度周期、默认的启动模式以及如果不需要低功耗休眠相关的裁剪。对零基础的人来说EcuM 的正确做法是先按默认值让工程能生成代码把“能跑起来”作为第一目标等功能验证通过再回来精调启动顺序。一上来就追求配到完美很容易卡在某条状态机迁移上出不来。4. Os 与 Rte最小系统里最容易反复返工的两块如果前面几章是“按图施工”这一章就是“图纸上有几处需要自己算”。Os 和 Rte 是最小系统里配置量最大、依赖关系最密、也最容易在生成代码之后才发现问题的两个模块。教程在这两块给的篇幅不算多但提到的问题个个都是硬骨头。4.1 Counter Ticks 与 Seconds Per Ticks 的换算教程里给的一组值是Counter Ticks 填 120000Seconds Per Ticks 填 0.001。这两个数的关系必须搞清楚否则计时会差出好几倍。算式很朴素CounterTicks SecondsPerTicks × f_CPU 0.001 s × 120,000,000 Hz 120,000含义是这个 OS Counter 每秒钟数 120000 下每一下对应 1ms。填 120000 的前提是主频真的是 120MHz——如果 vBRS 里的主频填错或者 CMU 的 PLL 没配对这里填多少都是错的而且编译器不会拦你只会在跑起来之后表现为“任务周期莫名其妙变长或变短”。换算表放在下面改主频的时候直接查主频目标 tickSeconds Per TicksCounter Ticks120MHz1ms0.001120000120MHz100us0.00011200080MHz1ms0.00180000160MHz1ms0.001160000注意这两个参数是联动的改一个另一个必须同步改只改一边在配置上不报错运行时的节拍就是错的。4.2 Os 的 Memory Protection 报错根因通常不在 Os教程提到“这个 Os 的配置页面往下翻还会看到 Memory Protection 处会有错误”但原文没展开原因。这里的常见情况是Os 开了内存保护相关的配置项要求每个 Task、ISR、Counter 都必须归属到某个 OsApplication而 OsApplication 又要绑定内存区域。最小系统刚建的时候 Task 都没建几个OsApplication 是空的这些校验自然全红。解法有两条路。第一条是按最小系统思路处理既然目标是先跑起来就把内存保护相关选项先关掉或保持默认关闭状态等 Task 和 OsApplication 的划分稳定了再开。第二条是老老实实建 OsApplication把 Task 分进去——这条路在量产项目上迟早要走但在最小系统阶段属于给自己加难度。还有一个细节容易误解S32K312 是单核配置里出现的多核相关提示比如某个核间同步项只是 Information不是错误。教程原文特意点明“图中显示的这个并非错误因为我们这里用的 S32K312 是单核的”原因在于 SIP 是按 S32K3xx 整个系列做的包里本身就含多核型号的描述。看到这类提示别急着改先确认它的严重级别。提示配置树里的红色图标分 Error 和 Info 两类鼠标悬停会显示具体级别。按 Error 逐条清Info 只看不改能省掉一半无效操作。4.3 Rte 的 Instance 修补与 MainFunction 映射Rte 是 Runtime Environment给 AUTOSAR 提供运行环境绝大部分内容是配置工具自动生成的手写代码极少。但“自动生成”不等于“自动正确”。第一层是 Instance。加完 Rte 之后工具会扫描整个工程发现缺哪些关联组件就提示补哪些点建议按钮会创建对应的 Instance。教程提醒得很到位“根据提示创建的这些 Instance 后也不一定是完整的有些信息需要手动添加或者手动关联上去的。”第二层是 Mapping这才是真正的坑。典型报错是 EcuM_MainFunction 没有 mapping 到一个合法的 Task。工具只会告诉你“没映射”不会告诉你为什么——因为很可能 Os 里压根没建那个 Task。正确顺序是反过来的先在 Os 里建好周期 Task比如一个 10ms 的 Task把 Task 挂到对应的 OsApplication再回到 Rte 把 EcuM 的 MainFunction 映射到这个 Task 上。顺序搞反你会陷入“点自动修复 → 报错消失 → 重新校验 → 报错又回来”的死循环。报错现象实际缺的东西处理位置EcuM_MainFunction 未映射到合法 TaskOs 里没有对应周期 Task先建 Task再回 Rte 映射Rte 提示缺少 Instance关联组件未创建实例按提示补补完重新校验Task 建了但仍无法映射Task 未归属 OsApplicationOs 侧补 OsApplication 归属4.4 生成代码前跑一遍自检点生成之前我习惯用脚本把关键配置扫一遍比在 GUI 里翻树快得多。下面这段在生成输出目录下跑#!/usr/bin/env bash # 用法: ./check_cfg.sh [输出目录]默认 ./output set -u OUT${1:-./output} # 1. 六个关键模块是否都产出了 C/H 文件 for m in Os OsIf EcuM Det BswM Rte; do d$(find $OUT -maxdepth 3 -type d -name $m 2/dev/null | head -n1) if [ -z $d ]; then echo MISSING DIR : $m continue fi n$(find $d -type f \( -name *.c -o -name *.h \) | wc -l) echo OK : $m - $d ($n files) done # 2. Os 的节拍换算是否真的落到配置里 grep -rn 120000\|SECONDS_PER_TICK\|OsCounter $OUT \ --include*.arxml 2/dev/null | head -n 5 # 3. OsIf 的 OsType 是否已实例化 grep -rn OsIfAutosarOsType $OUT --include*.arxml 2/dev/null | head -n 3逻辑说明第一段按模块名找生成目录找不到直接打印 MISSING能第一时间发现某个模块压根没参与生成常见的漏配找到则统计文件数文件数为 0 说明模块被加进来了但没配置任何内容属于空壳。第二段在 arxml 里搜 120000 这个关键数字用来验证 Counter 配置确实写进去了而不是只在 GUI 里填了没保存。第三段确认 OsIf 的自动修复真的产生了类型定义而不是按钮点了个寂寞。参数说明脚本第一个位置参数是生成输出目录不同工程默认路径不一样Configurator 里能看到具体的 output 目录传进去即可--maxdepth 3是防止在超大工程里全盘遍历拖慢速度如果模块目录层级更深把它调到 4 或 5。这段脚本不能替代配置工具自己的校验但能在“校验通过、生成成功、编译报错”这种最难受的场景里快速定位到底是哪一层没落地。5. 避坑与排查从满屏红叉到零错误的三小时下面五条是这类最小系统工程里出现频率最高的问题每条按“现象 → 原因 → 解决”写。顺序基本就是我在实际配置时的处理顺序。5.1 加完组件满屏红不知道从哪条开始修现象八个组件加进去工程树上几十个红叉展开任何一个模块都是一串错误点自动修复有的管用有的不管用。原因BSW 模块之间是强依赖关系下游模块的报错大部分是上游参数没配引发的连锁反应。比如 vBaseEnv 没选 MCUvBRS 的时钟参数就没有合法取值范围Os 的 tick 换算也无从校验。解决按依赖顺序自上而下清vBaseEnv → vBRS → Base含 OsIf→ Det → BswM → EcuM → Os → Rte。每清完一层重新校验一次工程看红叉数量是不是在下降。如果清完某一层之后红叉数量反而变多说明这一层的某个参数把下游的默认值冲掉了回头检查刚改的那个字段。5.2 自动修复点了没反应或者修完又变红现象悬停提示有“Choose/TS_.../OsIfAutosarOsType”这类一键修复入口点下去错误消失但重新校验或者改动别的模块之后同样的错误又回来了。原因两种可能。一是上游依赖没满足工具创建了类型但挂不上去下次校验时判定为无效配置二是这个错误本身是别的模块引发的修它只是暂时掩盖。解决先确认上游模块比如 Os是否已经加进来并配好基础参数再点自动修复。修完立刻做一次完整校验确认不是假性消失。对于反复出现的错误别继续点按钮展开错误详情看它引用了哪个模块的哪个字段从被引用的那一侧改。5.3 Counter Ticks 填了 120000实测节拍差了好几倍现象Os 配置里 Counter Ticks 明明是 120000Seconds Per Ticks 是 0.001理论上 1ms 一个 tick但实测任务周期明显不对。原因主频链路没打通。vBRS 里主频填的是 120MHz但 Clock Reference 指向的 CMU 时钟还是默认的晶振频率12MHz或者 PLL 没使能实际跑的是内部 RC。这种情况下 120000 对应的是 12MHz 下的 10ms而不是 1ms。解决回到 vBRS 的 Clock Reference确认它引用的是 CMU 里已经配好并使能的 PLL 输出再回到 CMU 检查输入分频、倍频、输出分频三组参数是否与参考手册的约束一致。改完之后重新生成代码用示波器或翻转 GPIO 的方式实测一次节拍别只信配置界面。5.4 EcuM_MainFunction 死活映射不到 Task现象Rte 里提示 EcuM_MainFunction 没有 mapping 到一个合法的 Task点自动修复无效手动下拉列表里也没有可选项。原因Os 里还没有建对应的周期 Task或者 Task 建了但没有归属到 OsApplication导致它在 Rte 看来不合法。解决先去 Os 配置里建一个周期 Task最小系统里 10ms 就够设置好周期和优先级把它挂到默认 OsApplication 上回 Rte 重新校验此时下拉列表里就能选到这个 Task 了。如果还是不行检查这个 Task 是不是被设成了非 AUTOSAR 扩展任务或者被条件编译屏蔽了。5.5 生成代码成功但编译阶段报大量未定义符号现象Configurator 校验零错误代码顺利生成扔进 S32DS 编译时满屏 undeclared identifier 和 undefined reference。原因最常见的是 MCAL 驱动模块没加全——最小系统虽然叫“最小”但 Port、Dio、Mcu、Platform 这几个基础驱动通常还是要有否则生成的初始化代码会引用不存在的函数。其次是编译器选错工程建的时候选了 GCCS32DS 里却按 IAR 的方式配置了链接脚本。解决先看第一个未定义符号属于哪个模块回 Configurator 把它加进工程并配置最简参数再核对工程设置里的编译器与目标芯片是否和建工程时一致。这类问题的排查顺序永远是“先补模块再对工具链”反过来做会浪费大量时间在编译器选项上。6. 把最小系统当基线工程复用三个我踩出来的硬规矩最小系统配通之后最有价值的动作不是接着写业务代码而是立刻把它固化成一份基线工程。后面每上一个新项目从这份基线复制一份改芯片型号和时钟参数就能起步——这一步能省掉每次重头消红叉的两三个小时。我自己的做法是配完当天就做三件事第一把生成前的工程状态打一个快照包括 arxml 配置、SIP 版本号、工具版本号全部记在一个 README 里。AUTOSAR 的工具链对版本极其敏感半年后回来复现一个老工程最大的障碍往往不是代码而是“当时用的是哪个版本的包”。第二把第 5 章那五条排查记录写成清单挂在基线工程的根目录。新人拿到工程后按清单走一遍比口头讲十遍管用。第三把第 4.4 节那段自检脚本放进工程每次改完关键配置就跑一次。下面这张表是我现在每次改配置后固定核对的项改动点需要同步重配的组件验证方式换 MCU 型号vBaseEnv、vBRS、Base、Os重新校验工程红叉归零改主频vBRS、CMU、Os CounterCounter Ticks 重算实测节拍新增周期 TaskOs、Rte Mapping确认 MainFunction 已挂载换编译器工程设置、启动文件、链接脚本全量重新生成并编译新增 SWCDeveloper、Rte、BswM检查 Instance 与端口连接这里有个血泪经验值得单独说改主频这件事千万别只改 vBRS 一个地方。我见过一次因为只改主频没改 Os 的 Counter TicksCAN 通信的超时判定全部失效现象是“偶发丢帧”查了整整两天才回到时钟配置上。从那以后我每次动时钟相关参数都强制走一遍“vBRS → CMU → Os Counter → 实测翻转 GPIO”这条链路一步不跳。还有一个容易被忽略的复用细节基线工程里的 Det 和 BswM 配置是工具自动补的默认值看着没什么内容但删掉会导致一堆模块报错。复制基线时这两个模块要跟着一起走别觉得它们“没配什么”就手工剔掉。最后提醒一句这份教程明确说了启动代码、最小系统编译和调试运行在另一份文档里所以拿到工程能生成代码并不等于能跑起来。生成之后的第一件事仍然是把代码拖进 S32DS 编一遍把未定义符号清干净再谈板上验证。我现在的习惯是每配完一个模块就生成一次、编一次绝不攒到最后一起做——攒着做的结果一定是几十个错误糊在一起分不清哪个是配置问题、哪个是代码问题。希望帮到你。本文还有配套的精品资源点击获取