המלצה | זית לאנדרואיד - יתכן!

לא-מתייאש

@avrasha
אנדרואיד 8 זה מאוד מסובך, ואי איפשרי בשיטה שהוא פעל.
אחרי שניסיתי את האפליקצייה של @אפרול זה נתן לי מוטיבצייה לתת לlucene (מנוע חיפוש של זית) תמיכה אמיתית לאנדרואיד וios והלכתי עם גישה אחרת לגמרי, קצת יותר כבדה בapk אבל עם ביצועים יותר טובים ועם תמיכה מאנדרואיד 10 וגם תמיכה בios. זה אפשרי עם אותה שיטה גם לתמוך באנדרואיד 8 אבל זה מסובך מידי בשביל הרווח שזה יתן
https://github.com/NucleusFramework/NucleusJvmAccess @אפרול אם אתה רוצה להיות הראשון שינסה את זה (כרגע צריך להמתין שgradle יאשרו לי אותו)

אריה 6

@לא-מתייאש
כדאי אולי לחכות לאפליקציה שלך?
או להשתמש בנתיים בשלו?

מיישה ש

יש אפשרו לשלוח קישור להורדה לנטפרי עכשיו?
תודה

לא-מתייאש

@אריה-6 כתב:

@לא-מתייאש
כדאי אולי לחכות לאפליקציה שלך?
או להשתמש בנתיים בשלו?

שלי יכולה לצאת בעוד 3 חודשים - שנים, או שלא תצא בכלל, וודאי שאפשר להשתמש בשלו

אריה 6

@לא-מתייאש
לא רשמת שהוצאת עוד סוג?
התכוונתי להשתמש בזה

avrasha

@לא-מתייאש כתב:

ועם תמיכה מאנדרואיד 10 וגם תמיכה בios. זה אפשרי עם אותה שיטה גם לתמוך באנדרואיד 8 אבל זה מסובך מידי בשביל הרווח שזה יתן

החזון שלי שאברך יוכל לשים את זה בנגן/טאבלט קטן שיקנה מעלי. אם כרגע הנגנים והטבלטים שם מאנדרואיד 10 אין הכי נמי. אם זה עדיין אוחז באנדרואיד 9 ומעלה אולי כדאי לשקול לעשות גם לזה. אני יכול להשיג שיאומי חצי טאץ ע"מ לנסות אם אתה צריך נראה לי שזה מאנדרואיד 10 ומעלה. כמובן שהוא מוגבל במקום ואין לו אפשרות להתקן חיצוני.
בכל אופן החידוש שזה עכשיו גם לאנדרואיד ושיהיה ניתן להתקין חלק מהספרים לפי בחירה [תלוי בכמות המקום שיש] ושיהיה ניתן להתקין גם על התקן חיצוני מאוד מבורך ולדעתי יכול להרבות תורה.

לא-מתייאש

@אריה-6
[מתורגם על ידי AI]
אוקיי, אני מתחיל מההתחלה. יש שני קשיים גדולים בהעברת זית לאנדרואיד. הראשון הוא מנוע החיפוש לוסין. לוסין הוא מנוע החיפוש הטוב בעולם שזמין לקהל הרחב. הבעיה היא שאף על פי שלוסין היא ספרייה של ג'אווה, זו לא ג'אווה שתואמת לאנדרואיד. כדי להבין את הבעיה: כשגוגל רצתה להציע למפתחים שפה לפיתוח אפליקציות אנדרואיד, היא רצתה שפה שכולם כבר מכירים, אבל לא רצתה לשלם רישיון. לכן היא מימשה מחדש לגמרי מכונה וירטואלית של ג'אווה, כלומר, בגדול, היא העתיקה רק את התחביר של השפה בלי להעתיק את המנוע שמריץ אותה (מה שעלה לה עשר שנים של משפטים מול אורקל). זה מה שנקרא ART. בקיצור, הם נעצרו בג'אווה 11, ולכן אנדרואיד מסוגל להריץ רק תחביר של ג'אווה 11. אחר כך הם פיתחו את ה"דה-שוגרינג" כדי להמיר ג'אווה 17 לג'אווה 11, כך ש-ART יוכל להריץ אותה. בינתיים הגיעה קוטלין, ובנוסף לכך שהיא מודרנית יותר, לא הייתה לה שום בעיית רישוי, ולכן הם החליטו להפסיק כמעט לגמרי את התמיכה בג'אווה באנדרואיד ולהפוך ל"קוטלין תחילה".

