好问题。
关于被遮挡问题：会下降，下降程度取决于你丢了多少帧以及你在raptorq的参数里设置了多少的repair rate（默认10%，可以调）。
实际上的话，扫码miss是常态发生，在10% repair的情况下，按你说的只是虫子飞过，影响微乎其微，有人经过的情况，基本上也丢失不会很多。10% repair你可以粗略理解为，如果丢了一帧，接下来可以用正常的10帧的冗余可以把这丢掉的一帧通过数学算法恢复出来。如果中间丢掉了很长的一段帧，那就会恢复的比较慢，丢掉太多的话可能需要等待二维码loop回原始帧。
给你个参考，其他的基于fountain code的信息通信项目（像我提到的卫星往地球广播消息），他们大多数设置的repair rate是5%。我个人觉得二维码良好条件下10%，恶劣环境可以试20%-50%。
关于变形问题，这个其实取决于底层zxing库的能力而不是我项目的能力，我可以说的是zxing对这方面的优化还是很不错的，然后可以通过高级设置里面勾选try harder、try rotate（try rotate我记得好像是可以提供倾角大于45度的尝试，小于45度默认就能处理的了）等参数尝试解决，可能会增加CPU占用，在好的设备上表现不会很明显，但是差的设备我确实不知道。我也提供了几个Decode preset（fast到robust，robust为最大解码尝试）可以供实验。
关于对比度问题，同上，这个我可以确定的是现有的解码算法已经非常成熟了，基本上不影响。而且默认的二值化参数是LocalAverage，已经是最稳健的了，大多数情况都能正确处理复杂的光照条件。
但是对于频闪严重的那种老式逐行扫描的显示器来说，影响扫描的不是对比度，而是摄像头有可能在高快门速度下拍出来的二维码是条状的而不是正常二维码，这种情况基本没什么解决办法，因为是网页应用，没办法去访问设备相机硬件调参数。
此外，二维码标准里其实就带了ECC纠错，项目也支持。默认是最低一档，可以调高增加识别率（代价是单张二维码承载信息减少）