沒有最好，只有合適-選擇服務器框架也是如此

網(wǎng)站構(gòu)建一個穩(wěn)定、高效的后臺服務器程序是一件非常重要的事情。要達到這樣的目的，選擇一款快速、高效的后臺程序款框架是我們必須要考慮清楚的。一個后臺框架是一系列工具、代碼包以及其他軟件模塊的集合，利用這些基礎設置你就可以快速的開發(fā)出功能全面的服務器后臺程序。這些框架在設計之初就考慮到了將來的服務器程序要面臨的需求，并且提供了比較合理全面的解決方案。我們只需要根據(jù)我們的需求，對應到這些框架的不同模塊，利用這些模塊實現(xiàn)我們的業(yè)務代碼即可。

本人掌握了包含市面上大部分常用的編程語言以及相關(guān)的框架，也都使用過這些框架開發(fā)出了 server 程序。在2021年，我羅列出目前常用的幾個框架與大家分享交流。

Laravel

編程語言：PHP

laravel是一個免費、開源的PHP開發(fā)框架，它是基于MVC程序結(jié)構(gòu)設計的。對于常年使用PHP語言做項目的人來說，laravel是普遍的首選方案。我以前接手的一些項目，云服務器平臺是客戶早年就在使用的，比如GoDaddy、Hostinger 等等，這些云平臺對PHP語言的支持非常好，那么考慮到入鄉(xiāng)隨俗，要使用云服務里的PHP環(huán)境，那么用laravel就是非常合適的了。

laravel提供了權(quán)限管理、API 設計、后臺緩存、日志管理、測試等多種功能。它的文檔也非常的全面易懂。laravel 非常適合用來開發(fā)博客網(wǎng)站、門戶網(wǎng)站、電商網(wǎng)站的后臺。

不過時過境遷，由于現(xiàn)在更多更好的框架的出現(xiàn)，PHP語言以及l(fā)aravel變得有些過時和年邁，很多人會暫時放棄PHP以及l(fā)aravel，會嘗試使用其他的選擇。

Flask vs Django

編程語言：Python

我把這兩個框架放在一起進行說明。幾年前我在自學完P(guān)ython語言后，就去尋找基于Python的服務器開發(fā)框架，flask和Django是兩個常用的。在玩過了這兩個框架之后，我明確的選擇了Flask。因為我個人的開發(fā)風格和習慣是前后端分離的，用Angular或者Vue去專心開發(fā)前端頁面，用框架細致的開發(fā)后端服務器的一些功能，前后端之間的通信和數(shù)據(jù)交換使用 Restful API 來實現(xiàn)。

Django也是一款比較強大的框架，但是它對前后端分離風格的開發(fā)者不太友好。在開發(fā)的時候很多時候需要將前端的HTML、JavaScript和后端的Python進行聯(lián)合開發(fā)，代碼可能會比較混亂。但是事情都有兩面性，反過來講Django的封裝性更好一些，很多功能都是拿來即用的，只要根據(jù)自己的需求稍加修改，就可以快速的實現(xiàn)一些功能，比如form表單。

而 Flask 是純粹的前后端分離的風格，屬于微型框架。你在用Flask寫代碼的時候，可以完全不需要考慮前端。可以專心的開發(fā)服務器程序。最后提供一些 API 訪問鏈接地址給前端即可。所以Flask 框架會比Django更小，使用flask也需要開發(fā)者去處理和開發(fā)更多的功能邏輯。

Express.js vs Koa2

編程語言：JavaScript / TypeScript

得益于node.js的流行和廣泛使用，歷史悠久、可愛的JavaScript語言終于可以涉足到后臺服務器程序開發(fā)領(lǐng)域了。一般的，在安裝好node.js后，很少有人會直接用JavaScript原生的開發(fā)服務器代碼，而是會選擇一款框架。那么express.js和koa2就是目前比較流行的兩款框架了。

他們都可以用 JS 快速的開發(fā)出 API 程序，也都能通過安裝其他的模塊實現(xiàn)與后臺數(shù)據(jù)庫的連接。我個人在多年的編程經(jīng)歷中，面對中小型的項目，對性能要求不高的時候，都會考慮使用這兩個框架。一般會很快的寫好 Restful API 程序和數(shù)據(jù)庫的CRUD程序。另外部他們兩個的部署也比較方便，Linux上裝好node.js，然后服務器程序文件放在一個地方，用 pm2 這種基于 node.js 的命令工具啟動即可向前端提供服務了。

