Re: [心得] 非native開發app，反而讓開發過程更痛苦

[jsgoc (jsgoc)]

回一篇文章和大家交流一下  我想闡述的總結先寫一下

[總結懶人包]

是每個程式語言都有它的特性和適合的地方

所以我的建議是 技術圖多開不同語言 (不要只守單一語言)

這樣才不會讓自己視野和想法被限制住



[JAVA & C]

現在大家在使用android lib時候 都是直接使用jar檔到Gradle

所以久而久之就忘記裡面也很多C語言 (JAVA透過JNI呼叫C,這也是JAVA流行原因之一)

因為魯叔經歷過痛苦JNI過度的日子 就是JNI要自己刻 所以JAVA和C都要會之互博之術

雖然很多現成的C lib可以直接用JNI包起來 但是測試起來還是頗累(要編譯)

2006左右曾經有個案子 當時博班學長聽到要用JAVA實作都皺眉頭(JAVA剛流行)

嚷嚷說C++才是最強 全部都用C++才是王道 (學長是199X~200X?年代學C++,非JAVA)

最後考慮平台移植性(我們使用很多不同application layer protocol,ex:diameter,AAA)

老闆還是決定用JAVA(200X~以後幾乎是必修) 結果那份code活過了4~5年

如果當時選擇使用C++的話程式碼活不超過1年 需要重新編寫

這就是當選用語言時會考慮到你寫的以後還會不會有人使用




回顧2004~2006左右 當時JAVA在推廣的時候 就是遇到JNI的缺乏(需要有人去填洞)

但因JNI是開放的 所以大家都可以來填洞 (也可以純JAVA實作)

由於JAVA跨平台特性 可以跑在linux(免錢)可以跑在windows(要錢) (當年很潮der)

記憶體又開始便宜的時候 JAVA的優勢就漸漸跑出來 雖然很跑很慢 現在還是很慢...


那為什麼大家手上android手機apk跑得還不錯 (不管SOC裡面是intel或arm)

因為現今JNI已經相當完善加上純JAVA的package也變多 而且都在github可以找到

(有時候呼叫的雖然是JAVA內建API 你去追下去的話 有時候也會發現他也是呼叫JNI的C)

需要效能的都是透過JNI然後用C去跑 (需要加速注重效率的部分就用C就對了)

而UI抽象邏輯部分(Button/Dialog等等之類)考慮跨平台的就還是使用JAVA(其實底層還是C去畫圖)

這樣就可以兼顧跨平台和效能 廠商不會因為晶片不一樣要一直不斷地重複編寫編譯apk

一個apk可以到處跑 (有JVM前提)

跨平台只要重新編譯JNI的C (如果有cpu instruction加速也寫在這邊)

JAVA的Source Code都可以完全保留

舉個例子 如果有在使用android media player的人 我們來看ExoPlayer

https://github.com/google/ExoPlayer/blob/release-v2/extensions/ffmpeg/src/main/jni/ffmpeg_jni.cc

對 沒錯 decoder是使用c來實作  原因是什麼

c語言的特性 省記憶體/有效率/可呼叫DSP加速/直接輸出direct buffer(直接控制記憶體)

加上已經很多以實現實作的decoder可以使用 為什麼還要用JAVA寫一次?

那JAVA特性是什麼 UI抽象元件可以跨平台 TCP之上的protocol也很適合跨平台

像OKHttp裡面的parser/protocol就是使用JAVA實作

如果你是效能控 沒有最快不甘心 你也可以用C實作parser/protocl再用jni包起來

但是如果此段程式碼只佔一個操作的1%  你瘋狂加速這段讓速度快50%

可是總體速度只快0.5%  這你就要考慮有無必要用C去實現

所以掌握好每個程式語言特性 你的視野會變得比較開闊

如果你要說JAVA 484寄生在C身上啊 我會說他們是互補足彼此的缺點

所以寫JAVA不代表不需要寫C (遇到效能問題用C就對了)

同樣的寫js不代表以後不需要寫JAVA (遇到有現成ecosystem先用jar就對了)

你會發現很多react-native-XXXX很多只是包一層ReactPackage再包jar

為什麼? 因為沒必要再寫一次啊 有現成就用現成 和當初C decoder一樣啊 現成 讚讚讚

而且JNI編譯一次之後 就可以改你常改你的java soure code (JNI編譯時間可以省掉 讚)

RN也是

RN編譯一次後就可以瘋狂畫圖UI 每改一次UI都不用重新包裝media player jar.. etc


[js & JAVA]

js的特性是動態 不需重新編譯就可以運行 語法乾淨簡潔 這是他最大優勢

而JAVA和C的缺點就是需要編譯 所以當大量需要客製化UI時候或測試撈web api資料時候

js的優勢就跑出來 加上FB對於React的Virtual DOM實作是使用js 可以直接現成使用

加上大量flux pattern lib都是使用js實現(PS:你也可以使用JAVA或C++實現以上東西,只是目前沒有)

也導致React Native出現(裡面有個東西叫做ReactPackage類似以前JNI)

而這一波我覺得比較可怕的是 npm現在已經有很多現成的js package

而且npm社群相當龐大 所以後勁會比以前JAVA那一波更大

(當時JAVA很多lib只有幾個公司努力自己刻+一些社群力量+公司自己客製化的JNI(沒公開))

而現在npm社群力量很強大(很多人下載就會被FB或Google帶走) 再加上FB公司在後面支撐

