前言： 用戶需求使得應用必須通過Socket InputStream快速接收大約800K的數據，並將800K數據分成7個數組繪製成折線圖顯示在界面上。界面卡頓，各種警告、GC、skip frames……泡在Stack Overflow上搜索着問題和疑惑，發現了好多篇討論這類問題的Q&A，翻譯過來，以便更好理解
問題
我設計了一個自定義的能夠縮放的view，目的是爲了實現path繪製。path會首先被GPU加載爲texture，然後再繪製到界面，因而對path有一個最大容量的限制，這個限制在不同設備間也不相同。
我的自定義view最大可達30000像素，爲了避開最大texture的限制，我爲自定義view設置了setLayerType(LAYER_TYPE_SOFTWARE)。這取得了不錯的顯示效果，但是並不能實現60FPS。
爲了滿足界面刷新的幀率要求，我決定將view設置爲LAYER_TYPE_NONE。同時，和之前無法確定path的大小不同的是，我決定在縮放到一定程度的時候停止縮放，並且爲了進一步縮放，同比縮放canvas（代價則是清新簡明）。爲了確定應當停止的縮放程度，也就是確定何時停止縮放path，開始縮放canvas，我做了一些測試（測試設備時nexus7和nexus9）。
我希望能夠在達到texture最大限制時看到“path too large to be rendered into a texture”，也就是我需要調用canvas.inHardwareAccelrated()方法的地方。
1.對nexus7，texture的最大限制是2048，但是path在width和height達到2036的時候就消失（無法繪製）了，因爲此時log中已經出現了“path are too large to be rendered into a texture”。我本以爲這個數據應該是2048！
2.對nexus9，texture的最大限制是16384，但是有時候，應用會在還沒有達到最大限制的時候出現“A/libc: Fatal signal 11(SIGSEGV), code 1, fault addr 0x78 in tid 7252(RenderThread)”。例如，有許多不同尺寸的自定義view，（7199，5049），（13814，2500），（8040，4200），我發現它們的共同點就是這些自定義view的總區域（path也一樣）都超過了32,000,000像素。
因此，我無法精準地確定我何時應該由縮放path轉換爲縮放canvas。Any ideas as to when to do this?
問題補充
我發現在nexus9上，只要path的總區域達到了大約33,000,000，應用就會崩潰。這個限制的意義是什麼？
注
作者遇到了texture容量限制的問題，希望能在達到最大容量前，由path轉換爲canvas，但是無法準確定位出texture的最大限制值，因而布吉島何時轉換。
