Dropbox寧願將代碼編寫兩次，也不願在iOS版和Android版應用程序之間共享C＋代碼！

編寫一次、隨處運行？別開玩笑了。

Dropbox擯棄了長期奉行的技術策略：在iOS版和Android版的應用程序之間共享C 代碼，稱代碼編寫兩次的開銷低於共享代碼這種做法的成本。

這家在線存儲公司在2013年制定了這前一個策略，讓一支小型團隊能夠迅速發布代碼。現在它「完全退出這個策略」，改而針對每個平台使用原生語言，「主要是Swift和Kotlin」。

軟體工程師Eyal Guthmann給出了決定這麼做的幾個原因。他表示，C 開發社區中的開源文化還不成氣候，移動方面尤為如此，於是他們只好構建框架，以解決跨語言類型聲明、介面綁定（以便與Objective-C和Java對接）、JSON解析和序列化等問題。若使用原生庫，就不需要這麼做了。該團隊還必須創建一個自定義構建系統。

其次，Guthmann稱跨平台開發的工具不如原生語言的工具來得強大，這意味著就更難找到代碼錯誤（bug）。涉及C 和Java之間多線程代碼的一個問題需要「數周才能弄清楚」。

第三，由於iOS和Android之間的差異，並非所有代碼都可以跨平台。你必須為某些方面（比如與相機相冊交互）編寫針對特定平台的代碼。

第四，很難找到從事C 移動端開發的資深開發人員。

如果選擇C 而不是C#或JavaScript，Dropbox可能會使跨平台編程尤其困難重重。另一方面，Guthmann稱：「C/C 是其編譯器同時得到谷歌和蘋果支持的唯一兩種語言，因此使用一種不同的語言會帶來另外一大堆問題需要處理。」

Dropbox面臨的特殊問題並不適用於每個項目。Dropbox需要與操作系統深度集成，而性能至關重要。比如說，自定義業務應用對跨平台解決方案來說可能是更合適的使用場景，因為它沒必要有同樣程度的集成。跨平台C 對於大量使用非可視演算法的應用而言同樣大有意義。

話雖如此，Guthmann所發的帖子確實表明，編寫一次、隨處運行這個夢想實際上對於許多類型的應用而言仍然遙不可及。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！