首先是声明：
目前版本的emotePlayer只是用来测试兼容性以及证明“可用”，并非“实用”版本，希望有较完美/流畅体验的玩家，还是等待未来更加完善的版本为好。
另外，艹车只支持DX/D3D版本的emote，最快也要一两个版本之后才能实现，届时原生KR2版本（也就是目前1.2.5实现的版本）的性能也会有极大提升。
然后是可以无视的正文（以下测试都在某渣渣荣耀4x上进行）：
在两周前，emote插件总算编码完成（当然，到目前为止都还不算完美），真是可喜可贺。在PC上测试能到20+FPS，那还是没开优化的情况下。
于是抱着激动的心情放进手机测试，然而映照在我懵逼的表情上的，是无情的1.8FPS（猫娘x1）。
测试了一下各模块的耗时，发现了不少计算密集的函数耗时很多（基本都与绘图相关），便决定尝试进行代码优化。
在阅读了一些手册教程之后，带着新的理解重新审阅之前的代码，只感叹自己写的代码还是很有改进的潜力的。
于是陷入了那似乎永无止境的优化之中……
……苦逼优化中……
优化的成果还是相当喜人的，帧数从1.8FPS（猫娘x1）提升到了5.1FPS（猫娘x1），四舍五入就是2倍的性能提升有木有！
……喜人你妹！最后的结论是，结果还是被CPU绘图给拖累了。抱着试一试的想法切换成OpenGL，果然画面变得乱七八糟，而且帧数变成了更悲惨的0.7FPS（猫娘x1）。
没办法，之前做motionPlayer完全没有为GPU设计渲染，完全走的CPU处理路线，以至于切换到OpenGL后产生了大量的CPU->GPU->CPU->...的数据交换，浪费了大量的时间。
只好再继续实现OpenGL的兼容设计。在这期间也发现艹车和艹猫都有设计完全D3D绘图的流程，彻底抛弃KR2原生的绘图方式，这才是正途有木有！KR2那绘图简直太反GPU了。
于是这回在改进emotePlayer/motionPlayer时，也保留了将来为支持全GPU渲染流程的扩展，当然那工程量太大，现在能做的也只是为将来的功能先铺铺路。
……苦逼优化中……
最终，开启了OpenGL后，一只猫的情况下能有15~17FPS，总算脱离了“卡到想砸手机”的程度。
至此，初始版emotePlayer插件算是可以进入公测阶段了。
附这期间的一些心得：
一篇极好的neon汇编教程+范例：
https://people.xiph.org/~tterribe/daala/neon_tutorial.pdf
（给自己看的？）NEON汇编笔记：
·进入NEON指令代码时，实际执行时间会有所延迟
｜如果处理量太少，使用NEON指令并无优势
·与内存的数据交换消耗的时钟周期较多，需要多费心优化
｜声明内存对齐可以成倍减少时钟周期，栈上的变量也在对齐后传给SIMD指令
｜A8芯片在前后两条指令分别是字节存取/字节变换（即非数值运算）指令和数值运算指令时，可以并行处理
｜↑尽量不要在加载指令后立马就使用数据，规划好数值计算指令和字节存取/变换指令，尽量交错处理
｜就算专门为A8优化，也不用担心A9及之后的CPU会导致性能下降
｜PLD并不是万能的，多耗费了一个周期，有时却完全没有性能提升，反而还会下降
｜↑在掌握的理论还不足以运用于实践时，只能无奈地反复测试来验证PLD可用与否
目前版本的emotePlayer只是用来测试兼容性以及证明“可用”，并非“实用”版本，希望有较完美/流畅体验的玩家，还是等待未来更加完善的版本为好。
另外，艹车只支持DX/D3D版本的emote，最快也要一两个版本之后才能实现，届时原生KR2版本（也就是目前1.2.5实现的版本）的性能也会有极大提升。
然后是可以无视的正文（以下测试都在某渣渣荣耀4x上进行）：
在两周前，emote插件总算编码完成（当然，到目前为止都还不算完美），真是可喜可贺。在PC上测试能到20+FPS，那还是没开优化的情况下。
于是抱着激动的心情放进手机测试，然而映照在我懵逼的表情上的，是无情的1.8FPS（猫娘x1）。
测试了一下各模块的耗时，发现了不少计算密集的函数耗时很多（基本都与绘图相关），便决定尝试进行代码优化。
在阅读了一些手册教程之后，带着新的理解重新审阅之前的代码，只感叹自己写的代码还是很有改进的潜力的。
于是陷入了那似乎永无止境的优化之中……
……苦逼优化中……
优化的成果还是相当喜人的，帧数从1.8FPS（猫娘x1）提升到了5.1FPS（猫娘x1），四舍五入就是2倍的性能提升有木有！
……喜人你妹！最后的结论是，结果还是被CPU绘图给拖累了。抱着试一试的想法切换成OpenGL，果然画面变得乱七八糟，而且帧数变成了更悲惨的0.7FPS（猫娘x1）。
没办法，之前做motionPlayer完全没有为GPU设计渲染，完全走的CPU处理路线，以至于切换到OpenGL后产生了大量的CPU->GPU->CPU->...的数据交换，浪费了大量的时间。
只好再继续实现OpenGL的兼容设计。在这期间也发现艹车和艹猫都有设计完全D3D绘图的流程，彻底抛弃KR2原生的绘图方式，这才是正途有木有！KR2那绘图简直太反GPU了。
于是这回在改进emotePlayer/motionPlayer时，也保留了将来为支持全GPU渲染流程的扩展，当然那工程量太大，现在能做的也只是为将来的功能先铺铺路。
……苦逼优化中……
最终，开启了OpenGL后，一只猫的情况下能有15~17FPS，总算脱离了“卡到想砸手机”的程度。
至此，初始版emotePlayer插件算是可以进入公测阶段了。
附这期间的一些心得：
一篇极好的neon汇编教程+范例：
https://people.xiph.org/~tterribe/daala/neon_tutorial.pdf
（给自己看的？）NEON汇编笔记：
·进入NEON指令代码时，实际执行时间会有所延迟
｜如果处理量太少，使用NEON指令并无优势
·与内存的数据交换消耗的时钟周期较多，需要多费心优化
｜声明内存对齐可以成倍减少时钟周期，栈上的变量也在对齐后传给SIMD指令
｜A8芯片在前后两条指令分别是字节存取/字节变换（即非数值运算）指令和数值运算指令时，可以并行处理
｜↑尽量不要在加载指令后立马就使用数据，规划好数值计算指令和字节存取/变换指令，尽量交错处理
｜就算专门为A8优化，也不用担心A9及之后的CPU会导致性能下降
｜PLD并不是万能的，多耗费了一个周期，有时却完全没有性能提升，反而还会下降
｜↑在掌握的理论还不足以运用于实践时，只能无奈地反复测试来验证PLD可用与否
