TD无辜，号簿管家同步慢与TD网络无关

idofindit

近日，我从不同渠道获悉用户在使用号簿管家时与其它同类产品相比同步速度较慢，将其原因归结于TD网络太差，为此我不得不站在个人角度给以解释；因为我从负责过公司PIM业务，在08年又与中国移动的号簿管家服务器进行了适配，现实是号簿管家同步速度确实较慢，我试举例说明：比如用户号簿管家服务器有1000条联系人，用户执行同步，影响同步效率有以下两点：

1、交互次数：在号簿管家所用的SYNCML协议中有一个字段， 终端向服务器发送此字段的数值以规定接收包的大小，也就是手机端给服务器发的这个值是10K，服务器返回一个不超过10K的包，如果是100K服务器返回100K的包， 我知道大多数厂家选择的是10K,但是如果选择20K，就会让交互减少一半，如果选择100K就会让交互次数减少10倍，我以前选择的是100K，这包确实有点大，但在CM-NET上选择100K问题不大，CM-wap选择20K应该没问题吧。

2、接收下来的数据的处理效率：这是一个更加重要的原因，号簿管家用例中还有一个case就是，用户接收数据过程中取消，再同步，比如，用户正在接收第21条数据时，用户取消，那手机端必须保证接收下来的只是21条，否则测试为不通过....这个用例看似简单，但却给效率带来了的阻碍，分析如下：


   做开发的人都知道，端到端的交互是以数据包为单位交互的，不可能每个联系人一个包，也就是如1中所说，服务器返回的包可能是10K，20K，100K，10K的包如果对于只有姓名和电话的联系人，大概要有40个左右的联系人组成，这个包接收到手机后，我们的程序首先进行解析，这没问题，解决出的40条联系人必须一条一存储，存储成功一条，提示用户的接收数据会增加一条，这样存储40次。这有什么问题呢？ 开发的人都知道数据库中的事务的概念，一般的手机通讯录是存数据库的，数据库都支持 事务和批量插入，说通俗一点，一次存储一条和一次存储40条，所花的时间基本一样， 但存储40次和40条一次存储所花的时间差不多就是40倍。



    我不知道我有没有说清楚？如果接收1000条联系人，手机要进行1000次事务的提交，但是如果以一个包为单位(无论这个包有30条50条还是100条)进行一次事务的提交，手机端数据存储花的时间将减少。  这样处理后的用户体验如下：


    用户UI中看到的是， 正在接收“第1--40条数据”，正在接收“第41--80条数据”，如果这时用户取消，手机端只有此前的40条数据，这样用户是可以理解的，别看只这样一个提示的变化，同步效率却是提高了。


    运营商是老大，如果想做定制，运营商的用例必须要过，并且一字一句不得有半点差错，当年我为了过用例，不得不把同步效率较高的程序改为同步较低的一条一条接收，也给移动反应过这个问题，但大都是怕承担责任，或是找不到拍板的领导，所以号簿管家的测试规范，一年又一年，终端厂家无条件遵守，取近听到有用户说TD太差了，原因就是和一个其它网的PIM产品对比速度而得的结论，我恍然间，事情闹大了，TD无辜呀.....

    这事说影响也影响，说不影响也不影响，如果用户有3百5百条联系人，总同步时间也用不了多少时间，但是如果是3000条5000条，给用户体验带来的潜在影响是很大的，尤其用户并不知道什么规范，什么数据库，事务之类的，只要影响了他的速度，影响了他的体验他都怪罪到TD头上，所以，TD是无辜的.....