Summary:
## Context
A React Native application can configure its RCTImageLoader by initializing it with two different sets of objects:
- id<RCTImageURLLoader>
- id<RCTImageDataDecoder>
Therefore, RCTImageLoader supports this initializer:
```
- (instancetype)initWithRedirectDelegate:(id<RCTImageRedirectProtocol>)redirectDelegate
loadersProvider:(NSArray<id<RCTImageURLLoader>> * (^)(void))getLoaders
decodersProvider:(NSArray<id<RCTImageDataDecoder>> * (^)(void))getHandlers
```
Right now, both the id<RCTImageURLLoader>s and id<RCTImageDataDecoder>s are NativeModules. So, they need to be loaded using the Bridge/TurboModuleManager.
## Problem
The method [that constructs RCTImageLoader](https://www.internalfb.com/code/fbsource/[6530647879a5e6d5edcfad029b39879c87e97bb3]/fbobjc/Apps/Wilde/FBReactModule2/FBReactModuleAPI/FBReactModuleAPI/FBReactModule.mm?lines=1462-1469) is shared between bridge mode and bridgeless mode. So, the shared constructor needs to know what infra to use to load the loaders/decoders: the TurboModuleManager, when called from a bridgeless context; the bridge, when called from a bridge context. There's no easy way to let this shared constructor know what context it's being called from. We could fork the constructor, but that's not very clean.
## Changes
In this refactor, RCTImageLoader gives its loadersProvider and decodersProvider its RCTModuleRegistry. If the module was instantiated in bridgeless mode, RCTModuleRegistry will use the TurboModuleManager. If the module was instantiated in bridge mode, RCTModuleRegistry will use the bridge. Using RCTModuleRegistry allows these two blocks to load the RCTImageURLLoaders and RCTImageDataDecoder from correct infra, in both contexts.
Changelog: [iOS][Changed] - Give RCTImageURLLoader's loader/decoder provider blocks RCTModuleRegistry
Reviewed By: PeteTheHeat
Differential Revision: D28012999
fbshipit-source-id: 09c787923b57bbf72aff95b504f88ee1f2f44283
Summary:
When shouldEnableLoggingForRequestUrl is false, ImageTelemetry is not initialized, and no logging is done.
* Replace `- (NSString *)loaderModuleNameForRequestUrl:(NSURL *)url` with `- (BOOL)shouldEnableLoggingForRequestUrl:(NSURL *)url`
* Rename RCTImageLoaderInstrumentableProtocol.h -> RCTImageLoaderLoggableProtocol.h
Reviewed By: fkgozali
Differential Revision: D24523984
fbshipit-source-id: a5463eceea1c40f9452b0ad2ee6bf047f71a02c1
Summary: Changelog: [Internal] Add IGviewpoint to get image visibility callbacks for when an UIImageView is in or out of view
Reviewed By: fkgozali
Differential Revision: D23428528
fbshipit-source-id: 87e4cee8fbe3c6b7da5153f87bbb530b2f990d96
Summary:
Added basic hook to enable image instrumentation. The hook passes information to the existing image loader, where instrumentation is done, specific for each app, if any.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19047899
fbshipit-source-id: 6c013806cce98bcf1ea240d696a7ede9697e5cd9
Summary:
Introduced 2 helper functions to toggle image instrumentation/logging (not in this diff) so that gating check is more efficient and easy to access across RN iOS core.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D18597208
fbshipit-source-id: 0b22031802ab020b16d6fb63e52461cf80a37ab5
Summary:
In D16805827, I moved `RCTImageLoader`, `RCTImageStoreManager`, and `RCTImageEditingManager` to `CoreModules`. This was necessary to turn `RCTImageLoader` into a TurboModule. However, after D17671288 landed, it's no longer necessary to have OSS NativeModules in `CoreModules`. Therefore, I'm moving these NativeModules back to `RCTImage`.
Changelog: [iOS][Fixed] Move RCTImage NativeModules back to RCTImage
Reviewed By: shergin
Differential Revision: D17921612
fbshipit-source-id: 8ae36d2dc8deaf704313cbe2479bfa011ebcbfbc
Summary: In D16805827, I moved `RCTImageLoader`, `RCTImageStoreManager`, and `RCTImageEditingManager` to `CoreModules`. This was necessary to turn `RCTImageLoader` into a TurboModule. However, after D17671288 landed, it's no longer necessary to have OSS NativeModules in `CoreModules`. Therefore, I'm moving these NativeModules back to `RCTImage`.
Reviewed By: PeteTheHeat
Differential Revision: D17720575
fbshipit-source-id: 44b07cfa07cbb2b87254132810f86974edc7edab
Summary:
This diff moves RCTImageLoader, RCTImageEditingManager, and RCTImageStoreManager to CoreModules. This is necessary for us to convert all these NativeModules to TurboModules.
**Note:** As a part of this diff, I had to break apart `RCTImageLoader.h`. All the protocols that were in `RCTImageLoader` are now in their own headers. Furthermore, `RCTImageLoader`'s methods are defined in `RCTImageLoaderProtocol`, so that we can call them from classes like `RCTImageViewManager` in `RCTImage`.
Reviewed By: PeteTheHeat
Differential Revision: D16805827
fbshipit-source-id: 89f6728b0766c30b74e25f7af1be8e6b8a7e6397
Summary: We no longer want to access RCTImageLoader from the bridge.
Reviewed By: shergin
Differential Revision: D16389383
fbshipit-source-id: 8e006bf0e2e2651f3ac036c09e589213ac9d29f9
Summary:
[After we migrated to new GIF implementation](https://github.com/facebook/react-native/pull/24822), we can remove old implementation now.
## Changelog
[iOS] [Deprecated] - Remove old GIF code
Pull Request resolved: https://github.com/facebook/react-native/pull/25636
Test Plan: GIF still works.
Reviewed By: shergin
Differential Revision: D16280044
Pulled By: osdnk
fbshipit-source-id: 00979280e6c17c93859ce886dd563b0d185c84aa
Summary: This diff wires up everything from the previous 8 diffs. After this, all codepaths that execute `modulesConformingToProtocol` in `RCTImageLoader.m` will instead use iOS plugins to retrieve the modules on FBiOS.
Reviewed By: fkgozali
Differential Revision: D14360252
fbshipit-source-id: 6f0cecfa8dffa1955ba2f9ed54bc1c130fb23341
Summary:
This is a re-submit of D13895627 which got landed but didn't include a fix to Instagram's code. The sheriffs were unsure how it got landed without running the build.
Currently, before we store the image to cache, we only respect `Cache-Control`, actually, we also may need to check `Expires`、`Last-Modified`, refer to [MDN docs](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching#Freshness), and [okhttp](568a91c44a/okhttp/src/main/java/okhttp3/internal/cache/CacheStrategy.java (L268)) respect the `MDN`, so in iOS, we can also respect this.
[iOS] [Fixed] - Respect `MDN` cache strategy before cache the image.
Reviewed By: shergin
Differential Revision: D13896822
Pulled By: cpojer
fbshipit-source-id: 8c1714f4a17ad40496146806cff3e188a60be93c
Summary:
Update reference to property in code comment in `RCTImageLoader`. There is no protocol named `RCTImageCacheDelegate` in the codebase. Its just `RCTImageCache` and it exists [here](f2894e58cf/Libraries/Image/RCTImageLoader.h (L22)).
Pull Request resolved: https://github.com/facebook/react-native/pull/22406
Differential Revision: D13373793
Pulled By: cpojer
fbshipit-source-id: b5edf18ebad626bf09648c079299e5acd14ba48a
Summary:
This PR increases the speed at which cached images are loaded and displayed on the screen. Images are currently cached in memory using RCTImageCache, but each time they are loaded, a round trip through RCTNetworking happens before RCTImageCache is even checked. This is likely so that RCTNetworking can handle the caching behavior required by the HTTP headers. However, this means that at the very least, images are read from disk each time they're loaded.
This PR makes RCTImageLoader check RCTImageCache _before_ sending a request to RCTNetworking. RCTImageCache stores a bit of information about the response headers so that it can respect Cache-Control fields without needing a roundtrip through RCTNetworking.
Here are a couple of graphs showing improved loading times before this change (blue) and after (red) with SDWebImage (yellow) as a baseline comparison. The increase is most evident when loading especially large (hi-res photo size) images, or loading multiple images at a time.
https://imgur.com/a/cnL47Z0
More performance gains can potentially be had by increasing the size limit of RCTImageCache: 1a6666a116/Libraries/Image/RCTImageCache.m (L39) but this comes at the tradeoff of being more likely to run into OOM crashes.
Pull Request resolved: https://github.com/facebook/react-native/pull/20356
Reviewed By: PeteTheHeat
Differential Revision: D12909121
Pulled By: alsun2001
fbshipit-source-id: 7f5e21928c53d7aa53f293b7f1b4ec5c99b5f0c2
Summary: This change drops the year from the copyright headers and the LICENSE file.
Reviewed By: yungsters
Differential Revision: D9727774
fbshipit-source-id: df4fc1e4390733fe774b1a160dd41b4a3d83302a
Summary:
The API was available only on Android (with no mention to that effect in the docs, AFAICT).
This commit adds a simple iOS implementation based on NSURLCache. It should be possible to
query the decoded image cache as well to provide higher fidelity (i.e. "disk", "memory",
"decoded") if the caller passes size, scale, etc. in addition to the image URL, but it's
probably not worth the complexity. The assumption is that callers are interested in the
durability rather than performance aspect of the returned information.
Tested with RNTester on iPhone emulator.
[IOS] [ENHANCEMENT] [Image] - Implemented queryCache
Pull Request resolved: https://github.com/facebook/react-native/pull/18782
Differential Revision: D9411533
Pulled By: hramos
fbshipit-source-id: b430263959bb5f9b8ed9e28bb0a95f8879df881a
Summary:
This PR increases the speed at which cached images are loaded and displayed on the screen. Images are currently cached in memory using RCTImageCache, but each time they are loaded, a round trip through RCTNetworking happens before RCTImageCache is even checked. This is likely so that RCTNetworking can handle the caching behavior required by the HTTP headers. However, this means that at the very least, images are read from disk each time they're loaded.
This PR makes RCTImageLoader check RCTImageCache _before_ sending a request to RCTNetworking. RCTImageCache stores a bit of information about the response headers so that it can respect Cache-Control fields without needing a roundtrip through RCTNetworking.
Here are a couple of graphs showing improved loading times before this change (blue) and after (red) with SDWebImage (yellow) as a baseline comparison. The increase is most evident when loading especially large (hi-res photo size) images, or loading multiple images at a time.
https://imgur.com/a/cnL47Z0
More performance gains can potentially be had by increasing the size limit of RCTImageCache: 1a6666a116/Libraries/Image/RCTImageCache.m (L39) but this comes at the tradeoff of being more likely to run into OOM crashes.
Pull Request resolved: https://github.com/facebook/react-native/pull/20356
Reviewed By: shergin
Differential Revision: D8978844
Pulled By: hramos
fbshipit-source-id: 4b86043bc14c40007b0596c9f8a213455b697686
Summary:
Includes React Native and its dependencies Fresco, Metro, and Yoga. Excludes samples/examples/docs.
find: ^(?:( *)|( *(?:[\*~#]|::))( )? *)?Copyright (?:\(c\) )?(\d{4})\b.+Facebook[\s\S]+?BSD[\s\S]+?(?:this source tree|the same directory)\.$
replace: $1$2$3Copyright (c) $4-present, Facebook, Inc.\n$2\n$1$2$3This source code is licensed under the MIT license found in the\n$1$2$3LICENSE file in the root directory of this source tree.
Reviewed By: TheSavior, yungsters
Differential Revision: D7007050
fbshipit-source-id: 37dd6bf0ffec0923bfc99c260bb330683f35553e
Summary:
To make React Native play nicely with our internal build infrastructure we need to properly namespace all of our header includes.
Where previously you could do `#import "RCTBridge.h"`, you must now write this as `#import <React/RCTBridge.h>`. If your xcode project still has a custom header include path, both variants will likely continue to work, but for new projects, we're defaulting the header include path to `$(BUILT_PRODUCTS_DIR)/usr/local/include`, where the React and CSSLayout targets will copy a subset of headers too. To make Xcode copy headers phase work properly, you may need to add React as an explicit dependency to your app's scheme and disable "parallelize build".
Reviewed By: mmmulani
Differential Revision: D4213120
fbshipit-source-id: 84a32a4b250c27699e6795f43584f13d594a9a82
Summary:
Before this PR, ```RCTImageLodaer```'s Cache was too big(200MB on disk) and It doesn't work with HTTP Cache-Control header. So to provide dynamic image, the users must have to add random value on url( ex. adding current date) to avoid cache.
So I change that cache system to default ```NSURLRequest```'s cache system, which is well-working with HTTP specs. As the discussion on this issue #7571 , making custom cache policy processor is not ready yet and useless, over-tech things, I think.
Even we have no plan about image cache system(or would change plan later), before having a nice plan, I think we should let user use image module with common HTTP Specs.
So I remove custom ```NSURLCache```, and make logic like below,
1. try fetch image,
2. on response, get ```Date``` on response's header and make ```cacheKey``` with ```Date```.
> (why? because if ```NSURLRequest```'s response was cached, the response's ```Date``` header dosen't change.)
3. find decoded imag
Closes https://github.com/facebook/react-native/pull/8235
Reviewed By: bnham
Differential Revision: D3469086
Pulled By: javache
fbshipit-source-id: 35a5552cda6e6c367481020bbf3c28eb4a9d0207
Summary:
This uses `[UIImage imageNamed:]` to load local assets that are bundled using `require('../image/path.png')` and makes sure it is done synchronously on the main queue to prevent images from flickering. This improves user experience a lot when using large local images and prevents icon flickers to match the behaviour of most native apps.
This adds to methods to the ImageLoader protocol, one to tell if the image loader must be executed on the url cache queue and one to tell if the result of the image loader should be cached. I then use these to make the LocalImageLoader bypass the url cache queue and avoid caching images twice.
Note that this doesn't affect debug builds since images are loaded from the packager.
I'm not sure if we want to still support async loading of local images as I'm not sure how much of a perf difference this will make. Maybe someone at fb can benchmark this see how it affects your apps but there wasn't a noticeable one in mine. Also I only enabled this for loading png and jpg im
Closes https://github.com/facebook/react-native/pull/8102
Reviewed By: bnham
Differential Revision: D3433647
Pulled By: javache
fbshipit-source-id: 37bd6aff20c0465c163db3cdbcaeaedff55f7b1f
Summary:
Now that we no longer have a separate NetworkImageView implementation, we can remove that code path from Image.js
I've also moved the prefetch method into RCTImageViewManager for consistency with the getImageSize method, which means we no longer need to export the RCTImageLoader module to js.
Reviewed By: javache
Differential Revision: D3398157
fbshipit-source-id: fbbcf90a61549831ad28bad0cb3b50c375aae32c
Summary:
Allows developers to specify headers to include in the HTTP request
when fetching a remote image. For example, one might leverage this
when fetching an image from an endpoint that requires authentication:
```
<Image
style={styles.logo}
source={{
uri: 'http://facebook.github.io/react/img/logo_og.png',
headers: {
Authorization: 'someAuthToken'
}
}}
/>
```
Note that the header values must be strings.
Works on iOS and Android.
**Test plan (required)**
- Ran a small example like the one above on iOS and Android and ensured the headers were sent to the server.
- Ran a small example to ensure that \<Image\> components without headers still work.
- Currently using this code in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/7338
Reviewed By: javache
Differential Revision: D3371458
Pulled By: nicklockwood
fbshipit-source-id: cdb24fe2572c3ae3ba82c86ad383af6d85157e20
Summary:Initializing native modules can block the main thread for tens of milliseconds when it starts up, making it difficult to instantiate the bridge on demand without causing a performance blip.
This diff splits up the initialization of modules so that - although they still happen on the main thread - they don't block the thread continuously.
Reviewed By: javache
Differential Revision: D2965438
fb-gh-sync-id: 38c9c9d281e4672b5874d68b57d4c60d1d268344
shipit-source-id: 38c9c9d281e4672b5874d68b57d4c60d1d268344
Summary:
public
Standardises the image decoding logic for all image sources, meaning we get the benefits of efficient downscaling of images from all sources, not just ALAssets.
Reviewed By: javache
Differential Revision: D2647083
fb-gh-sync-id: e41456f838e4c6ab709b1c1523f651a86ff6e623
Summary:
public
This diff adds a `getSize()` method to `Image` to retrieve the width and height of an image prior to displaying it. This is useful when working with images from uncontrolled sources, and has been a much-requested feature.
In order to retrieve the image dimensions, the image may first need to be loaded or downloaded, after which it will be cached. This means that in principle you could use this method to preload images, however it is not optimized for that purpose, and may in future be implemented in a way that does not fully load/download the image data.
A fully supported way to preload images will be provided in a future diff.
The API (separate success and failure callbacks) is far from ideal, but until we agree on a unified standard, this was the most conventional way I could think of to implement it. If it returned a promise or something similar, it would be unique among all such APIS in the framework.
Please note that this has been a long time coming, in part due to much bikeshedding about what the API should look like, so while it's not unlikely that the API may change in future, I think having *some* way to do this is better than waiting until we can define the "perfect" way.
Reviewed By: vjeux
Differential Revision: D2797365
fb-gh-sync-id: 11eb1b8547773b1f8be0bc55ddf6dfedebf7fc0a
Summary: public
The image loader was previously returning on the main thread, which could lead to poor performance due to various call sites doing further image processing (resizing, cropping, etc.) directly in the completion block.
This diff modifies the loader to return on a background thread (the same one used to load the image), and updates the call sites to dispatch to the explicit thread they need.
Reviewed By: javache
Differential Revision: D2549774
fb-gh-sync-id: fed73b7c163fdf67ff65bae72ab1986327e75815
Summary: public
Added RCTDataRequestHandler, which is responsible for loading data URLs. This moves the logic for data URL handling out of RCTImageDownloader (no longer needed) and into the RCTNetwork library, where it makes more sense.
This also means that it is now possible to load data URLs via XHR, and use them for purposes other than just images.
Reviewed By: javache
Differential Revision: D2540964
fb-gh-sync-id: 4f0418bd6b9186f047cc8297276bb970795af104
Summary:
GIF images are currently loaded as a CAKeyframeAnimation, however returning this animation directly from RCTImageLoader was dangerous, as any code that expected a UIImage would crash.
This diff changes RCTGIFImageLoader to return a UIImage of the first frame, with the keyframe animation attached as an associated object. This way, code that is not expecting an animation will still work correctly.
Summary:
RCTNetworkImageView and RCTStaticImage had significant overlap in functionality, but each had a different subset of features and bugs.
This diff merges most of the functionality of RCTNetworkImageView into RCTStaticImage, eliminating some bugs in the former, such as constant redrawing when properties were changed.
I've also removed the onLoadAbort event for now (as it wasn't implemented), and renamed the other events to match the web specs for `<img>` and XHMLHttpRequest. The API is essentially what Adobe proposed here: http://blogs.adobe.com/webplatform/2012/01/13/html5-image-progress-events/
The following features have not yet been ported from RCTNetworkImageView:
- Background color compositing. It's not clear that this adds much value and it increases memory consumption, etc.
- Image request cancelling when images are removed from view. Again, it's not clear if this is a huge benefit, but if it is it should be combined with other optimisations, such as unloading offscreen images.
(Note that this only affects the open source fork. For now, internal apps will still use FBNetworkImageView for remote images.)
Summary:
Merged RCTStaticImage with our internal RKStaticImage and ported over logic where assets are loaded at the optimal size and reloaded if the view size changes.
Andres Suarez
Ramanpreet Nara
Paige Sun
Kevin Gozali
Ashok Menon
Peter Argany
zhongwuzw
Richard Zito
Karan Thakkar
Eric Samelson
Héctor Ramos
EUROPE\laprosek
Mehdi Mulani
Sophie Alpert
Yujie Liu
Pieter De Baets
Maria Mateescu
skatpgusskat
Janic Duplessis
Nick Lockwood
Adam Comella
Alex Akers
Philipp von Weitershausen
