在很多测试中，都表明日常渲染的UI，cpu可以占用很高，比如快速滑动，子控件的弹出，动画帧数，但是此时gpu负载却很低。而后很多人，包括始作俑者的测试者@ioncannon 测试的结论。当然这个测试本身没问题，可是很多人看到这个测试却得出错误的结论，包括测试者本身。看到cpu占用很高，gpu没负载，武断的判断出，日常看cpu，gpu那么强大毫无作用(现在吧里依然充斥着这种言论，完全不了解这种言论正确的原因)。这个结论看似没问题，却没深入到原理，导致很多人出现了错误的认知。这个结论正确只在opengl上，因为其高昂的开销。
众所周知，安卓所有的渲染通过Canvas API来绘制UI元素的， API调用最终会转化为Opengl 图形API调用。都知道opengl 驱动代销很大，导致在某些渲染中cpu占用老高，gpu空闲，很影响流畅，而且本身多线程支持有差。日常的渲染基本就属于这类型的调用，比如安卓经常在意的过度绘制。而这基本就是opengl的软肋，这类型的调用，使用opengl渲染，代价非常之大，而且多核利用上不去。导致在测试结果中出现一个怪现象，cpu占用老高，而gpu基本无动于衷。很多人就误以为安卓日常界面不需要gpu，但这是opengl的渲染机制及本身的弱点所决定的，采用vulkan渲染可有效降低这种调用开销，真正发挥gpu的优势。
说到这，可能又有人问，那ios怎么回事，很大可能性是因为为了让旧设备的支持metal所导致的恶果，而安卓7.0就决然断绝这种问题，不强行兼容本来就不兼容的老旧，过时的801的330.以前研究过上古卷轴5的都知道，dx11的enb比起dx9的enb效率要低很多，使用dx11的enb直接导致帧数大降。主要是5是dx9开发，dx11渲染代价要高很多。本来不兼容，强行兼容的代价是很高的。
vulkan这类型的驱动开销比opengl 要小很多这个是有目共睹的。而安卓日常界面基本都是这种渲染，安卓采用这种渲染能直接提高gpu的作用，发会gpu渲染优势，降低渲染的代价，优化能耗。当然肯定不可能一下子就能看到，毕竟需要过渡。但可以预见的是vulkan给安卓带来的不仅是游戏的流畅，更是系统的流畅。
