回一篇文章和大家交流一下 我想闡述的總結先寫一下
[總結懶人包]
是每個程式語言都有它的特性和適合的地方
所以我的建議是 技術圖多開不同語言 (不要只守單一語言)
這樣才不會讓自己視野和想法被限制住
[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(雖然都是購買國外機器和軟體再修修改改)