這些年在項目開發(fā)中遇到過很多困難,? 有些在當(dāng)時覺得很困難, 但是后來回頭再看時感覺也沒那么難,? 所以要在其中找一個最困難的, 好像也不太容易比較.

這里就簡單說兩個印象最深刻的吧.

第一個是當(dāng)開始開發(fā)時的一個頁面嵌套滑動的需求開發(fā), ? 用在查詞結(jié)果頁的展示, ?(此處可以展示實景)

難點是要在一個可以側(cè)滑的場景下, ?也可以上下滑動, ?并且在上下滑動的同時要控制header的展示位置, 當(dāng)時也是參考了很多實現(xiàn), 包括, 外部viewpager+內(nèi)部listview, ?listview+懸浮header

scrollview+listview ? ?發(fā)現(xiàn)都不能很好的實現(xiàn), ? 當(dāng)時自己也是對頁面觸摸事件分發(fā)一知半解, ?對嵌套頁面的滑動沖突沒有實際經(jīng)驗, 所以面對這個問題覺得很頭大.

好在最終在借鑒各種方案的前提下, ?通過外部scrollview + viewpager+listview的方式實現(xiàn)了, ?主要邏輯都在外部的scrollview的dispatchTouchEvent()中,

經(jīng)過這一兩年, 也遇到過一些其他的例子, 現(xiàn)在仍然感覺當(dāng)時的處理還是比較有道理的.

通過這個需求, 自己對頁面事件分發(fā)流程的理解也算是更深一步.

第二個要說一個應(yīng)用換膚的需求, 當(dāng)時產(chǎn)品提出一個籠統(tǒng)的換膚的要求, ?但沒有說明具體的方式方法, ?我們也是分析研究了幾種當(dāng)時能夠想到的方式, 包括主題切換方式實現(xiàn), ?還有通過插件方式提供資源包, 又分為靜態(tài)預(yù)置, 動態(tài)獲取兩種更新方式. ? ?形式上也分為簡單資源壓縮包, 或者以apk形式形式提供. ? 而在資源包具體實現(xiàn)上又分為全量包, 和差量包;

這個需求的難點在于前期的這些調(diào)研, ?需要對每種方案都進行研究, 分析原理, 風(fēng)險, 并測試流程.

最終考慮到我們的換膚需求, 并沒有太多的動態(tài)性, ?作為我們的應(yīng)用未來可能也不會qq一樣會有第三方提供主題插件, ?而且未來的UI變化太大, 也無法提前確定一套顏色+圖片的設(shè)計框架.

所以最終我們選擇了最保守的方案, ?只是抽取了應(yīng)用設(shè)計的顏色, 在不同的5個主題下分別定義了這幾十種顏色, 而在后期的頁面開發(fā)中都必須使用這些顏色號, 而不能直接設(shè)置具體顏色值.

這樣主題切換時, 就會自動呈現(xiàn)不同的顏色主題. ? 此處可以實景演示.

代碼重構(gòu): ?從最開始的原始結(jié)構(gòu): activity+ fragment 逐漸過渡到mvp模式開發(fā). ? ?在業(yè)務(wù)分模塊的前提下, 區(qū)分model, presenter, view三個部分

其他也有很多難點,包括:

實現(xiàn)兼容的狀態(tài)欄沉浸式方案, 并且解決因此引起的AdjustResize模式失效. ?至今stackoverflow上還有這個問題的討論, 當(dāng)時也是查了很多資源, 才解決.

加快應(yīng)用啟動速度, ?需求要求我們的查詞頁面在所有機型上0.5s之內(nèi)啟動完成, 這個為了這個需求費了好大勁, 顯示分析頁面啟動過程中所有的耗時點, ?然后重構(gòu)代碼, 延遲加載, 優(yōu)化布局, 去掉大圖片資源, 改為自定義顏色值, ?自定義一些布局控件, 減少measure步驟, 等等, ?然后再次分析耗時點. ? ?最終基本上在所有手機上實現(xiàn)0.5s內(nèi)啟動. ? ? 但很可惜后期的需求又把這個需求覆蓋了, 我們現(xiàn)在也提供了啟動廣告頁面展示, 已經(jīng)不再要求快速啟動了. ? 但仍然在這個過程中, 熟悉了一套優(yōu)化啟動速度的經(jīng)驗.