這兩個框架其實是同一班人的作品。express.js問世的較早，koa2其實是express.js的改進，代碼更加精煉緊湊，都是不錯的選擇。

Spring

編程語言：Java

聚光燈照顧來，歡呼尖叫響起，superstar 到來了。沒錯，spring是這幾年服務器開發(fā)框架里的明星。基于Java這幾十年的穩(wěn)健發(fā)展，已經(jīng)有了太多的處理各種問題和需求的Java第三方包。再結(jié)合spring的優(yōu)良品質(zhì)，比如常見的權(quán)限控制、Restful API 開發(fā)、SQL/NoSQL 數(shù)據(jù)庫操作這種常見的功能以外，還可以想象一下利用spring結(jié)合hadoop生態(tài)來開發(fā)big data 應用，那會是另外一片天空了。

我個人在2020年指導了幾個本科大學生的畢業(yè)設計項目。他們告訴我，他們的老師不僅要求他們寫論文，還需要他們開發(fā)一個完整的Web項目，要有網(wǎng)站、服務器，后面還要掛個數(shù)據(jù)庫。值得注意的一點是，導師們要求他們必須用spring框架實現(xiàn)服務器。這些學生當然連前端三劍客 HTML/CSS/JavaScript 都還沒有玩會，后臺抽象的代碼更是小白一個。他們說導師也只是知道有這種技術(shù)，但是也沒法完全指導他們，所以我就有了雪中送炭的機會。

另外，現(xiàn)在很多中大型網(wǎng)站的后臺的主要業(yè)務邏輯，就是用java的spring來實現(xiàn)的，并結(jié)合其他技術(shù)向外提供服務。比如國內(nèi)的一些電商平臺就是這樣的設計。

其他

上面我只是列舉了幾個典型的方案，其實還有很多，我基本上都玩過。比如 hapi（JavaScript）、Golang（Go）、Slim（PHP）等等。大家可以根據(jù)自己的需求和實際情況，了解這些框架后進行選擇。

如何選擇合適的框架

和擇偶很類似，選擇適合的才是明智之選。大家都說她好，包括你的父母都很欣賞那個人，但是你就是不喜歡。所以強扭的瓜不甜。下面是幾條選擇框架的方針，供大家參考：

