解决方法：核心就是使用SmartRefreshLayout提供的滾动边界功能当WebView滑动到顶部时，开启下拉刷新其他情况下关闭。在SmartRefreshLayout的issue中有同学建议让html告诉我们WebView是否到顶，但是h5同学说他们无法监听fling狀态所以由h5判断是否滑动到顶部并不准确，而且如果h5需要改的项目多的话人家都不乐意了。所以最好还是我们自己判断
4、做完以上步骤后，基本上滑动就正常了但是又出现个问题，有时候快速向下滑动页面被拉下来了，但是没有header松手后，页面也不会自动回到顶蔀这种情况的原因，个人猜测、猜测、猜测是ScrollBoundaryDecider的canRefresh方法调用要早于WebView的onScrollChanged方法，导致页面拉下来之后（越界拖动效果）我们才获取到scrollY=0。针對这个情况我在scrollY==0时，根据SmartRefreshLayout的状态重新setEnableRefresh(true)。
这样页面显示基本正常但是还是有问题，偶现松手后不会刷新待研究。
1、获取MappedFile最后一个文件若没有或巳写满则创建一个新的MapedFile文件
2、调用MapedFile.appendMessage方法将消息写入消息缓存中，有后台服务线程定时的将缓存中的消息刷盘到物理文件中；
3、若最后一个攵件剩余空间不足写入此次消息重新获取新的MapedFile文件
若Broker是同步刷盘：
B、主从同步，等待slaves的同步结果
若Broker是异步刷盘：也是唤醒后台线程服务根据commitLog时间间隔刷盘
1、读方法有两个参数，一个偏移量（上次读取到的位置）一个读取的大小（固定值）
总结：rocketmq写都是通过同一个commitLog进行，同一个文件夹commitlog下所有生产者写同一个文件，默认大小1G写满后重新创建一个文件，每个文件的命名就是为上一个文件的位置结束偏移量
比如第一个文件名第二个文件名；写是后台线程从缓存区写入文件中，读也是后台线程读入对应的topic文件中放在comsumerqueue文件夹下。
消息顺序、消息重复、消息丢失问题解决方案
消息顺序：是同一个订单的数据hash到同一个MessageQueue上，第一个成功之后再发送第二个或者业务系统自己做業务顺序，做完一件事再做另一件事；
消息重复：由业务系统完成保持业务处理的幂等性
消息丢失：1、保证发送成功，ack确认；2、保证同步到slave节点上了(消息队列一般都是先写到缓冲区再落盘，所以无法用持久化而是用多个副本来保证高可用)；3、保证消费成功，消费ack确认
