Edmond ChuiandFacebook GitHub Bot
20462ca984
Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/44811 Changelog: [General][Fixed] - Debugger frontend socket-termination countdown now begins after the ping message is actually sent The debugger is currently disconnected if a ping-pong message is missed. This causes the debugger to be unusable if it happens to be lagging, e.g. when the initialisation is competing with the flood of log spam T191394188 There are a few ways to fix this as discused with motiz88 and robhogan: 1. Ensure the websocket has a chance to respond, e.g. in via web worker 1. Lengthen the time allowed for the pong resopnse I've done some digging to find the root cause of the UI being blocked in CDT, However, profiling shows that most of the work is not simple to break up, i.e. the number of expensive re-layout calls. Diving into that rabbit hole could mean accidentally writing React. Because we ping every 10 seconds, we could get un/lucky where CDT happens to be busy _at that exact moment_, making this a flaky symptom to fix, even if we lengthen the allowed time-to-respond. # V2+ So upon further investigation, CDT websocket is actually responding to the pings in due time: {F1679132204} (CDT doesn't show the ping/pong API as frames, so a custom tick/tock message was used to visualise the timing) Over here in dev-middleware, we currently start a timeout to terminate the socket after sending the ping: https://www.internalfb.com/code/fbsource/[813870db697a8701f2512d25a7fed730f0ec6ed9]/xplat/js/react-native-github/packages/dev-middleware/src/inspector-proxy/InspectorProxy.js?lines=306-307 If CDT doesn't respond in time, websocket would be terminated. But we saw CDT respond immediately above, even during the log spam, so the delay must be coming from somewhere else. The intuition is that during the log-spam, the middleware takes a perf hit too when it's processing the spam from the device and forwarding it to the CDT websocket. We can confirm this by passing a "sent" callback via `socket.ping(cb)`: https://github.com/websockets/ws/blob/9bdb58070d64c33a9beeac7c732aac0f4e7e18b7/lib/websocket.js#L246-L254 This gives us the timing between calling `socket.ping()` and when the ping is actually sent. Regular, stress-free operation without log-spam shows most pings are sent within the same millisecond: {F1679223326} With the pong response grace period at 5 seconds, there's plenty of time for CDT to `pong` back. That's why it has been working in most cases. However, during the log-spam, we easily see this send-sent delay over 5 seconds. In extreme cases, almost 30 seconds would have passed before middleware sent a message to CDT, which then responded under 2 seconds: {F1679163335} This means while CDT is getting flooded and has observable lag in the UI, the smoking gun is actually the middleware. Digging a little deeper, we know that incoming messages from the target goes into a Promise queue, including the console logs: https://www.internalfb.com/code/fbsource/[d5d312082e9c]/xplat/js/react-native-github/packages/dev-middleware/src/inspector-proxy/Device.js?lines=155-157 This means during the flood of logs from the target, the Promise queue keeps getting chained rapidly for each message. Meanhile, the `ws` lib uses the underlying NodeJS `Socket.write` method for `ping(…)` and `send(…)`: https://github.com/websockets/ws/blob/9bdb58070d64c33a9beeac7c732aac0f4e7e18b7/lib/sender.js#L349 …which is guaranteed to fire the callback asynchronously: https://github.com/nodejs/help/issues/1504#issuecomment-422879594 Promise queue is in the macro task queue, which gets priority before the micro task queue. So if the Promise queue is not cleared yet, the websocket queue will have a hard time getting executed in time – explaining the extreme send-sent durations during a log spam. The fix is simple: 1. Start the terminate-socket-timer until the `ping` is actually sent 1. Treat any incoming message (along with `pong`s) as a terminate-socket-timer reset 1. This also applies if `pong` comes in between `send` and `sent`, which can happen sometimes due to the async nature of the callback: {F1679288626} # V1 ~~In this diff, a more forgiving mechanism is introduced, i.e. CDT is allowed to miss a ping-pong roundtrip 3 times before the websocket connection is terminated.~~ ~~This allows a bit more breathing room for CDT's initialisation during log spam while maintaining the same ping-pong interval for VS Code to keep the auto SSH tunnel alive.~~ Reviewed By: huntie Differential Revision: D58220230 fbshipit-source-id: 7111c9878492d8755a6110a5cdf4ef622265001d
React Native
Learn once, write anywhere:
Build mobile apps with React.
Getting Started · Learn the Basics · Showcase · Contribute · Community · Support
React Native brings React's declarative UI framework to iOS and Android. With React Native, you use native UI controls and have full access to the native platform.
- Declarative. React makes it painless to create interactive UIs. Declarative views make your code more predictable and easier to debug.
- Component-Based. Build encapsulated components that manage their state, then compose them to make complex UIs.
- Developer Velocity. See local changes in seconds. Changes to JavaScript code can be live reloaded without rebuilding the native app.
- Portability. Reuse code across iOS, Android, and other platforms.
React Native is developed and supported by many companies and individual core contributors. Find out more in our ecosystem overview.
Contents
- Requirements
- Building your first React Native app
- Documentation
- Upgrading
- How to Contribute
- Code of Conduct
- License
📋 Requirements
React Native apps may target iOS 13.4 and Android 6.0 (API 23) or newer. You may use Windows, macOS, or Linux as your development operating system, though building and running iOS apps is limited to macOS. Tools like Expo can be used to work around this.
🎉 Building your first React Native app
Follow the Getting Started guide. The recommended way to install React Native depends on your project. Here you can find short guides for the most common scenarios:
📖 Documentation
The full documentation for React Native can be found on our website.
The React Native documentation discusses components, APIs, and topics that are specific to React Native. For further documentation on the React API that is shared between React Native and React DOM, refer to the React documentation.
The source for the React Native documentation and website is hosted on a separate repo, @facebook/react-native-website.
🚀 Upgrading
Upgrading to new versions of React Native may give you access to more APIs, views, developer tools, and other goodies. See the Upgrading Guide for instructions.
React Native releases are discussed in this discussion repo.
👏 How to Contribute
The main purpose of this repository is to continue evolving React Native core. We want to make contributing to this project as easy and transparent as possible, and we are grateful to the community for contributing bug fixes and improvements. Read below to learn how you can take part in improving React Native.
Code of Conduct
Facebook has adopted a Code of Conduct that we expect project participants to adhere to. Please read the full text so that you can understand what actions will and will not be tolerated.
Contributing Guide
Read our Contributing Guide to learn about our development process, how to propose bugfixes and improvements, and how to build and test your changes to React Native.
Open Source Roadmap
You can learn more about our vision for React Native in the Roadmap.
Good First Issues
We have a list of good first issues that contain bugs which have a relatively limited scope. This is a great place to get started, gain experience, and get familiar with our contribution process.
Discussions
Larger discussions and proposals are discussed in @react-native-community/discussions-and-proposals.
📄 License
React Native is MIT licensed, as found in the LICENSE file.
React Native documentation is Creative Commons licensed, as found in the LICENSE-docs file.