I'm trying this, I set up alwaysRun to true in cordova-uglify and ionic-minify folders, but the only way to see the files minimized and uglified is running ionic build android --release (but i don't want to generate the app for PRD yet)
If I do
ionic build android --minimize
The result is the full file, not minimized.
Any idea how to get the files minimized? I'm trying to fix a performance issue with this as the app takes 12 seconds to open and in all sites suggest this as a performance improvement.
Related
I am trying to create a sudoku app with C++, SDL2 and Android Studio NDK.
In theory it is already working well unless I build and install the app manually.
While I get around 50-60 FPS when I run the app with the RUN-Button in Android Studio, there is a major performance drop when I install the app via BUILD -> GENERATE SIGNED BUNDLE / APK... -> APK and put it on the SD-Card on an actual android device (I've testet this on Xiaomi Mi A1, Samsung Tab S3 and some older devices). I get around 9-11 FPS when installing the app manually.
To create the project, I used the template project in the SDL2 package (version 2.0.18).
I use the same (release-)Build Variant for both cases.
The app is build via NDK-Build.
My conclusion is, that while my code for rendering is maybe not the most efficient, it is not the problem which causes this massive performance issue here.
Screenshot: build with RUN Screenshot: build with BUILD -> GENERATE SIGNED BUNDLE / APK... -> APK
I already tried change several build settings, including switching between debug and release mode, adding optimization (C and C++ -)flags in the Application.mk file, build with uncompressed assets. The performance stays the same in both cases.
My Question is: What could be the difference between building the APK and clicking on RUN, which causes this performance issue?
I hope someone can help me out here, because I am very clueless at the moment. Thank you in advance.
The difference between RUN and BUILD is in my Run-configuration.
Under Installation Options -> Deploy I chose "APK from app bundle". After researching and trying for hours I changed it to "Default APK", which caused the same performance problems as building and manual install as described in my question above.
While I still don't really know why this is the case, I found a way to get an APK-file which, at least for now, works for me:
Instead of building with BUILD -> GENERATE SIGNED BUNDLE / APK... -> APK I now choose BUILD -> GENERATE SIGNED BUNDLE / APK... -> ANDROID APP BUNDLE and convert the app bundle to an APK via bundletool (https://developer.android.com/studio/command-line/bundletool). The converted APK runs fine on my android device.
I upgraded my .NET Core 2.1 project to Angular 6 and everything seems to be working correctly except for hot-updates. Before updating it was possible to update the TypeScript and VS would re-compile and reload the browser, now that seems to be broken along with having to manually run ng build to recompile the scripts, VS doesn't seem to recompile automatically anymore.
Is there a setting, possibly in angular.json that I need to set to enable the development server?
Update
For some reason, Hot Updates started working temporarily and not sure what I did to get it to start/stop working. When I start a debug session and update any of the .ts files, I can see the compiler output succeeding but when I refresh my browser I don't see any of the changes unless I manually build the project using the ng build.
I am starting to think that there is some miscommunication going on somewhere or possibly an error somewhere that isn't being picked up by the compiler causing something not to update?
Another thing I noticed while watching my output window is my site starts running on localhost:44359 but in the output, it says Angular Live Development Server is listening on localhost:55287 should these ports match?
one last observation I have made is after a change has been made during a debug session the output window lists all the chunks just like when running it manually with the exception it outputs i ｢wdm｣: Compiled successfully could something be corrupt or is this simply an output bug?
After a ton of messing around, I finally got this working and thought I would share what is going on.
When you run ng build it compiles and outputs to the ClientApp/dist folder. When you start the Debug Session your project uses this version. If you change a file at runtime it will re-compile the files but it will not overwrite the compiled files in the dist directory. I think because the files were manually generated outside of the UI, VS thinks it can not overwrite them.
So if you start running into this same problem luckily there is an easy fix, simply delete the ClientApp/dist folder before you start the Debug Session. Visual Studio will compile the files in the background and when you update a source file or style sheet your browser should refresh automatically.
Update
Another thing I found is if you need to manually run ng build there is another way to keep the files up-to-date at least (requiring reload):
package.json
"scripts": {
"ng": "ng",
"start": "ng serve",
"build": "ng build",
"test": "ng test",
"lint": "ng lint",
"e2e": "ng e2e",
"debug": "ng serve --watch",
},
Then run ng build --watch instead of ng build this will put the prompt into a watch mode (press ctrl c to end), then every time you change one of the source files it will update. I added the "debug" because I wasn't sure if it would mess with the production, always safe to keep things existing or default if you can as a backup.
Then in Startup.cs (Configure(…)) update the server to use the new "debug":
spa.UseAngularCliServer(npmScript: "debug");
Update - 2
Another thing that I have found when using Angular and VS (2017) is if you happen to have an error somewhere in your code that isn't picked up by the cli compiler, especially in any of the constructors or ngOnInit() functions, it will hang up the Angular Service even after shutdown, making it seem like the hot-updates are no longer working. This will lead to complete Madness because none of the changes or updates will be loaded until the service is shutdown.
Another possible cause are errors when compiling .scss or Angular. Check the "Output" window for any Angular-cli Errors or in the Browsers Output.
After shutting down VS, make sure that VSCompiler.exe, any extra Console Windows Host (Angular Server, not the one running under the SQL User i.e. MSSQLFDLauncher... ) and any Visual Studio services are shutdown in your Task Manager.
I realized that it was actually an ERROR in MY CODE that was causing everything to stop working or not work at all. Angular and .NET will NOT always throw an error, sometimes the errors are simply skipped (especially when there are syntax errors) or output in the midst of all the other outputs.
More than likely if things stop working, it is either because of an error or some other reason that caused the compiler to stop responding. One last area to double check are your package.json and angular.json, especially any paths, then run the following and keep an eye on the output for updates that need to be made:
ng update
npm update
npm rebuild
npm install
The default .json files should work right out of the package, try to revert back to those to check your configuration. Deleting the dist folder basically is a shortcut for the above (minus the actual output, let VS compile before Debug), forcing angular to recompile everything but keep in mind that if the service is hung up, it won't matter what you do until that service is stopped.
Short answer.
Delete 'Dist' folder in ClientApp folder. in VisualStudio
and Reboot and Run
I have passed trought the same problem.
You have two options:
Delete the "dist" folder(this folder will be recreated everytime you use 'ng-build')
Make the implementation equals the link below. This implementation makes the application ignore the dist folder. It will only be used at production environment.
Implementation
I think the second solution is better, because you don't have to delete the "dist" folder everytime you want to debug your application.
recently I finished my app with ionic2 and about to build, when I use ionic build --release --prod ,it can work well in ios but not in android.when I build android a package or just use ionic run android with product mode,I can run my app and get the main page.But wherever I click next,the screen will go white like get a white mask and every thing hardly seen,but in console no thing goes wrong.here is some screenshot:
first in
do some click and go white
could someone help me or did some one get same situation?
finally i solved it by remove my setting in variables.scss, by reducing $colors setting to less than 20 makes my app work well in prod mode, more detail in ionic issues
I have been exploring the PowerBI visualizations github project and starting to make my own visualization but I'm having the following issues that is really slowing me down on the development:
It takes almost 3m to run the "build", is there any other option for rapid development because when we are starting with the project 3m see the results of the code changed is too much...
Is there any way to debug the visualizations inside the framework? I had setted the property "DEBUG" to false in the gulpfile.js but without success...
Thanks!
If you are a windows user then just use Visual Studio 2015 solution PowerBIVisuals.sln from src/ folder
It has continuous build support, so that when you open the solution it will run continuous_build_debug task.
If you are a Unix/Linux/Mac user then you'll need to manually run continuous_build_debug. (Run "gulp continuous_build_debug")
This task will run Watchers which will build project parts after you save changes to any file.
I migrated my grunt project to ember-cli, I found the time from file modification to liveload completion was so long, about 10 minutes.
After I installed ember-cli-windows, ember-cli-windows-addon, no obvious prompt was gained. The following is one example output after ember-cli-windows, ember-cli-windows-addon installed:
file changed routes\services.js
Build successful - 382781ms.
Slowest Trees | Total
----------------------------------------------+---------------------
Babel | 82175ms
Concat: Vendor | 75980ms
Funnel: App JS Files | 57393ms
JSHint app- QUnit | 49491ms
ES6: App Tree | 41827ms
Slowest Trees (cumulative) | Total (avg)
----------------------------------------------+---------------------
Babel (2) | 82394ms (41197 ms)
Concat: Vendor (1) | 75980ms
Funnel: App JS Files (1) | 57393ms
JSHint app- QUnit (1) | 49491ms
ES6: App Tree (1) | 41827ms
By contrast, the build process can be finished in 2~3 seconds in grunt project after file modification.
I use windows 7.
You ask
Why the ember-cli is so slow
It is not ember-cli per se that is slow, it is Broccoli. Reasons include:
Broccoli copies files instead of symlinking under Windows. To avoid this, run your builds in a command prompt with administrator privileges.
Broccoli is disk-intensive. To solve this, get an SSD.
Broccoli is processor intensive. To solve this, get a faster machine (preferably non-Windows).
Broccoli creates huge numbers of temporary files in tmp, which can slow down performance. To solve this, clean out tmp from time to time.
Broccoli is known to be inherently slow. You can find relevant questions on the broccoli site. To solve this, wait for the broccoli people to address performance issues, which is on their roadmap. Substantial improvements have already been made, so upgrade to the latest version of everything.
Broccoli rebuilds everything over and over again, including things which did not change. To solve this, manually tweak your build process to exclude certain things and do them manually as-needed. For instance, let's say you are bringing in a 200KB external JS package via bower, and app.import'ing it in your Brocfile.js. As a temporary work-around, and to see if it makes a difference, remove that file from the Broccoli world and load it directly in index.html. The same applies to large CSS files.
Broccoli will run babel in a default installation. Babel is not that slow, but it does take time. To solve this, if you are not using ES6 syntax, remove the babel dependency.
Your virus scanner may be trying to scan the thousands of files Broccoli creates. ember-cli-windows deals with this problem only for Defender. If you are using a different anti-virus package, to solve this add your dev directory to its list of places to skip.
For your reference, I have a small Ember project I build in an Ubuntu Virtual Box VM with Windows host on a fast machine with SSD, and builds take 2-3 seconds.
You may also want to consider asking this on an ember-cli list. You could also choose a different framework that does not bake in an immature and inefficient build system.
For windows users, one will need to correctly enable symlinks. As our friends at Microsoft are actually active users of both ember and ember-cli. They have provided an addon that does exactly that.
See: http://ember-cli.com/user-guide/#windows for further details.
For all users see: https://github.com/ember-cli/ember-cli/blob/master/docs/perf-guide.md
[Update]
In the last 6 months several large performance improvements have landed, some are seeing one or two orders of magnitude improvements (obviously this depends on some factors...)
As time permits, more performance improvements are planned, one particular important one is decoupling the need to rely on symlinks or copying. Which should make our windows counterparts (and those with slower drives) quite happy.
For anyone currently feeling like they are seeing less then optimal performance, let me recommend this guide: https://github.com/ember-cli/ember-cli/blob/master/docs/perf-guide.md
Many of the recent improvements have been done in a backwards compatible way, but do require dependencies being upgraded, be sure to upgrade relevant depends, and use that guide to track down any remaining issues and report them.
Windows Subsystem Linux also appears to now work very well!
The best solution for fixing performance issues in windows is running a Ubuntu (or whatever linux you want) in a virtual machine, and running ember serve inside it, using NFS to share folders with host.
I had the exact same problem and I'm getting now sub-second building times. Tried all the solutions found here and in the internet, but without luck. I got 10x performance when I migrated to a Ubuntu VM.