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

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

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

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

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

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

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

企業(yè)微信截圖_3f4025c4-f9b0-4ecd-9a2f-d362edbbf526.png