今天在做客戶的項(xiàng)目時(shí)，有一個(gè)需求是App上要顯示遠(yuǎn)端的圖片，而遠(yuǎn)端的圖片有可能會(huì)更新，但圖片名不變。

成都創(chuàng)新互聯(lián)是一家專業(yè)提供廣信企業(yè)網(wǎng)站建設(shè),專注與成都網(wǎng)站制作、做網(wǎng)站、外貿(mào)營(yíng)銷網(wǎng)站建設(shè)、H5場(chǎng)景定制、小程序制作等業(yè)務(wù)。10年已為廣信眾多企業(yè)、政府機(jī)構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)網(wǎng)絡(luò)公司優(yōu)惠進(jìn)行中。

在react-native中，顯示圖片是用的自帶的Image組件，大家都知道react在更新組件之前都會(huì)判斷props或state是否有改變，當(dāng)有改變時(shí)才會(huì)更新，否則不會(huì)刷新頁(yè)面。

那問(wèn)題就來(lái)了，遠(yuǎn)端的圖片名不變，傳入Image組件的props就不會(huì)變，Image組件就不會(huì)刷新，當(dāng)遠(yuǎn)端的圖片內(nèi)容被修改之后，該怎么讓前端同時(shí)顯示最新的圖片呢？

在遇到這個(gè)問(wèn)題時(shí)，我是先在網(wǎng)上找到一個(gè)方法，說(shuō)是兩個(gè)同名的圖片，如果內(nèi)容不一樣，則轉(zhuǎn)成base64之后也不一樣，可以以這種方式讓前端刷新，

我當(dāng)時(shí)也覺(jué)得這是一個(gè)好方法，于是我寫(xiě)了如下代碼：

let buffer = await akita.get('/圖片地址').buffer();
let base64 = 'data:p_w_picpath/jpeg;base64,' + buffer.toString('base64');

render(){
    ...
    <Image source={{uri:this.state.base64}}/>
    ...
}

結(jié)果真的可以更新了，我興奮的打了一個(gè)release版放到真機(jī)上去測(cè)試，但沒(méi)過(guò)兩秒，app竟然閃退了，

瞬間感覺(jué)不會(huì)再愛(ài)了。

然后我開(kāi)始輸出日志查看，特別注明：不論是debug版還是release版，下面這條命令都能查看到輸出日志，但.....具體情況還是你們自己試一下吧，反正不會(huì)爆炸。

adb logcat androidRuntime:E/

然后就輸入了很多日志，全是關(guān)于java的，我都快哭了，最終，在日志里找到一個(gè)報(bào)錯(cuò)的輸出：

 FATAL EXCEPTION: mqt_js
Process: com.appscreen, PID: 28053
java.lang.RuntimeException: Error calling function: RCTDeviceEventEmitter:emit
        at com.facebook.react.bridge.queue.NativeRunnable.run(Native Method)
        at android.os.Handler.handleCallback(Handler.java:733)
        at android.os.Handler.dispatchMessage(Handler.java:95)
        at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:31)
        at android.os.Looper.loop(Looper.java:136)
        at com.facebook.react.bridge.queue.MessageQueueThreadImpl$3.run(MessageQueueThreadImpl.java:196)
        at java.lang.Thread.run(Thread.java:841)
 Caused by: java.lang.RuntimeException: Failed to create String from JSON:
        ... 7 more
   Force finishing activity com.appscreen/.MainActivity
