- 目前我聽(tīng)著歌腐巢，心里預(yù)約，發(fā)現(xiàn)bug玄括，到解決Bug冯丙，總共費(fèi)時(shí)3天，心情如過(guò)山車一樣遭京，便有此文
我們App是一個(gè)LAUNCHER應(yīng)用胃惜，就是一個(gè)安卓系統(tǒng)搭載我們APP泞莉，我們App作為啟動(dòng)的應(yīng)用，在OTA的時(shí)候沒(méi)有發(fā)現(xiàn)數(shù)據(jù)庫(kù)丟失船殉，但是更新系統(tǒng)的時(shí)候鲫趁，發(fā)現(xiàn)所有數(shù)據(jù)丟失，這是QA反饋的情況
- 1利虫、首先懷疑是系統(tǒng)的問(wèn)題挨厚，因?yàn)槲覀兊南到y(tǒng)是定制化的，有些特定的程序糠惫，特定的分區(qū)給我們App獨(dú)特使用疫剃，同時(shí)我們App是沒(méi)有權(quán)限限制，也就是說(shuō)代碼沒(méi)有做動(dòng)態(tài)權(quán)限的申請(qǐng)硼讽，所以有可能是系統(tǒng)更新后巢价，導(dǎo)致某個(gè)權(quán)限沒(méi)有了，然后導(dǎo)致讀取文件的失敗
- 所以我先排除了是權(quán)限的問(wèn)題理郑，但是這個(gè)時(shí)候蹄溉，還是不明白為什么OTA APP正常，OTA Image不正常您炉，同時(shí)也反饋情況給leader，說(shuō)明情況
回到問(wèn)題的本身役电，我們數(shù)據(jù)如何處理赚爵，我們App本身內(nèi)置了一個(gè)數(shù)據(jù)庫(kù)文件，這個(gè)數(shù)據(jù)庫(kù)文件主要是確定用戶在沒(méi)有網(wǎng)絡(luò)的情況下法瑟，也能夠正常的使用內(nèi)置的數(shù)據(jù)冀膝，同時(shí)我們把資源文件（主要是圖片）放在專門(mén)的一個(gè)分區(qū)，apd分區(qū)
OTA 系統(tǒng)會(huì)改動(dòng)這個(gè)分區(qū)的數(shù)據(jù)么霎挟？不會(huì)窝剖，這個(gè)可以算是用戶分區(qū)，同時(shí)"/data/data/" + context.getPackageName()這個(gè)也是用戶空間酥夭，OTA App或者是系統(tǒng)是不會(huì)丟失這里面的文件的
App的數(shù)據(jù)庫(kù)加載流程
- 1赐纱、首次啟動(dòng)APP。App會(huì)判斷是否有數(shù)據(jù)庫(kù)文件熬北，如果有疙描，不做任何處理
- 2、如果沒(méi)有數(shù)據(jù)庫(kù)文件讶隐，那么通過(guò)流的操作起胰，把App的資源文件寫(xiě)入到
"/data/data/" + context.getPackageName()，也就是原始的數(shù)據(jù)庫(kù)文件巫延，這個(gè)文件效五，會(huì)跟著APP一生地消，也就是這個(gè)產(chǎn)品的一生
問(wèn)題是數(shù)據(jù)庫(kù)文件丟失？觀察原始系統(tǒng)下的 db文件大小畏妖，和ota完成以后的大小
但是當(dāng)ota成功后脉执，這個(gè)數(shù)據(jù)庫(kù)變?yōu)?66k，所以問(wèn)題是數(shù)據(jù)庫(kù)文件丟失
到這里明白數(shù)據(jù)文件的丟失了瓜客，但是為什么OTA APP正常呢适瓦？為什么呢？這個(gè)問(wèn)題困擾我一直到第二天谱仪，我的理解就是兩個(gè)都有問(wèn)題玻熙，然后就可以去找數(shù)據(jù)庫(kù)文件為什么丟失
到這里我第一個(gè)思路，就是替換原來(lái)的DB文件到最新版本疯攒，同時(shí)資源文件也是嗦随，因?yàn)槲覀冇行略龅臄?shù)據(jù)，在沒(méi)網(wǎng)的情況下敬尺，用戶能夠看到數(shù)據(jù)枚尼，但是顯示不了圖片，同時(shí)我在這里忽略了一個(gè)極其重要的問(wèn)題砂吞，用戶原來(lái)的數(shù)據(jù)庫(kù)文件怎么辦署恍？
由于發(fā)的是正式版本，需要對(duì)每一條數(shù)據(jù)庫(kù)文件檢查蜻直，同時(shí)每一條數(shù)據(jù)都在APP上實(shí)際操作盯质，這個(gè)過(guò)程在我們發(fā)第一個(gè)版本，足足弄了一周概而，而且還有不確定的問(wèn)題產(chǎn)生呼巷，所以這個(gè)解決很大問(wèn)題，同時(shí)還要備份原來(lái)的數(shù)據(jù)庫(kù)文件赎瑰，實(shí)際操作的時(shí)間遠(yuǎn)大于解決這個(gè)問(wèn)題的意義
So王悍，我不太能夠說(shuō)服我自己，同時(shí)心里開(kāi)始產(chǎn)生懷疑餐曼，應(yīng)該OTA都有問(wèn)題压储，但是我今天加班，QA的小伙伴不在公司
由于系統(tǒng)集成的app都是system分區(qū)的晋辆，自己可以通過(guò)push模擬OTA的操作渠脉，通過(guò)模擬的結(jié)果：開(kāi)始懷疑，QA的測(cè)試結(jié)果有問(wèn)題瓶佳，應(yīng)該是OTA App 和 Image 都是有問(wèn)題的芋膘，對(duì)的，這次更加的確定
放棄幻想，開(kāi)始戰(zhàn)斗为朋，開(kāi)始懷疑數(shù)據(jù)庫(kù)的更新關(guān)鍵是有問(wèn)題的臂拓，由于這塊邏輯不是我寫(xiě)的
所以，大膽假設(shè)习寸，小心求證
DB的更新流程如下：
1胶惰、備份數(shù)據(jù)，如果是新表的話霞溪，其實(shí)是不需要備份數(shù)據(jù)的孵滞，需要做些判斷
2、刪除表
3鸯匹、創(chuàng)建表
4坊饶、恢復(fù)數(shù)據(jù)，同第一點(diǎn)一樣殴蓬，如果備份數(shù)據(jù)表的中間表不存在匿级，也是不需要的
通過(guò)以上流程的分析，這塊代碼沒(méi)有問(wèn)題染厅，只不過(guò)是我們Pro的版本何什，有個(gè)跨表升級(jí)的問(wèn)題蚓土，最后修復(fù)了张抄，跨表升級(jí)的問(wèn)題
我們App分為好多個(gè)版本丛晦，但是數(shù)據(jù)版本是一直在增加，所以有可能出現(xiàn)涩馆，Rro的線上版本需要從1升級(jí)到9這種情況散庶，需要特定處理
第二天正式上班，第一件事情凌净，就是讓QA復(fù)現(xiàn)他的情況，為什么OTA App是正常的屋讶，最后看了測(cè)試視屏冰寻，終于明白，OTA App 是保持有網(wǎng)絡(luò)的狀態(tài)皿渗，所以當(dāng)更新到最新版本斩芭，發(fā)現(xiàn)本地沒(méi)有數(shù)據(jù)，就回去網(wǎng)絡(luò)上獲取乐疆，到這里終于真想大白划乖。
解決這個(gè)問(wèn)題，我的心態(tài)是變化是：迷茫--->清晰--->困惑---->懷疑--->解決--->多方求證--->驗(yàn)證答案挤土，皆大歡喜
最后感謝我們公司的QA小伙伴不離不棄琴庵，哈哈
