2016-08-19 3 views
1

任意の要素のXCUIElementツリー全体を再帰的に参照し、指定されたラベルまたはIDを持つ子要素を返す関数findElementWithLabel()を構築しようとしています。組み込みのchildrenMatchingType()関数とは異なり、子どもは直接的な子供だけでなく、複数のレベルの深みを検索します。良いパフォーマンスでXCUIElementツリーを再帰的に検索するには?

public extension XCUIElement { 

     public func findElementWithLabel(label: String) -> XCUIElement? { 
      return findElementWithName(self, name:label) 
     } 

     private func findElementWithName(elementToSearch:XCUIElement?, name: String) -> XCUIElement? { 
      if let currentElement = elementToSearch { 
       if currentElement.label == name { 
        return currentElement 
       } 
      } else { 
       return nil 
      } 

let children = elementToSearch?.childrenMatchingType(.Any) 
      var loopIndex:UInt = 0 
      while (loopIndex < children?.count) { 
       let foundElement = findElementWithName(children?.elementBoundByIndex(loopIndex), name:name) 
       if let unwrappedFoundElement = foundElement { 
        return unwrappedFoundElement 
       } 
       loopIndex += 1 
      } 

      return nil 
     } 

    } 

機能が適切な結果を返しますが、残念ながらパフォーマンスを返すために、ほぼ10〜15秒を取って恐ろしいです:私はここのサンプルコードは、XCUIElementの拡張としてこの機能を構築しています。 xcode UIの自動化に関する専門家は、これを引き起こす可能性のあるものを推論するのに役立つでしょうか?もともと私はそれが "XCUIElement.childrenMatchingType(.Any)"の繰り返し呼び出しだと考えましたが、これを排除することができます。この関数の平均計算時間は0.007秒です。私はそれを約30回呼び出します。これは、それが原因ではないことを意味します。私が持っている唯一の他の理論は:

1)いくつかの遅延がどこかで適用されており、実行時間に大きな影響を与えます。私はこの関数をjavascriptのapiとUIATarget.localTarget()を呼び出して、この関数を書きました。その後、popTimeout(0)でツリーをたどる前にpushTimeout(0)を実行しました。これは本質的に私の再帰的な関数呼び出しが遅れたり、要素を待ったりしないようにしました...もしこれが原因であれば、この新しいpushTimeout()とpopTimeout()

2)新しいui-automationによるxcodeコンソールログの膨大な量が、ランタイムに影響している必要があります。私はNSLogの同期と速度が遅いことを知っているので、これが原因でしょうか?もしそうなら、これらのログをどのように切り替えることができますか?組み込みのxcode xctestデバッグログが実行時間に非常に大きな影響を及ぼす場合、これをどのように進めることができますか?開発者としては、これらのログが必要ですが、このようなランタイムに影響を与えることもできません。

+0

達成しようとしていることは何ですか? XCUIElementQueryを使用しない理由があると思いますか? – Oletha

+0

私はXCElementQueryを使用していると考えました... – AyBayBay

答えて

0

私は私の質問に対する答えを見つけました。私の再帰呼び出しはElementレベルで動作していたようで、ElementQueryレベルで作業しているはずです。要素が一度だけ解決され、クエリチェーンが解決されるため、クエリの作成が大幅に高速化されます。

新しいAPIでは、要素を解決することは、毎回要素を解決して確認するためにアプリと通信するため、非常にコストがかかるようです。私はJavascript APIもこれを行っていたと思われますが、ElementQuery構造体が公開されていないので、タイムアウトを0にして、各要素の処理を遅らせて解決するようにフレームワークに指示しました。とにかく、私の質問への答えは、ルート要素にdescendantsOfElement()を使用し、ラベル/ idクエリを書くことでした。

関連する問題