React-native: تعطل التطبيق على نظام التشغيل Android OS 6 Samsung Galaxy S7 SM-G930FD (JSC Crash) دعم 64 بت A / libc: إشارة قاتلة 11 (SIGSEGV)
تقرير الشوائب
تحطمت عند الإطلاق
تحطمت فقط مع سجل الأخطاء هذا الذي تم تتبعه على android logcat A / libc: إشارة فادحة 11 (SIGSEGV) ، الرمز 1 ، عنوان الخطأ 0x0 في tid 20217.
لإعادة إنتاج
رد فعل أصلي تشغيل الروبوت
وانتقل إلى الشاشة الثانية من المسار الأولي من خلال ملاح المكدس. أنا أستخدم React-Navigation 3.6
يتعطل التطبيق بمجرد أن أبدأ في الدخول إلى react-navigation وتعطل جهاز Samsung S7 64 bit CPU ، يعمل بشكل جيد في أجهزة Android الأخرى التي أستخدمها.
سلوك متوقع
فقط للعمل بطريقة مستقرة. كما هو الحال في الإصدار الأصلي المتفاعل 0.58
بيئة
تفاعل معلومات البيئة الأصلية:
النظام:
نظام التشغيل: Mac OS mojave 10.14
الثنائيات:
npm: 6.4.1
ستوديو أندرويد: الإصدار 3.2.1
Android 6.0.1 (الجهاز الحقيقي: Samsung S7 SM-G930FD)
رد الفعل الأصلي v0.59.3
الحل المؤقت:
عندما أزلت فلاتر ndk
أنه يعمل بشكل جيد.
ndk {
abiFilters "armeabi-v7a", "x86", "arm64-v8a", "x86_64" -> change to
abiFilters "armeabi-v7a", "x86"
}
dishantwalia
ال 190 كومينتر
شكرا لتقديم مشكلتك. هل يمكنك إلقاء نظرة أخرى على الوصف الخاص بك والتأكد من ملء نموذج المشكلة بالكامل؟
👉 انقر هنا إذا كنت تريد إلقاء نظرة أخرى على نموذج تقرير الأخطاء.
react-native-bot
في ٢ أبريل ٢٠١٩
شكرا لتقديم مشكلتك. هل يمكنك إلقاء نظرة أخرى على الوصف الخاص بك والتأكد من ملء نموذج المشكلة بالكامل؟
👉 انقر هنا إذا كنت تريد إلقاء نظرة أخرى على نموذج تقرير الأخطاء.
محدث
dishantwalia
في ٣ أبريل ٢٠١٩
لقطة شاشة خطأ Logcat للرجوع إليها
dishantwalia
في ٣ أبريل ٢٠١٩
نشر إصدار 64 بت مقسم ، كما أنني أتلقى هذا الانهيار عند الإطلاق على Galaxy S7 و Galaxy S7 Edge مع Android 7.0
تظهر مؤشرات android الحيوية:
الإشارة 11 (SIGSEGV) ، الكود 1 (SEGV_MAPERR) WTFCrash
backtrace:
# 00 جهاز كمبيوتر 00000000007e048c /data/app/com.mosko.bus-1/lib/arm64/libjsc.so (WTFCrash + 16)
# 01 جهاز كمبيوتر 00000000000be650 /data/app/com.mosko.bus-1/lib/arm64/libjsc.so (_Z16WTFCrashWithInfoiPKcS0_i + 24)
# 02 جهاز كمبيوتر 0000000000489f2c /data/app/com.mosko.bus-1/lib/arm64/libjsc.so (OperationLinkDirectCall + 1120)
# 03 جهاز كمبيوتر 000000000019e27c
على Crashlytics لتلك الأجهزة التي أحصل عليها:
استثناء فادح: com.facebook.react.common.c
انتهاك ثابت: استئناف العمل لم يتم تنفيذه بعد.
الحل البديل لتقديم إصدار 32 بت فقط هو حل هذه المشكلة في الوقت الحالي
nadavmos
في ٧ أبريل ٢٠١٩
أرى نفس الأخطاء تمامًا مثل nadavmos على Galaxy S7 الذي يعمل بنظام Android 7.0. التطبيق يتعطل عند بدء التشغيل
nsantacruz
في ٨ أبريل ٢٠١٩
أرى نفس الأخطاء تمامًا مثل nadavmos على Galaxy S7 الذي يعمل بنظام Android 7.0. التطبيق يتعطل عند بدء التشغيل
nsantacruz هل تستخدم أيضًا رد الفعل والملاحة؟ تبدو شائعة لجميع المراسلين الآخرين
nadavmos
في ٨ أبريل ٢٠١٩
nadavmos ، أنا لا أستخدم react-navigation . ربما تكون هذه المشكلة نفسها مثل # 24260 لأن هذه المشكلة تؤثر أيضًا على 0.59 مع Samsung S7 على Android 7.0
nsantacruz
في ٨ أبريل ٢٠١٩
nadavmos لا يتعلق العطل بـ react-navigation ، في الواقع ، التطبيق يتعطل في مشروع RN جديد تم إنشاؤه عبر init-native init.
ishantsagar
في ٨ أبريل ٢٠١٩
hramosmkonicek اعتبارا من الآن يمكننا أن نستنتج أن هذا يبدو أن مشكلة مع أحدث RN 0.59 الإفراج، مما يؤثر على الروبوت يبني تعمل على Samsung S7 ، S7 Edge بعد أن قدمت دعما ل arm64-v8a ، x86_64 ، إزالتها من build.gradle لا تؤدي إلى تعطل التطبيق ، مما قد يؤثر على تشغيل التطبيقات بعد 1 August 2019 وفقًا لسياسة دعم Google Play 64 بت. نود يا رفاق لفت بعض الانتباه إليه ، من فضلك؟
ishantsagar
في ٩ أبريل ٢٠١٩
يحدث أيضًا في 0.58.5. جالكسي S7. أندرويد 6.0. لا يعمل أيضًا تعيينه على إصدار 32 بت.
Merikw
في ١١ أبريل ٢٠١٩
نلاحظ نفس الأعطال على إصدارات 64 بت من RN 0.59.4 على Galaxy S7 الذي يعمل بنظام Android 7.0. للأسف لا يمكننا الوصول إلى هذا الطراز من الجهاز. إنه يعمل بشكل جيد على كل منا.
wbercx
في ١٥ أبريل ٢٠١٩
مواجهة نفس المشكلة مع جهاز Huawai P9 في ظل البيئة التالية:
React Native Environment Info:
System:
OS: macOS 10.14.3
CPU: (12) x64 Intel(R) Core(TM) i9-8950HK CPU @ 2.90GHz
Memory: 63.57 MB / 32.00 GB
Shell: 5.3 - /bin/zsh
Binaries:
Node: 11.3.0 - /usr/local/bin/node
Yarn: 1.12.3 - /usr/local/bin/yarn
npm: 6.9.0 - /usr/local/bin/npm
Watchman: 4.9.0 - /usr/local/bin/watchman
SDKs:
iOS SDK:
Platforms: iOS 12.2, macOS 10.14, tvOS 12.2, watchOS 5.2
Android SDK:
API Levels: 23, 26, 27, 28
Build Tools: 23.0.1, 25.0.0, 26.0.3, 27.0.3, 28.0.1, 28.0.2, 28.0.3
System Images: android-24 | Google APIs Intel x86 Atom, android-27 | Google APIs Intel x86 Atom, android-28 | Google APIs Intel x86 Atom
IDEs:
Android Studio: 3.2 AI-181.5540.7.32.5056338
Xcode: 10.2/10E125 - /usr/bin/xcodebuild
npmPackages:
react: ^16.8.3 => 16.8.3
react-native: ^0.59.4 => 0.59.4
npmGlobalPackages:
eslint-plugin-react-native: 3.5.0
react-native-cli: 2.0.1
react-native-git-upgrade: 0.2.7
هذا هو تتبع مكدس Crashlytics الذي نحصل عليه:
# Platform: android
# Issue ID: 5beec130f8b88c29632f185d
# Session ID: 5cb483b90037000127d26eeee3e996f5_DNE_0_v2
# Date: 2019-04-15T13:15:00Z
# OS Version: 7.0
# Device: PRA-LX1
# RAM Free: 1.3%
# Disk Free: 14.3%
#0. Crashed: Thread
0 (Missing) 0xc00d9b20 (Missing)
1 (Missing) 0x3ffffffd (Missing)
2 libc.so 0xeda60d64 (Missing)
3 (Missing) 0x3fdec95c (Missing)
4 libc.so 0xeda3223f (Missing)
5 libutils.so 0xee283df1 (Missing)
6 (Missing) 0xea6ac55a (Missing)
7 libart.so 0xebc85331 (Missing)
8 (Missing) 0x12dfd11e (Missing)
9 (Missing) 0x12da927e (Missing)
10 system@[email protected] 0x74d6de0d (Missing)
11 (Missing) 0x3fdec95c (Missing)
12 (Missing) 0x12f39976 (Missing)
13 (Missing) 0x12c2064e (Missing)
14 (Missing) 0x70e43ada (Missing)
15 (Missing) 0x12f43b8e (Missing)
16 libart.so 0xebc85331 (Missing)
17 (Missing) 0x70d268be (Missing)
18 system@[email protected] 0x716279db (Missing)
19 (Missing) 0x70837262 (Missing)
20 (Missing) 0x70190306 (Missing)
21 (Missing) 0x2cb6ab0c (Missing)
22 (Missing) 0x70d58d82 (Missing)
23 (Missing) 0x2cb6ab0c (Missing)
24 (Missing) 0x2cb6ab0c (Missing)
25 (Missing) 0x70c63cee (Missing)
26 (Missing) 0x12c2064e (Missing)
27 (Missing) 0x70e43ada (Missing)
28 (Missing) 0x12f43c1e (Missing)
29 libart.so 0xebca3526 (Missing)
30 (Missing) 0x3fdec95c (Missing)
31 (Missing) 0x70e43ada (Missing)
32 (Missing) 0x70e43ada (Missing)
33 (Missing) 0x12f39976 (Missing)
34 (Missing) 0x12f43b8e (Missing)
35 libart.so 0xebc85331 (Missing)
36 (Missing) 0x70d268e2 (Missing)
37 (Missing) 0x3fdec95c (Missing)
38 libutils.so 0xee283ced (Missing)
39 (Missing) 0x70abe4f6 (Missing)
40 (Missing) 0x70aadb2e (Missing)
41 libandroid_runtime.so 0xecdb23ff (Missing)
42 (Missing) 0x70abe4f6 (Missing)
43 (Missing) 0x12c2fa8e (Missing)
44 system@[email protected] 0x749d1865 (Missing)
45 (Missing) 0x12c2fa8e (Missing)
46 system@[email protected] 0x741f0347 (Missing)
47 (Missing) 0x70d3b9ca (Missing)
48 (Missing) 0x12c2fa8e (Missing)
49 (Missing) 0x12c2fa8e (Missing)
50 (Missing) 0x70abe4f6 (Missing)
51 (Missing) 0x70aadb2e (Missing)
--
#0. Crashed: Thread
0 (Missing) 0xc00d9b20 (Missing)
1 (Missing) 0x3ffffffd (Missing)
2 libc.so 0xeda60d64 (Missing)
3 (Missing) 0x3fdec95c (Missing)
4 libc.so 0xeda3223f (Missing)
5 libutils.so 0xee283df1 (Missing)
6 (Missing) 0xea6ac55a (Missing)
7 libart.so 0xebc85331 (Missing)
8 (Missing) 0x12dfd11e (Missing)
9 (Missing) 0x12da927e (Missing)
10 system@[email protected] 0x74d6de0d (Missing)
11 (Missing) 0x3fdec95c (Missing)
12 (Missing) 0x12f39976 (Missing)
13 (Missing) 0x12c2064e (Missing)
14 (Missing) 0x70e43ada (Missing)
15 (Missing) 0x12f43b8e (Missing)
16 libart.so 0xebc85331 (Missing)
17 (Missing) 0x70d268be (Missing)
18 system@[email protected] 0x716279db (Missing)
19 (Missing) 0x70837262 (Missing)
20 (Missing) 0x70190306 (Missing)
21 (Missing) 0x2cb6ab0c (Missing)
22 (Missing) 0x70d58d82 (Missing)
23 (Missing) 0x2cb6ab0c (Missing)
24 (Missing) 0x2cb6ab0c (Missing)
25 (Missing) 0x70c63cee (Missing)
26 (Missing) 0x12c2064e (Missing)
27 (Missing) 0x70e43ada (Missing)
28 (Missing) 0x12f43c1e (Missing)
29 libart.so 0xebca3526 (Missing)
30 (Missing) 0x3fdec95c (Missing)
31 (Missing) 0x70e43ada (Missing)
32 (Missing) 0x70e43ada (Missing)
33 (Missing) 0x12f39976 (Missing)
34 (Missing) 0x12f43b8e (Missing)
35 libart.so 0xebc85331 (Missing)
36 (Missing) 0x70d268e2 (Missing)
37 (Missing) 0x3fdec95c (Missing)
38 libutils.so 0xee283ced (Missing)
39 (Missing) 0x70abe4f6 (Missing)
40 (Missing) 0x70aadb2e (Missing)
41 libandroid_runtime.so 0xecdb23ff (Missing)
42 (Missing) 0x70abe4f6 (Missing)
43 (Missing) 0x12c2fa8e (Missing)
44 system@[email protected] 0x749d1865 (Missing)
45 (Missing) 0x12c2fa8e (Missing)
46 system@[email protected] 0x741f0347 (Missing)
47 (Missing) 0x70d3b9ca (Missing)
48 (Missing) 0x12c2fa8e (Missing)
49 (Missing) 0x12c2fa8e (Missing)
50 (Missing) 0x70abe4f6 (Missing)
51 (Missing) 0x70aadb2e (Missing)
taschik
في ١٥ أبريل ٢٠١٩
تواجه نفس المشكلة مع Samsung Galaxy S7 ، على Android 7
ASSERT|04-17 00:30:16.272|18763|18813||libc|Fatal signal 11 (SIGSEGV), code 1, fault addr 0xbbadbeef in tid 18813 (mqt_js)
ASSERT|04-17 00:30:16.402|18920|18920||DEBUG|Build fingerprint: 'samsung/heroltexx/herolte:7.0/NRD90M/G930FXXS1DQHF:user/release-keys'
ASSERT|04-17 00:30:16.402|18920|18920||DEBUG|*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
ASSERT|04-17 00:30:16.405|18920|18920||DEBUG|ABI: 'arm64'
ASSERT|04-17 00:30:16.405|18920|18920||DEBUG|Revision: '8'
ASSERT|04-17 00:30:16.406|18920|18920||DEBUG|pid: 18763, tid: 18813, name: mqt_js >>> com.profibackoffice.reactnative <<<
ASSERT|04-17 00:30:16.406|18920|18920||DEBUG|signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xbbadbeef
ASSERT|04-17 00:30:16.407|18920|18920||DEBUG| x16 00000070110b1acc x17 000000700bc121a8 x18 0000000021ecfc88 x19 000000700fed7e80
ASSERT|04-17 00:30:16.407|18920|18920||DEBUG| x20 00000070108cf560 x21 0000006ffd4c8070 x22 000000700bc00000 x23 0000006ff9616ca0
ASSERT|04-17 00:30:16.407|18920|18920||DEBUG| x28 ffff000000000002 x29 00000070108cf560 x30 0000007011408484
ASSERT|04-17 00:30:16.407|18920|18920||DEBUG| x24 0000000000000007 x25 0000000000000000 x26 0000000000000000 x27 ffff000000000000
ASSERT|04-17 00:30:16.407|18920|18920||DEBUG| x8 00000000bbadbeef x9 00000070114b19d0 x10 0000000000000000 x11 0000006ffc4f0000
ASSERT|04-17 00:30:16.407|18920|18920||DEBUG| x0 00000070108cf3c8 x1 00000070108cf3c8 x2 0000000000000000 x3 00000000000000a8
ASSERT|04-17 00:30:16.407|18920|18920||DEBUG| sp 00000070108cf400 pc 000000701140848c pstate 00000000a0000000
ASSERT|04-17 00:30:16.407|18920|18920||DEBUG| x4 000000700bfaee80 x5 0000006ff62a4980 x6 0000006ffa6a6820 x7 0000000000000000
ASSERT|04-17 00:30:16.407|18920|18920||DEBUG| x12 0000000000000000 x13 000000700b617c00 x14 0000000000000002 x15 00000000bd36143d
ASSERT|04-17 00:30:16.412|18920|18920||DEBUG|backtrace:
ASSERT|04-17 00:30:16.412|18920|18920||DEBUG| #03 pc 00000000001afe80 <anonymous:000000700bdff000>
ASSERT|04-17 00:30:16.412|18920|18920||DEBUG| #02 pc 0000000000489f2c /data/app/com.profibackoffice.reactnative-1/lib/arm64/libjsc.so (operationLinkDirectCall+1120)
ASSERT|04-17 00:30:16.412|18920|18920||DEBUG| #01 pc 00000000000be650 /data/app/com.profibackoffice.reactnative-1/lib/arm64/libjsc.so (_Z16WTFCrashWithInfoiPKcS0_i+24)
ASSERT|04-17 00:30:16.412|18920|18920||DEBUG| #00 pc 00000000007e048c /data/app/com.profibackoffice.reactnative-1/lib/arm64/libjsc.so (WTFCrash+16)
gpetrosyan
في ١٦ أبريل ٢٠١٩
~ قد تؤدي إضافة هذا إلى android/app/build.gradle ~ إلى إصلاحه ~ (لم يحدث): ~
packagingOptions {
pickFirst '**/libjsc.so'
pickFirst '**/libc++_shared.so'
}
~ انظر https://github.com/react-native-community/jsc-android-buildscripts/pull/95~
AndrewJack
في ١٦ أبريل ٢٠١٩
شكرا لمحاولتك المساعدة ولكن الحل لم يساعدنا.
16 апр. 2019 г.، в 19:12، Andrew Jack [email protected] написал (а):
قد تؤدي إضافة هذا إلى android / app / build.gradle إلى إصلاحه:
التعبئة والتغليف خيارات {
pickFirst " /libjsc.so"pickFirst " /libc++_shared.so"
}
راجع رد فعل المجتمع الأصلي / jsc-android-buildscripts # 95 https://github.com/react-native-community/jsc-android-buildscripts/pull/95
اختبار هذا الآن.-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو قم بعرضها على GitHub https://github.com/facebook/react-native/issues/24261#issuecomment-483728028 ، أو تجاهل الموضوع https://github.com/notifications/unsubscribe-auth/ AEO_1BMzddSncn2DtQeDcx_y1KIz0ZSGks5vhfaJgaJpZM4cX_xB .
gpetrosyan
في ١٦ أبريل ٢٠١٩
قد تؤدي إضافة هذا إلى
android/app/build.gradleإلى إصلاحه:packagingOptions { pickFirst '**/libjsc.so' pickFirst '**/libc++_shared.so' }راجع رد فعل المجتمع الأصلي / jsc-android-buildscripts # 95
أنا أختبر هذا الآن.
AndrewJack هل كان يعمل من أجلك؟
taschik
في ١٦ أبريل ٢٠١٩
قد تؤدي إضافة هذا إلى
android/app/build.gradleإلى إصلاحه:packagingOptions { pickFirst '**/libjsc.so' pickFirst '**/libc++_shared.so' }راجع رد فعل المجتمع الأصلي / jsc-android-buildscripts # 95
أنا أختبر هذا الآن.
للأسف كان لدينا بالفعل هؤلاء هناك.
لقد سحبنا تصميمات 64 بت الخاصة بنا من متجر Play. قد لا يكون هذا مرتبطًا على الإطلاق بالتعطل الذي حدث في إصدار 64 بت ، ولكن أجهزة Galaxy S7 التي تعمل بنظام armeabi-v7a تتعطل الآن كثيرًا وفقًا لما هو مذكور أدناه. فور بدء التشغيل.
أتساءل حقًا ما هو الاختلاف في S7 مقارنة بالأجهزة الأخرى.
Version Code: 10000036
Version Name: 2.3.4
Android: 8.0.0
Android Build: R16NW
Manufacturer: samsung
Model: SM-G930F
Date: undefined
com.facebook.react.bridge.UnexpectedNativeTypeException: TypeError: expected dynamic type `double', but had type `null'
at com.facebook.react.bridge.ReadableNativeMap.getIntNative
at com.facebook.react.bridge.ReadableNativeMap.getInt
at com.facebook.react.g.a.a
at com.facebook.react.modules.core.ExceptionsManagerModule.reportSoftException
at java.lang.reflect.Method.invoke(Method.java:-2)
at com.facebook.react.bridge.JavaMethodWrapper.invoke
at com.facebook.react.bridge.JavaModuleWrapper.invoke
at com.facebook.react.bridge.queue.NativeRunnable.run
at android.os.Handler.handleCallback(Handler.java:789)
at android.os.Handler.dispatchMessage(Handler.java:98)
at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage
at android.os.Looper.loop(Looper.java:164)
at com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run
at java.lang.Thread.run(Thread.java:764)
taschik لم تنجح ، اعتقدت أن تصحيح تكوين jsc-android-buildscripts قد يعمل.
AndrewJack
في ١٧ أبريل ٢٠١٩
أحصل على نفس الاستثناء ولا يمكن اكتشافه بواسطة معالج استثناء غير معلوم. في تطبيق Android الخاص بي ، جربت هذا الرمز:
Thread.setDefaultUncaughtExceptionHandler(...);
باستخدام المعالج ، الذي يكتب فقط اسم الاستثناء لوحدة التحكم ثم يعيد التحكم إلى المعالج الافتراضي ، لكن هذا الرمز لم يتم تنفيذه قبل تعطل التطبيق.
كنت أحاول التحقيق في سبب عدم قيام Crashlytics بتسجيل هذه الاستثناءات. ربما يكون هذا هو السبب ... أتذكر أنني رأيت مرة أو مرتين أعطالًا أصليًا في وحدة التحكم في النسيج ، لذا فإن المتعطلات قادرة على تسجيل الأعطال الأصلية ، ولكن بطريقة ما ليس في هذه الحالة.
SpertsyanKM
في ١٨ أبريل ٢٠١٩
SpertsyanKM يحدث الانهيار على مستوى ndk. لن ترى التعطل في وحدة تحكم Firebase ، إلا إذا أضفت مكتبة Crashlytics NDK. https://docs.fabric.io/android/crashlytics/ndk.html
نظرًا لأنك وجدت Thread.setDefaultUncaughtExceptionHandler سيصطاد فقط استثناءات Java.
AndrewJack
في ١٨ أبريل ٢٠١٩
قمت بالترقية إلى RN 0.59.5 اليوم ولا يزال الانهيار يحدث. هذه المشكلة لم يتم إصلاحها بعد.
taschik
في ١٩ أبريل ٢٠١٩
مرحبًا ، جميعًا ، لدي نفس المشكلة في 0.59.5 ، قم بإزالة android: screenOrientation = "
Jeijie
في ٢٢ أبريل ٢٠١٩
Jeijie لم يكن لدي ذلك بالفعل هناك ، لكنه تحطم على أي حال.
wbercx
في ٢٢ أبريل ٢٠١٩
نفس المشكلة على REDMI NOTE 4X Android 7.0 و huawei HRY AL00A Android 9
AutomaticThread
SIGSEGV(SEGV_MAPERR)
1 #00 pc 000000000042c064 /data/app/com.example.app-gUSG17yMVBByrSNhEo7j7A==/lib/arm64/libjsc.so [arm64-v8a]
2 #01 pc 0000000000429638 /data/app/com.example.app-gUSG17yMVBByrSNhEo7j7A==/lib/arm64/libjsc.so [arm64-v8a]
3 #02 pc 0000000000429d28 /data/app/com.example.app-gUSG17yMVBByrSNhEo7j7A==/lib/arm64/libjsc.so [arm64-v8a]
4 #03 pc 000000000041664c /data/app/com.example.app-gUSG17yMVBByrSNhEo7j7A==/lib/arm64/libjsc.so [arm64-v8a]
5 #04 pc 00000000007ea4cc /data/app/com.example.app-gUSG17yMVBByrSNhEo7j7A==/lib/arm64/libjsc.so [arm64-v8a]
6 #05 pc 00000000007eabcc /data/app/com.example.app-gUSG17yMVBByrSNhEo7j7A==/lib/arm64/libjsc.so [arm64-v8a]
7 #06 pc 00000000007e0fec /data/app/com.example.app-gUSG17yMVBByrSNhEo7j7A==/lib/arm64/libjsc.so [arm64-v8a]
8 #07 pc 00000000007ee4fc /data/app/com.example.app-gUSG17yMVBByrSNhEo7j7A==/lib/arm64/libjsc.so [arm64-v8a]
9 #08 pc 00000000007ffdb8 /data/app/com.example.app-gUSG17yMVBByrSNhEo7j7A==/lib/arm64/libjsc.so [arm64-v8a]
10 #09 pc 0000000000083550 /system/lib64/libc.so (__pthread_start(void*)+36) [arm64-v8a]
11 #10 pc 00000000000241a0 /system/lib64/libc.so (__start_thread+68) [arm64-v8a]
12 java:
13 [Failed to get Java stack]
yinhangfeng
في ٢٣ أبريل ٢٠١٩
نفس المشكلة على Galaxy S7 Edge / Android 7.0 وثلاثة إصدارات مختلفة من React-Native: 0.58.4 و 0.58.5 و 0.59.5.
لم يتم اكتشاف العطل على أجهزة Android الأخرى.
الحل الوحيد لتجنب هذه المشكلة حاليًا هو إنشاء التطبيق على 32 بت فقط. ولكن يجب إصلاح المشكلة في أول أغسطس لأن متجر Play لن يقبل بعد الآن تطبيقات 32 بت فقط.
ntorion
في ٢٤ أبريل ٢٠١٩
نفس الشيء ، يقتصر على Galaxy S7 مع Android <= 7.0 (وليس 8.0). يحدث منذ أن قمنا بتمكين دعم 64 بت.
danilobuerger
في ٢٤ أبريل ٢٠١٩
اعتبارًا من التكوين الافتراضي الخاص بنا ، لا ندعم حتى 64 بت ، ومع ذلك تحدث الأعطال.
""
التكوين الافتراضي {
applicationId _applicationId
الإصدار 16
targetSdk الإصدار 27
versionCode _versionCode
versionName _versionName
ndk {
abiFilters "armeabi-v7a" ، "x86"
}
packagingOptions {
exclude "lib/arm64-v8a/libgnustl_shared.so"
}
renderscriptTargetApi 27
renderscriptSupportModeEnabled true
vectorDrawables.useSupportLibrary = true /
multiDexEnabled true
}```
مرة أخرى هنا ، لاحظت أن المشكلة تحدث مع بعض أجهزة Mediatek أيضًا
Alcatel A5 (ELSA6)
Alcatel 1x / TCL L9 (U5A_PLUS_4G)
بعض الأجهزة الأخرى التي تدعم MediaTek SoCs مع دعم x64
murilobast
في ٢٥ أبريل ٢٠١٩
مرحبا. لقد وجدنا أن:
- ~ إصلاح إزالة دعم 64 بت يعمل ~ هذا فقط أصلح المشكلة لبعض مستخدمينا
- ~ لقد طلبنا من المستخدمين حل هذه المشكلة بأنفسهم من خلال _إعادة تشغيل هواتفهم_ (لا داعي للتبديل إلى تطبيق 32 بت) ~ لم يكن لديهم نفس المشكلة.
jeremyhon
في ٢٥ أبريل ٢٠١٩
يمكنني أن أؤكد أن إزالة دعم 64 بت قلل من تقارير الأعطال بنسبة 90٪ تقريبًا
هذا يحدث مع بعض الأجهزة. لكن "الإصلاح" الحالي هو أفضل ما يمكنني فعله الآن
murilobast
في ٢٦ أبريل ٢٠١٩
أتلقى تعطلًا في OnePlus 3 أيضًا ، لكن إزالة دعم 64 بت لا يساعد. أتعرض لأعطال في مشروع init الأصلي التفاعلي (أيضًا على المحاكيات عند فتح APK للتطبيق).
quietbits
في ٢٩ أبريل ٢٠١٩
نفس المشكلة s7 edge android 7.0 تتعطل في الإنتاج مع تقسيم الحزمة ، يبدو أن البعض الآخر على ما يرام
الإشارة 11 (SIGSEGV) ، الكود 1 (SEGV_MAPERR)
backtrace:
# 00 جهاز كمبيوتر 000000000009e144
# 01 جهاز كمبيوتر 00000000000a4a70
bakir97
في ٤ مايو ٢٠١٩
تم تحديد هذه المشكلة بالفعل على webkit repo. لقد علقت هناك عندما اكتشفت هذه المشكلة منذ أشهر: https://github.com/WebPlatformForEmbedded/WPEWebKit/issues/327#issuecomment -436781890
سيكون من الرائع تنسيق الجهود.
ملاحظة: في Youi ، نستخدم RN بطريقة غير قياسية. لقد قمنا ببناء JSC 64 بت الخاص بنا ، لذلك حصلنا على هذه المشكلة في وقت سابق ، قبل 0.58.
ncuillery-youitv
في ٦ مايو ٢٠١٩
يبدو أن العوامل المشتركة هي أجهزة Android 6.0 أو 7.0 (المستوى 23 و 24) و ARM 64.
الجهاز الأكثر شيوعًا مع هذه المجموعة هو S7. تعمل ترقية S7 إلى Android 8 على إصلاح المشكلة.
لقد قمت بإعادة إنتاج التعطل في محاكي Android ARM 64 بت ، لكن صور محاكي Android ARM غير مستقرة وعربات التي تجرها الدواب للعمل معها. لدي أيضًا S7 لتصحيحه ، والذي أحاول الرجوع إلى إصدار Android 7 ، على الرغم من أن Samsung لم تجعل ذلك سهلاً.
kmagiera & kudo قمت مؤخرًا بإصدار نسخة جديدة من JSC. هل تتوقع أن يعمل هذا الإصدار على حل هذه المشكلة؟ هل ستساعد محاذاة إصدارات NDK؟ https://github.com/react-native-community/jsc-android-buildscripts/pull/95
AndrewJack
في ٧ مايو ٢٠١٩
AndrewJack الإصدار الجديد فقط من أجل تصحيحات أمان WebKit وإزالة libc ++ _ shared.so من أجل https://github.com/facebook/react-native/pull/24672. لا أعتقد أن هذه ستصلح مشكلات التعطل.
AFAIK ، هناك أنواع مختلفة من حوادث JSC.
بعضها من processLinkDirectCall حيث تم الإبلاغ عن هذه المشكلة وبعضها من NPE مثل https://github.com/react-native-community/jsc-android-buildscripts/issues/84.
معظمهم مرتبطون بـ JIT.
من الصعب إعادة إنتاج مسار تحطم JIT داخليًا ويصعب استكشاف الأخطاء وإصلاحها أيضًا.
لدي بعض الإصلاحات المحتملة ولكن لست متأكدًا مما إذا كانت ستحل مشكلة التعطل حقًا.
أحد الإصلاحات هو تعطيل DFG_JIT .
يوجد أيضًا إصلاح من عملية التشغيل ذات الصلة المنبع LinkDirectCall
أحدث JSC (WebKitGTK 2.24) يتضمن الكثير من تغييرات JIT. يستحق المحاولة إذا كانت الترقية تساعد.
IMO ، إذا لم يكن التكاثر الداخلي ممكنًا ، فإن البديل هو تقديم البناء التجريبي.
خطتي هي جعل ترقية JSC أسهل ، ببساطة yarn add jsc-android@experiment . يجب أن يحدث هذا عند RN 0.60.
باستخدام هذه الآلية ، على الأقل يمكن أن نكون خطوة للأمام لإصلاح مشكلات التعطل.
من ناحية أخرى ، قد يكون من المفيد وجود كود وبيئة إعادة إنتاج موثوقة.
على سبيل المثال ، هناك ريبو من رد فعل-أصلية-ملاحة. يساعد كثيرا.
https://github.com/react-native-community/jsc-android-buildscripts/issues/84#issue -407898908
Kudo
في ٧ مايو ٢٠١٩
يحدث التعطل أيضًا على هاتف Pixel 2 مع Android 9 ، إذا كان ذلك يساعد.
هل هناك أي طريقة للحصول على سجلات الأعطال عند تشغيل APK؟ سأكون سعيدًا بالمساعدة في الحصول على مزيد من المعلومات حول هذه الأعطال ، لكنني لا أعرف الكثير عن تطوير Android.
quietbits
في ٧ مايو ٢٠١٩
quietbits ، معظم السجلات المتعلقة بهذه المشكلات ليست مفيدة للغاية ، ولكن
ابحث عن وقت حدوث التعطل باستخدام adb logcat سيبدو شيئًا من هذا القبيل (ليس بالضبط ، لأنني استخرجت هذا للتو من أعلى السجل ، لكنه يُظهر مقتطفًا وهو سبب إشارته خارج):
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'samsung/heroqltetmo/heroqltetmo:8.0.0/R16NW/G930TUVU4CRI2:user/release-keys'
Revision: '14'
ABI: 'arm'
pid: 32435, tid: 32482, name: mqt_js >>> com.YOURAPP <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xcd
Cause: null pointer dereference
سيقول أيضًا عادةً أن السجل مكتوب على "شاهد القبر".
لإزالة علامة القبر ، استخدم adb bugreport ./MySuperSpecialBugReport مع الجزء الأخير بوضوح هو المسار الذي تريده فيه.
سيتم إيقافه كرمز مضغوط ، ويمكنك فك ضغطه ، والتنقل (على معظم الأجهزة) إلى: ./MySuperSpecialBugReport/FS/data/tombstones وبعد ذلك يمكنك فتح علامة القبر باستخدام محرر النصوص الخاص بك.
مرة أخرى ، نظرًا لطبيعة هذه الحوادث ، فهي ليست مفيدة للغاية. على الأقل مع عناويننا ، تكون عادةً مع mqt_js ، وفي عنوان مؤشر منخفض. كما أنها لا تزال تحدث (على الرغم من أنها أقل غرابة / غير متوقعة) مع ملفات 32 بت فقط.
===
@ Kudo - أتطلع بالتأكيد إلى القدرة على تجربة JSCs المختلفة بسهولة أكبر ومعرفة ما تفعله. لقد كانت هذه نقطة ألم حقيقية حتى الآن في الترقية إلى 0.59 مع أعطال فائقة غير حتمية وغير متوقعة (تحدث أيضًا على أجهزة معينة فقط ... في بعض الأحيان).
j-wang
في ٧ مايو ٢٠١٩
للحصول على backtrace الرمزي ، اعتدت الجمع بين adb logcat و ndk-stack
على سبيل المثال ، استهداف RN 059 stock JSC (وهو [email protected]) و arm64-v8a ABI.
wget https://registry.npmjs.org/jsc-android/-/jsc-android-236355.0.0.tgz
tar xf jsc-android-236355.0.0.tgz
unzip package/dist/org/webkit/android-jsc/r236355/android-jsc-r236355.aar
adb logcat | ndk-stack -sym jni/arm64-v8a/libjsc.so
أي تعديل حدث في هذه القضية؟
paulupendo
في ١٠ مايو ٢٠١٩
لا تعد إزالة 64 بت حلاً وفقًا لـ Google Play 64 bit support policy. فقد يؤثر ذلك على التطبيقات التي يتم بثها مباشرة بعد 1 August 2019 . نود أن يكون لدينا حل مناسب لهذه المشكلة. hramos أي تحديث على هذا؟ يرجى لفت الانتباه.
dishantwalia
في ١٦ مايو ٢٠١٩
مرحبًا بالجميع ، لدي نفس المشكلة في 0.59.8 ،
نود أن يكون لدينا حل مناسب لهذه المشكلة.
sikeeoh
في ١٦ مايو ٢٠١٩
مرحبا،
أنا أساعد في مشكلة تعطل JSC وأيضًا متعاون في jsc-android-buildscripts.
RN 0.59 JSC هو في الواقع من jsc-android-buildscripts .
لاستكشاف مشكلة التعطل وإصلاحها ، نحتاج إلى تعقب العطل.
نأمل ، يرجى اتباع الخطوات أدناه للحصول على backtrace والنشر هنا.
يمكنني بعد ذلك المتابعة لإيجاد حلول محتملة.
قم بتثبيت ndk-build وتنفيذ الأوامر:
wget https://registry.npmjs.org/jsc-android/-/jsc-android-236355.0.0.tgz
tar xf jsc-android-236355.0.0.tgz
unzip package/dist/org/webkit/android-jsc/r236355/android-jsc-r236355.aar
adb logcat -c
adb logcat | ndk-stack -sym jni/arm64-v8a/libjsc.so
يبدو أن الكثير من التعطل يأتي من Samsung S7. لسوء الحظ ، ليس لدي S7 في متناول اليد.
نأمل في الحصول على بعض المعلومات المفيدة لمتابعة استكشاف الأخطاء وإصلاحها.
Kudo
في ١٦ مايو ٢٠١٩
تضمين التغريدة
OtacilioN
في ١٦ مايو ٢٠١٩
Kudo هذا هو السجل الذي حصلت عليه من تشغيل هذه الأوامر في مشروع جديد على RN 0.59.8
حاولت إنشاء تصميمات تصحيح الأخطاء وإصدارها وتجميع ملفات jsc بنفسي بواسطة السجلات تبدو متشابهة في كل حالة.
********** Crash dump: **********
Build fingerprint: ‘samsung/heroltexx/herolte:7.0/NRD90M/G930FXXU1DQEL:user/release-keys’
#00 0x00000000007e048c /data/app/com.testproj-2/lib/arm64/libjsc.so (WTFCrash+16)
WTFCrash
??:0:0
#01 0x00000000000be650 /data/app/com.testproj-2/lib/arm64/libjsc.so (_Z16WTFCrashWithInfoiPKcS0_i+24)
WTFCrashWithInfo(int, char const*, char const*, int)
??:0:0
#02 0x0000000000489f2c /data/app/com.testproj-2/lib/arm64/libjsc.so (operationLinkDirectCall+1120)
operationLinkDirectCall
??:0:0
#03 0x00000000001710f0 <anonymous:00000072adbff000>
Crash dump is completed
لدي S7 في متناول اليد وسأكون سعيدًا لمحاولة تشغيل أي شيء آخر لمحاولة اكتشاف ذلك.
MalcolmScruggs
في ١٦ مايو ٢٠١٩
اقتراحي هو إعادة ترجمة JSC مع تعطيل JIT. من الممكن أن تتداخل آليات الأمان في نظام التشغيل مع JIT
عمليات بطريقة لا يمكن التنبؤ بها.
matthargett
في ١٧ مايو ٢٠١٩
لقد أعدت إنتاج نفس سجلات الأعطال مثل @ MalcolmScruggs. على S7 - Android 7.1.2 - LineageOS 14.1.
على RN 0.59.8 وأحدث إصدار من الفرع الرئيسي .
لا توجد تغييرات مطلوبة لإعادة إنتاج التعطل. يؤدي نموذج RN الافتراضي إلى حدوث عطل بعد قليل من النقر على الشاشة.
الريبو هنا - https://github.com/AndrewJack/jsc_crash/tree/rn_master_branch
توجد سجلات الأعطال في الملف README.md
الخطوات التالية: إنشاء إصدار خاص من JSC مع تعطيل JIT
إذا كان لدى أي شخص S7 على إصدار أحدث من Android ويريد الرجوع إلى إصدار أقدم. وهذا هو ما فعلته:
قم بتنزيل هذا البرنامج:
- https://twrp.me/samsung/samsunggalaxys7.html
- https://www.los-legacy.de/ v14.1 - herolte
- https://opengapps.org/
- تثبيت ريكفري TWRP (باستخدام أودين [يتطلب Windows] أو طريقة أخرى)
- التمهيد في الانتعاش
- جبل التخزين
- نسخ حزمة LineageOS rom & gapps
- تثبيت فلاش LineageOS و صور gapps
- اعادة التشغيل.
AndrewJack
في ١٧ مايو ٢٠١٩
باستخدام أحدث إصدار أصلي للتفاعل واستخدام no_dfg_jit أو no-jit من مفترق Kudo ، لا يمكنني إعادة إنتاج الانهيار.
https://github.com/AndrewJack/jsc_crash/tree/no_dfg_jit
https://github.com/AndrewJack/jsc_crash/tree/no_jit
AndrewJack
في ١٧ مايو ٢٠١٩
AndrewJack مذهل ، لقد وجدت
شكرًا لك على ملاحظاتك ومن الجيد معرفة أن هذه الإصدارات أصلحت لك العطل.
Kudo
في ١٧ مايو ٢٠١٩
الأعزاء،
لقد جربت نسختين من JSC ، يرجى المحاولة إذا كان بإمكانهما إصلاح الأعطال لك.
خطوات موجزة هنا:
https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17
أحد الإصدارات التي تم تجربتها هو تعطيل نوع واحد من JIT.
والآخر يعطل JIT تمامًا من matthargett الموصى به.
إذا كان الإصداران سيعملان على إصلاح التعطل بالنسبة لك ، فيرجى أيضًا إرسال ملاحظات إلينا على الأداء العام و TTI كما هو مذكور في جوهر بلدي.
Kudo
في ١٧ مايو ٢٠١٩
@ كودو شكرا لأولئك! ماذا تعرف عن GC المتزامن في تلك البنى؟ لقد رأيت مذكورًا في مكان ما كان هناك اختلاف آخر مقارنة بإصدار 32 بت ، لكن بالطبع لا يمكنني العثور على هذا التعليق بعد الآن. قد يكون شيء آخر يستحق اللعب مع استمرار وقوع حوادث.
wbercx
في ١٧ مايو ٢٠١٩
wbercx هل تقصد GC متزامن أو JS متزامن (JIT متزامن)؟
بشكل افتراضي ، يتم تمكين GC المتزامن فقط لـ arm64 و x64.
قد لا يتعلق GC المتزامن بمشكلة التعطل. من المحتمل أن يكون حول إدارة الكومة وليس JIT ذات الصلة.
تم تعطيل JS المتزامن لكلا البناءين.
(بشكل افتراضي ، سيتم تمكينه فقط مقابل ENABLE(DFG_JIT) && USE(JSVALUE64) )
راجع للشغل ، JIT في JavaScriptCore معقد ولست خبيرًا في ذلك.
لا تتردد في توضيح ما إذا كنت مخطئا.
Kudo
في ١٧ مايو ٢٠١٩
Kudo جربت إصدارات JSC التجريبية no-jit و no-dfg-jit ولم أتمكن من إعادة إنتاج العطل. يبدو أن هذا يتماشى مع ما ذكره AndrewJack .
كنت أحاول ذلك في مشروع أساسي لذا لا يمكنني التعليق على أي تأثير على الأداء.
MalcolmScruggs
في ١٧ مايو ٢٠١٩
لدي المزيد من المعلومات ، وأرى هذا التعطل أيضًا في:
Samsung Galaxy S7 (herolte) ، Android 7.0
Oppo F7 (CPH1819) ، Android 8.1
harryt2
في ١٨ مايو ٢٠١٩
يحدث أيضًا في 0.58.5. جالكسي S7. أندرويد 6.0. لا يعمل أيضًا تعيينه على إصدار 32 بت.
لا يزال العطل يحدث هنا أيضًا بعد العودة إلى 32 بت
harryt2
في ١٨ مايو ٢٠١٩
MalcolmScruggs جميل أن تسمع كلا الإصدارين
أفكر في تعطيل DFG_JIT ، على الأقل يتماشى خيار JIT مع JSC القديم.
Kudo
في ٢٠ مايو ٢٠١٩
Kudo هل تخطط لاستهداف DFG_JIT فقط للأجهزة / وحدات المعالجة المركزية المتأثرة؟
MalcolmScruggs
في ٢١ مايو ٢٠١٩
هل حاول شخص ما باستخدام الإصدار الأخير من React Native (0.59.8) والذي يعمل على إصلاح بعض الأعطال (المذكورة في ملاحظة الإصدار)؟
https://github.com/facebook/react-native/releases
ntorion
في ٢١ مايو ٢٠١٩
هل حاول شخص ما باستخدام الإصدار الأخير من React Native (0.59.8) والذي يعمل على إصلاح بعض الأعطال (المذكورة في ملاحظة الإصدار)؟
https://github.com/facebook/react-native/releases
في حالتي ، كنت أستخدم 0.59.8 ، ومنذ ذلك الحين عدت إلى 0.57.8 نظرًا لعدم نجاح أي شيء آخر. هذا الخطأ سيء بشكل خاص لأنه يتسبب في تعطل التطبيق فور فتحه. أخذ تطبيقي قصة شعر في المراجعات.
تحتوي هذه الأجهزة على إشارة 11 تعطلًا لكنها تظهر موقعًا في الذاكرة فقط.
جنرال موبايل GM8 Go - أندرويد 8.1
موتورولا موتو إي - أندرويد 7.1
Samsung Galaxy A6 + - أندرويد 8.0
Samsung Galaxy Grand Prime Pro - أندرويد 8.0
Samsung Galaxy Tab S2 - أندرويد 8.0
Samsung Galaxy J5 Prime - أندرويد 8.0
Samsung Galaxy J6 - أندرويد 8.0
Samsung Galaxy J7 Max - أندرويد 8.1
يبدو أن هذه الأجهزة تظهر مع وجود خطأ يشبه == / lib / arm64 / libjsc.so . لا أعرف ما يكفي عن الأعمال الداخلية لأعرف ما يعنيه ذلك ، لكن آمل أن يساعد.
هواوي Y9 - أندرويد 8.1
Oppo RMX1811 - Android 8.1
هاتف Oppo R15 - Android 8.1
موتورولا موتو اكس - اندرويد 9.0
نوكيا 3 - أندرويد 8.1
Samsung Galaxy Note9 - أندرويد 9.0
Samsung Galaxy S9 - أندرويد 9.0
هاتف Xaomi Redmi Note 5 Pro - Android 8.1
harryt2
في ٢١ مايو ٢٠١٩
يمكنني إضافة بعض الأجهزة إلى قائمة @ harryt2.
تحطم الإشارة 11 مع موقع ذاكرة فقط:
Samsung Galaxy Note 9 - أندرويد 9.0
هواوي اونور 8 اكس - اندرويد 9.0
Samsung Galaxy A7 (2018) - أندرويد 9.0
Samsung Galaxy S9 - أندرويد 9.0
Samsung Galaxy A6 + - أندرويد 9.0
نوكيا 8 - أندرويد 9.0
هواوي Huawei P30 lite - Android 9.0
Samsung Galaxy Note8 - أندرويد 9.0
Samsung Galaxy A9 - Android 8.0
Samsung Galaxy S7 - أندرويد 8.0
...
تستمر القائمة مع 65 جهازًا مختلفًا تقريبًا وإصدار Android بين 7.0 و 9.0.
لا يحدث الخطأ دائمًا على هذه الأجهزة. لكنه مصدر قلق حقيقي ، حيث تغير معدل تعطل تطبيقي المبلغ عنه في google play من 0.16٪ إلى 1.02٪ بعد التحديث من 0.57.8 إلى 0.59.5.
0.57.8:
0.59.5:
لست خبيرًا في تطوير Android ، ولا أفهم من أين يأتي هذا التعطل. يمكنني تقديم المزيد من البيانات إذا كانت تساعد.
alexkuttig
في ٢٢ مايو ٢٠١٩
ntorion في مشروعنا ما زلنا نرى هذه الأعطال على Samsung s7 مع رد فعل أصلي 0.59.8 أنا خائف.
tijs
في ٢٢ مايو ٢٠١٩
أي حل لهذا في هذه اللحظة؟
لقد اختبرت في جهازي Galaxy Note 9 مختلفين ، كل هاتف يتعطل على الفور
{"dependencies": {
"axios": "^0.18.0",
"prop-types": "^15.7.2",
"react": "16.8.3",
"react-native": "0.59.8",
"react-native-gesture-handler": "^1.2.1",
"react-native-iphone-x-helper": "^1.2.0",
"react-native-linear-gradient": "^2.5.4",
"react-native-vector-icons": "^6.4.2",
"react-navigation": "^3.11.0",
"react-redux": "^7.0.3",
"reactotron-react-native": "^3.5.2",
"reactotron-redux": "^3.1.0",
"reactotron-redux-saga": "^4.2.2",
"realm": "^2.27.0",
"redux": "^4.0.1",
"redux-saga": "^1.0.2",
"reduxsauce": "^1.1.0",
"seamless-immutable": "^7.1.4",
"styled-components": "^4.2.0"
},
"devDependencies": {
"@babel/core": "^7.4.5",
"@babel/runtime": "^7.4.5",
"babel-eslint": "^10.0.1",
"babel-jest": "^24.8.0",
"babel-plugin-root-import": "^6.2.0",
"eslint": "^5.16.0",
"eslint-config-airbnb": "^17.1.0",
"eslint-import-resolver-babel-plugin-root-import": "^1.1.1",
"eslint-plugin-import": "^2.17.2",
"eslint-plugin-jsx-a11y": "^6.2.1",
"eslint-plugin-react": "^7.13.0",
"eslint-plugin-react-native": "^3.7.0",
"jest": "^24.8.0",
"metro-react-native-babel-preset": "^0.54.1",
"react-test-renderer": "16.8.3"
}}
dudusotero
في ٢٣ مايو ٢٠١٩
dudusotero استخدامKudo تعليمات https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17
matpaul
في ٢٣ مايو ٢٠١٩
matpaulKudo يمكنني أن أؤكد أن هذا البناء التجريبي لـ js core يبدو يحل المشكلة لنا أيضًا (تم اختباره على Samsung s7).
tijs
في ٢٣ مايو ٢٠١٩
اختفت أعطالي المتعلقة بهذا التتبع على Android عندما خفضت التصنيف إلى 0.58.6 . كنت أخطط للرجوع إلى 57.6 ، ولكن يبدو أن 58.6 قد أصلح هذا الأمر بالنسبة لي (على الرغم من وجود بعض مشكلات Android الأخرى التي كان علي التخفيف منها ، حيث يتعين علي الإنشاء يدويًا للإصدار)
wildseansy
في ٢٣ مايو ٢٠١٩
@ كودو
الأعزاء،
لقد جربت نسختين من JSC ، يرجى المحاولة إذا كان بإمكانهما إصلاح الأعطال لك.
خطوات موجزة هنا:
https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17أحد الإصدارات التي تم تجربتها هو تعطيل نوع واحد من JIT.
والآخر يعطل JIT تمامًا من matthargett الموصى به.
إذا كان الإصداران سيعملان على إصلاح التعطل بالنسبة لك ، فيرجى أيضًا إرسال ملاحظات إلينا على الأداء العام و TTI كما هو مذكور في جوهر بلدي.
Kudo لدي
- يتوقف التطبيق عن التبعية
@kudo-ci/jsc-android@241213-no-dfg-jit، عند استخدام أحد تطبيقات الإنتاج لدينا لبضع دقائق. - يعمل التطبيق بشكل جيد مع تبعية
@kudo-ci/jsc-android@241213-no-jitas of nowويظل TTI كما هو / غير ملحوظ فيما يتعلق بالإصدارات السابقة.
كودو ، هل سيكون طلب السحب كافيًا لإصلاح ذلك ، حيث لاحظت تعليق التطبيق عند اختباره مقابل no_dfg_jit
ishantsagar
في ٢٤ مايو ٢٠١٩
بعض التحديث أكثر هنا:
أشك حقًا في حدوث التعطل الأصلي بسهولة على S7 edge ، فيجب أن تكون هناك تطبيقات أخرى تواجه مثل هذه المشكلات.
مسكتك!
واجهت خدمة Google Play مع Text API هذه المشكلات ولكن لم يتم إصلاح OSS
وجدت Mono مشكلة تعطل في S7 Exynos bit.LITTLE arch وهنا الإصلاح .
استخدم JavaScriptCore __clear_cache في ARM64Assembler.
سيكون لدي بناء آخر تم تجربته لتصحيح __ مسح_ذاكرة التخزين المؤقت في وقت لاحق من هذا الأسبوع.
Kudo
في ٢٨ مايو ٢٠١٩
البنيات التي تم تجربتها والتي تم إصلاحها __clear_cache جاهزة.
الخطوات هي نفسها كما كانت من قبل ولكن فقط لاستخدام تبعية مختلفة في الدقيقة.
yarn add '@kudo-ci/jsc-android@241213-fix-clear-cache-dfg'وتأكيد adb logcat بالإصدار241213.8000.0( رمز مصدر المرجع هنا )yarn add '@kudo-ci/jsc-android@241213-fix-clear-cache-no-dfg'وتأكيد adb logcat بالإصدار241213.9000.1( رمز مصدر المرجع هنا )
أنا آسف لأنني لا أستطيع التحقق من مشكلة التعطل مرة أخرى ولكن فقط للتحقق من الوظائف الأساسية.
الرجاء المساعدة في اختبار JSC التجربتين إن أمكن.
شكرا جزيلا لكم جميعا ونتمنى لنا حظا سعيدا هذه المرة.
سم مكعبAndrewJackMalcolmScruggstijsishantsagartimhatch
Kudo
في ٢٨ مايو ٢٠١٩
Kudo لقد تلقيت الآن تعليقات على @kudo-ci/jsc-android@241213-fix-clear-cache-dfg و @kudo-ci/jsc-android@241213-fix-clear-cache-no-dfg .
يبدو أن كلا الاختبارين خالين من الأعطال حتى الآن على Samsung Galaxy S7 Edge / Android 7.0 (حتى الآن تركيبة المشكلة)
timhatch
في ٢٨ مايو ٢٠١٩
Kudo لقد جربت كلاً من @kudo-ci/jsc-android@241213-fix-clear-cache-dfg و @kudo-ci/jsc-android@241213-fix-clear-cache-no-dfg في مشروع أساسي يعمل على React-Native 0.59.8 وفي كلا الإصدارين لم يحدث الانهيار. اختبرت على Samsung Galaxy S7 على نظام Android 7.0:
[ro.product.board]: [universal8890]
[ro.product.brand]: [samsung]
[ro.product.cpu.abi]: [arm64-v8a]
[ro.product.cpu.abilist]: [arm64-v8a,armeabi-v7a,armeabi]
[ro.product.cpu.abilist32]: [armeabi-v7a,armeabi]
[ro.product.cpu.abilist64]: [arm64-v8a]
[ro.product.device]: [herolte]
[ro.product.first_api_level]: [23]
[ro.product.locale]: [en-GB]
[ro.product.manufacturer]: [samsung]
[ro.product.model]: [SM-G930F]
[ro.product.name]: [heroltexx]
Kudo لقد جربت أحدث @kudo-ci/jsc-android@241213-fix-clear-cache-dfg لكنني واجهت تعطلًا في Samsung Galaxy S5 (SM-G900F) ، على غرار ذلك الذي كان لدينا مع JSC في React Native 0.59.8
كان الإصدار الذي لا يحتوي على JIT يعمل بشكل مثالي ( @kudo-ci/jsc-android@241213-no-jit ) ولم يواجه أي أعطال في هذا الإصدار بغض النظر عن مدى دفع التطبيق إلى أقصى الحدود. لذلك أعتقد أننا سنلتزم بذلك الآن.
نحن نستخدم ReactRootViews في عارض العرض ، لذلك نقوم بإنشاء وتدمير حالات التفاعل الأصلية في كثير من الأحيان ، ويبدو أن هذا يتسبب في حدوث هذا الانهيار. ربما لهذا السبب نواجه هذه المشكلة في كثير من الأحيان. نحن نعيد زيارة نهج عارض العرض في الوقت الحالي ، ولكن في غضون ذلك ، آمل أن يكون سجل التعطل هذا مفيدًا. (إنه للإصدار 241213.8000.0 ، التفاعل الأصلي 0.59.8)
A/libc: Fatal signal 11 (SIGSEGV), code 1, fault addr 0x66 in tid 16184 (mqt_js)
D/InputReader: Input event: value=1
I/InputReader: Touch event's action is 0x0 (deviceType=0) [pCnt=1, s=0.1239 ] when=8467503214000
I/InputDispatcher: Delivering touch to (1173): action: 0x4, toolType: 1
I/InputDispatcher: Delivering touch to (16117): action: 0x0, toolType: 1
I/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG: Build fingerprint: 'samsung/kltexx/klte:5.0/LRX21T/G900FXXU1BOH4:user/release-keys'
I/DEBUG: Revision: '14'
I/DEBUG: ABI: 'arm'
I/DEBUG: pid: 16117, tid: 16184, name: mqt_js >>> uk.co.thetimes.debug <<<
I/DEBUG: signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x66
I/DEBUG: r0 00000036 r1 8cc43b20 r2 8e558040 r3 fffffffb
I/DEBUG: r4 00000000 r5 91800000 r6 8c752df0 r7 92efea88
I/DEBUG: r8 fffffffb r9 8cce0000 sl 91a08821 fp fffffffc
I/DEBUG: ip 8c752df0 sp 92efe8e0 lr 91d970a9 pc 91ea6502 cpsr 600b0030
I/DEBUG: backtrace:
I/DEBUG: #00 pc 004a7502 <unknown>
I/DEBUG: #01 pc 003980a7 <unknown>
tuncaulubilge
في ٢٩ مايو ٢٠١٩
للأسف كان لدينا بالفعل هؤلاء هناك.
لقد سحبنا تصميمات 64 بت الخاصة بنا من متجر Play. قد لا يكون هذا مرتبطًا على الإطلاق بالتعطل الذي حدث في إصدار 64 بت ، ولكن أجهزة Galaxy S7 التي تعمل بنظام armeabi-v7a تتعطل الآن كثيرًا وفقًا لما هو مذكور أدناه. فور بدء التشغيل.
أتساءل حقًا ما هو الاختلاف في S7 مقارنة بالأجهزة الأخرى.
Version Code: 10000036 Version Name: 2.3.4 Android: 8.0.0 Android Build: R16NW Manufacturer: samsung Model: SM-G930F Date: undefined com.facebook.react.bridge.UnexpectedNativeTypeException: TypeError: expected dynamic type `double', but had type `null' at com.facebook.react.bridge.ReadableNativeMap.getIntNative at com.facebook.react.bridge.ReadableNativeMap.getInt at com.facebook.react.g.a.a at com.facebook.react.modules.core.ExceptionsManagerModule.reportSoftException at java.lang.reflect.Method.invoke(Method.java:-2) at com.facebook.react.bridge.JavaMethodWrapper.invoke at com.facebook.react.bridge.JavaModuleWrapper.invoke at com.facebook.react.bridge.queue.NativeRunnable.run at android.os.Handler.handleCallback(Handler.java:789) at android.os.Handler.dispatchMessage(Handler.java:98) at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage at android.os.Looper.loop(Looper.java:164) at com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run at java.lang.Thread.run(Thread.java:764)
لقد رأينا هذا داخليًا ولاحظنا أن بعض خصائص التصميم الخاصة بنا كانت تعود بلا قيمة. أدت إزالة ذلك وإضافة خاصية النمط فقط بشكل مشروط إلى إصلاح استثناء مشابه - قد يكون هناك شيء ما يحدث مع نوع وحدة نمطية أصلي لك؟
lunaleaps
في ٢٩ مايو ٢٠١٩
tuncaulubilge شكرا على المعلومات.
فقط لمضاعفة التأكيد على أن Samsung S5 (SM-G900F) هي بنية ذراع (وليس arm64) ، أليس كذلك؟
يمكنك التحقق من خلال adb shell getprop ro.product.cpu.abi
من سجل الأعطال الخاص بك ، يبدو أنه ذراع.
إذا كان الأمر كذلك ، أفترض أن السبب الجذري يجب أن يكون قصة أخرى غير هنا.
هل سبق لك اختبار الإصدار no-dfg-jit ، أي @kudo-ci/jsc-android@241213-no-dfg-jit أو @kudo-ci/jsc-android@241213-fix-clear-cache-no-dfg ؟
يجب أن يكون هذان الإصداران متماثلين في arm32 ، يمكنك اختبار أي منهما.
Kudo
في ٢٩ مايو ٢٠١٩
تحديث كودو @
تم الإبلاغ عن backtrace مرة أخرى من خلال وحدة تحكم المطور للمشكلة الأصلية (الأعطال القابلة للتكرار عند تشغيل التطبيق [حصريًا] Samsung S7 Edge + Android 7.0) يبدو كما يلي:
#00 pc 00000000007e048c /data/app/org.ifsc.boulder14-1/lib/arm64/libjsc.so (WTFCrash+16)
#01 pc 00000000000be650 /data/app/org.ifsc.boulder14-1/lib/arm64/libjsc.so (_Z16WTFCrashWithInfoiPKcS0_i+24)
#02 pc 0000000000489f2c /data/app/org.ifsc.boulder14-1/lib/arm64/libjsc.so (operationLinkDirectCall+1120)
#03 pc 00000000002149a8 <unknown>
يبدو أن المشكلة الأصلية قد تم إصلاحها من خلال كل من البنيات التالية:
@kudo-ci/jsc-android@241213-no-jit
@kudo-ci/jsc-android@241213-fix-clear-cache-no-dfg
@kudo-ci/jsc-android@241213-fix-clear-cache-dfg
ومع ذلك ، فقد تمكنت من تحفيز حادث آخر في مناسبتين لآخرهما ( @kudo-ci/jsc-android@241213-fix-clear-cache-dfg ) على جهاز مختلف وبتتبع خلفي مختلف:
#00 pc 00000000004886ac /data/app/org.ifsc.boulder14-ECb5NhJUQgyp_UkWAZLdKg==/lib/arm64/libjsc.so (operationLinkDirectCall+176)
#01 pc 000000000043ad90 <anonymous>
على الرغم من أنني تمكنت من تعطل التطبيق التجريبي مرتين ، في كل مرة باستخدام نفس التوقيع ، لا يمكن تكرار التعطل بشكل منهجي ويحدث أثناء التنقل بين الشاشات المختلفة في التطبيق التجريبي وليس عند التشغيل. نظرًا لأن الجهاز ذي الصلة في متناول اليد ، فقد تمكنت من سحب تتبع أكثر اكتمالاً من الجهاز الذي يقرأ على النحو التالي:
05-29 15:39:06.132 9361 9361 F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x1c
05-29 15:39:06.132 9361 9361 F DEBUG : Cause: null pointer dereference
05-29 15:39:06.132 9361 9361 F DEBUG : x0 0000007363fc4900 x1 000000735b75a000 x2 0000000000000004 x3 0000000000000000
05-29 15:39:06.132 9361 9361 F DEBUG : x4 000000736470caa0 x5 e805b658e92d4328 x6 0000007368dfc8f0 x7 0000000000000000
05-29 15:39:06.132 9361 9361 F DEBUG : x8 0000000000000007 x9 0000000000000000 x10 0000007364d39d80 x11 0000000000000040
05-29 15:39:06.132 9361 9361 F DEBUG : x12 0000007364d39d80 x13 000000000000b324 x14 00000000ffdaeb75 x15 00000073609a09c0
05-29 15:39:06.132 9361 9361 F DEBUG : x16 000000736a1515fc x17 00000073647121a8 x18 0000000000000002 x19 000000735b75a000
05-29 15:39:06.132 9361 9361 F DEBUG : x20 0000007368dfca10 x21 0000007363f0c070 x22 0000007364700000 x23 0000000000000004
05-29 15:39:06.132 9361 9361 F DEBUG : x24 0000000000000000 x25 0000000000000007 x26 0000000000000000 x27 ffff000000000000
05-29 15:39:06.132 9361 9361 F DEBUG : x28 ffff000000000002 x29 0000007368dfca10
05-29 15:39:06.132 9361 9361 F DEBUG : sp 0000007368dfc920 lr 000000736a1516ac pc 000000736a1516ac
05-29 15:39:06.154 9361 9361 F DEBUG :
05-29 15:39:06.154 9361 9361 F DEBUG : backtrace:
05-29 15:39:06.154 9361 9361 F DEBUG : #00 pc 00000000004886ac /data/app/org.ifsc.boulder14-ECb5NhJUQgyp_UkWAZLdKg==/lib/arm64/libjsc.so (operationLinkDirectCall+176)
05-29 15:39:06.154 9361 9361 F DEBUG : #01 pc 000000000043ad90 <anonymous:00000073648ff000>
و
05-29 15:10:13.010 7853 7853 F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x1018
05-29 15:10:13.010 7853 7853 F DEBUG : x0 00000073642c6c40 x1 0000007359684500 x2 0000000000001000 x3 0000000000000000
05-29 15:10:13.010 7853 7853 F DEBUG : x4 00000073008a3030 x5 000000000000006d x6 00000000ffffffff x7 cb010063d1004021
05-29 15:10:13.010 7853 7853 F DEBUG : x8 0000000000000007 x9 0000000000000000 x10 00000073651159c0 x11 0000000000000040
05-29 15:10:13.010 7853 7853 F DEBUG : x12 00000073651159c0 x13 000000736a744558 x14 000000736249dc00 x15 000000736928a2e8
05-29 15:10:13.010 7853 7853 F DEBUG : x16 000000736a1575fc x17 0000007364a121a8 x18 0000000000000045 x19 0000007359684500
05-29 15:10:13.010 7853 7853 F DEBUG : x20 000000736928a2a0 x21 0000007362fb7700 x22 0000007364a00000 x23 0000000000001000
05-29 15:10:13.010 7853 7853 F DEBUG : x24 0000000000000000 x25 0000000000000007 x26 0000000000000000 x27 ffff000000000000
05-29 15:10:13.010 7853 7853 F DEBUG : x28 ffff000000000002 x29 000000736928a2a0
05-29 15:10:13.010 7853 7853 F DEBUG : sp 000000736928a110 lr 000000736a1576ac pc 000000736a1576ac
05-29 15:10:13.024 7853 7853 F DEBUG :
05-29 15:10:13.024 7853 7853 F DEBUG : backtrace:
05-29 15:10:13.024 7853 7853 F DEBUG : #00 pc 00000000004886ac /data/app/org.ifsc.boulder14-ECb5NhJUQgyp_UkWAZLdKg==/lib/arm64/libjsc.so (operationLinkDirectCall+176)
05-29 15:10:13.024 7853 7853 F DEBUG : #01 pc 00000000005169d8 <anonymous:0000007364bff000>
لا توجد فكرة عما إذا كان هذا يساعد ، فإن تصحيح الأخطاء والتفسير على Android لم يكن شيئًا قمت به من قبل
timhatch
في ٢٩ مايو ٢٠١٩
Kudo ها هي النتائج التي توصلت إليها:
سعر Samsung S5 هو armeabi-v7a . لقد جربت جميع البدائل الأربعة التي قدمتها ، ويبدو أن البديل الخالي من التعطل هو البديل الوحيد الخالي من التعطل. يؤدي تعطيل dfg إلى تقليل معدل الأعطال كثيرًا ولكن لا يزال بإمكاني تحطيمه.
أختبر أيضًا على Pixel XL ( arm64-v8a ) ولم أواجه أي أعطال حتى الآن على kudo-ci/jsc-android@241213-fix-clear-cache-no-dfg ولكن من الصعب إعادة إنتاج العطل على الأجهزة المتطورة حيث يبدو أن السبب الأساسي يكون ضغط الذاكرة منخفضًا.
لنلخص:
@kudo-ci/jsc-android@241213-no-jit : هذا خالي من الأعطال على كلا الجهازين
@kudo-ci/jsc-android@241213-fix-clear-cache-no-dfg : هذا يحدث عطلًا في الأجهزة المنخفضة الجودة ، ولا يمكن إعادة إنتاجه على الأجهزة المتطورة
@kudo-ci/jsc-android@241213-fix-clear-cache-dfg : يتعطل هذا بشكل متكرر أكثر من الإصدار الآخر على جهاز منخفض النهاية. (لا يزال أفضل من المخزون RN 59 jsc)
@kudo-ci/jsc-android@241213-no-dfg-jit : تعطل هذا أيضًا على الأجهزة المنخفضة الجودة ، ولم أختبرها على الأجهزة المتطورة.
حتى الإنشاء بدون jit يكون أسرع بكثير من JSCs الأسهم ، لذلك نحن نخطط لاستخدام @kudo-ci/jsc-android@241213-no-jit وسنختبره أكثر للتأكد من جاهزيته للإنتاج.
شكرا جزيلا على كل المساعدة بالمناسبة. اسمحوا لي أن أعرف إذا كان بإمكاني تقديم أي مساعدة
tuncaulubilge
في ٣٠ مايو ٢٠١٩
timhatchtuncaulubilge شكرا للاختبار منهجي رائع وردود الفعل.
الآن ليس لدي أي فكرة لإصلاح المشكلة.
لا يساعد تعطيل DFG ولا إصلاح __clear_cache في ذلك.
علاوة على ذلك ، يحدث الانهيار على arm32 أيضًا (وقد يكون السبب الجذري مختلفًا عن arm64)
في رأيي الشخصي ، أود تعطيل JIT على الإطلاق افتراضيًا ، على الأقل للتأكد من أن لدينا JSC خالية من التعطل أولاً.
راجع للشغل tuncaulubilge كيف قمت بقياس أن @kudo-ci/jsc-android@241213-no-jit أسرع من الأسهم JSC؟
مجرد فضول منذ نتيجة الاختبار ، يعمل الإصدار no-jit بشكل أبطأ قليلاً.
Kudo
في ٣٠ مايو ٢٠١٩
Kudo هل قمت أيضًا بقياس وقت بدء تشغيل التطبيق واستخدام الذاكرة؟ لطالما افترضت أن هذين المقياسين سيكونان أفضل بدون JIT. نظرًا لأن معظم التطبيقات ثقيلة في واجهة المستخدم ، فأنا لست متأكدًا من أن JIT ستكون ذات فائدة كبيرة في تطبيقات العالم الحقيقي ، لذلك أود تعطيل JIT إذا كان يعمل على تحسين بدء التشغيل واستخدام الذاكرة. أشعر بالفضول أيضًا ما إذا كان JSC سيكون له مساحة قرص أصغر بدون JIT.
tido64
في ٣٠ مايو ٢٠١٩
@ كودو
إن إصلاح __clear_cache كما فعلت في تصميمات الاختبار هذه يعمل بالتأكيد على تحسين الموقف ، ولكن إما أن يكون هناك آثار جانبية من الإصلاح أو تفاعل أكثر تعقيدًا لم يتضح بعد. ومع ذلك ، لم أتمكن مرة أخرى من تعطل التطبيق التجريبي -fix-clear-cache-dfg . قد يكون الأمر كما يقول tuncaulubilge ، السلوك يعتمد على ضغط الذاكرة و / أو عوامل أخرى.
يبدو أن تعطيل JIT تمامًا هو خيار "عدم التعطل" ، ولم ألاحظ تدهورًا في الأداء مع هذا الخيار ، لذا سيكون الخيار "الآمن".
timhatch
في ٣١ مايو ٢٠١٩
Kudo للتوضيح ، لقد كنت أقارن React-Native 0.58.6 (بدون تثبيت أي Jsc مخصص) مقابل 0.59.8 بـ @kudo-ci/jsc-android@241213-no-jit .
لم أقم بأي قياسات ولكن تحسن الأداء ملحوظ جدًا. أتوقع أن يكون الإصدار no jit أبطأ قليلاً من الإصدار [email protected] كما ذكرت ، لكن هذا أمر يمكن تجاهله بالمقارنة. أقترح استخدام إصدار no-jit كخيار افتراضي أيضًا ، حيث تفوق تحسينات الاستقرار بشكل كبير تحسين الأداء الطفيف الذي تحصل عليه من Jit.
tuncaulubilge
في ٣١ مايو ٢٠١٩
نحن نستخدم Expo v32 لبناء تطبيقنا ونرى هذا الخطأ عبر إصدارات Android والأجهزة.
Elijen
في ٣١ مايو ٢٠١٩
@ tido64 لا توجد اختلافات كبيرة بين TTI. حجم ثنائي يقلل حوالي 1 ميغابايت من إصدار no_dfg. تقل الذاكرة بحوالي 48٪.
لقد أرسلت PR لتعطيل JIT تمامًا وهناك نتيجة قياس.
https://github.com/react-native-community/jsc-android-buildscripts/pull/108
timhatch جيد لسماع تحديد __clear_cache يساعد قليلاً.
ما زلت أشك في أن السبب الجذري هو big.LITTLE ، لكنني لم أجد رمز JSC آخر يسبب مشاكل بعد.
كل من Samsung S5 و S7 كبيران. LITTLE ومجموعة CPU لها حجم خط ذاكرة تخزين مؤقت مختلف.
ربما يكون هذا هو السبب في عدم تمكني من إعادة إنتاج التعطل على Samsung Note 5 ، حيث يبلغ حجم خط ذاكرة التخزين المؤقت لمجموعة وحدة المعالجة المركزية (CPU) كلاهما 64B.
لست متأكدًا مما إذا كان من الممكن لجدولة نظام التشغيل و JSC الانتقال بين وحدة المعالجة المركزية الكبيرة <-> LITTLE في وقت التشغيل.
إذا كان هذا صحيحًا ، فقد تحدث المشكلة بشكل خاص في ذلك الوقت.
tuncaulubilge هذا فضولي بالنسبة لي.
يمكنك التحقق من العلاقات العامة الخاصة بي ، الإصدار no-jit أبطأ من المخزون RN058 JSC.
هذا أيضًا ما شعرت به أثناء القياس.
ربما تكون المعايير حالات متطرفة وليست جميلة مثل تطبيق RN المعتاد.
راجع للشغل ، لقد رأيت الحجم الثنائي وحجم الذاكرة يتناقصان من إصدار no-jit.
هاتان الفائدتان وخالية من التعطل أكثر منطقية بالنسبة لي.
Kudo
في ٣١ مايو ٢٠١٩
RomanovYurii
في ٢ يونيو ٢٠١٩
RomanovYurii عندما أزلنا فلاتر 64 بت ndk "arm64-v8a" ، "x86_64" من ndk abiFilters في مجموعة التكوين الافتراضي من build.gradle من خلال توفير دعم 32 بت فقط. لقد انتهى الانهيار ولكن وفقًا لتفويض دعم Google 64 بت ، يجب إصلاح هذا بدعم 64 بت ndk.
dishantwalia
في ٢ يونيو ٢٠١٩
25060
dishantwalia
في ٣ يونيو ٢٠١٩
dishantwaliaKudo المعطل يعمل JIT بالنسبة لي على 64 بت ولا أرى أي مشكلات في الأداء حتى الآن.
trieto
في ٣ يونيو ٢٠١٩
عملت هذه الفكرة من أجلي https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17
fjmorant
في ٣ يونيو ٢٠١٩
الأعزاء،
لقد نشرنا no-JIT JSC في jsc-android npm وقمت بمراجعة موجتي السابقة لاستخدام jsc-android@next .
https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17
نأمل في إصلاح جميع مشاكل التعطل.
إذا لم يكن هناك انخفاض كبير في الأداء ، فسنقترح الإصدار no-JIT باعتباره @ أحدث إصدار رسميًا ونرسل PR
Kudo
في ٤ يونيو ٢٠١٩
الأعزاء،
لقد نشرنا no-JIT JSC في jsc-android npm وقمت بمراجعة موجتي السابقة لاستخدام
jsc-android@next.
https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17
نأمل في إصلاح جميع مشاكل التعطل.
إذا لم يكن هناك انخفاض كبير في الأداء ، فسنقترح الإصدار no-JIT باعتباره @ أحدث إصدار رسميًا ونرسل PR
شكرا @ كودو تعطيل
dishantwalia
في ٤ يونيو ٢٠١٩
شكرا @ كودو على كل العمل الشاق! يبدو أن الرقم 241213.2.0 قد قام بحل الأعطال بالنسبة لنا. لسوء الحظ ، فإن تأثير الأداء كبير جدًا. في الأجهزة المنخفضة الجودة على بعض الشاشات الأكثر انشغالًا ، شهدنا انخفاضًا في معدل إطارات js بنسبة 20-30٪.
benoitdion
في ٥ يونيو ٢٠١٩
يمكنني أيضًا أن أؤكد أن الأعطال قد ولت ولكننا نشهد أيضًا أداءً ضعيفًا في الأجهزة ذات النهاية المنخفضة. يجب أن أقول إنه أمر محبط للغاية بالنظر إلى أننا كنا ننتظر الترقية إلى RN58 / RN59 للحصول على JSC الأكثر حداثة.
ItsNoHax
في ٥ يونيو ٢٠١٩
kudo أسوأ سيناريو ، يجب تعطيل jit فقط للإصدار 64 بت ، فقط الأجهزة التي تدعم 64 بت تتعطل
yenda
في ٥ يونيو ٢٠١٩
yenda إذا أصبح هذا الإصدار هو الإصلاح ، فسيكون من الجيد أن يكون لديك هذا الخيار نعم. لست متأكدًا من مدى صعوبة ذلك. نأمل ألا يعني ذلك شحن نسختين من JSC
tijs
في ٥ يونيو ٢٠١٩
benoitdionItsNoHax يمكنك سرد الأجهزة المحددة التي لوحظ ضعف الأداء في؟ شكر!
darrengyles
في ٥ يونيو ٢٠١٩
تم الاختبار على Nexus 5 و Samsung Tab E من بين أجهزة أخرى.
benoitdion
في ٥ يونيو ٢٠١٩
بالنسبة إلى أي من موظفي Google الذين يقومون بترقية مشروع RN الخاص بهم إلى 59.x ، تأكد من أنه في android/app/build.gradle -> android {defaultConfig {versionName}} لا يتم مطابقته مع الإصدار المحدد الخاص بك.
لقد كافحت حوالي ثلاثة أيام من أجل نفس المشكلة واكتشفت لاحقًا أن مشروع React Native الذي تمت ترقيته في الإصدار 59.3 قد تم تحديثه بواسطة code-push الذي يحتوي على React Native v54.7
يجب ألا يكون هذا هو الحال بالنسبة لـ 90٪ من الناس. لكن بالنسبة للبعض مثلي ، يمكن أن يوفر الوقت.
بعد ذلك بفضلKudo. تم إصلاح مشاكل التعطل.
Krutarth-Dave
في ٨ يونيو ٢٠١٩
لدى Huawei Honor 8X هذه المشكلة أيضًا
blohamen
في ١٣ يونيو ٢٠١٩
يمكنني أيضًا أن أؤكد أن الأعطال قد ولت ولكننا نشهد أيضًا أداءً ضعيفًا في الأجهزة ذات النهاية المنخفضة. يجب أن أقول إنه أمر محبط للغاية بالنظر إلى أننا كنا ننتظر الترقية إلى RN58 / RN59 للحصول على JSC الأكثر حداثة.
نفسه هنا. كان RN القديم على Android بطيئًا وتعطلًا ، و RN الجديد سريع ومتعطل ومع هذا الإصلاح الجديد RN مستقر وبطيء. يبدو أنه لا يمكننا الحصول على كل شيء على Android. 🙈
matthiasdilger
في ١٤ يونيو ٢٠١٩
الأعزاء،
أنا آسف جدًا لأن الأداء كان سيئًا بالنسبة لإصدار no-JIT.
وآسف ليس لدي حلول الآن.
يصعب علي استكشاف هذه المشكلة التي لم أتمكن من إعادة إنتاجها.
نأمل أن يساعد شخص ما من المجتمع في حل المشكلة.
JSC لـ RN هو OSS على https://github.com/react-native-community/jsc-android-buildscripts.
وهو يدعم تمكين بناء تصحيح الأخطاء عن طريق إلغاء التعليق في https://github.com/react-native-community/jsc-android-buildscripts/blob/master/scripts/start.sh#L10.
إرفاق gdb أو lldb للتصحيح محليًا ، ربما يكون هناك بعض الأدلة.
قد ينتهك التعطل بعض RELEASE_ASSERT في https://trac.webkit.org/browser/webkit/releases/WebKitGTK/webkit-2.22.6/Source/JavaScriptCore/jit/JITOperations.cpp#L1067 ، لكن لست متأكدًا من كيفية استمرار المشكلة إلى الدولة.
Kudo
في ١٨ يونيو ٢٠١٩
شكرًا لكل عملك على هذا و jsc-android-buildscripts @ كودو. لقد كان من الرائع متابعة تقدمك! هل هناك أي شيء يمكننا (المجتمع الذي يشاهد هذه المشكلة) فعله للمساعدة؟ أعتقد أن لدى tuncaulubilge قضية repro مستقرة في الغالب.
ربما يكون لدى فريق رد الفعل الداخلي على Facebook خبراء JSC؟
benoitdion
في ١٨ يونيو ٢٠١٩
لقد واجهت هذه المشكلة للتو ، لا يحدث إلا على REAL DEVICE ، LENOVO A701a48 ، تشغيل ANDROID 6.
حذف "arm64-v8a", "x86_64" من
ndk {
abiFilters "armeabi-v7a", "x86", "arm64-v8a", "x86_64"
}
تم حلها ولكن شعرت أنها قليلة الاختراق.
آمل أن يكون هناك تحديث من فريق RN قريبًا :(
rayj10
في ١٨ يونيو ٢٠١٩
الأعزاء،
ربما تكون هذه هي المحاولة الأخيرة - لاستخدام إصدار WebKit الأحدث.
يعتمد @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg على WebKitGTK 2.24.2 ، مع JIT الأساسي ولكن بدون DFG JIT.
التغيير الملحوظ هو أن WebKit الأحدث قد غيرت تنسيق JIT bytecode.
x86's JIT غير مدعوم ودعم armeabi-v7a JIT من المجتمع (شكرًا Igalia).
نظرًا لأن الانهيار يحدث فقط على arm64 ، فلا يزال الإصدار الجديد يستحق المحاولة.
الخطوات التفصيلية لدمج هذا الإصدار موجودة في https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17#file -steps_for_webkitgtk_2_24_2-md.
التغيير الملحوظ هو أن 241213 -> 245459 من إصدار JSC السابق وتأكد من وجود 245459.9000.0 في سجل adb.
الرجاء المساعدة في التحقق من هذا JSC المجرب.
نأمل أن يكون لدينا الحظ هذه المرة. 🤞
benoitdion شكرا لتشجيعك ❤️
Kudo
في ١٩ يونيو ٢٠١٩
Kudo @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg يعمل بشكل جيد!
يمكن أن تؤكد أن الانهيار الذي كان يحدث مع RN v0.59 ، عند استخدام JSC أعلاه ، قد اختفى. تم اختباره في Google Nexus 6 ، وسيتم تأكيد الآخرين بعد طرحه.
شكر!!
rimzici
في ٢٠ يونيو ٢٠١٩
Kudo يمكنني أن أؤكد أن @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg يعمل معي أيضًا. لم يحدث أي عطل في Samsung Galaxy S7 SM-G930FD كان يحدث سابقًا مع RN v0.59 وتم إصلاحه بـ no-jit أو jsc-android v241213.2.0 .
dishantwalia
في ٢٠ يونيو ٢٠١٩
لم تتح لي الفرصة لدمج هذا التصميم الجديد حتى الآن حيث أن بعض معالم المشروع الأخرى تعترض طريقنا لكنني أخطط للقيام بذلك بمجرد أن تنتهي هذه الأمور.
يبني برنامجKudo الأصلي no-dfg 99٪ من الأعطال التي رأيتها ، وبينما كنت قادرًا على تحفيز حادث واحد ، لم أتمكن من تكراره.
أعتقد أن tuncaulubilge كان قادرًا على إعادة إنتاج الأعطال باستخدام no-dfg ، لذلك سيكون من المثير للاهتمام معرفة ما يصنعه لهذا الإصدار الجديد.
timhatch
في ٢٠ يونيو ٢٠١٩
rimzicidishantwaliatimhatch شكرا لمساعدتكم.
tuncaulubilge إذا كان لديك الوقت المتاح ، فهل يمكنك من فضلك المساعدة في التحقق من أحدث إصدار تم تجربته؟
IIRC ، أنت و timhatch فقط أبلغت عن أعطال من " 241213 -fix-clear-cache-no-dfg" آخر مرة.
نأمل أن نتمكن من إصلاح الأعطال من خلال الإصدار المحدث.
شكرا جزيلا.
Kudo
في ٢١ يونيو ٢٠١٩
@ كودو
Error when loading lib: dlopen failed: "/data/data/com.amiclient.qa/lib-main/librealmreact.so" is 32-bit instead of 64-bit lib hash: 28b81ed6ba5d3bb31c51509ac8150cd4 search path is /data/app/com.amiclient.qa-1/lib/arm64
لديك هذه المشكلة بعد دمج @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg على ZTE Blade و Samsung S8 و OnePlus 6. فقط على Motorola Z2 Android 7.1.1 بدأ البناء!
blohamen
في ٢١ يونيو ٢٠١٩
@ كودو
Error when loading lib: dlopen failed: "/data/data/com.amiclient.qa/lib-main/librealmreact.so" is 32-bit instead of 64-bit lib hash: 28b81ed6ba5d3bb31c51509ac8150cd4 search path is /data/app/com.amiclient.qa-1/lib/arm64
لديك هذه المشكلة بعد دمج@kudo-ci/jsc-android@245459-fix-clear-cache-no-dfgعلى ZTE Blade و Samsung S8 و OnePlus 6. فقط على Motorola Z2 Android 7.1.1 بدأ البناء!
يبدو أن هذا متعلق بـ realm يرجى مراجعة https://github.com/realm/realm-js/issues/2261#issuecomment -468691502
https://github.com/realm/realm-js/issues/2221
dishantwalia
في ٢١ يونيو ٢٠١٩
Kudo مرة أخرى ، شكرًا على العمل الرائع! لسوء الحظ ، انتقلت إلى مشروع جديد ولم يعد بإمكاني الوصول إلى المشروع القديم. سأحاول الوصول إلى زملائي القدامى في الفريق والحصول على شخص ما ليقوم بهذه المحاولة.
كنا نواجه أعطالًا خاصةً على reactRootView.unmountReactApplication ، مما يؤدي إلى جمع القمامة ، مما يؤدي إلى حوادث عرضية. قد تتمكن من إعادة إنتاجه باستخدام نموذج تطبيق ، وإنشاء وإتلاف ReactRootViews.
tuncaulubilge
في ٢١ يونيو ٢٠١٩
@ كودو
Error when loading lib: dlopen failed: "/data/data/com.amiclient.qa/lib-main/librealmreact.so" is 32-bit instead of 64-bit lib hash: 28b81ed6ba5d3bb31c51509ac8150cd4 search path is /data/app/com.amiclient.qa-1/lib/arm64
لديك هذه المشكلة بعد دمج@kudo-ci/jsc-android@245459-fix-clear-cache-no-dfgعلى ZTE Blade و Samsung S8 و OnePlus 6. فقط على Motorola Z2 Android 7.1.1 بدأ البناء!يبدو أن هذا مرتبط بـ
realmيرجى التحقق من realm / realm-js # 2261 (تعليق)
عالم / عالم- js # 2221
شكرا جزيلا! كان فقط لتحديث المجال إلى 2.28.
@ كودو شكر خاص. تطبيقي يعمل بالفعل بشكل صحيح!
blohamen
في ٢١ يونيو ٢٠١٩
Kudo لقد أعدت إنشاء إصدار من تطبيق متأثر سابقًا بنفس تكوين @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg .
لا توجد أعطال أو توقف حتى الآن - سأرى ما إذا كان بإمكاني التأكيد على التطبيق خلال عطلة نهاية الأسبوع والإبلاغ مرة أخرى إذا واجهت أي مشاكل.
timhatch
في ٢١ يونيو ٢٠١٩
timhatch شكرا جزيلا لك ورجاء خذ وقتك خلال عطلة نهاية الأسبوع.
أشترك لسماع أخبار جيدة منك في المرة القادمة.
Kudo
في ٢٢ يونيو ٢٠١٩
لا يمكنني البناء مع التصحيح. أتلقى الخطأ التالي من FBSDK:
""
المهمة: رد فعل أصلي- fbsdk: compileReleaseJavaWithJavac FAILED
/ Users / waltermonecke / Documents / Code / React-Native2 / moodPixel / node_modules / رد فعل-أصلي-fbsdk / android / src / main / java / com / facebook / رد فعل / androidsdk / FBAppEventsLoggerMod
أولي. جافا: 209 : خطأ: لا يمكن العثور على رمز
ReactMethod (isBlockingSynchronousMethod = صحيح)
^
الرمز: الطريقة هي BlockingSynchronousMethod ()
الموقع: interface ReactMethod
ملاحظة: تستخدم بعض ملفات الإدخال واجهة برمجة تطبيقات مهملة أو تتجاوزها.
ملاحظة: إعادة التحويل البرمجي باستخدام -
ملاحظة: يستخدم /Users/waltermonecke/Documents/Code/React-Native2/moodPixel/node_modules/react-native-fbsdk/android/src/main/java/com/facebook/reactnative/androidsdk/Utility.java عمليات غير محددة أو غير آمنة.
ملاحظة: إعادة التحويل البرمجي باستخدام -
1 خطأ
فشل: فشل البناء مع استثناء.
""
wmonecke
في ٢٣ يونيو ٢٠١٩
wmonecke تبدو المشكلة غريبة بالنسبة لي. لم أتطرق إلى أي كود جافا أو تبعيات متدرجة في JSC AAR.
هل يمكنك التحقق من المشكلة أو وصف كيفية تطبيق التصحيح بإيجاز؟
أعتقد أنك تستخدم بطريق الخطأ اعتماد RN القديم و
يمكنك التحقق من خلال ./gradlew :app:dependencies | grep 'com.facebook.react:react-native:' (الرجاء التأكد من أن إصدار RN الذي تم إرجاعه هو الذي توقعته).
Kudo
في ٢٤ يونيو ٢٠١٩
لا يمكنني البناء مع التصحيح. أتلقى الخطأ التالي من FBSDK:
Task :react-native-fbsdk:compileReleaseJavaWithJavac FAILED /Users/waltermonecke/Documents/Code/React-Native2/moodPixel/node_modules/react-native-fbsdk/android/src/main/java/com/facebook/reactnative/androidsdk/FBAppEventsLoggerMod ule.java:209: error: cannot find symbol @ReactMethod(isBlockingSynchronousMethod = true) ^ symbol: method isBlockingSynchronousMethod() location: <strong i="7">@interface</strong> ReactMethod Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /Users/waltermonecke/Documents/Code/React-Native2/moodPixel/node_modules/react-native-fbsdk/android/src/main/java/com/facebook/reactnative/androidsdk/Utility.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. 1 error FAILURE: Build failed with an exception.
wmonecke ، عليك إضافة كل من (رد فعل أصلي و kudo ci) مستودع مافن للحصول عليه مجمعة
مخضرم {
// كل React Native (JS ، مصادر Obj-C ، ثنائيات Android) مثبتة من npm
url "$ rootDir /../ node_modules / رد فعل أصلي / android"
}
مخضرم {
// Local Maven repo يحتوي على AARs مع مكتبة JSC مصممة لنظام Android
url "$ rootDir /../ node_modules / @ kudo-ci / jsc-android / dist"
}
dishantwalia
في ٢٤ يونيو ٢٠١٩
Kudo لا توجد مشاكل مع @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg . لا يوجد تطبيق توقف أو يتعطل.
timhatch
في ٢٤ يونيو ٢٠١٩
Kudo لا توجد مشاكل مع
@kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg. لا يوجد تطبيق توقف أو يتعطل.
Kudo الرجاء دفع هذا الإصلاح في jsc-android-buildscripts ونشر إصدار. حتى نتمكن من طرح هذا في تطبيقات الإنتاج لدينا https://github.com/react-native-community/jsc-android-buildscripts.
dishantwalia
في ٢٤ يونيو ٢٠١٩
تضمين التغريدة شكرا خاصا على تصديقك ستدفع تغييرات JSC إلى RN قريبًا.
dishantwalia نعم ، مستمر. شكرا جزيلا.
Kudo
في ٢٥ يونيو ٢٠١٩
شكرًا Kudo على كل عملك على هذا. هل يمكنك (أو أي شخص آخر يعرف ما يحدث) فقط من فضلك إرشادي في الاتجاه الصحيح لتنفيذ هذا الإصلاح (أدرك أنه عمل قيد التقدم).
أنا حاليًا على RN 0.59.9. مع طرح التغييرات ، هل سيتوفر إصدار محدث من RN مثل 0.59.10 أم يجب أن أقوم بدلاً من ذلك بتثبيت jsc-android-buildscripts كحزمة تابعة لجهة خارجية ، وتنفيذ 0.59x وفقًا للوثائق؟
jacquesdev
في ٢٥ يونيو ٢٠١٩
Kudo لا مشاكل سواء مع الإصدار الأخير الخاص بك. عمل عظيم! 💪
Fouppy
في ٢٥ يونيو ٢٠١٩
بفضلKudo، لدي نفسjacquesdev السؤال يسأل 0.59.10 أو jsc-android-buildscripts ؟
fjmorant
في ٢٥ يونيو ٢٠١٩
تضمين التغريدة
شكر! كنت أحفظ فقط:
maven {
// workaround for crash on 64 bit devices - remove once RN 59+ has resolved issue.
// issue: https://github.com/facebook/react-native/issues/24261
url "$rootDir/../node_modules/@kudo-ci/jsc-android/dist"
}
مع البناء
wmonecke
في ٢٥ يونيو ٢٠١٩
Kudo للأسف لا تزال المشكلة قائمة (Galaxy S7 ، Android7). لقد حاولت @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg .
لقد جربت أيضًا إصدار no-JIT ، والذي لم يساعد. لم أتمكن من جعل إصدار "JavaScriptCore" مطبوعًا في adb logcat باستخدام grep الذي قدمته ، ولم أر أي ذكر لـ JavaScriptCore في السجل نفسه من خلال البحث يدويًا.
يمكنني إعادة إنتاج العطل بشكل متكرر. لا يصطدم دائمًا في نفس المكان.
هذا هو الخطأ (245459-fix-clear-cache-no-dfg):
06-26 13:56:22.982 4374 4521 W google-breakpad: Chrome build fingerprint:
06-26 13:56:22.982 4374 4521 W google-breakpad: 3.0.70
06-26 13:56:22.982 4374 4521 W google-breakpad: 30070
06-26 13:56:22.982 4374 4521 W google-breakpad: ### ### ### ### ### ### ### ### ### ### ### ### ###
06-26 13:56:22.984 4374 4521 F libc : Fatal signal 11 (SIGSEGV), code 1, fault addr 0xafca in tid 4521 (mqt_js)
06-26 13:56:22.986 3075 3075 W : debuggerd: handling request: pid=4374 uid=10169 gid=10169 tid=4521
06-26 13:56:23.089 3769 5715 D SSRM:k : SIOP:: AP = 430, PST = 398 (W:6), CP = 318, CUR = -104, LCD = 99
06-26 13:56:23.154 4557 4557 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
06-26 13:56:23.156 4557 4557 F DEBUG : Build fingerprint: 'samsung/hero2ltexx/hero2lte:7.0/NRD90M/G935FXXU1ZPL3:user/release-keys'
06-26 13:56:23.156 4557 4557 F DEBUG : Revision: '8'
06-26 13:56:23.156 4557 4557 F DEBUG : ABI: 'arm64'
06-26 13:56:23.157 4557 4557 F DEBUG : pid: 4374, tid: 4521, name: mqt_js >>> com.myapp <<<
06-26 13:56:23.157 4557 4557 F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xafca
06-26 13:56:23.157 4557 4557 F DEBUG : x0 000000000000a01a x1 0000000000000000 x2 00000079f6a30000 x3 0000007a05afe748
06-26 13:56:23.157 4557 4557 F DEBUG : x4 0000000000000000 x5 0000000000000010 x6 ffff000000000002 x7 0000000000009ab0
06-26 13:56:23.158 4557 4557 F DEBUG : x8 0000007a045acd6c x9 0000000000000002 x10 0000000000000001 x11 0000000000000000
06-26 13:56:23.158 4557 4557 F DEBUG : x12 0000000000000fff x13 00000079df7ed2b8 x14 00000079f6973890 x15 0000000000000001
06-26 13:56:23.158 4557 4557 F DEBUG : x16 00000079f6a59a30 x17 0000007a1ae56058 x18 000000000045b4fb x19 0000007a05afe7f0
06-26 13:56:23.158 4557 4557 F DEBUG : x20 0000007a05afe750 x21 00000079f6a3a6b8 x22 0000007a1ae4b000 x23 00000079f693cf50
06-26 13:56:23.158 4557 4557 F DEBUG : x24 0000000000000000 x25 00000079df415e10 x26 0000000000000001 x27 ffff000000000000
06-26 13:56:23.158 4557 4557 F DEBUG : x28 ffff000000000002 x29 0000007a05afe750 x30 0000007a045ac890
06-26 13:56:23.158 4557 4557 F DEBUG : sp 0000007a05afe640 pc 0000007a045a27e4 pstate 0000000040000000
06-26 13:56:23.173 4557 4557 F DEBUG :
06-26 13:56:23.173 4557 4557 F DEBUG : backtrace:
06-26 13:56:23.173 4557 4557 F DEBUG : #00 pc 00000000001647e4 /data/app/com.test.app-1/lib/arm64/libjsc.so
06-26 13:56:23.173 4557 4557 F DEBUG : #01 pc 000000000016e88c /data/app/com.test.app-1/lib/arm64/libjsc.so
06-26 13:56:23.173 4557 4557 F DEBUG : #02 pc 000000000016ebf0 /data/app/com.test.app-1/lib/arm64/libjsc.so
06-26 13:56:23.173 4557 4557 F DEBUG : #03 pc 000000000016ed8c /data/app/com.test.app-1/lib/arm64/libjsc.so
06-26 13:56:23.173 4557 4557 F DEBUG : #04 pc 0000000000005ecc <anonymous:00000079eb5f9000>
backtrace لا يقول أي شيء ذي معنى.
سأذكر أيضًا أنه ليس لدي Android7 رسميًا على جهاز Galaxy S7 الخاص بي لأنه كان من المستحيل الرجوع إلى إصدار أقدم من Android8 (لا يمكن أن تنتج المشكلة مع Android8) ، لذلك اضطررت إلى العثور على rom مخصص يدعم Android7.
أنا أحقق في محاولة تجميع إصدار تصحيح الأخطاء الخاص بي من jsc-android باستخدام آخر التزام لك على jsc-android-buildscripts ، لكن الأمر سيستغرق بعض الوقت.
ChrisEelmaa
في ٢٦ يونيو ٢٠١٩
أعتقد أننا نواجه نفس المشكلة.
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
pid: 0, tid: 0 >>> com.groundspeak.react.adventures <<<
backtrace:
#00 pc 00000000007e048c /data/app/com.groundspeak.react.adventures-1/lib/arm64/libjsc.so
#01 pc 00000000000be650 /data/app/com.groundspeak.react.adventures-1/lib/arm64/libjsc.so
#02 pc 0000000000489f2c /data/app/com.groundspeak.react.adventures-1/lib/arm64/libjsc.so
#03 pc 000000000025fd98 <anonymous>
حسب إصدار Android:
الإصدار | رقم | نسبه مئويه
- | - | -
أندرويد 7.0 | 66 | 100.0٪
حسب الجهاز:
الجهاز | رقم | نسبه مئويه
- | - | -
hero2lte | 26 | 39.4٪
هيرولت | 24 | 36.4٪
heroltebmc | 16 | 24.2٪
syntax-e
في ٢٦ يونيو ٢٠١٩
لقد تلقيت أيضًا تعطل Galaxy S7 بعد تحديث RN من 0.58.6 إلى 0.59.9.
لا يزال إصدار npm الحالي من jsc-android يتسبب في تعطل التطبيق ، ولكن باستخدام @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg وإصدار JSC 245459.9000.0 أصلح لي التعطل على S7.
kristerkari
في ٢٧ يونيو ٢٠١٩
ChrisEelmaa تسجيل الدخول إلى "JavaScriptCore.Version" في adb logcat هو طريقة تؤكد اختيار إصدار JSC الصحيح.
لأن RN 0.59 قد بنيت في libjsc.so و pickFirst '** / libjsc.so' لا يمكن الاعتماد عليها في رأيي.
تتمثل الطريقة البديلة لتأكيد إصدار JSC في اتباع الخطوات:
- unzip /path/to/app.apk
- سلاسل jni / arm64-v8a / libjsc.so | grep -C 1 JavaScriptCore.Version
يجب أن يكون الإخراج شيئًا مثل:
$ strings jni/arm64-v8a/libjsc.so|grep -C 1 JavaScriptCore.Version
API Wrapper
JavaScriptCore.Version
245459.9000.0
Kudo شكرًا على الإصلاح الخاص بك ، يبدو أنه يمنع حدوث الجحيم.
سنتان لدي هناك: ليس لدي مجلد jni ولكن لدي مجلد lib بدلاً من ذلك ، لذا استخدم هذا الأمر للتحقق من الإصدار بعد فك الضغط:
$ strings lib/arm64-v8a/libjsc.so | grep -C 1 JavaScriptCore.Version
API Wrapper
JavaScriptCore.Version
245459.9000.0
ebaynaud
في ٢٧ يونيو ٢٠١٩
شكرا @ كودو
كان لدي سابقًا 0.58.3 تفاعل أصلي ، وأرى أن الناس يذكرون 0.59 طوال الوقت ، لذلك قررت أيضًا التحديث. يبدو أن الجمع بين وجود 0.59.0 و @ kudo-ci / jsc-android @ 245459-fix-clear-cache-no-dfg يؤدي إلى الحيلة بالنسبة لي.
لم يعد بإمكاني إنتاج الانهيار.
ChrisEelmaa
في ٢٧ يونيو ٢٠١٩
هل يعرف أي شخص ما إذا كان سيتم إصلاح هذه المشكلة في إصدار RN التالي؟
Darren-Ivey
في ٢٧ يونيو ٢٠١٩
هل يعرف أي شخص ما إذا كان سيتم إصلاح هذه المشكلة في إصدار RN التالي؟
https://github.com/react-native-community/jsc-android-buildscripts#for -react-native-version-060-and-newer
skantus
في ٢٧ يونيو ٢٠١٩
تضمين التغريدة
فقط لتأكيد الخطوات التي اتبعتها.
لقد اتبعت التعليمات هنا ، https://github.com/react-native-community/jsc-android-buildscripts#for -react-native-version-059
لكنك بدلًا من إضافة "jsc-android": "241213.x.x", ، أضفت @kudo-ci/jsc-android": "^245459.9000.0 إلى package.json؟ هل أجريت أي تغييرات أخرى؟
على سبيل المثال ، أرى أنه في build.grade ، يجب عليك إضافة implementation "org.webkit:android-jsc:r241213" ، هل يجب تغيير هذا السطر أيضًا ، وإذا كانت الإجابة بنعم فما الذي يجب أن يكون؟
أستمر في الحصول على خطأ الإنشاء Could not find org.webkit:android-jsc:r241213. أو Could not find org.webkit:android-jsc:r245459.9000.0. لذا أعتقد أن مشكلتي تستخدم المرجع الخاطئ هناك ، لكن لا يمكنني تحديد ما يجب أن يكون.
jacquesdev
في ٢٨ يونيو ٢٠١٩
jacquesdev اتبع الخطوات الواردة في هذا الدليل: https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17#file -steps_for_webkitgtk_2_24_2-md
kristerkari
في ٢٨ يونيو ٢٠١٩
الأعزاء،
فقط لتحديث ذلك بمساعدة kmagiera ، تم نشر التصحيح الخاص بي كـ " [email protected] ".
لقد أرسلت https://github.com/facebook/react-native/pull/25426 للحصول على JSC المحدث في RN.
و @ kelset أيضًا في RN 0.60 RC.
نأمل أن نتمكن أخيرًا من إصلاح هذه المشكلة وإغلاقها.
صرخ للناس هنا خصيصًا للمساعدة في التحقق من الإصدارات التي تم تجربتها ذهابًا وإيابًا.
نحن هكذا ندعى مجتمع RN!
Kudo
في ٢٨ يونيو ٢٠١٩
شكرا @ كودو! هل لديك أي فكرة عما إذا كان لهذا أي فرصة لإصدار 0.59.x ، أم أنه من المحتمل أن يكون في 0.60 فقط؟
csouth3
في ٢٨ يونيو ٢٠١٩
سيكون من الرائع أن نحصل عليه في 0.59.x
يحتوي 0.60 على الكثير من التغييرات العاجلة مع AndroidX والمحتويات الخارجية.
anuragdadheech
في ٢٩ يونيو ٢٠١٩
+1 بالنسبة إلينا ، سيؤدي إدخاله في 0.59.x إلى حل الكثير من المشكلات التي تواجهنا
تطبيقات.
لا تريد حقًا التوجه إلى 0.60 بسبب دعم Android X في
المكتبات حتى الآن.
الاختيار الأول لـ JSC لم ينجح بالنسبة لنا ، يجب أن يكون أحد الليبيين الأصليين لدينا
تسبب في مشكلة ولكن يبدو أنه دائمًا ما يختار الإصدار الداخلي لـ rn.
(نجح المشروع النظيف ، لذا يجب أن يكون أحد أقسامنا سببًا لذلك)
كيرك
يوم السبت ، 29 يونيو 2019 ، الساعة 19:35 مساءً ، Anurag Dadheech ، [email protected]
كتب:
سيكون من الرائع أن نحصل عليه في 0.59.x
يحتوي 0.60 على الكثير من التغييرات العاجلة مع AndroidX والمحتويات الخارجية.-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/facebook/react-native/issues/24261؟email_source=notifications&email_token=AABPHZ25TBIFBOI3QWMSPXLP46TN3A5CNFSM4HC77RA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AABPHZ2D5WUEM4S3242ZTYTP46TN3ANCNFSM4HC77RAQ
.
kbateman
في ٢٩ يونيو ٢٠١٩
مرحبًا ، هل يمكنني معرفة مكان إضافة "@ kudo-ci / jsc-android @ 245459-fix-clear-cache-no-dfg "؟
tlweiii6465
في ٣٠ يونيو ٢٠١٩
مرحبًا Kudo شكرًا على عملك الرائع!
في WebKit القديم بدون DFG JIT ، لا تزال الأعطال تحدث ولكن يبدو أن WebKit 2.24.2 الأحدث مع عدم وجود DFG JIT قد أصلحها. أتساءل عما إذا كان الأمر يستحق تجربة WebKit الجديدة مع تمكين DFG JIT من أجل السماح بأعلى أداء ممكن إذا كان يعمل.
tomtanti
في ٣٠ يونيو ٢٠١٩
وأنا أتفق مع بعض الملاحظات قبل أن تكون الأفضل أن يكون 0.59.10 مع هذا الإصلاح لأنه سيكون من الصعب للترقية إلى 0.60Kudokelsetgrabbouturnrye
fjmorant
في ١ يوليو ٢٠١٩
لديك نفس المشكلة هنا ،
لا يمكننا الترقية إلى 0.60 لأن خرائط التفاعل الأصلية لا تدعم AndroidX حتى الآن ، ولا يمكننا دفع تحديثاتنا إلى 0.59.X بسبب تعطل S7 و S7 plus.
هذه حقًا مشكلة للشركات تعتمد على التفاعل الأصلي
هل هناك أي حل بديل لهذا؟
adnkh
في ١ يوليو ٢٠١٩
أتفق مع adnkh ، لا يمكننا الترقية إلى AndroidX الآن ، لكننا بحاجة إلى حل أعطال 0.59.
douglasjunior
في ١ يوليو ٢٠١٩
لا تحتاج إلى الترقية إلى 0.60 لاستهلاك الإصلاح. يجب أن تكون قادرًا على اتباع التعليمات الموجودة على https://github.com/react-native-community/jsc-android-buildscripts/#for -react-native-version-059. الإصدار الذي تريد تثبيته هو 245459.0.0 أو أكبر.
benoitdion
في ١ يوليو ٢٠١٩
مرحبًا benoitdion ،
نعم ، من الممكن أن تستهلك على الرغم من عدم وجودها في المكتبة الرئيسية ، في الواقع ، لقد اتبعت هذه التعليمات https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17 . وعملت
لكنني لا أعتقد أن هذا حل دائم وأنيق نظرًا للعديد من الأشياء التي تحتاج إلى إضافتها إلى مشروع Android الخاص بك ، أعتقد أن الإصلاح العاجل في RN الرئيسي سيكون أكثر ملاءمة من وجهة نظر المطور وسيحل العديد من مشكلات التعطل على تطبيقات Android
fjmorant
في ١ يوليو ٢٠١٩
لا تحتاج إلى الترقية إلى 0.60 لاستهلاك الإصلاح. يجب أن تكون قادرًا على اتباع التعليمات الموجودة على https://github.com/react-native-community/jsc-android-buildscripts/#for -react-native-version-059. الإصدار الذي تريد تثبيته هو 245459.0.0 أو أحدث.
benoitdion نعم ، لكنه حل بديل ، سيكون الإصلاح الرسمي المنشور كـ 0.59.10 أفضل.
douglasjunior
في ١ يوليو ٢٠١٩
شكرا @ كودو
استخدم @kudo-ci/jsc-android@245459-fix-clear-cache-no-dfg لتقليل معظم الأعطال
ولكن لا تزال هناك بعض الانقطاعات في الإنتاج
xiaomi MIX 3 XiaoMi / MIUI Android 9 ، المستوى 28 arm64-v8a
1 #00 pc 00000000000f7748 /data/app/com.gezbox.windmessage--4BWJ7puodXEdg5g4H7Mdg==/lib/arm64/libjsc.so (JSC::AccessCase::propagateTransitions(JSC::SlotVisitor&) const+16) [arm64-v8a]
2 #01 pc 0000000000143fe8 /data/app/com.gezbox.windmessage--4BWJ7puodXEdg5g4H7Mdg==/lib/arm64/libjsc.so (JSC::PolymorphicAccess::propagateTransitions(JSC::SlotVisitor&) const+48) [arm64-v8a]
3 #02 pc 000000000012f0a8 /data/app/com.gezbox.windmessage--4BWJ7puodXEdg5g4H7Mdg==/lib/arm64/libjsc.so (JSC::CodeBlock::propagateTransitions(JSC::ConcurrentJSLocker const&, JSC::SlotVisitor&)+556) [arm64-v8a]
4 #03 pc 0000000000139484 /data/app/com.gezbox.windmessage--4BWJ7puodXEdg5g4H7Mdg==/lib/arm64/libjsc.so (JSC::ExecutableToCodeBlockEdge::runConstraint(JSC::ConcurrentJSLocker const&, JSC::VM&, JSC::SlotVisitor&)+40) [arm64-v8a]
5 #04 pc 000000000013900c /data/app/com.gezbox.windmessage--4BWJ7puodXEdg5g4H7Mdg==/lib/arm64/libjsc.so (JSC::ExecutableToCodeBlockEdge::visitChildren(JSC::JSCell*, JSC::SlotVisitor&)+1044) [arm64-v8a]
6 #05 pc 00000000001fb9c4 /data/app/com.gezbox.windmessage--4BWJ7puodXEdg5g4H7Mdg==/lib/arm64/libjsc.so (_ZZN3JSC11SlotVisitor5drainEN3WTF13MonotonicTimeEENK3$_3clERNS_14MarkStackArrayE+324) [arm64-v8a]
7 #06 pc 00000000001f8e90 /data/app/com.gezbox.windmessage--4BWJ7puodXEdg5g4H7Mdg==/lib/arm64/libjsc.so (JSC::SlotVisitor::drain(WTF::MonotonicTime)+132) [arm64-v8a]
8 #07 pc 00000000001f96bc /data/app/com.gezbox.windmessage--4BWJ7puodXEdg5g4H7Mdg==/lib/arm64/libjsc.so (JSC::SlotVisitor::drainFromShared(JSC::SlotVisitor::SharedDrainMode, WTF::MonotonicTime)+580) [arm64-v8a]
9 #08 pc 00000000001e41a0 /data/app/com.gezbox.windmessage--4BWJ7puodXEdg5g4H7Mdg==/lib/arm64/libjsc.so (_ZN3WTF17SharedTaskFunctorIFvvEZN3JSC4Heap13runBeginPhaseENS2_11GCConductorEE4$_17E3runEv+580) [arm64-v8a]
10 #09 pc 00000000006171ec /data/app/com.gezbox.windmessage--4BWJ7puodXEdg5g4H7Mdg==/lib/arm64/libjsc.so (WTF::ParallelHelperClient::runTask(WTF::RefPtr<WTF::SharedTask<void ()>, WTF::DumbPtrTraits<WTF::SharedTask<void ()> > > const&)+40) [arm64-v8a]
11 #10 pc 0000000000617950 /data/app/com.gezbox.windmessage--4BWJ7puodXEdg5g4H7Mdg==/lib/arm64/libjsc.so (WTF::ParallelHelperPool::Thread::work()+16) [arm64-v8a]
12 #11 pc 000000000060de7c /data/app/com.gezbox.windmessage--4BWJ7puodXEdg5g4H7Mdg==/lib/arm64/libjsc.so (_ZN3WTF8FunctionIFvvEE15CallableWrapperIZNS_15AutomaticThread5startERKNS_14AbstractLockerEE3$_0E4callEv+376) [arm64-v8a]
13 #12 pc 000000000061b084 /data/app/com.gezbox.windmessage--4BWJ7puodXEdg5g4H7Mdg==/lib/arm64/libjsc.so (WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*)+212) [arm64-v8a]
14 #13 pc 0000000000646dc8 /data/app/com.gezbox.windmessage--4BWJ7puodXEdg5g4H7Mdg==/lib/arm64/libjsc.so (WTF::wtfThreadEntryPoint(void*)+4) [arm64-v8a]
15 #14 pc 0000000000081dac /system/lib64/libc.so (__pthread_start(void*)+36) [arm64-v8a]
16 #15 pc 0000000000023788 /system/lib64/libc.so (__start_thread+68) [arm64-v8a]
OPPO R9S Oppo / COLOROS Android 6.0.1 ، المستوى 23 arm64-v8a
1 #00 pc 00000000000f7748 /data/app/com.gezbox.windmessage-1/lib/arm64/libjsc.so (JSC::AccessCase::propagateTransitions(JSC::SlotVisitor&) const+16) [arm64-v8a]
2 #01 pc 0000000000143fe8 /data/app/com.gezbox.windmessage-1/lib/arm64/libjsc.so (JSC::PolymorphicAccess::propagateTransitions(JSC::SlotVisitor&) const+48) [arm64-v8a]
3 #02 pc 000000000012f0a8 /data/app/com.gezbox.windmessage-1/lib/arm64/libjsc.so (JSC::CodeBlock::propagateTransitions(JSC::ConcurrentJSLocker const&, JSC::SlotVisitor&)+556) [arm64-v8a]
4 #03 pc 0000000000139484 /data/app/com.gezbox.windmessage-1/lib/arm64/libjsc.so (JSC::ExecutableToCodeBlockEdge::runConstraint(JSC::ConcurrentJSLocker const&, JSC::VM&, JSC::SlotVisitor&)+40) [arm64-v8a]
5 #04 pc 000000000013900c /data/app/com.gezbox.windmessage-1/lib/arm64/libjsc.so (JSC::ExecutableToCodeBlockEdge::visitChildren(JSC::JSCell*, JSC::SlotVisitor&)+1044) [arm64-v8a]
6 #05 pc 00000000001fb9c4 /data/app/com.gezbox.windmessage-1/lib/arm64/libjsc.so (_ZZN3JSC11SlotVisitor5drainEN3WTF13MonotonicTimeEENK3$_3clERNS_14MarkStackArrayE+324) [arm64-v8a]
7 #06 pc 00000000001f8e90 /data/app/com.gezbox.windmessage-1/lib/arm64/libjsc.so (JSC::SlotVisitor::drain(WTF::MonotonicTime)+132) [arm64-v8a]
8 #07 pc 00000000001f96bc /data/app/com.gezbox.windmessage-1/lib/arm64/libjsc.so (JSC::SlotVisitor::drainFromShared(JSC::SlotVisitor::SharedDrainMode, WTF::MonotonicTime)+580) [arm64-v8a]
9 #08 pc 00000000001e41a0 /data/app/com.gezbox.windmessage-1/lib/arm64/libjsc.so (_ZN3WTF17SharedTaskFunctorIFvvEZN3JSC4Heap13runBeginPhaseENS2_11GCConductorEE4$_17E3runEv+580) [arm64-v8a]
10 #09 pc 00000000006171ec /data/app/com.gezbox.windmessage-1/lib/arm64/libjsc.so (WTF::ParallelHelperClient::runTask(WTF::RefPtr<WTF::SharedTask<void ()>, WTF::DumbPtrTraits<WTF::SharedTask<void ()> > > const&)+40) [arm64-v8a]
11 #10 pc 0000000000617950 /data/app/com.gezbox.windmessage-1/lib/arm64/libjsc.so (WTF::ParallelHelperPool::Thread::work()+16) [arm64-v8a]
12 #11 pc 000000000060de7c /data/app/com.gezbox.windmessage-1/lib/arm64/libjsc.so (_ZN3WTF8FunctionIFvvEE15CallableWrapperIZNS_15AutomaticThread5startERKNS_14AbstractLockerEE3$_0E4callEv+376) [arm64-v8a]
13 #12 pc 000000000061b084 /data/app/com.gezbox.windmessage-1/lib/arm64/libjsc.so (WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*)+212) [arm64-v8a]
14 #13 pc 0000000000646dc8 /data/app/com.gezbox.windmessage-1/lib/arm64/libjsc.so (WTF::wtfThreadEntryPoint(void*)+4) [arm64-v8a]
15 #14 pc 00000000000664a4 /system/lib64/libc.so (__pthread_start(void*)+52) [arm64-v8a]
16 #15 pc 000000000001ebc4 /system/lib64/libc.so (__start_thread+16) [arm64-v8a]
RMX1901 Oppo / COLOROS Android 9 ، المستوى 28 arm64-v8a
1 #00 pc 0000007772fbb2c0 <unknown>
2 #01 pc 00000000005519bc /data/app/com.gezbox.windmessage-vCMpnEKA509f1Di2EyrZ2w==/lib/arm64/libjsc.so (JSC::RegExp::match(JSC::VM&, WTF::String const&, unsigned int, WTF::Vector<int, 0ul, WTF::CrashOnOverflow, 16ul>&)+500) [arm64-v8a]
3 #02 pc 00000000005722e8 /data/app/com.gezbox.windmessage-vCMpnEKA509f1Di2EyrZ2w==/lib/arm64/libjsc.so (JSC::stringProtoFuncReplaceUsingRegExp(JSC::ExecState*)+3072) [arm64-v8a]
4 #03 pc 0000007772dff1ec <unknown>
👋 الجميع.
نسمعكم جميعًا ، وبسبب المشكلات التي يواجهها الكثير منكم ، قمنا بإصدار آخر تصحيح 0.59.10 لتزويدكم بالإصدار الجديد من JSC.
شكراً جزيلاً لـ Kudo لعمله على إعادة تحويل هذا إلى 0.59.
لن نقوم بإصدارات 0.59 أخرى في المستقبل المنظور ، لأنه عمل مليء بالتحديات وأصعب لأننا نعمل أيضًا على 0.60 (والذي سيكون له JSC الجديد أيضًا!).
سأغلق هذا نظرًا لأنه تم معالجة المشكلة الأساسية الرئيسية ، لكنني أقترح فتح واحدة جديدة للأعطال الأخرى التي قد تواجهها بعد 0.59.10.
kelset
في ٢ يوليو ٢٠١٩
أخبارممتازه !!
شكرا للجميع ، وخاصة @ kudo !!
في الثلاثاء ، 2 يوليو 2019 ، الساعة 12:29 مساءً ، لورينزو شياندرا ، [email protected]
كتب:
👋 الجميع.
نسمعكم جميعًا ، وبسبب المشكلات التي يواجهها الكثير منكم
قمت بإصدار آخر تصحيح 0.59.10 لتزويدك بالإصدار الجديد من
هيئة الأوراق المالية.شكراً جزيلاً لـ Kudo https://github.com/Kudo لعمله على
عودة تحويل هذا إلى 0.59.لن نقوم بإصدارات 0.59 الجديدة ، حيث إنه عمل صعب وحتى
أصعب لأننا نعمل أيضًا على 0.60 (والذي سيكون له JSC الجديد
جدا!).سأقوم بإغلاق هذا الموضوع حيث تم معالجة المشكلة الأساسية الرئيسية ، لكني سأفعل ذلك
أقترح فتح واحدة جديدة للأعطال الأخرى التي قد تواجهها
بعد 0.59.10.-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/facebook/react-native/issues/24261؟email_source=notifications&email_token=AABPHZZG2Z764HFNPJB7UVTP5M325A5CNFSM4HC77RA2YY3PNVWWK3TUL52HS4DFVREXG43VMVB50
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AABPHZ5PYT4F7ZZGQXZKKKLP5M325ANCNFSM4HC77RAQ
.
kbateman
في ٢ يوليو ٢٠١٩
شكرا جزيلا على الإصلاح! بعد ترقية رد الفعل الأصلي إلى الإصدار 0.59.10 ، هل ما زلت بحاجة إلى تنفيذ الخطوات المذكورة هنا ؟
kevinetore
في ٣ يوليو ٢٠١٩
كيفن ،
بعد الترقية إلى RN 0.59.10 ، لن تحتاج إلى اتباع أي من الجوهر
التعليمات بعد الآن.
ك
في الأربعاء ، 3 يوليو 2019 ، الساعة 15:42 ، كتب كيفن إيتور ، [email protected] :
شكرا جزيلا على الإصلاح! بعد ترقية رد الفعل الأصلي إلى الإصدار 0.59.10 ،
هل ما زلت بحاجة إلى تنفيذ الخطوات المذكورة هنا
https://gist.github.com/Kudo/cc40662163fbd69dd01d66fd99476c17 ؟-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/facebook/react-native/issues/24261؟
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AABPHZ6UMO5NS4F4OZ7RWPTP5S3DVANCNFSM4HC77RAQ
.
kbateman
في ٣ يوليو ٢٠١٩
لا يزال تطبيقي يتعطل على Meizu M5s M612H Android OS 6 مع RN-0.59.10. لقد خلق جديد قضية كماkelset المقترحة.
IvanStrelcov
في ٣ يوليو ٢٠١٩
لا يزال يتعطل على Caterpillar S41 (Android 8.0). تم حل المشكلة على جميع الأجهزة الأخرى. كما تم إنشاء مشكلة جديدة . أخبرني إذا لم تكن هذه هي الطريقة الصحيحة للقيام بذلك.
ebaynaud
في ٤ يوليو ٢٠١٩
اهلا ياجماعة
يتعطل تطبيقي أيضًا في بعض أجهزة Android عند تجميع 64 بت
هل تستخدم الإصدار 1.1.0 من حزمة رد فعل أصلي العناصر ؟؟
لأن رأس المكون يعطل تطبيقي وأيضًا مكون الصورة الرمزية عندما أضع رمز الخاصية أو العنوان
هل يمكن لشخص آخر التحقق مما إذا حدث نفس الشيء لهم؟
mgvictor7
في ١٢ يوليو ٢٠١٩
هل أتيحت الفرصة لأي من مالكي s7 لاختبار هذه المشكلة مع Hermes؟
nadavmos
في ١٥ يوليو ٢٠١٩
إذا كنت أستخدم تعطل التطبيق أدناه وقبله متجر google play
ndk {abiFilters "armeabi-v7a"، "arm64-v8a"، "x86"، "x86_64"}
إذا كنت أستخدم التطبيق أدناه يعمل ولكن غير مقبول من متجر google play
ndk {abiFilters "armeabi-v7a"، "x86"}
الرجاء مساعدتي في حل أي شخص
afras21
في ١٥ يوليو ٢٠١٩
لا يزال يتعطل على Moto G7 و Pixel 2 (كلاهما Android 9.0) مع 64 بت arm APK. إنه يعمل بشكل جيد مع 32 bit arm APK.
tanx
في ١٨ يوليو ٢٠١٩
@ afras21 - هذا لأن الخطأ موجود في إصدار 64 بت ، والذي يجعل متجر Google Play إلزاميًا.
jacquesdev
في ٢٢ يوليو ٢٠١٩
jacquesdev شكرًا jacq ، الآن قاموا بإزالة الإلزامية وهي تعمل الآن
afras21
في ٢٣ يوليو ٢٠١٩
@ afras21 تقصد أن Google قد رفعت قيود 64 بت من playstore؟
sahil290791
في ٢٣ يوليو ٢٠١٩
لدي نفس المشكلة. إذا قمت بتحديث مشروعي من 0.59.9 إلى 0.60.4 ، فهل يجب علي إصلاح المشكلة؟
claudioviola
في ٢٣ يوليو ٢٠١٩
لدي نفس المشكلة. أنا أستخدم حاليًا 0.59.9. إذا قمت بالترقية إلى 0.60.x ، فهل سيتم حل المشكلة؟
hiennguyen92
في ٢٣ يوليو ٢٠١٩
يرجى المحاولة أولاً إذا كان 0.59.10 قد حل المشكلات من أجلك.
إذا لم يكن الأمر كذلك ، فربما يستحق الأمر ترقية RN 0.60.4 وتشغيل Hermes بدلاً من ذلك.
Kudo
في ٢٣ يوليو ٢٠١٩
بتكرار ما قاله كودو ، فقط قم بإعطاء السياق وتلخيص المحتوى السابق لهذه المشكلة (لأنه ربما يكون من الصعب فرز العديد من التعليقات في هذه المرحلة):
إذا كان لديك 0.59.9 أو أقل ، فهذه مشكلة تم التحقق منها مع JSC القديم. إنه موضوع مئات التعليقات أعلاه (وفي قضايا أخرى). لا تقتصر المشكلة على 64 بت ، ولكنها تحدث غالبًا مع 64 بت.
0.60+ له العديد من التغييرات المفاجئة ، خاصة على Android.
إذا كنت لا ترغب في متابعة ذلك ، فجرّب 0.59.10 نظرًا لأنه يحتوي على الإصلاح (كما هو موضح أعلاه) مدمج مباشرةً في الإصدار / الإصدار - ويبدو أنه يعمل على حل المشكلة بالنسبة لمعظم الحالات.
لا تزال هناك حالات توجد فيها مشكلات لبعض الهواتف (والتي صادفتها أيضًا) ، راجع # 25494 - إذا كان لديك هذا ، فأقترح نشر علامات التكديس الخاصة بك على هذه المشكلة المفتوحة هناك. ومع ذلك ، إذا كنت تقول أن لديك 0.59.9 ، فيمكنك _ربما _ إصلاح مشكلتك بالانتقال إلى 0.59.10.
j-wang
في ٢٣ يوليو ٢٠١٩
MalcolmScruggsntorion @ harryt2
هل قمت بحلها؟ كيف تحل？ شكرا
HelloJack0
في ١٩ أغسطس ٢٠١٩
0.59.10 لم يحلها بالنسبة لي. سأحاول إجراء ترقية 0.60.x
rogerkerse
في ١٩ أغسطس ٢٠١٩
MalcolmScruggsntorion @ harryt2
هل قمت بحلها؟ كيف تحل？ شكرا
0.59.10 لم يحلها بالنسبة لي أيضًا. لا يمكنني الترقية إلى 0.60.x لأن بعض التبعيات الخاصة بي لن تعمل. حصلت على تجميع على Hermes ولكن شهدت ارتفاعًا كبيرًا في ANRs (الحمد لله على الطرح التدريجي). ما زلت جالسًا في متجر Play بإصدار RN 0.57.8 ولكن لا يمكنني تحديث تطبيقي بعد الآن بسبب متطلبات 64 بت. محبط للغاية ومحاولة تحديد ما إذا كنت ستعيد إنشاء التطبيق بالكامل باستخدام إطار عمل آخر.
harryt2
في ١٩ أغسطس ٢٠١٩
@ harryt2rogerkerse شكرا.
وضعي أسوأ. الإصدار الذي تم إصداره به أخطاء ، لذلك يجب علي ترقية تطبيق 64. لا يمكنني حل هذه المشكلة في الوقت الحالي. أحاول أيضًا استبدال الرفرفة ، ولكن ليس الاستبدال الكامل السريع.
HelloJack0
في ٢٠ أغسطس ٢٠١٩
لقد مررت بالفعل بمشكلة ارتطام React-Native بـ 0.60.5 وتمكين Hermes + 64-bit (والذي كان بمثابة ألم ، حيث أن ترقية رد الفعل الأصلي دائمًا) وما زلت أواجه هذه المشكلات على العديد من هواتف Android (بما في ذلك HUAWEI MYA-L41).
لقد جربت كل شيء وجدته في سلاسل الرسائل الأخرى دون الكثير من الحظ ، لذلك يمكنني أن أخبرك أن استخدام Hermes لا يصلح كل هذه المشكلات.
يعد رد الفعل الأصلي المحدث + Hermes و 64 بت مذهلًا على أجهزة Android الأخرى التي قمت بتشغيلها عليها ولم يشعر تطبيقنا أبدًا بسلاسة أكبر.
ومع ذلك ، كلما اختبرت على الجهاز المحدد الذي ذكرته (Huawei) ، فإنه يتعطل على الفور أو بعد فتح التطبيق لمدة 1-2 ثانية دون رسالة تعطل محددة ، ليس لدي أي أجهزة أخرى بخلاف ذلك الجهاز وأحدث Huawei ( الذي يعمل بشكل مثالي) لذلك لا يمكنني تزويدك بمزيد من المعلومات على الهواتف الأخرى.
إذا أحرز أي شخص أي تقدم في هذه المشكلة أو كان لديه أي أفكار لتسجيل مشاكلي بشكل أكثر تحديدًا ، فإن النصيحة مرحب بها دائمًا وأنا على استعداد لمشاركة أي معلومات تتعلق بهذه المشكلة.
شكرًا للأشخاص الموجودين في هذا الموضوع على تقديم الحلول ، ولكن لا حظ حتى الآن. 🙂
YoranRoels
في ٢٣ أغسطس ٢٠١٩
YoranRoels هل جربت تشغيل تطبيق نظيف تم إنشاؤه بواسطة init-native init؟ أتساءل ما إذا كان العطل ناتجًا عن RN نفسها أو بعض المكتبات أو الكود الذي كتبته.
armenbadalyan
في ٢٣ أغسطس ٢٠١٩
armenbadalyan شكرا على الاستجابة السريعة.
لقد أعددت للتو مشروعًا جديدًا وحاولت تشغيله على الجهاز ويبدو كل شيء على ما يرام ، لذلك في النهاية يبدو الأمر وكأنه شيء في الإعداد. هل هناك طريقة فعالة لتصحيح هذا لأن logcat الخاص بي لم يخرج أي شيء مفيد إلى جانب قتل com.<our_app_id> ؟
YoranRoels
في ٢٣ أغسطس ٢٠١٩
React Native 59.10 لا يحلها لنا أيضًا. لا يزال التطبيق يتعطل عند التشغيل الأول.
GreanBeetle
في ٢٦ أغسطس ٢٠١٩
GreanBeetle راجع https://github.com/facebook/react-native/issues/25494. 0.59.10 ، للأسف ، معروف في هذه المرحلة بعدم حل هذه المشكلة في جميع الحالات.
المسار الأكثر حداثة هو استخدام (كما في هذا الموضوع) ، 0.60+ و Hermes.
YoranRoels احصل على علامة مميزة من الجهاز. انظر: https://github.com/facebook/react-native/issues/24261#issuecomment -490239902
j-wang
في ٢٧ أغسطس ٢٠١٩
GreanBeetle يمكنك استخدام محرك V8 على 0.59.10 للتخلص من هذه المشكلة
https://github.com/Kudo/react-native-v8
manuhook
في ٢٧ أغسطس ٢٠١٩
شكرا @ جي وانغ. manuhook سيعطي الحل الخاص بك فرصة.
GreanBeetle
في ٢٧ أغسطس ٢٠١٩
GreanBeetle يمكنك استخدام محرك V8 على 0.59.10 للتخلص من هذه المشكلة
https://github.com/Kudo/react-native-v8
يمكن أن يؤكد أن هذا حل المشكلة بالنسبة لنا. 64 بت مع react-native-v8 على 0.59.10 لم يعد يتعطل بعد الآن ويمكننا أخيرًا دفع التحديثات مرة أخرى على Google Play. شكرا جزيلا!
tanx
في ٢٧ أغسطس ٢٠١٩
لقد جربت تسجيل شواهد القبور @ j-wang المذكورة ولكني لم أستخدم ذلك مطلقًا وكان ملفًا هائلاً يصعب قراءته ، بعد البحث لفترة من الوقت لم أجد حقًا سببًا جذريًا يمكن قراءته.
بعد أخذ نصيحة armenbadalyan ، بدأت في التساؤل عما إذا لم يكن شيئًا سخيفًا في بداية تطبيقنا وكان متأكدًا بدرجة كافية عند إزالة واجهة مستخدم المكون الأول ، لاحظت أن التطبيق كان يعمل مرة أخرى ومستقرًا. لذلك ، بعد المزيد من البحث ، لاحظت أن مكونًا معينًا تم إعطاؤه مشكلات حيث تم عرض الصورة.
في هذا المكون ، هناك فرصة لتمرير null source كمتغير react-native Image . استغرق الأمر مني بعض الوقت للبحث عن هذا ليس هناك أخطاء حقيقية واضحة ولكن هذا أخيرًا أصلح كل شيء بالنسبة لي وهو يعمل على جميع أجهزتنا الاختبارية. لا يوجد حتى الآن دليل على سبب عدم فشلها على جهاز الاختبار الآخر ...
قد يساعد الأشخاص الآخرين على تبسيط المكون الأول من تطبيقهم للتأكد من عدم تعطله في هذا الرمز.
TL ؛ DR : من المحتمل أن يكون هذا خارج الموضوع تمامًا الآن ، ولكن لمن يهمه الأمر: لا تستخدم null AS source متغير Image ، لا يوجد ' ر العمل على جميع الأجهزة. 😅
YoranRoels
في ٢٧ أغسطس ٢٠١٩
@ harryt2 نعم ، وأنا أيضا. حصلت على ارتفاع كبير في أخطاء ANR بعد الترقية إلى RN 0.60. +
nguyen95
في ١٢ سبتمبر ٢٠١٩
القليل من المساعدة لأولئك الذين ما زالوا يحاولون معالجة تعطل بدء التشغيل:
- تشغيل
adb logcatفي وحدة تحكم - انتظر حتى يتوقف البريد العشوائي في وحدة التحكم
- افتح التطبيق المعطل على جهازك
- أوقف adb logcat باستخدام Ctrl + c
- قم بالتمرير لأعلى وابحث عن الحادث
إنه لا يحل المشكلة ولكنه يتيح لك اكتشاف المزيد. لدي تطبيقان ، أحدهما يعمل بشكل جيد مع 64 بت ، ولا يزال يكافح على الآخر حتى لو كان لديهم نفس التكوين. جهازي المتعطل هو One Plus 5t (64 بت)
ivanfranchi
في ١٦ سبتمبر ٢٠١٩
لقد رأيت هذا للتو في إصدار جديد من تطبيقنا ، تم إنشاؤه باستخدام RN 59.10 ، وتحديداً على Samsung Galaxy Note9 على Android 9. أي شخص آخر يرى مشكلة مماثلة؟
msspshaw
في ٢٠ سبتمبر ٢٠١٩
msspshaw كما ذكر أعلاه وفي العدد الآخر ، نعم. يتجمد / يتعطل JSC الجديد بشكل عشوائي على أجهزة Android معينة لأنه يتم جمع القمامة بشكل غير حتمي - ثم يتعطل التطبيق بالكامل.
الحل هو الترقية إلى 0.60+ واستخدام Hermes ، أو تبديل JSC للإصدار 8.
j-wang
في ٢٠ سبتمبر ٢٠١٩
لقد جربت تسجيل شواهد القبور @ j-wang المذكورة ولكني لم أستخدم ذلك مطلقًا وكان ملفًا هائلاً يصعب قراءته ، بعد البحث لفترة من الوقت لم أجد حقًا سببًا جذريًا يمكن قراءته.
بعد أخذ نصيحة armenbadalyan ، بدأت في التساؤل عما إذا لم يكن شيئًا سخيفًا في بداية تطبيقنا وكان متأكدًا بدرجة كافية عند إزالة واجهة مستخدم المكون الأول ، لاحظت أن التطبيق كان يعمل مرة أخرى ومستقرًا. لذلك ، بعد المزيد من البحث ، لاحظت أن مكونًا معينًا تم إعطاؤه مشكلات حيث تم عرض الصورة.
في هذا المكون ، هناك فرصة لتمرير
nullsourceكمتغيرreact-nativeImage. استغرق الأمر مني بعض الوقت للبحث عن هذا ليس هناك أخطاء حقيقية واضحة ولكن هذا أخيرًا أصلح كل شيء بالنسبة لي وهو يعمل على جميع أجهزتنا الاختبارية. لا يوجد حتى الآن دليل على سبب عدم فشلها على جهاز الاختبار الآخر ...قد يساعد الأشخاص الآخرين على تبسيط المكون الأول من تطبيقهم للتأكد من عدم تعطله في هذا الرمز.
TL ؛ DR : من المحتمل أن يكون هذا خارج الموضوع تمامًا الآن ، ولكن لمن يهمه الأمر: لا تستخدم
nullASsourceمتغيرImage، لا يوجد ' ر العمل على جميع الأجهزة. 😅
+1 يعمل بالنسبة لي. كان لدي نفس المشاكل. شكرا جزيلا!
moneymc
في ٣٠ سبتمبر ٢٠١٩
شاهد أيضًا ما يحدث على Samsung Galaxy S7 IO-IL 086 على Android 7.0 RN 0.59.10
BracketMan
في ٧ أكتوبر ٢٠١٩
BracketMan هل تستخدم V8 بدلاً من JSC؟
EmilScherdin
في ٧ أكتوبر ٢٠١٩
EmilScherdin ahhh لا ، لست كذلك. سوف يعطيها فرصة وتقرير شكرا.
BracketMan
في ٧ أكتوبر ٢٠١٩
EmilScherdin يمكنني أن أؤكد أن التشغيل على V8 على RN 0.59.10 يعمل معي ، لا مزيد من الأعطال.
شكر!
BracketMan
في ٨ أكتوبر ٢٠١٩
نواجه نفس المشكلة على RN 0.59.10 مع v8. أرى أن JIT غير معطل لـ arm64-v8a وعلى الأجهزة ذات هذه البنية لدينا أعطال.
mmamoyco
في ١١ أكتوبر ٢٠١٩
mmamoyco هل لديك تعقب الصدمة من V8؟
Kudo
في ١٥ أكتوبر ٢٠١٩
Kudo نعم لدي سجل الأعطال. لقد انتقلنا إلى الإصدار 8 من JSC لأننا كنا نعاني من الكثير من الأعطال. لكن الشيء نفسه يحدث عند استخدام الإصدار 8. أدناه هو السجل
00 جهاز كمبيوتر 0000000000c31dd8 /data/app/my.app.id-a42vFQTz2lrEJMUnXdYsYA==/lib/arm64/libv8.so
# 01 جهاز كمبيوتر 0000000000c3437c /data/app/my.app.id-a42vFQTz2lrEJMUnXdYsYA==/lib/arm64/libv8.so
# 02 جهاز كمبيوتر 0000000000c30554 /data/app/my.app.id-a42vFQTz2lrEJMUnXdYsYA==/lib/arm64/libv8.so
# 03 جهاز كمبيوتر 0000000000c33070 /data/app/my.app.id-a42vFQTz2lrEJMUnXdYsYA==/lib/arm64/libv8.so
# 04 pc 0000000000bf2e94 /data/app/my.app.id-a42vFQTz2lrEJMUnXdYsYA==/lib/arm64/libv8.so (v8 :: internal :: ItemParallelJob :: Task :: RunInternal () + 24)
# 05 pc 0000000000a4d660 /data/app/my.app.id-a42vFQTz2lrEJMUnXdYsYA==/lib/arm64/libv8.so (v8 :: platform :: DefaultWorkerThreadsTaskRunner :: WorkerThread :: Run () + 56)
# 06 جهاز كمبيوتر 0000000000a4a074 /data/app/my.app.id-a42vFQTz2lrEJMUnXdYsYA==/lib/arm64/libv8.so
# 07 جهاز كمبيوتر 0000000000067ec4 /system/lib64/libc.so (__pthread_start (void *) + 36)
# 08 جهاز كمبيوتر 000000000001f2f4 /system/lib64/libc.so (__start_thread + 68)
AmandeepSingh06
في ٢٥ أكتوبر ٢٠١٩
كانت لدينا هذه المشكلة بالضبط في 0.59.1 وتمكنا من إصلاحها بالقيام بما يلي:
⛄️ هذه الاتجاهات ليست هي نفسها الموجودة في JSC-android README . لقد قمنا بتعديل أرقام الإصدارات وبعض الدلالات. و
canaryنسخة منjscلا إصلاح المشكلة. إنه الإصدار المطلوب بعد jsc-android @ canary ، انظر: هذا التصحيح للإصلاح الأصلي الذي تم دمجه في الريبو المتفاعل الأصلي. بفضل @ ravali121 للمساعدة في حل هذه المشكلة.
- أضف
jsc-androidإلى قسم "التبعيات" فيpackage.json:
dependencies {
...
+ "jsc-android": "^245459.0.0",
...
}
ثم قم بتشغيل npm install أو yarn (اعتمادًا على عميل npm الذي تستخدمه) من أجل تثبيت التبعية الجديدة في node_modules
- قم بتعديل ملف
android/build.gradleلإضافة مستودع المخضرمين المحلي الجديد المعبأ في حزمةjsc-androidإلى مسار البحث:
allprojects {
repositories {
mavenLocal()
jcenter()
maven {
// All of React Native (JS, Obj-C sources, Android binaries) is installed from npm
url "$rootDir/../node_modules/react-native/android"
}
+ maven {
+ // Local Maven repo containing AARs with JSC library built for Android
+ url "$rootDir/../node_modules/jsc-android/dist"
+ }
}
}
- قم بتحديث ملف تطبيقك
build.gradleالموجود فيandroid/app/build.gradleلإضافة تبعية JSC. يرجى التأكد من أن التبعية موجودة قبل تبعية React Native.
dependencies {
+ // Make sure to put android-jsc at the top
+ implementation 'org.webkit:android-jsc:+'
compile fileTree(dir: "libs", include: ["*.jar"])
implementation "com.android.support:appcompat-v7:${rootProject.ext.supportLibVersion}"
implementation "com.facebook.react:react-native:+" // From node_modules
}
- قم بتحديث ملف
build.gradleلتطبيقك الموجود فيandroid/app/build.gradleلاستخدام مكتبة JSC المطابقة الأولى.
android {
// ...
+ packagingOptions {
+ pickFirst '**/armeabi-v7a/libc++_shared.so'
+ pickFirst '**/x86/libc++_shared.so'
+ pickFirst '**/x86_64/libc++_shared.so'
+ pickFirst '**/arm64-v8a/libc++_shared.so'
+ pickFirst '**/libjsc.so'
+ }
}
sotownsend
في ٣١ أكتوبر ٢٠١٩
يمكن لأي شخص أن يساعد في الإجابة على هذا السؤال؟
https://github.com/react-native-community/jsc-android-buildscripts/issues/127
pengcao1
في ١١ نوفمبر ٢٠١٩
لا تستخدم
nullمثلsourceمتغيرImage، فهو لا يعمل على جميع الأجهزة. 😅
أنا أكره أن أقتبس منك فقط لكنني كدت أن أفقد الحل الخاص بك في ضجيج هذا الموضوع. شكرا جزيلاYoranRoels !! هذا أنقذ اليوم!
joshuapinter
في ١٩ نوفمبر ٢٠١٩
لقد وجدت موقعًا لاختبار الجهاز الحقيقي عبر الإنترنت ، حيث اخترت GALAXY S7 Edge ونظام التشغيل android 7.0 ، ولكن للأسف لم يحدث تعطل ، وأحاول استخدام طريقة YoranRoels التي تم تعيينها source متغير Image إلى {null} و {{ uri: null }} لكنها ما زالت لم تتحطم ، فظيع لا أعرف حتى كيف حدث ذلك ، هل يمكن لأي شخص مساعدتي.
JinYuSha0
في ٢٣ ديسمبر ٢٠١٩
كانت لدينا هذه المشكلة بالضبط في 0.59.1 وتمكنا من إصلاحها بالقيام بما يلي:
⛄️ هذه الاتجاهات ليست هي نفسها الموجودة في JSC-android README . لقد قمنا بتعديل أرقام الإصدارات وبعض الدلالات. و
canaryنسخة منjscلا إصلاح المشكلة. إنه الإصدار المطلوب بعد jsc-android @ canary ، انظر: هذا التصحيح للإصلاح الأصلي الذي تم دمجه في الريبو المتفاعل الأصلي. بفضل @ ravali121 للمساعدة في حل هذه المشكلة.
- أضف
jsc-androidإلى قسم "التبعيات" فيpackage.json:dependencies { ... + "jsc-android": "^245459.0.0", ... }ثم قم بتشغيل
npm installأوyarn(اعتمادًا على عميل npm الذي تستخدمه) من أجل تثبيت التبعية الجديدة فيnode_modules
- قم بتعديل ملف
android/build.gradleلإضافة مستودع المخضرمين المحلي الجديد المعبأ في حزمةjsc-androidإلى مسار البحث:allprojects { repositories { mavenLocal() jcenter() maven { // All of React Native (JS, Obj-C sources, Android binaries) is installed from npm url "$rootDir/../node_modules/react-native/android" } + maven { + // Local Maven repo containing AARs with JSC library built for Android + url "$rootDir/../node_modules/jsc-android/dist" + } } }
- قم بتحديث ملف تطبيقك
build.gradleالموجود فيandroid/app/build.gradleلإضافة تبعية JSC. يرجى التأكد من أن التبعية موجودة قبل تبعية React Native.dependencies { + // Make sure to put android-jsc at the top + implementation 'org.webkit:android-jsc:+' compile fileTree(dir: "libs", include: ["*.jar"]) implementation "com.android.support:appcompat-v7:${rootProject.ext.supportLibVersion}" implementation "com.facebook.react:react-native:+" // From node_modules }
- قم بتحديث ملف
build.gradleلتطبيقك الموجود فيandroid/app/build.gradleلاستخدام مكتبة JSC المطابقة الأولى.android { // ... + packagingOptions { + pickFirst '**/armeabi-v7a/libc++_shared.so' + pickFirst '**/x86/libc++_shared.so' + pickFirst '**/x86_64/libc++_shared.so' + pickFirst '**/arm64-v8a/libc++_shared.so' + pickFirst '**/libjsc.so' + } }
كنت منقذا للحياة! ❤️ لقد كنت أبحث عن إجابتك لمدة ثلاثة أيام للصق هذا الرمز وتغيير إصدار jsc-android إلى الإصدار الذي ذكرته بالضبط. وهي تعمل الآن! حدث خطأ عندما قمت بترقية إصدار RN من 0.59 إلى 0.60. تم كسر التطبيق لنظام Android فقط ، وكان iOS جيدًا. أغرب شيء هو أنه تم تجميع التطبيق بنجاح بحيث بدا كل شيء رائعًا ، ولكن عند إطلاقه ، تعطل على الفور
LPranulis
في ١٦ يناير ٢٠٢٠
القضايا ذات الصلة
upbit
·
3تعليقات
lazywei
·
3تعليقات
aniss
·
3تعليقات
ghost
·
3تعليقات
josev55
·
3تعليقات
التعليق الأكثر فائدة
hramosmkonicek اعتبارا من الآن يمكننا أن نستنتج أن هذا يبدو أن مشكلة مع أحدث RN 0.59 الإفراج، مما يؤثر على الروبوت يبني تعمل على
Samsung S7،S7 Edgeبعد أن قدمت دعما لarm64-v8a،x86_64، إزالتها منbuild.gradleلا تؤدي إلى تعطل التطبيق ، مما قد يؤثر على تشغيل التطبيقات بعد1 August 2019وفقًا لسياسة دعم Google Play 64 بت. نود يا رفاق لفت بعض الانتباه إليه ، من فضلك؟