在Cortex-A8平台下memcpy性能的测试

2024-01-16 04:48
文章标签 平台 性能 测试 memcpy cortex a8

本文主要是介绍在Cortex-A8平台下memcpy性能的测试，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

用goole搜到的一篇文章： 暂时忘记了出处，转到这里吧！

在Cortex-A8平台下memcpy性能的测试

ShuyongChen

前言

在Crun timelibrary中，memcpy是重要的函数，对应用软件的性能有着重要的影响。ARM芯片发展到Cortex-A8[1][2]架构，不但频率有了很大提升，而且架构设计有了很大地改进。其中增加的NEON指令，是类似于原先X86平台下的MMX指令，是为多媒体而设计。但因为这类指令一次可以处理64-bit数据，对memcpy函数性能提升也很有帮助。本文主要是测试采用NEON[2]指令的多种memcpy实现，探讨NEON指令和预取(preload)指令对性能的影响，以及在芯片优化和工艺进步后，这些影响的变化趋势。同时希望芯片设计人员在了解软件实现的基础上，给予一个知其然，也知其所以然的解释，进而指导进一步提高性能的方向。

平台介绍

本次的测试平台来源于笔者工作项目中接触到的Cortex-A8平台。见下面列表：

  • FreeScalei.MX51 / i.MX53

  • QualCommmsm8x50 / msm7x30

  • Samsungs5pc100 / s5pc110

  • TIomap 3430 / omap 3730

i.MX5family

i.MX5family的介绍见[6][7]。其中i.MX535可以运行在800MHZ/ 1000MHZ两种频率上。

  • i.MX515

  • freq:800MHZ

  • cachesize: 32KB/32KB I/D Cache and 256KB L2 Cache

  • cacheline: 64-bit wide(NEON), 64-byte / line

  • i.MX535

  • freq:800MHZ / 1000MHZ

  • cachesize: 32KB/32KB I/D Cache and 256KB L2 Cache

  • cacheline: 64-bit wide(NEON), 64-byte / line

Snapdragonfamily

Snapdragon的介绍见[8][9][10]。其中msm7x30可以运行在800MHZ/ 1000MHZ两种频率上。此外Snapdragoncache特别之处是128-bitwide(NEON), 128-byte / line。标准Cortex-A8中，该数值为64-bitwide(NEON), 64-byte / line。这对性能有较大影响。

  • msm8x50

  • freq:1000MHZ

  • cachesize: 32KB/32KB I/D Cache and 256KB L2 Cache

  • cacheline: 128-bit wide(NEON), 128-byte / line

  • msm7x30

  • freq:800MHZ / 1000MHZ

  • cachesize: 32KB/32KB I/D Cache and 256KB L2 Cache

  • cacheline: 128-bit wide(NEON), 128-byte / line

s5pcfamily

s5pcfamily参考平台见[11]。

  • s5pc100

  • freq:665MHZ

  • cachesize: 32KB/32KB I/D Cache and 256KB L2 Cache

  • cacheline: 64-bit wide(NEON), 64-byte / line

  • s5pc110

  • freq:1000MHZ

  • cachesize: 32KB/32KB I/D Cache and 512KB L2 Cache

  • cacheline: 64-bit wide(NEON), 64-byte / line

omap3family

omap3family参考平台见[12][13][14]。

  • omap3430

  • freq:550MHZ

  • cachesize: 16KB/16KB I/D Cache and 256KB L2 Cache

  • cacheline: 64-bit wide(NEON), 64-byte / line

  • omap3730

  • freq:1000MHZ

  • cachesize: 32KB/32KB I/D Cache and 256KB L2 Cache

  • cacheline: 64-bit wide(NEON), 64-byte / line

memcpy实现介绍

memcpy的实现在ARM平台上的发展有3类版本：

  1. C语言版本

  2. ARM汇编版本

  3. NEON汇编版本

