摘要：語法不兼容語法，會產(chǎn)生一些不可預(yù)知的。經(jīng)過商量，服務(wù)器對接收到的數(shù)據(jù)進(jìn)行去重，且后續(xù)時間以服務(wù)器時間為準(zhǔn)。的數(shù)據(jù)存儲速度有待懷疑。

1、ES6語法不兼容for of語法，會產(chǎn)生一些不可預(yù)知的bug。

2、從服務(wù)器獲取到的配置文件XXX.bytes，直接根據(jù)pb文件解析即可，千萬不要進(jìn)行json解析，否則pb里的枚舉值就會被轉(zhuǎn)成字符串，導(dǎo)致獲取不到預(yù)想的結(jié)果。

3、做本地緩存的時候，react-native提供的AsyncStoreage只能存儲字符串，所以存入緩存之前數(shù)據(jù)都要進(jìn)行json序列化，但是當(dāng)從緩存中取出數(shù)據(jù)，進(jìn)行json解析，加入緩存之前的對象的一些默認(rèn)（例如：boolean類型）值，都變成undefined了，會影響原有的判斷邏輯，需要對數(shù)據(jù)進(jìn)行邏輯判斷的補(bǔ)充。

4、在開發(fā)中肯定會遇到需要獲取時間戳的問題，React-native中獲取的時間戳是毫秒為單位，而且后面還有幾位小數(shù)，打印了幾條數(shù)據(jù)觀察，發(fā)現(xiàn)都是1位小數(shù)，毫秒到的秒的轉(zhuǎn)換，需要再除以1000，于是就按4位小數(shù)進(jìn)行截取，let timeStamp = timeStamp.substring(0, timeStamp.length - 4);，但是在后來的程序運行中同事發(fā)現(xiàn)，有的時候，后面會有沒有小數(shù)的情況，結(jié)果截取到的時間戳就少了一位，結(jié)果就出錯了。于是他把獲取時間戳的代碼修改如：let timeStamp = Math.floor(new Date().getTime() / 1000).toString();，這樣獲取到的就是時間戳的整數(shù)部分了，且是用秒為單位的。

5、react-native中的text組件，如果不設(shè)置寬度的話，默認(rèn)是父組件的寬度，顯示不下才會進(jìn)行換行，開發(fā)中遇到遇到兩種情況：一個image & text 采用橫向布局，如果不設(shè)置text的寬度的話，超過父組件的寬度，右側(cè)的文本會有丟失的情況；一個text & image 采用橫向布局，如果不設(shè)置text的寬度的話，text會默認(rèn)占用父組件的全部寬度，結(jié)果右側(cè)的image被擠到了父組件之外。

6、數(shù)據(jù)埋點遇到的坑點：由于服務(wù)器和客戶端不在同一個時區(qū)，服務(wù)器接收到打點數(shù)據(jù)，因為時間差的原因，對客戶端上報的一條數(shù)據(jù)進(jìn)行了多次入庫，導(dǎo)致數(shù)據(jù)量異常。經(jīng)過商量，服務(wù)器對接收到的數(shù)據(jù)進(jìn)行去重，且后續(xù)時間以服務(wù)器時間為準(zhǔn)。

7、AsyncStoreage的數(shù)據(jù)存儲速度有待懷疑。在性能調(diào)優(yōu)的時候發(fā)現(xiàn)，一些方法的執(zhí)行，快的是1毫秒，大部分的發(fā)放執(zhí)行在40毫秒左右，到了賬號信息存儲的時候，就執(zhí)行了一個AsyncStorage.multiSet方法，其中是5條數(shù)據(jù)，耗時一下就變成了800毫秒左右。截圖如下：

上面這個方法的執(zhí)行耗時是783毫秒，所以對于這里的信息存儲，還是有很大的提升空間的。
AsyncStoreage給我們在開發(fā)中提供了一些數(shù)據(jù)存儲的便利，但是只適合于存儲少量數(shù)據(jù)，且對耗時感知不是很強(qiáng)的場景，對于登錄和注冊這種關(guān)鍵性步驟，AsyncStoreage的性能還有有欠缺的。