ClassLoader.getResourceAsStreamを使用した呼び出しパフォーマンスの問題の調査

AndroidアプリケーションでClassLoader.getResourceAsStream（）メソッドを呼び出すのに1432msかかり、一部のライブラリがどれほど危険であるかに興味がある場合は、catを使用してください。

問題の説明

Androidアプリケーションのパフォーマンスの問題を調査すると、この方法に気付きました。 問題は最初の呼び出しでのみ現れ、その後の呼び出しはすべて数ミリ秒かかりました。 興味深い機能は、問題が非常に多数のアプリケーションにあり、1億ダウンロード以上のAmazonのKindleから、数百ダウンロードの小さなものまでに及ぶことです。



別の機能は、さまざまなアプリケーションでこの方法がまったく異なる時間を要したことです。 ここでは、たとえば、最も人気のあるセルフィーアプリの時間です： B612-心からの自分撮り







ご覧のとおり、ここではメソッドの所要時間は771ミリ秒で、これも小さくありませんが、1432ミリ秒よりはるかに短くなっています。



問題の大きさを強調する非常に人気のあるアプリケーション。

（アプリケーションのプロファイルを作成するために、サービスhttps://nimbledroid.comが使用されました ）

アプリ	GetResourceAsStream（）ランタイム
ヤフーファンタジースポーツ	2166ms
タイムホップ	1538ms
Audibleのオーディオブック	1527ms
ナイキ+ランニング	1432ms
Booking.comホテル予約	497ms

その他多数。



いくつかのアプリケーションの呼び出しスタックを詳しく見てみましょう。



LINE：無料通話とメッセージ ：



ご覧のとおり、getResourceAsStream呼び出しはメインスレッドにはありません。 これは、Line開発者がそれがどれほど遅いかを認識していることを意味します。



Yahooファンタジースポーツ ：



呼び出しはアプリケーションコードではなく、 JodaTimeライブラリ内で発生します



Audibleのオーディオブック



呼び出しはLogbackライブラリで発生します。



この問題のあるアプリケーションを分析した後、この呼び出しが主にJarファイルとして配布されるさまざまなライブラリとSDKで使用されていることが明らかになりました。 この方法でリソースにアクセスできるため、これは論理的です。さらに、このコードはAndroidと大きなJavaの両方の世界で機能します。 多くの人がJavaの経験でAndroid開発に来て、もちろん、アプリケーションがどれほど遅いか知らずに、使い慣れたライブラリを使い始めます。 なぜこれほど多くのアプリケーションが影響を受けるのかが明らかになったと思います。



実際、彼らは問題について知っています。たとえば、stackoverflowには次のような質問がありました。AndroidJava-Joda Date is slow

2013年にこの投稿が書かれました： http : //blog.danlew.net/2013/08/20/joda_time_s_memory_issue_in_android/とそのようなライブラリが登場しましたhttps://github.com/dlew/joda-time-android



しかし、

1. JodaTimeの通常バージョンを使用するアプリケーションはまだ多くあります。
2. 同じ問題を持つ他の多くのライブラリとSDKがあります。

問題が明確になったので、その原因が何であるかを理解してみましょう。

研究課題

これを行うには、Androidのソースコードを理解します。

ソースの場所、AOSPの作成方法などについては詳しく説明しませんが、それでも自分で理解して自分の道を繰り返したい人のために、ここから始めましょう。https：// source.android.com/



android-6.0.1_r11ブランチを使用します



ファイルlibcore / libart / src / main / java / java / lang / ClassLoader.javaを開いて、getResourceAsStreamコードを見てみましょう。

