本文首發於微信公眾號——世界上有意思的事，搬運轉載請註明出處，否則將追究版權責任。微訊號：a1018998632，交流qq群：859640274

有人說我標題黨，也怪我開始決定寫的時候沒有注意標題，也沒想到會有這麼多閱讀量，的確會生出一些是非出來。那麼從現在開始標題改為 從零開始仿寫一個抖音App 系列。希望技術討論能夠多一點，沒看文章就噴的人能夠少一點。我會堅持寫下去，好好提升自己的能力。

連載文章

• 4.從零開始仿寫一個抖音App——日誌和埋點以及後端初步架構
• 5.從零開始仿寫一個抖音App——app架構更新與網路層定製
• 6.從零開始仿寫一個抖音App——音視訊開篇
• 7.從零開始仿寫一個抖音App——基於FFmpeg的極簡視訊播放器
• 8.從零開始仿寫一個抖音App——跨平臺視訊編輯SDK專案搭建

本專案的 github 地址：MyTikTok

一、寫在前面

這個坑可能會持續很久，之前開過好幾個坑，但是都不長久。原因是計劃趕不上變化。每過一段時間我都會感覺有更重要的事情要去做，所以之前開的坑就被我拋棄了。但是這一次不同，具體的不同點我會在下面一一列舉出來。

• 1.關於目的：筆者目前在抖音的競品裡面做android端的視訊拍攝和編輯這塊。大公司大家也知道，各個業務都是分層的，所以我們平時的業務都是在音視訊架構組封裝的sdk之上進行的。所以一旦時間長久了自身的競爭力就會減弱，畢竟沒有掌握“核心科技”。好在sdk的原始碼是內部開放的，所以我可以讀讀原始碼去了解“核心科技”。正好讀了原始碼之後可以練練手，自己去實現一遍，這就是本專案誕生的初衷。
• 2.關於程式碼：首先由於保密協議，我們公司的原始碼是絕對不能開源出去的，因此本專案的全部程式碼都將會是我自己根據讀原始碼獲取到的思想最後實現的。所以本專案最終在效能、相容性、程式碼可讀性都是不如原本的程式碼的，所以如果有讀者要整合入商業專案的話請慎重。
• 3.關於專案：本專案預計會持續1-2年的時間，除非我中途離職了，否則一定會堅持更新。目前的預期是每兩週更新一篇部落格，與此同時更新一版feature。此外本專案雖然說是寫一個抖音App，但其實最終專案中的實現只會是抖音App中各種特效的實現集合，至於和伺服器互動還有介面的互動方面我並不會花費很長時間去寫。當然除了抖音App中的特效，我有一個愛好是深度學習，所以我將會製作一些基於深度學習的特效整合到專案中，所以有這方面愛好的同學也可以和我多多交流。
• 4.饗讀者：本專案雖然是我自己的練手專案，但是也有部分目的是希望讓一部分不甘於現狀想深入學習android的同學和我共同進步。所以大家有專案上面的問題和github上的issue都歡迎和我交流。

二、專案概述

這一節我主要是想對未來專案做一個概述吧，說一下專案的技術棧，這樣也好讓大家對專案有一個概念。

• 1.MVP：這是專案的架構方式，熟悉架構的同學應該知道現在android中有三種架構方式：MVC、MVP、MVVM。為何選擇MVP想必大家也都清楚，首先MVC非常老舊也有一堆缺點所以第一個排除。然後是MVVM雖然這種架構已經被“吹”了很久了，但是到現在為止也沒有一個成熟完整的解決方案，雖然我之前幾個自己寫的專案都是使用MVVM（databinding為基礎），但是那都是小打小鬧。據我所知的“大廠”中沒有使用MVVM來當做真正的解決方案的。所以如果大家對這種MVVM有興趣的話，可以去看看我之前寫的幾篇部落格和專案。另外說一句，我會自己從零開始封裝一個MVP的框架，也算對自己一個挑戰吧。
• 2.okhttp+retrofit：這兩個框架想必大家都很熟悉了，我就不多說了。只是我會在專案的過程中對這兩個框架進行深度的定製以實現一些有意思的東西，所以這一方面還是有點看頭的。
• 3.fresco：這個也是廣為人知的框架了，可以說這是最強大和效能最好的圖片框架了吧。不是我“吹”這個框架，雖然他的缺點有一些比如：侵入性強、框架比較重。但是一個像抖音這樣的音視訊app，使用fresco是非常適合的，其他圖片框架像glide、picasso等等，都有功能不全的問題。此外因為我完整的讀過fresco的原始碼，所以我也可以對fresco進行比較深度的定製。對fresco原始碼感興趣的同學也可以去翻翻我之前的部落格。
• 4.外掛化+元件化+熱修復：這幾個東西算是類似的吧，我還是一個個說
  • 1.外掛化：幾個優點分別是，多成員負責不同的模組的時候加快編譯速度、各個模組解耦、減小發版的包大小按需載入。使用的框架我傾向於自己寫一個，但是不知道有沒有時間，最後可能會在tinker和360RePlugin中選擇一個吧。
  • 2.元件化：其實和外掛化類似，主要用於解耦模組，用到的技術是路由元件和gradle分模組依賴技術，傾向於自己寫一個。
  • 3.熱修復：主要用於應對線上bug，應該會在andfix和Robust裡面選一個，畢竟我們的專案對這個要求不高
