一位跨平臺開發者的自白

Andreia Gaita 在 OSCON 開源大會上發表了一個題為跨平臺開發者的自白的演講。她長期從事於開源工作，並且為 Mono 工程（LCTT 譯註：一個致力於開創 .NET 在 Linux 上使用的開源工程）做著貢獻，主要以 C#/C++ 開發。Andreia 任職於 GitHub，她的工作是專注構建 Visual Studio 的 GitHub 擴充套件管理器。

我在她發表演講前就迫不及待的想要問她一些關於跨平臺開發的事，問問她作為一名跨平臺開發者在這 16 年之中學習到了什麼。

在你開發跨平臺程式碼中，你使用過的最簡單的和最難的程式碼語言是什麼?

我很少討論某種語言的好壞，更多是討論是那些語言有哪些庫和工具。語言的編譯器、直譯器以及構建系統決定了用它們做跨平臺開發的難易程度（或者它們是否可能做跨平臺開發），可用的 UI 庫和對本地系統的訪問能力決定了與該作業系統整合的緊密程度。按照我的觀點，我認為 C# 最適合完成跨平臺開發工作。這種語言自身包括了允許快速的本地呼叫和精確的記憶體對映的功能，如果你希望你的程式碼能夠與系統和本地函式庫進行互動就需要這些功能。而當我需要非常特殊的系統功能時，我就會切換到 C 或者 C++。

你使用的跨平臺開發工具或者抽象層有哪些？

我的大部分跨平臺工作都是為其它需要開發跨平臺應用的人開發工具、庫和繫結（binding），一般是用 MONO/C# 和 C/C++。在抽象的層面我用的不多，更多是在 glib 庫和友元（friends）方面。大多數時候，我用 Mono 去完成各種跨平臺應用的，包括 UI，或者偶然在遊戲開發中用到 Unity3D 的部分。我經常使用 Electron（LCTT 譯註：Atom 編輯器的兄弟專案，可以用 Electron 開發桌面應用)。

你接觸過哪些構建系統？它們之間的區別是由於語言還是平臺的不同？

我試著選擇適合我使用的語言的構建系統。那樣，就會很少遇到讓我頭疼的問題（希望如此）。它需要支援平臺和體系結構間的選擇、構建輸出結果位置可以智慧些（多個並行構建），以及易配置性等。大多數時候，我的專案會結合使用 C/C++ 和 C#，我要從同一原始碼同時構建不同的配置環境（除錯、釋出、Windows、OSX、Linux、Android、iOS 等等），這通常需要為每個構建的輸出結果選擇帶有不同引數的不同編譯器。構建系統可以幫我做到這一切而不用讓我（太）費心。我時常嘗試著用不同的構建系統，看看有些什麼新的變化，但是最終，我還是回到了使用 makefile 的情況，並結合使用 shell 和批處理指令碼或 Perl 指令碼來完成工作（因為如果我希望使用者來構建我的軟體，我還是最好選擇一種到處都可以用的命令列指令碼語言）。

你怎樣平衡在這種使用統一的使用者介面下提供原生的外觀和體驗的需求呢？

跨平臺的使用者介面的實現很困難。在過去幾年中我已經使用了一些跨平臺 GUI，並且我認為這些事情上並沒有最優解。基本上有兩種選擇。你可以選擇一個跨平臺工具去做一個並不是完全適合你所有支援的平臺的 UI，但是程式碼庫比較小，維護成本比較低。或者你可以選擇去開發針對平臺的 UI，那樣看起來更原生，整合的也更好，但是需要更大的程式碼庫和更高的維護成本。這種決定完全取決於 APP 的型別、它有多少功能、你有多少資源，以及你要把它執行在多少平臺上？

最後，我認為使用者比較接受這種“一個 UI 打通關”了，就比如 Electron 框架。我有個 Chromium + C + C# 的框架側專案，有一天我希望可以用 C# 構建 Electron 型的 app，這樣的話我就可以做到兩全其美了。

構建/打包系統的依賴性對你有影響嗎 ?

我依賴的使用方面很保守，我被崩潰的 ABI（LCTT 譯註：應用程式二進位制介面）、衝突的符號、以及丟失的包等問題困擾了太多次。我決定我要針對的作業系統版本，並選擇最低的公有部分來使問題最小化。通常這就意味著有五種不同的 Xcode 和 OSX 框架庫，要在同樣的機器上相應安裝五種不同的 Visual Studio 版本，多種 clang（LCTT 譯註：C語言、C++、Object-C、C++ 語言的輕量級編譯器）和 gcc 版本，一系列的執行著各種發行版的虛擬機器。如果我不能確定我要使用的作業系統的包的狀態，我有時就會靜態連線庫，有時會子模組化依賴以確保它們一直可用。大多時候，我會避免這些很棘手的問題，除非我非常需要使用他們。

