近期编译了android下支持opencl的opencv，使用opencl能力的关键是用cv::UMat替换cv::Mat。
实际使用后发现坑很多，非常不成熟，不推荐使用这种方式来提升实际产品的性能。
- 每个UMat产生的时候会从gpu分配内存，而GPU分配内存是很慢的；使用Mat的时候，这点开销不值得一提，但是UMat完全不是一回事。因此，UMat一定一定要重用，避免反复分配。
- mat.getUMat()方法很多坑，引用计数的错误很难查，至今没搞明白原理。因此一直用mat.copyTo(umat)来代替。
- mat.copyTo(umat) 和 umat.copyTo(mat)也是很慢的，因此，一定要计算时间大于数据拷贝时间，抵消了拷贝的开销，使用umat才能带来性能提升。
- 例如这样一个函数 cv::cvtColor(umat_in, umat_out)，第一次使用是很慢的，因为opencl的核函数编译很耗时。因此要使用很多次，多到第一次使用的编译开销可以忽略。
- 再说核函数编译的问题：opencv是C风格的，每次调用，核函数都要编译一次，虽然第二次以后很快，但是这种每次调用都编译一次核函数没有意义。
- T-API看起来很好，一套API既支持Mat又支持UMat，但其中的坑是：计算到底用GPU完成的还是CPU完成的，你不知道。例如我使用cv::dft()一样，传入的UMat必须按照2的倍数对齐，否则就会退化到用CPU计算。这下大坑就来了――我先mat.copyTo(umat)，然后传给cv::dft()， 函数内部检测无法用GPU计算后，自动退化成CPU计算，然后内部umat.getMat()， 计算完成后再mat.getUMat，白白多了两次GPU内存拷贝，加上外部调用又拷贝了两次，来回有四次GPU内存拷贝。
- opencv的函数都没有提供opencl的Queue的支持，也就是所有的拷贝和计算无法让CPU和GPU做到异步。就算GPU分担了CPU的压力，但是CPU在等着GPU计算的结果。
- 从opencl支持的源码风格上看，很可能T-API最初只在intel GPU & AMD GPU上测试，网上的android+opencv+opencl的文章也很少――由此猜测：android下的opencv中的opencl加速，可能并没有专门针对android平台去测试加速情况。没有前人证明过这条路可行！