共计 3246 个字符，预计需要花费 9 分钟才能阅读完成。
Hello，各位铁铁，明天咱们不聊技术，侃一侃一个理论开发中的问题，那就是，在以往的开发中，你遇到过难以解决的问题吗？或者咱们换个角度，面对产品经理提过来的，很难实现的需要，你是怎么解决的？又或者本人在研发某个性能时，遇到阻碍，又是如何解决的？
面对此类的问题，如果老铁你从头至尾都没遇到过，我只有艳羡的份，别的没有，艳羡的可能是你的手上技术，也可能是你的口上技术，也就是，要么小菜一碟的实现，要么也是小菜一碟的回怼产品经理，实现不了，无奈实现，总之，你的过人技术，必定着实膜拜。
像对于我而言，就显得平平奇奇，每次的我的项目，公司的也好，本人的也好，简直每次都有几个小挫折，都须要破费一些工夫来调研，来解决，而面对产品经理提出的需要，除了抗拒，还有遵从，所以，基本上，很少回绝，一是体面，二是也想挑战一下未知技术，所以大部分我的解决形式是，双手接收，通通揽入怀中，经验了如此之多，也缓缓的知道了一些另辟蹊径之办法，的确，很多符合实际又难以实现的性能，真的有其余的解决办法。
记得刚加入工作，也就是 8 年前，有一个需要，要实现顶部 Banner 和上面的列表进行联动下拉刷新，初入职场的我，纯小白一个，这就是一个很简单的性能，兴许回过头来只能讥笑过来的本人，但谁不是一步一步的走过去的，是吧？过后的本人，头也很大，怎么搞，一点思路都没有，去网上搜，也不晓得搜什么，真的不会搜，一点都不夸大，你刚接触一门语言，所谓的认知真的是很匮乏。
上面是 ListView，下面是 Banner, 两个控件怎么联动到一起，过后本人就陷入到了，怎么用另一个控件包裹住它俩，然而怎么也没实现；如此简略的问题，在过后，却成了难以解决的问题，东搜搜，西搜搜，缓缓摸索，才发现，把顶部的 Banner 当做 ListView 的头 View，就解决了，的确，绕了很大一圈，才发现，这样的性能，人家本身都存在。很多时候，自身的局限就限度了它简略的实现，你感觉它难，其实它就你眼前，很多这样的性能，的确须要另辟蹊径的从基本发现，而不是有限的挖掘。
再说一个最近开发中的问题，咱们都晓得 Jetpack 中有一个组件 navigation，一个导航的库，通过可视化的形式来治理 Fragment 的切换，以后的我的项目，就是应用它作为了底部的 tab 切换，但随之而来的一个问题就来了，每次点击底部 tab，以后的 Fragment 就会从新加载，这种成果，必定是不符合实际需要的，那么怎么去解决它呢？此时的另辟蹊径，没有别的方法，只能去查看外面的源码，通过源码，才发现 Fragment 的切换是通过 replace 形式来切换的，并且退出回退栈，也就是说每次切换 Fragment, 都会销毁视图和从新创立视图，找到了起因之后，从新创立继承类，批改导致谬误的办法，做针对性的解决。此时的问题，如果你还想用它，只能破费心理去钻研它，其它的别无他法，除非你不必它。
理论开发中的问题，我置信很多都须要另辟蹊径，说是另辟蹊径，不如说是寻找解决的办法，再说一个本人之前遇到的小程序问题，真的才是另辟蹊径，因为遇到了问题太多了，多的差点本人的小程序就阉割了。
还记得当微信小程序推出来之后，本人也退出了开发营垒，但随之而来的一个问题是，数据从哪里来？又是如何渲染进去？兴许对于一个企业，或者说一个团队而言，这些都是微不足道的小问题，然而对于一个集体开发者而言，确确实实是要面对的问题，如果在 2017 年，你打算要做一个常识技术分享的小程序，你该如何进行呢？
买服务器，买域名，买证书，找人或者本人开发一套接口，而后本人依据接口，依照小程序语法来研发属于本人的性能，ok，当然是能够的，问题又来了，小程序不反对集体 webview，始终到当初，依然未对集体凋谢，针对此问题，你的页面内容如何动静展现呢？注册个公司吗？因为一个小程序，又是买服务器，又是开公司，你感觉划算吗？是你，在 2017 年，你该如何解决？
种种的问题，都是妨碍一个想要开发小程序的开发者，特地是一个集体开发者，一个想收费做一个小程序的开发者，兴许旁人遇到这样的问题，就间接退缩了，但我不一样啊，我是杠头啊，越是妨碍，越要另辟蹊径的去找到解决形式。
确确实实，在 2017 年，这些都是妨碍本人开发小程序的前提，我的数据从哪里来，又是如何进行渲染到页面上呢？把内容和资源间接打包到小程序里？必定不行，一是数据无奈动静更新，二是小程序也有大小限度，过后打包体积是 2M，此办法行不通，转而摸索其余形式。
过后我的想法是，我只是做一个常识技术分享的平台，并不波及到交互，是不是找一个动态文件托管的平台，也能够呢？过后也是说干就干，我把一些数据，写成了一个一个的动态 txt 文件，写好之后，就搜寻一些收费的服务器，放上去的确能够动静获取，但收费的终归是收费，很不稳固，还有正式的打包上线，必须是 https，收费的都是 http，显然这个是无奈满足的。
兜兜转转，盯上了 github，咱们都晓得 github 能够实现一个动态的网站，同样也能够托管一些文件资源，并且还是 https 的，真的是非常合乎，小程序的第一版，就全副托管到了 github。尽管解决了文件托管的难题，然而 github 毕竟是国外的，国内有时拜访也不稳固，最初盯上了阿里云 code，当前的版本，所有的动态文件和图片，都托管到了阿里云 code，拜访既快也很稳固。
从此动态文件的难题是解决了，然而图文并茂的文章，如何展现呢？毕竟集体小程序是不反对 webview 的，把文章做成一个一个的图片，而后，放到动态文件里，每个页面进行申请加载图片？形式是能够，然而图片资源有时太多，而且加载图片过大，有加载的过程，而且也消耗流量，对用户也不敌对。
后续针对文章的展现，本人消耗了大量的工夫去钻研，如何疾速的实现一篇图文并茂的文章，在小程序里可能敌对的展现，最终定了一套计划，就是，把文章转为一个动态的 txt 文件，也就是一个纯 json，而后由小程序文章页面依据文章 id 来申请，把对应的 Json 转化为文章。
通过 json 的形式，依据类型动静的创立小程序标签来展现不同的内容，的确能够满足当下的需要，而且图文并茂，十分的合乎，然而每篇的文章，如何生成对应的 Json，文字款式和图片款式，如何更改呢，须要手动一段一段的复制吗？显然太消耗工夫了，于是，接下来，依据文章的内容，做了一个动静转化 json 的可视化工具，如下图，通过这一列的操作，算是解决了集体开发者的一个妨碍项。
通过这种形式，有一个问题存在，那就是须要本人把文章内容及图片复制过去，尽管可视化的，但也稍稍耗时，既然市面上有富文本编辑器，为何不加以革新呢？无非生成的是 html 标签，把这些转化为小程序的标签不就行了，的确，这种想法是可行的，进而又放慢了文章的 json 生成。
小程序接踵而至的问题，如果不能无效的另辟蹊径，很难有这样的一个产品出炉，当然了，我说的收费的，集体开发者单独研发的，所以啊，老铁们，遇到问题，很多时候，须要咱们别具匠心，不能执拗在一个点上，否则，真的是既付出了工夫，也付出了精力，最初也难达到咱们的冀望。
上述简略的通过本身的三个小例子，论述了一下本人面对难以解决问题的时候的解决形式，大家能够发现，面对问题的抉择，我个别都是先揽下，毕竟对于未知的世界，另辟蹊径，兴许有可能的实现计划，无论是针对公司里的我的项目还是本人的我的项目，从来不会间接的放弃，兴许会有很多艰难，但真正的解决完这些问题后，你会发现，除了技术的晋升，还有认知的晋升。
在开发中会遇到各式各样的问题，多多少少都会有一些难以解决的问题，当遇到这些问题的时候，不是一上来就 say no，而是面对问题的自身，咱们是否有进行解决的思路和认识， 技术的自身不是狭窄的，不是回绝的，而是发散的，翻新的。
好了各位老铁，遇到难以解决的问题，你是如何解决的呢？
当然了，面对难以实现的需要还有艰难的问题，有一个场景，领导问了你，你间接回绝了说不能实现，解决不了，但偏偏他人实现了，解决了，这种状况下，你……
