如何看待使用 native 開發 Android/iOS 跨平台應用？

01-05

我們leader要求我們把app的所有業務邏輯全部用c/c++實現，各個平台只做ui和轉換層，實現代碼的通用，從而實現跨平台。
於是乎，我們開始自己寫httpclient，線程線程管理，handler，message，imageloader，cache……此處省略一萬字。
歷時半年，我們的app出來了，但是性能極差，cpu和內存都吃得厲害。

你們如何看待這種做法？

在編程領域，「造輪子」的門檻很可能比「造車子」高至少十倍——很多領域甚至都不止要高一萬倍。

所以，當前輩告誡我們不要「重複造輪子」的時候，千萬別以為人家的意思是「輪子這麼簡單而且別人已經造出來了的東西，實在沒什麼稀罕的，就不要自己再造一個了」。

——恰恰相反，這句話真正的意思是：「看似簡單的輪子，其實後面可能隱藏著一整個產業鏈，其中的很多環節用到的還是普通程序員一輩子都摸不到邊的高科技：所以花費時間搞一個拙劣的模仿品是愚蠢的，不如直接用現成的、高質量的工業產品」。

反過來說也對：當你決定自己造一個輪子時，千萬別輕易認定這只是個做xx工程時稍微花上兩天就可以搞出來的「附帶品」；事實上，「造一個輪子」很可能是比你們那個自以為宏大的、面向終端用戶的應用宏大無數倍的東西。

——如果你覺得「我們設計個更美觀好用的藥瓶吧，隨便探索一下藥瓶里裝的結晶牛胰島素怎麼化學合成」很可笑，那麼……寫一個服務普通用戶的簡單程序時「隨便造一個輪子」很可能同樣可笑。

說的更直白一點——如果你們那個自己造「httpclient，線程線程管理，handler，message，imageloader，cache……」的輪子、都還能在半年內做出來的應用，實際上至多值幾個人日的話；那麼你前面提到的每一個詞，哪怕只是穩定性/性能勉強達到及格線，都需要至少一個人月。

換句話說，你們相當於在做一個普通工程師也只需要幾個人日的小項目時，打算「順便」把領域專家也需要至少6個人月的中型項目搞定。

並不覺得是腦子有病，之前dropbox就這麼干過，還把他們的方案開源了，據他們說代碼復用率達到了80%。

只是你們leader對團隊水平判斷不足，所以駕馭不了c++，另外，如果想跨平台的話，現在有更好的方案呀，比如react native

我十年前都有你說的整套東西了，放Android上仍然不爽，倒不是功能無法實現，主要是現在找不到靠譜又不算特別貴的C艹工程師了，編碼能力強的都不好找。但你說程序大占內存是什麼鬼，我是做車載音響整機的，不算圖標整體七八個App加起來程序都不到3M(準確來說是一個APP七八個Activity),內存佔用除了播視頻外，五六個同時開也只是十幾兆的樣子，用C艹能寫得又大又占內存也真是人才

react native 不就是你說的東西嘛。可以做到一定程度的跨平台。

這說明，有這想法的公司不少啊。但是真心沒必要自己造一套，拿個現成的跨平台框架去做多好。

移動端ios android 用c++做網路層存儲層好像是通用做法。

邏輯層放到c++這一層的比較少見，但也不是不可以，只是介面會變的很蛋疼，而且很多系統相關的東西很難封裝，好處就是跨平台代碼不用寫兩份。

至於handler線程這些，可以用現有的庫，也可以自己寫，httpclient就真的不要自己寫了。。

如果說性能不行，那應該不是採用這種跨平台方案的鍋，

可能要麼是架構設計有問題，要麼是實現有坑。

謝邀，這個leader不是沒帶過移動端團隊的問題了。是腦子有屎。

ndk開發是沒問題，但是那麼多開源庫都不用，一點點重複造輪子，費時費力，圖什麼？

而且我不信這半年就沒人提出過反對意見，他不聽，老闆也不聽？

不過對於個人發展來說，在這種項目裡面過一遍，對ndk一定有個全面的認識了，是好事。

目測發生了內存泄露。

……迷之被邀請。

話說這就是傳說中的「重複造輪子」？

有人出錢學了一遍底層，美滋滋

從企業成本，和工程師角度來講，這個領導是個大坑。從程序員角度來講，message，imageload，cache，這些，你佔了大便宜，在有人付你錢的情況下，把這些東西走了一遍，很有好處。以後你就知道功底和只會call API的區別了

一個農民本來去種田,結果為了化肥成了化學家，為種子成了生物學家

其實也不難，我就搞過類似的幾乎95%的代碼可以服用。只要各個平台吧opengl 的surface 搞好委託給c艹就行了

