苏宁 .：苏宁物流移动端百万级离线数据处理方案.docxVIP

苏宁 11.11：苏宁物流移动端百万级离线数据处理方案 随着苏宁物流的进展，对网点的整合，很好的强化了苏宁物流最终一公里配送力量，可以在相对短期内整合双方在仓储、干线、末端等方面的快递网络资源，编织一张掩盖最终一公里的密织高效网络，整合完成将极大地强化苏宁物流最终一公里配送力量，提高配送效率，降低运营成本。 其中物流移动端在仓储，干线和末端等各个环节都扮演一个格外重要的角色，然而移动端的用户和我们一般的移动互联网用户有相同的地方也有很大区分，首先物流移动端的用户基本上是我们处在一线的操作人员，界面的交互和服务的响应速度直接影响用户的作业速度。另外移动互联网用户一般是手机，而物流移动端的用户包括手机和手持码枪，这就对我们移动应用提出了更高的要求，不只仅要具有手机的机警性还要有手持的有用性。最终随着 3G，4G 的普及移动互联网用户手机联网性一般很好，但是我们的一线作业人员可能处在仓库的角落，信号的盲区，这就要求我们的应用不只要在有信号的情况下可以作业，在无信号的形态下也可以正常作业。 为了实现各大区网点不能满足实时的网络交互环境的情况下正常作业，这就要求我们操作终端多向前走一步，同时能满足各网点无论在网络环境好坏的情况下都能完成作业。假如满足这些条件就需要原来在服务端处理的数据下载到码枪，在码枪本地本地进行校验处理，服务器的主数据量在都在万级以上，最大的一张表数据在百万级，而正常作业下我们用的码枪都是安卓系统，运转内存在 2G，4G，有的码枪甚至处理内存在 1G。假如通过对码枪的更新换代可以更换功能更好的码枪，但是这种成本是巨大的 ，所以通过对技术上的实现去节省成本和添加用户体验是我们苏宁物流要首当其冲面对的问题。 我们的处理方案 一?数据处理实际规律 通过网络下载 txt 文件 按行读取每行字符串文本 接受 String.split 函数依据指定的格式分割字符串为字符数组 通过字符数组组装 Entity 数据类，讲数据类添加到 List 里缓存 推断 List 的 Size 大小，达到 3000 条后调用 Greendao 方法启动线程开启事务批量插入，清空 List 连续循环 未达 3000 条连续循环走 2 流程 图 1、数据处理规律流程 二、功能瓶颈分析 使用 TraceView 找到功能的瓶颈，TraceView 是 Android SDK 中内置的一个工具，它可以加载 trace 文件，用图形的方式呈现代码的执行时间、次数及调用栈。生成 trace 文件有三种方法： 使用代码 使用 Android Studio 使用 DDMS 图 2、开头 trace 图 3、写入到 trace 文件 图 4、执行耗时分析 图 5、函数耗时分析 通过 TraceView 分析，另外结合代码分析总结出几共功能瓶颈 String .split 接受正则婚配，大数据量效率低 读文件比较耗时，假如数据库速度大于文件读取速度，则会等待文件读取 插入数据库也比较耗时，假如插入速度小于文件读取速度，则文件读取会堵塞等待 每次使用 GreenDao 开启线程，没有限制最大线程数，开启大量线程，导致数据库连接数超出上限，极易 OOM 另外，通过代码日志分析得出，Entity 没有重用，每次循环创建新的 Entity，导致内存不足，频繁耗时 GC，界面卡顿。 三、处理方案： 针对 Spilt 的优化：重写了 String.split 的实现方式，接受效率更高的 index 方式代替原来的正则婚配，依据业务特点固定了分割数目 针对对象没有重用的优化：接受动态事务，在事务中接受单条连续插入数据库，操作避开创建多余对象，达到指定数量后一起 Commit 到数据库 单次提交数量优化：经过多次测试，统计出单次提交 12000 条为效率最高的提交量 针对相互等待问题：接受堵塞队列，对象池方式削减等待 具体流程图如下： 图 6、优化流程图 四、结果对比： 通过测试的对比可以发觉，同样的数据，合理婚配文件的读写速度和数据库的读写速度，削减等待间隔。 在单次 8000 量的时候 ，速度可以比原来缩减 3 分 40 秒， 在单次 10000 量的时候可以比原来缩减 3 分 50 秒， 在单量 15000 量的时候可以缩减 3 分 50 秒左右， 在单次 12000 量的时候可以缩减 3 分 57 秒。 图 7、优化对比 五、优化方案 + 完成的上步之后，虽然功能上有了很大的提升，但是为了给一线的苏宁物流用户供应更优的用户体验，我们想到了优化方案 +。 1. 传统 Rollback Journal SQLite 实现 原子性提交和回滚操作 的默认方法是 rollback journal。当对 DB 进行写操作的时候，SQLite 首先将预备要修改部分的原始内