React Native APK size for a hello world example is around 20M (in recent versions) because of support different hardware architectures (ARMv7, ARMv8, X86, etc) while Flutter APK size for same application is around 7M.
What's the reason for the difference in size? Do Flutter support all hardware architecture?
So Junius answer is correct but I don't believe covers the reason why. So Flutter compiles to 100% native code, where RN uses a combination of native code and JavaScript communicating across a bridge.
That is why Flutter does not need to add the JavaScript core thus, the size is smaller. But anyway, as your app grows, the JS part will always be around the same size.
Visit to below mentioned url's and may be they could help you out regarding what you are looking for.
https://nevercode.io/blog/flutter-vs-react-native-a-developers-perspective/
https://android.jlelse.eu/comparing-apk-sizes-a0eb37bb36f
if not it will still give more insights to others on how Flutter is different than others, and whether one should choose flutter over any other hybrid app development technology or not.
RN use open source JavaScriptCore, which is the default engine for Safari. RN iOS and Android apps don't have the same size. For iOS RN uses the JavaScriptCore provided by the iOS platform, and for Android RN bundles JavaScriptCore with the app, which increases the size of the app. The reason why Flutter and RN Hello World differ in size is because of JavaScriptCore.
The day before yesterday I published an Flutter application in which there are also images. However, the application has libraries that are not small like Firebase and I managed to make it become 2.3 Mb. Instead, I have another Flutter app that I published and weighs 8.5 Mb, do you want to know the only difference? The Api Min starts from 21, while the one that weighs 8.5 from 16. This is a big advantage because 2.3 are very few. Only in debug mode the size is very large, so don't worry, because when you compress the flutter application in appBundle for example to the Play Store, the size of him smallest very more.
Related
I want to detect low performance device in runtime in react native to disable complex lottie animation. I consider for use device model from react-native-device-info, but I should have a list of heigh performance phones
I'm also interested in this question and it would be fine to have some solution. I can think of using react-native-device-info and comparing following properties of device:
CPU architecture (32/64 bit)
total RAM available
total disk capacity
current android version
Maybe using these variables we are able to calculate some performance level with not that bad accuracy.
64bit + lets say at least 3GB RAM + 32GB capacity + one of newer Android version can be good indication that device should have some power inside.
on the other hands 32bit + 1/2GB RAM + max 8/16GB capacity + not that new Android version can lead to performance prblms.
Seriously let's talk about it :D Maybe we can find some good compromise and maybe write a lib or contribute to react-native-device-info with a feature that will try to suggest developers about device's performance.
consider use android version
we use this formula:
low android version === old phone === low performance
performance can be low if device is out of memory, too many applications opened, which browser used, etc... its hard to detect
when is neccesary, you can write small performance test in app before animations or on app load/initialization, and you can use these results.
It's possible to run any benchmark in background using web worker or use library like fireball-js, then compare the score.
Can Somebody suggest me whether it is effective to Test all as many mobile device as possible to ensure a website compatibility.
As per my view, it is good for some extent to test various version of a Browser to check the Page view and compatibility rather testing many mobile or tablet devices.
Please share your thoughts.
Your correct to some extend.When testing a mobile web site we need to be concerned about following
Browser compatibility
Page rendering in different screen resolutions/sizes
From above, we should pay more attention to Browser compatibility. And your correct on putting more weight on same.
By testing on many devices we can cover the screen resolution/form factor support.However, you should be able to create a good set of target test devices(Around 10)to cover the most used devices in the market.
For most used Android device types based on screen size, you can refer Android Dashboard for latest data
https://developer.android.com/about/dashboards/index.html
My suggestion based on current data, is to focus on following combination
Small Size - ldpi Density
Normal, Large, X Large - mdpi density
Normal Size - hdpi density
Normal Size - xhdpi & xxhdpi density
So for Android you can manage with around 7 devices for the initial round of testing based on current status
For iOS you could check the latest iPad & iPhone cause the platform has very few different screen sizes & adoption of the latest OS and device is better in iOS
Reference
http://www.fiksu.com/ipad-iphone-and-ios-7-adoption-trackers#ipad-usage
http://www.fiksu.com/ipad-iphone-and-ios-7-adoption-trackers#iphones-usage
Based on my experience with less than 10 devices you can have significant coverage on form factor support for mobile web testing.
Hope this is helpful..
Our app is currently extremely slow when first booting up.
What are the key elements that contribute to app loading time and how can we accelerate that process?
We load very simple note objects into memory upon launch and intend to use plugins for native databases soon.
We plan on minifying as well as using native plugins for storage, what other strategies can we employ?
This guest post by hojoki has been pretty helpful as well.
Duplicate resources
In trigger.io all resources (Android + iOS) are packaged together. E.g. the splash screen Android is included both in the iOS and Android build -- and vice versa. Perhaps that's one reason for the size?
And if so, building two separate apps, one per platform, may be one way to work around that issue. Obviously the ability to exclude non-platform resources would be even better, but that doesn't work right now.
File size
Run minification on all js/css, reduce png/jpeg file-sizes.
I recently moved from a PC to a MacBook Pro. I'm starting to go through tutorials on Objective-C and developing in Cocoa. I do a lot of image processing algorithm development work (pixel by pixel manipulation) in my day job so I'd like to get create a test image processing app or two for OS X. I'm struggling to figure out where to start - let's say I want to create a simple application (that I could reuse) like the following:
load an image from an open file option within a file menu
display this within the GUI.
Click a button to apply pixel by pixel processing
Update the displayed image
Save the processed image from the save option within the file menu
Any pointers or links would be most appreciated.
Thanks
Other info:
I'm pretty familiar with OpenCV within Linux - haven't looked at using it within Objective-C/Cocoa/Xcode environment yet though - not even sure if this would be a good idea?
I guess it would be nice to use GPU acceleration as well, but I'm not familiar with OpenGL/OpenCL - so I might have to put that one on the long finger for the moment.
As you are looking at the Apple platform, you should look into the CoreImage framework - it will provide you most of pre-baked cookies ready to be consumed in your application.
For more advanced purposes, you can start off with openCV.
Best of luck!!
As samfisher suggests, OpenCV is not that hard to get working on the Mac, and Core Image is a great Cocoa framework for doing GPU-accelerated image processing. I'm working on porting my GPUImage framework from iOS to the Mac, and it's entirely geared around making accelerated image processing easy to work with, but unfortunately that isn't working right now.
If you're just getting started on the Mac, one tool that I can point out which you might overlook is Quartz Composer. You have to download the separate Graphics Tools package from Apple's developer site to install Quartz Composer, because it's no longer shipped with Xcode.
Quartz Composer is a graphical development tool that lets you drag and drop modules, connect inputs and outputs, and do rapid development of some fairly interesting things. One task it's great for is doing rapid prototyping of image processing, either using Core Image or OpenGL shaders. I've even heard of people using OpenCV with this using custom patches. You can easily connect an image or camera source into a filter chain, then edit the filters and see live updates as you work on them, without requiring a compile-run cycle.
If you want some sample QC projects to play with, I have a couple of them linked from this article I wrote a couple of years ago. They both do the same color-based object tracking, with one using Core Image and the other OpenGL shaders. You can dig into that and play around to see how that works, without having to get too far into writing any code.
I'm looking to implement Game Center features into my iOS app; however, I'm not sure how much it will increase my application's binary filesize. There seem to be a lot of features in GameKit which I won't be using because I only want to use achievements and leaderboards. Is there a way to leave out the unused features at compile time?
Thanks in advance!
The actual code for frameworks is not copied into your program. The linker builds symbolic links into your executable code that enables it to find the frameworks on the deployment platform (iPhone, iPad, etc) at runtime.
The only increase in your program size will come from code you actually write to use the GameKit (for example your leaderboard or P2P code).
Linking to iOS frameworks does not increase the size of your binary by any substantial amount. Those frameworks are all already on the device, as part of the operating system, so applications which link to them don't include the library in the app itself, they just load it from the shared location on the device.