ARM公司的文档[4]对memcpy的实现有很好描述。有人[5][19][20]还进一步阐述了实现原理和技巧。简述如下：

  • NEON指令一次可以处理64-bit数据，效率更高。

  • NEON架构与L1/L2cache都有直连，在OS层级enable后，可以获得更好的性能。

  • ARM/ NEON的pipeline有可能异步处理，交替使用ARM/ NEON指令有可能获得更好的性能。

  • 在一次循环中，用尽可能多的寄存器copy更多的数据，保证pipeline有更好的效率。目前一次最大处理块为128-byte。

  • 对cache的操作有讲究。

  • memcpy属于一次扫瞄无回溯的操作，对于cache采用预取(preload)策略可以提高hitrate。所以汇编版本中一定会使用pld指令提示ARM预先把cacheline填充好。

  • pld指令中的offset很有讲究。一般为64-byte的倍数。在ARMv5TE平台是一个循环用一个pld指令。在Cortex-A8平台上速度更快，需要一个循环用2~3个pld指令填充cacheline。这样一个循环消费2~3个时钟周期换得cachehit rate提高，效果是值得的。

  • 进一步的，Cortex-A8架构提供了preloadengine指令，可以让软件更深地影响cache，以便让cachehit rate得到提高。不过要在用户空间使用ple指令，需要在OS中打补丁开放权限。



C语言版本

C语言版本主要是做对比。采用两个实现：

  1. 32-bitwide copy。后面标记为in32_cpy。

  2. 16-bytewide copy。后面标记为vec_cpy。这个实现的技巧是采用gcc的向量扩展”__attribute__((vector_size(16)))”，在C语言层级实现16-bytewide copy，将具体实现交给编译器。



值得注意的事情是，编译器不会主动插入pld指令。因为编译器无法判断应用对内存的访问模式。

ARM汇编版本

ARM汇编版本也主要是做对比。采用两个实现：

  1. SiarheiSiamashka实现[15]。后面标记为arm9_memcpy。他是为NokiaN770做的优化。

  2. NicolasPitre实现[16]。后面标记为armv5te_memcpy。这是目前glibc里面缺省的armmemcpy实现。

NEON汇编版本

NEON汇编版本采用四个实现：

  1. MånsRullgård实现[19]。这是一个128-byte-alignblock的最简单的实现。没有判断不是128-bytealign的情况。因此不是实用的版本。但通过这类实现，可以考察memcpy性能的极限。他总共提供4种实现。

    1. 全ARM汇编的实现。后面标记为memcpy_arm。此外，笔者还将其中的pld指令去掉，做为对比试验，考察pld指令的影响。后面标记为memcpy_arm_nopld。

    2. 全NEON汇编的实现。后面标记为memcpy_neon。此外，笔者还将其中的pld指令去掉，做为对比试验，考察pld指令的影响。后面标记为memcpy_neon_nopld。

    3. ARM/NEON指令交替使用的实现。后面标记为memcpy_armneon。此外，笔者还将其中的pld指令去掉，做为对比试验，考察pld指令的影响。后面标记为memcpy_armneon_nopld。

    4. ple+NEON的实现。后面标记为memcpy_ple_neon。此外，笔者还将其中的NEON指令换成ARM指令，做为对比试验，考察ple指令对ARM/NEON指令的影响。后面标记为memcpy_ple_arm。因为这个实现需要对linuxkernel打补丁，在omap3430平台上没有成功。在Snapdragon平台上更换kernel有些麻烦，所以也没有测试。

  2. CodeSourcery实现[17]。这是CodeSourcerytoolchain中的glibc里面的实现。也分两种实现。

    1. ARM实现。后面标记为memcpy_arm_codesourcery。笔者还将其中的pld指令去掉，做为对比试验，考察pld指令的影响。后面标记为memcpy_arm_codesourcery_nopld。

    2. NEON实现。后面标记为memcpy_neon_codesourcery。这也是Androidbionic里面采用的NEON实现。笔者还将其中的pld指令去掉，做为对比试验，考察pld指令的影响。后面标记为memcpy_neon_codesourcery_nopld。

  3. QualComm实现[18]。后面标记为memcpy_neon_qualcomm。这是QualComm在CodeAurora Forum中为Snapdragon平台开发的优化版本。主要是对8660/8650A平台的优化。这个版本的特点是针对L2cache line size ＝ 128bytes而设计，pldoffset设置得特别大。结果在其它Cortex-A8平台上没有效果。所以笔者将pldoffset改为MånsRullgård实现的数值。笔者还将其中的pld指令去掉，做为对比试验，考察pld指令的影响。后面标记为memcpy_neon_qualcomm_nopld。

  4. SiarheiSiamashka实现[20]。后面标记为memcpy_neon_siarhei。这是SiarheiSiamashka向glibc提交的NEON版本，没有被glibc采纳。但是在MAEMO项目中得到采用。这个版本的特点是pldoffset是从小到大增长的，以期望适应blocksize的变化。