要明確自己開發(fā)的服務器后臺的目的，以及將來的后臺的規(guī)模，數(shù)據(jù)量或業(yè)務量的大小，峰值是多少。拿著這些需求和目的，去和眾多的框架去對照，選擇能夠真正解決你的需求的框架。
框架的安全性如何。畢竟服務器程序不是兒戲，前端其實只是個交互操作界面，大部分真正的數(shù)據(jù)和處理邏輯都在后臺服務器。我曾經(jīng)用了一個小時，就很快的模仿開發(fā)出了微信App的程序，但是這沒有什么可炫耀的，微信厲害的地方其實在它的后臺！
隨著時間的推移，一般的，對于后臺服務器程序的訪問量、數(shù)據(jù)流量、數(shù)據(jù)讀寫的 I/O 效率都會有更高的要求。那么我們要仔細考慮一款框架的適應性如何，是否能夠隨著業(yè)務的增長同樣能夠提供相同的性能。
易于部署、配置和維護。這時毋庸置疑的，我在以往的涉獵過程中，體驗到了基于Go語言的后臺項目是最易于部署的，只要基于不同的OS（Windows，LInux）將代碼編譯好之后，直接放在操作系統(tǒng)里并啟動即可。需要編譯的方案，運行起來速度會更好，比如Java的框架。有些是不需要編譯，是解釋運行的，比如JavaScript / node.js的框架，部署可能方便，但是運行效率可能會有些折扣。不過由于現(xiàn)在的硬件機能已經(jīng)比20年前有了指數(shù)級的發(fā)展，所以在沒有特殊要求下，基本上哪個方便不麻煩就用哪個吧。
開發(fā)文檔的質(zhì)量。現(xiàn)在很多人學習計算機還迷戀與哪一本書，哪些視頻教程。在十幾年前倒是可以這樣考慮，因為以前互聯(lián)網(wǎng)并不發(fā)達，網(wǎng)速、內(nèi)容資源都比較差，買書學習就成了首選。現(xiàn)在就不同了，現(xiàn)在你如果買了書，可能書里的內(nèi)容可能很快就會過時，就會和實際情況有了差距。有些人也會去報培訓班，大家請擦亮眼睛，培訓班也是要走流量的，公司要求一波學生必須在4~5個月結(jié)業(yè)，如果時間太長，他們占用了教室、教師資源，公司就很難再繼續(xù)招收新的學生了，那么他們的現(xiàn)金流量就可想而知了。所以培訓班的老師講課都是非常快的，非常刻板的，他們每天都有進度的要求。這樣填鴨式的教學效果我就不用多說了。說回來，一款框架肯定都有他們自己的官方文檔，這幾年我還發(fā)現(xiàn)這些網(wǎng)站對中文的支持也很好了，以前基本上沒有中文版的官方開發(fā)文檔。那么好好利用這些官方文檔來學習是最靠譜的。大家能自學就不要去請教別人，自己琢磨、鉆研、嘗試后得到的收獲對自己的技術(shù)更加有幫助，而且成本更低。
學習曲線。也就是學習的難度和周期。這點就要和編程語言有所結(jié)合了，比如JavaScript、Python更加容易上手，Java稍微難一些復雜一些。這一點其實僅僅是針對初學者或者入行時間不長的人的，像我這種已經(jīng)熟練掌握了至少4門語言，能玩轉(zhuǎn)10多門語言的人，學習曲線基本上可以不用考慮。
社區(qū)。這一點也很可觀。一款框架用的人多，他們遇到的問題也就會多，那么他們在網(wǎng)絡上查詢問題、詢問問題也就多，那么就會有更多的人給出各種問題的解決方案來。慢慢的就形成了社區(qū)，現(xiàn)在很多成型的編程社區(qū)網(wǎng)站就是這樣建立起來的。典型的就是 stackworkflow，我經(jīng)常能在這里找到靈感。個人意見啊，我建議讀者們但凡有一點英文能力，就去英文網(wǎng)站找解決方案。國內(nèi)的百度搜出來的結(jié)果一般都很爛，沒啥幫助，有些人就算給出方案也能看出來是敷衍的寫的，要么語言表述不清，要么代碼胡亂粘貼。能翻墻就翻墻用Google，不能翻墻就用Microsoft bing（國際版），一般搜出來的都是國外網(wǎng)站，里面有很多有識之士給出的解答更加有幫助，甚至立竿見影。

送給大家一句話：

擇偶時，沒有最好的，只有合適的。選擇框架也是一樣的！

歌Chrome產(chǎn)品管理主管阿弗尼?沙哈（Avni Shah）今天在I/O開發(fā)者大會上發(fā)布了新版Chrome，該產(chǎn)品將出現(xiàn)于名為Android L的新一代Android系統(tǒng)版本上。

與預期一樣，新版Chrome進行了一些功能升級。不過它并不只是進行了改進。對于它，谷歌還傳達了一個清晰而意義深遠的信息。該公司想要融合原生應用與網(wǎng)頁標簽。原生應用的終結(jié)可能比我們想象得還要快。

在Android L中，經(jīng)過重新設計的應用切換器與iOS 7上的Safari非常相似。它會在某種卡片抽屜中顯示你最近打開過的應用。同時它也顯示原生應用以及活躍網(wǎng)頁標簽。每一個網(wǎng)頁標簽都有著與應用同等的價值。這是件大事。

同樣地，谷歌將其應用索引API（應用程序接口）擴展至所有的Android應用。在此之前，該公司就與特定的幾家公司展開了相關(guān)合作。例如，在谷歌搜索電影，搜索結(jié)果中會出現(xiàn)一個可直接打開IMDb應用中相關(guān)電影頁面的深度鏈接。這是一種從網(wǎng)頁到原生應用的無縫過渡。

了解這些后，不妨想象一下Android L會變成什么樣子。打開手機，在主屏幕上用谷歌語音搜索某樣東西，接著Chrome打開，點擊第一個搜索結(jié)果，你就可以打開原生應用。你可以轉(zhuǎn)到應用上閱讀你之前在Chrome上看到過的這篇文章。

在這一過程中，網(wǎng)頁應用與原生應用之間反復來回切換。不久之后，你會察覺不出自己是在網(wǎng)頁中還是在原生應用當中。

為什么說這一變化有意義呢？谷歌一直以來都是以網(wǎng)頁開發(fā)為先。該公司最早是通過它的搜索引擎取得成功。不過它之后的熱門產(chǎn)品很多都是網(wǎng)頁應用，如Gmail，Google Calendar日歷，Google Drive。谷歌可能仍然是網(wǎng)頁應用開發(fā)領(lǐng)域的王者。

