2.qml性能问题

1.渲染机制

这篇写的很好: 跳转
QWidget
cpu渲染，移动开发不友好
但是对低性能设备非常友好
QQuick
gpu渲染，吃显卡

2. 注意事项与优化

如果你生产环境的设备显卡不太行的话
使用qml开发是有点不友好的
qml开发效率肯定是非常快的，布局起码比qwidget快很多
但是动态数据不友好

我们在qml中可以使用loader进行动态加载，同时也可以加上asynchronous进行异步加载
我只能说掉帧严重，显卡差的话
一般动态数据我们考虑 listview ，gridview ， tableview 等组件
listview ，gridview 不适合渲染复杂的itemdelegate
如果绑定scrollbar， 你会发现scrollbar 老卡了，为什么呢
因为scrollbar 是可以快速滑动的，快速滑动的时候，loader没完全加载出来不就卡爆了吗？

呵呵，显卡差到qml的便利性都没得了，叫老板给你升级gpu，老板跟你说成本高不给加，我说那用回qwidget，老板说都老东西了，以后升级肯定不方便，那qwidget加qml混合使用呢？老板说都用qml了那还用qwidget干嘛？我…

说回正题，以下是我的优化方案

优化方法

①所以—如果显卡不太好就得采用分页显示动态数据的办法了，这个时候就用repeater配合column或者row或者grid就可以完成了，不要用复杂的listview,gridview,tableview，最好数据源处理好了的
，从c++获取到直接用，不要出现复杂处理在qml， 如果你是静态行稳的雅痞。。。。

②尽量屏蔽-------console.log(无厘头打印) ------重写他们用一个变量__DEV__管理是否打印，非常影响页面刷新

③尽量不要用qml的绑定binding动态变量，用手动赋值取值的的方式，也不要使用计算属性，计算属性加入逻辑之后的动态变量，你给你自己的qml写一个paintEvent方法专门用来刷新页面 写个setparam getparam 负责赋值取值，全部给组件设置id，通过id赋值取值

④Image图像加载，全部asynchronous=true异步加载，
所有的图片只要清晰通通给我压缩,压缩到最小承受度

⑤如果不需要背景就不要用rectangle, 用item就行了

⑥尽量不要操作透明度opacity，会影响渲染速度，
底层肯定是有对透明度有算法的，你渲染的面积越大，肯定越费时间
当然逼不得已，一定搞个透明图层，那肯定可以用

⑦抗锯齿antialiasing尽量不要开，尽量不要设置圆角radius，
搞圆角能拖垮渲染速度3/4倍，不信你自己在paint事件试试就知道了

⑧你派生了QQuickPaintedItem 制作的自定义控件吗？
重绘paint事件，卡爆了吗？我只能说卡肯定是卡，比不过qwidget的3/4倍
fps60 指的是 frame per 60 每秒60帧 ， 但是显卡垃圾，根本就没有这种能力
假设你设计一个图像编辑器， 很好，记住paint里面不要有逻辑， 比如矩形，圆形，三角形， 你先粉分别创建
他们的list 容器管理 ， 在painted 里面直接绘画
不要变更太多的状态，什么是状态？字体，笔 ，刷子，能不变尽量不变，
如果要做逻辑判断你在外面做好再调用 update 渲染，让cpu跑逻辑，让gpu跑渲染，你放到paint里面那不就是渲染还得等你cpu逻辑渲染逻辑渲染吗 那肯定卡了，逻辑跟渲染一定要分割开来
a）逻辑跟渲染分离
b）update 设置绘制范围，一般是视口viewport范围
c）paint 状态不要高频率切换
d) 抗锯齿不影响的话尽量不要设置

⑨显卡太差，多页面切换都有问题，我真的是c了个dj，用popup的open()都能渲染半天，
这又得了解qml的机制，原来visible控制渲染不渲染，open里面就执行了visible =true, 你如果qml文件太复杂，就会影响到打开页面的速度。那完了，我的qml就得很复杂的怎么办呢？用过ps吗？ 知道图层概念把，你弄多层，使用z 就是深度
我们z=1视为不可见层
z=2为背景层，我们将原来的背景换成Item不要让他吃我们的性能，我第⑤条里面说的
z=3为可见层，也就是给用户看的

显卡太差，不要用loader诸如此类的动态加载页面，除非简单页面
用静态页面，而且不要设置visible吗，非也，你只设置z控制图层，他也是会被渲染的，
我的意思就是简单的图层用loader ，看起来打开也很顺畅的用visible控制， 复杂的就用z控制，这样子懂了把