react-native-charts-wrapper組件庫Linechart折線圖中默認自動滾動的解決方案-----react-native專案整理

只要使用過react-native繪制過圖表的人都知道，react-native-cahrts-wrapper是github上chart方面非常棒的組件庫，這這個組件庫里面RN開發者可以很輕松的找到各種想要的圖表，實乃居家旅行，rn開發的利器，

附上github地址：https://github.com/wuxudong/react-native-charts-wrapperhttps://github.com/wuxudong/react-native-charts-wrapper

問題背景：

首先，在專案中有一個起著關鍵功能的圖表，這個圖表是一個折線圖，這個折線圖的資料源是不斷重繪的，但是重繪的頻率不定，可能是1s重繪一個資料，也可能是兩秒重繪一個點，那么折線圖的樣子應該很容易想象，就不截屏了，現在的問題是：我們的折線圖一屏的起點默認就是第一個x軸坐標，這就很不好，因為在這個折線圖中的資料在使用后期會形成一個堆積，導致最后的折線圖完全不具備可讀性，所以我第一個要解決的問題就是如何使得折線圖能夠滾動起來，

你可能會說，當一屏中的資料堆積起來后，可以直接通過手指對圖表進行伸縮使得圖表前后滑動，沒必要再寫什么解決方案了啊，

沒錯，react-native-charts-wrapper確實提供了通過手指對圖表進行水平和豎直方向的伸縮，我在后面的解決方案中也使用了這個方法，那我們什么還要做這個？

要知道，當用戶一開始懷著一定的需求進入你的APP，他一定是急切的想要找到他需求的解決方法，如果你能夠妥善解決，才有可能讓這個用戶長期使用你的APP，如果的你操作過于冗余，我們很有可能會喪失這個用戶，就拿這個問題做例子，我們為什么要做成一進入圖表頁面就直接默認滾動，而不是等著用戶對這個他根本不知道怎么使用的APP中的圖表進行手動伸縮，這是很簡單的道理，市面上有這么多同款的APP，用戶憑什么選擇你的APP，具有圖表的工具類APP就要有簡單操作的覺悟，只要能留住用戶，在后續的改版中，再對操作進行精細化處理也不晚，

第一個問題：如何使得圖表能夠自動滾動

首先，對于這個問題，我查閱了該組件庫在github上面的說明檔案，檔案也不是很多，當然也不會很詳細，一開始什么都沒有看出來，直到我查看這個組件庫的issues我看到了一個屬性似乎可以解決我的問題：Zoom，

一開始當我把這個zoom屬性寫到我的Linechart中時，我發現，當scaleX、sacleY、xValue以及yValue不為默認值時，他們對圖表會進行一個縮放，而且是既可以放大也可以縮小，這就給了我很大的啟發：我是不是可以直接利用這個伸縮來實作跟手動滑動一樣的效果，接著我發現這個操作是可以實作的，只不過當scaleY不為默認值后，伸縮到的y坐標值會不可見，所以我將scaleY設定為默認值，這樣就可以只伸縮x軸以來達到間接性的自動水平滑動效果，做完這些我喜滋滋的以為我的任務完成了，但是事情并未簡單的結束，

上面的上午做完的任務，下午我閑著沒事我就打開專案除錯，結果我發現，圖表根本加載不出來，直接導致了軟體宕機，只有重啟軟體才能重新回到頁面，我心想，壞了，趕緊打開vscode除錯代碼，一除錯不要緊，除錯完我就傻了眼，我才知道了原因：

上午寫代碼進行除錯時，我直接使用的是保存重繪，也就是區域重繪APP，而下午啟動APP是重繪APP整體，上午寫的那一行代碼中的yValue導致了整個程式的崩潰，這是萬萬想不到的，而導致yValue不能使用的原因可能是我的圖表x軸并非數字，而是進行了format處理的時間，反正不知道咋回事，yValue屬性不能在重繪整個APP后第一次使用圖表時出現在圖表屬性中，我心想，這還好，直接把這個屬性去掉不就成了，結果出乎我的意料，當Linechart中不包含yValue屬性后，圖表不能跟上午一樣進行伸縮了，這可就壞了，也引出了下一個問題，

第二個問題：如何能夠在一開始不放入yValue屬性的情況下，使得圖表能夠伸縮

其實，這個時候我就已經知道該怎么辦了，不就是一開始不能放入yValue嗎，我等著圖表重繪一段時間后我在重繪Zoom屬性不就可以解決這個問題了，嘿嘿，充分看完這個組件庫issue的我，確實解決了這個問題，

其實在Zoom屬性中，對于我們這個應用場景來說，只有scaleX這個屬性的值是有意義的，而其他的屬性雖然不需要變動，但是保持固定值是必要的，

zoom: {scaleX: 1, scaleY: 1, xValue: 2},

這是一開始沒有yValue的zoom屬性，這種寫法是不能進行縮放的，

    zoom :{scaleX: 1.2, scaleY: 1, xValue: 200, yValue: 500},