测试方案介绍

测试方案十分简单。参考了movialmemory tester的实现[21]。执行步骤如下：

  1. 先对每个实现进行正确性的验证。主要方法是以随机的blocksize & offset，填充随机的内容，然后执行memcpy操作，然后再用系统的memcmp函数对两块内存做校验。

  2. 然后对每个实现以不同的blocksize调用400次。如果totalcopy size < 1MB，则增加count直到满足要求。对总操作计时。

  3. 以totalcopy size / total copy time公式计算memcpybandwidth。



上述提到的blocksize = 2^n ( 7 <= n <= 23 )。



此外，这个测试程序运行在openembedded-gpe软件系统中。QualComm/Samsung硬件平台只提供Android软件系统，要更换到GPE系统有些麻烦，则采用chroot方式进行测试。不论是哪种软件平台，都是进入到图形系统后，静置，等待黑屏，然后再进行测试。



下表是运行环境的统计。

硬件平台

软件环境

imx51800MHZ

openembedded-gpe

imx531000MHZ

openembedded-gpe

imx53800MHZ

openembedded-gpe

msm72301000MHZ

Android+ chroot

msm7230800MHZ

Android+ chroot

msm82501000MHZ

Android+ chroot

omap3430550MHZ

openembedded-gpe

omap37301000MHZ

openembedded-gpe

s5pc100665MHZ

Android+ chroot

s5pc1101000MHZ

Android+ chroot



下表是测试项目的统计。

实现方案

i.MX51

i.MX53

Snapdragon

s5pc1xx

omap3430

omap3730

int32_cpy

YES

YES

YES

YES

YES

YES

vec_cpy

YES

YES

YES

YES

YES

YES

arm9_memcpy

YES

YES

YES

YES

YES

YES

armv5te_memcpy

YES

YES

YES

YES

YES

YES

memcpy_arm

YES

YES

YES

YES

YES

YES

memcpy_arm_nopld

YES

NO

YES

YES

YES

YES

memcpy_neon

YES

YES

YES

YES

YES

YES

memcpy_neon_nopld

YES

NO

YES

YES

YES

YES

memcpy_armneon

YES

YES

YES

YES

YES

YES

memcpy_ple_arm

YES

YES

N/A

YES

N/A

YES

memcpy_ple_neon

YES

YES

N/A

YES

N/A

YES

memcpy_arm_codesourcery

YES

YES

YES

YES

YES

YES

memcpy_arm_codesourcery_nopld

YES

NO

YES

YES

YES

YES

memcpy_neon_codesourcery

YES

YES

YES

YES

YES

YES

memcpy_neon_codesourcery_nopld

YES

NO

YES

YES

YES

YES

memcpy_neon_qualcomm

YES

YES

YES

YES

YES

YES

memcpy_neon_qualcomm_nopld

YES

NO

YES

YES

YES

YES

memcpy_neon_siarhei

YES

YES

YES

YES

YES

YES

注1：因为i.MX53EVK板子发生故障，未能测试所有nopld的测试项。

注2：在给omap3430打开preloadengine后，测试产生非法指令错，未能测试ple的测试项。

注3：要替换Snapdragonkernel有些麻烦， 未能测试ple的测试项。

测试结果与分析

下面的图表限于页面大小不能很好地显示细节。具体的数据和大图可到数据表文档中查看。

