『壹』 大牛們是怎麼讀 Android 系統源碼的
1.顯然Eclipse不是閱讀Android源碼的好工具,不流暢,搜索低效,繼承性關系/調用關系都無法有效查看。推薦Source Insight,在這個工具幫助下,你才可以駕馭巨大數量的Android 源碼,你可以從容在java,C++,C代碼間遨遊,你可以很快找到你需要的繼承關系。 順便,我們公司一直是Windows+Linux+Samba的工作模式。 2.宏觀上看,Android源碼分為功能實現上的縱向,和功能拓展上的橫向。在閱讀源碼時需要把握好著兩個思路。 譬如你需要研究音頻系統的實現原理,縱向:你需要從一個音樂的開始播放追蹤,一路下來,你發現Jni調用解碼庫,共享內存的創建和使用,路由的切換,音頻輸入設備的開啟,音頻流的開始。 3.Android的功能模塊絕大部分是C/S架構,你心裡一定需要有這個層級關系,你需要思路清晰地找到Server的位置,它才是你需要攻破的城。然後你才能發現HAL和Kernel一層層地剝離。 我大概在三個月前閱讀完Android UI系統的源碼,這是Android最復雜的部分,沒有之一。 我需要先找一個開頭,和UI有直接關系的就是最常見的Activity了吧,我就從它開始解剖。 我從Activity的創建入手,尋找Activity真正的創建位置,setContentview這個方法很明顯和UI有關,這兩方面一結合,我發現了ViewRoot和WindowManager的身影,沿著WM和WMS我發現了Surface,以及draw的函數,它居然在Activity 創建時出現的DeCorView上畫東西。藉助Source Insight我總結了UI Java層的橫向靜態圖。 完成這個靜態UML,我覺得我可以開始功能實現上追蹤了,這部分主要是C++的代碼(這也是我堅定勸阻的放棄Eclipse的原因),我沿著draw函數,看到了各個層級的關系,SurfaceSession的控制和事務處理,SharedBuffer讀寫控制,彪悍的SurfaceFlinger主宰一切,OpenGL ES的神筆馬良。FrameBuffer和FrameBufferDevice的圖像輸出。一氣呵成的完成了。
『貳』 開發一款小視頻app源碼怎麼做
開發一個直播app其實不需要太多的錢,和一般的APP一樣,是根據實際功能需求的頁面總數來估算價格的,
比如說一個頁面800元,當然只有幾個功能的話一定會有個底價,就像打車也有個起步價,畢竟不管再少的功能
也要配備後台開發人員,前端開發人員,ios和安卓各一個,還有UI和產品經理,這是基本配置。
直播app這個核心模塊一般是選擇第三方的SDK接入,就像簡訊接入,聊天接入一樣都有相關模塊的服務商,
相關收費標准需要咨詢SDK服務,,山東趣構網路科技有限公司都會給你搞定,費用是開發之外的,
因為很多SDK都是按數量或者流量計費的。當然你也可以選擇自己研發SDK,不過費用會非常高,
技術門檻也很高,即使開發出來沒有經過長時間大量的用戶檢驗是無法提供完善服務的,
市面上除了直播巨頭擁有自己的SDK,其他的基本上都是調用第三方SDK。開發費用是可以量化的,
需要投入的可能是APP上線之後的推廣營銷費用,這是非常巨大的一筆投入,當然也有很多免費的渠道,
需要把各個應用市場的優化工作做好。
【企業直播平台】
相比於傳統直播服務平台,企業直播APP平台不管是在硬體設備上還是軟體上,實現的難度更加高。
【 主要技術功能模塊】主播端: 把主播實時錄制的視頻,經過(採集、美顏處理、編碼)
推送到伺服器伺服器: 處理(轉碼、錄制、截圖、鑒黃)後分發給用戶播放端播放器:
獲取伺服器地址, 進行拉流、解碼、渲染互動系統: 聊天室、禮物系統、贊主播端: LFLiveKit
已包含採集、美顏、編碼、推流等功能伺服器 : 【 nginx+rtmp伺服器】免費開源,能搭建本地電腦上,
支持RTMP協議,滿足直播需求。播放端 : ijkplayer視頻直播框架 封裝很完善只要有url,
就可以實時播放由於涉及音視頻的編碼解碼、美顏功能的演算法,幀的處理等很多問題,
能從底層自己開發的完整功能的絕對是大牛!不過正是有這些大牛們的奉獻 ,
我們不需要處理繁瑣的底層問題,一些封裝好的庫可以完美實現。
1、 利用第三方直播SDK快速的開發夢網視頻雲: 提供以實時輕視頻技術為核心,
開放智能視頻、Video CDN、VR、視頻編碼、視頻渲染、分布式緩沖、軟交換、多屏播放等前沿視頻技術。
幫您從容應對業務突發峰值。廣泛應用於 游戲直播、娛樂直播、泛生活直播、 教育類、 遠程醫療、
企業遠程視頻會議等典型場景。提供一站式視頻解決方案,幫助企業一個星期搭建完整的視頻直播平台。
同時結合領先的人工智慧技術,開放智能圖像識別、視頻特效、黃反審核功能,讓視頻內容更豐富,更安全。
夢網視頻雲是專為企業平台打造的視頻服務和一站式實現SDK/API端到端直播場景的企業級直播雲服務平台。
2、自研還是使用第三方直播SDK開發?自研: 對於一個初創公司或團隊來講,自研直播不管在技術門檻、CDN、
帶寬上都是有很大的門檻的,而且需要耗費大量的時間和成本才能做出成品,不利於前期發展。
第三方SDK開發:開發周期短,前期投入少,從長遠看,第三方費用較高,占很大一筆支出,
相對來說自研可以節省成本,技術成面比直接用SDK相對可控。
『叄』 請大牛按照圖片結果輸出格式幫我寫下matlab源代碼,謝謝了
這種問題應該不會有人回答的,你也太會偷巧了吧。這應該是作業吧。你還是自己做做吧。如果遇到具體問題了,我想會有很多人幫你的。
『肆』 低代碼究竟是什麼
簡介:什麼是低代碼?我們為什麼需要低代碼?低代碼會讓程序員失業嗎?本文總結了低代碼領域的基本概念、核心價值與行業現狀,帶你全面了解低代碼。
什麼是低代碼
「Low-Code」是什麼?如果你是第一次聽說,沒准也會跟我當年從老闆口中聽到這個詞後的內心戲一樣:啥?「Low-Code」?「Code」是指代碼我知道,但這個「Low」字是啥意思?不會是老闆發現我最近趕工寫的代碼很醜很「Low」吧... 想多了,老闆怎麼可能親自review代碼呢。那難道是指,「Low-level programming」里的「Low」?老闆終於發現讓我等編程奇才整天堆Java業務代碼太浪費,要派我去閉關寫一個高性能C語言網路庫... 顯然也不是,老闆哪能有這技術情懷呢。那到底是什麼意思?作為一名搜商比情商還高的程序員,能問Google的絕不會問老闆。於是我一頓操作後,不假思索地點開了第一條搜索結果:Low-code development platform。
Wikipedia定義
有了低代碼後,這一狀況將得到根本改善:上述各角色都可以在同一個低代碼開發平台上緊密協作(甚至可以是同一個人),這種全新的協作模式不僅打破了職能豎井,還能通過統一的可視化語言和單一的應用表示(頁面/數據/邏輯),輕松對齊項目各方對應用形態和項目進度的理解,實現更終極的敏捷開發模式,以及在傳統DevOps基礎之上更進一步的BizDevOps[2]。
統一開發平台下的聚合效應
低代碼嘗試將所有與應用開發相關活動都收斂到同一個平台(one platform)上後,將會產生更多方面的聚合效應與規模收益:
•人員聚合:除了上一點所提到的各職能角色緊密協作以外,人員聚合到統一的低代碼開發平台進行作業後,還能促進整個項目流程的標准化、規范化和統一化。
•應用聚合:一方面,新應用的架構設計、資產復用、相互調用變得更容易;另一方面,各應用的數據都天然互通,同時平台外數據也能通過集成能力進行打通,徹底消除企業的數據孤島問題。
•生態聚合:當低代碼開發平台聚合了足夠多的開發者和應用後,將形成一個巨大的、連接一切、有無限想像力的生態體系,徹底放飛低代碼的價值。
『伍』 求大牛我用的織夢源碼的模板怎麼圖片載入不出來啊 也就是css文件吧
很明顯路徑不對,檢查一下你的模板css文件在哪兒?
正確路徑應該是根目錄下/templates/default/css/,這是默認模板的路徑;查看一下你自己的模板文件名稱,所有模板都在templates下
檢查是否錯誤
『陸』 哪裡可以找到大牛寫的ACM題的源代碼
用搜索引擎能搜到很多,不過一般適用於有目的性的找某題,還有可以買ACM相關的書,這樣的書一般系統地分類了(按演算法)很多題目及其AC的程序,如果需要網路上的,你可以搜解題報告,一般有題目的闡述、分析和源代碼,解題報告和書更適合新手學習。
『柒』 天天寫業務代碼的程序員,怎麼成為技術大牛,開始寫技術代碼
一個產品業務的開發過程中必然存在很多需要解決的問題,比如 崩潰,死鎖,性能低下,延遲高,伺服器不穩定,數據丟失,某些功能不知道怎麼實現。
產品業務如果要成功,這些問題必須要解決,至少解決其中絕大部分。
誰解決這些問題誰就是大牛,你想去寫業務邏輯公司也捨不得。
遇到這種問題直接退縮或者推給別人,就寫一輩子業務邏輯吧。
問題就是機會,你主動去解決問題,你沒搞定別人也沒搞定啊,萬一搞定了就是你牛逼,多劃算的買賣啊。
以我多年解決問題的經驗來看,其實大多問題並不難,只需要認真去google下跟蹤調試進源代碼深處就能解決,這種問題其實就是誰敢上誰就行。很多人不去解決,就是因為懶和慫。問題解決多了,就會越來越有感覺,別人也就更傾向把疑難雜症交給你。所以一個組里只有一兩個人能成長起來,因為只要有一個人成長了其它人就失去了機會,並不是這一兩個人比其他人優秀很多,只是他們是第一個敢於主動迎難而上的人。
要不怎麼說,性格決定命運呢。
『捌』 請大牛分析一下這段源碼 php的
上傳文件太大,超過30秒限制了。php.ini設置下時間
『玖』 有哪位大牛能分享一下ICP(迭代最近點)演算法的源代碼
你要什麼語言實現的,我有visualc++ ,delphi和matlab實現的
『拾』 大牛們是怎麼閱讀 Android 系統源碼的
由於工作需要大量修改framework代碼, 在AOSP(Android Open Source Project)源碼上花費了不少功夫, Application端和Services端都看和改了不少.
如果只是想看看一些常用類的實現, 在Android包管理器里把源碼下載下來, 隨便一個IDE配好Source Code的path看就行.
但如果想深入的了解Android系統, 那麼可以看下我的一些簡單的總結.
知識
Java
Java是AOSP的主要語言之一. 沒得說, 必需熟練掌握.
熟練的Android App開發
Linux
Android基於Linux的, 並且AOSP的推薦編譯環境是Ubuntu 12.04. 所以熟練的使用並了解Linux這個系統是必不可少的. 如果你想了解偏底層的代碼, 那麼必需了解基本的Linux環境下的程序開發. 如果再深入到驅動層, 那麼Kernel相關的知識也要具備.
Make
AOSP使用Make系統進行編譯. 了解基本的Makefile編寫會讓你更清晰了解AOSP這個龐大的項目是如何構建起來的.
Git
AOSP使用git+repo進行源碼管理. 這應該是程序員必備技能吧.
C++
Android系統的一些性能敏感模塊及第三方庫是用C++實現的, 比如: Input系統, Chromium項目(WebView的底層實現).
硬體
流暢的國際網路
AOSP代碼下載需要你擁有一個流暢的國際網路. 如果在下載代碼這一步就失去耐心的話, 那你肯定沒有耐心去看那亂糟糟的AOSP代碼. 另外, 好程序員應該都會需要一個流暢的Google.
一台運行Ubuntu 12.04的PC.
如果只是閱讀源碼而不做太多修改的話, 其實不需要太高的配置.
一台Nexus設備
AOSP項目默認只支持Nexus系列設備. 沒有也沒關系, 你依然可以讀代碼. 但如果你想在大牛之路走的更遠, 還是改改代碼, 然後刷機調試看看吧.
高品質USB線
要刷機時線壞了, 沒有更窩心的事兒了.
軟體
Ubuntu 12.04
官方推薦, 沒得選.
Oracle Java 1.6
注意不要用OpenJDK. 這是個坑, 官方文檔雖然有寫, 但還是單獨提一下.
安裝:
sudo apt-get install python-software-properties
sudo add-apt-repository ppa:webupd8team/java
sudo apt-get update
sudo apt-get install oracle-java6-installer
sudo apt-get install oracle-java6-set-default
Eclipse
估計會有不少人吐槽, 為什麼要用這個老古董. 其實原因很簡單, 合適. 剛開始搞AOSP時, 為了找到效率最優的工具, 我嘗試過Eclipse, IntelliJ IDEA, Vim+Ctags, Sublime Text+Ctags. 最終結果還是Eclipse. 主要優點有:
有語法分析 (快速准確的類, 方法跳轉).
支持C++ (IntelliJ的C++支持做的太慢了).
嵌入了DDMS, View Hierarchy等調試工具.
為了提高效率, 花5分鍾背下常用快捷鍵非常非常值得.
調整好你的classpath, 不要導入無用的代碼. 因為AOSP項目代碼實在是太多了. 當你還不需要看C++代碼時, 不要為項目添加C++支持, 建索引過程會讓你崩潰.
Intellij IDEA
開發App必備. 當你要調試系統的某個功能是, 常常需要迅速寫出一個調試用App, 這個時候老舊的Eclipse就不好用了. Itellij IDEA的xml自動補全非常給力.
巨人的肩膀
這個一定要先讀. 項目介紹, 代碼下載, 環境搭建, 刷機方法, Eclipse配置都在這里. 這是一切的基礎.
這個其實是給App開發者看的. 但是裡面也有不少關於系統機制的介紹, 值得細讀.
此老羅非彼老羅. 羅升陽老師的博客非常有營養, 基本可以作為指引你開始閱讀AOSP源碼的教程. 你可以按照博客的時間順序一篇篇挑需要的看.但這個系列的博客有些問題:
早期的博客是基於舊版本的Android;
大量的代碼流程追蹤. 讀文章時你一定要清楚你在看的東西在整個系統處於什麼樣的位置.
鄧凡平老師也是為Android大牛, 博客同樣很有營養. 但是不像羅升陽老師的那麼系統. 更多的是一些技術點的深入探討.
Android官方Issue列表. 我在開發過程中發現過一些奇怪的bug, 最後發現這里基本都有記錄. 當然你可以提一些新的, 有沒有人改就是另外一回事了.
一定要能流暢的使用這個工具. 大量的相關知識是沒有人系統的總結的, 你需要自己搞定.
其它
代碼組織
AOSP的編譯單元不是和git項目一一對應的, 而是和Android.mk文件一一對應的. 善用mmm命令進行模塊編譯將節省你大量的時間.
Binder
這是Android最基礎的進程間通訊. 在Application和System services之間大量使用. 你不僅要知道AIDL如何使用, 也要知道如何手寫Binder介面. 這對你理解Android的Application和System services如何交互有非常重要的作用. Binder如何實現的倒不必著急看.
HAL
除非你對硬體特別感興趣或者想去方案公司上班, 否則別花太多時間在這一層.
CyanogenMod
這是一個基於AOSP的第三方Rom. 從這個項目的wiki里你能學到很多AOSP官方沒有告訴你的東西. 比如如何支持Nexus以外的設備.
DIA
這是一個Linux下畫UML的工具, 能夠幫你梳理看過的代碼.
XDA
這里有最新資訊和最有趣的論壇.
想到了再補充.