UiPathの動作高速化チューニング

By | 2018年10月21日

UiPathの動作高速化チューニング

※2018.3よりUiPathがデフォルト日本語のアクティビティ名となりましたので、
この記事では各アクティビティや機能名を日本語名(英語名)というように記載しています。

UiPathの動作を人に見せると帰ってくる反応のひとつとして、「もっと早く動かないの?」というのがあります。
実は十分な検証をすることができるのであれば、スピードアップにチャレンジすることもできます。
ここでは具体的にどのあたりをチューニングするかのポイントを解説していきます。

チューニングポイント1:操作系アクティビティ前後の待機時間

 

実はUiPathのマウス操作やキーボード操作はデフォルト設定でワンアクション(アクティビティ)ごとに、
前に0.2秒、後ろに0.3秒の、合わせて0.5秒遅延が入っています。(プロパティ>共通)
当然、これらは意味もなく入っているわけではありません。
これを短くすれば対象のアプリケーションによっては反応が追いつかなくなり、
ついにはUiPath側の動作が追い越してしまい、エラーになってしまうというリスクがあるからです。
逆に言うと十分な検証を行えば、最速で0秒の待機とすることもできます。

まずマウスクリックやキーボード操作を見ていきましょう。
こういったタイプのアクティビティには確実にプロパティで個の項目がありますので、
待機時間を前後合計0.5秒以下になるように設定していきましょう。
なお、これ以外のタイプ、例えばEXCELファイルの読み込み、
代入などのアクティビティにはこういった設定はありません。

この時にお勧めなのが、設定値を変数にすることです。

(ホントは設定ファイルでデフォルト値を一律変更できるといいんですけどね¨)

これにより、デバッグモードの低速ステップのように、代入(Assign)アクティビティと組み合わせて、
一律動作速度を変更することができるようになります。

もちろん検証によってこの部分は待機無し、この部分は待機あり、
という細かいチューニングが必要な場合はこのやり方はお勧めできません。

チューニングポイント2:文字を入力(Type Into)アクティビティ

例えばファイルを保存するとき、フォームへ入力をするときなど、
文字を入力(Type Into)アクティビティでキーボードの自動入力操作が行われます。
この入力操作は大量の文字を入力することもよくあるので、
動作中の見た目は自動化しているな~というインパクトがありますが、
これが何千、何万件ともなってくると、塵も積もればで遅延の原因となります。
これを高速化するには2つの方法があります。

2-1.文字を入力(Type Into)プロパティで「入力をシミュレート」のチェックを入れる

1つ目の方法は文字を入力(Type Into)プロパティで「入力をシミュレート」のチェックを入れることです。
このチェックを入れている状態がこのアクティビティで一番早いキーボード入力をすることが可能な状態になります。
普段は人がキーボードを打っているような感じで文字が入っていくのですが、
このチェックが付いている場合は一瞬で全文字が入ります。
※ちなみにもう一つ「ウィンドウメッセージを送信」というプロパティも入力方法を変更しますが、こちらは逆に一番遅くなります。デフォルトはどっちにもチェックが付いていません。

じゃあ全部「入力をシミュレート」だけでいいと思うかもしれませんが、
これにも一つ欠点があり
対象によってはうまく動作しないことがあります。
具体的にはTabキーを押させたいときに「”k[tab]”」などの特殊な記載方法をしますが、
これがキーボードのキーとして認識されず、そのまま文字のk[tab]として打たれることがあります。
やっかいなことにちゃんと入力される部分(部品)もあれば、ちゃんとtabキーとして動作する部分もあるため、
先ほど説明した「検証が必要」という部分になります。

長文入力系処理の際にここがうまく動作すると、例えば1秒かかっていたものが0.5秒になるだけで、

遅延時間は件数×0.5秒となるわけですから、件数が多ければ多いほど見直す価値が出てくるということです。

2-2.クリップボードのコピー&ペーストで入力させる

2つ目の方法は「クリップボードに設定(Set To Clipboard)」アクティビティと、
「ホットキーを押下(send hotkey)」アクティビティを組み合わせる方法です。
クリップボードにいったん打ち込みたい文字を設定し、それを貼りつけ(Ctrl+v)操作で貼りつけることにより、
文字入力ではなく貼りつけによって文字列を一気に設定します。

この方法の利点はただのWindows操作となるため応用範囲が広く、どの部品でもたいてい同じ動作をすることです。
欠点はクリップボードを操作するため、一部の高速化のためにクリップボードを使うようなEXCELマクロや、
クリップボード操作をするWebページなどとは相性が悪いです。

また、そもそもペースト(Ctrl+v)が効かない部分には使えません。まあ、めったにないですが。

2-3.Set Textアクティビティを使う

こちらはセレクターが指定できる、という前提条件が必要ですが、貼りつけのように高速にセットできます。
存在自体を忘れられがちなのですが、文字を入力(Type Into)よりまずこれを試した方がよいかもしれません。

チューニングポイント3:「待機(Delay)」アクティビティを切り替える

繰り返し処理の中で「待機(Delay)」アクティビティを使っていませんか?少数の繰り返しであれば問題はありませんが、
例えば3秒の待機処理を1000回繰り返した場合、何もやっていない時間は合計で3000秒となり、
合計50分も待機していることになります。もちろんこのチェック間隔を短くするのも一つの手ではありますが、
無駄な負荷をかけたくないというジレンマもあります。

それではどうやってこういった待機を見直せばよいのでしょう?
例えば次のウィンドウが出るまでを待つ処理であれば、余裕をみて5秒や10秒間隔で待機を使ってループ、
と設定するのではなく「要素を探す(Find Element)」アクティビティや、
「画像を探す(find Image)」アクティビティにすることで、指定した(デフォルト30秒)の中で、
条件を満たしたら動く、ということができます。
これで出ていようが出ていまいが待つ、ということはなくなりますので、必要最低限の待ち時間になります。

しかし、これらのアクティビティが万能ではないのも確かで、例えば「要素を探す(Find Element)」は、
見つけるのが早すぎる(処理を追い越す)ということがたびたびあります。
なので、要素を探すのみでうまくいかないのであれば、
要素を探す(Find Element)の後にセットで待機(Delay)アクティビティをごく短い時間設定する、
というのが現実的な解決方法かもしれません。
画像の方は「画面上に出ていること」という条件が常に不安要素となります。

ファイル作成系の処理でファイル作成待ちをしているあれば、
「イベントを監視(Monitor Events)」+「ファイル変更トリガー(File Change Trigger)」アクティビティを組み合わせるのもよいでしょう。