D/dalvikvm(28053): GC_CONCURRENT freed 484K, 12% free 4735K/5344K, paused 5ms+3ms, total 50ms
D/dalvikvm(28053): WAIT_FOR_CONCURRENT_GC blocked 31ms
D/dalvikvm(28053): WAIT_FOR_CONCURRENT_GC blocked 42ms
D/dalvikvm(28053): WAIT_FOR_CONCURRENT_GC blocked 12ms
D/dalvikvm(28053): WAIT_FOR_CONCURRENT_GC blocked 14ms
D/dalvikvm(28053): WAIT_FOR_CONCURRENT_GC blocked 35ms
D/dalvikvm(28053): WAIT_FOR_CONCURRENT_GC blocked 27ms
D/dalvikvm(28053): GC_FOR_ALLOC freed 173K, 9% free 4985K/5452K, paused 21ms, total 22ms
D/dalvikvm( 1014): GC_FOR_ALLOC freed 292K, 22% free 7064K/9032K, paused 65ms, total 65ms
I/Choreographer(28053): Skipped 37 frames!  The application may be doing too much work on its main thread.
I/Process (28053): Sending signal. PID: 28053 SIG: 9
W/InputDispatcher( 1014): channel '41b9ec38 com.appscreen/com.appscreen.MainActivity (server)' ~ Consumer closed input channel or an error occurred.  events=0x9
E/InputDispatcher( 1014): channel '41b9ec38 com.appscreen/com.appscreen.MainActivity (server)' ~ Channel is unrecoverably broken and will be disposed!
W/InputDispatcher( 1014): Attempted to unregister already unregistered input channel '41b9ec38 com.appscreen/com.appscreen.MainActivity (server)'
I/ActivityManager( 1014): Process com.appscreen (pid 28053) has died.
I/WindowState( 1014): WIN DEATH: Window{41b9ec38 u0 com.appscreen/com.appscreen.MainActivity}
 Caught a RuntimeException from the binder stub implementation.
 java.lang.NullPointerException
      at android.inputmethodservice.IInputMethodWrapper.setSessionEnabled(IInputMethodWrapper.java:280)
      at com.android.internal.view.IInputMethod$Stub.onTransact(IInputMethod.java:129)
      at android.os.Binder.execTransact(Binder.java:404)
      at dalvik.system.NativeStart.run(Native Method)

看到這，我已經(jīng)心涼了，這是什么錯(cuò)，完全和自己寫(xiě)的代碼對(duì)不上號(hào)啊，

但是沒(méi)辦法，只能硬著頭皮去網(wǎng)上扒拉，希望能找到答案，

結(jié)果是........讓人很失望，我沒(méi)有找到怎么解決這個(gè)bug。

后來(lái)實(shí)在感覺(jué)弄不出來(lái)了，只好去請(qǐng)教大神，對(duì)話如下：

我：大神，我這有個(gè)問(wèn)題幫我看一下唄，

大神：  RN我也沒(méi)搞過(guò)啊，

........我很心涼，這時(shí)大神又問(wèn)了一句

大神： 你什么需求，

我： Q#$^#$&#@@&@（見(jiàn)文章開(kāi)頭）,

大神：這還不好辦，既然請(qǐng)求的是網(wǎng)絡(luò)圖片，你給圖片地址后面加隨機(jī)參數(shù)不就行了。

。。。。。。

好吧，大神就是大神，一句話讓我網(wǎng)上扒拉資料的4個(gè)小時(shí)變成了一堆廢渣。。

于是我就按大神說(shuō)的來(lái)做，

randomString() {
  len = 6;
  var $chars = 'ABCDEFGHJKLMNPQRSTUVWXYZabcdefhijklmnprstuvwxyz0123456789';
  var maxPos = $chars.length;
  var pwd = '';
  for (let i = 0; i < len; i+=1) {
    pwd += $chars.charAt(Math.floor(Math.random() * maxPos));
  }
  return pwd;
}

render(){

    let imgUrl = SERVER_HOST + '/pic/' + item.pic + '.jpg' + this.randomString();
    ...
    <Image source={{uri:imgUrl}}/>
    ...
}

好吧，不得不再次感嘆一聲，大神就是大神，一句話讓我之前寫(xiě)的代碼全白費(fèi)，又同時(shí)解決了我的問(wèn)題。

在此，感謝大神。

---------------------------下面是重點(diǎn)----------------------------------------------

想讓圖片刷新，就必須保證傳入 Image 組件的props是不一樣的，基于文件名相同，則只能：

1，使用base64，不同圖片內(nèi)容的base64是不一樣的，但這種方法可能會(huì)碰見(jiàn)我上面說(shuō)的坑。

2，因?yàn)槭蔷W(wǎng)絡(luò)圖片，所以，每一個(gè)圖片地址就像當(dāng)于一個(gè)API接口，是可以帶參數(shù)的。

    文件名后面跟上一些參數(shù)后，不管參數(shù)是什么，api接口沒(méi)有變就能得到圖片內(nèi)容，同時(shí)，因?yàn)閰?shù)不一樣，最終傳入Image組件的props也不一樣，這樣就能讓Image組件刷新了。

文章題目：react-native之遠(yuǎn)程圖片修改后APP不更新
文章起源：http://aaarwkj.com/article36/pdehsg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站排名、定制網(wǎng)站、云服務(wù)器、網(wǎng)站制作、響應(yīng)式網(wǎng)站、ChatGPT

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)