Android-是否有可能制作无限画布？

目前我正在做的应用程序允许用户绘制。简单想想，只要扩展Canvas类，大部分事情就完成了

这是我最初的想法和想法。但是由于画布相当小，因为这只是用户在屏幕上看到的，所以没有太多可能的空间来绘制。浏览文档时，我找到了允许我移动画布的

translate（）

方法。我发现当我移动它时，会有一些空白，就像你移动一张纸一样。我明白这是完全正常的，就像我之前说过的——画布只是“屏幕”

我的问题是-有没有可能制作出类似于无限画布的东西，这样你就可以画出一幅巨大的画并移动所有东西？

在提出这个问题之前，我想了两件事，如何做到这一点：

同时移动画布上的所有对象——这不是个好主意，因为如果你有很多对象，那么移动的速度就非常差

当您移动它时（或者更好地在屏幕上查看），请执行与在

列表视图中类似的操作。只有屏幕上的视图以及一个before和一个after加载到内存中，其余视图在需要时动态上载。我认为这是实现这一目标的最佳选择

编辑：

Kai给出的问题/答案向我表明，编辑我的问题以澄清一些事情是值得的

关于用户可以做什么的基本假设：

• 用户有机会只画圆和矩形，其中一些（约80%）在画布上有可绘制（位图）的
• 我假设所有屏幕上最多有500-800个矩形或圆形

首先，关于无穷大，我想到的是相当多的屏幕-每侧至少有30个缩放1x。我只需要让我的用户在他们所做的事情上有更大的自由

在这个屏幕上，一切都可以正常进行-绘制、缩放（

TouchListener

、

ScaleListener

、

DoubleTapListener

）。当谈到缩放时，还有另一件事必须关注，并与画布的“无限”相联系。当用户缩小屏幕时，屏幕或不可见的“邻居”上更精确的对象应该以适当的比例显示，就像在现实生活中缩小相机一样

我刚刚意识到的另一件事是在小的缩放级别上画图的可能性——也就是在两个或三个屏幕上，然后放大——我想它应该剪切并重新计算它作为一个较小的部分

我希望至少从API 10支持设备，而不仅仅是高端设备

---

关于时间的问题是最关键的。我希望一切尽可能平滑，这样用户就不会知道每次都在创建新的画布。

我认为这取决于很多因素：

这个“无限画布”的复杂性：它到底有多“无限”，可以在上面做什么操作，等等

要支持的设备

您希望在这方面花费的时间/资源量

如果真的没有那么多的对象/命令需要绘制，并且您不打算支持老式/低端手机，那么您只需绘制所有内容就可以了。gfx系统将进行检查，并且只绘制实际显示的内容，因此您只需花费一些时间将通过JNI边界的命令发送到gfx系统和相关的rect检查

如果您决定需要更有效的方法，您可以将所有gfx对象的位置存储在4个树结构中，因此当您搜索屏幕应显示的左上/右上/左下/右下“窗口”时，将快速找到与此窗口相交的gfx对象，然后仅绘制这些对象

[编辑]

首先，我想到的是无穷大 屏幕数量-每侧至少30个放大1倍。我只需要 让我的用户在他们所做的事情上有更大的自由

如果您只是描述画布对象的相对位置，那么画布的大小几乎没有限制，但可能必须提供一个按钮，将用户带到画布上他们熟悉的某个点，以免他们迷失方向

当谈到缩放时，还有一件事必须考虑 与画布的“无限”有关并联系在一起。当用户 然后缩小屏幕或不可见屏幕上更精确的对象 “邻居”应该以适当的比例显示，因为你会缩小 现实生活中的照相机

如果将画布对象存储在“虚拟空间”中，并使用“转换因子”将对象从虚拟空间转换到屏幕空间，则放大/缩小之类的事情将非常简单，例如

screenObj.left=obj.left*transFactor-offsetX;
screenObj.right=obj.right*transFactor-offsetX;
screenObj.top=obj.top*transFactor-offsetY;
screenObj.bottom=obj.bottom*transFactor-offsetY;
//draw screenObj

以下是我的电影预订应用程序的屏幕截图：

下部窗口显示电影院的所有座位，上部窗口是同一影院的放大视图。它们被实现为同一SurfaceView类的两个实例，除了用户输入处理之外，唯一的区别是上面的一个应用了上述“翻译因子”

我假设所有屏幕上最多有500-800个矩形 或圆圈

其实还不算太坏。阅读您的编辑，我认为一个潜在的更大问题是，如果用户将大量对象添加到画布的同一部分。那么，如果你只画实际显示的对象，而不画其他东西，那就没关系了——因为GPU的填充率是饱和的，所以你仍然会得到很差的FPS

因此，实际上有两个潜在的问题来源：

绘制命令太多（如果在画布上绘制所有内容而不是仅绘制可见的内容）

t的同一部分中有太多大型对象