各个硬件平台上各种实现的表现

  1. imx51800MHZ





  1. imx531000MHZ





  1. imx53800MHZ





  1. msm72301000MHZ





  1. msm7230800MHZ





  1. msm82501000MHZ





  1. omap3430550MHZ





  1. omap37301000MHZ





  1. s5pc100665MHZ





  1. s5pc1101000MHZ





  1. 小结

  1. 在blocksize = 512B ~ 32K之间，有一个性能高台，blocksize = 256K也有一个性能的转折。

    1. 这个特性体现了32KBL1 / 256KB L2 cache的影响。

    2. 小于512B的性能不佳，可能与函数调用，函数开始的块对齐技巧造成的损耗有关，也可能与blocksize太小，cache没有准备好函数就结束了有关。

  2. 文档[]对memcpy的实现还是有指导意义的。但随着芯片内部的优化和工艺的提升，有些规则发生了变化。

    1. NEON指令的性能总是要高于ARM指令的性能。但交替使用ARM/NEON指令并不总是带来性能的提升。随着发展ARM/NEON指令之间性能差在缩小。

    2. pld指令的作用越来越小。在较老的芯片上，如omap3430，采用pld指令后，同一个实现可以有50%的性能提升。在较新的芯片上，如msm7230/s5pc110上，性能基本没有区别，甚至同一个实现没有pld指令后，性能稍稍有些提升。这也许是因为pld指令没有效果，倒反在每个循环中浪费了时钟周期造成的。

    3. 采用ple指令的实现的性能令人大失所望。这也说明如果没有很好的模型设计，软件去干预cache的使用，很容易会造成性能的恶化。

  3. Snapdragon平台有最好的cache性能。超出cache后，各种实现(包括C语言实现)的性能基本一致，也很高效。这也许是Snapdragon平台13-stageload/storepipeline[][]的设计造成的。这个特性对高级语言是有好处的。因为编程不可能在很多地方采用汇编语言。这样开发人员就不必过多地考虑汇编优化，依赖编译器就可以了。

  4. s5pc110平台有最好的平均性能。超出cache后，NEON实现的性能最好，基本保持一条水平线。

在small/bigblock size下各个硬件平台的表现

性能因为blocksize分为fitin cache / out of cache两种表现，所以做两个剖面做对比分析。

  • 8Kblock size。体现fitin cache时的性能。

  • 8Mblock size。体现outof cache时的性能。

MånsRullgård的实现

因为MånsRullgård的实现最简单，除了一个循环体外，没有其它判断代码，可以认为是体现平台速度极限的实现。





ARM的实现









NEON的实现









小结

  1. NEON指令的性能总是要高于ARM指令的性能。随着发展ARM/NEON指令之间性能差在缩小。

  2. 交替使用ARM/NEON指令，在fitin cache条件下性能要差于NEON版本。在outof cache条件下，两个版本性能基本一样。

  3. 在fitin cache条件下，Snapdragon平台有最好的性能。超过第二名s5pc110大约为43%。

  4. 在outof cache条件下，s5pc110有最好的性能。超过第二名omap3730大约为57%。

  5. 在同一个硬件平台下，超频(如i.MX53800/1000MHZ & msm7x30 800/1000MHZ)对memory性能影响很小。

实用ARM/NEON实现在各个硬件平台的表现

通过同一种实现在不同硬件平台上性能的对比，结合上一节的图表，可以评价一种实现的平均性能，也就是适应性。

ARM的实现













NEON的实现













小结

  1. 同一种的实现，在不同的硬件平台上都有不同的表现。没有一种实现在所有平台上是最好的。

  2. Codesourcery版本，包括ARM/NEON版本，有很好的适应性。不愧是做toolchain的公司。

  3. SiarheiSiamashka的NEON版本也有很好的适应性。NOKIA的技术实力也很强。这哥们好像也是pixman项目里面做NEON优化的主力。

  4. Qualcomm版本只适合Snapdragon平台。期待以后能在msm8660以及后续的芯片上进行测试。

总结

  1. 在blocksize = 512B ~ 32K之间，有一个性能高台，blocksize = 256K也有一个性能的转折。这个特性体现了32KBL1 / 256KB L2 cache的影响。

  2. NEON指令的性能总是要高于ARM指令的性能。随着发展ARM/NEON指令之间性能差在缩小。交替使用ARM/NEON指令，性能往往要差于NEON版本。

  3. 如果没有很好的模型设计，软件去干预cache的使用，很容易会造成性能的恶化。

  4. 在fitin cache条件下，Snapdragon平台有最好的性能。

  5. 在outof cache条件下，s5pc110有最好的性能。

  6. 在同一个硬件平台下，超频对memory性能影响很小。

  7. 同一种的实现，在不同的硬件平台上都有不同的表现。没有一种实现在所有平台上是最好的。

进一步的测试

因为在Cortex-A8系列芯片里，NEON模块是必有的。而在Cortex-A9系列芯片里，NEON模块是可选的。因为NEON模块会影响到diesize，因而影响功耗和成本。因此有些Cortex-A9芯片，如NvidiaTegra250，没带有NEON模块。那么有无NEON模块会对软件性能造成什么样的影响呢？

参考文档

  1. ARMCortex-A8

http://en.wikipedia.org/wiki/ARM_Cortex-A8



  1. Cortex™-A8Technical Reference Manual