fragment的引入. ?之前的應(yīng)用版本中沒有使用過fragment , 而我們從7.0開始需要一個側(cè)滑菜單, 并且需要支持平板, 所以是一個引入fragment的好契機, ?通過引入fragment, 實現(xiàn)了一部分頁面的復(fù)用邏輯, 像是左側(cè)的側(cè)滑菜單, ?在平板上就是常駐的. ? 實現(xiàn)本身并沒有什么難度, 但遇到的問題還是很讓人頭痛.

一篇博文:http://www.reibang.com/p/d9143a92ad94

在Activity之外, 還得重新研究fragment的生命周期, 而fragment的生命周期更復(fù)雜;

startActivityForResult的返回碼需要處理; ?在嵌套fragment中收不到這個回調(diào). ?新版android已經(jīng)修復(fù)了這個問題

getActivity()返回null; 常發(fā)生在內(nèi)存不足被重啟的情況下; ?有異步操作沒有完成, 而fragment已經(jīng)detach了. ?好的建議是在fragment內(nèi)部存一個activity實例;

有使會生成兩個一樣的fragment實例, ?給調(diào)試帶來困難; ?-- 什么情況下? ?內(nèi)存重啟, ?具體可以見:http://www.reibang.com/p/78ec81b42f92//新版android已經(jīng)修復(fù)了這個問題; ? 能用replace就不要使用hide() show()

popBackStack 不可靠, 容易導(dǎo)致白屏問題; ?--具體原因是內(nèi)部的bug, 新版本android 已經(jīng)修復(fù);

Fragment傳參, 需要注意, fragment自動重啟時參數(shù)為空的情況.建議使用setArguments() ?但是一些復(fù)雜的自定義類對象, 又做不到.

fragment切換動畫不如view切換動畫好實現(xiàn);

形成經(jīng)驗:只有在整個頁面都需要復(fù)用的時候才考慮使用fragment, 而如果是一些局部顯示, 優(yōu)先考慮使用view . ? 盡量不要使用嵌套fragment; 配合mvp模式, fragment盡量不參與業(yè)務(wù)邏輯;

總之要輕度使用fragment;

小說的排版,

需求要支持小說閱讀頁面點擊查詞功能, ?需要動態(tài)計算點擊位置對應(yīng)的單詞; ?同事又要支持閱讀頁面點擊跳轉(zhuǎn), 這樣在實現(xiàn)時, 需要增加標(biāo)簽支持, ?這與前面的點擊查詞功能有些沖突, 實現(xiàn)時非常頭痛.

如何點擊取詞;

如何在TextView中顯示鏈接, 并相應(yīng)點擊事件.

消息推送:

機型適配, 個別小機型崩潰問題定位.用戶修改了字體, 用戶root刷機之后崩潰, 還有修改了特殊語言之后的崩潰,

SDK開發(fā);

自動化測試方案: 使用jenkins搭建了一個自動化運行平臺, ?可以自動執(zhí)行寫好的腳本, 驗證核心查詞接口的功能,

難點是包括jenkins, robotium, 都沒有使用過, 需要從0開始,

客戶端頁面可被后臺隨時啟動功能. ?可以根據(jù)需要, 隨時通過后臺喚起客戶端的一個頁面, 可以是一個展示網(wǎng)頁的頁面(此時需要把網(wǎng)頁地址作為參數(shù)傳給客戶端), ?也可以是客戶端已經(jīng)存在的任何一個頁面, 比如一本小說詳情頁, 一個課程頁面, 在需要開展促銷活動的時候, 提供跳轉(zhuǎn)到這些頁面的能力;

入口是后臺推送入口和主頁預(yù)留的活動入口;

需要實現(xiàn)一種后臺可配置的啟動字符串機制, ?最后確定了通過以個json格式的字符串, 來制定要啟動的頁面, 和附帶相應(yīng)的參數(shù); ? 這樣客戶端所有的頁面都不需要修改, 只需要在入口處解析出這個命令字符串, 然后跳轉(zhuǎn)到對應(yīng)的頁面;

遇到的困難是, 有些已有的頁面需要很復(fù)雜的參數(shù), 甚至是一個bean 對象; ?所以在給這些activity準(zhǔn)備參數(shù)的時候就要通過字符串的形式提供, 然后再解析為bean 對象實例.

從某種意義上來說, ?就是定義了一種啟動頁面的協(xié)議.

內(nèi)存泄漏分析: