|
|
本帖最后由 moo.tinys 于 2011-12-9 10:34 编辑 " z4 m: S/ |1 F: ^* ~# y% r
1 m0 Z/ }0 J+ l9 Y1 n/ o' R* |# p背景知识: 来自 Accounts 同步过来的联系人的叫 Contact, 自动 link (包括1的情况)成 Person+ m" o# S; z7 J5 K6 o/ @' g& b2 I
背景知识2: edit 修改 contact, 查看是 person/ U7 _+ D ]- ?; k0 g
可能有关的条件: 使用 1.4G 特殊内核后(也可能无关)( x5 B( t0 h) P
操作: 编辑联系人点done后, 展开 contacts
) Y, s# p i2 `; r7 z+ H错误现象:
+ V" _* V1 z4 M! D9 G, b 1. 修改后 person 信息是修改后的, 点 app.contacts 的 Person 详细资料的顶部展开 contact, contact 信息是修改前的 (一般不展开, 所以此现象比较少留意到)
. K( T. z5 f5 y 2. 接着点击 edit 进行再修改, 看到的是老的 contact 信息 (现象很明显, 来回修改就会发现)
0 D& a$ P- ~1 ^0 z分析原因:$ w: ]- X, }: k6 A
a. 修改后, 系统先保存 person 后保存 contacts" M* u7 z" _) g4 D6 U! p
b. person 的 detail view (查看详细资料) 界面在 watch person 数据库, 一旦修改就触发脚本执行 reloadContacts 重新载入 联系人, 此时 contacts 尚未被写入. S3 b1 S# x7 K4 O" J f
+ T p2 p* g" u其他罗嗦话: 以上确实从代码逻辑上分析出问题了. 而为何以前用 2.1.2 没发现, 为何模拟器里的 2.1.0 没这个问题, 这些疑问尚未深入研究, 也不打算研究. 至少原因相关的代码并没有被补丁修改过, 甚至这部分代码 2.1.2 跟 2.1.0 是一样的. 只能怀疑是这里的确是 Race condition (竞争条件)说不定谁先谁后, 所以随即概率出问题. watch 跟 cpu 速度的变化暴露了这个问题. 保存 person/contacts 的过程是多个 Future.then 操作, Future 之间 db watch 事件可能先触发 (未深入分析 Future/dbwatch 的机制, 猜测应该是如此)
* z! @# ]" ]' W7 A因此即使没用超频内核, 也有一定概率出现, 因此修复后可更稳定8 `) l9 Z; I+ ?: `
4 u! v- p. K( s1 I2 k- r6 c: g
补丁研发中 |
|
|Archiver|手机版|小黑屋|吹友吧
( 京ICP备05078561号 )
狗仔卡
发表于 2011-12-9 02:11
提升卡
变色卡
显身卡