這種架構並不少見，用native做成又大又慢也只能說是開發團隊能力跟不上了。

我覺得吧，你們的leader是想搞點事情，然後到處吹牛逼，跳槽…吹牛逼…加薪……

聲明我是利益攸關方，正在寫一個跨平台C/C++ SDK。

首先回答一個問題，是不是值得用native開發Android/iOS跨平台應用？——值！對如何開發跨平台app，很多人往往第一閃現是用腳本語言框架，react native、angular、vue，等等，無論哪種框架，它們都存在只能發揮80%性能的固有頑疾。導致的是一條不變循環：公司一開始為儘快上市，用腳本語言先開發出app，等有了一定資金、人力後，發現腳本語言不能滿足需要，然後改為原生開發。要破除這個魔咒，則要求使用的跨平台技術能發揮100%性能，這意味只能用原生開發。

原生跨平台開發只能用C/C++。對iOS， objective-c是原生語言，誰都知道，但說C/C++是原生語言，有人就不認同了。但這是事實，iOS支持 objective-c 和C/C++混編，C/C++可直接調用 objective-c API。同樣，Android的NDK編程使用C/C++。至於C/C++開發Windows、Linux app，不用說了。

新的設計理念。為什麼要說這個？已有的C++ SDK往往給人一種感覺，C/C++開發太難了，而且還有點雞肋。說到這個不得不說下Qt，我用8個字形容Qt：代碼臃腫、積重難返。Qt也就那樣，咱管不了，但對新SDK須使用些新理念。1）不用高深語法，提倡「C加class」。2）融合GUI、場景API，同時支持開發遊戲、非遊戲App。3）高度模塊化，明確各子系統邊界。1、2兩點不擴展了，深入說下第3點。

有這麼三個開源項目，SDL：向上層提供低級的、統一跨平台調用；Webrtc：提供網路視頻、音頻、文件通信，以及多線程API；chromium：提供解釋瀏覽器腳本語言。現在要設計一個同時擁有以上三個功能的SDK，一種方法是直接集成那三個項目，然後編寫融合劑代碼，穩定後向外變成一個新的SDK。——雖然寫的代碼不多，但這個SDK已經穩定、強大，升級簡單，有著天然的子系統邊界。

當然，一個跨平台SDK只是擁有SDL、Webrtc、chromimum功能，那是不夠的，很簡單一個理由，它們沒gui功能（chromimum只是集成解釋腳本、圖文混排模塊）。越是複雜的事物，其本質越是簡單！當用模塊化編寫跨平台SDK，會發現你真正要寫的主要部分就是GUI和場景，至於其它的，可直接內置那些開源項目。下圖顯示了SDK要自個實現的功能(gui、場景、動畫)，以及要用哪些開源庫。

言歸正轉，回答題問：我認為方向是對的，但執行方法有BUG。

真的這樣嘛？我的天～好理解你呀～大兄弟～

移動端我感覺這兩年不太好了情況，像ios和安卓，h5都是段時間火爆，一兩年～

從安卓工程師的角度考慮，用C/C++將業務邏輯封裝入Native庫的確相當有好處，事實上大廠都有這麼干，其主要原因在於Java代碼過於容易被破解反編譯，所以一些對於安全性要求很高或者用戶量很大的產品需要將業務邏輯隱藏，於是就使用C/C++將其編譯成靜態庫或動態庫，並進行加殼，這樣可以杜絕大部分黑客攻擊。

而對於iOS工程師而言，由於OC或Swift本身就會編譯成Native代碼，所以意義不大。

另外補充下：

其實在安卓上，執行Native程序的效率並不一定比Java高，甚至往往可能更低，由於安卓並未提供pthread之類的常用組件，所以在Native中如果要進行線程和系統介面的調用往往會需要反過來通過JNI調Java的組件，所以執行效率反而低。

未展開說明前，我差點以為有些評論里說的腦子壞掉了的 Leader 就是我了。

我們已經在三個產品上使用了 Dropbox 開源的 djinni，用 C++ 實現跨平台。不過我們並沒有像題主他們那樣造了那麼多輪子。HTTP Client，Image Loader 以及線程等這些我們都是用的平台實現，如 Android 的 HttpUrlConnection/OkHttp/Glide，iOS 的 AFNetworking/SDWebImage 等。

我只是覺得寫習慣JAVA,回去搞C++常常忘了delete

想不明白，為啥自己寫，c++發展的如此成熟，現在由於大量的高級語言誕生，才慢慢減少使用。但凡你用到的都可以找到現成的庫。方向正確，執行有bug

好多遊戲引擎不都是跨平台的嗎？比如cocos2dx

我們公司現在就有一個APP是C++寫的底層。然後做C++的大神走了。維護各種蛋疼