如react, redux(Author去FB), redux ecosystem, flux, immutable, rxjs(Author去Google)


另外讓我覺得比預期還短的是 RN的黑暗時期比我想像中的短

(這裡黑暗時期是指有比較規模人數加入社群開始計算到有企業使用,不是指RN推出時候)

例如airbnb和ig都有使用且產品化 我的低階手機跑的也是順暢

加上從去年開始js直接跳過JAVA直接呼叫C來做CSS layout時候 UI效能有很明顯的提升

理論上CSS layout js -> JAVA -> C,去年js -> C (JAVA???)

那js的UI未來可以跨到哪 有ios/android/web/windows

而後面兩個還在發展 還有PWA/Webassembly的加入 所以未來結果是怎樣我也說不明白

不過我可以確定的是跨平台和語言特性 從2003到現在一直是領導軟體發展的走向
(從以前跨OS/CPU 到現在 跨Web和APP)

還有就是程式語言/環境生態不斷的進化 讓更多人加入一起寫程式

例一:程式語言語法

java:當時就讓看不懂C pointer的能可以一起來寫程式

js:免除了JAVA/C++一堆語法(syntax)包袱 做一樣的事情 但是程式碼變得更簡潔

例二:抓gps location

c++：(open com port->select protocol->parsing string->get position->close com)

js：navigator.geolocation.getCurrentPosition done

一行就把以前要做的事情都包起來 我就只是想知道我位置啊 還要去研究硬體知識

gps是用serial溝通還是i2c 用什麼protocol



結論

多看多摸 不要只守住單一語言 對你和未來發展是有幫助的

打算守住單一語言 吃到退休 不是不可能 只是案例很少

尤其台灣軟體開發都是跟者美國在走 就好像當初JAVA的UI取代比C/C++的gtk/qt的UI一樣

現在大家手持的跑JAVA還是居多  手持裝置跑gtk ui不是沒有 只是很少和凋零

未來你說js會不會普遍和廣泛使用 目前看來後勢是相當不錯的

至少npm環境和很多大公司(FB/Google/Microsoft)都參與進來

我覺得比十幾年前那時候好的太多 我寫下去的程式碼 以後可以重複使用

現在時間點很像2004~2007時候一樣 JAVA會不會大量廣泛使用?

但是現在台灣金融業/電信業已經普遍使用JAVA(雖然都是購買國外機器和軟體再修修改改)


推 ian90911: 推
推 tz5514: 推
→ diabloevagto: 現金(X)  現今(O)
→ diabloevagto: 另外可以多了解每個語言/lib出現所要解決的問題
→ diabloevagto: 可以幫助選擇與評估
→ pttworld: 怎麼記得gtk for c, Qt, wxWidget for c++
補上
→ jsgoc: 補一篇文章https://goo.gl/2Nv8yE 如果考慮code要放1年以上
→ jsgoc: 我覺得現在學kotlin是不錯選擇 他其實也是跑在JVM上
→ jsgoc: 不用擔心相容性 但是語法更乾淨
推 jackblack: 推這篇
推 wildli0422: 拜託不要刪文阿阿阿 這篇好棒
推 gmoz: 優文
推 bakedgrass: 推
推 freedls: 推
推 zeussteven: 好文！！ 真的不能死守一種語言。
推 swallowcc: 推
推 duck10704: push
※ 編輯: jsgoc (110.28.233.145), 10/17/2017 17:58:09
推 visa9527: JS的code壽命現在感覺超長，剛出時覺得都短命仔 script
→ visa9527: 到底是誰把 JS 從瀏覽器的牢籠裡放出來變大怪獸的...
→ visa9527: 不過JS在瀏覽器上始終不是直接繪製UI，都是透過HTML+CSS
→ visa9527: 它只是一個控制器而已，就算svg / canvas仍然只是控制
推 dannypsnl: node吧？以前也有類似的努力，不過node特別成功
推 makeman: 幹嘛舉gtk  qt就全包了  XD
推 hangigi: 推一個 讚讚讚
推 Wolfken: 有兩個關鍵的地方不一樣，1. 超過20萬行以上時，Java比
→ Wolfken: C++容易維護，雖然是說規模大統統很難維護，但是C++更難
→ Wolfken: 而同樣超過20萬行，改成js並不會比Java容易維護，反而更
→ Wolfken: 難，因為動態語言跟js一些先天限制，導致超過一定行數就
→ Wolfken: 很難維護 2. npm社群快速擴張有好也有壞，其他語言要做什
→ Wolfken: 麼事大致上都能找到一個go to lib，npm太多lib反而造成這
→ Wolfken: 個生態圈沒有標準出來，每個團隊的lib stack都不一樣
→ Wolfken: 對技術累積跟轉換反而帶來門檻
推 doranako: 跨平台弱點就在於原生sdk跟os改太快，一年一大版，跟不
→ doranako: 上
推 CaLeLu: 詳細推
推 jjwei: push
→ dreamnook: 用過幾年Java跟c++的感想是：讓我用Python(?
推 zenixls2: 推這篇，不過除非跨平台可以自己parse原生api生wrapper
→ zenixls2: 不然都得慢慢等人implement
推 atpx: 好聞推
→ remmurds: JAVA在安卓上快主要是因為aot還有gc的改進
→ remmurds: 另外有個東西叫ReactiveX給原po參考一下
推 SMNOONMS: 高級推。XD
推 fuanan: 這篇寫得真的不錯 推推！
→ angusyu: aot ? ART吧