• 5.google新MVVM元件：這是google最近釋出的元件套裝ViewModel+Room+Lifecycles+LiveData，雖然我們用的是MVP框架，但是google推薦的元件使用起來還是用好處的。
  • 1.首先Room就可以拋棄了，他是資料庫的元件，我們有更好的選擇
  • 2.ViewModel：第一個功能可以使ViewModel以及ViewModel 中的資料在螢幕旋轉或配置更改引起的Activity重建時存活下來，重建後資料可繼續使用，第二個功能可以幫助開發者輕易實現Fragment與Fragment之間，Activity與Fragment之間的通訊以及共享資料，所以還是很有必要使用的，可以整合在我們的MVP框架中。
  • 3.Lifecycles：這個就不用說了，生命週期元件是Android官方架構元件中的核心元件,它可以使各種例項作為觀察者與Activity和Fragment等具有生命週期特性的元件繫結在一起，LiveData和ViewModel，都是基於此元件，簡而言之就是，你將需要繫結生命週期的例項註冊給該元件，該元件就會在你指定的某個生命週期方法執行時通知這個例項。
  • 4.LiveData：這個元件其實做的和Rxjava的事情類似，第一個功能是觀察者模式，在Value發生變化時通知之前註冊的所有觀察者，第二功能是基於生命週期元件與Activity和Fragment等具有生命週期特性的元件繫結在一起，在生命週期發生改變時停止或恢復之前的事件。瞭解Rxjava的同學都知道這些功能在其擴充包中都是有的，所以這個元件我們可以不使用。
• 6.Rxjava：不用說Rxjava的生態已經很成熟了，他有RxCache，RxLifecycle，RxAndroid，RxPermission，Retrofit-Adapter等大量並且強大的衍生庫，在寫專案的過程中我也會對使用到的Rxjava的功能進行分析。
• 7.AOP技術：這個技術用處很多，比如日誌記錄、自動埋點等等，目前候選的框架有：AspectJ、APT和ASM這些到時候看實現日誌和埋點框架的時候再選吧。
• 8.JNA：可能有些同學不瞭解這個框架，其實這就是一個代替jni的對java開發者更加友好的呼叫native方法的框架，因為我前面說了我們這個專案主要目的是實現抖音中的各種特效，所以必不可少的會用到jni，因此我用了JNA這個更加方便的庫。
• 9.opencv：目前我也沒有開始瞭解我司到底是使用了哪種技術來實現視訊中的各種特效，所以暫定是opencv，以後隨著我深入核心程式碼，可能框架會改變。再次宣告，本專案中的程式碼並不會有任何我司的核心程式碼，所以大家最好別將專案程式碼用於商業專案
• 10.深度學習框架：我之前也使用過tensorflow lite，但是這個框架太簡陋了，所以現在的有一個新選擇是騰訊的ncnn，這個問題將會在到了該使用深度學習的時候再選擇。另外如果對tensorflow lite有興趣的同學可以去看看我之前寫的圖片處理APP的和一個使用demo。
• 11.資料庫：初步預想是使用GreenDao，使用起來方便一些，而且我們對於資料庫使用程度並不強，我司就是使用這個框架，所以還是可靠的。
• 12.WebView：最近hybird app非常流行，所以專案裡先把這個技術佔一個坑吧，到時候可能會實現一個簡陋的與js互相呼叫的WebView容器吧，到時候再看。
• 13.待補充，不知道還有什麼技術或者框架是一個成熟的App應該使用的，所以之後想到會陸續補充，如果大家有什麼建議，特別、十分、非常、超級的歡迎在評論區指出來，十分感謝！