http://infocenter.arm.com/help/topic/com.arm.doc.ddi0344k/index.html



  1. c0,Cache Size Identification Registers

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344f/Chdebced.html



  1. Whatis the fastest way to copy memory on a Cortex-A8?

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka13544.html



  1. ARM-NEONmemory hazards

http://hardwarebug.org/2008/12/31/arm-neon-memory-hazards/



  1. i.MX5family

http://en.wikipedia.org/wiki/I.MX



  1. Freescalei.MX515

http://www.7-cpu.com/cpu/imx515.html



  1. Snapdragon(System on Chip)

http://en.wikipedia.org/wiki/Snapdragon_(System_on_Chip)



  1. QualcommReveals Details on Scorpion Core

http://www.bdti.com/InsideDSP/2007/11/14/Qualcomm



  1. QualcommSnapdragon

http://www.7-cpu.com/cpu/Snapdragon.html



  1. ODROID

http://hardkernel.com/



  1. OMAP3family

http://en.wikipedia.org/wiki/OMAP3



  1. OmapWorld

http://omapworld.com/



  1. beagleboard

http://beagleboard.org/



  1. SiarheiSiamashka: Optimized Memory Copying Functions For Nokia 770

http://lists.maemo.org/pipermail//maemo-developers/2006-March/003269.html



  1. NicolasPitre: ARM memcpy and memmove

http://sourceware.org/ml/libc-ports/2006-10/msg00024.html



  1. CodeSourceryC Library

http://www.codesourcery.com/



  1. Neonmemcpy: Attempts to do a memcpy with Neon registers if possible

https://www.codeaurora.org/patches/quic/qsd/SAMPLE_3918_NEON_MEMOPS_20101001.tar.gz



  1. MånsRullgård: memory bandwidth problem - Beagle Board

http://groups.google.com/group/beagleboard/browse_thread/thread/12c7bd415fbc0993/c54dde7b9d55cf99



  1. SiarheiSiamashka: ARM: NEON optimized implementation of memcpy

http://sourceware.org/ml/libc-ports/2009-07/msg00003.html



  1. Memorytester

http://sandbox.movial.com/gitweb?p=mmem.git;a=summary



这篇关于在Cortex-A8平台下memcpy性能的测试的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！


http://www.chinasem.cn/article/611388。

相关文章

Vue3 的 shallowRef 和 shallowReactive：优化性能

Vue3 的 shallowRef 和 shallowReactive：优化性能

大家对 Vue3 的 ref 和 reactive 都很熟悉，那么对 shallowRef 和 shallowReactive 是否了解呢？ 在编程和数据结构中，“shallow”（浅层）通常指对数据结构的最外层进行操作，而不递归地处理其内部或嵌套的数据。这种处理方式关注的是数据结构的第一层属性或元素，而忽略更深层次的嵌套内容。 1. 浅层与深层的对比 1.1 浅层（Shallow） 定义
阅读更多...
流媒体平台/视频监控/安防视频汇聚EasyCVR播放暂停后视频画面黑屏是什么原因？

流媒体平台/视频监控/安防视频汇聚EasyCVR播放暂停后视频画面黑屏是什么原因？

视频智能分析/视频监控/安防监控综合管理系统EasyCVR视频汇聚融合平台，是TSINGSEE青犀视频垂直深耕音视频流媒体技术、AI智能技术领域的杰出成果。该平台以其强大的视频处理、汇聚与融合能力，在构建全栈视频监控系统中展现出了独特的优势。视频监控管理系统EasyCVR平台内置了强大的视频解码、转码、压缩等技术，能够处理多种视频流格式，并以多种格式（RTMP、RTSP、HTTP-FLV、WebS
阅读更多...
性能测试介绍

性能测试介绍

性能测试是一种测试方法，旨在评估系统、应用程序或组件在现实场景中的性能表现和可靠性。它通常用于衡量系统在不同负载条件下的响应时间、吞吐量、资源利用率、稳定性和可扩展性等关键指标。 为什么要进行性能测试 通过性能测试，可以确定系统是否能够满足预期的性能要求，找出性能瓶颈和潜在的问题，并进行优化和调整。 发现性能瓶颈：性能测试可以帮助发现系统的性能瓶颈，即系统在高负载或高并发情况下可能出现的问题
阅读更多...
字节面试 | 如何测试RocketMQ、RocketMQ？

字节面试 | 如何测试RocketMQ、RocketMQ？