public InputStream getResourceAsStream(String resName) { try { URL url = getResource(resName); if (url != null) { return url.openStream(); } } catch (IOException ex) { // Don't want to see the exception. } return null; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すべてが非常に単純に見えます。最初にリソースへのパスを見つけ、それがnullでない場合は、java.net.URLにあるopenStream（）メソッドを使用して開きます。



getResource（）の実装を見てみましょう：

 public URL getResource(String resName) { URL resource = parent.getResource(resName); if (resource == null) { resource = findResource(resName); } return resource; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

それでも面白くない、findResource（）：

 protected URL findResource(String resName) { return null; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

OK、つまりfindResource（）は実装されていません。 ClassLoaderは抽象クラスであるため、実際のアプリケーションで使用されているクラスを見つける必要があります。 ドキュメントhttp://developer.android.com/reference/java/lang/ClassLoader.htmlを開くと、 Androidがクラスの具体的な実装をいくつか提供しますが、PathClassLoaderが通常使用されます。 。



これを確認したいので、以前に同様の方法でgetResourceAsStream（）を変更して、AOSPを構築しました。

 public InputStream getResourceAsStream(String resName) { try { Logger.getLogger("RESEARCH").info("this: " + this); URL url = getResource(resName); if (url != null) { return url.openStream(); } ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

dalvik.system.PathClassLoaderと予想されるものを入手しましたが、PathClassLoaderのソースパスをチェックすると、 findResource（）の実装が見つかりません。 実際、 findResource（）は親クラスであるBaseDexClassLoaderに実装されています。

/libcore/dalvik/src/main/java/dalvik/system/BaseDexClassLoader.java ：

 @Override protected URL findResource(String name) { return pathList.findResource(name); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

pathListを見つけましょう（具体的には開発者のコ​​メントを削除しないので、内容を理解しやすくなります）。

 public class BaseDexClassLoader extends ClassLoader { private final DexPathList pathList; /** * Constructs an instance. * * @param dexPath the list of jar/apk files containing classes and * resources, delimited by {@code File.pathSeparator}, which * defaults to {@code ":"} on Android * @param optimizedDirectory directory where optimized dex files * should be written; may be {@code null} * @param libraryPath the list of directories containing native * libraries, delimited by {@code File.pathSeparator}; may be * {@code null} * @param parent the parent class loader */ public BaseDexClassLoader(String dexPath, File optimizedDirectory, String libraryPath, ClassLoader parent) { super(parent); this.pathList = new DexPathList(this, dexPath, libraryPath, optimizedDirectory); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このDexPathListに移りましょう。

libcore / dalvik / src / main / java / dalvik / system / DexPathList.java ：

 /** * A pair of lists of entries, associated with a {@code ClassLoader}. * One of the lists is a dex/resource path &mdash; typically referred * to as a "class path" &mdash; list, and the other names directories * containing native code libraries. Class path entries may be any of: * a {@code .jar} or {@code .zip} file containing an optional * top-level {@code classes.dex} file as well as arbitrary resources, * or a plain {@code .dex} file (with no possibility of associated * resources). * * <p>This class also contains methods to use these lists to look up * classes and resources.</p> */ /*package*/ final class DexPathList {
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

リソース検索が実際に実行される場所を見つけたようです。

 /** * Finds the named resource in one of the zip/jar files pointed at * by this instance. This will find the one in the earliest listed * path element. * * @return a URL to the named resource or {@code null} if the * resource is not found in any of the zip/jar files */ public URL findResource(String name) { for (Element element : dexElements) { URL url = element.findResource(name); if (url != null) { return url; } } return null; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

要素は、 DexPathListの単なる静的な内部クラスです 。 そして、その中にはもっと面白いコードがあります：

 public URL findResource(String name) { maybeInit(); // We support directories so we can run tests and/or legacy code // that uses Class.getResource. if (isDirectory) { File resourceFile = new File(dir, name); if (resourceFile.exists()) { try { return resourceFile.toURI().toURL(); } catch (MalformedURLException ex) { throw new RuntimeException(ex); } } } if (zipFile == null || zipFile.getEntry(name) == null) { /* * Either this element has no zip/jar file (first * clause), or the zip/jar file doesn't have an entry * for the given name (second clause). */ return null; } try { /* * File.toURL() is compliant with RFC 1738 in * always creating absolute path names. If we * construct the URL by concatenating strings, we * might end up with illegal URLs for relative * names. */ return new URL("jar:" + zip.toURL() + "!/" + name); } catch (MalformedURLException ex) { throw new RuntimeException(ex); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これについてもう少し詳しく見ていきましょう。 知っているように、APKは単なるzipファイルです。 見ての通り：

 if (zipFile == null || zipFile.getEntry(name) == null) {
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ZipEntryを名前で検索し、見つかった場合はjava.net.URLを返します。 これはかなり遅い操作かもしれませんが、 getEntryの実装を確認すると、これはLinkedHashMapの単なる反復であることがわかります。



/libcore/luni/src/main/java/java/util/zip/ZipFile.java ：

 ... private final LinkedHashMap<String, ZipEntry> entries = new LinkedHashMap<String, ZipEntry>(); ... public ZipEntry getEntry(String entryName) { checkNotClosed(); if (entryName == null) { throw new NullPointerException("entryName == null"); } ZipEntry ze = entries.get(entryName); if (ze == null) { ze = entries.get(entryName + "/"); } return ze; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは超高速操作ではありませんが、非常に長い時間はかかりません。



ひとつ忘れてしまったのは、Zipファイルを操作する前に、それらを開く必要があるということです。 DexPathList.Element.findResource（）メソッドの実装をもう一度見ると、 maybeInit（）が表示されます。 。

それをチェックしてみましょう：

 public synchronized void maybeInit() { if (initialized) { return; } initialized = true; if (isDirectory || zip == null) { return; } try { zipFile = new ZipFile(zip); } catch (IOException ioe) { /* * Note: ZipException (a subclass of IOException) * might get thrown by the ZipFile constructor * (eg if the file isn't actually a zip/jar * file). */ System.logE("Unable to open zip file: " + zip, ioe); zipFile = null; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここにある！ この行：

 zipFile = new ZipFile(zip);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

zipファイルを読み取り用に開きます。

 public ZipFile(File file) throws ZipException, IOException { this(file, OPEN_READ); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは非常に遅い操作です。ここでは、 エントリを LinkedHashMapに初期化します 。 明らかに、zipファイルが大きいほど、開くのに時間がかかります。 初期化されたフラグのため、zipファイルを1回だけ開きます。これにより、後続の呼び出しがすぐに発生する理由がわかります。



Zipファイルの内部構造をさらに理解するには、ソースを参照してください。

https://android.googlesource.com/platform/libcore/+/android-6.0.1_r21/luni/src/main/java/java/util/zip/ZipFile.java



おもしろかったです！ それは始まりにすぎないからです。

実際、これまでは呼び出しのみを扱ってきました。

 URL url = getResource(resName);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、getResourceAsStreamコードを次のように変更した場合：

 public InputStream getResourceAsStream(String resName) { try { long start; long end; start = System.currentTimeMillis(); URL url = getResource(resName); end = System.currentTimeMillis(); Logger.getLogger("RESEARCH").info("getResource: " + (end - start)); if (url != null) { start = System.currentTimeMillis(); InputStream inputStream = url.openStream(); end = System.currentTimeMillis(); Logger.getLogger("RESEARCH").info("url.openStream: " + (end - start)); return inputStream; } ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

AOSPを収集し、いくつかのアプリケーションをテストするため、 url.openStream（）はgetResource（）よりもはるかに時間がかかることがわかります。

url.openStream（）

この部分では、あまり興味深い点をいくつか省略します。 url.openStream（）からの呼び出しのチェーンに沿って移動すると、 /libcore / luni / src / main / java / libcore / net / url / JarURLConnectionImpl.javaに到達します 。

 @Override public InputStream getInputStream() throws IOException { if (closed) { throw new IllegalStateException("JarURLConnection InputStream has been closed"); } connect(); if (jarInput != null) { return jarInput; } if (jarEntry == null) { throw new IOException("Jar entry not specified"); } return jarInput = new JarURLConnectionInputStream(jarFile .getInputStream(jarEntry), jarFile); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

connect（）メソッドを確認しましょう：

 @Override public void connect() throws IOException { if (!connected) { findJarFile(); // ensure the file can be found findJarEntry(); // ensure the entry, if any, can be found connected = true; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

面白いことは何もありません。もっと深くする必要があります:)

 private void findJarFile() throws IOException { if (getUseCaches()) { synchronized (jarCache) { jarFile = jarCache.get(jarFileURL); } if (jarFile == null) { JarFile jar = openJarFile(); synchronized (jarCache) { jarFile = jarCache.get(jarFileURL); if (jarFile == null) { jarCache.put(jarFileURL, jar); jarFile = jar; } else { jar.close(); } } } } else { jarFile = openJarFile(); } if (jarFile == null) { throw new IOException(); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは興味深い方法であり、ここで停止します。 一連の呼び出しを通じてgetUseCaches（）を使用すると、

 public abstract class URLConnection { ... private static boolean defaultUseCaches = true; ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この値はオーバーライドされないため、キャッシュの使用が表示されます。

 private static final HashMap<URL, JarFile> jarCache = new HashMap<URL, JarFile>();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

findJarFile（）メソッドには、2番目のパフォーマンスの問題があります！ zipファイルが再び開きます！ 当然、これは、特にサイズが40MBのアプリケーションでは、すぐには機能しません:)



もう1つの興味深い点があります。openJarFile（）メソッドを確認しましょう。

 private JarFile openJarFile() throws IOException { if (jarFileURL.getProtocol().equals("file")) { String decodedFile = UriCodec.decode(jarFileURL.getFile()); return new JarFile(new File(decodedFile), true, ZipFile.OPEN_READ); } else { ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のとおり 、 ZipFileではなくJarFileを作成しています 。 JarFileはZipFileの子孫です。追加することを確認しましょう。

 /** * Create a new {@code JarFile} using the contents of file. * * @param file * the JAR file as {@link File}. * @param verify * if this JAR filed is signed whether it must be verified. * @param mode * the mode to use, either {@link ZipFile#OPEN_READ OPEN_READ} or * {@link ZipFile#OPEN_DELETE OPEN_DELETE}. * @throws IOException * If the file cannot be read. */ public JarFile(File file, boolean verify, int mode) throws IOException { super(file, mode); // Step 1: Scan the central directory for meta entries (MANIFEST.mf // & possibly the signature files) and read them fully. HashMap<String, byte[]> metaEntries = readMetaEntries(this, verify); // Step 2: Construct a verifier with the information we have. // Verification is possible *only* if the JAR file contains a manifest // *AND* it contains signing related information (signature block // files and the signature files). // // TODO: Is this really the behaviour we want if verify == true ? // We silently skip verification for files that have no manifest or // no signatures. if (verify && metaEntries.containsKey(MANIFEST_NAME) && metaEntries.size() > 1) { // We create the manifest straight away, so that we can create // the jar verifier as well. manifest = new Manifest(metaEntries.get(MANIFEST_NAME), true); verifier = new JarVerifier(getName(), manifest, metaEntries); } else { verifier = null; manifestBytes = metaEntries.get(MANIFEST_NAME); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ええ、それが違いです！ 知っているように、APKファイルは署名されている必要があり、 JarFileクラスはこれを検証します。



検証の仕組みを理解したい場合は、これ以上先に進みません。https ： //android.googlesource.com/platform/libcore/+/android-6.0.1_r21/luni/src/main/java/java/utilをご覧ください/ jar / 。



しかし、言わなければならないことは、それが非常に非常に遅いプロセスであることです。

おわりに

ClassLoader.getResourceAsStream（）が初めて呼び出されると、APKファイルはリソースを見つけるためのzipファイルとして開きます。 その後、2回目に開きますが、InputStreamを開くための検証が行われます。 また、さまざまなアプリケーションで通話速度に大きな違いがある理由も説明しますが、それはすべてAPKファイルのサイズと内部にあるファイルの数に依存します。

もう一つ

nimbledroidの右上隅の[ フルスタックトレース]セクションで[Androidフレームワークの展開 ]をクリックすると、実行したすべてのメソッドが表示されます。

Q＆A

Q：DalvikとARTランタイム、およびgetResourceAsStream（）呼び出しの操作に違いはありますか



A：実はいいえ、 android-6.0.1_r11のいくつかのAOSPブランチをARTで、 android-4.4.4_r2の Dalvikをチェックしました。 両方に問題があります！

それらの違いはわずかに異なりますが、これについては多くのことが書かれています:)



Q：ClassLoader.findClass（）を呼び出すときに、このような問題がないのはなぜですか



A：既にわかっているDexPathListクラスに移動すると、 次のように表示されます。

 public Class findClass(String name, List<Throwable> suppressed) { for (Element element : dexElements) { DexFile dex = element.dexFile; if (dex != null) { Class clazz = dex.loadClassBinaryName(name, definingContext, suppressed); if (clazz != null) { return clazz; } } } if (dexElementsSuppressedExceptions != null) { suppressed.addAll(Arrays.asList(dexElementsSuppressedExceptions)); } return null; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

一連の呼び出しに続いて、メソッドに到達します。

 private static native Class defineClassNative(String name, ClassLoader loader, Object cookie) throws ClassNotFoundException, NoClassDefFoundError;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さらに、これがどのように機能するかはランタイム（ARTまたはDalvik）に依存しますが、ご覧のとおり 、 ZipFileでは機能しません。



Q：Resources.get ...（resId）の呼び出しにこの問題がないのはなぜですか



A：ClassLoader.findClass（）と同じ理由で。

これらの呼び出しはすべて、 / frameworks / base / core / java / android / content / res / AssetManager.javaにつながります。

 /** Returns true if the resource was found, filling in mRetStringBlock and * mRetData. */ private native final int loadResourceValue(int ident, short density, TypedValue outValue, boolean resolve);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご清聴ありがとうございました！ ハッピーコーディング！