而更重要的是，谷歌的大部分收入還是來自網(wǎng)頁廣告。該公司希望人們更長時間地呆在web上，從而看到更多的谷歌廣告。這一點在下一份季度財報中還不會發(fā)生改變。

因此，不管是從技術(shù)還是從業(yè)務角度來看，谷歌的未來都維系在web上。有幾位HTML5和網(wǎng)頁開發(fā)倡導者認為，Android最終可能會成為基于網(wǎng)頁應用的操作系統(tǒng)。這實際上也意味著原生應用的終結(jié)。

數(shù)家公司在這方面展開過嘗試——推WebOS的Palm和打造Firefox OS的Mozilla。它們都以失敗而告終，原因有多個方面——當時的系統(tǒng)級芯片還不夠強大，網(wǎng)頁運行不夠高效，它們的網(wǎng)頁開發(fā)者不夠出色。

最主要的原因還是時機問題。而谷歌這個適合步步為營地向這種新的應用模式轉(zhuǎn)型則并無不妥。現(xiàn)在的系統(tǒng)級芯片可能能夠運行功能齊備的筆記本電腦。谷歌一直在不知疲倦地改進JavaScript和HTML渲染引擎。當然，谷歌麾下也有成千上萬優(yōu)秀的網(wǎng)頁開發(fā)者。

推廣網(wǎng)頁應用是個漫長的過程，可能要耗時數(shù)年。不過谷歌今天的行動可以說是明確向這一方向邁出的第一步。（譯：羽騰）

/ Google Android NDK 技術(shù)負責人 Dan Albert

最新版本的 Android 原生開發(fā)工具包 (NDK) Android NDK r16 Beta 1 現(xiàn)在可以下載了：

https://developer.android.google.cn/ndk/downloads/index.html

也可以通過 Android Studio 在 SDK 管理器中獲取此版本。

NDK r16 對我們來說是一個重大的里程碑，因為它是我們準備建議用戶開始遷移到 libc++ 的第一個版本！我們會在后面提供更多信息。

我們還更新了 libc++ 及其相關(guān)項目，因此，這個版本提升了對 C++1z 的支持。請注意，在 C++1z 成為 C++17 之前，包含的任何內(nèi)容都有可能發(fā)生變化。

您可以在此處查看該版本的版本說明：

https://android.googlesource.com/platform/ndk/+/ndk-release-r16/CHANGELOG.md

libc++ 和 libandroid_support

NDK 有一個名為 libandroid_support 的庫，這個庫可以向后移植 libc++ 依賴、但舊版本不支持的 libc API。我們至今無法認可 libc++（在 NDK 中實現(xiàn)）的原因仍然是對這個庫缺乏信心。r16 的焦點是重新編寫了這個庫，以獲得更高的穩(wěn)定性。

由于 libandroid_support 現(xiàn)在是一個比較小的庫，您的應用的行為應當更接近系統(tǒng)的行為。例如，libandroid_support 之前包含對部分 stdio 的替代實現(xiàn)。盡管一些功能向后移植到 ICS，不過，這也意味著替代實現(xiàn)中的任何錯誤都會出現(xiàn)在自從您的應用引入錯誤以來發(fā)布的所有 OS 版本中。

在新版本的 libandroid_support 中，我們已將替代實現(xiàn)移除，因此您在較舊的設備上將無法使用某些功能（幾乎是一些沒人使用的功能，例如格式字符串中的 %a 支持），不過由于沒有這些功能，您使用 libc++ 的應用將變得更小、更可靠。

轉(zhuǎn)到 libc++

所以，為什么您應轉(zhuǎn)到 libc++ 呢？首先，其他 STL 今后將不再受支持。我們一直將 libc++ 用于自 Lollipop 以來的 Android 平臺，有一項變化讓我們的工程師感到非常興奮。我們在平臺中比在 NDK 中更早地完成了這種過渡，因為我們不需要 libandroid_support，并且可以僅更新 libc。

與 NDK 中當前可用的其他 STL 相比，libc++ 完全支持 C++11、C++14 和大多數(shù)的 C++1z！Stlport 自從 2008 年以來就沒有更新過了，gnustl（我們對 GNU 的 libstdc++ 的叫法，這是為了避免與 Bionic 的 libstdc++ 混淆，后者不是一種 STL）一直以來都不是很適合 Clang，尤其是在與和之類的編譯器內(nèi)建函數(shù)緊密關(guān)聯(lián)的標頭中，更是如此。