你使用持續整合（CI）、程式碼審查以及相關的工具嗎？

基本每天都用。這是保持高效的唯一方式。我在一個專案中做的第一件事情是配置跨平臺構建指令碼，保證每件事儘可能自動化完成。當你面向多平臺開發的時候，持續整合是至關重要的。沒有人能在一個機器上構建各種平臺的不同組合，並且一旦你的構建過程沒有包含所有的平臺，你就不會注意到你搞砸的事情。在一個共享式的多平臺程式碼庫中，不同的人擁有不同的平臺和功能，所以保證質量的唯一的方法是跨團隊程式碼審查結合持續整合和其他分析工具。這不同於其他的軟體專案，如果不使用相關的工具就會面臨失敗。

你依賴於自動構建測試，或者傾向於在每個平臺上構建並且進行本地測試嗎？

對於不包括 UI 的工具和庫，我通常使用自動構建測試。如果有 UI，兩種方法我都會用到——針對已有的 GUI 工具的可靠的、可指令碼化的 UI 自動化少到幾乎沒有，所以我要麼我去針對我要跨我所支援的平臺建立 UI 自動化工具，要麼手動進行測試。如果一個專案使用了定製的 UI 庫（比如說一個類似 Unity3D 的 OpenGL UI），開發可程式設計的自動化工具並自動化大多數工作就相當容易。不過，沒有什麼東西會像人一樣雙擊就測試出問題。

如果你要做跨平臺開發，你喜歡用跨編輯器的構建系統，比如在 Windows 上使用 Visual Studio，在 Linux 上使用 Qt Creator，在 Mac 上使用 XCode 嗎？還是你更趨向於使用 Eclipse 這樣的可以在所有平臺上使用的單一平臺？

我喜歡使用跨編輯器的構建系統。我更喜歡在不同的IDE上儲存專案檔案（這樣可以使增加 IDE 變得更容易），通過使用構建指令碼讓 IDE 在它們支援的平臺上去構建。對於一個開發者來說編輯器是最重要的工具，學習它們是需要花費時間和精力的，而它們是不可相互替代的。我有我自己喜歡的編輯器和工具，每個人也可以使用他們最喜愛的工具。

在跨平臺開發的時候，你更喜歡使用什麼樣的編輯器、開發環境和 IDE 呢？

跨平臺開發者被限制在只能選擇可以在多數平臺上工作的所共有的不多選擇之一。我愛用 Visual Studio，但是我不能依賴它完成除 Windows 平臺之外的工作（你可能不想讓 Windows 成為你的主要的交叉編譯平臺），所以我不會使用它作為我的主要 IDE。即使可以，跨平臺開發者的核心技能也是儘可能的瞭解和使用大量的平臺。這就意味著必須很熟悉它們——使用該平臺上的編輯器和庫，瞭解這種作業系統及其適用場景、執行方式以及它的侷限性等。做這些事情就需要頭腦清醒（我的捷徑是加強記憶），我必須依賴跨平臺的編輯器。所以我使用 Emacs 和 Sublime。

你之前和現在最喜歡的跨平臺專案是什麼？

我一直很喜歡 Mono，並且得心應手，其它的專案大部分都是以某種方式圍繞著它進行的。Gluezilla 是我在多年前開發的一個 Mozilla 繫結（binding），可以把 C# 開發的應用嵌入到 Web 瀏覽器頁面中，並且看起來很有特色。我開發過一個 Winform 應用，它是在 linux 上開發的，它可以在 Windows 上執行在一個 Mozilla 瀏覽器頁面裡嵌入的 GTK 檢視中。CppSharp 專案（以前叫做 Cxxi，更早時叫做 CppInterop）是一個我開始為 C++ 庫生成 C# 繫結（binding）的專案，這樣就可以在 C# 中呼叫、建立例項、子類化 C++ 類。這樣，它在執行的時候就能夠檢測到所使用的平臺，以及用來建立本地執行庫的是什麼編譯器，併為它生成正確的 C# 繫結（binding）。這多麼有趣啊。

你怎樣看跨平臺開發的未來趨勢呢？

我們構建本地應用程式的方式已經改變了，我感覺在各種桌面作業系統的明顯差異在慢慢變得模糊；所以構建跨平臺的應用程式將會更加容易，而且對系統的整合也不需要完全本地化。不好的是，這可能意味著應用程式易用性更糟，並且在發揮作業系統特性方面所能做的更少。庫、工具以及執行環境的跨平臺開發是一種我們知道怎樣做的更好，但是跨平臺應用程式的開發仍然需要我們的努力。

---

via: https://opensource.com/business/16/5/oscon-interview-andreia-gaita

作者：Marcus D. Hanwell 譯者：vim-kakali 校對：wxy

本文由 LCTT 原創翻譯，Linux中國 榮譽推出