Google应用程序脚本超时〜5分钟？
我的谷歌应用程序脚本迭代通过用户的谷歌驱动器文件和复制，有时移动文件到其他文件夹。 5分钟后脚本始终停止，日志中没有错误消息。
我在一次运行中sorting了数十甚至数千个文件。
有没有任何设置或解决方法？
配额
单个脚本的最大执行时间是6分钟/执行
– https://developers.google.com/apps-script/guides/services/quotas
但是还有其他的限制要熟悉一下。 例如，只允许一个小时/天的总触发器运行时间，所以不能将一个长function拆分为12个不同的5分钟块。
优化
也就是说，你真的需要花六分钟才能执行的原因很less。 JavaScript在几秒钟内sorting数千行数据应该没有问题。 对Google Apps本身的服务呼叫可能会损害您的performance。
您可以编写脚本，通过最大限度地减less读取和写入次数来充分利用内置caching。 交替读写命令很慢。 为了加速脚本，可以用一个命令将所有数据读入数组中，对数组中的数据执行任何操作，然后用一个命令写出数据。
– https://developers.google.com/apps-script/best_practices
配料
您可以做的最好的事情是减less服务电话的数量。 Google通过允许大部分API调用的批量版本来实现这一点。
作为一个微不足道的例子， 而不是这个 ：
for (var i = 1; i <= 100; i++) { SpreadsheetApp.getActiveSheet().deleteRow(i); } 这样做 ：
SpreadsheetApp.getActiveSheet().deleteRows(i, 100);
在第一个循环中，您不仅需要在工作表上调用100次deleteRow，还需要获得100次激活工作表。 第二个变化应该比第一个好几个数量级。
交织读取和写入
另外，你也应该非常小心，不要在阅读和写作之间频繁地来回走动。 您不仅会失去批量操作的潜在收益，但Google将无法使用其内置caching。
每次读取数据时，我们都必须清空（提交）写入caching，以确保您正在读取最新数据（您可以通过调用
SpreadsheetApp.flush()来强制写入caching）。 同样，每次写入时，都必须抛弃读取caching，因为它不再有效。 因此，如果您可以避免交错读取和写入，您将充分受益于caching。
– http://googleappsscript.blogspot.com/2010/06/optimizing-spreadsheet-operations.html
例如，而不是这个 ：
sheet.getRange("A1").setValue(1); sheet.getRange("B1").setValue(2); sheet.getRange("C1").setValue(3); sheet.getRange("D1").setValue(4);
这样做 ：
sheet.getRange("A1:D1").setValues([[1,2,3,4]]);
链接函数调用
作为最后的手段，如果你的function在六分钟之内真的不能完成，你可以将呼叫连接在一起，或者打破你的function，在一小段数据上工作。
您可以将数据存储在caching服务 （临时）或属性服务 （永久）存储区中，以便跨执行检索（因为Google Apps脚本具有无状态执行）。
如果您想启动另一个事件，则可以使用触发器构build器类创build自己的触发器，或在紧张的时间表上设置循环触发器。
找出一种分解工作的方式，这样只需要不到6分钟，因为这是任何脚本的限制。 在第一遍中，您可以迭代并存储电子表格中的文件和文件夹列表，并为第2部分添加时间驱动的触发器。
在第2部分中，删除列表中的每个条目。 当列表中没有项目时，删除触发器。
这就是我正在处理一个大约1500行的表格，这些表格被分散到大约十几个不同的电子表格中。 由于调用电子表格的次数，它会超时，但在触发器再次运行时会继续。
我开发了一个Google Apps脚本库，它使用UserProperties和编程触发器来运行一个超过6分钟的批处理。 你可以在你的GAS项目中导入这个库，然后用API包装你的代码，这样它就可以运行FOREVER（实际上，我们受限于与触发器可以运行的小时数有关的配额）
你可以在这里了解到这一切： http : //patt0.blogspot.in/2014/08/continuous-batch-library-update-for.html
如果您是商业客户，现在可以注册Early Access to App Maker ，其中包括灵活配额 。
在灵活配额制度下，这种硬配额限制被取消。 脚本在达到配额限制时不会停止。 相反，它们被延迟，直到配额可用，此时脚本执行恢复。 一旦开始使用配额，它们将按照正常费率重新填充。 为了合理使用，脚本延迟很less。
