2015-02-20 04:10:52 +00:00
|
|
|
/**
|
2015-03-23 20:35:08 +00:00
|
|
|
* Copyright (c) 2015-present, Facebook, Inc.
|
|
|
|
* All rights reserved.
|
|
|
|
*
|
|
|
|
* This source code is licensed under the BSD-style license found in the
|
|
|
|
* LICENSE file in the root directory of this source tree. An additional grant
|
|
|
|
* of patent rights can be found in the PATENTS file in the same directory.
|
2015-02-20 04:10:52 +00:00
|
|
|
*
|
|
|
|
* @providesModule MessageQueue
|
2016-09-23 18:12:51 +00:00
|
|
|
* @flow
|
2017-07-31 13:09:54 +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
|
|
|
/*eslint no-bitwise: 0*/
|
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-07-31 13:09:54 +00:00
|
|
|
method: string | number,
|
|
|
|
isSync: boolean,
|
|
|
|
successCbId: number,
|
|
|
|
failCbId: number,
|
|
|
|
args: Array<any>,
|
|
|
|
returnValue?: any,
|
|
|
|
};
|
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
|
|
|
|
2016-08-04 15:38:49 +00:00
|
|
|
const TRACE_TAG_REACT_APPS = 1 << 17;
|
2015-07-09 16:12:53 +00:00
|
|
|
|
2017-07-31 13:09:54 +00:00
|
|
|
const DEBUG_INFO_LIMIT = 64;
|
2016-08-27 01:44:07 +00:00
|
|
|
|
2017-06-22 16:46:28 +00:00
|
|
|
// Work around an initialization order issue
|
|
|
|
let JSTimers = null;
|
|
|
|
|
2016-05-06 11:13:30 +00:00
|
|
|
class MessageQueue {
|
2017-07-31 13:09:54 +00:00
|
|
|
_lazyCallableModules: {[key: string]: (void) => Object};
|
2016-09-23 18:12:54 +00:00
|
|
|
_queue: [Array<number>, Array<number>, Array<any>, number];
|
2017-04-28 10:47:19 +00:00
|
|
|
_successCallbacks: Array<?Function>;
|
|
|
|
_failureCallbacks: Array<?Function>;
|
2016-09-23 18:12:51 +00:00
|
|
|
_callID: number;
|
2017-03-28 14:11:45 +00:00
|
|
|
_inCall: number;
|
2016-09-23 18:12:51 +00:00
|
|
|
_lastFlush: number;
|
|
|
|
_eventLoopStartTime: number;
|
|
|
|
|
|
|
|
_debugInfo: Object;
|
|
|
|
_remoteModuleTable: Object;
|
|
|
|
_remoteMethodTable: Object;
|
|
|
|
|
|
|
|
__spy: ?(data: SpyData) => void;
|
|
|
|
|
2016-09-23 18:12:54 +00:00
|
|
|
constructor() {
|
2017-06-06 14:03:10 +00:00
|
|
|
this._lazyCallableModules = {};
|
2016-01-04 10:15:19 +00:00
|
|
|
this._queue = [[], [], [], 0];
|
2017-04-28 10:47:19 +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();
|
[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 = {};
|
|
|
|
}
|
[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-07-31 13:09:54 +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-07-31 13:09:54 +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-07-31 13:09:54 +00:00
|
|
|
callFunctionReturnFlushedQueue = (
|
|
|
|
module: string,
|
|
|
|
method: string,
|
|
|
|
args: Array<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-07-31 13:09:54 +00:00
|
|
|
};
|
2015-02-20 04:10:52 +00:00
|
|
|
|
2017-07-31 13:09:54 +00:00
|
|
|
callFunctionReturnResultAndFlushedQueue = (
|
|
|
|
module: string,
|
|
|
|
method: string,
|
|
|
|
args: Array<any>,
|
|
|
|
) => {
|
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-07-31 13:09:54 +00:00
|
|
|
};
|
2016-07-18 14:12:19 +00:00
|
|
|
|
2017-07-31 13:09:54 +00:00
|
|
|
invokeCallbackAndReturnFlushedQueue = (cbID: number, args: Array<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-07-31 13:09:54 +00:00
|
|
|
};
|
2015-02-20 04:10:52 +00:00
|
|
|
|
2017-07-31 13:09:54 +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-07-31 13:09:54 +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-07-31 13:09:54 +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-07-31 13:09:54 +00:00
|
|
|
enqueueNativeCall(
|
|
|
|
moduleID: number,
|
|
|
|
methodID: number,
|
|
|
|
params: Array<any>,
|
|
|
|
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)
|
|
|
|
onFail && params.push(this._callID << 1);
|
|
|
|
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-07-31 13:09:54 +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__) {
|
|
|
|
// Any params sent over the bridge should be encodable as JSON
|
|
|
|
JSON.stringify(params);
|
|
|
|
|
|
|
|
// The params object should not be mutated after being queued
|
2017-07-31 13:09:54 +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-07-31 13:09:54 +00:00
|
|
|
if (
|
|
|
|
global.nativeFlushQueueImmediate &&
|
|
|
|
(now - this._lastFlush >= MIN_TIME_BETWEEN_FLUSHES_MS ||
|
|
|
|
this._inCall === 0)
|
|
|
|
) {
|
2017-03-31 07:46:14 +00:00
|
|
|
var 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-07-31 13:09:54 +00:00
|
|
|
|
|
|
|
if (this.__spy) {
|
|
|
|
this.__spyNativeCall(moduleID, methodID, params, {
|
|
|
|
failCbId: onFail ? params[params.length - 2] : -1,
|
|
|
|
successCbId: onSucc ? params[params.length - 1] : -1,
|
|
|
|
});
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
callSyncHook(moduleID: number, methodID: number, args: Array<any>) {
|
|
|
|
if (__DEV__) {
|
|
|
|
invariant(
|
|
|
|
global.nativeCallSyncHook,
|
|
|
|
'Calling synchronous methods on native ' +
|
|
|
|
'modules is not supported in Chrome.\n\n Consider providing alternative ' +
|
|
|
|
'methods to expose this method in debug mode, e.g. by exposing constants ' +
|
|
|
|
'ahead-of-time.',
|
2017-02-07 01:39:15 +00:00
|
|
|
);
|
2015-07-13 16:37:05 +00:00
|
|
|
}
|
2017-07-31 13:09:54 +00:00
|
|
|
const returnValue = global.nativeCallSyncHook(moduleID, methodID, args);
|
|
|
|
if (this.__spy) {
|
|
|
|
this.__spyNativeCall(moduleID, methodID, args, {
|
|
|
|
isSync: true,
|
|
|
|
returnValue,
|
|
|
|
});
|
|
|
|
}
|
|
|
|
return returnValue;
|
[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
|
|
|
|
2016-09-23 18:12:54 +00:00
|
|
|
createDebugLookup(moduleID: number, name: string, methods: Array<string>) {
|
|
|
|
if (__DEV__) {
|
|
|
|
this._remoteModuleTable[moduleID] = name;
|
|
|
|
this._remoteMethodTable[moduleID] = methods;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2017-03-28 14:11:45 +00:00
|
|
|
* Private methods
|
2016-09-23 18:12:54 +00:00
|
|
|
*/
|
|
|
|
|
2017-03-28 14:11:45 +00:00
|
|
|
__guard(fn: () => void) {
|
|
|
|
this._inCall++;
|
|
|
|
try {
|
|
|
|
fn();
|
|
|
|
} catch (error) {
|
|
|
|
ErrorUtils.reportFatalError(error);
|
|
|
|
} finally {
|
|
|
|
this._inCall--;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-09-23 18:12:54 +00:00
|
|
|
__callImmediates() {
|
2017-06-22 16:46:28 +00:00
|
|
|
Systrace.beginEvent('JSTimers.callImmediates()');
|
|
|
|
if (!JSTimers) {
|
|
|
|
JSTimers = require('JSTimers');
|
|
|
|
}
|
|
|
|
JSTimers.callImmediates();
|
2016-09-23 18:12:54 +00:00
|
|
|
Systrace.endEvent();
|
|
|
|
}
|
|
|
|
|
2016-09-23 18:12:51 +00:00
|
|
|
__callFunction(module: string, method: string, args: Array<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;
|
2015-12-16 10:12:33 +00:00
|
|
|
Systrace.beginEvent(`${module}.${method}()`);
|
2017-02-07 01:39:15 +00:00
|
|
|
if (this.__spy) {
|
2017-07-31 13:09:54 +00:00
|
|
|
this.__spyJSCall(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-07-31 13:09:54 +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-07-31 13:09:54 +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
|
|
|
|
2016-09-23 18:12:51 +00:00
|
|
|
__invokeCallback(cbID: number, args: Array<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.
|
|
|
|
const callID = cbID >>> 1;
|
2017-07-31 13:09:54 +00:00
|
|
|
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-07-31 13:09:54 +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-07-31 13:09:54 +00:00
|
|
|
invariant(callback, errorMessage);
|
2016-06-15 14:50:20 +00:00
|
|
|
}
|
2017-07-31 13:09:54 +00:00
|
|
|
const profileName = debug
|
|
|
|
? '<callback for ' + module + '.' + method + '>'
|
|
|
|
: cbID + '';
|
|
|
|
if (this.__spy) {
|
|
|
|
this.__spyJSCall(null, profileName, args, {
|
|
|
|
failCbId: isSuccess ? -1 : cbID,
|
|
|
|
successCbId: isSuccess ? cbID : -1,
|
|
|
|
});
|
2016-06-15 14:50:20 +00:00
|
|
|
}
|
|
|
|
Systrace.beginEvent(
|
2017-07-31 13:09:54 +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;
|
|
|
|
}
|
|
|
|
|
|
|
|
this._successCallbacks[callID] = this._failureCallbacks[callID] = 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
|
|
|
callback.apply(null, 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
|
|
|
}
|
2017-07-31 13:09:54 +00:00
|
|
|
|
|
|
|
__spyJSCall(
|
|
|
|
module: ?string,
|
|
|
|
method: string,
|
|
|
|
methodArgs: Array<any>,
|
|
|
|
params: any,
|
|
|
|
) {
|
|
|
|
if (!this.__spy) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
this.__spy({
|
|
|
|
type: TO_JS,
|
|
|
|
isSync: false,
|
|
|
|
module,
|
|
|
|
method,
|
|
|
|
failCbId: -1,
|
|
|
|
successCbId: -1,
|
|
|
|
args: methodArgs,
|
|
|
|
...params,
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
__spyNativeCall(
|
|
|
|
moduleID: number,
|
|
|
|
methodID: number,
|
|
|
|
methodArgs: Array<any>,
|
|
|
|
params: any,
|
|
|
|
) {
|
|
|
|
const spy = this.__spy;
|
|
|
|
if (!spy) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
let moduleName = moduleID + '';
|
|
|
|
let methodName = methodID;
|
|
|
|
if (__DEV__ && isFinite(moduleID)) {
|
|
|
|
moduleName = this._remoteModuleTable[moduleID];
|
|
|
|
methodName = this._remoteMethodTable[moduleID][methodID];
|
|
|
|
}
|
|
|
|
|
|
|
|
spy({
|
|
|
|
type: TO_NATIVE,
|
|
|
|
isSync: false,
|
|
|
|
module: moduleName,
|
|
|
|
method: methodName,
|
|
|
|
failCbId: -1,
|
|
|
|
successCbId: -1,
|
|
|
|
args: methodArgs,
|
|
|
|
...params,
|
|
|
|
});
|
|
|
|
}
|
[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;
|