這是后來需要對圖表進行縮放時，替換的zoom屬性，200和500都是為了在放大后顯示螢屏能夠緊跟最新重繪的資料設定的，而scaleX等于1.2就使得圖表在x軸方向成功伸展，可以達到預期的目標，

至于我是怎么在圖表運行之后自動啟用重繪zoom屬性的這個方法，看下面代碼：

if (
            (secondall1 - secondall == 40 && minuteall1 == minuteall) ||
            (minuteall1 - minuteall == 1 &&
              secondall1 + 60 - secondall == 40) ||
            (hourall1 - hourall == 1 && secondall1 + 60 - secondall == 40)
          ) {
            //啟用重繪zoom的函式
          }

secondall和minuteall是圖表啟動的時間，secondall1和mintueall1是當前圖表重繪周期中獲取的時間，只要距離啟動時間為40秒，就會啟動重繪zoom的函式，

我本以為我可以再次高枕無憂了，現實卻又一次打了我的臉，

我發現：如果我只讓啟動40s后重繪zoom以來達到滑動x軸的目的，確實在圖表資料更新的前期可以達到我的目的，但是隨著圖表資料的不斷重繪，可視一屏不斷向后滾動，我吃驚的發現了一個大問題：到了后期，我原先設計的40s一屏就慢慢變成了50s甚至是60s，這可是一個大問題，重繪的并不均衡，

第三個問題：如何能夠讓圖表保持40s一屏的方式進行滾動

為了解決這個問題，我觀察了好久圖表的滾動到底為什么到最后會成60s，在看了n次整個程序后，我發現，圖表更新的那個方向沒有問題，但是，不知道為什么，一屏中最左邊的滾動卻想比右邊的重繪跨度要小一點，就小這么一點，就導致了當資料堆積，一屏中x軸的范圍擴大了很多，

一開始，我對于這個問題的解決方案是，在圖表啟動40s，也就是資料重繪了40s之后，呼叫以下方法：

 resetZoom=(scale_switch)=>{
    this.setState({
    zoom :{scaleX: this.state.scaleX, scaleY: 1, xValue: 200, yValue: 500},
    });
    this.state.scaleX=this.state.scaleX+scale_switch;
    }

在確認達到40s的判斷陳述句中，我這樣寫：

if (
            (secondall1 - secondall == 40 && minuteall1 == minuteall) ||
            (minuteall1 - minuteall == 1 &&
              secondall1 + 60 - secondall == 40) ||
            (hourall1 - hourall == 1 && secondall1 + 60 - secondall == 40)
          ) {
            let scale1=setInterval()//什么一大堆
          }

就是在40s的判斷陳述句中，我們寫一個定時器，這個定時器每隔一個周期，就會呼叫一次resetZoom方法，從而進行x軸的伸縮，

可能有朋友會問：你對x軸進行伸縮干嘛，你需要解決的是前后滾動速度的不一致問題，

我這樣說吧，我們已知靠近y軸那邊的資料滾動速度慢，而我們又通過設定zoom屬性的200和500固定了我們默認視野是在最右方，那么能夠抵消x軸縮放的只有擴展x軸，通過resetZoom屬性我們就可以通過定時器來周期性的對x軸進行擴展，從而使得一屏保持只有40s，

除此之外我還發現，圖表越滾動到后面，它x軸收縮的速度就越快，那么要保持40s我們只能相應的加快x軸的擴展速度，這也是我為什么要寫resetZoom這個可以傳參的函式，

這個問題就不單列出來了，多設定幾個判斷時間的陳述句就成，而且我們為了保證不同時出現多個定時器，我們從第二個時間節點開始，每進入一個if判斷，我們就取消上一個時間節點的定時器，

到此為止，我們的滾動是實作了，雖然確實是40s一屏，但是圖表總感覺是一卡一卡的，因為x軸擴展的太過于劇烈了，啥啥都是問題，

第四個問題：如何使得圖表滾動時更加的自然，而不是一卡一卡的

一開始對于這個問題，我感徑訓是很好解決的，我直接把每一個時間節點的定時器周期跳到0.1秒，企圖讓用戶看不出來圖表進行了擴展，但是事與愿違，這樣寫不但使得x軸的擴展更加的明顯且別扭，而且由于定時器呼叫過于頻繁，軟體后期會直接卡死，

完美的解決方案是：將各個時間點的判斷寫到圖表控制重繪的定時器中，不知道這一步的小伙伴記得看我上一篇關于圖表解耦的blog，只要判斷在定時器中，我們在對時間點的判斷中就不用再寫定時器，直接就可以呼叫相應x軸擴展范圍的resetZoom函式，

對了，還記得我的資料時不定期重繪的嗎，所以在對時間點的判斷中還要加入對是否在這個圖表更新周期中有資料重繪進行限制，只有進行資料重繪的定時器周期才能呼叫resetZoom函式進行x軸的擴展，

就這樣，當每一秒有資料重繪的時候，我們靠近y軸的那一方的線就會神不知鬼不覺的擴展一下，以來抵消圖表原有的缺陷，

這篇文章寫到這里就結束了，寫了4530字，純手敲，純原創，求個贊不過分吧