阿江

又进行了一些测试，
发现修改后触发它的同步并不一定非要新建或者删除一条备忘录条目，
关键看是修改了什么内容。

目前发现修改后不同步的，往往是编辑了其中一行，并且修改量不大的。
比如，将一篇较长的文字中的 9月18日 改为 20200918
其它的不变，这样是不能触发同步的。
但如果在原文中增加一个新的空行（不是在末尾，是在中间），则就能触发使手机端同步。
然后，从云端删除这个空行，又不能触发同步了。
然后在删除的空行前面的那一行里增加一个汉字，又触发同步了。
以上测试过程是可以准确重现的，可以排除有时候同步有时候不同步这样的随机情况。

这中间到底是一个怎样的逻辑来触发同步的，即怎样的修改才会被云端认为这条备忘录真的被修改了是需要同步的，目前不得而知。

这个BUG一直没有引起华为的重视，可能就是因为这个BUG具有隐蔽性。他们的测试人员测试的时候，是会在已有的备忘录条目中胡乱打一段文字，这样正好就触发了同步了，他们发现不了这个问题，就算是偶尔有人反馈到他们那里，他们无法重现这个问题，也就引不起重视。

ts99

个人还没有用到备忘录的地方。。

阿江

我感觉我可能找到华为程序员使用的判断是否需要同步的逻辑了。
他们很可能是判断字串长度（数据总字节数）和段落数（除末尾外回车的个数）
当字节数变化不大时，就认为没有修改，不需要同步。
上述例子中，加了一个空行同步，前面还有一步是在上面一行加了一个汉字，也没同步，但两步加起来，加增加了一个汉字加一个回车，它就认为增加了一个有一个汉字的段落（虽然那个汉字并不在这个空段里），就给同步了。

用这个猜测来解释，几乎所有的同步或者不同步的情况都能吻合。
我感觉这次我很可能猜对了。

阿江

再测试，如果在备忘录的末尾删除一整行文字，就算是很长的文字，也不会触发同步。

感觉这还有可能是华为的一种“保护机制”，它把一些行为（比如很微小的改动，或者末尾删除了整行）界定为误操作给忽略掉了。如果真是这样，我感觉这有点耍小聪明的味道了。

chinaquery

没备忘录的习惯  

一天

阿江这对事情探究的态度确实强，专业

牛站网

别测试了

这么简单的问题这么多年都没人处理

说明他们自己也不用这个产品

烂就是烂