Шаг 1: Создайте UserModel.js
class UserModel {
constructor() {
stateName,
username,
email,
mobile,
gender,
address;
}
}
Примечание. Не экспортируйте его, если не хотите устанавливать глобально.
Шаг 2: Screen1.js - установить UserModel и перейти с экрана 1.
_handlePress = async () => {
UserModel.username = "Vishal Patoliya"
this.props.navigation.navigate('UserList',{userData: UserModel});
}
Шаг 3: Получение класса модели на другом экране.
render() {
console.log(TAG, "render() Called.")
const UserModel = this.props.navigation.getParam('userData');
console.log("Username", UserModel.username)
}
OutPut:
01-16 17:30:32.085 4541 5638 I ReactNativeJS: 'Username', 'Vishal Patoliya'
Действительно это о Вашем выборе в алгоритмах. Обычно нет никакой "серебряной пули" для оптимизации.
Например, использование a StringBuilder
вместо конкатенации может сделать Ваш код значительно быстрее, но существует компромисс. Если Вы не связываете огромные наборы строк, памяти и время, она берет для инициализации StringBuilder
хуже, чем просто использование регулярной конкатенации. Существует много примеров этого всюду по платформе, таких как словарь, кэширующийся, как Вы упомянули в своем вопросе.
Единственная общая оптимизация можно действительно учиться и обратиться кодированию в течение дня, хит производительности из упаковки/распаковывания ("куча" по сравнению со стеком). Чтобы сделать это, необходимо изучить то, о чем это и как избежать, или уменьшить потребность сделать это.
Документация MSDN Microsoft имеет 2 статьи о производительности, которые дают много хороших методов общего назначения для использования (они - действительно просто различные версии той же статьи).
Существуют часто проблемы с алгоритмами также, обычно когда что-то дорогое сделано в цикле. Обычно первая вещь, которую Вы делаете, представить Ваше приложение, которое скажет Вам самую медленную часть (части) приложения. Обычно то, что Вы делаете для ускорения приложения, зависит от того, что Вы находите. Например, если Ваше приложение подражает файловой системе, может случиться так вызовом базы данных рекурсивно для перемещения дерева (например). Можно оптимизировать тот случай путем изменения тех рекурсивных вызовов в один сглаженный вызов базы данных, который возвращает все данные в одном вызове.
Снова, ответ, как всегда, 'он зависит'. Однако больше примеров и совета могут быть найдены в блоге Rico Mariani (обзор назад несколько лет, поскольку его акцент перенесся):
В целом удостоверьтесь, что Вы понимаете временную сложность различных алгоритмов и используете то знание для выбора реализаций мудро.
Для.NET в частности, эта статья вдается в большие подробности об оптимизации кода, развернутого на CLR (хотя это также важно для Java или любой другой современной платформы), и одно из лучших руководств, которые я когда-либо читал:
http://msdn.microsoft.com/en-us/library/ms973852.aspx
Дистиллировать статью в одно предложение: Ничто не влияет на скорость приложения.NET (с разумными алгоритмами) больше, чем объем потребляемой памяти его объектов. Очень старайтесь минимизировать свое потребление памяти.
Зависит от большого количества вещей, действительно.
Как пример, когда память становится проблемой и большим количеством временных объектов, создаются, я склонен использовать пулы объектов. (Наличие сборщика мусора не является причиной не заботиться о выделении памяти). Если скорость - то, что имеет значение затем, что я мог бы использовать небезопасные указатели для работы с массивами.
Так или иначе, если Вы боретесь слишком много с методами оптимизации в c#/.net приложении, Вы, вероятно, выбрали неправильный язык/платформу.
Я рекомендовал бы Эффективный C# Bill Wagner (первый выпуск и второй выпуск). Он проходит много конструкций языка и методов и объясняет, которые быстрее и почему. Он затрагивает много лучших практик также.
Как правило, однако, оптимизация Вашего алгоритма даст Вам намного лучшие результаты, чем использование любого вида языка / метод оптимизации.