2015-02-20 04:10:52 +00:00
|
|
|
/**
|
2015-03-23 20:35:08 +00:00
|
|
|
* Copyright (c) 2015-present, Facebook, Inc.
|
|
|
|
*
|
2018-02-17 02:24:55 +00:00
|
|
|
* This source code is licensed under the MIT license found in the
|
|
|
|
* LICENSE file in the root directory of this source tree.
|
2015-02-20 04:10:52 +00:00
|
|
|
*
|
2016-09-23 18:12:51 +00:00
|
|
|
* @flow
|
2017-09-28 20:11:08 +00:00
|
|
|
* @format
|
2015-02-20 04:10:52 +00:00
|
|
|
*/
|
|
|
|
|
[ReactNative] Refactor BatchedBridge and MessageQueue
Summary:
@public
The current implementation of `MessageQueue` is huge, over-complicated and spread
across `MethodQueue`, `MethodQueueMixin`, `BatchedBridge` and `BatchedBridgeFactory`
Refactored in a simpler way, were it's just a `MessageQueue` class and `BatchedBridge`
is only an instance of it.
Test Plan:
I had to make some updates to the tests, but no real update to the native side.
There's also tests covering the `remoteAsync` methods, and more integration tests for UIExplorer.
Verified whats being used by Android, and it should be safe, also tests Android tests have been pretty reliable.
Manually testing: Create a big hierarchy, like `<ListView>` example. Use the `TimerMixin` example to generate multiple calls.
Test the failure callback on the `Geolocation` example.
All the calls go through this entry point, so it's hard to miss if it's broken.
2015-06-17 14:51:48 +00:00
|
|
|
'use strict';
|
2015-04-29 18:54:26 +00:00
|
|
|
|
2016-06-15 14:50:20 +00:00
|
|
|
const ErrorUtils = require('ErrorUtils');
|
2016-09-23 18:12:51 +00:00
|
|
|
const Systrace = require('Systrace');
|
2015-03-24 00:09:14 +00:00
|
|
|
|
2016-09-19 11:43:09 +00:00
|
|
|
const deepFreezeAndThrowOnMutationInDev = require('deepFreezeAndThrowOnMutationInDev');
|
2016-09-23 18:12:51 +00:00
|
|
|
const invariant = require('fbjs/lib/invariant');
|
2016-06-15 14:50:20 +00:00
|
|
|
const stringifySafe = require('stringifySafe');
|
2015-03-24 00:09:14 +00:00
|
|
|
|
2016-09-23 18:12:51 +00:00
|
|
|
export type SpyData = {
|
|
|
|
type: number,
|
|
|
|
module: ?string,
|
2017-09-28 20:11:08 +00:00
|
|
|
method: string | number,
|
2017-10-10 23:20:15 +00:00
|
|
|
args: any[],
|
2017-09-28 20:11:08 +00:00
|
|
|
};
|
2016-09-23 18:12:51 +00:00
|
|
|
|
|
|
|
const TO_JS = 0;
|
|
|
|
const TO_NATIVE = 1;
|
|
|
|
|
2016-06-15 14:50:20 +00:00
|
|
|
const MODULE_IDS = 0;
|
|
|
|
const METHOD_IDS = 1;
|
|
|
|
const PARAMS = 2;
|
|
|
|
const MIN_TIME_BETWEEN_FLUSHES_MS = 5;
|
2015-02-20 04:10:52 +00:00
|
|
|
|
2017-10-10 23:20:15 +00:00
|
|
|
// eslint-disable-next-line no-bitwise
|
2016-08-04 15:38:49 +00:00
|
|
|
const TRACE_TAG_REACT_APPS = 1 << 17;
|
2015-07-09 16:12:53 +00:00
|
|
|
|
2017-09-07 21:23:13 +00:00
|
|
|
const DEBUG_INFO_LIMIT = 32;
|
2016-08-27 01:44:07 +00:00
|
|
|
|
2016-05-06 11:13:30 +00:00
|
|
|
class MessageQueue {
|
2017-09-28 20:11:08 +00:00
|
|
|
_lazyCallableModules: {[key: string]: (void) => Object};
|
2017-10-10 23:20:15 +00:00
|
|
|
_queue: [number[], number[], any[], number];
|
2018-03-20 11:12:06 +00:00
|
|
|
_successCallbacks: {[key: number]: ?Function};
|
|
|
|
_failureCallbacks: {[key: number]: ?Function};
|
2016-09-23 18:12:51 +00:00
|
|
|
_callID: number;
|
|
|
|
_lastFlush: number;
|
|
|
|
_eventLoopStartTime: number;
|
2018-06-16 00:00:53 +00:00
|
|
|
_immediatesCallback: ?() => void;
|
2016-09-23 18:12:51 +00:00
|
|
|
|
2017-10-10 23:20:15 +00:00
|
|
|
_debugInfo: {[number]: [number, number]};
|
|
|
|
_remoteModuleTable: {[number]: string};
|
|
|
|
_remoteMethodTable: {[number]: string[]};
|
2016-09-23 18:12:51 +00:00
|
|
|
|
|
|
|
__spy: ?(data: SpyData) => void;
|
|
|
|
|
2018-04-03 12:59:07 +00:00
|
|
|
constructor() {
|
2017-06-06 14:03:10 +00:00
|
|
|
this._lazyCallableModules = {};
|
2016-01-04 10:15:19 +00:00
|
|
|
this._queue = [[], [], [], 0];
|
2018-03-20 11:12:06 +00:00
|
|
|
this._successCallbacks = {};
|
|
|
|
this._failureCallbacks = {};
|
2016-01-04 10:15:19 +00:00
|
|
|
this._callID = 0;
|
2015-10-13 15:00:36 +00:00
|
|
|
this._lastFlush = 0;
|
Add yieldy, chained async task support to InteractionManager
Summary:
Default behavior should be unchanged.
If we queue up a bunch of expensive tasks during an interaction, the default
`InteractionManager` behavior would execute them all in one synchronous loop at
the end the JS event loop via one `setImmediate` call, blocking the JS thread
the entire time.
The `setDeadline` addition in this diff enables an option to only execute tasks
until the `eventLoopRunningTime` is hit (added to MessageQueue/BatchedBridge),
allowing the queue execution to be paused if an interaction starts in between
tasks, making the app more responsive.
Additionally, if a task ends up generating a bunch of additional tasks
asynchronously, the previous implementation would execute these new tasks after
already scheduled tasks. This is often fine, but I want it to fully resolve
async tasks and all their dependencies before making progress in the rest of the
queue, so I added support for `type PromiseTask = {gen: () => Promise}` to do
just this. It works by building a stack of queues each time a `PromiseTask` is
started, and pops them off the stack once they are resolved and the queues are
processed.
I also pulled all of the actual queue logic out of `InteractionManager` and into
a new `TaskQueue` class to isolate concerns a bit.
public
Reviewed By: josephsavona
Differential Revision: D2754311
fb-gh-sync-id: bfd6d0c54e6410cb261aa1d2c5024dd91a3959e6
2015-12-24 00:10:39 +00:00
|
|
|
this._eventLoopStartTime = new Date().getTime();
|
2018-06-16 00:00:53 +00:00
|
|
|
this._immediatesCallback = null;
|
[ReactNative] Refactor BatchedBridge and MessageQueue
Summary:
@public
The current implementation of `MessageQueue` is huge, over-complicated and spread
across `MethodQueue`, `MethodQueueMixin`, `BatchedBridge` and `BatchedBridgeFactory`
Refactored in a simpler way, were it's just a `MessageQueue` class and `BatchedBridge`
is only an instance of it.
Test Plan:
I had to make some updates to the tests, but no real update to the native side.
There's also tests covering the `remoteAsync` methods, and more integration tests for UIExplorer.
Verified whats being used by Android, and it should be safe, also tests Android tests have been pretty reliable.
Manually testing: Create a big hierarchy, like `<ListView>` example. Use the `TimerMixin` example to generate multiple calls.
Test the failure callback on the `Geolocation` example.
All the calls go through this entry point, so it's hard to miss if it's broken.
2015-06-17 14:51:48 +00:00
|
|
|
|
2016-06-15 14:50:20 +00:00
|
|
|
if (__DEV__) {
|
|
|
|
this._debugInfo = {};
|
|
|
|
this._remoteModuleTable = {};
|
|
|
|
this._remoteMethodTable = {};
|
|
|
|
}
|
2017-09-07 21:23:13 +00:00
|
|
|
|
2017-09-28 20:11:08 +00:00
|
|
|
(this: any).callFunctionReturnFlushedQueue = this.callFunctionReturnFlushedQueue.bind(
|
|
|
|
this,
|
|
|
|
);
|
|
|
|
(this: any).callFunctionReturnResultAndFlushedQueue = this.callFunctionReturnResultAndFlushedQueue.bind(
|
|
|
|
this,
|
|
|
|
);
|
|
|
|
(this: any).flushedQueue = this.flushedQueue.bind(this);
|
|
|
|
(this: any).invokeCallbackAndReturnFlushedQueue = this.invokeCallbackAndReturnFlushedQueue.bind(
|
|
|
|
this,
|
|
|
|
);
|
[ReactNative] Refactor BatchedBridge and MessageQueue
Summary:
@public
The current implementation of `MessageQueue` is huge, over-complicated and spread
across `MethodQueue`, `MethodQueueMixin`, `BatchedBridge` and `BatchedBridgeFactory`
Refactored in a simpler way, were it's just a `MessageQueue` class and `BatchedBridge`
is only an instance of it.
Test Plan:
I had to make some updates to the tests, but no real update to the native side.
There's also tests covering the `remoteAsync` methods, and more integration tests for UIExplorer.
Verified whats being used by Android, and it should be safe, also tests Android tests have been pretty reliable.
Manually testing: Create a big hierarchy, like `<ListView>` example. Use the `TimerMixin` example to generate multiple calls.
Test the failure callback on the `Geolocation` example.
All the calls go through this entry point, so it's hard to miss if it's broken.
2015-06-17 14:51:48 +00:00
|
|
|
}
|
2015-02-20 04:10:52 +00:00
|
|
|
|
|
|
|
/**
|
[ReactNative] Refactor BatchedBridge and MessageQueue
Summary:
@public
The current implementation of `MessageQueue` is huge, over-complicated and spread
across `MethodQueue`, `MethodQueueMixin`, `BatchedBridge` and `BatchedBridgeFactory`
Refactored in a simpler way, were it's just a `MessageQueue` class and `BatchedBridge`
is only an instance of it.
Test Plan:
I had to make some updates to the tests, but no real update to the native side.
There's also tests covering the `remoteAsync` methods, and more integration tests for UIExplorer.
Verified whats being used by Android, and it should be safe, also tests Android tests have been pretty reliable.
Manually testing: Create a big hierarchy, like `<ListView>` example. Use the `TimerMixin` example to generate multiple calls.
Test the failure callback on the `Geolocation` example.
All the calls go through this entry point, so it's hard to miss if it's broken.
2015-06-17 14:51:48 +00:00
|
|
|
* Public APIs
|
2015-02-20 04:10:52 +00:00
|
|
|
*/
|
2017-09-07 21:23:13 +00:00
|
|
|
|
2017-09-28 20:11:08 +00:00
|
|
|
static spy(spyOrToggle: boolean | ((data: SpyData) => void)) {
|
|
|
|
if (spyOrToggle === true) {
|
2016-09-23 18:12:51 +00:00
|
|
|
MessageQueue.prototype.__spy = info => {
|
2017-09-28 20:11:08 +00:00
|
|
|
console.log(
|
|
|
|
`${info.type === TO_JS ? 'N->JS' : 'JS->N'} : ` +
|
|
|
|
`${info.module ? info.module + '.' : ''}${info.method}` +
|
|
|
|
`(${JSON.stringify(info.args)})`,
|
|
|
|
);
|
2016-08-09 13:32:41 +00:00
|
|
|
};
|
2016-08-04 15:38:49 +00:00
|
|
|
} else if (spyOrToggle === false) {
|
|
|
|
MessageQueue.prototype.__spy = null;
|
|
|
|
} else {
|
|
|
|
MessageQueue.prototype.__spy = spyOrToggle;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-10-10 23:20:15 +00:00
|
|
|
callFunctionReturnFlushedQueue(module: string, method: string, args: any[]) {
|
2017-03-28 14:11:45 +00:00
|
|
|
this.__guard(() => {
|
2015-10-13 10:22:40 +00:00
|
|
|
this.__callFunction(module, method, args);
|
[ReactNative] Refactor BatchedBridge and MessageQueue
Summary:
@public
The current implementation of `MessageQueue` is huge, over-complicated and spread
across `MethodQueue`, `MethodQueueMixin`, `BatchedBridge` and `BatchedBridgeFactory`
Refactored in a simpler way, were it's just a `MessageQueue` class and `BatchedBridge`
is only an instance of it.
Test Plan:
I had to make some updates to the tests, but no real update to the native side.
There's also tests covering the `remoteAsync` methods, and more integration tests for UIExplorer.
Verified whats being used by Android, and it should be safe, also tests Android tests have been pretty reliable.
Manually testing: Create a big hierarchy, like `<ListView>` example. Use the `TimerMixin` example to generate multiple calls.
Test the failure callback on the `Geolocation` example.
All the calls go through this entry point, so it's hard to miss if it's broken.
2015-06-17 14:51:48 +00:00
|
|
|
});
|
2015-09-29 10:14:14 +00:00
|
|
|
|
[ReactNative] Refactor BatchedBridge and MessageQueue
Summary:
@public
The current implementation of `MessageQueue` is huge, over-complicated and spread
across `MethodQueue`, `MethodQueueMixin`, `BatchedBridge` and `BatchedBridgeFactory`
Refactored in a simpler way, were it's just a `MessageQueue` class and `BatchedBridge`
is only an instance of it.
Test Plan:
I had to make some updates to the tests, but no real update to the native side.
There's also tests covering the `remoteAsync` methods, and more integration tests for UIExplorer.
Verified whats being used by Android, and it should be safe, also tests Android tests have been pretty reliable.
Manually testing: Create a big hierarchy, like `<ListView>` example. Use the `TimerMixin` example to generate multiple calls.
Test the failure callback on the `Geolocation` example.
All the calls go through this entry point, so it's hard to miss if it's broken.
2015-06-17 14:51:48 +00:00
|
|
|
return this.flushedQueue();
|
2017-09-07 21:23:13 +00:00
|
|
|
}
|
2015-02-20 04:10:52 +00:00
|
|
|
|
2017-09-28 20:11:08 +00:00
|
|
|
callFunctionReturnResultAndFlushedQueue(
|
|
|
|
module: string,
|
|
|
|
method: string,
|
2017-10-10 23:20:15 +00:00
|
|
|
args: any[],
|
2017-09-28 20:11:08 +00:00
|
|
|
) {
|
2016-07-18 14:12:19 +00:00
|
|
|
let result;
|
2017-03-28 14:11:45 +00:00
|
|
|
this.__guard(() => {
|
2016-07-18 14:12:19 +00:00
|
|
|
result = this.__callFunction(module, method, args);
|
|
|
|
});
|
|
|
|
|
2016-09-16 13:14:13 +00:00
|
|
|
return [result, this.flushedQueue()];
|
2017-09-07 21:23:13 +00:00
|
|
|
}
|
2016-07-18 14:12:19 +00:00
|
|
|
|
2017-10-10 23:20:15 +00:00
|
|
|
invokeCallbackAndReturnFlushedQueue(cbID: number, args: any[]) {
|
2017-03-28 14:11:45 +00:00
|
|
|
this.__guard(() => {
|
2015-10-13 10:22:40 +00:00
|
|
|
this.__invokeCallback(cbID, args);
|
|
|
|
});
|
|
|
|
|
[ReactNative] Refactor BatchedBridge and MessageQueue
Summary:
@public
The current implementation of `MessageQueue` is huge, over-complicated and spread
across `MethodQueue`, `MethodQueueMixin`, `BatchedBridge` and `BatchedBridgeFactory`
Refactored in a simpler way, were it's just a `MessageQueue` class and `BatchedBridge`
is only an instance of it.
Test Plan:
I had to make some updates to the tests, but no real update to the native side.
There's also tests covering the `remoteAsync` methods, and more integration tests for UIExplorer.
Verified whats being used by Android, and it should be safe, also tests Android tests have been pretty reliable.
Manually testing: Create a big hierarchy, like `<ListView>` example. Use the `TimerMixin` example to generate multiple calls.
Test the failure callback on the `Geolocation` example.
All the calls go through this entry point, so it's hard to miss if it's broken.
2015-06-17 14:51:48 +00:00
|
|
|
return this.flushedQueue();
|
2017-09-07 21:23:13 +00:00
|
|
|
}
|
2015-02-20 04:10:52 +00:00
|
|
|
|
2017-09-07 21:23:13 +00:00
|
|
|
flushedQueue() {
|
2017-06-02 15:16:04 +00:00
|
|
|
this.__guard(() => {
|
|
|
|
this.__callImmediates();
|
|
|
|
});
|
2015-10-13 10:22:40 +00:00
|
|
|
|
2016-06-15 14:50:20 +00:00
|
|
|
const queue = this._queue;
|
2016-01-04 10:15:19 +00:00
|
|
|
this._queue = [[], [], [], this._callID];
|
2015-10-13 10:22:40 +00:00
|
|
|
return queue[0].length ? queue : null;
|
2017-09-07 21:23:13 +00:00
|
|
|
}
|
2015-09-29 10:14:14 +00:00
|
|
|
|
Add yieldy, chained async task support to InteractionManager
Summary:
Default behavior should be unchanged.
If we queue up a bunch of expensive tasks during an interaction, the default
`InteractionManager` behavior would execute them all in one synchronous loop at
the end the JS event loop via one `setImmediate` call, blocking the JS thread
the entire time.
The `setDeadline` addition in this diff enables an option to only execute tasks
until the `eventLoopRunningTime` is hit (added to MessageQueue/BatchedBridge),
allowing the queue execution to be paused if an interaction starts in between
tasks, making the app more responsive.
Additionally, if a task ends up generating a bunch of additional tasks
asynchronously, the previous implementation would execute these new tasks after
already scheduled tasks. This is often fine, but I want it to fully resolve
async tasks and all their dependencies before making progress in the rest of the
queue, so I added support for `type PromiseTask = {gen: () => Promise}` to do
just this. It works by building a stack of queues each time a `PromiseTask` is
started, and pops them off the stack once they are resolved and the queues are
processed.
I also pulled all of the actual queue logic out of `InteractionManager` and into
a new `TaskQueue` class to isolate concerns a bit.
public
Reviewed By: josephsavona
Differential Revision: D2754311
fb-gh-sync-id: bfd6d0c54e6410cb261aa1d2c5024dd91a3959e6
2015-12-24 00:10:39 +00:00
|
|
|
getEventLoopRunningTime() {
|
|
|
|
return new Date().getTime() - this._eventLoopStartTime;
|
|
|
|
}
|
|
|
|
|
2016-09-23 18:12:51 +00:00
|
|
|
registerCallableModule(name: string, module: Object) {
|
2017-06-06 14:03:10 +00:00
|
|
|
this._lazyCallableModules[name] = () => module;
|
|
|
|
}
|
|
|
|
|
|
|
|
registerLazyCallableModule(name: string, factory: void => Object) {
|
|
|
|
let module: Object;
|
2017-09-28 20:11:08 +00:00
|
|
|
let getValue: ?(void) => Object = factory;
|
2017-06-06 14:03:10 +00:00
|
|
|
this._lazyCallableModules[name] = () => {
|
|
|
|
if (getValue) {
|
|
|
|
module = getValue();
|
|
|
|
getValue = null;
|
|
|
|
}
|
|
|
|
return module;
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
2017-07-03 14:44:38 +00:00
|
|
|
getCallableModule(name: string) {
|
2017-06-08 19:40:19 +00:00
|
|
|
const getValue = this._lazyCallableModules[name];
|
|
|
|
return getValue ? getValue() : null;
|
2016-09-08 10:59:32 +00:00
|
|
|
}
|
|
|
|
|
2017-09-28 20:11:08 +00:00
|
|
|
enqueueNativeCall(
|
|
|
|
moduleID: number,
|
|
|
|
methodID: number,
|
2017-10-10 23:20:15 +00:00
|
|
|
params: any[],
|
2017-09-28 20:11:08 +00:00
|
|
|
onFail: ?Function,
|
|
|
|
onSucc: ?Function,
|
|
|
|
) {
|
[ReactNative] Refactor BatchedBridge and MessageQueue
Summary:
@public
The current implementation of `MessageQueue` is huge, over-complicated and spread
across `MethodQueue`, `MethodQueueMixin`, `BatchedBridge` and `BatchedBridgeFactory`
Refactored in a simpler way, were it's just a `MessageQueue` class and `BatchedBridge`
is only an instance of it.
Test Plan:
I had to make some updates to the tests, but no real update to the native side.
There's also tests covering the `remoteAsync` methods, and more integration tests for UIExplorer.
Verified whats being used by Android, and it should be safe, also tests Android tests have been pretty reliable.
Manually testing: Create a big hierarchy, like `<ListView>` example. Use the `TimerMixin` example to generate multiple calls.
Test the failure callback on the `Geolocation` example.
All the calls go through this entry point, so it's hard to miss if it's broken.
2015-06-17 14:51:48 +00:00
|
|
|
if (onFail || onSucc) {
|
2016-06-15 14:50:20 +00:00
|
|
|
if (__DEV__) {
|
2017-04-28 10:47:19 +00:00
|
|
|
this._debugInfo[this._callID] = [moduleID, methodID];
|
|
|
|
if (this._callID > DEBUG_INFO_LIMIT) {
|
|
|
|
delete this._debugInfo[this._callID - DEBUG_INFO_LIMIT];
|
2016-08-27 01:44:07 +00:00
|
|
|
}
|
2016-06-15 14:50:20 +00:00
|
|
|
}
|
2017-04-28 10:47:19 +00:00
|
|
|
// Encode callIDs into pairs of callback identifiers by shifting left and using the rightmost bit
|
|
|
|
// to indicate fail (0) or success (1)
|
2017-10-10 23:20:15 +00:00
|
|
|
// eslint-disable-next-line no-bitwise
|
2017-04-28 10:47:19 +00:00
|
|
|
onFail && params.push(this._callID << 1);
|
2017-10-10 23:20:15 +00:00
|
|
|
// eslint-disable-next-line no-bitwise
|
2017-04-28 10:47:19 +00:00
|
|
|
onSucc && params.push((this._callID << 1) | 1);
|
|
|
|
this._successCallbacks[this._callID] = onSucc;
|
|
|
|
this._failureCallbacks[this._callID] = onFail;
|
2015-06-15 20:01:39 +00:00
|
|
|
}
|
2016-01-04 10:15:19 +00:00
|
|
|
|
2016-06-21 19:02:31 +00:00
|
|
|
if (__DEV__) {
|
|
|
|
global.nativeTraceBeginAsyncFlow &&
|
2017-09-28 20:11:08 +00:00
|
|
|
global.nativeTraceBeginAsyncFlow(
|
|
|
|
TRACE_TAG_REACT_APPS,
|
|
|
|
'native',
|
|
|
|
this._callID,
|
|
|
|
);
|
2016-06-21 19:02:31 +00:00
|
|
|
}
|
2016-01-04 10:15:19 +00:00
|
|
|
this._callID++;
|
|
|
|
|
2016-09-23 18:12:51 +00:00
|
|
|
this._queue[MODULE_IDS].push(moduleID);
|
|
|
|
this._queue[METHOD_IDS].push(methodID);
|
2016-09-08 10:59:32 +00:00
|
|
|
|
2016-09-19 11:43:09 +00:00
|
|
|
if (__DEV__) {
|
2017-12-14 19:05:35 +00:00
|
|
|
// Validate that parameters passed over the bridge are
|
|
|
|
// folly-convertible. As a special case, if a prop value is a
|
|
|
|
// function it is permitted here, and special-cased in the
|
|
|
|
// conversion.
|
|
|
|
const isValidArgument = val => {
|
|
|
|
const t = typeof val;
|
|
|
|
if (
|
|
|
|
t === 'undefined' ||
|
|
|
|
t === 'null' ||
|
|
|
|
t === 'boolean' ||
|
|
|
|
t === 'number' ||
|
|
|
|
t === 'string'
|
|
|
|
) {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
if (t === 'function' || t !== 'object') {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
if (Array.isArray(val)) {
|
|
|
|
return val.every(isValidArgument);
|
|
|
|
}
|
|
|
|
for (const k in val) {
|
|
|
|
if (typeof val[k] !== 'function' && !isValidArgument(val[k])) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
};
|
|
|
|
|
|
|
|
invariant(
|
|
|
|
isValidArgument(params),
|
|
|
|
'%s is not usable as a native method argument',
|
|
|
|
params,
|
|
|
|
);
|
2016-09-19 11:43:09 +00:00
|
|
|
|
|
|
|
// The params object should not be mutated after being queued
|
2017-09-28 20:11:08 +00:00
|
|
|
deepFreezeAndThrowOnMutationInDev((params: any));
|
2016-09-19 11:43:09 +00:00
|
|
|
}
|
|
|
|
this._queue[PARAMS].push(params);
|
2015-10-13 15:00:36 +00:00
|
|
|
|
2016-06-15 14:50:20 +00:00
|
|
|
const now = new Date().getTime();
|
2017-09-28 20:11:08 +00:00
|
|
|
if (
|
|
|
|
global.nativeFlushQueueImmediate &&
|
2018-05-10 17:45:36 +00:00
|
|
|
now - this._lastFlush >= MIN_TIME_BETWEEN_FLUSHES_MS
|
2017-09-28 20:11:08 +00:00
|
|
|
) {
|
2018-05-11 02:06:39 +00:00
|
|
|
const queue = this._queue;
|
2016-01-04 10:15:19 +00:00
|
|
|
this._queue = [[], [], [], this._callID];
|
2015-10-13 15:00:36 +00:00
|
|
|
this._lastFlush = now;
|
2017-03-31 07:46:14 +00:00
|
|
|
global.nativeFlushQueueImmediate(queue);
|
2015-10-13 15:00:36 +00:00
|
|
|
}
|
2015-12-30 07:36:34 +00:00
|
|
|
Systrace.counterEvent('pending_js_to_native_queue', this._queue[0].length);
|
2017-09-07 21:23:13 +00:00
|
|
|
if (__DEV__ && this.__spy && isFinite(moduleID)) {
|
2017-09-28 20:11:08 +00:00
|
|
|
this.__spy({
|
|
|
|
type: TO_NATIVE,
|
|
|
|
module: this._remoteModuleTable[moduleID],
|
|
|
|
method: this._remoteMethodTable[moduleID][methodID],
|
|
|
|
args: params,
|
|
|
|
});
|
2017-09-07 21:23:13 +00:00
|
|
|
} else if (this.__spy) {
|
2017-09-28 20:11:08 +00:00
|
|
|
this.__spy({
|
|
|
|
type: TO_NATIVE,
|
|
|
|
module: moduleID + '',
|
|
|
|
method: methodID,
|
|
|
|
args: params,
|
|
|
|
});
|
2015-07-13 16:37:05 +00:00
|
|
|
}
|
[ReactNative] Refactor BatchedBridge and MessageQueue
Summary:
@public
The current implementation of `MessageQueue` is huge, over-complicated and spread
across `MethodQueue`, `MethodQueueMixin`, `BatchedBridge` and `BatchedBridgeFactory`
Refactored in a simpler way, were it's just a `MessageQueue` class and `BatchedBridge`
is only an instance of it.
Test Plan:
I had to make some updates to the tests, but no real update to the native side.
There's also tests covering the `remoteAsync` methods, and more integration tests for UIExplorer.
Verified whats being used by Android, and it should be safe, also tests Android tests have been pretty reliable.
Manually testing: Create a big hierarchy, like `<ListView>` example. Use the `TimerMixin` example to generate multiple calls.
Test the failure callback on the `Geolocation` example.
All the calls go through this entry point, so it's hard to miss if it's broken.
2015-06-17 14:51:48 +00:00
|
|
|
}
|
2015-02-20 04:10:52 +00:00
|
|
|
|
2017-10-10 23:20:15 +00:00
|
|
|
createDebugLookup(moduleID: number, name: string, methods: string[]) {
|
2016-09-23 18:12:54 +00:00
|
|
|
if (__DEV__) {
|
|
|
|
this._remoteModuleTable[moduleID] = name;
|
|
|
|
this._remoteMethodTable[moduleID] = methods;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-06-16 00:00:53 +00:00
|
|
|
// For JSTimers to register its callback. Otherwise a circular dependency
|
|
|
|
// between modules is introduced. Note that only one callback may be
|
|
|
|
// registered at a time.
|
|
|
|
setImmediatesCallback(fn: () => void) {
|
|
|
|
this._immediatesCallback = fn;
|
|
|
|
}
|
|
|
|
|
2016-09-23 18:12:54 +00:00
|
|
|
/**
|
2017-03-28 14:11:45 +00:00
|
|
|
* Private methods
|
2016-09-23 18:12:54 +00:00
|
|
|
*/
|
|
|
|
|
2018-04-03 12:59:07 +00:00
|
|
|
__guard(fn: () => void) {
|
|
|
|
if (this.__shouldPauseOnThrow()) {
|
|
|
|
fn();
|
|
|
|
} else {
|
|
|
|
try {
|
|
|
|
fn();
|
|
|
|
} catch (error) {
|
|
|
|
ErrorUtils.reportFatalError(error);
|
|
|
|
}
|
|
|
|
}
|
2017-12-11 15:59:45 +00:00
|
|
|
}
|
|
|
|
|
2018-04-03 12:59:07 +00:00
|
|
|
// MessageQueue installs a global handler to catch all exceptions where JS users can register their own behavior
|
|
|
|
// This handler makes all exceptions to be propagated from inside MessageQueue rather than by the VM at their origin
|
|
|
|
// This makes stacktraces to be placed at MessageQueue rather than at where they were launched
|
|
|
|
// The parameter DebuggerInternal.shouldPauseOnThrow is used to check before catching all exceptions and
|
|
|
|
// can be configured by the VM or any Inspector
|
|
|
|
__shouldPauseOnThrow() {
|
|
|
|
return (
|
|
|
|
// $FlowFixMe
|
2018-05-21 18:08:25 +00:00
|
|
|
typeof DebuggerInternal !== 'undefined' &&
|
|
|
|
DebuggerInternal.shouldPauseOnThrow === true // eslint-disable-line no-undef
|
2018-04-03 12:59:07 +00:00
|
|
|
);
|
2017-03-28 14:11:45 +00:00
|
|
|
}
|
|
|
|
|
2016-09-23 18:12:54 +00:00
|
|
|
__callImmediates() {
|
2017-06-22 16:46:28 +00:00
|
|
|
Systrace.beginEvent('JSTimers.callImmediates()');
|
2018-06-16 00:00:53 +00:00
|
|
|
if (this._immediatesCallback != null) {
|
|
|
|
this._immediatesCallback();
|
2017-06-22 16:46:28 +00:00
|
|
|
}
|
2016-09-23 18:12:54 +00:00
|
|
|
Systrace.endEvent();
|
|
|
|
}
|
|
|
|
|
2017-10-10 23:20:15 +00:00
|
|
|
__callFunction(module: string, method: string, args: any[]): any {
|
2015-10-13 15:00:36 +00:00
|
|
|
this._lastFlush = new Date().getTime();
|
Add yieldy, chained async task support to InteractionManager
Summary:
Default behavior should be unchanged.
If we queue up a bunch of expensive tasks during an interaction, the default
`InteractionManager` behavior would execute them all in one synchronous loop at
the end the JS event loop via one `setImmediate` call, blocking the JS thread
the entire time.
The `setDeadline` addition in this diff enables an option to only execute tasks
until the `eventLoopRunningTime` is hit (added to MessageQueue/BatchedBridge),
allowing the queue execution to be paused if an interaction starts in between
tasks, making the app more responsive.
Additionally, if a task ends up generating a bunch of additional tasks
asynchronously, the previous implementation would execute these new tasks after
already scheduled tasks. This is often fine, but I want it to fully resolve
async tasks and all their dependencies before making progress in the rest of the
queue, so I added support for `type PromiseTask = {gen: () => Promise}` to do
just this. It works by building a stack of queues each time a `PromiseTask` is
started, and pops them off the stack once they are resolved and the queues are
processed.
I also pulled all of the actual queue logic out of `InteractionManager` and into
a new `TaskQueue` class to isolate concerns a bit.
public
Reviewed By: josephsavona
Differential Revision: D2754311
fb-gh-sync-id: bfd6d0c54e6410cb261aa1d2c5024dd91a3959e6
2015-12-24 00:10:39 +00:00
|
|
|
this._eventLoopStartTime = this._lastFlush;
|
2018-04-30 16:52:34 +00:00
|
|
|
if (__DEV__ || this.__spy) {
|
|
|
|
Systrace.beginEvent(`${module}.${method}(${stringifySafe(args)})`);
|
|
|
|
} else {
|
|
|
|
Systrace.beginEvent(`${module}.${method}(...)`);
|
|
|
|
}
|
2017-02-07 01:39:15 +00:00
|
|
|
if (this.__spy) {
|
2017-09-28 20:11:08 +00:00
|
|
|
this.__spy({type: TO_JS, module, method, args});
|
2015-07-09 16:12:53 +00:00
|
|
|
}
|
2017-07-03 14:44:38 +00:00
|
|
|
const moduleMethods = this.getCallableModule(module);
|
2015-12-11 07:15:38 +00:00
|
|
|
invariant(
|
|
|
|
!!moduleMethods,
|
2016-08-10 14:41:54 +00:00
|
|
|
'Module %s is not a registered callable module (calling %s)',
|
2017-09-28 20:11:08 +00:00
|
|
|
module,
|
|
|
|
method,
|
2015-12-11 07:15:38 +00:00
|
|
|
);
|
2016-08-02 18:06:19 +00:00
|
|
|
invariant(
|
|
|
|
!!moduleMethods[method],
|
|
|
|
'Method %s does not exist on module %s',
|
2017-09-28 20:11:08 +00:00
|
|
|
method,
|
|
|
|
module,
|
2016-08-02 18:06:19 +00:00
|
|
|
);
|
2016-07-18 14:12:19 +00:00
|
|
|
const result = moduleMethods[method].apply(moduleMethods, args);
|
2015-12-11 11:49:15 +00:00
|
|
|
Systrace.endEvent();
|
2016-07-18 14:12:19 +00:00
|
|
|
return result;
|
[ReactNative] Refactor BatchedBridge and MessageQueue
Summary:
@public
The current implementation of `MessageQueue` is huge, over-complicated and spread
across `MethodQueue`, `MethodQueueMixin`, `BatchedBridge` and `BatchedBridgeFactory`
Refactored in a simpler way, were it's just a `MessageQueue` class and `BatchedBridge`
is only an instance of it.
Test Plan:
I had to make some updates to the tests, but no real update to the native side.
There's also tests covering the `remoteAsync` methods, and more integration tests for UIExplorer.
Verified whats being used by Android, and it should be safe, also tests Android tests have been pretty reliable.
Manually testing: Create a big hierarchy, like `<ListView>` example. Use the `TimerMixin` example to generate multiple calls.
Test the failure callback on the `Geolocation` example.
All the calls go through this entry point, so it's hard to miss if it's broken.
2015-06-17 14:51:48 +00:00
|
|
|
}
|
2015-02-20 04:10:52 +00:00
|
|
|
|
2017-10-10 23:20:15 +00:00
|
|
|
__invokeCallback(cbID: number, args: any[]) {
|
2015-10-13 15:00:36 +00:00
|
|
|
this._lastFlush = new Date().getTime();
|
Add yieldy, chained async task support to InteractionManager
Summary:
Default behavior should be unchanged.
If we queue up a bunch of expensive tasks during an interaction, the default
`InteractionManager` behavior would execute them all in one synchronous loop at
the end the JS event loop via one `setImmediate` call, blocking the JS thread
the entire time.
The `setDeadline` addition in this diff enables an option to only execute tasks
until the `eventLoopRunningTime` is hit (added to MessageQueue/BatchedBridge),
allowing the queue execution to be paused if an interaction starts in between
tasks, making the app more responsive.
Additionally, if a task ends up generating a bunch of additional tasks
asynchronously, the previous implementation would execute these new tasks after
already scheduled tasks. This is often fine, but I want it to fully resolve
async tasks and all their dependencies before making progress in the rest of the
queue, so I added support for `type PromiseTask = {gen: () => Promise}` to do
just this. It works by building a stack of queues each time a `PromiseTask` is
started, and pops them off the stack once they are resolved and the queues are
processed.
I also pulled all of the actual queue logic out of `InteractionManager` and into
a new `TaskQueue` class to isolate concerns a bit.
public
Reviewed By: josephsavona
Differential Revision: D2754311
fb-gh-sync-id: bfd6d0c54e6410cb261aa1d2c5024dd91a3959e6
2015-12-24 00:10:39 +00:00
|
|
|
this._eventLoopStartTime = this._lastFlush;
|
2017-04-28 10:47:19 +00:00
|
|
|
|
|
|
|
// The rightmost bit of cbID indicates fail (0) or success (1), the other bits are the callID shifted left.
|
2017-10-10 23:20:15 +00:00
|
|
|
// eslint-disable-next-line no-bitwise
|
2017-04-28 10:47:19 +00:00
|
|
|
const callID = cbID >>> 1;
|
2017-10-10 23:20:15 +00:00
|
|
|
// eslint-disable-next-line no-bitwise
|
|
|
|
const isSuccess = cbID & 1;
|
|
|
|
const callback = isSuccess
|
|
|
|
? this._successCallbacks[callID]
|
|
|
|
: this._failureCallbacks[callID];
|
2016-06-15 14:50:20 +00:00
|
|
|
|
|
|
|
if (__DEV__) {
|
2017-04-28 10:47:19 +00:00
|
|
|
const debug = this._debugInfo[callID];
|
2016-06-15 14:50:20 +00:00
|
|
|
const module = debug && this._remoteModuleTable[debug[0]];
|
|
|
|
const method = debug && this._remoteMethodTable[debug[0]][debug[1]];
|
2017-04-28 10:47:19 +00:00
|
|
|
if (!callback) {
|
2016-06-23 10:06:58 +00:00
|
|
|
let errorMessage = `Callback with id ${cbID}: ${module}.${method}() not found`;
|
2016-06-15 14:50:20 +00:00
|
|
|
if (method) {
|
2017-09-28 20:11:08 +00:00
|
|
|
errorMessage =
|
|
|
|
`The callback ${method}() exists in module ${module}, ` +
|
|
|
|
'but only one callback may be registered to a function in a native module.';
|
2016-06-15 14:50:20 +00:00
|
|
|
}
|
2017-09-28 20:11:08 +00:00
|
|
|
invariant(callback, errorMessage);
|
2016-06-15 14:50:20 +00:00
|
|
|
}
|
2017-09-28 20:11:08 +00:00
|
|
|
const profileName = debug
|
|
|
|
? '<callback for ' + module + '.' + method + '>'
|
|
|
|
: cbID;
|
2017-09-07 21:23:13 +00:00
|
|
|
if (callback && this.__spy) {
|
2017-09-28 20:11:08 +00:00
|
|
|
this.__spy({type: TO_JS, module: null, method: profileName, args});
|
2016-06-15 14:50:20 +00:00
|
|
|
}
|
|
|
|
Systrace.beginEvent(
|
2017-09-28 20:11:08 +00:00
|
|
|
`MessageQueue.invokeCallback(${profileName}, ${stringifySafe(args)})`,
|
|
|
|
);
|
2015-02-20 04:10:52 +00:00
|
|
|
}
|
2016-06-15 14:50:20 +00:00
|
|
|
|
2017-04-28 10:47:19 +00:00
|
|
|
if (!callback) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2018-03-20 11:12:06 +00:00
|
|
|
delete this._successCallbacks[callID];
|
|
|
|
delete this._failureCallbacks[callID];
|
2017-10-10 23:20:15 +00:00
|
|
|
callback(...args);
|
2016-06-15 14:50:20 +00:00
|
|
|
|
|
|
|
if (__DEV__) {
|
|
|
|
Systrace.endEvent();
|
|
|
|
}
|
[ReactNative] Refactor BatchedBridge and MessageQueue
Summary:
@public
The current implementation of `MessageQueue` is huge, over-complicated and spread
across `MethodQueue`, `MethodQueueMixin`, `BatchedBridge` and `BatchedBridgeFactory`
Refactored in a simpler way, were it's just a `MessageQueue` class and `BatchedBridge`
is only an instance of it.
Test Plan:
I had to make some updates to the tests, but no real update to the native side.
There's also tests covering the `remoteAsync` methods, and more integration tests for UIExplorer.
Verified whats being used by Android, and it should be safe, also tests Android tests have been pretty reliable.
Manually testing: Create a big hierarchy, like `<ListView>` example. Use the `TimerMixin` example to generate multiple calls.
Test the failure callback on the `Geolocation` example.
All the calls go through this entry point, so it's hard to miss if it's broken.
2015-06-17 14:51:48 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-02-20 04:10:52 +00:00
|
|
|
module.exports = MessageQueue;
|