三、尾巴

在最後想和大家聊聊我的想法與未來android工程師的發展道路。

1.如何當好一個大廠的螺絲釘

• 1.都說面試造核彈，入職擰螺絲，我雖然是一個才剛入職的應屆生，但是感觸也頗多。入職之前希望做點有意思的事情，能多麼多麼牛逼。但是其實大多數人進入了大廠都是有可替代性的，真正不可替代的只是頂部的小部分人，所以最後大多數人每天的工作就是維護業務，接需求，修bug。我就是大多數人中的一份子，我怕我就這樣適應了這種工作，然後一天天的重複相同的事情失去了激情，最終為了錢在碼程式碼退變成為一名光榮的“程式碼搬運工”。
• 2.所以如何當好一個大廠的螺絲釘？辭職是不可能辭職的，這幾年都不會辭職的，大廠福利和薪資又這麼好，只能去利用公司的資源學習更多的東西，才能勉強維持激情。所以我才會決定開這個專案的坑，不斷學習公司裡的技術做一些自己沒做過的事情，保持初心提升自己。

2.android工程師的發展道路

• 1.“我要轉前端”、“我要轉後臺”、“android開發沒人要了”......想必這些話在各種android技術群裡時長會出現，這樣也加深了不少android工程師的焦慮感。但是我想說的只有一句話：牛逼的人做啥都牛逼，只有人的問題沒有方向的問題。
• 2.為什麼android工程師沒人要了？首先我們得明確一點，在可預期的時間範圍內（五年內）android這個平臺是不會死的。在我看來只有更加新型的互動作業系統（ar、vr、mr?）會革了android的命，但是最近是看不到希望的。明確了上面一點，我們就可以聊聊為啥android沒人要了。
  • 1.第一個原因可能是經濟問題導致公司倒閉了，那麼App就少了，這個無解。
  • 2.第二個原因應該就是hybird App、類react native框架、小程式、flutter等等跨平臺解決方案的崛起。
    • 1.首先hybird App可以不用管，因為“慢”是一個永恆的問題。其次“小程式”在我看來也不是一個大問題，但凡一個大一點的網際網路公司都會有原生App，因為你不可能把自己的小命完全交給騰訊。
    • 2.所以現在在和原生android搶地盤的就是類react native框架與flutter。其實我們可以這麼看，這兩種其實都是通過js寫業務邏輯然後將繪製邏輯通過c++交給native控制元件，所以只要你學的深並不用怕這兩個東西搶了你的飯碗。
• 3.android工程師的發展道路在哪？我目前想到的一個詞就是“深挖”，具體體現在：深入三方框架原始碼、深入framework、深入c++層、深入音視訊處理以及深度學習。我想大家從我前面的專案概述中就能知道為啥了。成為一個只有很少人能替代的人，才是你我的核心競爭力。

3.計劃

說了這麼多，我來定一個計劃吧，也算是接下來整個專案的計劃表，這樣也好推動我進行專案的更新。其實上面概述中提到的技術我只熟悉1/3，希望我能堅持下去在接下來的1年裡能完成這個對於我來說巨集大的專案。（暫定兩週一個推進節點，寫一篇部落格，專案大更新一版）

• 1.完成專案基礎結構的搭建，熟悉概述中的各個不熟悉的技術
• 2.完成自建MVP框架和元件化路由框架的編寫
• 3.將google新MVVM元件整合進自建MVP元件中，完成日誌框架編寫
• 4.完成埋點框架編寫，寫一個python伺服器進行埋點資料以及其他需要上傳伺服器的資料展示（上）
• 5.深入學習ncnn框架，寫一個python伺服器進行埋點資料以及其他需要上傳伺服器的資料展示（下）
• 6-10.開始畫介面，著重學習公司核心程式碼，著重繼續學習深度學習
• 11-20.介面畫完開始實現特效每個節點實現兩個特效，同時學習公司核心程式碼和繼續學習深度學習
• 20之後.離一年還有6個節點，算是進行收尾工作以及為中間突發事件留下的機動時間。
• 另外.前1-5中會適當學習公司核心程式碼以及深度學習

不販賣焦慮，也不標題黨。分享一些這個世界上有意思的事情。題材包括且不限於：科幻、科學、科技、網際網路、程式設計師、計算機程式設計。下面是我的微信公眾號：世界上有意思的事，乾貨多多等你來看。