開放原始碼的回收與再利用-資料下載頁
2025-09-20 08:26本頁面
【導(dǎo)讀】Google時代的來臨也加快了程式員的各種面向速度的。Google是找到問題答案的最佳途徑，你會遇到的。IM軟體的流行也使得同儕網(wǎng)絡(luò)變成好的解題方。開放原始碼質(zhì)與量俱皆大增。透過搜尋引擎極易取得所需的程式碼。後Google時代的程式員：除了書籍或文章外，更從。解決問題或麻煩的方式不同。前Google時代的程式員：嘗試、摸索，詢問前輩，重視的技能取向不同。建立好的整合架構(gòu)。善於搜尋所面臨問題的解決方案，並從中快速吸取新。善於追蹤了解文件不足的程式碼。程式碼來自世界各地，其目的或範圍往往不盡人意。施以最小幅度的心力，達成相同的目的。暫時忽略非第一個里程碑的內(nèi)容。選擇執(zhí)行平臺相符或相似者。相似時仍需花費移植心力。選擇版權(quán)宣告合適者。即使已經(jīng)盡量的選擇範圍接近自己所需的專案，但多。必須制定幾個不同階段的目標，並且從最小的里程碑。被註解掉的部份，在通過第一個里程碑後，解決其編。修整介面，保持作用，符合目的。成功的達成第一個里程碑後，便逐一的依照同樣的方
【正文】 xt *)。 ? struct AVInputFormat *next。 ? } AVInputFormat。 判斷 AVInputFormat各欄位的作用 ? 用非物件導(dǎo)向的方式來實作物件導(dǎo)向的多型 ? 有很多一看就知道是探測格式時不會需要的 ? 我們應(yīng)該要特別注意 read_probe及 extension兩欄位 訂定不同的階段，從最小的里程碑開始 ? 我們試著訂出三個階段 ? 探測 mpegps格式 ? 探測 mpegts格式 ? 探測其他格式 ? 試著編譯，一定會發(fā)生很多問題 ? 結(jié)構(gòu)之間的環(huán)環(huán)相扣：為了 AVInputFormat中的read_header，我們得括入 AVFormatContext和AVFormatParameters ? 後來我們會因為更了解而發(fā)現(xiàn)這個函式指標根本不需要 ? 但此刻的我們只好先把它們先加入 ? 在 ：av_register_input_format()、 match_ext()、av_probe_input_format() 適度的斬斷關(guān)聯(lián)性，尋找適當?shù)奶娲? ? av_probe_input_format() 會用到許多 utility函式 ? av_realloc()、 get_buffer()、 url_open()、 url_fseek()、url_fclose() ? 這些函式看起來就是標準 C函式庫中的函式差不多。所以決定退化回標準 C函式庫中函式 ? 改用 malloc()來代替 av_realloc()及 get_buffer()的作用；改用 fopen()來代替 url_open()；改用 fseek()來代替url_fseek()；改用 fclose()來代指 url_fclose() ? 要建立防火牆，不能讓相依性的火一直蔓延的燒 整理介面，去除不必要的元素 ? 在這過程中，我們愈來愈了解整體的運作方式 ? 所以我們發(fā)現(xiàn) AVInputFormat裡的結(jié)構(gòu)有很多欄位是不必要的 ? 只需要保用 read_probe這個函式指標即可 ? 其他的部份我們都可以拿掉 ? 更可以順手拿到一些不必要的資料結(jié)構(gòu)定義 ?例如拿掉了 read_header可以一舉拿掉AVFormatContext及 AVFormatParameters的定義 做好心理建設(shè)，面對混亂 ? 在這個過程中，我既不去修改它的命名慣例，更不會去重新排版 ? 我把所有取出來的程式碼包在一塊，把它當做一個黑箱子來使用 ? 有些取自標頭檔的定義也許還有精簡的可能性，但是先將它擱在一塊 ? 此刻我們需要的只是生產(chǎn)力－短期間內(nèi)透過回收和整理取得我們想要的產(chǎn)物 結(jié)論 ? 最後支援十種格式以上的這個格式探測程式庫，大小不到 40KB ? 幾乎沒有寫下半行程式碼，但憑藉著回收和整理的技巧，只需一晚，我們得到了一個相當實用的程式庫 ? 原先對各視訊檔案格式完全不通的我，也能達成這個目標，而且在這個過程中對視訊檔案格式也有一定的認識 ? 開放原始碼的各種程式片段俯拾可得 ? 需要的是化桌子為椅子的功夫 Q amp。 A Thanks
教學(xué)課件相關(guān)推薦
鄂ICP備17016276號-1