אבל בינתיים, עולם ג'אווה שנמצא בשימוש בשרתים המשיך להתפתח, ולוסין כמובן מיועד לשרתים, ולוסין 10 (הגרסה הנוכחית) דורש ג'אווה 21. מה שהחבר שלנו עשה זה לכתוב מחדש חלקים מסוימים של לוסין ואז לקמפל אותם מחדש כדי שיעבדו באנדרואיד. גם אני העליתי את האפשרות הזאת בגיטהאב, אבל הבעיה בדרך הזאת היא שהיא תנעל אותנו לתמיד על לוסין 10, כי לוסין 11 ידרוש ג'אווה 25 ושם כבר יהיה בלתי אפשרי לתקן אותו כדי שיעבוד באנדרואיד. ג'אווה עוברת מהפכה בשפה: חוטים וירטואליים, וולהלה שמגיעה בג'אווה 29, ועוד ועוד. ספריות שידרשו גרסה עדכנית של ג'אווה יהיו בלתי אפשריות להרצה באנדרואיד. ומי שמכיר אותי יודע שאני שונא לעשות מחדש עבודה שמישהו כבר עשה (בגלל זה רציתי להשתמש בעולם ג'אווה בשביל זית, כי היו לי כל הספריות בהישג יד), ובעיקר אני שונא לעבוד לחינם. לעבוד כדי להתאים את לוסין 10 כשאני יודע שזה יישבר לי בלוסין 11, זה בלתי נתפס. דבר נוסף: לי ממש לא אכפת להעביר את זית לאנדרואיד. לדעתי טאבלטים של אנדרואיד הם סמארטפונים גדולים. מה שמעניין אותי זה להעביר אותו לאייפד, ולאייפד אין שום תמיכה בג'אווה, ולכן אין שום תיקון אפשרי, והיה צריך לכתוב מחדש את לוסין, וזה חסר כל היגיון. גם אם יש מי שיגידו שהבינה המלאכותית תעשה את זה, כולם יודעים מה דעתי על זה, אין צורך לחזור על זה.

בעקבות האפליקציה של החבר שלנו, שהתנהגה מצוין על טאבלט אנדרואיד, התחלתי לחפש פתרון לאייפד, ובאמת אחרי קצת חיפושים מצאתי במאגר הגיטהאב הרשמי של אורקל (החברה שמחזיקה היום בג'אווה) את אופן-ג'י-די-קיי מובייל. בקיצור, מדובר במכונה וירטואלית אמיתית של ג'אווה שמאפשרת להריץ קוד ג'אווה אמיתי באנדרואיד ובאייOS. זה פרויקט שאף אחד לא מכיר, אבל הוא מתוחזק. ה-JDK אפילו לא מקומפל מראש. עשיתי לו פורק רק כדי להגדיר מערכת אינטגרציה שמקמפלת אותו לאייOS ולאנדרואיד: https://github.com/NucleusFramework/openjdk-mobile. הבעיה היא שהמכונה הווירטואלית עובדת על ידי קומפילציה של הקוד תוך כדי ריצה, מה שנקרא JIT (וזה מה שהופך את ג'אווה ליעילה כל כך), אבל פרקטיקה זו נחשבת מסוכנת בעיני אפל ולכן אסורה. אבל אורקל הגדירה את המכונה הווירטואלית לאייOS כך שרק מפרשת את הקוד בלי לקמפל אותו. אז כן, מאבדים הרבה ביצועים, אבל ההימור שלי היה שבחיפוש פשוט, ועם מכשירים חזקים כמו של אפל, לא נרגיש בזה, ואכן מגיעים ל-1.5 שניות לחיפוש, וזה סביר אחרי אופטימיזציה. ואז החלטתי לבצע את המשימה באופן אוטומטי, ואם כבר עושים את זה באייOS, עשיתי את זה גם באנדרואיד במקביל, כי למה לא. וזה הפרויקט ששיתפתי: מודול שמאפשר לשלב מכונה וירטואלית אמיתית של ג'אווה באייOS ובאנדרואיד ולהריץ קוד ג'אווה באופן כמעט שקוף. ואחרי כמה מבחני ביצועים הבנתי שהביצועים של מכונה וירטואלית אמיתית באנדרואיד טובים עד פי 8 מהמכונה הווירטואלית של אנדרואיד (ART).

הקושי השני הוא ממשק המשתמש של זית, שנבנה עם המסגרת ג'ואל של ג'טברינס, שתוכננה ליישומי שולחן עבודה מורכבים, ואותה אין שום סיכוי להעביר לאנדרואיד. מה שהחבר שלנו עשה זה לכתוב מחדש לגמרי ממשק שדומה לזה של גוגל, בעזרת ממשק מטריאל של גוגל שגמיש מאוד, ולכן הוא הצליח להעביר בקלות רבה את הצבעים וכו'. גם כאן, זו לא בהכרח הגישה שהייתי בוחר, ולא הייתי משתמש במטריאל באייOS, כי כמו שאמרתי, זית תוכנן קודם כול למק ואחר כך לווינדוס, כי למה לא. ואם אוציא גרסת אייפד, היא תעבוד גם באנדרואיד, כי למה לא, אבל לא תתוכנן קודם כול לאנדרואיד. אחרי זה, אני חושב שאת חלק מהרכיבים באנדרואיד אעשה במטריאל, כי זה לא לוקח הרבה זמן. בקיצור, הכול יהיה תלוי מאוד בזמן שיהיה לי.

פלמנמוני

@לא-מתייאש

אם לא היית מתרגם, לפחות היינו חושבים שאם היית מתרגם היינו מבינים...

לא-מתייאש

@פלמנמוני כדי לפשט קצת את העניין, גם זית אינה רצה על JVM מסורתית, אלא מהודרת לקוד מכונה באמצעות GraalVM. ההבדל הוא ש-GraalVM הוא פרויקט מקורי של אורקל, וכשעיינתי בקוד המקור שמתי לב שיש בו גם יעד ל-iOS ול-Android, אלא שמערך הבנייה האוטומטי פשוט לא כלל אותו. לכן עשיתי אותו דבר: יצרתי עותק נפרד של המאגר והתאמתי את מערך הבנייה האוטומטי כך שיפרסם את סביבת הריצה. כך הגעתי לביצועים מהירים פי 9 ב-iOS ולגודל חבילה קטן פי 2.5! בנוסף, זה צורך פחות זיכרון עבודה מ-JVM אמיתית. כל זה כדי לומר שבסופו של דבר, זית על iOS אפשרית לגמרי, עם פתרון יציב לטווח ארוך, ובנוסף מהיר מאוד.

Here are all the benchmarks I ran, with Zayit's real index (7M documents). App benchmarks are medians of 3 runs on Android and one run on iOS, with OS caches dropped before each run on Android.

Android (arm64 emulator, Android 15)

Full app: hybrid search (lexical + semantic)

	ART (patched Lucene)	HotSpot (NJA)	GraalVM (NJA)
First search, cold (includes runtime start)	1.41 s	2.11 s	1.51 s
First book lookup, cold	97 ms	108 ms	–
5 warm rounds, total	5.82 s	5.27 s	6.01 s
Search, first page	83 ms	75 ms	85 ms
Search, next page	9.5 ms	9.6 ms	9.5 ms
Facets	8.0 ms	8.1 ms	7.8 ms
Highlights (by meaning)	20 ms	21 ms	23 ms
Book suggestions	3.3 ms	4.5 ms	3.0 ms
Peak memory (PSS)	426 MB	559 MB	481 MB

Full app: lexical search

	ART (patched Lucene)	HotSpot (NJA)	GraalVM (NJA)
First search, cold	0.92 s	1.55 s	0.91 s
First book lookup, cold	86 ms	104 ms	–
5 warm rounds, total	7.29 s	5.75 s	7.78 s
Search, first page	75 ms	59 ms	79 ms
Search, next page	75 ms	58 ms	76 ms
Facets	8.4 ms	7.9 ms	9.1 ms
Highlights	0.4 ms	0.4 ms	0.4 ms
Book suggestions	4.5 ms	3.6 ms	3.4 ms
Peak memory (PSS)	337 MB	332 MB	329 MB

I didn't extract the first-lookup time from the GraalVM runs.

App size (per arm64 device)

	ART (patched Lucene)	HotSpot (NJA)	GraalVM (NJA)
App installed	42.7 MB	~98 MB	58.1 MB
Added by Lucene	~3 MB (dex)	~58 MB (JVM + Java runtime)	~19 MB (`libnja.so`)
Download (compressed, estimate)	~1–2 MB	not measured	~7 MB

Lucene alone (no app around it), GraalVM

	GraalVM, warm
Phrase search	1–3 ms
Facets	1–4 ms
Vector search (KNN), warm disk cache	3–10 ms
Vector search (KNN), cold disk cache	130–500 ms
Memory (RSS)	63 MB

I only ran the Lucene-alone test with GraalVM on Android.

iOS (simulator)

HotSpot isn't possible on iOS (Apple forbids JIT compilers), so the JVM option is Zero, its interpreter. ART is Android-only.

Full app: hybrid search

	Zero (NJA, JVM)	GraalVM (NJA)
First search, cold (includes runtime start)	4.63 s	0.82 s
First book lookup, cold	240 ms	206 ms
Search, first page	1.18 s	144 ms
Search, next page	50 ms	41 ms
Facets	148 ms	18 ms
Highlights (by meaning)	15 ms	14 ms
Book suggestions	67 ms	48 ms
Memory after warm-up (peak)	386 MB (422)	390 MB (430)

Full app: lexical search

	Zero (NJA, JVM)	GraalVM (NJA)
First search, cold	4.15 s	0.52 s
First book lookup, cold	243 ms	181 ms
Search, first page	1.11 s	142 ms
Search, next page	1.11 s	127 ms
Facets	146 ms	18 ms
Highlights	3.5 ms	3.5 ms
Book suggestions	68 ms	48 ms
Memory after warm-up (peak)	148 MB (163)	124 MB (155)

App size

	Zero (NJA, JVM)	GraalVM (NJA)
Added by Lucene	~50 MB (VM + Java runtime bundled)	~20 MB (one object linked into the app)
Download (compressed, estimate)	not measured	~7 MB

Lucene alone (no app around it), warm

	macOS HotSpot (reference)	iOS GraalVM
Phrase search	1–2 ms	1–2 ms
Facets	1–3 ms	1–4 ms
Vector search (KNN), warm disk cache	~2 ms	~1.5 ms
Vector search (KNN), cold disk cache	130–250 ms	130–250 ms
Memory	–	61 MB

Correctness

Check	Result
NJA test suite, iOS GraalVM	2008 / 2008
NJA test suite, Android GraalVM (x86_64 emulator, CI)	passed
NJA test suite, Android ART and Android HotSpot	2008 / 2008 each
Same search results, iOS GraalVM vs desktop JVM	byte-identical, hybrid search included

Summary:

On Android, GraalVM is as fast to start and nearly as light as ART, with the real Lucene. HotSpot is the fastest once warm, but heavier, bigger, and slower to start.
On iOS, GraalVM is about 8× faster than Zero, starts about 5–8× faster, and adds less than half the size.

בנימין מחשבים

@לא-מתייאש

עכשיו הכל מובן

הדבר היחיד ש(נדמה לי ש)אני הצלחתי להבין זה שלא-מתייאש כמעט התייאש מזית לאנדרואיד/iOS ועכשיו הוא כבר לא-מתייאש שאפו, באמת!