3W1H和5W1H分析方法的区别

在用户研究中我们经常会使用3W1H、5W1H这些分析方法,那么为什么会有3W1H,5W1H这样的分析方法,这两个方法有什么差异和不同?因此就展开了资料搜集,接下来让我们看看他们到底有何不同,以及分析方法的延伸,和在用户研究工作中使用的注意点。
在工作中,我们时常会用到下列的方法:

理论方法

5W理论
美国学者H·拉斯维尔于1948年在《传播在社会中的结构与功能》一篇论文中,首次提出了构成传播过程的五种基本要素,并按照一定结构顺序将它们排列,形成了后来人们称之“五W模式”或“拉斯维尔程式”的过程模式。这五个W分别是英语中五个疑问代词的第一个字母,即:
Who ---------谁
Says What ---------说了什么
In Which Channal ---------通过什么渠道
To Whom ---------向谁说
With What Effect ---------有什么效果

5W1H分析方法
5W1H分析法也称六何分析法,是一种思考方法,也可以说是一种创造技法。是对选定的项目、工序或操作,都要从原因(WHY)、对象(WHAT)、地点(WHERE)、时间(WHEN)、人员(WHO)、方法(HOW)等六个方面提出问题进行思考。这种看似很可笑、很天真的问话和思考办法,可使思考的内容深化、科学化。
why---------为什么要做,是原因;
what--------做什么,做成什么,是目标;
where-------在哪儿做,是地点;
when--------什么时候做,是时间;
who---------谁来做,是执行对象;
how---------怎么做,是方法。

3W1H分析方法
what --------做什么
who --------谁来做
when --------什么时候做
how---------怎么做

在用户研究中的应用

5W1H & 3W1H哪种方法更好?
在于我们研究分析的粒度,如果我们只是针对产品的某些功能进行前期概括性研究,那么3W1H方法有时候就足够了。
如果我们需要研究详细的功能点和发生的场景,那么5W1H的方法更适用。对于互联网产品来说,我们需要确定用户是在哪种场景中才会使用某个功能或者产品,因此where、when是非常关键的因素,这里的where可以是某个竞品的某个功能,也可能是我们自身产品的某个功能位置。
5W1H的方法更加有助于我们发现特定场景下用户的需求差异。因此3W1H相对来说只能回答我们用户在什么时候是如何做了怎样的事情。
同时5W1H也有弊端,5W1H中有why这个维度,通过询问原因我们可以了解用户为何会在特定场景下做某个动作,但这里也需要我们注意用户说出来的why和真正的why是不是一致,这也就要求我们的用户研究人员通过分析去判断真正的原因。
技巧:
1.在整个访谈过程中针对某个关键问题换一种方式多问几个why,这样用户也会越来越对自己的真正原因更加清晰。
2.综合用户行为来判断背后的真实原因。
3.虽然用户说出来的why和真正的why有时候存在差异,但我也认为直接询问用户why还是有必要的,通过用户真实的语言和动作也可以观察和判断是否是真正的原因。

延伸阅读

在研究资料的同时,我也发现了更多的W相关的方法,但更多使用于企业管理、工业工程工作中。涉及效果、成本监控,以及如何优化工程程序。其实也可有一定程度的价值。


1、5W2H分析方法

又叫七何分析法,是二战中美国陆军兵器修理部首创。简单、方便,易于理解、使用,富有启发意义,广泛用于企业管理和技术活动,对于决策和执行性的活动措施也非常有帮助,也有助于弥补考虑问题的疏漏。



2、5W2H1E分析法
任何一种企划书的构成都必须有5W2H1E,共8个基本要素。所谓的5W2H1E即:
What(什么)–企划的目的、内容。
Who( 谁)–企划相关人员。
Where( 何处)–企划实施场所。
When(何时)–企划的时间。
Why(为什么)–企划缘由、前景。
How(如何)–企划的方法和运转实施。
How much(多少)–企划预算。
Effect(效果)–预测企划结果、效果。