字节面试：RocketMQ是怎么测试的呢？ 答： 首先保证消息的消费正确、设计逆向用例，在验证消息内容为空等情况时的消费正确性； 推送大批量MQ，通过Admin控制台查看MQ消费的情况，是否出现消费假死、TPS是否正常等等问题。（上述都是临场发挥，但是RocketMQ真正的测试点，还真的需要探讨） 01 先了解RocketMQ 作为测试也是要简单了解RocketMQ。简单来说，就是一个分
阅读更多...
性能分析之MySQL索引实战案例

性能分析之MySQL索引实战案例

文章目录 一、前言二、准备三、MySQL索引优化四、MySQL 索引知识回顾五、总结 一、前言 在上一讲性能工具之 JProfiler 简单登录案例分析实战中已经发现SQL没有建立索引问题，本文将一起从代码层去分析为什么没有建立索引？ 开源ERP项目地址：https://gitee.com/jishenghua/JSH_ERP 二、准备 打开IDEA找到登录请求资源路径位置
阅读更多...
综合安防管理平台LntonAIServer视频监控汇聚抖动检测算法优势

综合安防管理平台LntonAIServer视频监控汇聚抖动检测算法优势

LntonAIServer视频质量诊断功能中的抖动检测是一个专门针对视频稳定性进行分析的功能。抖动通常是指视频帧之间的不必要运动，这种运动可能是由于摄像机的移动、传输中的错误或编解码问题导致的。抖动检测对于确保视频内容的平滑性和观看体验至关重要。 优势 1. 提高图像质量 - 清晰度提升：减少抖动，提高图像的清晰度和细节表现力，使得监控画面更加真实可信。 - 细节增强：在低光条件下，抖
阅读更多...
JAVA智听未来一站式有声阅读平台听书系统小程序源码

JAVA智听未来一站式有声阅读平台听书系统小程序源码

智听未来，一站式有声阅读平台听书系统 🌟&nbsp;开篇：遇见未来，从“智听”开始 在这个快节奏的时代，你是否渴望在忙碌的间隙，找到一片属于自己的宁静角落？是否梦想着能随时随地，沉浸在知识的海洋，或是故事的奇幻世界里？今天，就让我带你一起探索“智听未来”——这一站式有声阅读平台听书系统，它正悄悄改变着我们的阅读方式，让未来触手可及！ 📚&nbsp;第一站：海量资源，应有尽有 走进“智听
阅读更多...
如何解决线上平台抽佣高 线下门店客流少的痛点！

如何解决线上平台抽佣高 线下门店客流少的痛点！

目前，许多传统零售店铺正遭遇客源下降的难题。尽管广告推广能带来一定的客流，但其费用昂贵。鉴于此，众多零售商纷纷选择加入像美团、饿了么和抖音这样的大型在线平台，但这些平台的高佣金率导致了利润的大幅缩水。在这样的市场环境下，商家之间的合作网络逐渐成为一种有效的解决方案，通过资源和客户基础的共享，实现共同的利益增长。 以最近在上海兴起的一个跨行业合作平台为例，该平台融合了环保消费积分系统，在短
阅读更多...
Android平台播放RTSP流的几种方案探究（VLC VS ExoPlayer VS SmartPlayer）

Android平台播放RTSP流的几种方案探究（VLC VS ExoPlayer VS SmartPlayer）

技术背景 好多开发者需要遴选Android平台RTSP直播播放器的时候，不知道如何选的好，本文针对常用的方案，做个大概的说明： 1. 使用VLC for Android VLC Media Player（VLC多媒体播放器），最初命名为VideoLAN客户端，是VideoLAN品牌产品，是VideoLAN计划的多媒体播放器。它支持众多音频与视频解码器及文件格式，并支持DVD影音光盘，VCD影
阅读更多...
【测试】输入正确用户名和密码，点击登录没有响应的可能性原因

【测试】输入正确用户名和密码，点击登录没有响应的可能性原因

目录 一、前端问题 1. 界面交互问题 2. 输入数据校验问题 二、网络问题 1. 网络连接中断 2. 代理设置问题 三、后端问题 1. 服务器故障 2. 数据库问题 3. 权限问题： 四、其他问题 1. 缓存问题 2. 第三方服务问题 3. 配置问题 一、前端问题 1. 界面交互问题 登录按钮的点击事件未正确绑定，导致点击后无法触发登录操作。 页面可能存在
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2