事情還得在兩天前說起，部門經理拉我去單獨聊天，跟我說公司現在需要做一個平臺型的SDK。因為公司接的遊戲都是租用著別人的SDK，要給租金不說，處理突發事情也不夠及時。所以，希望我來開發一個屬於公司自己的SDK。當時，我一聽，這挺好啊，那就做吧。就問要需求文件，經理居然回我，需求的話就是按照我們現在租用的SDK來開發就可以了。當時我就懵逼了，沒有需求文件怎麼去開發。就因為這個問題，我們討論了快半個小時，經理很堅定說，其實我就是需要和這個SDK一樣功能的就可以了。你就去用一下這個SDK就知道了，為什麼要我寫文件。其實，對於我們開發來說，比起看得到的功能來說，我認為SDK裡面的業務邏輯才是最重要的。我們能看見的功能，就只能模仿到表面，卻瞭解不了真正的精髓。沒辦法啊，既然經理給不了具體的需求，那隻能靠自己了。

既然靠自己，就得看看自己手上現在有什麼資源，自己的目標是什麼，下一步要做什麼。有什麼資源呢，有一個SDK的jar和一個SDK的lib。目標就是按照這個SDK去開發自己的SDK，現在我知道這個SDK的表面功能，下一步我要了解SDK裡面的業務邏輯。左思右想，要怎麼了解業務邏輯呢？叫開發商給原始碼是不可能，這輩子不可能給原始碼的。但是可以個接入文件，我這裡可能瞭解個大概的流程啊！於是，我拿到了SDK的接入文件，與接入的demo。經過認真的跑demo，看文件後。我為自己畫了個流程圖

在這個流程圖能看得見也就是 登入，註冊，支付，登出。其他的都是SDK內部業務邏輯上的介面。所以我從不相信SDK能靠幾個功能這麼簡單就可以撐起來一個SDK平臺，能撐起來的是背後強大的業務邏輯。

畫了流程，知道了一個SDK的大概框架。我的下一步就要看他們的原始碼，讓他們給原始碼是不可能，還是得靠自己。看原始碼才是看出一個應用真身，才知道一個應用能穩定執行的真正原因是什麼。看原始碼，那就用反編譯吧，把SDK反編譯，只能祈禱SDK沒有做過混淆的操作。經過一系列猛如虎的操作，成功把SDK反編譯了，謝天謝地，可以看原始碼。這就很滿足了！真開心去看原始碼的時候，才發現一個看起來簡單的SDK，原始碼居然這麼多！而且讓人不知從哪裡看起，更不知道每個檔案，每個方法的作用是什麼！

到這裡我才知道，我痛苦的開發SDK歷程才剛剛開始。我告訴自己不能慫，直面原始碼，別人看書我看原始碼。想開發出一個穩定的SDK，就要學習前人的經驗。看！不看不是人！

最後，致敬所有看過別人原始碼的同學。我也會記錄下來，我看原始碼的思路，方法。我是一名Android工程師，我為自己加油！