3、ECRS分析法

ECRS分析法,是工业工程学中程序分析的四大原则,用于对生产工序进行优化,以减少不必要的工序,达到更高的生产效率。ECRS,即取消(Eliminate)、合并(Combine)、调整顺序(Rearrange)、简化(Simplify)。
取消(Eliminate):“作业要素能完成什么,完成的有否价值?是否必要动作或作业?为什么要完成它?”,“该作业取消对其它作业或动作有否影响”。
合并(Combine):如果工作或动作不能取消,则考虑能否可与其他工作合并,或部分动作或工作合并到其它可合并的动作或作业中。
重排(Rearrange):对工作的顺序进行重新排列。
简化(Simplify):指工作内容和步骤的简化,亦指动作的简化,能量的节省。
在进行5W1H分析的基础上,可以寻找工序流程的改善方向,构思新的工作方法,以取代现行的工作方法。运用ECRS四原则,即取消、合并、重组和简化的原则,可以帮助人们找到更好的效能和更佳的工序方法。

<think>好的,我现在需要解决用户在编译FFmpeg时遇到的错误:`./libavutil/aarch64/bswap.h:33:13: error: invalid instruction mnemonic &#39;rev16&#39;`。用户的环境是Android aarch64交叉编译,使用了LLVM工具链。首先,我需要理解这个错误的原因。 首先,错误提示是“invalid instruction mnemonic &#39;rev16&#39;”,意味着编译器不识别这个指令。可能的原因是什么?aarch64架构的汇编指令是否有变化?或者工具链的问题? 我记得在ARM架构中,不同的指令集可能有不同的指令名称。例如,AArch32AArch64可能有不同的指令。用户是在交叉编译到aarch64,也就是ARM64架构。而rev16指令在AArch64中是否存在呢? 查一下ARM的文档,AArch64的指令集确实有rev16,但可能语法不同。或者,可能在某个版本的编译器中对指令的支持有变化。也有可能用户使用的工具链版本较低,不支持这个指令的某种写法。 另外,用户使用的交叉编译工具链是LLVM,即clangllvm-as等。clang在处理内联汇编时可能与GCC有不同的要求。例如,寄存器前缀是否需要使用%w表示32位寄存器,而%x表示64位?在AArch64中,寄存器的名称可能是w0或x0,而不是%w0。可能内联汇编的语法在这里有问题。 原来的代码是:`__asm__("rev16 %w0, %w1" : "=r"(y) : "r"(x));`。这里使用了%w0%w1作为寄存器,而rev16指令在AArch64中是否接受这样的操作数? 或者,是否存在指令名称的大小写问题?比如是否需要写成REV16而不是rev16?不过ARM汇编通常是大小写不敏感的,但可能需要检查。 另一个可能性是,这个内联汇编代码原本是针对GCC编写的,而Clang在处理时可能有不同的要求。例如,Clang是否要求不同的语法结构,比如必须明确指定寄存器的位数? 假设问题出在寄存器前缀上,AArch64的寄存器是64位的,但这里使用的是%w0,这代表的是寄存器的低32位。而rev16指令在AArch64中可能需要操作64位寄存器。例如,正确的指令是否是rev16 x0, x1,而不是w0? 或者,rev16指令在AArch64中是否有不同的变体?例如,是否有rev16的32位64位版本? 查阅ARM的文档,发现AArch64的rev16指令确实存在,但它操作的是32位或64位寄存器的字节顺序。例如,`rev16 w0, w1` 是处理32位寄存器的低16位的字节反转,而`rev16 x0, x1` 是处理64位寄存器的每个16位部分的字节反转。所以,当目标寄存器是32位时,使用w寄存器,否则使用x寄存器。 那么,问题可能出在内联汇编中使用了%w0,而Clang可能期望不同的语法。例如,是否应该使用%0%1,让编译器自动分配寄存器,而不是显式指定w寄存器? 或者,Clang是否要求在内联汇编中使用不同的模板语法?例如,是否需要使用模板修饰符,如%w0改成%w0,或者是否应该省略w前缀,让编译器自动处理? 另外,Clang对于内联汇编的处理可能更严格,特别是在寄存器名称的使用上。例如,GCC可能允许使用%w0来表示32位寄存器,但Clang可能需要不同的表示方式,比如直接使用w0或者x0,或者使用模板修饰符。 另一个可能的问题是Clang的版本。如果用户使用的Clang版本较旧,可能不支持某些指令的内联汇编写法。需要检查Clang的版本,并确认是否支持rev16指令的当前写法。 此外,FFmpeg的代码库可能有针对不同编译器的条件编译。例如,可能存在某些宏定义用于处理GCCClang的区别。用户是否在配置时启用了适当的功能或宏? 用户提供的配置命令中使用了--cc=$TOOLCHAIN/bin/clang,说明使用的是Clang编译器。因此,可能需要调整内联汇编代码以适应Clang的语法。 可能的解决方案是修改bswap.h中的内联汇编语句,使其符合Clang的要求。例如,将%w0改为%0,并让编译器自动处理寄存器的位数,或者显式使用x寄存器。 例如,将原来的: __asm__("rev16 %w0, %w1" : "=r"(y) : "r"(x)); 改为: __asm__("rev16 %0, %1" : "=r"(y) : "r"(x)); 或者,可能需要使用不同的寄存器修饰符,如%w0在Clang中是否需要写成%x0或其他形式? 另外,查阅Clang的文档,发现Clang在处理AArch64内联汇编时,寄存器名称可以使用w0到w30表示32位寄存器,x0到x30表示64位寄存器。因此,在指令中使用%w0可能正确,但需要确认rev16是否接受这样的操作数。 如果rev16指令需要64位寄存器,而这里使用的是32位寄存器(%w0),则可能导致错误。例如,rev16在AArch64中可能只接受64位寄存器,所以应该使用x寄存器: __asm__("rev16 %x0, %x1" : "=r"(y) : "r"(x)); 但这里变量yx的类型是什么?如果它们是32位整数,那么使用x寄存器可能会出错。或者,可能编译器会自动处理类型转换? 另一个可能性是,rev16指令在AArch64中实际对应的内在函数或宏已经存在,可以使用编译器内置函数代替内联汇编,从而避免这个问题。例如,使用__builtin_bswap16或类似的函数。 检查FFmpeg的代码,看看是否有条件编译的部分,当使用Clang时采用不同的实现。如果没有,可能需要向FFmpeg提交补丁,或者手动修改本地代码。 例如,在libavutil/aarch64/bswap.h中,是否有针对Clang的特殊处理?如果没有,可以尝试将指令改为rev16的适当形式,或者使用内置函数。 可能的临时解决方案是修改该文件中的对应行,将rev16改为正确的指令格式,或者使用其他方法实现字节交换。 总结可能的原因解决方案: 1. 内联汇编语法不适应Clang,需要调整寄存器名称或指令格式。 2. rev16指令在目标架构或工具链中不可用,需要使用替代方法。 3. 工具链版本过低,需要升级Clang。 4. FFmpeg代码需要针对Clang进行适配,可能需要打补丁或修改代码。 用户需要检查这些可能性,并尝试相应的解决方案。</think>根据你遇到的 `rev16` 指令错误,这一问题通常与 **内联汇编语法不兼容 Clang 编译器** 或 **目标架构指令集支持** 相关。以下是详细的解决方案: --- ### **1. 问题根源分析** 错误信息: ```bash ./libavutil/aarch64/bswap.h:33:13: error: invalid instruction mnemonic &#39;rev16&#39; __asm__("rev16 %w0, %w1" : "=r"(y) : "r"(x)); ``` - **直接原因**:Clang 编译器在解析 AArch64 内联汇编时,对 `rev16` 指令的寄存器格式(`%w0`)不兼容。 - **深层原因**: - `rev16` 是 ARM 指令,用于反转 16 位数据的字节序。 - **Clang 内联汇编语法**与 GCC 存在差异,可能需调整寄存器格式或指令写法。 - 目标工具链(如 NDK 版本)可能未完全支持该指令的特定写法。 --- ### **2. 解决方案** #### **方法 1:修改内联汇编语法(推荐)** 直接调整 `bswap.h` 中的汇编代码,适配 Clang 语法: ```c // 原始代码(GCC 风格): __asm__("rev16 %w0, %w1" : "=r"(y) : "r"(x)); // 修改为(Clang 风格): __asm__("rev16 %0, %1" : "=r"(y) : "r"(x)); // 删除 %w 寄存器限定符 ``` - **原理**:Clang 可能不需要显式指定寄存器位数(如 `%w0`),使用通用占位符 `%0` `%1` 让编译器自动分配。 - **操作步骤**: 1. 找到文件 `libavutil/aarch64/bswap.h` 第 33 行。 2. 修改 `rev16 %w0, %w1` 为 `rev16 %0, %1`。 3. 重新编译 FFmpeg。 #### **方法 2:使用编译器内置函数替代** 若 `rev16` 的功能可通过编译器内置函数实现,可替换汇编代码: ```c // 替换为: y = __builtin_bswap16(x); // 使用 Clang 内置函数 ``` - **验证**:检查 `__builtin_bswap16` 是否在 Clang 中支持(通常可用)。 #### **方法 3:升级工具链** 若问题由旧版 NDK/Clang 导致,尝试升级工具链: ```bash # 更新 NDK 至 r25+ 或更高版本 sdkmanager --update sdkmanager --install "ndk;25.2.9519653" ``` #### **方法 4:检查 FFmpeg 补丁** 查看 FFmpeg 官方是否已修复此问题: ```bash git checkout origin/master # 更新到最新代码 git log --grep="aarch64 bswap" # 搜索相关提交 ``` - 若存在补丁,同步代码后重新编译。 --- ### **3. 验证修改** 重新编译并检查错误是否消失: ```bash make clean && make -j$(nproc) ``` - **关键检查点**: - 确认 `bswap.h` 修改后的代码被正确编译。 - 确保无其他架构相关错误(如新的指令不兼容)。 --- ### **4. 扩展排查** 若问题仍未解决,进一步检查: 1. **工具链兼容性**: ```bash $TOOLCHAIN/bin/clang --version # 确认 Clang 版本 >= 12.0 ``` 2. **汇编指令支持**: - 确认 `rev16` 在 AArch64 指令集中有效([ARM 文档](https://developer.arm.com/documentation/dui0801/b/A64-Data-Transfer-Instructions/REV16))。 3. **简化测试**: 编写一个独立测试文件验证 `rev16` 指令: ```c // test_rev16.c int main() { int x = 0x1234, y; __asm__("rev16 %0, %1" : "=r"(y) : "r"(x)); return y; } ``` 编译并运行: ```bash $TOOLCHAIN/bin/clang test_rev16.c -o test_rev16 && ./test_rev16 ``` --- ### **5. 替代方案** 若仍无法解决,可尝试: 1. **禁用 AArch64 优化**: ```bash ./configure ... --disable-asm ``` - 注意:这会降低性能,仅用于临时绕过问题。 2. **提交 Issue**: 向 FFmpeg 社区反馈此问题,提供完整错误日志编译环境信息。 --- 通过上述步骤,应能解决 `rev16` 指令导致的编译错误。如果问题仍存在,请提供以下信息以便进一步分析: 1. `clang --version` 输出。 2. 修改后的 `bswap.h` 代码片段。 3. 完整的 `make` 错误日志。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

领头喵

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值