項目中遇到的問題
拖拽性能問題
排序問題，在 Safari 中排序不生效
Common.postRequest方法gesture手勢，pan，flick事件判定標(biāo)準(zhǔn)傳遞過程中需要傳遞
hybridid事件傳遞的組織方式
問題的解決
拖拽性能問題
頁面中要通過拖動時間點來確定出行的時間段，在拖動時，發(fā)現(xiàn)第一次拖拽dot時有明顯的卡頓跳躍現(xiàn)象。查看chrome timeline工具，會發(fā)現(xiàn)有這樣的提醒。
于是推斷是因為在定位中使用position：absolute，通過改變left值來修改dot位置使得頁面不停的reflow導(dǎo)致頁面卡頓，于是將dot的定位方式修改為通過transform屬性來改變位置，這樣對頁面其他部分不會產(chǎn)生影響。修改后頁面中還是會有卡頓現(xiàn)象出現(xiàn)，timeline中依然會提示上面的信息。應(yīng)該是因為在每次拖動改變時間段后對數(shù)據(jù)進(jìn)行篩選再重新渲染的緣故。但是改為transform方式還是對性能有一定的提升。
繼續(xù)查找卡頓的原因，發(fā)現(xiàn)只有在移動左側(cè)dot 時，會有明顯的跳躍現(xiàn)象。對left偏移值跟蹤處理發(fā)現(xiàn)，在拖動時，left偏移值第一次變化大概會有20px左右，問題應(yīng)該出在這里。仔細(xì)回想代碼之后，發(fā)現(xiàn)是因為獲取拖拽距離時，使用的了pageX屬性。剛開始計算修改后的位置是計算pageX-gapLeft，由于不會計算拖拽開始時的位置，只是獲取鼠標(biāo)結(jié)束點的pageX再賦值給startDot，這樣就會出現(xiàn)拖動開始第一次20px的跳躍，因為拖動的位置更偏向中間，而不是dot 點的最左側(cè)。找到問題的原因后，使用clinetX判斷起止點的位移差，這個值就是手指拖動時移動端真實距離。再修改后，跳躍問題確實有了很大的改觀，但是仔細(xì)觀察的話還是能發(fā)現(xiàn)有卡頓現(xiàn)象，這個是由于事件判定的原因?qū)е碌?，后面會講。
排序問題
為了使篩選出符合條件的車站排在最前面，對篩選出的數(shù)據(jù)進(jìn)行了排序，但是只判斷是否符合時間條件，會出現(xiàn)其他數(shù)據(jù)一直閃動的現(xiàn)象，因此我選擇了對車次的出發(fā)時間進(jìn)行二次判斷，這樣在被篩選出的車站不發(fā)生改變的情況下，其他車站的位置也不會發(fā)生變化。使用Array.sort()方法，對數(shù)組排序，由于是否在范圍內(nèi)使用boolean值進(jìn)行判斷，因此我判定相等時就直接返回了true/false。在chrome中，排序生效，但是在Safari中，排序無效，查閱相關(guān)資料發(fā)現(xiàn)，在Safari中，sort方法對boolean值類型的返回值無法進(jìn)行處理。隨后將返回值全部修改為正負(fù)值，成功解決了問題。
common.postRequest
由于后端接口是開放給客戶端的，因此在頁面中無法直接請求這種接口，必須要調(diào)用客戶端請求服務(wù)器的方法才能進(jìn)行，在QApp框架中，已經(jīng)定義好了Common.postRequest方法，可以直接調(diào)用客戶端中的插件。但是必須要在scheme鏈接中加上hybridid字段,必須是flight_bus_app/flight_ship_app才可以，否則無法調(diào)用客戶端的方法，可以在測試版的應(yīng)用上查看注冊的插件都有哪些。
手勢判定
判斷是否為拖拽行為時，會判斷持續(xù)時間有沒有超過300ms，如果沒有超過會判定為flick事件，因為pan事件開始的前300ms，事件并不會被觸發(fā)，導(dǎo)致拖動后的第一次位置變化會有微小的跳躍，但是并不明顯，暫時沒有很簡便的解決方法，除非重寫一個新的手勢判定標(biāo)準(zhǔn)。
