android.graphics.path的局限

前言： 用户需求使得应用必须通过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的最大限制值，因而布吉岛何时转换。