我們很有可能讓 libc++ 成為下一個 NDK 版本的默認選擇，但是現(xiàn)在，如果您還沒用過，可以按照下面的說明操作，選擇啟用這種庫。

像其他 STL 一樣，libc++ 同時提供靜態(tài)庫和共享庫。使用哪一個取決于您的具體情況，但是如果您的應用中有且僅有一個共享庫，tl;dr 將使用靜態(tài)版本，并在所有其他情況下使用共享版本。

ndk-build

將以下內(nèi)容添加至您的 Application.mk 文件中：

APP_STL :=c++_shared

CMake

調(diào)用 CMake 時請粘貼以下內(nèi)容：

-DANDROID_STL=c++_shared

如果您正在通過 Gradle 使用 CMake，請將以下內(nèi)容添加至您的 build.gradle 中：

externalNativeBuild {
cmake {
arguments "-DANDROID_STL=c++_shared"
}
}

獨立工具鏈

在創(chuàng)建獨立工具鏈時，請傳遞 --stl=libc++。

libandroid_support 的未來

如果您已經(jīng)閱讀我們的路線圖：

https://android.googlesource.com/platform/ndk/+/master/docs/Roadmap.md

想必了解我們計劃擴展 libandroid_support 以向后移植盡可能多的 libc/libm。每次跟大家說到這個問題，我們最多只是收到冷淡的回應。考慮到大家看起來不感興趣，而且這樣做也會讓庫增大（進而導致 APK 增大，這是每個人都非常感興趣的話題），我們不再打算擴展。

如果我們誤解了您的回應，或者您還沒有回應我們，并且希望我們擴展，請告訴我們：

https://github.com/android-ndk/ndk/issues/456

_FILE_OFFSET_BITS=64

tl;dr：如果您想要保留舊 NDK 中的行為，請不要設置 _FILE_OFFSET_BITS=64。

在 NDK 中設置 _FILE_OFFSET_BITS=64 一直都沒什么用。此功能在棄用的標頭中已經(jīng)移除。對于統(tǒng)一標頭，NDK 現(xiàn)在具有支持此功能的最新標頭。

您可以在您的應用中定義 _FILE_OFFSET_BITS=64 宏，以便在 32 位代碼中獲取對 64 位 off_t 的支持。將 off_t 設為 64 位（默認情況下，它在 32 位代碼中為 32 位）和使用 lseek64 調(diào)用隱式替換對 lseek 之類 API 的調(diào)用可以實現(xiàn)這種支持。

之前版本的 Android 沒有添加對 _FILE_OFFSET_BITS=64 的支持。lseek64 這個 API 一直在 bionic 中。大多數(shù) API 在 Lollipop 中添加，其他的一些 API 則到后期版本才添加。

如果您針對的版本不支持正在使用的某個函數(shù)的 64 位 off_t 變體，并且已設置 _FILE_OFFSET_BITS=64，該函數(shù)將不可用。這與 r15 和 r15b 的行為不同（但與 r15c 的行為一致），在這兩個版本中，函數(shù)使用 32 位 off_t 錯誤公開，將被靜默截斷。

請注意，即使沒有不同名稱的 _FILE_OFFSET_BITS=64，64 位 off_t API 仍然可用。例如，請調(diào)用 lseek64，而不是 lseek。使用 off64_t，而不是 off_t。

最后，由于此功能對具有統(tǒng)一標頭的 NDK 來說是一項新功能，如果您只想返回到統(tǒng)一前的標頭行為，您要做的只是停止設置 _FILE_OFFSET_BITS=64。

如需了解有關(guān) bionic 中 off_t ABI 詳細信息的更多信息，請參閱 Bionic 32 位 ABI 錯誤文檔：

https://android.googlesource.com/platform/bionic/+/master/docs/32-bit-abi.md

查看更多文章，請關(guān)注『谷歌開發(fā)者』官方微信公眾號

在線咨詢

上一篇：你真的學會HTML標簽了嗎？
下一篇：前端開發(fā)人員必備Web前端面試題與答案西安尚學堂

您的項目需求

*請認真填寫需求信息，我們會在24小時內(nèi)與您取得聯(lián)系。

整合營銷服務商