Bug1 ：
当然，这种后 8 个 num 相同，前面的 num 不相同的情况的确很少见的，但还是会偶尔出现。
而通过后 8 位比较确定联系人的方法，会出现这样的好结果：
譬如，我保存的联系人的手机号有的是存成 +8613********* ，有的是存成 13********* ，那无所谓（来电时手机收到的号码是 13********* ），因为手机只比较后八位，两种存贮方法都能在对方来电时显示其姓名；
又如，我存了北京地区的固话，无论存成 010******** 或者 8610******** 或者不加区号，该固话来电时（手机收到的会是 010******** 这串号码）都能进行识别。
但同时也会带来这样的不便：
譬如，我是在一个固话号码只有 7 位的地区生活的，那么我拨打当地的电话时就不需要加区号，直接打那 7 位的号码就行了（在某些地区尚需拨打区号）；我要存当地的某个号码自然也只存个 7 位的号就行了；但这样一来，当这个号码打我的手机时，由于手机收到的是一个连区号的来电，手机在和通讯簿中的联系人号码比较，其他的当然都不合适了，而当比较到本来属于这个联系人的号码时，前面 7 次比较返回的都是 1 ，但到了第 8 次，一边是数字，一边是 nc （空）；当然就返回 0 了，于是手机会确认这个来电是陌生来电，显示的是一串连区号的数字，而不是联系人的名字！
更有甚者，如果你做了接听清单，那么这个固话也会识别成不在接听清单中而被拒接掉 L 。所以固话号码是 7 位的地区，在 628 上存储固话时，就必须加上区号了。
Bug2 ：
我们存储联系人，譬如一对夫妇，那么“家中”号码的一项就会是同一个号码了；譬如，你先输入 husband 的手机号，再输入 husband 家中的号码；然后又输入 wife 的手机号和家中号码（当然，在大多数情况下，你可能不输入的），那么默认情况下，这四个号码是按输入先后顺序在手机中存放的，为方便说明，不妨设为存储在 1 ， 2 ， 3 ， 4 这四个位置。
628 不能做拒接清单，但可以做接听清单；那么我们如果要把这对夫妇的家中号码放在接听清单中，我们也就很自然的只放其中一个；譬如，你随便选了 wife 的家中电话存了进去。
那么如果这对夫妇用家中电话打你手机了，你的手机会显示 husband 的名字，然后拒接！而不是显示 wife 的名字然后响起那悠扬的 32 和弦。
但如果你在接听清单中放的是 husband 的家中电话，那么就会显示 husband 的名字，然后响起来电的提示音。
经过尝试，如果不同联系人用了同一个号码，手机显示的是在手机存贮位置中靠前那个联系人的姓名。（而与在查找联系人时联系人的显示顺序无关。）
这样，我们可以知道 628 对接听清单的操作过程了：因为接听清单都是对手机中的联系人进行操作的；接听清单中标记的是联系人在话机中的位置，说白了，接听清单其实就是一个位置列表。所以当你选了选择性接听模式时，有来电进入，手机会首先按照话机中联系人存贮位置的先后顺序，分别和来电号码的后 8 位进行对照，只要找到后 8 位完全相同的，就确定是该联系人，然后再将该联系人的位置与接听清单中的位置列表对照，如果发现在列表中，就显示该来电，反之则拒接。
譬如：我们把 wife 家中电话放在接听清单，那么接听清单中记录的是“ 4 ”这个位置；然后当这对夫妇家里的电话打入时，手机沿着联系人在话机中的存贮顺序，对照后 8 位，发现和 husband 家中电话吻合，确定是 husband 家打来的电话（而不是 wife ），然后把“ 2 ”位置与接听清单对照，发现接听清单中没有“ 2 ”，于是，拒接。
当然，同一个号码被两位（或以上）联系人占用的情况是很少的，但如果你真的有这种情况，那么你在编辑接听清单时，一定要是把存储在话机中最前位置的号码加进去，这样，当这个号码打入时才能顺利接听。（查找位置的方法：通讯录－高级－位置清单）
无疑，这两个 bug 的产生完全是因为希望提高手机的效率的得来得：只需要对照 8 个数位而不是 11 位或更多（对于第一个 bug ）；只需要找到第一个联系人就可以结束搜索过程而不是 510 个位置都搜索一遍（对于第二个 bug ）。
但从可靠性（某些情况下也带来了一定的方便性）的角度来说，降低一点点效率也是有必要的。
希望 628 以后的版本会注意到这两个小问题；加以解决。
Bug3 ：
在联系人管理里面有一个群组功能，虽然不能为群组加特定的来电大头贴和个性铃声，但还是可以在发短信和编写接听清单时带来一定的方便。
你建了一个群组，然后在里面加联系人，联系人的排列方式是和你加入联系人的顺序一致的。（而与联系人在通讯簿里面的顺序无关）。
如果在群组里面的某个联系人的号码不再使用了，你要把这个联系人的号码删掉；删掉以后，你进入群组，你会发现原来联系人所在的地方出现了一个空白，你选中这个空白，要删除它也删除不掉！解决办法是把这个群组删掉，重新再建一次。
为什么会这样呢？那应该与 628 对群组中的联系人的标记方式有关，它标记的联系人列表是联系人在手机中的存贮位置；这样一来，当你把手机中的某个位置的联系人删掉了，手机中该位置就是 nc （空）了，但这个时候群组的列表并没有作出相应的更新；那个 nc 的位置号仍然在列表中，从而就出现了一个空白，并且无法删除。
因此我们在要删除某个在群组中的联系人的电话之前，最好先在群组中把这个联系人删除；这样就会避免产生如上所述的产生了一个无法删除的空白的情况了。
如果说第一第二个 bug 是为了提高效率不得已而为之的话，那么这第三个 bug 就实在是很不应该出现的了。手机的软件应该在用户对联系人作出删除操作的时候，检查一次群组列表，如果该待删除的联系人的位置在群组列表中，应该把群组列表中的这个位置也相应的删除。这样机子的软件设计就更为人性和合理了。
Bug4 ：
为联系人加来电大头贴的确是机子的个性所在，你把一张图片和一个联系人进行了关联后，你还可以随便修改这个联系人和这张图片的名字，这种关联不会时失效。这的确是非常好的。
但是如果你希望释放内存的空间来放一张壁纸或一个屏保，也不再希望这个联系人与那张图片进行关联了；那么你可能会直接把图片删掉，而存入一张壁纸或者屏保；那在这个联系人来电时，显示的是什么？是你新存入的壁纸或屏保！
那是因为 628 在联系人和图片关联时，是位置对位置的关联；也就是说，是联系人在手机中的位置与图片在内存中的起始位置的关联。当我把图片或联系人重命名时，它们的位置并未发生变化，关联仍然有效，这当然是好的；但当我删除了这个图片的时候，这种位置对位置的关联却仍然不会消失；而 628 在内存的头指针的控制上，又是指向刚删除的文件的第一个位置（只要有了一次删除文件的操作）；于是，当有新的文件要存到内存时，该文件的第一个存贮位置也就应该和刚删除的文件的第一个位置相同了。在位置与位置的关联没有消失的情况下，新存入的文件类型又是正确的（是可以作为来电大头贴的文件类型），从而，这个联系人又重新和新的图片产生了关联！
这种方式有好有不好，如果你是希望为联系人替换一张新的图片的话，那自然是很方便的，但如果是出现上面我说的情况，那就未免会带来一定的不便了。
一个软件在设计上不可能面面俱到的，不知道索爱的软件工程师会不会在这个问题上想出个好主意了： P
注：以上问题都是基于 r4c003 版本。欢迎各位大侠赐教。
